Mehrsprachige KI-Sichtbarkeit: Locale-Signale richtig setzen

In eigenen Analysen sehen wir bei lokalen Unternehmen mit mehreren Sprachversionen ein wiederkehrendes Muster: Die deutsche Version taucht im Local Knowledge Panel auf, die englische Parallelseite für denselben Betrieb bleibt unsichtbar, obwohl beide auf dieselbe Adresse und dieselben Öffnungszeiten verweisen.

Definition: Mehrsprachige KI-Sichtbarkeit beschreibt, wie zuverlässig KI-Suchsysteme wie ChatGPT, Perplexity, Google AI Overviews und Claude ein lokales Unternehmen über mehrere Sprachversionen seiner Website hinweg als dieselbe Entität erkennen. Locale-Signale wie hreflang, das Schema.org-Attribut inLanguage und sprachspezifische Angaben im Google Business Profile liefern dafür die technische Grundlage. Ersatz für konsistente NAP-Daten (Name, Adresse, Telefonnummer) sind sie nicht.

hreflang als technisches Locale-Signal nutzen

Der erste Schritt ist rein technisch, aber grundlegend: Jede Sprachversion einer lokalen Landingpage braucht ein eigenes hreflang-Attribut, das auf alle anderen Sprachversionen derselben Seite verweist. Laut der Dokumentation von Google Search Central sollen hreflang-Annotationen genutzt werden, damit in den Suchergebnissen automatisch die passende Sprach- oder Regionalversion einer URL ausgespielt wird (https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites). Für ein lokales Unternehmen bedeutet das: /de/standort-berlin und /en/location-berlin müssen sich gegenseitig referenzieren, nicht nur die deutsche Version auf die englische verweisen.

Wichtig dabei: Der Verweis muss wechselseitig sein. Verlinkt nur die deutsche Seite auf die englische, aber nicht umgekehrt, gilt das Signal als unvollständig und wird ignoriert – beide Sprachversionen wirken dann technisch wie unabhängige, konkurrierende Seiten. Details zur korrekten Implementierung stehen im Beitrag Hreflang Tags für multilinguales KI-SEO: Internationale Websites in Generativen Modellen.

inLanguage-Schema für jede Sprachversion einzeln pflegen

Neben hreflang braucht jede Sprachversion ein eigenes, korrektes inLanguage-Attribut im strukturierten Markup. schema.org definiert mit der Property inLanguage das offizielle Format, um die Sprache eines Inhalts nach dem IETF-Standard BCP 47 auszuzeichnen, etwa als „de” oder „en-US” (https://schema.org/inLanguage). Für ein LocalBusiness-Schema heißt das: Die deutsche Seite trägt inLanguage: "de", die englische inLanguage: "en", auch wenn Adresse, Öffnungszeiten und Telefonnummer im restlichen Markup identisch bleiben.

Wichtig dabei: Das inLanguage-Feld muss für jede Sprachversion einzeln gesetzt und darf nicht unverändert aus einer anderen Version übernommen werden. Fehlt es oder ist es falsch gesetzt, behaupten zwei Seiten mit unterschiedlichem sichtbarem Text dieselbe Sprache – das erschwert die Zuordnung zur richtigen Sprachversion für ein Modell zusätzlich.

Google Business Profile ohne mehrsprachigen Firmennamen

Ein Fehler, der sich in der Praxis besonders hartnäckig hält: der Versuch, Mehrsprachigkeit direkt im Profilnamen unterzubringen. Laut den Richtlinien von Google Business Profile ist es untersagt, den Firmennamen wiederholt in mehreren Sprachen oder Schriftsystemen anzugeben, etwa nach dem Muster „Burger King バーガーキング” (https://support.google.com/business/answer/3038177). Daraus folgt: Sprachdifferenzierung gehört in die Beschreibung des Profils und in eigene Sprachversionen der verlinkten Website, nicht in den Namen selbst.

Typischer Stolperstein: Ein Betrieb trägt „Café Sonnenschein - Sunshine Café” als Profilnamen ein, in der Annahme, so in beiden Sprachen gefunden zu werden. Das verstößt gegen die Richtlinie und riskiert eine Beanstandung des Profils, ganz unabhängig davon, wie gut die Website selbst mehrsprachig aufgebaut ist. Mehr zur Optimierung des Profils insgesamt liefert Google Business Profile für KI optimieren: Lokal in AI Overviews ranken.

NAP-Konsistenz über alle Sprachversionen hinweg

Name, Adresse und Telefonnummer müssen über sämtliche Sprachversionen identisch bleiben, auch wenn sich Schreibweisen sprachbedingt anders anfühlen. Als Grundregel gilt: Je mehr Varianten derselben Adresse im Umlauf sind, desto größer der Interpretationsspielraum für ein System, das die Entität zusammenführen soll.

Element	Deutsche Schreibweise	Englische Schreibweise	Risiko ohne Abgleich
Straße	Musterstraße 12	Musterstrasse 12 / Muster St. 12	Zwei Adressvarianten wirken wie zwei Standorte
Telefonnummer	0395 5553304	+49 395 5553304	Fehlende Landesvorwahl erschwert die Zuordnung
Öffnungszeiten	Mo-Fr 9-18 Uhr	Mon-Fri 9am-6pm	Unterschiedliche Zeitformate ohne einheitliches Schema-Markup

Wichtig dabei: Je mehr Sprachversionen dazukommen, desto größer das Risiko, dass sich beim manuellen Pflegen von Adresse, Telefonnummer und Öffnungszeiten in jeder Fußzeile kleine Abweichungen einschleichen. Aus unserer Sicht lohnt sich deshalb eine zentrale Quelle für diese Angaben, aus der alle Sprachversionen automatisch übernehmen, statt sie einzeln von Hand zu pflegen.

Sprachspezifische Modellschwächen einplanen und Local Knowledge Panel je Sprache testen

Locale-Signale sind nur die halbe Miete, wenn die zugrunde liegenden Sprachmodelle selbst je nach Sprache unterschiedlich leistungsfähig sind. Anthropics eigene Benchmark-Tabelle zum MMLU-Test in 14 Sprachen zeigt, dass Claude bei ressourcenarmen Sprachen deutlich hinter der englischen Baseline (100 Prozent) zurückfällt: Sonnet 4.5 erreicht bei Swahili noch 91,1 Prozent, Haiku 4.5 nur 78,3 Prozent; bei Yoruba fallen die Werte auf 79,7 beziehungsweise 52,7 Prozent (https://platform.claude.com/docs/en/build-with-claude/multilingual-support). Im vergleichbaren Benchmark von OpenAI über 14 Sprachen zeigt sich beim Modell o3-high ein ähnliches Muster: Spanisch als eine der ressourcenreicheren Sprachen schneidet deutlich besser ab als ressourcenarme Sprachen wie Yoruba (https://github.com/openai/simple-evals/blob/main/multilingual_mmlu_benchmark_results.md).

Eine Studie von Songbo Hu, Ivan Vulić und Anna Korhonen (EMNLP 2025) untersucht anhand von 13 Modellvarianten und 11 mehrsprachigen Datensätzen, ob eine bessere Gesamtleistung eines mehrsprachigen Sprachmodells auch mit größerer Fairness zwischen Sprachen einhergeht, und findet: Die Lücke bei ressourcenarmen Sprachen bleibt trotz allgemeiner Modellverbesserungen bestehen (https://aclanthology.org/2025.emnlp-main.199/). Diese Zahlen stammen aus allgemeinen Sprachfähigkeits-Benchmarks und beziehen sich nicht auf lokale Unternehmenssuche im Speziellen. Die dokumentierten Kapazitätsunterschiede zwischen Sprachen sind real.

Typischer Stolperstein: Ein Betrieb testet seine KI-Sichtbarkeit nur in der eigenen Hauptsprache und schließt aus einem guten Ergebnis dort automatisch auf gleich gute Sichtbarkeit in jeder weiteren Sprachversion. Sinnvoller ist, das Local Knowledge Panel und typische Nutzeranfragen in jeder relevanten Sprache einzeln zu prüfen, etwa mit dem Knowledge Panel optimieren: So wird deine Marke von KI erkannt beschriebenen Vorgehen.

Häufig gestellte Fragen

Was sind Locale-Signale in der KI-Suche? Locale-Signale sind technische und inhaltliche Angaben, die einem KI-System zeigen, welche Sprache und Region eine Seite bedient. Dazu zählen hreflang-Attribute, das Schema.org-Attribut inLanguage und sprachspezifische Angaben im Google Business Profile. Sie sagen einem Modell, welche Version einer Seite zu welcher Sprachanfrage passt.

Muss ich für jede Sprachversion ein eigenes Google Business Profile anlegen? Nein, ein Standort erhält ein Profil. Da der Firmenname laut Google Business Profile nicht mehrsprachig dupliziert werden darf, gehört die Sprachdifferenzierung in die Beschreibung des Profils und in die verlinkten Sprachversionen der Website.

Erkennen KI-Modelle lokale Unternehmen in jeder Sprache gleich gut? Nein, nicht gleich gut. Anthropics MMLU-Benchmark in 14 Sprachen zeigt für Claude bei Swahili noch rund 91 beziehungsweise 78 Prozent der englischen Baseline, bei Yoruba fällt der Wert auf rund 80 beziehungsweise 53 Prozent; der vergleichbare Benchmark von OpenAI zeigt bei ressourcenarmen Sprachen ein ähnliches Muster. Ob sich das direkt auf die Qualität lokaler Sucheinträge überträgt, ist in den von mir geprüften Quellen nicht abschließend belegt.

Wie prüfe ich, ob meine mehrsprachige Website korrekt ausgezeichnet ist? Die vollständige Regelliste ist für registrierte Nutzer auf geaio.de/erklaert einsehbar, ebenso wie die Historie früherer Analysen.