Roughly three quarters of hreflang implementations contain errors. That figure comes from vendor analysis rather than a peer-reviewed study, so treat the exact percentage with caution, but anyone who has audited multilingual sites will recognise the shape of it. What makes hreflang unusual among technical tasks is the failure mode. It does not degrade gracefully. A single wrong return tag can cause search engines to disregard the relationship between pages, and when that happens the whole cluster stops working rather than one page performing slightly worse.
Luxembourg is where this bites hardest. Four candidate content languages, a workforce nearly half of which searches from three neighbouring countries, and buyers who may legitimately be served by a French page, a German page or an English page depending on who they are. The number of ways to get the tagging wrong is larger here than almost anywhere.
This article is narrow on purpose. It covers the cluster architecture, the four failure modes, and the language-region decisions that are specific to this market.
What a correct cluster actually looks like
Strip away the debate and the mechanics are settled. Google documents hreflang as the mechanism for connecting localised versions of a page. Each version references itself and every equivalent, and one version may be nominated as x-default for users whose language or region is not covered by any of the specific alternates.
Four rules follow from that, and none of them is optional.
One language per URL
Separate indexable URLs for each language, normally under subdirectories such as /fr/ and /de/ and /en/. Not query parameters that get stripped. Not a cookie that swaps the text under a single URL, which leaves search engines with one page whose content changes unpredictably. Subdirectories also inherit the domain's accumulated authority, which matters disproportionately in a small market where earning links is harder than in France or Germany.
Every page canonical to itself
The German version's canonical points at the German version. This sounds obvious and it is the most common serious error we find. Pointing the German page's canonical at the French page tells search engines the German page is a duplicate that should not be indexed separately, which removes it from results while the hreflang tags continue to claim it exists. Google has moved away from recommending the older practice of simplifying canonicals across market variants, so implementations built on advice from several years ago frequently carry this defect.
Reciprocity, or the whole thing is ignored
If the French page lists the German page as an alternate, the German page must list the French page back. Missing return tags are the single most frequent cause of a cluster being disregarded. This is why hreflang has to be treated as a monitored system with its own error report rather than a task someone completes once and closes.
No redirect that blocks a crawler
Automatic redirection based on the visitor's IP address is a genuine trap. If a crawler requesting the French page is forcibly redirected to the English one, it cannot see the French page at all, and the alternate that hreflang promises does not exist as far as the index is concerned. Language switching should be a crawlable link that the user chooses, with any geographic suggestion offered rather than imposed.
How a Language Cluster Cancels Itself
Each of these is silent. Nothing errors, nothing warns, and the pages simply stop being treated as alternates.
Missing return tag
Page A claims Page B as its alternate, Page B says nothing about Page A. The relationship is unverified, so it is disregarded. The most common defect of the four.
Invalid language or region code
Invented codes, a region code where a language code belongs, or the wrong case convention. An unrecognised value is not interpreted charitably, it is skipped.
Alternate URL that redirects or 404s
Common after a migration or a slug change. The tag still points at the old address, so the promised alternate cannot be fetched at the address given.
Cross-language canonical
The German page declares the French page as canonical. Hreflang says the German page exists as an alternate while the canonical says it should not be indexed at all. The contradiction resolves against you.
Error prevalence estimate of roughly 75% is from vendor analysis rather than peer-reviewed research. The failure mechanisms themselves are documented behaviour.
The language-region decisions that are specific to Luxembourg
Most guidance stops at "use the right codes" and leaves the actually difficult question untouched. Which codes? A French page for a Luxembourg business could reasonably be tagged fr, fr-LU, or left to compete with content targeted at fr-FR. Each choice has consequences, and in this market the choice interacts with the commuter population.
Consider a fiduciary in Luxembourg City. Its buyers include resident directors, French-resident commuters who work in the building, Belgian accountants referring clients across the border, and German-speaking family offices. Every one of those people might search in French or German or English. Some of them are physically in Luxembourg and some are not. There is no single correct targeting answer, only a defensible one.
| Situation | Reasonable tagging | Why |
|---|---|---|
| One French page serving Luxembourg only | fr-LU | Explicit about audience. Sensible where pricing, legal references or service coverage are Luxembourg-specific |
| One French page serving Luxembourg and cross-border commuters | fr | Language without region avoids excluding a French-resident commuter who is a legitimate buyer |
| Separate pages for Luxembourg, France and Belgium in French | fr-LU, fr-FR, fr-BE | Only justified where the content genuinely differs. Otherwise you have created three near-duplicates to maintain |
| German page for a Luxembourg business also serving DACH | de, with de-LU only if content differs | Splitting de-LU from de-DE without differentiated content usually costs more than it returns |
| English page for finance, funds and EU institutional buyers | en, frequently also the x-default | English is the working language of much of this audience and the safest fallback for unmatched visitors |
The pattern in that table is worth naming. Region codes are for content differences, not for flags. Adding fr-LU, fr-FR and fr-BE to three pages containing the same words does not target three markets. It creates three near-duplicate pages, triples the maintenance surface, and gives you three chances to break a return tag.
Do Not Let One Tag Do Another Tag's Work
Most broken clusters come from confusing these three, so it is worth being able to state the difference out loud.
Canonical
Names the preferred URL for this piece of content in this language. It points at itself. It is not a tool for consolidating languages, and using it that way removes pages from the index.
Hreflang alternate
Declares that an equivalent exists in another language or region. It must be reciprocal to be trusted, and it does not consolidate anything or influence which page ranks in its own language.
x-default
The fallback for visitors whose language and region match none of the alternates. In Luxembourg this is usually the English page, since English serves the widest unmatched audience here.
Behaviour as documented by Google. Google no longer recommends the older practice of simplifying canonicals across market variants.
Translation is not localisation, and search treats them differently
A cluster can be technically flawless and still fail. If the French page is unedited machine output, it will struggle, and there is a further risk that thin translated content across many language versions drags on quality signals more broadly rather than only on the page concerned.
This is not a market where that risk can be waved away. French is the sole language of legislative drafting in Luxembourg, so professional French here carries legal and administrative register that generic translation flattens. A German-speaking family office reading obviously machine-generated German will draw a conclusion about the firm, not about the website. And the audience is unusually multilingual, which means a reader can often compare your French and your English and notice that one of them was written by a person.
Our own rule is uncomfortable to state in a sales context and we state it anyway. Where we cannot staff native review for a language, we narrow the mandate rather than ship the language. Publishing four languages badly is worse than publishing two well, and in a market this small the reputational cost travels quickly.
Structured data has to follow the language too
Each language version should carry its own structured data with the correct inLanguage value and descriptions in that language, matching the visible content. This is worth doing because it clarifies which entity and which page a given claim belongs to. It is worth being honest about the limits as well: Google states that eligibility for its AI features depends on ordinary indexability and snippet eligibility, with no additional technical requirement, so structured data should not be sold as a mechanism that causes AI systems to cite you.
And if the fourth language is Luxembourgish
Some clients will want a Luxembourgish version, and there are legitimate reasons to build one. Municipal and civic content, cultural programming, and consumer brands where speaking the national language is part of the identity. If you do publish it, tag it lb, give it its own indexable URL, make it canonical to itself, and include it in every reciprocal set exactly like the others. The mechanics do not change.
What should change is the expectation attached to it. Luxembourgish is not currently among the supported languages for Google's AI Overviews or AI Mode, on Google's own published language lists, while smaller European languages including Romansh, Faroese and Maltese are. Peer-reviewed work also characterises Luxembourgish as a low-resource language for large language models, with documented failure modes in generation. So a Luxembourgish version can serve brand, civic and navigational purposes while contributing little to visibility inside AI-generated answers, at least as things stand at the date of writing.
That is a reasonable thing to build with clear eyes. It is not a reasonable thing to sell as an AI visibility play, and language support lists change without notice, so the claim needs a date attached whenever it is made.
Treat it as a monitored system
The reason hreflang keeps breaking is that it is usually implemented once and then subjected to years of ordinary website activity. Someone changes a slug. A page is retired. A new language is added by a different team. A migration rewrites URLs. Each of those is routine, and each can silently sever a return tag.
So the deliverable is not an implementation. It is an error report that runs on a schedule and that the client can read without a specialist present: every cluster, every alternate, whether the return tag exists, whether the URL resolves with a 200 status, whether the canonical is self-referential, and whether the language and region codes are valid. When something breaks, it should be visible that week rather than at the next annual audit.
That is unglamorous work. It is also the difference between a multilingual site that functions and four language versions that quietly compete with each other while everyone wonders why the German pages never appear.
Frequently Asked Questions
Do I really need hreflang if all my pages are on the same domain?
Yes, if you publish the same content in more than one language. Without hreflang, search engines have to infer which version to serve to which user, and inference is unreliable when several versions cover similar topics. The tags declare the relationship explicitly. What hreflang does not do is consolidate ranking signals between languages or decide which page ranks in its own language, and it is not a substitute for each version being independently indexable and canonical to itself.
Should a Luxembourg site use fr-LU or just fr?
It depends on whether the content differs. Use fr-LU where the page carries genuinely Luxembourg-specific substance such as local legal references, local service coverage or Luxembourg pricing. Use plain fr where the page serves French speakers regardless of which side of the border they sit on, which matters here because cross-border commuters filled 47% of roughly 494,000 salaried jobs at the end of 2025 and many of them are legitimate buyers searching from France. Region codes should follow content differences rather than being added as flags.
What should x-default point at in Luxembourg?
Usually the English version. x-default is the fallback for visitors whose language and region match none of the specific alternates, and English serves the widest unmatched audience in this market given the working-language profile of finance, funds, specialised professional services and the EU institutional population. It is a fallback rather than a preference, so nominating English as x-default does not weaken the French or German versions for their own audiences.
Can I point all language versions at one canonical URL to avoid duplicate content?
No, and this is one of the more damaging errors we find. Different languages are not duplicate content. Pointing the German page's canonical at the French page tells search engines the German page should not be indexed separately, which removes it from results while the hreflang tags continue to assert that it exists as an alternate. Google has moved away from recommending the older practice of simplifying canonicals across market variants, so implementations built on older advice often carry exactly this defect.
Is machine translation acceptable for the French and German versions?
Unedited machine output performs poorly, and thin translated content across many language versions carries a broader quality risk rather than affecting only the page concerned. That risk is amplified here because French is the sole language of legislative drafting in Luxembourg, so professional French carries a register that generic translation flattens, and because the audience is multilingual enough to compare your French against your English. Machine translation as a first draft followed by native review is workable. Machine translation as the published artefact is not.
How often should hreflang be audited?
Continuously rather than periodically, because the failures are silent and are caused by ordinary site activity such as slug changes, retired pages, migrations and new language versions added by a different team. Nothing errors and nothing warns. The practical answer is a scheduled error report covering every cluster: return tag present, alternate URL resolving with a 200 status, canonical self-referential, and language and region codes valid. A break should surface within the week rather than at the next annual audit.
Sources & References:
- Hreflang mechanism, self-referencing requirement, reciprocity and x-default behaviour: Google Search Central documentation on localised versions of pages.
- Google no longer recommends the older practice of simplifying canonical tags across market variants. Google Search Central documentation.
- Estimate that approximately 75% of hreflang implementations contain errors, and that a single error can invalidate a cluster: vendor analysis, digitalapplied.com. REPORTED, single secondary source. The underlying failure mechanisms are documented behaviour rather than vendor claims.
- AI feature eligibility depends on ordinary indexability and snippet eligibility with no additional technical requirement: Google Search Central documentation. No study establishes that adding structured data causes AI systems to cite a source.
- Luxembourgish is not listed among the supported languages for Google AI Overviews or AI Mode on Google's published supported-language lists, checked August 2026, while Romansh, Faroese and Maltese are. Language support lists change without notice.
- Luxembourgish as a low-resource language for large language models with documented generation failure modes: Lothritz, Cabot and Bernardy, Findings of the ACL: EACL 2026. Peer-reviewed.
- Cross-border employment: STATEC, Regards 02/26. Cross-border commuters held 47% of approximately 494,000 salaried jobs at end-2025.
- French as the sole language of legislative drafting in Luxembourg: luxembourg.public.lu.
- Workplace and company language profile used to justify English as x-default: STATEC, Active Residents, 2021 census basis, and STATEC via luxembourg.public.lu on main company working language.
- Machine translation performance and the broader quality risk of thin translated content across language versions are described as risks reported in industry guidance rather than as measured outcomes for this market.
- This article is technical search guidance, not legal advice.