International SEO and hreflang without breaking your site

TL;DR: Hreflang tells Google which URL to show a visitor based on their language and region, and it fails silently more often than any other technical SEO signal: Ahrefs found errors in 67% of hreflang implementations across 374,756 domains it audited. The five failures that cause almost all of it are missing return tags, wrong language or region codes, hreflang pointing at a URL your canonical tag disagrees with, a missing or misused x-default, and mixing implementation methods on the same site. Fix those five and you fix the vast majority of international SEO problems.

---

Table of contents

1. What hreflang actually does
2. Why most hreflang implementations are broken
3. Mistake 1: missing return tags
4. Mistake 2: wrong language or region codes
5. Mistake 3: hreflang and canonical disagreeing
6. Mistake 4: x-default missing or misused
7. Mistake 5: mixing implementation methods
8. Choosing your URL structure
9. HTML tags vs HTTP headers vs XML sitemap
10. A diagnosis workflow you can run this week
11. Validating hreflang after you fix it
12. What practitioners actually get wrong
13. International SEO is more than hreflang
14. Frequently asked questions
15. Key takeaways

What hreflang actually does

Hreflang is an annotation, not a redirect and not a ranking factor. It tells Google which version of a page to show a searcher based on the language and, optionally, the region their query signals. Google’s own documentation on localized versions states it plainly: “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” Hreflang exists to stop Google from treating your /en/, /de/, and /fr/ pages as duplicate content competing against each other, and to route French searchers to the French URL instead of the English one that happens to outrank it.

It does not help you rank higher in any given market. It does not pass authority between language versions. It does not fix thin or duplicate content, and a broken hreflang setup does not usually cause a manual penalty. What it does is control which URL appears in results for a given language and location, and when it is wrong, you can watch the wrong country’s page rank in the wrong country’s search results for months without an obvious error message anywhere in Search Console.

The syntax itself is short. On an HTML page it looks like this:

<link rel="alternate" hreflang="en-US" href="https://example.com/us/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Google also supports the same signal in an HTTP header for non-HTML files such as PDFs, and inside an XML sitemap using xhtml:link elements. All three are functionally equivalent. The complexity is not in the syntax. It is in getting the relationships between every URL correct, at scale, and keeping them correct as pages get added, renamed, and removed.

Why most hreflang implementations are broken

Ahrefs audited hreflang across 374,756 domains and found that 67% had at least one implementation issue, in a study published by Joshua Hardwick, Ahrefs’ Head of Content, and Patrick Stox, updated March 8, 2025. That is not a fringe failure rate on a niche feature. It is the majority outcome for a signal that most multi-market sites rely on to route traffic correctly.

Google’s own John Mueller has called hreflang “one of the most complex aspects of SEO” because, in his words, it “gets really hard quickly” as reported by Ahrefs. The reason it gets hard is structural, not conceptual. A site with 5 languages and 200 translated pages needs roughly 1,000 correctly reciprocated tag relationships. Miss one return tag on one page and Google ignores that entire pair, silently, with no warning in Search Console beyond a report most teams never check.

Google removed the standalone International Targeting report from Search Console in 2022, which used to flag hreflang errors directly. Hreflang issues now surface indirectly, through Page Indexing coverage anomalies or through manual URL Inspection checks, which is a large part of why so many broken implementations go unnoticed for years. You are not going to get a push notification. You have to go looking.

Mistake 1: missing return tags

This is the single most common failure, and Google states the rule without ambiguity in its localized versions documentation: “If two pages don’t both point to each other, the tags will be ignored.” Reciprocal linking is not a best practice here. It is a requirement. Every language variant must list itself and every other variant, including itself, in a full loop.

Picture three pages: /us/, /uk/, and /de/. Each one needs three hreflang tags: one pointing to itself, one to each of the other two. If /de/ forgets to include a tag pointing back to /uk/, Google discards the en-GB to de-DE relationship entirely, even though /uk/ still correctly points at /de/. The failure is invisible from one side and only shows up when you check both directions.

This scales badly. A 10-language site needs each page to carry 10 hreflang tags (nine alternates plus a self-reference). Add or remove one language and every single page across every other language needs updating, or the whole cluster breaks. Manual maintenance does not survive this at scale, which is why CMS-level template logic or a sitemap-driven approach, generated programmatically, is the only reliable long-term fix. If you are running a programmatic SEO setup across markets, this is exactly the kind of template logic that needs to live in the generation layer, not in per-page manual edits.

Mistake 2: wrong language or region codes

Hreflang codes follow a specific format: an ISO 639-1 language code, optionally followed by a hyphen and an ISO 3166-1 Alpha-2 region code. en-GB is valid. en-UK is not, because UK is not a valid ISO 3166-1 country code (GB is). Google’s documentation is direct on the underlying logic: “You can’t specify the country code by itself. The first code stands for the language and Google doesn’t automatically derive the language from a country code.” A tag with only US in it does nothing.

Region codes are a second source of quiet failures. Google flags codes like EU, UN, and UK as having no effect because they are not valid ISO 3166-1 codes, even though they look reasonable to a human reading them. Conductor's hreflang guide, published by Steven van Vessum, VP of Organic Marketing, collects two real-world examples of this from working practitioners. Kevin Indig, a growth advisor who has led SEO at Shopify and G2, points to teams “not following Google’s guidelines to a T and forgetting to self-reference.” David Iwanow, Head of Search at Reckitt, names a specific gotcha most people never catch: “check the hreflang language codes as be stands for Belarusian rather than Belgian.” If your team meant “Belgium” and typed be expecting a country code, Google reads it as the language code for Belarusian and the tag routes nobody correctly.

There is no fuzzy matching. A single wrong character in a code that looks almost right, zh-CN typed as zh-cn is technically fine since hreflang is case-insensitive, but zh-CH is not zh-CN and will silently target the wrong thing or nothing at all. Validate every code against the ISO lists directly rather than trusting memory or a template someone copied from another project years ago.

Mistake 3: hreflang and canonical disagreeing

This is the mistake that causes the most damage because it is invisible until you specifically go looking for it, and it directly determines which URL Google indexes. Google’s guidance on consolidating duplicate URLs states the rule: “If you’re using hreflang elements, make sure to specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn’t exist for the same language.”

In practice this means your /de-de/ page’s canonical tag must point to itself, or to another German-language URL, never back to the English original. Sites that build hreflang late, after the canonical tags were already set for a single-language site, frequently ship every localized page with rel="canonical" still pointing at the English source. Hreflang tells Google “these are different language versions.” Canonical tells Google “these are the same page, index this one instead.” Set both to contradictory instructions and Google has to guess, and it usually resolves the conflict by indexing only the canonical target and dropping the rest.

There is a second, subtler version of this rule that most guides skip. Google explicitly prioritizes URLs inside hreflang clusters for canonicalization: “if https://example.com/de-de/cats and https://example.com/de-ch/cats reciprocally point to each other with hreflang annotations, but not to https://example.com/de-at/cats, the pages for de-de and de-ch will be preferred as canonicals.” A page left out of the hreflang loop is treated as a weaker candidate for its own canonicalization, even if nothing else about it is wrong. The fix reinforces mistake 1: complete, reciprocated hreflang clusters are not optional hygiene, they directly influence which of your own pages Google keeps indexed.

Google also warns generally against sending mixed canonical signals across methods: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques (for example, don’t specify one URL in a sitemap, but a different URL for that same page using rel=‘canonical’).” Run a crawl that checks canonical and hreflang target agreement on every URL before you assume the setup is clean; this is one of the checks that belongs in any technical AI visibility audit alongside crawlability and indexability checks.

Mistake 4: x-default missing or misused

x-default is a reserved hreflang value, and Google’s documentation is specific about its purpose: “The reserved x-default value is used when no other language/region matches the user’s browser setting. This value is recommended for specifying the fallback page for users whose language settings don’t match any of your site’s localized versions.” It is not a generic catch-all for your homepage, and it is not required. It is a specific fallback for the case where a visitor’s locale matches none of your defined variants.

Two failure patterns show up repeatedly. The first is simply omitting it, which leaves Google to guess which page to show a visitor from, say, Portugal on a site that only has en-US, en-GB, and fr-FR variants. The second, more damaging pattern is pointing x-default at a page that also carries a specific language tag, creating a self-contradiction where the same URL claims to be both “the fallback for everyone” and “specifically for French speakers.” Conductor’s guide, citing SEO consultant Barry Adams, frames the broader risk correctly: “hreflang tags are strong hints and not directives. Google is known to ignore hreflang tags if they believe the implementation is incorrect.” A confused x-default signal is exactly the kind of internal contradiction that gets an entire cluster discounted rather than partially honored.

The practical fix, per Google’s own example, is a dedicated x-default target, often a language selector page or a geo-detected homepage, that is not simultaneously tagged as a specific-language alternate for any other URL in the cluster.

Mistake 5: mixing implementation methods

Google supports three equivalent implementation methods and explicitly frames them as alternatives, not layers to stack. Mixing them on the same site, HTML tags on some templates, sitemap entries for others, is a common byproduct of CMS migrations, where a legacy sitemap-based hreflang feed keeps running after a new template starts emitting HTML tags. The two systems drift apart the moment either one gets updated without the other, and you end up with contradictory signals for the same URL depending on which crawl path Google takes.

Pick one method per site and standardize on it. If you run a large multilingual catalog on WordPress, Ghost, or Shopify, check whether your platform or plugin generates hreflang via HTML tags or sitemap by default, and disable whichever legacy or plugin-generated feed would otherwise run in parallel.

Choosing your URL structure

Hreflang works with any URL structure, but the structure you pick changes your operating cost, your ability to geotarget, and how visible the targeting is to a human visitor. Google’s guidance on managing multi-regional sites lays out four structures and their tradeoffs directly.

Structure	Example	Geotargeting clarity	Setup cost	Google’s stated tradeoff
✓ ccTLD	example.de	Clear to users and Google	High (new domain, hosting, legal entity in some markets)	“Can only target a single country” per domain
✓ Subdirectory	example.com/de/	Unclear to users, clear to Google via hreflang	Low, shared infrastructure	”Low maintenance (same host)”; single server location
✓ Subdomain	de.example.com	Unclear to users without inspection	Medium	Easy separation, but “users might not recognize geotargeting from the URL alone”
✗ URL parameters	example.com?loc=de	Weakest	Lowest	Google does not recommend this approach for meaningful segmentation

Google’s specific reasoning against IP-based content switching without explicit URL signals matters here too: “Don’t use IP analysis to adapt your content…Google may not be able to crawl variations of your site properly.” Any structure you choose has to remain crawlable and linkable, with a distinct, requestable URL per language and region, or hreflang has nothing to point at. IP or cookie-based redirects that block Googlebot from reaching alternate versions directly are one of the fastest ways to make an otherwise correct hreflang implementation useless.

For most sites without the budget or legal need for country-specific entities, subdirectories are the pragmatic default: lowest infrastructure cost, and hreflang plus a visible language switcher covers the clarity gap that a bare subdirectory URL leaves for human visitors.

HTML tags vs HTTP headers vs XML sitemap

All three methods carry identical weight to Google. The right choice depends on your content type and how much control you have over templates versus a centralized feed.

Method	Best for	✓ Advantage	✗ Limitation
HTML <link> tags	Standard web pages	Lives with the content, easy to audit per page	Bloats <head> on large hreflang clusters (10+ languages)
HTTP headers	Non-HTML files (PDFs, downloadable docs)	Only method that works for non-HTML content	Requires server-level configuration access
XML sitemap xhtml:link	Large sites with many URLs	Centralizes all relationships in one file, easier to generate programmatically	Requires the sitemap stays in sync with live URLs; errors are less visible per page

Large multilingual catalogs, e-commerce especially, tend to move to sitemap-based hreflang once the HTML-tag approach becomes unmanageable across thousands of SKUs in a dozen languages. It is easier to generate and validate one structured XML file programmatically than to guarantee every template render includes the correct, complete, reciprocated tag set. Whichever you pick, do not run more than one simultaneously.

A diagnosis workflow you can run this week

Most hreflang problems are found reactively, when someone notices the wrong country’s page ranking somewhere it shouldn’t. A scheduled check catches it before it costs you a quarter of visibility in a market. Here is the order that surfaces the five mistakes above fastest.

flowchart TD
    A[Start: crawl all language URLs] --> B{Every hreflang tag<br/>has a reciprocal return tag?}
    B -- No --> B1[Fix Mistake 1: add missing<br/>return links, full loop]
    B -- Yes --> C{All language and region<br/>codes valid ISO codes?}
    C -- No --> C1[Fix Mistake 2: correct codes<br/>against ISO 639-1 / 3166-1]
    C -- Yes --> D{Canonical tag matches<br/>hreflang target language?}
    D -- No --> D1[Fix Mistake 3: align canonical<br/>with the correct language URL]
    D -- Yes --> E{x-default present and<br/>not double-tagged?}
    E -- No --> E1[Fix Mistake 4: set one clean<br/>x-default fallback page]
    E -- Yes --> F{Only one implementation<br/>method in use?}
    F -- No --> F1[Fix Mistake 5: pick one method,<br/>retire the other]
    F -- Yes --> G[Validate in URL Inspection<br/>and re-crawl in 2 weeks]
    B1 --> G
    C1 --> G
    D1 --> G
    E1 --> G
    F1 --> G

Run this as an actual crawl, not a spot check on three URLs. A crawler that reads hreflang, such as Screaming Frog or Sitebulb, will surface the reciprocal-tag and code-validity issues automatically across the full site in one pass. The canonical-alignment check and the x-default check need a manual cross-reference on a sample, since crawlers report the raw tags but do not always flag semantic conflicts between a canonical and an hreflang target on the same URL.

Validating hreflang after you fix it

Google Search Console’s URL Inspection tool shows the hreflang cluster Google actually recognizes for a specific URL, which is the closest thing to ground truth you get. Check a sample of URLs per language after any fix, not just the ones you edited, since a single broken return tag anywhere in the cluster invalidates the whole set for every page in it.

Beyond Search Console, three checks catch what automated tools miss:

• Manually view source on the live rendered page (not just the CMS template) to confirm the tags actually output correctly, since a templating bug can look correct in the CMS editor and break on render.
• Confirm the hreflang target URLs return a 200 status, not a redirect chain or a 404. A hreflang tag pointing at a URL that redirects elsewhere is treated inconsistently and should point directly at the final URL.
• Re-crawl on a schedule, not once. New pages published without the correct template inheriting hreflang logic are the most common source of regressions after an initial cleanup, and this is exactly the kind of drift that shows up in Search Console query and page data as a market’s visibility declining for no obvious reason months later.

What practitioners actually get wrong

Beyond the five structural mistakes, the pattern that shows up across practitioner commentary is treating hreflang as a one-time setup task instead of an ongoing content-operations requirement. Kevin Indig’s point about self-referencing generalizes: teams build the cluster correctly at launch, then a content team adds a new market six months later without looping in whoever owns the hreflang template logic, and the new URLs never get added to the existing pages’ tag sets.

Barry Adams’ framing that hreflang is “strong hints and not directives” that Google will discard on suspected error is the reason silent failure is the default failure mode here, rather than a hard error message. There is no dashboard alert. The signal just stops being honored, and your only symptom is a market’s organic traffic or ranking behaving oddly in a way that takes a deliberate audit to trace back to hreflang specifically.

Building this into a recurring check, not a launch-day checklist item, is the actual fix. Whoever owns technical SEO health checks on a multi-market site should have hreflang cluster validation on the same cadence as broken-link and indexation checks, because it degrades the same way: quietly, and only visible to someone specifically looking.

International SEO is more than hreflang

Hreflang routes an existing translated page to the right audience. It does nothing for content that was machine-translated without a quality pass, and Google’s own guidance that “localized versions of a page are only considered duplicates if the main content of the page remains untranslated” cuts both ways: content that reads as untranslated, thin, or auto-generated to a native speaker in that market does not earn a pass just because the hreflang tags are technically correct.

If you are weighing how much translation quality actually matters for ranking versus getting filtered as low-value content, that tradeoff by market is a separate decision from anything covered here; see multilingual content and AI translation quality thresholds for what changes the outcome. Structure and content quality are two different failure points, and fixing one does not fix the other. A site with flawless hreflang and machine-translated product descriptions will still underperform in that market, and a site with excellent native-language content and broken hreflang will route the wrong page to the wrong searchers regardless of how good the content is.

Teams running this at founder-level bandwidth with no dedicated international SEO hire tend to underinvest in the ongoing audit cadence specifically because nothing about a broken hreflang setup looks urgent from the outside. It looks like flat or declining traffic in one market, which gets attributed to competition or seasonality long before anyone checks the tags.

Frequently asked questions

What is hreflang and what does it do?

Hreflang is an HTML, HTTP header, or XML sitemap annotation that tells Google which URL to serve a visitor based on their language and region. It prevents Google from treating your translated pages as duplicate content and routes searchers to the correct language version. It is not a ranking factor and does not pass authority between pages; it only controls which URL appears for a given locale.

Does hreflang improve rankings?

No. Hreflang controls which of your pages Google shows to a given language and region, not how well any page ranks. A page with perfect hreflang but thin or poorly translated content will still rank poorly. Ranking depends on content quality, relevance, and authority signals separate from hreflang, which is purely a routing and duplicate-content signal.

Why does Google ignore my hreflang tags?

The most common reason is a missing return tag: Google states directly that “if two pages don’t both point to each other, the tags will be ignored.” Other causes include invalid language or region codes, a canonical tag pointing at a different language’s URL, or Google suspecting the implementation is wrong and discarding the whole cluster as a low-confidence hint.

What is x-default hreflang and when do I need it?

x-default is a reserved hreflang value marking the fallback page for visitors whose language settings match none of your defined alternates. Google recommends it but does not require it. Use it for a language selector page or geo-detected homepage, never for a URL that is also tagged as a specific-language alternate, which creates a contradictory signal.

Do I need hreflang if I only have one language but multiple countries?

Yes, if content differs by region, for example US and UK pricing or spelling variants under en-US and en-GB. Hreflang works on region alone when the region code is appended to the same language code. If content is identical across regions, a single page without region-specific hreflang variants is usually simpler and avoids duplicate-content routing complexity for no benefit.

Can I use hreflang without separate URLs per language?

No. Hreflang requires a distinct, crawlable URL for each language or region variant. It cannot annotate content that switches by cookie, browser detection, or IP address on a single URL, because Google needs a specific URL to point to and index for each variant. Dynamic content switching without distinct URLs is invisible to hreflang entirely.

What are valid hreflang language and region codes?

Language codes follow ISO 639-1 (two letters, lowercase by convention: en, de, fr). Region codes follow ISO 3166-1 Alpha-2 (US, GB, DE). Combine them as language-REGION, such as en-GB. Codes like EU, UN, and UK are not valid ISO 3166-1 codes and Google states they have no effect even though they look correct to a human reader.

Should hreflang match the canonical tag?

Yes, and mismatches are one of the most damaging hreflang errors because they directly affect indexing. Google’s guidance requires that “if you’re using hreflang elements, make sure to specify a canonical page in the same language.” A German page with a canonical pointing to the English original tells Google to index the English version instead, defeating the hreflang setup entirely.

What is the best URL structure for international SEO: ccTLD, subdomain, or subdirectory?

There is no universal best structure; Google supports all of them equally with hreflang. ccTLDs (example.de) give the clearest geotargeting but the highest cost and can only target one country each. Subdirectories (example.com/de/) are lowest-maintenance and share infrastructure but give less visible geotargeting to users. Most sites without a legal or budget need for country-specific domains use subdirectories.

Why did my traffic drop in one country after a site migration?

A migration frequently breaks hreflang without anyone noticing, because URLs change but the hreflang tag set is not regenerated to match. Check whether the affected country’s hreflang targets still resolve to 200 status pages, whether return tags survived the migration, and whether canonical tags still align with the correct language URL for that market.

Can hreflang point to a redirect instead of the final URL?

Hreflang should point directly to the final, live URL, not to a URL that redirects elsewhere. Pointing at a redirect creates an inconsistent signal that Google may not resolve reliably, and it adds an unnecessary crawl hop. Update hreflang tags to the destination URL whenever the target page’s URL changes permanently.

How many hreflang tags does each page need?

Each page needs one tag per language and region variant in the cluster, including a self-referencing tag pointing to itself, plus an optional x-default. A cluster of 10 language variants means each of the 10 pages carries 10 hreflang tags: nine alternates and one self-reference. Missing the self-reference is one of the most frequently cited mistakes by practitioners auditing large sites.

Does hreflang work for PDFs and non-HTML files?

Yes, but not through HTML <link> tags since PDFs have no HTML head. Use the HTTP header method instead, which Google’s documentation specifically identifies as the method for non-HTML files. This requires server-level configuration to add the Link header with the same rel="alternate" hreflang="..." syntax used in HTML.

Should I use HTML tags, HTTP headers, or an XML sitemap for hreflang?

All three carry equal weight with Google, so pick one based on your content type and scale. HTML tags work well for standard pages on smaller sites. HTTP headers are required for non-HTML files. XML sitemaps centralize hreflang for large multilingual catalogs where generating consistent per-page HTML tags is harder to maintain. Never run two methods simultaneously on the same URLs.

How do I check if my hreflang is actually working?

Use Google Search Console’s URL Inspection tool to see the hreflang cluster Google recognizes for a specific URL, which reflects what Google actually processed rather than what your template outputs. Cross-reference with a crawler like Screaming Frog or Sitebulb to check reciprocal tags and code validity across the full site, and manually view-source a sample of live pages to confirm rendering matches the template’s intent.

Is hreflang a ranking factor?

No. Hreflang is a routing and duplicate-content signal, not a ranking signal. Google confirms it only affects which URL is shown for a given language and region, not how well that URL ranks against competitors. Content quality, relevance, backlinks, and other standard ranking factors operate independently of whether hreflang is implemented correctly.

What happens if I don’t implement hreflang at all on a multilingual site?

Without hreflang, Google decides independently which language version to show a searcher, often based on content similarity and server location signals, and it can serve the wrong-language page or treat near-identical translated pages as duplicate content competing against each other. Sites with distinct, well-differentiated content per language sometimes perform adequately without hreflang, but routing accuracy suffers, especially across regions sharing a language.

Can hreflang cause a Google penalty?

No, hreflang errors do not trigger manual penalties. They cause silent routing and indexing problems, such as the wrong page ranking in the wrong market or a valid page failing to get indexed as the canonical for its cluster, but Google does not classify hreflang mistakes as a violation requiring manual action. The damage is lost visibility, not a penalty flag.

Do subdomains need separate hreflang setups from the main domain?

Subdomains need hreflang tags exactly like any other URL structure, pointing to and from URLs on other subdomains or subdirectories in the cluster. Hreflang works across subdomains, subdirectories, and even separate ccTLD domains interchangeably, since the annotation only cares about the URL relationships declared, not where those URLs live.

How often should I re-audit hreflang on a live site?

Treat it as a recurring check, not a launch-day task. New pages published without inheriting the correct template hreflang logic are the most common source of regressions, so a monthly or quarterly crawl-based audit, aligned with broader technical SEO health checks, catches drift before it costs a market meaningful visibility.

Key takeaways

• Hreflang routes visitors to the correct language and region version of a page. It is not a ranking factor and does not pass authority between pages.
• 67% of hreflang implementations Ahrefs audited across 374,756 domains had at least one error, and most of it comes down to five fixable mistakes.
• Missing return tags are the single most common failure: every language version must reciprocally reference itself and every other variant, or Google discards the whole relationship.
• Canonical tags must agree with hreflang targets in the same language. A mismatch tells Google to index a different URL than the one hreflang is trying to route to.
• x-default is a specific fallback for unmatched locales, not a generic tag for your homepage, and it should never double as a language-specific alternate.
• Pick one implementation method (HTML tags, HTTP headers, or XML sitemap) and standardize on it across the whole site.
• URL structure (ccTLD, subdomain, subdirectory) does not change whether hreflang works, only your operating cost and how visible geotargeting is to human visitors.
• Audit hreflang on a recurring schedule with a full-site crawl, not a one-time launch check, since new pages regularly ship without inheriting the correct tag logic.

Run the diagnosis workflow in this guide against your own site this week. If you find a broken cluster, fix the return tags and canonical alignment first; those two changes resolve the majority of routing problems in Ahrefs’ own error data.