Hreflang for DACH: Separating Germany, Austria and Switzerland

Businesses active across the DACH region often have a problem that goes unnoticed until you look for it directly: Google is not sure which page version is meant for which country. The language is German everywhere, but prices, phone formats and terminology differ - and without a clear signal, the search engine guesses instead of knowing.

Why hreflang matters especially in the DACH region

DACH is linguistically close but commercially more different than it looks at first glance. Different prices, different phone country codes, sometimes different terminology, and different legal requirements, for example around imprint obligations. Without hreflang, all three country versions effectively rank against each other for the same searches, and Google decides which version to show a visitor in Vienna or Zurich. With hreflang, you state it explicitly instead: this URL is for Germany, this one for Austria, this one for Switzerland.

These differences are the real reason a single shared page for all three countries rarely convinces: a Swiss visitor who sees prices in euros instead of francs and finds a German phone code in the contact form experiences the page as not built for them, regardless of how good the content otherwise is.

The correct hreflang syntax

Every language-country combination gets its own code: de-DE for German in Germany, de-AT for German in Austria, de-CH for German in Switzerland. An x-default version is added for visitors who cannot be clearly assigned to any of the three. A complete set for one page in the HTML head looks like this:

<link rel="alternate" hreflang="de-DE" href="https://example.de/" />
<link rel="alternate" hreflang="de-AT" href="https://example.de/at/" />
<link rel="alternate" hreflang="de-CH" href="https://example.de/ch/" />
<link rel="alternate" hreflang="x-default" href="https://example.de/" />

The rule most often overlooked is this: every page must also point to itself, known as self-referencing. The German page therefore also carries a de-DE link to itself, in addition to the links to the AT and CH versions. Without that self-reference, Google will often ignore the entire set.

Where the hreflang tag can live

Three technical paths lead to the same result, with different maintenance overhead:

• In the HTML head of every page as a link element - the easiest to maintain for most sites
• In the HTTP header - necessary for non-HTML resources such as PDF documents
• Centrally in sitemap.xml - practical with a large number of URLs, since everything is maintained in one place

Our own website uses the HTML variant: every page gets its hreflang alternates automatically from the same routing configuration that also produces the canonical URL, for German and English. That prevents translated paths and hreflang entries from drifting apart over time, since both are fed from the same source.

Common mistakes in practice

• Forgetting self-referencing: the page's own language version is missing from its own hreflang set
• Inconsistent URLs: trailing slash present on one variant, missing on another
• Wrong language codes, such as 'at' instead of the correct 'de-AT'
• Pointing to a URL that no longer exists or returns an error
• Asymmetric linking: the DE page points to the AT page, but the AT page does not point back

Any single one of these mistakes is enough for Google to discard a page's entire hreflang set and go back to guessing which version to show - all the implementation effort then goes to waste. Asymmetric linking is especially tricky, because it often only surfaces once one of the three versions is later renamed or moved and the other two are not updated to match. A hreflang set is not a one-time setup, it is something that needs maintaining every time one of the involved language versions changes structurally.

How to check that hreflang actually works

Three pragmatic methods give reliable coverage. Google Search Console shows hreflang errors per URL group under international targeting and is the first place to look. A manual test through a VPN service with a Swiss or Austrian IP address helps check which version actually shows up in a Google search. For pure syntax checking, specialised online tools such as Merkle's hreflang tag checker validate an existing set against the formal rules before it even goes live. All three methods complement each other: Search Console shows errors Google has already detected, the syntax checker catches problems before Google even sees them, and the manual VPN test shows how the implementation actually plays out in the search result - three different angles on the same question.

Concrete steps for the next 90 days

• Days 1-30: check your existing hreflang implementation with Search Console and a syntax checker, document gaps
• Days 31-60: add missing self-references, clean up URL inconsistencies, decide on an x-default version
• Days 61-90: launch the implementation, verify with a VPN test from AT and CH, watch results in Search Console

Conclusion

Hreflang is one of the technically simplest yet most commonly mis-implemented SEO measures for businesses focused on the DACH region. Getting the syntax right, never forgetting self-referencing, and checking it regularly wins visibility in all three countries at once, without the versions cannibalising each other. We cover how this technical cleanliness ties in with a modern rendering architecture in our article JavaScript SEO for SPAs. What a technical SEO audit typically costs is covered in our article on SEO costs. For a no-obligation review of your current hreflang setup, feel free to get in touch.