Canonical Is Not hreflang: How to Audit a Multilingual Website Properly
Multilingual pages can be reachable yet still lose the right language version in search. Learn how to audit canonicals, hreflang clusters, sitemaps, and language switching.
A company translates its website properly into German and English. Both versions are reachable, internally linked, and included in the sitemap. Yet Google starts showing the English URL for a German query, or one localized page disappears from the index.
The first response is often: “But we added hreflang.”
That is where a common misconception begins: hreflang and rel="canonical" solve two different problems. Treating them as interchangeable SEO tags can produce a technically polished multilingual setup whose signals contradict each other.
Google describes canonicalization as choosing a representative URL from duplicate or very similar pages. hreflang, by contrast, connects language or regional variants so the appropriate version can be served to users. Google also states that localized pages are only considered duplicates when the main content remains untranslated.
The practical consequence is simple: a German and an English page usually need their own canonical URLs while also being connected as language alternatives.
The common failure pattern
Imagine these pages:
https://example.com/de/leistungenhttps://example.com/en/services
The German page declares the English page as canonical because both pages represent “the same content.” At the same time, both pages reference each other with hreflang.
That may sound logical to a person: same subject, two languages. But the signals describe different relationships. The canonical effectively says: this other URL is the representative version of my content. The hreflang annotation says: this URL is a distinct localized alternative.
A more robust configuration will normally look like this:
- the German page canonicals to itself,
- the English page canonicals to itself,
- both pages list themselves and the other language page as
hreflangalternatives, - both URLs are reachable, indexable, and final,
- sitemaps and internal links point to those same final URLs.
Google's canonicalization guidance specifically recommends choosing a canonical in the same language when using hreflang, or the best available substitute language if no same-language canonical exists.
Canonical and hreflang answer different questions
Canonical asks: Which URL represents this content?
Canonicalization matters when the same or very similar content is available through several URLs. Common causes include tracking parameters, filters, legacy paths, HTTP/HTTPS variants, or very similar regional pages.
Google treats rel="canonical" as a strong signal, not an absolute command. Redirects, canonicals, and sitemap signals can reinforce one another. When signals conflict, Google may select a different canonical from the one you prefer.
hreflang asks: Which localized variant belongs to this page?
hreflang describes relationships between language or regional versions. A German page might use de, an English page en, and a Swiss German variant de-CH.
Importantly, Google does not use hreflang or the HTML lang attribute as its only way to detect a page's language. The visible content itself needs to make the language clear.
Eight multilingual red flags
1. Every language canonicals to one language
If /de/, /en/, and /fr/ all canonicalize to /en/ even though the main content is genuinely translated, the site is modelling localization incorrectly.
2. hreflang works in only one direction
If the German page points to English but the English page does not point back, Google may ignore or misinterpret the annotations. Reciprocal references are part of Google's guidance for reliable relationships.
3. A page omits itself
Every language version should include itself in its own hreflang set. The cluster is not merely a list of the “other” languages.
4. hreflang points to redirects, 404s, or non-indexable pages
Language relationships should point to final, reachable URLs. A cluster that relies on redirect chains or references noindex pages is needlessly fragile.
5. Language or region codes are wrong
en-GB combines a language and a region. A region code on its own is not enough. Intuitive-looking codes are not automatically valid either. Google's documentation explicitly notes that UK has no effect in hreflang; GB is the relevant region code.
6. HTML, HTTP headers, and sitemaps tell different stories
Google supports hreflang in HTML, HTTP headers, or sitemaps. Maintaining all three provides no Search benefit according to Google and increases the chance that implementations drift apart.
7. Language depends only on cookies or browser detection
If one URL serves different content based on cookies, IP location, or Accept-Language, a crawler may not discover every variant reliably. Google recommends separate URLs for language versions and warns against forced automatic language redirects.
8. The language switcher does not preserve page intent
A visible language switcher that always sends visitors to the other language's homepage is not technically an hreflang error, but it is a product problem. A visitor changing language on a specific service or article expects the corresponding page, not a restart of their journey.
The useful audit is a relationship audit
With hreflang, checking isolated pages is not enough. What matters is the graph between variants.
For every indexable language page, an audit should capture at least:
| Check | Expected result |
|---|---|
| HTTP status | final 200 response |
| Canonical | intended canonical URL, usually self-referential for genuine translations |
| hreflang self | present |
| hreflang alternatives | all intended variants present |
| Return links | alternatives reference back |
| Language codes | valid and appropriate |
| Sitemap | consistent with final URLs |
| Internal links | point to canonical language URLs |
| Indexability | no accidental noindex or blocking failure |
| Language switcher | leads to the semantically corresponding variant |
Even ten page types across three languages turn this into a matrix rather than a short checklist. That is why multilingual defects often surface only after relaunches or CMS changes.
x-default is a fallback, not a fourth language
For language or country selector pages, hreflang="x-default" can be useful. It marks a fallback for users whose language or region does not match an explicit variant.
That is particularly useful for a neutral country selector or global landing page. x-default does not replace normal language variants and does not mean that the target page is the “most important” one.
Regional near-duplicates are different
Not every international site consists of full translations. A business may have three English pages for the US, UK, and Australia with almost identical main content and only regional differences such as prices or shipping details.
In that case, canonicalization and localization interact more closely. Google's guidance for similar or duplicate content in the same language is to choose a preferred version and coordinate canonical and hreflang signals so users can still receive the appropriate regional URL.
This is a strong reason not to implement one global canonical rule for every language and region. The correct model depends on whether pages are truly translated, merely regionally adapted, or technically duplicated.
How to build this audit into operations
1. Define page families
Identify which URLs are semantic counterparts: homepage, product, service, category, article, help content, contact, login, or other page types.
2. Generate the expected language matrix
For each page family, define which language and region variants are supposed to exist. Missing translations should be intentionally missing, not hidden behind accidental links to another language's homepage.
3. Validate canonical and hreflang separately
First check the canonical identity of every URL, then inspect its relationships to alternatives. This makes contradictions visible: a page should not simultaneously imply “I am an independent localized page” and “another URL represents me” without a deliberate reason.
4. Inspect live responses, not CMS fields
What matters is not what an SEO plugin or CMS form says. What matters is what browsers and crawlers actually receive: HTML, response headers, redirects, and sitemaps.
5. Regression-test after releases
New languages, route changes, CMS plugin updates, middleware, reverse proxies, and relaunches can alter canonical or hreflang output. Representative page families should therefore be part of technical regression tests.
What Website-Pflichtencheck would inspect
A multilingual Website-Pflichtencheck audit would not merely search for the string hreflang. It can inspect:
- final status codes and redirects,
- canonicals for each language and regional page,
- complete and reciprocal hreflang clusters,
- valid language and region codes,
- differences between source HTML and rendered DOM,
- hreflang declarations in HTML, HTTP headers, or sitemaps,
- sitemap consistency,
noindexand robots conflicts,- internal links and language switchers,
- unexpected cross-domain or staging targets,
- template-level patterns affecting whole page types.
The goal is not to tick as many SEO tags as possible. It is to make sure each localized page has a clear technical identity while remaining correctly connected to its real alternatives.
If a multilingual site merely “looks right” after every relaunch but nobody checks the full canonical-hreflang graph, the setup is not controlled. One template mistake can alter thousands of relationships at once.
Multilingual architecture is not a collection of individual pages. It is a system of relationships, and it should be audited as one.