Hreflang für DACH: AI-Plattformen ignorieren Sprachsignale

Hreflang gilt als Standardwerkzeug für mehrsprachige und mehrregionale Websites. Im DACH-Raum soll es sicherstellen, dass österreichische Nutzer:innen die de-AT-Version sehen, deutsche die de-DE-Version und Schweizer die de-CH-Version. Diese Logik funktioniert in der klassischen Google-Suche, stößt aber an eine neue Grenze: AI-Plattformen wie ChatGPT, Perplexity, Copilot und Claude werten Hreflang-Annotationen weitgehend nicht aus. Dieser Artikel erklärt, wie Hreflang für DACH korrekt aufgesetzt wird, warum AI-Crawler die Signale ignorieren und wie du de-AT-Content trotzdem für KI-Antworten und klassische Suche sichtbar machst.

Warum Hreflang für DACH relevant ist und wo die neue Grenze liegt

Der DACH-Raum ist ein Sonderfall: drei Länder, eine Sprache, aber unterschiedliche Märkte, Preise, Rechtslagen und teils abweichende Begriffe. Genau hier setzt Hreflang an. Es teilt Suchmaschinen mit, welche URL für welche Sprach-Region-Kombination gedacht ist, damit Google in Österreich die de-AT-Seite und in Deutschland die de-DE-Seite ausspielt.

Der österreichische Markt ist dabei nahezu vollständig digital erschlossen. Zu Jahresbeginn 2025 nutzten 8,69 Millionen Menschen in Österreich das Internet, bei einer Penetrationsrate von 95,3 Prozent (Österreich). Wer diesen Markt mit eigener de-AT-Lokalisierung adressiert, hat ein berechtigtes Interesse daran, dass die richtige Variante ausgespielt wird, in Google und zunehmend auch in KI-Systemen.

Genau dort verschiebt sich das Spielfeld. Hreflang funktioniert nicht mehr als harter Constraint, sobald Inhalte über AI-vermitteltes Retrieval ausgegeben werden. Die Verbreitung dieser KI-Suche ist messbar: In Deutschland nutzen 50 Prozent der Internetnutzer:innen zumindest gelegentlich KI-Chats statt klassischer Suchmaschinen (Deutschland), und 42 Prozent dieser KI-Sucher:innen haben bereits falsche oder erfundene Informationen von der KI erhalten (Deutschland). Falsche Sprachversionen sind ein Teil dieses Problems: Wenn ein System de-DE-Inhalte an eine österreichische Anfrage ausgibt, stimmen Preise, USt-Sätze oder Rechtsbegriffe oft nicht.

Hreflang-Grundlagen für DACH: korrekte Annotation und reziproke Pflicht

Eine saubere Hreflang-Implementierung für den DACH-Raum folgt klaren Regeln. Die Sprach-Region-Codes kombinieren ISO 639-1 (Sprache) mit ISO 3166-1 Alpha-2 (Region).

• Korrekte Sprach-Region-Codes: de-DE für Deutschland, de-AT für Österreich, de-CH für die Schweiz. Reines de ohne Region adressiert alle deutschsprachigen Nutzer:innen unabhängig vom Land und kann als zusätzliche generische Variante sinnvoll sein.
• x-default als Fallback: Der Wert x-default kennzeichnet die Seite, die ausgespielt wird, wenn keine andere Variante passt, etwa für deutschsprachige Nutzer:innen ausserhalb von DACH oder für eine Sprachauswahlseite. x-default ist der am häufigsten fehlende Baustein.
• Self-Referencing: Jede Seite muss sich auch selbst per Hreflang referenzieren. Die de-AT-Seite listet also nicht nur de-DE und de-CH, sondern auch sich selbst als de-AT.
• Reziproke Verweise (Rückverweis-Pflicht): Hreflang ist bidirektional. Verweist die de-DE-Seite auf die de-AT-Seite, muss die de-AT-Seite zurück auf die de-DE-Seite verweisen. Fehlt der Rückverweis, ignoriert Google die Annotation.

Ein DACH-Minimum besteht damit aus de-DE, de-AT, de-CH und x-default, jeweils mit vollständigen, reziproken und selbstreferenzierenden Tags. Trotz dieser klaren Regeln ist Hreflang fehleranfällig. Eine internationale Analyse von 374.756 Domains fand, dass 67 Prozent mindestens ein Hreflang-Implementierungsproblem haben (international). Die häufigsten Fehler: bei 56,3 Prozent fehlt x-default, bei 18 Prozent fehlen selbstreferenzierende Tags und bei 16,9 Prozent verweisen Hreflang-Tags auf weitergeleitete oder defekte Seiten (international).

Warum AI-Crawler Hreflang weitgehend ignorieren

Der entscheidende Unterschied zwischen Google und AI-Plattformen liegt in der Verarbeitung. Google rendert Seiten, führt JavaScript aus und trifft auf Basis von Hreflang, Standort und Spracheinstellung eine Locale-Auswahl. AI-Crawler tun das nicht.

Eine Analyse des Crawler-Traffics über das Vercel-Netzwerk zeigt, dass keiner der grossen AI-Crawler JavaScript rendert (international). GPTBot, OAI-SearchBot, ClaudeBot und PerplexityBot laden Inhalte, führen sie aber nicht aus. Allein GPTBot erzeugte in einem Monat 569 Millionen Anfragen über das Netzwerk (international). Zwar laden einige Crawler JavaScript-Dateien herunter, bei ChatGPT machen JS-Dateien 11,50 Prozent und bei Claude 23,84 Prozent der Anfragen aus (international), zur Ausführung fehlt jedoch die Rendering-Umgebung. Eine breitere Untersuchung von 23 grossen AI-Crawlern kommt zum gleichen Ergebnis: 69 Prozent der AI-Crawler können kein JavaScript ausführen (international), darunter explizit GPTBot und ClaudeBot.

Daraus folgen drei Konsequenzen für Hreflang:

• Kein JS-Rendering: Hreflang-Signale, die erst durch clientseitiges JavaScript in den DOM gelangen, sind für AI-Crawler unsichtbar. Sie sehen nur das initiale HTML.
• Keine Locale-Auswahl: AI-Plattformen interpretieren Hreflang nicht als Auswahlmechanismus. Sie verarbeiten die URL, die sie gerade abgerufen haben, ohne aktiv die de-AT-Variante einer de-DE-URL zu suchen.
• Hint statt Constraint: Was bei Google ein schwacher Hinweis ist, wird im AI-Retrieval praktisch wirkungslos. Die Plattform liefert die Version aus, die sie indexiert hat, nicht zwingend die regional passende.

Wichtig ist die positive Kehrseite: Inhalte im initialen HTML, auch eingebettete JSON-Daten oder serverseitig gerenderte Komponenten, können indexiert werden, weil AI-Modelle auch Nicht-HTML-Inhalte interpretieren. Der Hebel liegt also nicht in Hreflang, sondern darin, das richtige Sprachsignal direkt ins ausgelieferte HTML zu schreiben.

content-language statt Hreflang für Bing und Copilot

Ein verbreiteter Irrtum ist, dass Hreflang ein universeller Standard sei. Bing unterstützt Hreflang nicht und nutzt stattdessen das content-language-Signal. Das ist im DACH-Raum kein Randthema: In Österreich liegt Bing mit 9,01 Prozent Marktanteil klar auf Platz zwei hinter Google mit 81,87 Prozent (Österreich, Mai 2026). Da Microsoft Copilot auf dem Bing-Index aufbaut, wirkt das content-language-Signal auch in dieses KI-System hinein.

• Korrektes ll-cc-Format: Auch content-language nutzt das Schema Sprache-Region, etwa de-AT. Mehrere Werte werden kommagetrennt angegeben.
• Priorität der Quellen: Bing wertet das Signal in einer Reihenfolge aus. Das HTTP-Header-Feld Content-Language hat Vorrang, danach das HTML-Attribut lang am html-Element, danach ergänzende Meta-Angaben. Wichtig ist Konsistenz über alle drei Ebenen.
• lang-Attribut nicht vergessen: Das Attribut lang="de-AT" am html-Tag ist das einfachste und robusteste On-Page-Sprachsignal. Es steht im initialen HTML und ist damit für Crawler ohne JS-Rendering sichtbar.

Für die Praxis bedeutet das: Wer DACH-Varianten ausspielt, sollte Hreflang für Google und content-language plus ein korrektes lang-Attribut für Bing, Copilot und AI-Crawler gemeinsam pflegen.

Hreflang als Hinweis, nicht als Direktive

Selbst bei Google ist Hreflang kein Befehl. Google bezeichnet Hreflang-Tags ausdrücklich als Hinweise, nicht als Direktiven (international). John Müller von Google stellt klar, dass Hreflang keine Indexierung garantiert und dass Google bei nahezu identischen Varianten häufig eine davon als Canonical wählt.

Das ist für DACH besonders relevant. de-DE, de-AT und de-CH sind sprachlich oft fast identisch. Sind zwei Varianten inhaltlich gleich, wählt Google bei gleichsprachigen Versionen typischerweise eine als Canonical, weil die Systeme die Sache vereinfachen (international). In der Folge kann die de-AT-Seite aus dem Index fallen, obwohl die Hreflang-Annotation technisch korrekt ist.

Dagegen hilft echte Differenzierung. Je stärker sich die de-AT-Variante inhaltlich unterscheidet, desto eher behandelt Google sie als eigenständige Seite:

• Eigenständige Inhalte: Österreichische Preise in Euro mit korrektem USt-Satz, lokale Ansprechpartner, österreichische Rechtsbegriffe und Referenzen aus dem AT-Markt.
• Lokale Begriffe und Schreibweisen: Wo sich österreichisches Deutsch unterscheidet, sollte der Text das abbilden. Das schärft Relevanz und Abgrenzung zugleich.
• Eigene URL je Variante: Eine klar getrennte URL pro Variante ist die Voraussetzung dafür, dass eine Variante überhaupt indexiert und in AI-Systemen referenziert werden kann.

Implementierungsmethoden im Vergleich und ihre AI-Sichtbarkeit

Hreflang lässt sich auf drei Wegen implementieren. Für AI-Crawler ist entscheidend, ob das Signal im initialen HTML steht.

• HTML-link-Elemente im head: Die Hreflang-Annotationen stehen als link-Tags im head-Bereich. Wenn sie serverseitig gerendert werden, sind sie im initialen HTML enthalten und damit für alle Crawler sichtbar. Diese Methode ist für DACH am transparentesten.
• HTTP-Header: Hreflang kann über den Link-HTTP-Header ausgeliefert werden, vor allem für Nicht-HTML-Dokumente wie PDFs. Der Header ist crawlerunabhängig sichtbar, in der Praxis aber schwerer zu warten.
• XML-Sitemap: Hreflang lässt sich vollständig in der XML-Sitemap abbilden. Das hält den HTML-Code schlank, hat aber einen Nachteil für AI-Retrieval: Das Signal steht nicht in der einzelnen Seite. Ein AI-Crawler, der eine URL direkt abruft, ohne die Sitemap auszuwerten, sieht die Annotation nicht.

Für die klassische Google-Suche sind alle drei Methoden gültig, aber sie dürfen nicht gemischt werden. Für die AI-Sichtbarkeit ist die serverseitig gerenderte head-Variante die robusteste, weil sie das Sprachsignal direkt mit dem ausgelieferten Dokument verbindet. Entscheidend bleibt jedoch das lang-Attribut und klare On-Page-Sprachsignale, da diese auch ohne Hreflang-Interpretation wirken.

Hreflang in Next.js und headless Architekturen

In modernen Next.js- und headless-Setups entscheidet die Rendering-Strategie darüber, ob Sprachsignale überhaupt bei AI-Crawlern ankommen.

• Server-Side-Rendering statt Client-Side: Locale-Signale müssen im initialen HTML stehen, nicht erst nach der Hydration durch clientseitiges JavaScript erzeugt werden. Da AI-Crawler kein JS rendern, geht jedes erst clientseitig gesetzte Signal verloren.
• alternates.languages in den Metadata: Next.js erlaubt es, Hreflang über das Metadata-Objekt mit alternates.languages serverseitig auszugeben. So landen die Annotationen verlässlich im head des initialen HTML.
• lang-Attribut serverseitig setzen: Das lang="de-AT" am html-Element sollte vom Server pro Locale gesetzt werden. Es ist das stabilste Sprachsignal für Crawler ohne Rendering.
• Saubere head-Struktur: Wichtige Meta-Daten müssen oben im head stehen. Eine internationale Erhebung fand, dass 10,1 Prozent der Desktop-Seiten ungültige Elemente im head haben (international). Stehen Hreflang, Canonical oder Meta-Robots unterhalb eines ungültigen Elements, werden sie in den body verschoben und damit wirkungslos.

GEO- und AEO-Konsequenzen für de-AT-Content

Wenn AI-Plattformen Sprachsignale ignorieren, verschiebt sich die Aufgabe von der Locale-Steuerung zur reinen Sichtbarkeit. Ziel ist, dass de-AT-Content in ChatGPT, Perplexity und Copilot als österreichischer Content erkennbar ist, ohne dass Hreflang als Filter wirkt.

• Serverseitiges Rendering als Pflicht: Nur was im initialen HTML steht, wird von AI-Crawlern verarbeitet. de-AT-Inhalte müssen vollständig serverseitig ausgeliefert werden.
• Explizite On-Page-Sprachsignale: Statt sich auf Hreflang zu verlassen, sollte der österreichische Bezug im Text selbst stehen: Österreich, AT-Standorte, Euro-Preise mit österreichischem USt-Satz, österreichische Rechts- und Fachbegriffe. Das macht die Lokalisierung für Sprachmodelle direkt lesbar.
• Eigene, stabile URLs: Jede Variante braucht eine eindeutige, dauerhaft erreichbare URL, damit sie zitiert und verlinkt werden kann.
• Strukturierte, belegte Inhalte: Klare Definitionen, Listen und belegte Aussagen erhöhen die Wahrscheinlichkeit, in generativen Antworten als Quelle genannt zu werden.

Der Subfolder-Ansatz mit example.com/at/ ist hierfür dem getrennten ccTLD-Ansatz meist überlegen, weil er die Domain-Autorität konsolidiert und gleichzeitig eine klare, indexierbare URL pro Region liefert. So bleibt die Lokalisierung erhalten, ohne die Sichtbarkeit auf mehrere schwache Domains zu verteilen.

Hreflang im Zusammenspiel mit Canonical, Redirects und Sitemaps

Hreflang steht nie allein. Konflikte mit Canonical-Tags, Redirects und Sitemaps gehören zu den häufigsten Fehlerquellen.

• Canonical und Hreflang nicht widersprüchlich setzen: Jede Variante sollte auf sich selbst kanonisieren. Ein Canonical, der von der de-AT- auf die de-DE-Seite zeigt, hebt die Hreflang-Logik auf und führt zur Konsolidierung.
• Keine Verweise auf Redirects: Hreflang muss auf die finale, mit Status 200 erreichbare URL zeigen, nicht auf eine per 301 weitergeleitete Adresse. Verweise auf Redirects oder defekte Seiten sind ein dokumentierter Hauptfehler.
• Konsistenz mit der XML-Sitemap: URLs in der Sitemap, im Canonical und in den Hreflang-Annotationen müssen identisch sein, inklusive Protokoll, Slash und Gross-/Kleinschreibung.

Die Größenordnung dieser Probleme ist erheblich. Eine internationale Studie von 18.786 Websites mit Hreflang-Code fand bei 31,02 Prozent widersprüchliche Hreflang-Direktiven und bei 47,95 Prozent ein fehlendes x-default (international). Solche Konflikte führen dazu, dass Google die Signale ignoriert und selbst entscheidet.

Monitoring, Validierung und Messung

Hreflang braucht laufende Kontrolle, gerade weil Fehler oft unsichtbar bleiben. Eine Kombination aus Tooling und Logfile-Analyse deckt die wichtigsten Probleme ab.

• Google Search Console: Der Bereich zur Internationalen Ausrichtung und die Indexabdeckung zeigen Hreflang-Fehler und ob die einzelnen DACH-Varianten tatsächlich indexiert sind.
• Crawler wie Screaming Frog: Ein technischer Crawl deckt fehlende Self-Referenzen, fehlendes x-default, nicht-reziproke Verweise und Hreflang-Tags auf, die auf Redirects oder Non-Canonical-Seiten zeigen.
• Logfile-Analyse der AI-Bot-Zugriffe: Server-Logs zeigen, ob und wie GPTBot, ClaudeBot und PerplexityBot die einzelnen Varianten abrufen. So lässt sich prüfen, ob das initiale HTML mit den korrekten Sprachsignalen ausgeliefert wird.
• Content-Render-Check: Ein Abruf des reinen HTML ohne JavaScript-Ausführung zeigt, ob lang-Attribut, Hreflang im head und der lokale Bezug wirklich im initialen Dokument stehen.

Zur Einordnung der Verbreitung: Laut der internationalen Web-Almanac-Erhebung 2022 nutzten 9,6 Prozent der Seiten auf dem Desktop Hreflang-Tags, wobei de zu den vier häufigsten Sprachwerten zählte (international). Hreflang ist also weit verbreitet, aber wie die Fehlerquoten zeigen, selten fehlerfrei.

Weiterführendes und Fazit

Hreflang bleibt für die klassische Google-Suche im DACH-Raum sinnvoll, wenn es sauber umgesetzt wird: de-DE, de-AT, de-CH und x-default mit vollständigen, reziproken und selbstreferenzierenden Tags. Entscheidend ist die Einsicht, dass Hreflang schon bei Google nur ein Hinweis ist und im AI-vermittelten Retrieval praktisch wirkungslos wird, weil AI-Crawler kein JavaScript rendern und keine Locale-Auswahl treffen.

Die Konsequenz für Unternehmen mit österreichischem Markt ist klar: Sprachsignale gehören ins serverseitig gerenderte HTML, der österreichische Bezug in den sichtbaren Text, und jede Variante braucht eine eigene, stabile URL. Erganzend sollten content-language und das lang-Attribut für Bing und Copilot gepflegt werden. Sinnvolle nächste Schritte sind ein Render-Check des initialen HTML, ein Hreflang-Audit mit einem Crawler und eine Logfile-Analyse der AI-Bot-Zugriffe, um zu prüfen, ob die richtige Variante überhaupt bei den KI-Systemen ankommt.