Regional variants: de-AT versus de-DE

A site annotates de-DE, de-AT and de-CH, and all three point at the same German page. Reporting tools start listing incorrect return tags, Austrian and Swiss queries surface inconsistently, and nothing about the site has actually changed.

Regional subtags are a claim that distinct pages exist for distinct regions. Making that claim when one page serves everybody is the most common way a well-intentioned annotation set becomes a liability.

When a regional subtag is justified Regional annotations are justified when the regions genuinely receive different content, such as different pricing or legal wording. When the same page serves both regions, annotate the language alone. A currency difference alone is usually handled within one page. When the answer is not known, starting with the language only is reversible; splitting is not. Does this locale deserve a regional tag? Do de-DE and de-AT serve different content? Yes — different pricing or law two URLs, two annotations No — same page, same words one URL, annotate as de Only currency differs usually still one page Unknown start with the language only
The fourth branch is the honest default: adding a region later is easy, removing one is not.

Root cause: a regional tag describes a page, not an audience

hreflang="de-AT" does not mean “German readers in Austria are welcome here”. It means “this URL is the Austrian German version of this page”. If the URL is the same one annotated as de-DE, the claim is that one URL is simultaneously two distinct regional versions, which is not a thing a crawler can act on.

The practical result is that some or all of the annotations are ignored, and the site loses the benefit of the ones that were correct. It also produces the confusing reports, because a tool checking reciprocity finds one URL claiming several identities.

The underlying confusion is understandable. Region matters enormously to a product — pricing, tax, shipping, legal wording — and it feels like the annotation should express that. But the annotation describes the document, and if the document is identical then no annotation can make it regional.

Language-only versus regional page splits Splitting by language alone gives one URL, one catalogue and one annotation entry per language, with translation paid once. Splitting by region multiplies URLs, catalogues that are largely identical, annotation entries and translation cost, and spreads crawl budget across near-duplicate pages. What a regional split actually costs One page per language One page per region URLs to maintain one per language one per region Catalogues one per language one per region, mostly identical Annotations n entries n×regions entries Translation cost paid once paid per region Crawl budget proportional multiplied
Every row multiplies. A regional split is a commitment to maintaining near-duplicates indefinitely.

Minimal reproducible example 

<!-- All three point at one URL: the claim is unverifiable -->
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/preise" />
<link rel="alternate" hreflang="de-AT" href="https://example.com/de/preise" />
<link rel="alternate" hreflang="de-CH" href="https://example.com/de/preise" />

The fix: annotate the language, or build the pages

If one page serves all German-speaking markets, annotate it once:

<link rel="alternate" hreflang="de" href="https://example.com/de/preise" />

A language-level annotation is honest, it is matched by every German-speaking reader regardless of region, and it needs no additional pages. For the large majority of products this is the correct answer.

If the content genuinely differs — Swiss prices in francs with different VAT wording, Austrian legal text — then the pages are different pages and each needs its own URL:

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

Note the fourth line. Keeping a language-level page alongside the regional ones gives readers in German-speaking regions you have not specifically built for — Liechtenstein, Luxembourg, South Tyrol — somewhere sensible to land, and gives you a target for x-default that is not one of the regions.

Five steps for a regional split that stays maintainable A regional split starts by confirming the content genuinely differs. Each region gets a distinct URL rather than a parameter. Annotations are reciprocal across every region. The catalogue stays single, with a small per-region override layer instead of a full duplicate. And the x-default entry points at the language-level page rather than at one region. Splitting a language into regions, properly 1 Confirm the content genuinely differs pricing, legal text, availability 2 Give each region its own URL /de-at/, not a query parameter 3 Annotate every region reciprocally including the language-only entry if it exists 4 Keep one catalogue, override per region not two full copies 5 Point x-default at the language page not at one of the regions
Step four is what keeps the split affordable — a region is an override layer, not a second translation.

Keeping a regional split affordable

The reason regional splits go wrong operationally is that teams implement them as full duplicates: three catalogues, three sets of pages, three translation invoices for text that is ninety-five percent identical. Within two release cycles the three copies have diverged in ways nobody intended, because a fix applied to one was not applied to the others.

The maintainable shape is a base language catalogue plus a thin per-region override layer. The override contains only the strings that genuinely differ — the price format, the tax sentence, the legal notice — and everything else resolves through the base. That is exactly the mechanism described in fallback chain configuration, applied at the region tier: de-AT falls back to de, and only the deliberate differences are stored.

Translation cost follows the same shape. A region override of thirty strings is thirty strings to translate and review, not three thousand. And because the override is small, a reviewer can actually read all of it, which is what keeps regional differences intentional rather than accidental.

The same argument applies to the pages themselves. A regional page should be the language page with a small number of region-aware components, not a separate template. If two regional templates exist, they will diverge.

Deciding the boundary before you build it

The question “should this be one page or three?” is easier to answer with a small amount of structure than by intuition, and answering it once saves an expensive reversal later.

Start by listing what actually differs between the regions. In practice the list is nearly always drawn from the same handful of items: price and currency, tax treatment, shipping options and timescales, legal or regulatory wording, product availability, and support contact details. Write down which of those apply, and for each one whether it differs in content or only in value.

That distinction is the whole decision. A price that differs in value — the same sentence with a different number and symbol — is a formatting concern that one page handles through date and number formatting standards. A legal notice that differs in content is different prose, and prose that differs is a different page.

Then weigh the count. One or two content differences usually argue for one page with region-aware components, because the maintenance burden of a second page is not justified by two paragraphs. Four or more, particularly if they include anything a regulator cares about, argue for genuine regional pages — at which point the annotations, the URLs and the override catalogue all follow.

The reason to write this down rather than decide informally is that the decision is not reversible on a normal timescale. Splitting one page into three creates URLs that get indexed and shared; collapsing them back means redirects, annotation churn and a period where neither shape is fully in effect. Starting language-only and splitting when the evidence appears is almost always the cheaper order.

Verification 

# Each regional URL must be distinct and must return distinct content
for r in de de-de de-at de-ch; do
  echo -n "$r: "
  curl -s "https://example.com/$r/preise" | md5sum | cut -c1-8
done

# Expected: the language page and each region differ; two identical hashes
# mean one of those regions does not deserve its own URL.

That hash comparison is worth keeping as a periodic check rather than a one-off. Regional pages tend to converge over time as content is updated in one place and copied to the others, and two regions whose pages have become identical should be collapsed back to one — the annotation is only earning its keep while the difference exists.

When to escalate

If regional pages are correct and rankings still favour the wrong region, the signal being outweighed is probably a country-level one such as a country-code domain or a server location. Annotations are a strong hint rather than an override.

If the split was made for currency alone, reconsider it. Currency is usually a property of the transaction rather than of the page, and rendering the right currency within one page — driven by the reader’s account or a selector — avoids the entire multiplication described above.

If reports still show incorrect return tags after the URLs are distinct, the cause has moved to reciprocity: every regional page must list every other one and the language-level page, using exactly the same URL strings. That is the general failure covered in locale-aware SEO and hreflang.

FAQ

Is de a valid hreflang value on its own?

Yes. A language subtag alone is valid and matches every reader of that language regardless of region. It is the right value whenever one page serves them all, and it is the value most sites should be using.

What about es-419 and other UN M.49 regions?

They are valid and useful. es-419 covers Latin American Spanish as a group, which is frequently the real content boundary — one page for Latin America, one for Spain — and it is a far better fit than annotating twenty country codes that all point at the same page.

Can I use a region I do not have a page for?

No. Every annotated value must name a URL that is genuinely that variant. Annotating de-LI because Liechtenstein exists, while pointing at the German page, is the same unverifiable claim in miniature.

Does splitting by region help with local search?

Marginally, and only when the content is genuinely local. A page with regional pricing, a local address and region-specific terms is a better result for that region; a duplicated page with a different URL is not, and it spreads crawl budget across pages that add nothing.

How do regional pages interact with a country-based redirect?

Poorly, if the redirect is unconditional. Sending every Austrian visitor to the Austrian page removes their ability to reach the German one deliberately, and it hides the regional pages from crawlers that request from a single location. Offer the regional page — a dismissible banner naming it — rather than forcing it, and keep every regional URL directly reachable.

Should the region appear in the URL or in a cookie?

In the URL. A cookie-selected region makes one address render different content for different readers, which means the indexed version is arbitrary and a shared link does not carry what the sender saw. The same argument that puts language in the path puts region there too, for exactly the same reasons.

Part of Locale-Aware SEO & hreflang.