Hreflang Checker Guide: Make Sure Search Engines Find the Right Language Version
A multilingual site has a quiet problem: the same content exists in several languages, and search engines must decide which version to show each searcher. Without guidance, an English speaker may be sent to the German page, or the search engine may treat the versions as duplicates and show only one of them. Hreflang is the guidance system. It is a set of tags, one on each version of a page, announcing the other versions and the language and region each one serves. The Hreflang Checker reads a pasted set of those tags and checks them for the errors that break the system: missing return links, invalid language codes, and pages that claim versions that do not exist. It works on the tags you paste, not by crawling your live site, so it checks the declarations you intend to publish rather than the ones a crawler happens to find.
The core idea is reciprocity. If the English page declares a French version and a German version, then the French page must declare the English and German versions, and the German page must declare the English and French versions, and each page must also declare itself. That full mesh is what makes hreflang reliable: each page confirms the others, so the search engine can trust the cluster. A missing return link breaks the confirmation, and search engines may then ignore the whole cluster for that page. The second core idea is correct codes. Languages use two-letter codes such as en for English, fr for French, and de for German, with an optional region code such as en-US for American English or de-DE for German as used in Germany. A region code on its own, such as US without a language, is invalid, and a made-up language code is worse than none, because it claims a version that no searcher can be matched to.
What the checker looks for
The checker reads each tag's language code and target address, and tests several things. Are all codes valid and correctly formed? Does every page in the cluster point back to every other page? Does each page include a self-reference? Are the target addresses well formed and distinct, rather than two language codes pointing at the same address? Is there an x-default tag, the fallback version shown when no language matches, and does it point at a sensible page, such as a language selector or the most general version? The checker also catches the classic copy-paste errors: a tag pasted from another page that still points at the old page, a language code typed as uk when the intent was en-GB, since uk is actually the code for Ukrainian, and a region code in the wrong case or order. Each of these is a small typo with a large consequence, because one bad tag can cause a search engine to distrust the cluster.
Worked example
Take a sample cluster of three pages, with values clearly labelled as an illustration: an English page, a French page, and a German page. A correct cluster needs each page to declare 3 tags: itself plus the two others, so the cluster as a whole needs 3 times 3, which is 9 tags. Suppose the pasted set contains only 7 tags, because the German page declares itself and the English page but omits the French page. That is 2 missing return links in effect: the French page's claim about the German page is unreciprocated, and the German page's set is incomplete. The missing fraction is 2 out of 9, about 22 percent, since 2 divided by 9 is roughly 0.222, but the practical effect is larger than the fraction suggests, because the French-German pair is now unconfirmed in one direction. Add a second fault: the English page's French tag points at the German address by a copy-paste slip, so two language codes now claim the same address. The checker flags both faults, and the fix is mechanical: add the missing German-to-French tag, correct the French tag's address, and re-check until the set shows 9 tags, each page self-referencing, each pair reciprocated. That re-check matters, because fixing one tag often reveals another fault hidden behind it.
Mistakes to avoid
The first mistake is adding hreflang to only one page of a cluster and assuming the job is done; reciprocity is the whole system, and a one-sided declaration is routinely ignored. The second is confusing language and region codes, especially UK for English, which is a common error with a precise meaning elsewhere. The third is pointing hreflang at redirected or broken addresses, which makes the declaration point at a page that does not serve the claimed language. The fourth is using hreflang as a substitute for proper redirects or language detection: it guides search results, it does not redirect a visitor who arrives at the wrong version by another route. The fifth is pasting tags from a staging site, with staging addresses, into the checker and then publishing them unchanged, which announces staging pages to search engines. Always check the exact tags that will go live, with live addresses.
Putting it into practice
Treat hreflang as part of publishing a translated page, not as an afterthought. When a new language version goes live, update every page in the cluster in the same change, add the new version to each existing page, and run the checker on the full pasted set before deploying. Keep a simple list of your clusters, one row per page with its language code and address, so a missing tag is visible as an empty cell rather than an absence you have to notice. Re-check after site moves, domain changes, or template changes, all of which silently break hreflang. For related checks, the Canonical Tags Explained guide covers the neighbouring problem of duplicate pages, and the URL Encoder & Decoder helps when translated addresses contain special characters, and the Regex tester helps validate the code patterns in a pasted tag set. The companion guide on SEO Titles Meta Descriptions covers the page elements that work alongside hreflang to present the right version well.
Key points
- Hreflang tells search engines which language and region version of a page to show
- Every hreflang link must be reciprocated: if page A points to page B, page B must point back
- Language codes must be valid, and region codes must pair with a language, never stand alone
- A checker reads pasted tags, it does not crawl a live site or guarantee rankings
In short: hreflang is a mesh, not a label. Every page declares itself and every sibling, codes are valid language-first pairs, and the whole set is checked together before publishing. Do that, and each searcher is far more likely to land on the version written for them.