Most international problems are market problems wearing a technical costume
This is the least popular thing to say at the start of an international engagement, and it is true often enough that skipping it wastes budget.
A site launches in five countries. Three do nothing. The brief that arrives says the hreflang must be broken. Sometimes it is. More often the quiet markets have no brand recognition, no local demand for the product as positioned, a competitor set nobody surveyed, a price that is wrong once converted, or content machine-translated well enough to read and not well enough to be chosen.
None of that is fixed by an annotation in the <head>. So the diagnosis starts before the markup: what demand exists in each market at query level in the local language rather than translated from English, who satisfies it now, and whether the pages were written for that market or converted into it.
Where the market is not there, the honest recommendation is to stop paying for four locales and put the money into the one that works. Where the demand exists and the site is not being served correctly, it is a technical problem, and the rest of this page is about the specific ways that goes wrong.
hreflang: three methods, and how to pick one for your stack
hreflang tells Google that several versions of a page exist for different languages or regions, so it can serve the right one to the right searcher. Google documents three implementation methods and states directly that "the three methods are equivalent from Google's perspective and you can choose the method that's the most convenient for your site."
- HTML link elements in the
<head>:<link rel="alternate" hreflang="[lang_code]" href="url_of_page" />, with fully qualified URLs including the protocol. Simplest to inspect, heaviest on the page when there are many locales. - HTTP headers:
Link: <url1>; rel="alternate"; hreflang="[lang_code_1]", and so on. This is the method for non-HTML files such as PDFs, and it keeps large annotation sets out of the HTML entirely. - XML sitemap, using
<xhtml:link rel="alternate" hreflang="[code]">child elements inside each<url>entry with the xhtml namespace declared. Best where there are many locales or where the CMS cannot reliably write to the head of every template.
The choice is an engineering one: which system in your stack already knows the full set of equivalent URLs for a given page. If that is the sitemap generator, use the sitemap. If it is the CMS, use the head. What does not work is two of them disagreeing, which happens whenever a team adds a second method without removing the first.
The failure that reports no error at all
Google's documentation contains one sentence that explains more broken implementations than everything else combined: "If two pages don't both point to each other, the tags will be ignored."
Every version must reference itself and every other version in the set. Miss the return reference and the annotation is not partially applied or downgraded — it is discarded. Nothing reports this. There is no status code and no warning, so the site simply behaves as though hreflang were never implemented while the team looking at the head of the page can see the tags sitting there.
Where return tags go missing:
- A new locale is added and the existing locales are not updated to reference it. The new market is invisible while every older one looks correct.
- The self-reference is omitted because it looks redundant. It is not optional.
- Annotations are generated per template and one template — usually the blog, or the product detail page — was never included.
- URLs are not fully qualified, or use a different protocol or host variant than the canonical version.
- Annotations point at URLs that redirect, or at non-canonical versions.
The other one to watch: a site migration invalidates every annotation unless they are rewritten to the new URLs as part of the move. Reference: Google's documentation on localized versions.
The code errors Google names explicitly
Language codes are ISO 639-1. Region codes are ISO 3166-1 alpha-2. The format is language or language-REGION — en-GB, de-CH, pt-BR. Scripts, where genuinely needed, use ISO 15924, as in zh-Hans.
Google lists the common errors directly, and each is worth checking for by name: missing return links, which it lists first; incorrect language codes that do not follow ISO 639-1; a region code without a language code, which is invalid — hreflang="jp" does not exist, though it is written constantly because it reads as though it should; and non-standard codes such as EU or UN, which are not countries in this scheme, and UK, where the correct code for the United Kingdom is GB.
Then x-default, frequently omitted and frequently misunderstood. Google describes it as the reserved value "used when no other language/region matches the user's browser setting." It is what a language selector or global fallback page should carry. Without it, a searcher whose settings match none of your locales gets whichever version Google picks.
Canonicals that contradict the annotations
The second structural failure, after return tags, is a conflict between what rel="canonical" says and what hreflang says.
The two work together and Google is explicit that where locales duplicate content, you use rel="canonical" and hreflang in combination so that the correct language or regional URL is served. The rule that keeps them coherent: each locale's page should be canonical to itself, and reference the others through hreflang. A locale page that canonicalizes to a different locale is telling Google that page should not be indexed independently, which removes it from the set the annotations were describing.
The pattern this usually appears as: an English-language site launches en-GB and en-AU with substantially identical content, someone worries about duplicate content, and canonicalizes the Australian version to the British one. The en-AU pages then stop ranking in Australia, the hreflang set is inconsistent, and the diagnosis offered is usually that hreflang does not work.
Related conflicts worth auditing at the same time: noindex applied to a locale that is also referenced in the annotation set; annotations pointing at parameterized or session URLs; and cross-domain sets where one domain's canonicals were configured by a different team than the other's.
ccTLD, subdomain or subdirectory — Google's own trade-offs
This decision is expensive to reverse, which is why it deserves more thought than it usually gets. Google publishes the trade-offs and they are worth taking at face value.
Country-code top-level domains (example.de) give what Google calls clear geotargeting, make server location irrelevant, and separate sites cleanly. Against that: cost and limited availability, more infrastructure, strict registration requirements in some registries, and each one targets exactly one country. A ccTLD per market is a portfolio of separate sites, each starting with no inherited authority.
Subdomains (de.example.com) are easy to set up, allow different server locations, and separate cleanly. Google's stated drawback: users may not recognize the geotargeting from the URL alone.
Subdirectories (example.com/de/) are easy and low maintenance on a single host. Google's stated drawbacks: less clear geotargeting signals, one server location, harder separation later.
URL parameters get one phrase from Google: "not recommended." If you inherit this, the decision was made for you and it was the wrong one.
The practical read: most organizations should use subdirectories unless there is a specific reason not to, because it concentrates effort rather than splitting it across properties that each need their own everything. A ccTLD earns its cost where a market requires local legal presence, local trust signals, or genuinely separate operations. Reference: Google on managing multi-regional sites.
Declare, do not detect
Google's instruction on IP-based redirection is unusually direct: "Don't use IP analysis to adapt your content." Its reasoning is that IP location analysis is difficult and generally not reliable, and that its crawlers may not properly detect variations created that way.
The failure mode is specific and severe. Googlebot crawls predominantly from United States addresses, so a site that redirects visitors to a locale based on IP will redirect Googlebot to the United States locale on every request — and every other locale becomes effectively invisible, however correct its hreflang is. Teams then debug the annotations for weeks.
The alternative Google states as a principle is to "make sure you explicitly tell Google about any locale or language variation" through hreflang, ccTLDs or explicit links, rather than relying on automatic detection. In practice: give every locale a stable, crawlable URL; suggest an alternative with a dismissible banner rather than a forced redirect; let the visitor decide.
On Search Console country targeting, check Google's current help documentation for what your property type actually exposes before relying on any setting, because this area has changed and a blog post from a few years ago is not evidence of what exists today. The load-bearing signals are the URL structure and the annotations regardless.
How this is engaged, when you do not need it, and how it is judged
Fixed-scope project. Sometimes the whole engagement is a structure decision made before a build starts, which is the cheapest and highest-value version of this work by a distance. More often it is a diagnosis of an existing multi-locale site: the market read, the structure assessment, a defect list with evidence, and an implementation specification your developers can build from.
What drives the effort: how many locales exist, whether they sit on one platform or several, whether content is genuinely localized or translated, whether annotations are generated centrally or per template, and whether a replatform is in the picture. Translation and market-entry strategy are not included.
You do not need this if you sell in one country in one language, even if traffic arrives from elsewhere — traffic is not a market. You do not need it if you are entering exactly one new country and will run it as a subdirectory with correct annotations, which is a short specification rather than a project. And you do not need it if the content in the failing markets was machine-translated, because the technical layer is not what is losing you those searchers.
Judging it: impressions and clicks segmented by country per locale, against that locale's own baseline rather than the home market's. Indexed URL counts per locale, since a locale that is not indexed cannot be measured on anything else. And patience, since annotation changes have to be recrawled across every version in the set before the effect is visible anywhere.
Frequently Asked Questions
Should I use a ccTLD, a subdirectory or a subdomain for international sites?
Google publishes the trade-offs. ccTLDs give clear geotargeting and clean separation, but cost more, need more infrastructure, face registration restrictions, and each targets one country only. Subdomains are easy to set up and allow different server locations, though users may not recognize the targeting from the URL. Subdirectories are easy and low maintenance on one host, with less clear geotargeting signals and harder separation later. URL parameters are explicitly not recommended. Most organizations should use subdirectories, because it concentrates effort instead of splitting it across properties that each need everything built twice.Why is my hreflang not working?
Most often, missing return links. Google states that if two pages do not both point to each other, the tags will be ignored — not downgraded, ignored — and nothing reports the failure. Every version must reference itself and every other version. After that, check for a region code without a language code, which is invalid; UK instead of GB; annotations pointing at redirecting or non-canonical URLs; a locale page canonicalizing to a different locale; and whether a recent migration rewrote the URLs without rewriting the annotations that referenced them.Is hreflang a ranking factor?
It is better understood as a serving instruction than a ranking lever. Google describes it as the way to tell it that localized versions of a page exist so the right one can be served to the right searcher. It does not make a page rank where it otherwise would not. What it does is stop the wrong version being shown, which can look identical to a ranking gain from the inside — a market that was seeing the home-market page and now sees its own will convert better without anything having moved in position. Fixing hreflang solves a targeting problem, not a competitiveness one.Do I need to translate my site to rank in another country?
You need content that a searcher in that market would choose, which is not the same as translated content. Machine translation that reads acceptably and was never reviewed by someone who sells in that market is the most common cause of a launched locale that does nothing. Start before translation: find out what demand exists at query level in the local language rather than translated from English, who satisfies it now, and whether the offer makes sense there once the price is converted. If the answer is that the market is not there, no amount of localization changes it.Should I redirect visitors based on their IP address?
No. Google's instruction is explicit: do not use IP analysis to adapt your content, because IP location analysis is unreliable and its crawlers may not properly detect variations created that way. The practical danger is specific — Googlebot crawls largely from United States addresses, so an IP redirect sends it to that locale every time and can make every other locale effectively invisible. Give each locale a stable crawlable URL, suggest an alternative with a dismissible banner rather than a forced redirect, and let the visitor choose.How long does international SEO work take?
The diagnosis and specification typically run two to five weeks, driven by how many locales exist, whether they sit on one platform or several, and whether the annotations are generated centrally or template by template. Implementation runs on your release cycle. Then there is a wait that cannot be shortened: annotation changes have to be recrawled across every version in the set before the effect shows anywhere, and a set is only as good as its slowest-crawled member. Expect the measurement to be readable a good deal later than the code shipped.Do I need a full international project to launch in one new country?
Probably not. One new market added to an existing site is usually a short specification rather than a project: choose the structure — a subdirectory, in most cases — set the URL pattern, write the hreflang set including self-references and x-default, and make sure the existing locales are updated to reference the new one, which is the step that gets missed. Where it becomes a project is if the market research has not been done, or if adding the locale exposes that the current structure will not scale past two.Published