hreflang annotation - a declaration in the head section, in an HTTP header or in the XML sitemap that tells search engines which language and country version is meant for which audience. It is one of the few SEO signals that breaks entirely invisibly: no status code changes, no page gets slower, no visitor sees an error message. Only weeks later does someone notice that the Austrian version ranks in Germany, that the English page appears for French queries, or that one locale has dropped out of the index. Technical SEO monitoring today covers the sitemap, robots.txt, structured data, redirect chains and noindex - multilingual setups are frequently the gap. This article shows which hreflang errors occur in practice, why a one-off audit does not keep them out for long, and how every language version can be checked together in continuous SEO monitoring.Why hreflang breaks without anyone noticing
hreflang is not part of the delivery itself but an additional statement about the delivery. The server answers with status 200, the content is complete, the load time is fine - and the annotation can still be wrong. It points to a URL that has not existed since the last relaunch. It names a region code the standard does not know. It is missing on precisely the one page that is needed as a counterpart. None of these deviations triggers an alert in classic availability monitoring, because the page under test remains reachable. Anyone watching only the status code of the home page sees nothing of this problem.
On top of that comes the sheer size of the problem. The annotation is reciprocal: every language version has to name itself and additionally list all sibling versions (Google Search Central). With five locales that means five entries per page and 25 entries per page group; with ten locales it is already 100. A website with 2,000 URLs per language and five languages therefore carries 50,000 individual references that all have to match up. That volume cannot be checked by eye, and it shifts with every deploy, every deleted page and every new redirect. This is exactly why multilingual setups are not a checklist item but a case for a recurring comparison.
There is an organisational effect as well. In many teams the editorial side owns the content per market, while engineering owns the template that generates the head section. A gap sits between those two responsibilities. Editors look at the finished page and judge text and imagery, not the source code. Engineering looks at the source code but rarely knows the market mapping in detail. When a relation drops out, neither side has a reason to go looking for it.
Search engines treat the annotation as a signal, not as a command (Google Search Central). It helps to surface the fitting language version in the results, but it does not force it. Two things follow from that: correct annotation is no substitute for genuinely localised content per market - and an error in the annotation is not reported as an error, it merely causes the signal to be discarded in silence. That is why the break stays unnoticed for so long: there is no error message, only an unacknowledged dismissal.
How the annotation is put together
An hreflang entry consists of two parts: the language tag and the target URL. The language tag follows the syntax defined in BCP 47 (RFC 5646) - a two-letter language code from ISO 639-1, optionally extended by a region code from ISO 3166-1 alpha-2 (Google Search Central). So de means German irrespective of country, de-AT means German in Austria. A region code on its own is invalid: AT without a preceding language code is discarded (Google Search Central). ISO 3166-1 alpha-2 currently lists 249 officially assigned country codes (ISO) - plenty of room for typos that look unremarkable on the page. The target URL has to be fully qualified, meaning it includes protocol and host name (Google Search Central); relative paths have no effect.
A common case is en-UK for the United Kingdom. The country code there is GB; UK is not assigned as a regular country code in ISO 3166-1 alpha-2 (ISO). The entry reads plausibly, does not match the standard and is therefore passed over. Related cases are those where a language code is confused with a country code - cz instead of cs for Czech, or jp instead of ja for Japanese. Such mix-ups typically arise where language tags are derived from a country list in the content system rather than from a language list.
| Annotation method | Suited to | Typical weak point |
|---|---|---|
| Link elements in the HTML head | manageable page counts, direct control per template | grows with every language and quietly falls away when templates are rebuilt |
| HTTP header of type Link | files without an HTML head, such as PDF documents | invisible in the browser, frequently lost during server moves |
| XML sitemap with xhtml:link | large page inventories, central maintenance in one place | sitemap ceiling of 50,000 URLs and 50 MB per file (sitemaps.org) |
All three methods are valid, but they should not be mixed on the same page: Google recommends settling on one method, because contradictory statements from head section and sitemap make interpretation harder (Google Search Central). In practice this contradiction arises during a switch. A team moves to the sitemap variant but does not remove the old link elements on every page type - and what remains is a state in which two sources make different claims. If you already monitor the XML sitemap, include the hreflang part in the same check rather than treating it separately.
Seven failure patterns that cost visibility
The following patterns turn up regularly when multilingual sites are examined. They differ in their cause but not in their effect: the signal is discarded, and the search engine decides without it which version to show in which market.
- Missing return link. If page A points to page B, page B has to point back to page A (Google Search Central). Without that return link the pair goes unconsidered. The error typically appears when a locale is added later and the existing templates are not brought along.
- Target answers with 404 or a redirect. An hreflang target should answer with status 200 directly. If the entry points to a deleted page or to a redirect, the relation is lost. Chains of several hops make it worse - how they come about and how to keep them short is covered in the article on redirect chains.
- Conflict between hreflang and canonical. Every language version should declare itself as the canonical version (Google Search Central). If the German page points its canonical at the English one, it cancels out its own hreflang entry: it declares itself a duplicate and drops out of the index.
- Wrong or invented region code.
en-UKinstead ofen-GB, a German country code for a Swiss version, a mainland Chinese code for a Taiwanese offering - such entries read plausibly and are discarded anyway, because the code does not match the standard (ISO). - x-default is missing. For visitors whose language or region matches none of the available versions, the value
x-defaultis provided (Google Search Central). Without that entry the search engine decides for itself which version to show in ambiguous cases - frequently the strongest one, not the most fitting one. - Automatic language redirection. If the server redirects visitors based on presumed language or IP address, the same rule catches crawlers. Google explicitly advises against automatic redirection based on the presumed user language (Google Search Central), because it can cut off access to the remaining versions.
- Country versions that push each other out. With very similar versions - a German and an Austrian page with largely identical text, say - the search engine may treat them as duplicates once the annotation breaks. Then one version ranks in both markets and the second disappears from the results.
Of all hreflang errors, the missing return link is the least conspicuous, because it is not visible on the page under test at all: there the entry sits complete and formally correct. The fault lies on the other side. A check that looks at a single URL will not find it, in our experience - only comparing all named targets against each other exposes it. That is why a dependable hreflang check has to fetch the entire language group, not just the entry page.
When the wrong locale ranks
The most common symptom of an hreflang break is not an error but a shift. Traffic stays stable in total yet distributes differently: the Austrian version suddenly collects German visitors, the British page appears for queries from the United States, the Dutch version loses visibility to the English one. In the reporting view that looks like a marketing topic; in fact there is a technical cause behind it. Anyone running campaigns per market should also watch out for clean campaign tagging, so the shift is not wrongly attributed to a paid channel.
Commercially the damage is more concrete than raw visit numbers suggest. Someone searching in Germany who lands on a version with a different currency, different delivery times, different payment methods or different legal texts bounces more often and buys less often. For providers with European business that matters: the European Union has 27 member states and 24 official languages (European Union), and a good half of German goods exports most recently went to EU member states (German Federal Statistical Office). Every one of those audiences expects the version tailored to it - and finds it only if the annotation is right.
What makes it harder is that the effect is difficult to trace back to a cause once it has taken hold. Rankings do not shift on the day of the deploy but over weeks, while the search engine re-evaluates the changed signals. Anyone who starts looking only then has several releases sitting between cause and effect. Monitoring that versions the head section per locale shortens that distance to a single day.
When visibility wanders between country versions, it is worth looking into the head section before rewriting content. Check in this order: does every version name itself? Do all named targets point back? Does every target answer directly with status 200? Does the canonical of each version point at itself? Four questions that can be answered by machine - and in this order they settle the majority of cases before content is even discussed.
Automatic language redirection: convenient, risky, partly unlawful
Many international websites redirect visitors automatically: by browser language, by IP address, or by a combination of both. From a product perspective that feels helpful. For discoverability it is risky, because a crawler receives the same treatment as a visitor. If a crawler with a US-based source address reaches the German version and gets redirected to the US path, it does not see the German version - and can therefore neither capture its content nor confirm the hreflang relation. Google therefore advises against automatic redirection based on the presumed user language (Google Search Central).
There is also a legal boundary that is rarely considered in an SEO context. Article 3 of the Geo-blocking Regulation forbids traders from automatically redirecting customers to a different country version of the online interface without their explicit consent (Geo-blocking Regulation). If a redirect does happen, the originally requested version has to remain easily accessible (Geo-blocking Regulation). The regulation has applied since 3 December 2018 (Geo-blocking Regulation) and therefore concerns a large share of European online offerings. Technical recommendation and regulatory requirement point in the same direction for once.
The gentler route is a hint rather than a redirect: a dismissible language suggestion with a clear choice that leaves the requested version in place. Search engines still see the requested URL, visitors keep control, and the requirement that the originally requested version stay easily accessible (Geo-blocking Regulation) is met. What matters is that a stored choice does not turn into a forced redirect on the next visit. Whether the flow actually behaves as intended in the browser can be reproduced with recorded browser flows.
Why a one-off audit is not enough
In many projects hreflang is set up once, checked once and then ticked off. The problem: the annotation describes relations between URLs - and URLs change. A campaign page is deleted, a product is discontinued, a category gets a new path, a template is rebuilt. Any of those changes can break a relation without anyone thinking about hreflang. Releases are particularly exposed: if the head section is produced by a layout building block, one changed condition is enough to make the entries vanish across an entire page type - much like the noindex tag that accidentally goes live after a deploy.
| Check aspect | One-off audit | Continuous monitoring |
|---|---|---|
| Timing | snapshot, usually at relaunch | on a fixed cadence and after every release |
| Return links | spot checks on a few templates | complete comparison across the whole language group |
| Status code of targets | rarely checked as well | every hreflang URL fetched individually |
| Redirects | only surface when clicked | captured as a chain and reported |
| Canonical conflict | searched manually in the source | compared automatically per version |
| Head section changes | unnoticed until the next audit | reported as a deviation from the previous day |
| Regional differences | checked from a single network view | checked from several countries |
The difference is not one of thoroughness but of frequency. An audit says what the state was on the day it ran. A continuous check says when the state changed - and that is the information that lets you tie a fault to a release and fix it. The same pattern holds for technical SEO in general: the value comes from repetition, not from the depth of a single pass.
What continuous hreflang monitoring has to check
For the check to be dependable, reading one page's head section is not enough. Four layers interlock and only together produce a usable picture:
Every URL named in the annotation is fetched and examined for whether it points back and names itself (Google Search Central). Only this comparison across the entire language group reveals one-sided relations. A check of individual URLs will not find them, in our experience, because everything looks correct on the page being viewed.
Every hreflang target is called individually: does it answer with 200, with 404 or with a redirect? A special case are pages that report status 200 despite having no content - which is where the article on error pages with the wrong status code comes in, since they pass every automated check as healthy.
Because language redirects and network rules take effect differently by country of origin, the check should run from several regions. Viewed from a single data centre, a geo-based redirect easily looks like a clean state. Why a single check location is too little is covered in the article on monitoring from several locations.
Head section and canonical are template components: they change with the code, not with the content. Monitoring that versions the head section per locale and reports deviations catches the break on the same day - and passes it on through notifications to the responsible team instead of collecting it in a report.
A six-step approach
Insight only turns into effect once the check moves into fixed routines. A pragmatic approach that smaller teams can run as well:
- Define language groups: determine which URLs belong together - per page type, not per individual page. Without that mapping no return link can be checked, because the target state stays unknown and every deviation passes as presumably correct.
- Standardise the annotation method: decide per page type on head section, HTTP header or sitemap and remove the remaining variants (Google Search Central). Duplicate entries from two sources are a frequent cause of contradictory signals.
- Check codes against the standard: compare every language tag against ISO 639-1 and ISO 3166-1 alpha-2 (ISO). A machine comparison catches cases like
en-UKthat slip past a reader because they feel right. - Fetch targets individually: check status code, redirect target and canonical for every hreflang URL. That check belongs in the same run as monitoring for broken links, because both share the same causes.
- Make deploys a trigger: start a run after every release and compare the head section against the last known state. It makes sense to check in the same pass whether stale versions from the cache are still being served - a cached page can keep showing an annotation that was corrected long ago.
- Report the findings: record the state per locale in regular reports, so that deterioration becomes visible before it shows up in rankings, and so that the development stays traceable over months.
If you are setting up a multilingual website from scratch or moving one, take the hreflang check into the migration plan from the start: the article on monitoring website migrations describes the framework for it. A relaunch brings all the risk factors together - new paths, new templates, new redirects - and the annotation is one of the details most easily dropped along the way.
Keeping multilingual setups under continuous watch
hreflang belongs to the declarations that get a lot of attention at launch and hardly any afterwards. That is precisely where the risk lies: the annotation describes relations between URLs, and those relations change with every deploy, every deleted page and every new redirect. A break produces no outage, no error message and no alert - it merely shifts which version appears in which market. That makes it a case for monitoring that compares the state rather than establishing it once.
SEO monitoring from XICTRAQ therefore checks not one page but the language group: every hreflang URL is fetched individually, status code and redirect target are captured per locale, return links are compared against each other, and language tags are checked against the standard. Changes to the head section and the canonical are reported as deviations after a release, and the requests come from check points in several countries, so that regional redirects stand out instead of hiding behind a single network view.
Start with the free trial and see how many of your locales' return links line up today. Or book a personal demo to watch the per-locale check run against your own website.
This article draws on data from Google Search Central, ISO, the European Union and the German Federal Statistical Office, as well as on the Geo-blocking Regulation (EU) 2018/302, the sitemap specification from sitemaps.org and the language tag syntax defined in RFC 5646. The figures cited refer to the state of the respective publication. None of it replaces legal advice.
What is hreflang and what is it needed for?
Why is my hreflang entry being ignored?
Does every multilingual website need an x-default?
x-default names the version for visitors whose language or region matches none of the available ones (Google Search Central). Without it the search engine decides for itself in ambiguous cases - in our experience in favour of the strongest version overall, not necessarily the most fitting one. Typically a language selection page or the international English version serves as x-default.