GEO SEO

Mehrsprachiges GEO: in jeder Sprache zitiert werden

Alejandro Rioja
Alejandro Rioja
9 Min. Lesezeit
TL;DR

Fast jeder GEO-Ratgeber setzt eine rein englische Seite voraus. Meine ist keine — sie läuft in 13 Sprachen — und drei Dinge waren kaputt oder liefen schlechter, sobald ich über Englisch hinausschaute: die Korrektheit von hreflang/x-default, der Umfang von llms.txt und die Schema-Konsistenz zwischen Sprachen. Hier ist, was sich wirklich ändert, plus der Audit-Prompt, mit dem ich eine mehrsprachige Seite in einem Durchgang prüfe.

Kostenloser Newsletter

Jeden Mittwoch. 28.400+ Experten. Kein Füllstoff.

Veröffentlicht im September 2026.

TL;DR: Fast jeder GEO-Ratgeber setzt eine rein englische Seite voraus. Meine ist keine — sie läuft in 13 Sprachen — und drei Dinge waren kaputt oder liefen schlechter, sobald ich über Englisch hinausschaute: die Korrektheit von hreflang/x-default, der Umfang von llms.txt und die Schema-Konsistenz zwischen Sprachen. Hier ist, was sich wirklich ändert, plus der Audit-Prompt, mit dem ich eine mehrsprachige Seite in einem Durchgang prüfe.

[Betreiber-Perspektive] Jede GEO-Checkliste, die ich gelesen habe, meine eigenen eingeschlossen, wurde für eine einzige Sprache geschrieben. Mir ist erst aufgefallen, wie sehr dieser Rat Englisch voraussetzt, als ich nachgesehen habe, warum meine spanischen und japanischen Seiten nicht die gleiche Behandlung bekamen wie die englischen Originale — gleicher Inhalt, gleiche Schema-Vorlage, völlig unterschiedliche Ergebnisse.

Inhaltsverzeichnis

Inhaltsverzeichnis öffnen

Warum mehrsprachiges GEO nicht einfach SEO in 12 weiteren Sprachen ist

Klassisches internationales SEO hat ein etabliertes Playbook: hreflang-Tags, übersetzter Inhalt, fertig. GEO fügt eine Ebene hinzu, die dieses Playbook nicht abdeckt, denn eine KI-Engine indexiert deine Seite nicht nur — sie entscheidet, pro Anfrage und pro Sprache, welche einzige Quelle sie dem Nutzer zitiert. Diese Entscheidung läuft in jeder Sprache, die die Engine bedient, separat ab, gegen ein anderes Wettbewerberfeld, einen anderen Pool zitierwürdiger Quellen und manchmal eine komplett andere Engine.

Eine ChatGPT-Antwort auf Englisch schöpft aus einem anderen Kandidatenpool als dieselbe Frage auf Japanisch. Ignorierst du das, machst du die ganze GEO-Arbeit einmal, auf Englisch, und nimmst an, dass sie sich überträgt. Das tut sie nicht.

Was zuerst kaputtgeht: hreflang und x-default

Das ist der Punkt, der dich Sichtbarkeit kostet, ohne je als Fehler aufzutauchen. Zwei Ausfallmuster, beide lautlos:

  1. Fehlendes oder falsches x-default. Jeder hreflang-Cluster braucht einen x-default-Eintrag, der Engines und Crawlern sagt, welche Version jemandem angezeigt wird, dessen Sprache zu keiner deiner Übersetzungen passt. Lässt du ihn weg, sagst du jedem nicht gezielten Crawler: „rate mal.”
  2. hreflang, das auf Seiten zeigt, die keine echten Übersetzungen sind. Das ist heimtückischer und häufiger, als es klingt. Wenn dein Sprachumschalter für jede Sprache auf die Startseite verlinkt, sobald eine Übersetzung noch nicht existiert, und du diese Ausweichlinks mit hreflang versiehst, behauptest du, dass ein rein englischer Artikel seine eigene spanische Übersetzung ist. Ist er nicht. Googles Crawler vertraut irgendwann dem ganzen Cluster nicht mehr; eine KI-Engine, die ihren Zitationsgraphen aus deinen <link>-Tags baut, übernimmt dasselbe fehlerhafte Signal.

Genau diesen Bug hatte ich. Der Sprachumschalter meiner Kopfzeile hat hreflang bei jedem Sprachlink ausgegeben, auch bei denen, die mangels vorhandener Übersetzung auf die Startseite einer Sprache zurückfielen. Jeder rein englische Artikel behauptete lautlos, zwölf Übersetzungen zu haben, die er nicht hatte. Die Korrektur war mechanisch, sobald sie gefunden war: hreflang nur annotieren, wenn eine echte Übersetzung existiert, und immer x-default ausgeben — mit Rückfall auf die erste verfügbare Alternative, wenn ein Cluster kein englisches Mitglied hat —, damit jeder echte Cluster eines hat.

So sieht die Korrektur aus, wie sie tatsächlich im <head> der Seite gerendert wird:

html
<link rel="alternate" hreflang="es" href="https://example.com/es/post-slug/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/post-slug/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/post-slug/" />

Drei Regeln, die es sich lohnt, auf der eigenen Seite in dieser Reihenfolge zu prüfen: Jeder hreflang-Cluster hat genau ein x-default; kein hreflang-Link zeigt auf eine Seite, die keine echte Übersetzung ist; keine zwei <link>-Tags im selben Cluster teilen sich einen Code (Google verwirft sonst den ganzen Cluster, nicht nur das Duplikat).

Die Lücke, die niemand prüft: llms.txt deckt nur Englisch ab

llms.txt ist die aufkommende Konvention, um KI-Crawlern einen kuratierten Index deiner besten Inhalte zu geben, statt sie crawlen und raten zu lassen. Ich habe vor Monaten eines für diese Seite gebaut. Aufgefallen ist es mir erst, als ich für diesen Artikel nach Daten gesucht habe: Der Filter, der auswählt, welche Artikel in den Index kommen, prüft lang === 'en' und hört dort auf.

Das heißt, zwölf Dreizehntel des Inhalts dieser Seite sind für jeden Crawler unsichtbar, der llms.txt als Index behandelt und nicht nur als Vorschlag. Jeder nicht-englische Artikel wird weiterhin über die Sitemap und interne Links gecrawlt, aber der kuratierte, vertrauenswürdige Index — der speziell dafür gebaut wurde, einer KI-Engine deine besten Seiten zu geben — war nur durch Unterlassung Englisch-only, nicht durch Entscheidung.

Wenn du eine mehrsprachige llms.txt betreibst, prüfe jetzt Folgendes: Listet die Datei (oder die Dateien) tatsächlich deine übersetzten Artikel auf, oder kollabiert der Index lautlos auf deine Ausgangssprache, wie es bei meiner war? Eine einzelne gemeinsame llms.txt, die nur englische URLs listet, ist nicht falsch im eigentlichen Sinne — sie tut nur nichts für die anderen Sprachen, in denen deine Seite existiert.

Schema und Entitäts-Konsistenz über Sprachen hinweg

Das FAQPage-, Article- und Person-Schema, das du schon laufen hast (siehe meine Aufschlüsselung von Schema Markup, falls noch nicht eingerichtet), muss in jeder Sprache dasselbe über dich aussagen, weil KI-Engines aus all diesen Sprachen einen einzigen Entitätsgraphen bauen.

Zwei Dinge, die du richtig machen musst:

  • Bezeichner unübersetzt lassen, menschenlesbare Strings übersetzen. Das @id, url, das sameAs-Array und der jobTitle-Wert deines Person- oder Organization-Schemas müssen in jeder Sprache identisch sein — das sagt einer Engine „das ist dieselbe Entität” über Sprachen hinweg. Nur der umgebende Text und für Menschen lesbare Labels ändern sich.
  • Lass keine veraltete Übersetzung hinter dem Schema zurückbleiben. Aktualisierst du dateModified in deinem Article-Schema oder fügst einen neuen FAQ-Eintrag auf Englisch hinzu, muss dieselbe Änderung in jeder Sprache im JSON-LD ankommen, nicht nur im Text. Eine Engine, die englischen Inhalt sieht, der letzte Woche aktualisiert wurde, und eine französische Version derselben Seite mit sechs Monate altem Schema, liest das als zwei verschiedene Seiten, nicht als eine Seite in zwei Sprachen.

Andere Sprachen, andere KI-Engines

Das GEO-Gespräch geht standardmäßig von ChatGPT, Perplexity und Google AI Overviews aus, weil dort das englischsprachige Gespräch stattfindet. Das ist nicht das vollständige Bild, sobald du auf Russisch, Chinesisch oder Koreanisch publizierst.

Yandex betreibt eine eigene generative Antwortschicht für russischsprachige Anfragen und hat einen deutlich höheren Anteil an der russischen Suche als Google. Baidus ERNIE-basierte Antworten zählen für Chinesisch. Navers KI-Zusammenfassungen zählen für Koreanisch. Wenn deine GEO-Checkliste nur das US-zentrierte Engine-Trio berücksichtigt, optimierst du vielleicht für 60 % der Antwort-Engines, die deine internationalen Leser tatsächlich nutzen — und du merkst es nicht, weil keine dieser Engines in Google Search Console auftaucht.

Ich habe von hier aus keinen sauberen Weg, Zitierraten bei Yandex oder Baidu zu prüfen, und das sage ich offen, statt etwas anderes vorzugeben. Was ich sagen kann: Nimm nicht an, dass dieselbe Dreier-Engine-Liste, für die du Englisch optimierst, überall die vollständige Liste ist.

Der reale Beleg von meiner eigenen Seite

Das hier kann ich messen. Es ist derselbe GEO-gegen-SEO-Vergleichsartikel, dieselbe Inhaltsvorlage, dasselbe Schema, in jede Sprache übersetzt — Search-Console-Daten vom 15. Juni bis 11. September 2026:

SpracheImpressionenDurchschnittsposition
Spanisch2.07731,9
Niederländisch3.37046,6
Französisch1.39325,1
Japanisch10614,8
Koreanisch5724,9
Deutsch8660,6
Italienisch3267,8
Englisch56958,2

Gleicher Artikel, gleiche Struktur, gleiche Schema-Vorlage, und die Rangspanne reicht von Position 14,8 bis Position 67,8. Ich will ehrlich sagen, was das beweist und was nicht: Das sind klassische Google-Positionen aus Search Console, keine KI-Zitationsdaten — ich habe keine saubere Attribution der ChatGPT- oder Perplexity-Zitierungen pro Sprache, und ich kenne niemanden, der das schon hat. Was es beweist: „Übersetze es, und dieselbe Optimierungsarbeit wirkt überall gleich” ist auf meiner eigenen Seite falsch. Die japanische Übersetzung schlägt mit einem Bruchteil der Impressionen jede andere Sprache im Ranking, das englische Original eingeschlossen. Irgendetwas an dieser Seite — Wettbewerb, Übersetzungsqualität, wie die Entität auf Japanisch aufgelöst wird — funktioniert auf eine Weise, die auf Deutsch und Italienisch nicht funktioniert, bei identischer Schema-Vorlage in allen Fällen.

Sag Claude oder ChatGPT, dass es das macht: ein mehrsprachiger GEO-Audit-Prompt

Du musst keine hreflang-Spezifikationen lesen, um das zu prüfen. Füg das mit der URL deiner Seite in Claude oder ChatGPT ein:

Ich betreibe eine Website mit Inhalten in mehreren Sprachen. Prüfe für [URL]: (1) ob die Seite ein x-default-hreflang-Tag ausgibt und ob jedes hreflang-Tag auf der Seite auf eine echte Übersetzung statt auf eine Ausweich-Startseite zeigt; (2) ob das JSON-LD-Schema der Seite (Person, Organization oder Article) über die Sprachen hinweg identische Werte für @id, url und sameAs verwendet, oder ob sie sich je Sprache unterscheiden; (3) falls die Seite eine llms.txt-Datei hat, ob sie Seiten in anderen Sprachen als Englisch listet. Sag mir genau, welcher dieser Punkte fehlschlägt, und zitiere das konkrete Tag oder Feld, das falsch ist, statt einer allgemeinen Zusammenfassung.

Prüfe die Antwort gegen den tatsächlichen Quellcode der Seite, bevor du ihr traust — ein Modell beschreibt selbstsicher ein x-default-Tag, das nicht existiert, wenn du es nicht hinschauen lässt.

Was du weglassen solltest

Baue nicht dreizehn separate llms.txt-Dateien, ohne echte Belege — Server-Logs, die KI-Crawler-Zugriffe pro Subdomain zeigen, keine Vermutung —, dass Engines deine Sprachen als getrennte Properties behandeln. Eine einzige, gut abgegrenzte Datei, die deine übersetzten URLs tatsächlich auflistet, schließt die Lücke oben ohne den Wartungsaufwand von dreizehn Dateien.

Übersetze eine Seite nicht maschinell, nur um eine Sprache abzuhaken. Eine dünne, wörtliche Übersetzung ist für GEO schlechter als keine Übersetzung — sie gibt einer KI-Engine eine minderwertige Quelle, die sie gegen den muttersprachlichen Inhalt eines Konkurrenten abwägt, und ist der schnellste Weg, in einem Support-Forum als „die Seite mit den komischen Übersetzungen” zitiert zu werden.

Das Fazit

Wenn deine GEO-Checkliste für eine einzige Sprache geschrieben wurde, teste sie an deiner schwächsten Sprache, bevor du ihr als System vertraust. Meine hatte einen echten, lautlosen hreflang-Bug und einen Englisch-only-Zitationsindex, der monatelang unbemerkt blieb, bevor ich nachgesehen habe. Beides waren einfache Korrekturen. Keine wäre aufgefallen, hätte ich nicht mit einer zweiten Sprache im Kopf gesucht.

Mehrsprachiges GEO — FAQ

Beeinflusst hreflang wirklich KI-Zitierungen, oder nur das klassische Google-Ranking?

Beides, auch wenn der Mechanismus unterschiedlich ist. Beim klassischen Google sagt hreflang dem Crawler, welche URL für welche Sprache in den Suchergebnissen ausgespielt wird. Bei KI-Engines sind hreflang und dein Schema zusammen Teil davon, wie die Engine löst, ob „das dieselbe Entität/derselbe Inhalt über Sprachen hinweg” ist — machst du das falsch, riskierst du, dass die Engine deine englische und spanische Seite als unabhängige Quellen behandelt statt als ein Thema, das zweimal abgedeckt wird.

Muss ich jeden Artikel in jede Sprache übersetzen, die meine Seite unterstützt?

Nein. Übersetze Artikel dort, wo Thema und Suchnachfrage es in diesem Markt rechtfertigen — ein US-spezifischer Preisratgeber braucht vielleicht keine arabische Übersetzung, ein globaler GEO-Erklärartikel wahrscheinlich schon. Unübersetzte Beinahe-Duplikate über Sprachen hinweg sind schlimmer als weniger Artikel, die dafür vollständig übersetzt sind.

Wie erkenne ich, ob meine llms.txt richtig abgegrenzt ist?

Öffne die Datei und prüfe, ob die gelisteten URLs Pfade in einer anderen als der Ausgangssprache enthalten. Sind alle URLs in einer einzigen Sprache und deine Seite publiziert in mehreren, ist der Index auf diese eine Sprache beschränkt, ob beabsichtigt oder nicht.

Brauche ich für jede Sprache ein eigenes Schema, oder einen einzigen, überall wiederverwendeten Schema-Block?

Eine Entität, übersetzte Darstellung. Die identifizierenden Felder (@id, url, sameAs) bleiben über Sprachen hinweg identisch; der menschenlesbare Text (headline, description, FAQ-Antworten) wird je Sprache übersetzt. Behandle es als eine Entität, die in mehreren Sprachen beschrieben wird, nicht als mehrere Entitäten.

Weiterlesen: Schema Markup für GEO · Wie du einen Blogartikel mit einem einzigen Agenten in 13 Sprachen übersetzt · GEO für Solo-Betreiber


Willst du eine zweite Meinung zu deinem eigenen mehrsprachigen Setup? Melde dich — ich mache GEO-Audits für Seiten, die in mehr als einer Sprache publizieren, oder probier den Prompt oben selbst mit Claude, wenn du es heute prüfen willst.

Weiterlesen

Ähnliche Beiträge

Weiterlesen

Holen Sie sich das KI-Playbook in Ihr Postfach

Jeden Mittwoch. 28.400+ Experten. Kein Füllstoff.

↵ alle Ergebnisse anzeigen esc esc zum Schließen