Most international SEO problems trace back to one confusion: teams treat language targeting and country targeting as the same lever. They aren’t. Language targeting answers who reads the page — the language a person actually uses. Country targeting answers where they are — the geography that governs their currency, shipping, and law. You can serve one Spanish page to every Spanish speaker on earth, or twenty country-specific Spanish pages, and those are completely different strategies with completely different signals, costs, and failure modes. Conflate them and you end up with duplicate pages Google can’t tell apart and hreflang tags that quietly cancel each other out.
The Core Distinction: Who Reads It vs Where They Are
Language-based targeting segments your audience by the language they read in, regardless of location — a French speaker in Montreal, Dakar, and Marseille all get the same French page. Country targeting segments by geography, regardless of language — everyone in Canada gets the Canadian experience whether they read English or French. The two axes are independent, and the smartest international sites decide on each one separately rather than assuming a page is “the German one” as if language and country were a single fact.
The practical reason this matters: language is cheap to serve well and country is expensive. One language version can rank across every market that speaks it, sharing all its authority. A country version needs its own reason to exist — localized pricing, a legal difference, region-specific stock, a genuinely different dialect. When there’s no such difference, splitting by country just fragments your signals for no gain.
When Language Targeting Is the Right Call
Reach for language targeting when the same content serves speakers across borders equally well. A SaaS product with global pricing in USD, a documentation site, a media publisher, a B2B tool sold the same way everywhere — these rarely need a separate page per country. One en page, one es page, one de page consolidates all the links and engagement each language earns into a single URL that competes hard in every market that speaks it.
Language-only targeting is also the honest default when you’re early. It’s far easier to run three language versions well than thirty country versions badly. Start language-based, watch where real demand concentrates, and split a specific market off into its own country page only when the data says that market behaves differently. Growing the page count before you have a reason is how sites end up with hundreds of near-identical URLs that dilute rather than compound.
When Country Targeting Earns Its Keep
Country targeting is worth the overhead when the market genuinely diverges. E-commerce with local currency, shipping, and tax is the clearest case — a shopper in Mexico and a shopper in Spain both read Spanish, but the price, the delivery promise, and the returns policy are different products. Regulated industries (finance, health, gambling) often need country pages because the legal copy changes. And dialect matters more than people admit: European Portuguese and Brazilian Portuguese, or Iberian and Latin American Spanish, differ enough in vocabulary that a shopper notices, and matching their variant lifts trust and conversion.
The test is simple: if you removed the country distinction, would a real user in that market get a worse experience or wrong information? If yes, build the country page. If the only difference is a flag in the header, you’re manufacturing duplication.
How hreflang Encodes Both Signals
Hreflang is the tag that tells Google which version to show which searcher, and it’s built to carry exactly these two dimensions. The value is an ISO 639-1 language code, optionally followed by an ISO 3166-1 Alpha-2 region code: en is language-only targeting, en-gb is English speakers in Great Britain, es-mx is Spanish speakers in Mexico. Language alone is valid and common; region alone is not — you cannot write hreflang for a country without naming a language.
Three rules make hreflang work, and each is a common failure point:
- Reciprocity. Every version must reference every other version, including itself. If page A points to page B but B doesn’t point back to A, Google discards the whole cluster. Bidirectional or nothing.
- An
x-default. Add onehreflang="x-default"entry pointing at the fallback page for users whose language or country you don’t explicitly cover — a country selector or your primary version. - One implementation, not three. Declare hreflang via HTML
<link>tags in the head, an HTTP header (for non-HTML like PDFs), or an XML sitemap — pick one. Doubling up creates conflicting signals.
The Classic hreflang Mistakes That Break Everything
The single most common error is inventing region codes. It’s en-gb, not en-uk — “UK” isn’t the ISO 3166-1 code for the United Kingdom, so en-uk is invalid and ignored. The same trap catches teams who put a language where a region belongs, or a region where a language belongs; the order is always language-then-region. Second is the reciprocity failure above — usually one template that forgets to include a self-referencing tag. Third is pointing hreflang at URLs that redirect, 404, or carry a noindex, which invalidates the annotation for that pair.
These are exactly the errors a crawl catches and a spreadsheet doesn’t, because they only surface when you see the whole reciprocal graph at once. SEO Rocket’s real-crawler site audit renders your pages the way a bot does and flags broken or non-reciprocal hreflang along with duplicate content across language versions — the two problems that quietly kneecap most multilingual sites. Fixing a missing return tag is trivial; finding it by hand across a few hundred URLs is not.
URL Structure: ccTLD vs Subdirectory vs Subdomain
Where you put each version shapes both signals. There are three structures, and none is universally correct:
- ccTLD (
example.de) sends the strongest country signal — Google geo-targets a.dedomain to Germany automatically, no configuration. The cost is real: each ccTLD is a separate domain that builds authority from zero, and buying and maintaining them across markets is expensive. - Subdirectory (
example.com/de/) keeps everything on one domain, so every version shares the root’s authority. It’s the easiest to manage and often the pragmatic winner for sites that can’t spare authority per market — but it carries no automatic geo-signal, so you lean entirely on hreflang. - Subdomain (
de.example.com) sits in between — cleaner separation than a folder, but Google treats subdomains as somewhat separate, so authority sharing is less certain than with a subdirectory.
For pure language-based SEO where you’re not geo-targeting at all, a subdirectory (/es/, /fr/) is almost always right: you want the languages sharing one authority pool, and you’re using hreflang, not a domain, to route users.
Google Retired the Country-Targeting Setting
If you learned international SEO before 2022, you may remember setting a target country for a gTLD site in Search Console’s International Targeting report. Google retired that country-targeting setting in 2022 — it’s gone. There is no longer a switch that tells Google “this subdirectory is for Canada.” Geo-targeting now relies entirely on the organic signals: a ccTLD, your hreflang region codes, server and CDN location, and local links and mentions from within the target market. This is the modern reality behind country targeting: you earn it with signals, you don’t declare it in a dashboard.
That shift makes hreflang region codes and genuine local relevance more important than they used to be, because they’re now doing the job the old setting used to do. It also means the language-versus-country decision is entirely yours to encode — Google reads the structure you build, not a preference you tick.
Why Auto-Redirecting by IP or Browser Language Backfires
The instinct to “helpfully” redirect a visitor to their local or language version by IP address or Accept-Language header is one of the most damaging patterns in international SEO. Googlebot crawls predominantly from US IP addresses, so an IP redirect can trap the crawler on your US or English version and prevent it from ever discovering — and therefore indexing — your other versions. You’ve built ten language pages and let Google see one.
The durable pattern is user choice, not forced routing: detect the likely preference and suggest it with a dismissible banner or a visible country/language selector, while letting every version remain independently crawlable at its own stable URL. Suggest, never hijack. Let hreflang do the matching for search, and let the user override for themselves.
Beyond Google: Baidu, Yandex, and Naver
Language and country targeting for Google doesn’t automatically translate to the engines that dominate specific markets. Baidu leads in China and has its own ranking system, indexing preferences, and strong sensitivity to hosting and site behavior within China. Yandex remains a major force in Russia with its own algorithm and webmaster tools. Naver dominates South Korea and surfaces results in a portal-style layout that blends its own blog, café, and knowledge properties, so ranking there is a different game than ranking on Google. If a target market runs on one of these engines, treat it as a separate optimization track with its own rules — not a hreflang variant of your Google strategy.
A Decision Framework You Can Apply Today
Put the two axes together and the choice gets concrete. Work it in order:
- List your markets by language first. Group everyone who reads the same language. That’s your baseline set of language versions.
- Ask, per language, whether any single country inside it diverges enough — currency, law, dialect, stock — to justify its own page. Split only those out into country versions (
esfor the shared page,es-mxandes-aronly where warranted). - Pick a URL structure once: subdirectory for language-led, authority-sharing sites; ccTLDs only if you have the resources and a strong per-country geo case.
- Validate demand with real per-country data. Keyword volume for the same term varies wildly between markets, and guessing wastes budget. SEO Rocket pulls real Ahrefs keyword data with a per-country selector, so you segment by the market you’re actually targeting instead of a global average, and it tracks rankings country by country so you can see each version compete on its own turf.
The whole exercise is a founder’s playbook proven across 1,000,000+ ranking pages, much of it in Southeast Asia — a genuinely multilingual region (English, Chinese, Malay, Tamil across neighbouring markets) where getting the language-versus-country call right is the difference between one page ranking everywhere and thirty pages ranking nowhere. Worth noting honestly: SEO Rocket is the SEO layer — the keyword research, the audit, the tracking — not a translation service. You still bring the localized copy; the platform makes sure the targeting signals around it are correct.
Frequently Asked Questions
What is the difference between language targeting and country targeting?
Language targeting serves content based on the language a person reads, regardless of where they live — one Spanish page for every Spanish speaker. Country targeting serves content based on geographic location, regardless of language — a Canada version for everyone in Canada. Hreflang encodes language alone (es) or language plus country (es-mx), so you can do either or combine both.
Can I use hreflang for a country without specifying a language?
No. Hreflang always requires a language code; the region code is optional and only valid when it follows a language. You can write en (language only) or en-gb (language plus country), but never a country on its own. And use the correct ISO codes — it’s en-gb, not the invalid en-uk.
Should I automatically redirect users to their language version?
Avoid it. Automatic redirects by IP or browser language can trap Googlebot — which crawls mostly from the US — on one version and stop it indexing the others. Suggest the likely version with a dismissible banner or a visible selector instead, and keep every version crawlable at its own stable URL.
