Most hreflang mistakes don’t announce themselves. There’s no penalty, no manual action, no red banner in Search Console — Google simply ignores the annotations it can’t trust and serves the wrong language version to the wrong country. Your German page outranks your German page’s replacement, your UK visitors land on the US pricing, and your carefully translated site cannibalizes itself in search. Because the failure is silent, teams often run broken hreflang for a year before anyone connects the traffic dip to a two-character typo. This guide walks the errors that actually cause that damage, and exactly how to fix each one.
Why Hreflang Mistakes Are So Easy to Make
Hreflang is deceptively simple in theory: tell Google which URL serves which language and region, and it shows the right one to the right searcher. In practice it is a graph problem. Every language version of a page must reference every other version, including itself, and every one of those references must point back. A ten-language site isn’t ten tags — it’s a hundred-plus interlocking annotations that all have to agree. One missing edge in that graph and Google discards the whole set for that page. That is why hreflang errors scale so badly and why they slip past manual spot-checks. The tags are also invisible to users, so nothing looks broken on the page itself.
Running SEO across Singapore and the wider ASEAN region — where a single business might serve English, Chinese, Malay, and Tamil audiences across half a dozen markets — I’ve seen these problems on sites that were otherwise technically clean. The common thread is always the same: the annotations were written once, by hand, and never validated against each other.
Mistake 1: Missing Return Links (Broken Reciprocity)
This is the single most common of all hreflang errors. Hreflang annotations must be reciprocal: if your English page points to your French page as an alternate, the French page must point back to the English one. Google’s rule is blunt — “if two pages don’t both point to each other, the tags will be ignored.” Not the broken tag alone; the entire annotation set for that URL.
The usual cause is a partial rollout — a team adds hreflang to the pages it translated this quarter and forgets the older versions, or a CMS template injects tags on new templates but not legacy ones. To fix it, treat the language cluster as an atomic unit: every URL in a translation group ships with the complete, matching set, or none of them do. When you audit, don’t check whether a page has hreflang — check whether every alternate it names returns the favor.
Mistake 2: Forgetting the Self-Referencing Tag
Every page in a language cluster must include an hreflang entry pointing to itself. So your English page’s tag block lists French, German — and English. Teams routinely list only the “other” languages, reasoning that a page doesn’t need to reference itself. Google disagrees: the self-reference is what confirms the page’s own language identity and anchors the reciprocal graph. Omit it and validation gets shaky, especially in XML sitemaps where the self-entry is how Google maps the annotation to a specific URL. If you fix only one thing after reading this, make it this and the return links above — together they account for the majority of hreflang problems in the wild.
Mistake 3: Wrong Language and Region Codes
The classic typo, and it fails silently. Hreflang accepts a language code in ISO 639-1 format, optionally followed by a region code in ISO 3166-1 Alpha-2 format — for example en, en-gb, es-mx, zh-cn. The specific traps:
- Using
en-ukfor the United Kingdom. The correct region code isen-gb. “UK” is not a valid ISO 3166-1 country code; “GB” is. Google discardsen-ukentirely. - Putting the region first. The format is language-then-region. You cannot specify a country on its own —
gbalone is invalid; it has to been-gb. - Inventing regions. Codes like
EU,UN, oren-euaren’t valid country codes. If you want to target Europe broadly, use a language-only value likeenplus anx-default, not a fake region. - Confusing language and locale.
zh-cnmeans Chinese as used in China; it is not interchangeable withzh-tw(Taiwan) orzh-hk(Hong Kong). For a Simplified-vs-Traditional Chinese split, the script matters to your users even when Google’s matching is loose.
The fix is validation against the actual ISO lists rather than intuition — the codes that “feel right” (uk, eu, en-us for a global page) are exactly the ones that break.
Mistake 4: No x-default for Unmatched Visitors
The x-default value tells Google which page to serve when no language or region in your set matches the searcher. A Portuguese speaker in Brazil hitting a site with only English, French, and German versions has no match — x-default decides where they go. Skipping it isn’t fatal, but it hands Google a guess for every unmatched visitor, and the guess is often your homepage in the wrong language. Point x-default at your global or language-selector page. It’s a single extra line and it closes the gap for the entire long tail of countries you didn’t explicitly target.
Mistake 5: Hreflang Fighting Your Canonical Tags
This is the subtlest and most destructive of the hreflang mistakes because two correct-looking systems contradict each other. Every language version must self-canonicalize — the French page’s canonical points to the French page. A frequent error is cross-language canonicalization: the French, German, and Spanish pages all set their canonical to the English URL, usually because a plugin treats English as the “original.” That tells Google the translations are duplicates of the English page and shouldn’t be indexed at all — which flatly contradicts the hreflang annotation asking Google to index and serve each one. Google resolves the conflict by trusting the canonical and dropping your translations from the index. Rule: hreflang and canonical must agree. Each localized URL canonicals to itself; hreflang handles the cross-language relationships.
Mistake 6: Relative URLs and Mixed Protocols
Hreflang requires fully-qualified, absolute URLs with the protocol included — https://example.com/fr/, never /fr/ or a protocol-relative //example.com/fr/. Relative paths are quietly ignored. Two adjacent versions of this: pointing hreflang at http:// URLs when the site has migrated to HTTPS, and pointing at pre-redirect URLs that now 301 elsewhere. Every hreflang target should be the final, canonical, 200-status HTTPS URL. If an alternate resolves to a redirect, a 404, or a noindexed page, the annotation is wasted and can invalidate the cluster. Crawl your alternates and confirm each returns a clean 200 before trusting the setup.
Mistake 7: Auto-Redirecting Users by IP or Language
Many international sites try to “help” by auto-redirecting visitors to a version based on IP geolocation or browser language. This creates one of the worst hreflang problems in practice, because Googlebot crawls predominantly from US IP addresses. If your site force-redirects every US IP to the American version, Googlebot may never see — and therefore never index — your other language versions, no matter how perfect the annotations are. You’ve built a beautiful hreflang graph and then blindfolded the crawler to most of it.
The durable fix is user choice, not forced redirection. Serve each URL at a stable address, let it be crawled on its own, and offer a dismissible banner or a country/language selector suggesting a better-matched version. Users get the nudge; Googlebot keeps its access to every variant.
Mistake 8: Mixing Implementation Methods and Conflicting Sets
Hreflang can be implemented three ways — HTML <link> tags in the head, an HTTP Link header (useful for non-HTML files like PDFs), or xhtml:link entries in an XML sitemap. Pick one. Teams sometimes ship two methods at once and, worse, let them disagree: the on-page tags say one thing, the sitemap says another, and Google sees a contradictory set it may discard. For large multilingual sites the XML sitemap method is usually the most maintainable, because the entire annotation graph lives in one place you can validate programmatically rather than scattered across thousands of page templates. Whichever you choose, make it the single source of truth and remove the others.
How to Find and Fix Hreflang Mistakes at Scale
You cannot eyeball a reciprocal graph across thousands of URLs and ten languages — the whole class of hreflang errors exists precisely because manual checking doesn’t scale. The reliable approach is a real crawler that fetches your pages, extracts every annotation, and verifies the graph: are return links present, do the codes validate against ISO lists, does each alternate return a 200, do canonicals agree with hreflang, is x-default set? This is exactly what SEO Rocket’s site audit does — it crawls the live site the way a search engine would and flags hreflang and cross-language duplication issues, so a missing return link surfaces as a specific finding instead of an unexplained ranking dip six months later.
Fixing the tags is only half the job. The other half is confirming the fix actually moved the right pages in the right markets. SEO Rocket tracks rankings per country and runs keyword research on real Ahrefs data with a market selector, so you can see your German page ranking in Germany rather than an averaged global number that hides the problem. It’s an SEO layer, not a translation service — it won’t localize your copy, but it will tell you whether your international setup is working market by market. That’s the same validation discipline behind a playbook proven across 1,000,000+ ranking pages: build the annotations correctly, then verify against the live crawler and per-country data instead of assuming.
Frequently Asked Questions
Do hreflang tags actually help rankings?
Not directly — hreflang doesn’t boost rankings on its own. It’s a targeting signal that tells Google which existing version to serve to which audience, and it helps prevent same-language pages from competing with each other. The ranking benefit is indirect: the right page reaches the right searcher, bounce rates improve, and you stop cannibalizing your own results across countries.
How do I check if my hreflang is set up correctly?
Crawl the site with a tool that validates the full reciprocal graph, not a single page. Check four things per cluster: every alternate has a matching return link, all codes are valid ISO 639-1 language plus ISO 3166-1 Alpha-2 region, canonicals point to self rather than across languages, and every target returns a clean 200 over HTTPS. A real-crawler site audit like SEO Rocket’s reports these as discrete findings.
What’s the difference between hreflang errors and canonical errors?
Hreflang errors — missing return links, bad codes, no x-default — cause Google to ignore your targeting and possibly serve the wrong version. Canonical errors, specifically cross-language canonicalization, are worse: they tell Google your translations are duplicates and shouldn’t be indexed at all, dropping them from search entirely. When the two conflict, canonical wins, so fixing canonicals is often the higher-priority repair.
