Strukturierte Daten international: Schema.org über Sprachgrenzen

Einführung in strukturierte Daten für mehrsprachige Websites

Strukturierte Daten nach Schema.org helfen Suchmaschinen, den Inhalt Ihrer Website zu verstehen – und das über Sprachgrenzen hinweg. Wenn Sie mehrere Sprachversionen betreiben, wird die korrekte Auszeichnung umso wichtiger. Suchmaschinen wie Google nutzen strukturierte Daten, um Rich Results wie Snippets, Produktpreise oder FAQ-Elemente anzuzeigen. Bei mehrsprachigen Seiten müssen diese Auszeichnungen sprachspezifisch sein, sonst können falsche Informationen ausgeliefert werden – etwa eine Telefonnummer aus der deutschen Seite in der französischen Version.

Ein typischer Fehler: Man übernimmt das Schema einer Sprache einfach in andere Versionen, ohne die Sprachangaben anzupassen. Dabei reicht es nicht, nur die Inhalte zu übersetzen; auch die Struktur muss die Zielsprache widerspiegeln. Beispielsweise sollte das inLanguage-Feld des Schema-Objekts die Sprache der jeweiligen Seite angeben. Ein deutscher Produktseite erhält `inLanguage: 'de'`, die englische `inLanguage: 'en'`. Zusätzlich können Sie mit `translationOfWork` auf die Originalversion verweisen.

Praktisch beginnen Sie mit den wichtigsten Seitentypen: Organisation, Produkt, FAQ. Diese werden am häufigsten für Rich Results genutzt. Prüfen Sie vorab, welche Seiten in welcher Sprache besonders relevant sind. Für eine internationale Unternehmensseite bietet sich das Organization-Schema an, für einen Onlineshop das Product-Schema. Achten Sie darauf, dass jede Sprachversion ein eigenes JSON-LD-Skript oder separate Einträge im Skript erhält. Verwenden Sie Tools wie den Google Rich Results Test, um jede Sprachversion einzeln zu validieren. Beachten Sie dabei, dass der Test nur eine Momentaufnahme liefert – eine regelmäßige Überprüfung ist empfehlenswert.

Rechtlich ist zu beachten, dass strukturierte Daten keine personenbezogenen Daten enthalten dürfen, die gegen die DSGVO verstoßen. Bei der Angabe von Kontaktdaten in verschiedenen Ländern sollten Sie sicherstellen, dass die Daten korrekt und aktuell sind. Lassen Sie sich bei Zweifeln von einem Rechtsberater unterstützen. Durch die saubere Implementierung mehrsprachiger strukturierter Daten verbessern Sie die Chancen, in den verschiedenen Sprachregionen mit relevanten Rich Results gefunden zu werden.

Grundlagen von Schema.org und Sprachauszeichnung

Schema.org bietet eine gemeinsame Vokabularstruktur, die von Suchmaschinen unterstützt wird. Für mehrsprachige Websites ist die korrekte Sprachauszeichnung zentral. Jedes Schema-Objekt kann eine `inLanguage`-Eigenschaft besitzen, die die Sprache des Inhalts angibt (z. B. `'de'`, `'en'`, `'fr'`). Diese Angabe sollte mit der tatsächlichen Sprache der Seite übereinstimmen. In JSON-LD setzen Sie `@language` entweder auf dem gesamten Dokument oder auf einzelnen Objekten, wenn mehrere Sprachen vorkommen.

Ein Beispiel: Für ein Produkt in deutscher Sprache nutzen Sie: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Wenn Sie dasselbe Produkt auf einer englischen Seite auszeichnen, steht stattdessen `"inLanguage": "en"` und der Name auf Englisch. Vermeiden Sie es, mehrere Sprachversionen in einem einzigen Schema-Objekt zu mischen – das führt zu Inkonsistenzen. Stattdessen verwenden Sie separate Markup-Blöcke pro Sprache oder arbeiten mit `@language`-Arrays innerhalb eines Objekts, falls die Entität mehrsprachig ist.

Für Website-spezifische Angaben wie `WebSite` oder `WebPage` sollten Sie ebenfalls die Sprache angeben. Bei einer Sprachumschaltung auf der Seite können Sie mit `potentialAction` oder `translationOfWork` auf die anderen Sprachversionen verweisen. In der Praxis hat es sich bewährt, für jede Sprache einen eigenen JSON-LD-Block im entsprechenden Seiten-Head zu platzieren. So bleibt die Zuordnung eindeutig und wird von Validierungstools korrekt interpretiert.

Achten Sie darauf, dass die Sprachcodes den ISO-639-1-Standard nutzen (z. B. „de“ für Deutsch, „en“ für Englisch). Für regionale Varianten können Sie Länderkürzel anhängen, also „de-CH“ für Schweizer Deutsch. Dabei müssen Sie prüfen, ob die Suchmaschine diese Feinunterscheidung unterstützt – in der Regel genügt der Basis-Sprachcode. Validieren Sie jede Sprachversion einzeln mit dem Google Structured Data Testing Tool oder dem Rich Results Test. Notieren Sie sich mögliche Warnungen zu fehlenden Sprachangaben und beheben Sie diese gezielt.

Organization-Schema: Unternehmensangaben in mehreren Sprachen

Das Organization-Schema ist ideal für Unternehmen mit mehrsprachigen Websites, da es zentrale Informationen wie Name, Adresse und Kontaktdaten bereitstellt. Für jede Sprachversion sollten Sie ein eigenes Organization-Objekt erstellen, das in der entsprechenden Sprache ausgezeichnet ist. Der `name` sollte in der Zielsprache angegeben werden – also „Muster GmbH“ auf Deutsch und „Sample Inc.“ auf Englisch. Wenn das Unternehmen einen einheitlichen Namen hat, reicht die Übersetzung der Beschreibung (`description`).

Bei Adressen verwenden Sie das `PostalAddress`-Schema mit `addressCountry` und `addressLocality`. Für internationale Standorte können Sie mehrere `location`-Einträge vorsehen. Achten Sie darauf, dass Telefonnummern (`telephone`) mit der korrekten Ländervorwahl versehen sind. Beispiel: Für die deutsche Seite `+49 30 1234567`, für die Schweizer Seite `+41 44 1234567`. Gleiches gilt für E-Mail-Adressen und Öffnungszeiten. Verwenden Sie `areaServed`, um abzudecken, in welchen Ländern das Unternehmen tätig ist.

Ein häufig übersehenes Detail ist die `sameAs`-Eigenschaft für Social-Media-Profile. Hinterlegen Sie sprachspezifische Profile, wenn vorhanden – etwa die deutsche Facebook-Seite und die englische Twitter-Präsenz. Auch die `url` sollte auf die sprachspezifische Startseite verweisen. Bei mehrsprachigen Websites können Sie mit `translationOfWork` einen Zusammenhang zwischen den Sprachversionen herstellen, sofern die Seiten denselben Inhalt in anderer Sprache abbilden.

Praktische Empfehlung: Implementieren Sie das Organization-Schema auf der Startseite jeder Sprachversion. Hinterlegen Sie dazu ein JSON-LD-Skript im `<head>`. Vermeiden Sie Duplikate, indem Sie für jede Sprache einen eigenen Block mit passendem `inLanguage` erstellen. Validieren Sie die Auszeichnung mit dem Google Rich Results Test und prüfen Sie, ob die Kontaktdaten korrekt dargestellt werden. Rechtlich müssen Sie beachten, dass die angegebenen Informationen vollständig und datenschutzkonform sind. Besonders bei mehreren Standorten: Die Impressumspflicht kann sich je nach Land unterscheiden. Holen Sie im Zweifel rechtlichen Rat ein. Durch diese Details stellen Sie sicher, dass Ihr Unternehmen in allen Sprachregionen einheitlich und korrekt repräsentiert wird.

Product-Schema: Produktbeschreibungen sprachspezifisch auszeichnen

Für mehrsprachige Websites ist die Auszeichnung von Produkten mit Schema.org Product in der jeweiligen Sprache essenziell. Jede Sprachversion eines Produkts sollte eine eigene Schema-Markierung erhalten, die den lokalen Namen, die Beschreibung und Attribute wie Preis, Währung oder Verfügbarkeit enthält. Dabei verwenden Sie das Attribut `inLanguage` pro Sprache – z. B. `"inLanguage": "de-DE"` für Deutsch (Deutschland). Achten Sie darauf, dass der Produktname und die Beschreibung im JSON-LD-Objekt tatsächlich auf Deutsch stehen, nicht nur das Sprach-Tag.

Ein häufiger Fehler ist die Auszeichnung aller Sprachvarianten mit derselben `@id` (z. B. einer globalen Produkt-ID). Stattdessen sollten Sie für jede Sprache eine eigene `@id` vergeben, etwa `https://example.com/de/produkt/123` und `https://example.com/fr/produit/123`. So kann Google die richtige Version ausspielen. Bei Preisen nutzen Sie `priceCurrency` mit ISO-4217-Code (z. B. EUR, USD) und geben Sie den Preis sprachspezifisch an – auch wenn der Preis gleich bleibt, gehört er zur lokalen Seite.

Praktische Empfehlung: Erstellen Sie für jedes Produkt eine JSON-LD-Vorlage, die dynamisch die Sprachparameter setzt. Prüfen Sie jede Sprachversion einzeln mit dem Rich Results Test von Google. Achten Sie darauf, dass das `url`-Attribut auf die jeweilige Sprach-URL zeigt. Vermeiden Sie es, alle Sprachen in einem einzigen JSON-LD-Block zu mischen – dies führt oft zu Validierungsfehlern. Für Bilder können Sie das `image`-Attribut sprachunabhängig halten, aber stellen Sie sicher, dass die Bild-URLs korrekt sind.

Zusätzlich können Sie `offers` mit `availability` je nach Markt anpassen (z. B. `InStock` für Deutschland, `PreOrder` für Frankreich). Nutzen Sie `gtin` oder `mpn` global, aber behalten Sie bei `sku` lokale Varianten. Testen Sie abschließend, ob die strukturierten Daten in der Search Console für jede Sprachversion korrekt indexiert werden.

FAQ-Schema: Frage-und-Antwort-Seiten mehrsprachig optimieren

FAQ-Seiten in mehreren Sprachen profitieren von einer klaren, sprachspezifischen Auszeichnung mit dem Schema FAQPage. Jede Sprachversion der FAQ-Seite erhält ein eigenes JSON-LD-Objekt. Setzen Sie `inLanguage` auf den entsprechenden Sprachcode (z. B. `fr-FR` für Französisch). Die Fragen und Antworten müssen im Objekt in der Zielsprache formuliert sein – eine maschinelle Übersetzung reicht oft nicht aus; lassen Sie sie von einem Muttersprachler prüfen, da Nuancen entscheidend sind.

Ein typischer Fehler: Dieselbe `@id` für alle Sprachvarianten. Verwenden Sie stattdessen die sprachspezifische URL als `@id`, z. B. `https://example.com/de/faq/` und `https://example.com/en/faq/`. Innerhalb des FAQPage-Schemas listen Sie die Fragen als `mainEntity` mit `@type: Question` und zugehörige Antwort als `acceptedAnswer`. Jede Frage kann zusätzlich `inLanguage` erhalten, was aber redundant ist, wenn die gesamte Seite markiert ist. Halten Sie die Anzahl der Fragen pro Seite auf maximal 10–15, da Suchmaschinen nur begrenzte Einträge berücksichtigen.

Handlungsempfehlung: Nutzen Sie ein Content-Management-System, das pro FAQ-Eintrag ein Mehrsprachigkeitsfeld bietet. In der JSON-LD-Ausgabe fragen Sie dynamisch die aktuelle Sprache ab. Validieren Sie jede Sprachversion einzeln mit dem Rich Results Test und achten Sie auf Warnungen zu fehlenden `name`-Eigenschaften bei den Fragen. Fügen Sie bei jeder Frage eine `url` hinzu, die auf den konkreten Anker verweist – so können Nutzer direkt zur passenden Antwort springen.

Beachten Sie: FAQPage eignet sich nur für Seiten mit expliziten Fragen und Antworten. Verwenden Sie es nicht für allgemeine Support-Seiten. Testen Sie nach dem Deployment die Sichtbarkeit in der Google Suche – FAQ-Rich-Snippets erscheinen oft bei Suchanfragen mit Fragepartikeln. Für mehrsprachige SEO lohnt es sich, die Antworten auf landestypische Formulierungen anzupassen (z. B. „Wie kann ich?“ vs. „Comment puis-je?“).

Die Feinheiten von inLanguage: Sprachcode und Gebietsschema

Das Attribut `inLanguage` in Schema.org gibt die Sprache eines Inhalts an, wobei der Wert idealerweise aus einem Sprachcode (ISO 639-1) und einem optionalen Regionscode (ISO 3166-1 Alpha-2) besteht – z. B. `en-US` für amerikanisches Englisch. Die Region ist wichtig, wenn sich Inhalte unterscheiden: „colour“ vs. „color“ oder unterschiedliche Maßeinheiten. Ohne Region wird der Code als allgemeine Sprache interpretiert. Verwenden Sie also `de-DE`, `de-AT`, `de-CH` für länderspezifische Seiten, auch wenn der Text fast identisch ist.

Ein Praxisbeispiel: Ein Produkt wird auf einer deutschen und einer österreichischen Seite angeboten. Die Sprache ist Deutsch, aber die Preise und Versandbedingungen unterscheiden sich. Setzen Sie `inLanguage: "de-DE"` für die deutsche und `"de-AT"` für die österreichische Seite. So kann Google die regionale Relevanz besser verstehen. Gleiches gilt für `en-GB` und `en-US`. Falls Sie keine regionale Unterscheidung benötigen, reicht `"de"` oder `"en"`. Achten Sie jedoch darauf, dass der Sprachcode immer in Kleinbuchstaben und die Region in Großbuchstaben geschrieben wird (z. B. `fr-CA`).

Ein häufiger Fehler ist die Verwendung von `inLanguage` auf einem übergeordneten Objekt, während Unterobjekte eine andere Sprache haben. Beispiel: Eine WebSite in Deutsch, aber ein einzelner Artikel auf Englisch. Dann setzen Sie `inLanguage: "de"` auf der WebSite und `inLanguage: "en"` auf dem Article. Validieren Sie dies mit einem Schema-Validator, da manche Tools Konflikte melden. Für mehrsprachige Seiten mit hreflang-Tags sollte `inLanguage` mit dem jeweiligen hreflang-Wert korrespondieren – das hilft Google, die korrekte Version auszuliefern.

Praktische Umsetzung: Definieren Sie pro Sprachversion einen eindeutigen `@id` und setzen Sie `inLanguage` konsistent. Nutzen Sie eine zentrale Konfigurationsdatei, die für jede Sprache die korrekten Codes enthält. Testen Sie mit dem Tool von schema.org, ob das `inLanguage`-Tag akzeptiert wird. Ein Tipp: Auch bei AMP-Seiten oder strukturierten Daten per Microdata sollten Sie `inLanguage` nicht vergessen. Bei JSON-LD platzieren Sie es auf der obersten Ebene (z. B. `WebSite` oder `WebPage`). Für dynamische Inhalte wie Blog-Artikel kann `inLanguage` je nach Beitrag variieren – dann setzen Sie es pro Item.

Mehrsprachigkeit auf einer einzelnen URL korrekt auszeichnen

Wenn eine URL Inhalte in mehreren Sprachen enthält – etwa über Sprachwechsler, Tabs oder Accordions –, müssen Sie in den strukturierten Daten klar kennzeichnen, welcher Text zu welcher Sprache gehört. Andernfalls kann ein Suchmaschinen-Crawler fälschlich annehmen, dass alle Inhalte in einer Sprache vorliegen, was zu Fehlern bei der Indexierung und Darstellung führt.

Die grundlegende Methode ist die Verwendung des `inLanguage`-Attributs auf den entsprechenden Elementen. Bei einem FAQ-Schema mit Fragen und Antworten in Deutsch und Englisch auf derselben Seite zeichnen Sie jede Frage und Antwort einzeln aus: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Entsprechendes gilt für Product-Schemata: Beschreiben Sie `name` und `description` je Sprache in einem eigenen `Product`-Objekt mit separatem `inLanguage`, oder nutzen Sie `@language` und `@value` in einer `multilingualDescription`-Eigenschaft (falls Ihr Vokabular dies unterstützt).

Für Organisationen mit mehrsprachigen Namen verwenden Sie ein Array von `name`-Objekten: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Vermeiden Sie es, die gesamte Seite als mehrsprachig zu deklarieren. Stattdessen sollten Sie die Sprachzuweisung so granular wie möglich vornehmen. Ein gängiger Fehler ist, `inLanguage` nur auf der obersten Ebene eines Schemas zu setzen, ohne die untergeordneten Elemente zu kennzeichnen. Prüfen Sie daher in Ihrem Validierungs-Workflow, ob alle Texte korrekt sprachlich ausgezeichnet sind.

Als konkrete Handlungsempfehlung: Erstellen Sie für jede Sprachvariante auf einer URL ein separates Schema-Objekt, das nur die Texte dieser Sprache enthält, und setzen Sie `inLanguage` auf den entsprechenden Sprachcode. Falls die Seite standardmäßig eine Hauptsprache anzeigt, die anderen aber per JavaScript laden, hinterlegen Sie die strukturierten Daten für alle Sprachen statisch im HTML. Tools wie der Google Rich Results Test zeigen Ihnen, ob die Auszeichnung korrekt interpretiert wird. Testen Sie jede Sprachversion einzeln, indem Sie den Crawler über eine URL-Parameter- oder Cookie-Steuerung auf die gewünschte Sprache zwingen.

Abgrenzung von hreflang und inLanguage: Wann welche Methode?

`hreflang` und `inLanguage` erfüllen unterschiedliche Zwecke in der internationalen SEO und sollten nicht verwechselt werden. `hreflang` ist ein HTML-Element oder HTTP-Header, das Suchmaschinen signalisiert, dass es alternative Sprach- oder Regionsversionen derselben Seite gibt. Es dient der richtigen Auslieferung der passenden Seite für Nutzer in verschiedenen Ländern oder mit bestimmten Spracheinstellungen. `inLanguage` hingegen ist ein Attribut in strukturierten Daten (Schema.org), das die Sprache angibt, in der ein bestimmtes Textelement verfasst ist.

Wann setzen Sie was ein? Verwenden Sie `hreflang`, wenn Sie separate URLs für verschiedene Sprachversionen haben (z. B. `example.com/de/` und `example.com/en/`). Damit verhindern Sie Duplicate-Content-Probleme und stellen sicher, dass die richtige Seite im Snippet erscheint. `inLanguage` ist notwendig, wenn Sie auf einer einzigen URL mehrsprachige Inhalte auszeichnen oder wenn ein strukturiertes Datenelement wie eine Produktbeschreibung in mehreren Sprachen vorliegt. `inLanguage` ergänzt `hreflang` also auf der Ebene einzelner Textblöcke.

Ein häufiges Missverständnis: `inLanguage` ersetzt nicht `hreflang`. Selbst wenn Sie jede Zeile eines Artikels mit `inLanguage` auszeichnen, wissen Suchmaschinen ohne `hreflang` nicht, ob es alternative Versionen der gesamten Seite gibt. Umgekehrt reicht `hreflang` nicht aus, um mehrsprachige Inhalte innerhalb einer URL feingranular zu beschreiben. In der Praxis bedeutet das: Haben Sie separate Seiten für jede Sprache, ist `hreflang` primär erforderlich, während `inLanguage` nur in den strukturierten Daten auf diesen Seiten die konkrete Sprache des Inhalts angibt. Liegen mehrere Sprachen auf einer URL, benötigen Sie zwingend `inLanguage` für jedes sprachspezifische Element.

Konkrete Empfehlung: Planen Sie Ihre URL-Strategie vor der Implementierung. Entscheiden Sie, ob Sie pro Sprache eine eigene URL (ccTLD, Subdomain, Unterverzeichnis) oder eine gemeinsame URL mit dynamischem Sprachwechsel nutzen. Für letzteres ist eine korrekte `inLanguage`-Auszeichnung unerlässlich. Prüfen Sie in jedem Fall, ob Ihre `hreflang`-Tags auf alle relevanten Sprachversionen verweisen und keine Widersprüche zu den `inLanguage`-Angaben in den strukturierten Daten bestehen. Ein Abgleich dieser beiden Signale kann Suchmaschinen dabei helfen, Ihre Inhalte richtig zuzuordnen.

Validierungs-Workflow: Tools und automatisierte Prüfungen

Die manuelle Prüfung strukturierter Daten auf jeder Sprachversion ist fehleranfällig und zeitaufwändig. Ein automatisierter Validierungs-Workflow stellt sicher, dass Ihre Schema.org-Auszeichnungen korrekt sind und bleiben – auch nach Content-Updates oder beim Hinzufügen neuer Sprachen. Die wichtigsten Tools sind der Google Rich Results Test (für von Google unterstützte Typen wie FAQ, Product) und der Schema.org Validator (für die reine Syntaxprüfung). Ergänzend helfen Crawler wie Screaming Frog SEO Spider, strukturierte Daten auf Ihrer gesamten Website zu extrahieren und auf Fehler zu prüfen.

Bauen Sie die Prüfung in Ihren CI/CD-Prozess ein: Nach jedem Deployment oder Sprachupdate lassen Sie einen automatisierten Testlauf durchführen. Verwenden Sie dazu die API des Google Rich Results Tests oder ein Skript, das Ihre Seiten parst und die JSON-LD-Blöcke gegen ein selbst definiertes Schema prüft. Achten Sie besonders auf folgende Fehlerquellen: - Fehlendes `inLanguage` an Stellen, wo mehrere Sprachen vorkommen. - Widersprüchliche Sprachcodes (z. B. „de“ statt „de-DE“ bei regionsspezifischen Varianten). - Unvollständige Pflichtfelder (z. B. `name` bei Product in jeder Sprache). - Veraltete `hreflang`-Tags, die nicht mehr zu Ihren aktuellen URLs passen.

Konkrete Handlungsempfehlung: Legen Sie für jede Schema-Art (Organization, Product, FAQ) eine Checkliste mit den erforderlichen Attributen je Sprache an. Nutzen Sie ein Test-Tool wie `json-schema` zur automatischen Validierung Ihrer Daten. Führen Sie zudem regelmäßig (z. B. monatlich) einen vollständigen Crawl mit dem Schema.org-Validator durch und lassen Sie sich Reports über fehlerhafte Seiten generieren. Dokumentieren Sie die Fehlerkategorien und weisen Sie Verantwortliche für Korrekturen zu. Beachten Sie, dass die strukturierten Daten auf den Live-Seiten geprüft werden müssen – ein Test im Staging reicht nicht, da dort möglicherweise andere Inhalte liegen. Nur so stellen Sie sicher, dass suchmaschinenrelevante Fehler zeitnah behoben werden.

Häufige Fehler bei internationalen strukturierten Daten

Die Auszeichnung mehrsprachiger Websites mit Schema.org birgt typische Fallstricke. Ein häufiger Fehler ist das Fehlen oder die inkorrekte Angabe des Sprachattributs `inLanguage`. Wenn Sie beispielsweise ein Produkt auf Deutsch anbieten, aber im Markup kein `inLanguage: "de-DE"` setzen, interpretieren Suchmaschinen die Daten möglicherweise als sprachneutral. Ein weiterer grundlegender Fehler ist die Vermischung von Sprachen innerhalb eines einzigen Schema-Blocks. So sollten Sie vermeiden, in einem `Product`-Objekt die `name`-Eigenschaft auf Englisch und die `description` auf Deutsch zu setzen. Stattdessen ist für jede Sprachversion ein separater Block mit korrektem `inLanguage` zu erstellen.

Ein ebenfalls verbreiteter Fehler ist die Verwendung unpassender Schema-Typen. Für ein mehrsprachiges Unternehmen greifen viele fälschlich zu `LocalBusiness`, obwohl `Organization` die richtige Wahl ist, wenn keine physische Adresse in jeder Sprache vorliegt. Auch bei Produkten wird oft vergessen, die `offers`-Eigenschaft sprachspezifisch auszuzeichnen. Hinzu kommt die unterlassene Aktualisierung der strukturierten Daten nach Übersetzungen: Ein neu übersetzter Produkttext muss auch im Markup angepasst werden – andernfalls zeigen Suchergebnisse veraltete oder falsche Informationen.

Die Vernachlässigung der Validierung ist ein weiterer Kardinalfehler. Nach jeder Änderung sollten Sie die Markups mit geeigneten Tools prüfen. Fehlerhafte oder fehlende `@id`-Referenzen bei Entitäten, die sprachübergreifend gleich sind (z. B. eine Organisation), führen zu Duplikaten oder unvollständigen Daten. Zudem wird oft das Zusammenspiel mit `hreflang` ignoriert: Wo keine Alternativ-URLs existieren, müssen Sie mit `inLanguage` auf derselben Seite arbeiten.

Handlungsempfehlungen: Prüfen Sie jedes Markup auf korrekte Sprachzuweisung. Nutzen Sie für jede Sprachversion separate Schema-Blöcke mit eindeutigen `@id`s. Verzichten Sie auf Vermischungen – auch in `aggregateRating` oder `review` muss die Sprache stimmen. Führen Sie nach jeder Übersetzung eine erneute Validierung durch und gleichen Sie die Daten mit den sichtbaren Inhalten ab. Nur so stellen Sie sicher, dass Suchmaschinen Ihre mehrsprachigen Angebote richtig verstehen.

Test mit Google Rich Results, Bing Webmaster Tools und Yandex

Die Überprüfung mehrsprachiger Schema.org-Markups sollte nicht auf ein einzelnes Tool beschränkt sein. Jede Suchmaschine hat eigene Interpretationen und Validierungskriterien. Der Google Rich Results Test ist der erste Anlaufpunkt: Geben Sie eine URL mit Ihrem Markup ein oder fügen Sie den Code direkt ein. Achten Sie auf alle Fehler und Warnungen – insbesondere ob die `inLanguage`-Angaben korrekt erkannt werden. Ein häufiges Problem ist, dass Google `de-DE` akzeptiert, aber bei fehlendem Regionsteil (`de`) dennoch eine Warnung ausgibt. Testen Sie jede Sprachversion einzeln.

Bing Webmaster Tools bietet eine URL-Prüfung mit einer strukturierten Datenansicht. Hier können Sie sehen, ob Bing die Markups wie erwartet interpretiert. Bing ist oft strenger bei der Validierung von `inLanguage` und erwartet möglicherweise zwingend den zweistelligen Sprachcode ohne Region (z. B. `de` statt `de-DE`). Führen Sie einen Live-Test durch und korrigieren Sie Abweichungen. Bing zeigt außerdem mögliche Duplikate an, wenn `@id`-Werte mehrfach verwendet werden.

Yandex Webmaster hat einen eigenen Validator, der vor allem für russischsprachige Seiten relevant ist. Auch hier können Sie strukturierte Daten testen. Yandex unterstützt die meisten Schema.org-Typen, aber die Fehlerbehandlung unterscheidet sich. Insbesondere bei `Product`-Markups wird häufig die `availability`-Eigenschaft bemängelt. Testen Sie daher auch hier jede Sprachversion. Beachten Sie, dass Yandex regionale Sprachcodes wie `de-DE` anders gewichten kann.

Handlungsempfehlungen: Testen Sie jede Sprachversion in allen drei Tools nach der Implementierung und nach jeder Änderung. Notieren Sie sich Abweichungen und passen Sie die Markups so an, dass sie von allen drei Suchmaschinen akzeptiert werden. Verwenden Sie idealerweise den zweistelligen Sprachcode (`de`, `en`) im `inLanguage`, da er von den meisten Systemen gleichermaßen verstanden wird. Automatisieren Sie die Tests mit CI-Tools, um bei mehrsprachigen Websites mit vielen Seiten den Überblick zu behalten.

Checkliste für die Implementierung mehrsprachiger Schema.org-Markups

Eine strukturierte Vorgehensweise verhindert typische Fehler bei der Internationalisierung. Vor der Implementierung sollten Sie die Sprachstrategie festlegen: Nutzen Sie separate URLs pro Sprache (z. B. `/de/produkt` und `/en/product`) oder eine einzelne URL mit Sprachumschaltung? Für separate URLs verwenden Sie `hreflang` und pro URL ein eigenes Markup. Bei einer einzelnen URL setzen Sie mehrere `inLanguage`-Blöcke mit unterschiedlichen Sprachcodes. Planen Sie zudem, welche Schema-Typen benötigt werden: Unternehmen (Organization), Produkte (Product), FAQ (FAQPage) etc.

Bei der Umsetzung achten Sie auf folgende Punkte: Jedes Schema-Objekt erhält ein eindeutiges `@id`, das die Entität sprachunabhängig identifiziert. Für jede Sprachversion legen Sie ein separates Objekt an, das über `inLanguage` die Sprache angibt. Verwenden Sie konsistente Sprachcodes – vorzugsweise den zweistelligen ISO-Code (z. B. `de`, `en`) ergänzt um die Region, falls nötig. Verlinken Sie innerhalb der Markups korrekt: Bei `Organization` nutzen Sie `url` und `logo` mit sprachspezifischen Pfaden. Überprüfen Sie, ob Texte wie `name` und `description` mit den sichtbaren Inhalten übereinstimmen.

Nach der Implementierung folgt die Validierung: Testen Sie jede Sprachversion mit dem Google Rich Results Test, Bing Webmaster Tools und Yandex. Korrigieren Sie Fehler und Warnungen. Achten Sie besonders auf fehlende `inLanguage` oder falsche Sprachcodes. Nutzen Sie zusätzlich das Schema.org-Validierungstool von Google, um die Syntax zu prüfen. Dokumentieren Sie alle Änderungen und führen Sie nach jeder Übersetzung erneute Tests durch.

Abschließend gehört das Monitoring zum Prozess: Überwachen Sie die Leistung in der Search Console, insbesondere die Berichte zu strukturierten Daten. Reagieren Sie auf neue Fehler oder Abmahnungen. Aktualisieren Sie die Markups zeitnah, wenn Sie Inhalte ändern oder übersetzen. Führen Sie regelmäßige Audits durch, um die Konsistenz über alle Sprachversionen hinweg zu gewährleisten. Eine gut gepflegte Schema.org-Implementierung verbessert die Sichtbarkeit in den Suchergebnissen – ohne Garantien, aber mit praktischem Nutzen.

Rechtliche Hinweise: Eigenverantwortung bei automatischer Übersetzung

Die automatische Übersetzung von strukturierten Daten birgt rechtliche Risiken, die Sie als Betreiber einer mehrsprachigen Website eigenverantwortlich prüfen müssen. Insbesondere bei Schema.org-Markups, die rechtlich relevante Inhalte wie Produktsicherheitshinweise, AGB oder Markenbezeichnungen enthalten, kann eine ungenaue Übersetzung zu Haftungsfällen führen. Beispielsweise kann ein falsch übersetzter Produktname oder eine irreführende Produktbeschreibung gegen Wettbewerbsrecht verstoßen. Wir empfehlen daher, alle automatisch erstellten Übersetzungen von einer muttersprachlichen Fachkraft korrekturlesen zu lassen. Dies gilt vor allem für Felder wie „description“ im Product-Schema oder „answer“ im FAQ-Schema, wo Nuancen entscheidend sind.

Neben der inhaltlichen Korrektheit spielen auch datenschutzrechtliche Aspekte eine Rolle: Wenn Ihr Schema personenbezogene Daten enthält (z. B. Kundenbewertungen im Review-Schema), müssen Sie sicherstellen, dass die Übersetzung DSGVO-konform erfolgt. Automatische Übersetzungsdienste sollten nur dann eingesetzt werden, wenn der Dienst ausreichende Datenschutzgarantien bietet. Ein generelles Verbot gibt es nicht, aber die Verantwortung für die Datenverarbeitung liegt bei Ihnen als Website-Betreiber. Lassen Sie sich von einem Rechtsberater zu den spezifischen Anforderungen in Ihren Zielländern beraten.

Ein weiterer rechtlicher Fallstrick: Die Verwendung von „inLanguage“ mit unzulässigen Sprachcodes. Verwenden Sie stets die offiziellen BCP-47-Codes (z. B. „de-DE“ statt „deutsch“). Fehlerhafte Codes können dazu führen, dass Ihre Markups von Suchmaschinen ignoriert werden – was zwar kein rechtliches Problem darstellt, aber die Auffindbarkeit beeinträchtigt. Führen Sie daher vor dem Livegang eine Validierung mit Tools wie dem Google Rich Results Test durch, und prüfen Sie ergänzend, ob die Übersetzungen alle rechtlich relevanten Felder korrekt abdecken.

Handlungsempfehlung: Definieren Sie einen Workflow, bei dem jede automatisch übersetzte Schema-Auszeichnung von einem muttersprachlichen Redakteur oder Juristen gegengeprüft wird. Dokumentieren Sie diesen Prozess, um im Streitfall nachweisen zu können, dass Sie Ihrer Sorgfaltspflicht nachgekommen sind. Verzichten Sie auf automatische Übersetzung von Textblöcken mit Rechtscharakter (z. B. Garantiebedingungen, Haftungsausschlüsse); übersetzen Sie diese manuell oder durch einen Fachdienst.

Ausblick: KI-gestützte Lokalisierung und zukünftige Schema-Entwicklungen

Die Lokalisierung von Schema.org-Markups wird zunehmend durch KI-gestützte Tools erleichtert. Aktuelle Systeme können auf Basis neuronaler Netze Übersetzungen erstellen, die kontextuell präziser sind als ältere statistische Verfahren. Für mehrsprachige Websites bedeutet das: Sie können große Mengen an Produktdaten oder FAQ-Inhalten schneller in mehrere Sprachen überführen. Allerdings bleibt die Qualitätssicherung entscheidend, da KI-Modelle branchenspezifische Begriffe oder regionale Nuancen nicht immer korrekt erfassen. Ein praktischer Ansatz ist der Einsatz von KI für die Rohübersetzung, gefolgt von einer menschlichen Prüfung. Tools wie Baduno kombinieren KI-Übersetzung mit muttersprachlicher Prüfung und bieten so eine skalierbare Lösung.

Parallel zur KI-Entwicklung erweitert Schema.org kontinuierlich sein Vokabular. Zukünftige Typen könnten stärker auf KI-generierte Inhalte eingehen, etwa ein „AIContent“-Schema zur Kennzeichnung von maschinell erstellten Texten. Auch die Verknüpfung mit Knowledge Graphen wird wichtiger: Mehrsprachige Markups könnten künftig automatisch aus zentralen Wissensbasen generiert werden. Bereits jetzt gibt es das „translationOfWork“-Property, das die Beziehung zwischen übersetzten Inhalten explizit macht. Wir empfehlen, solche neuen Eigenschaften frühzeitig in Ihre Strategie einzubeziehen, um bei Suchmaschinen-Updates gerüstet zu sein.

Ein weiterer Trend sind dynamische, sprachspezifische Markups, die auf Basis des Nutzerkontexts ausgespielt werden. Beispielsweise könnte ein Product-Schema je nach Standort des Nutzers die lokale Währung und Maßeinheit enthalten. Die Herausforderung liegt in der korrekten Verwendung von „inLanguage“ und der Vermeidung von Konflikten mit hreflang. Zukünftige Schema-Versionen könnten klarer definieren, wie sich regionale Varianten innerhalb eines Schemas darstellen lassen. Um sich darauf vorzubereiten, sollten Sie Ihre Markups modular aufbauen: Nutzen Sie für jede Sprache separate Blöcke innerhalb desselben JSON-LD oder verwenden Sie separate Script-Tags je Sprachversion – je nach technischer Infrastruktur.

Handlungsempfehlung: Testen Sie KI-basierte Übersetzungslösungen mit einem repräsentativen Satz Ihrer Schema-Daten und messen Sie die Fehlerquote. Halten Sie sich über Schema.org-Release-Notes auf dem Laufenden, um neue Eigenschaften zu identifizieren. Pilotieren Sie die dynamische Aussprache von Markups für verschiedene Zielgruppen und validieren Sie die Ergebnisse mit den Search Consoles der wichtigsten Suchmaschinen. So stellen Sie sicher, dass Ihre mehrsprachige Site von den zukünftigen Entwicklungen profitiert, ohne rechtliche oder technische Risiken einzugehen.

Praxisbeispiel: Schrittweise Implementierung einer mehrsprachigen Produktseite

Um die theoretischen Grundlagen in die Praxis umzusetzen, betrachten wir eine fiktive E-Commerce-Website, die ein Smartphone in den Sprachen Deutsch, Englisch und Französisch anbietet. Angenommen, die Produktseite ist unter einer einzigen URL mit Sprachumschalter verfügbar (z. B. example.com/smartphone). Ziel ist es, Schema.org Product-Markup mit sprachspezifischen Angaben auszuzeichnen.\n\n1. **Sprachcodes festlegen**: Für jede Sprachvariante wird ein eindeutiger inLanguage-Wert verwendet. Beispiel: Deutsch: "de-DE", Englisch: "en-US", Französisch: "fr-FR".\n\n2. **Name und Beschreibung sprachspezifisch auszeichnen**: Im JSON-LD-Markup wird ein @graph-Array genutzt. Jeder Sprachvariante wird ein eigenes Produkt-Objekt mit zugehörigem inLanguage zugeordnet. Beispiel:\n```json\n{\n "@context": "https://schema.org",\n "@graph": [\n {\n "@type": "Product",\n "inLanguage": "de-DE",\n "name": "Smartphone Pro Max",\n "description": „Leistungsstarkes Smartphone mit 128 GB Speicher“,\n "offers": { ... }\n },\n {\n "@type": "Product",\n "inLanguage": "en-US",\n „name“: „Smartphone Pro Max“,\n "description": „Powerful smartphone with 128 GB storage“,\n "offers": { ... }\n },\n {\n "@type": "Product",\n "inLanguage": "fr-FR",\n "name": „Smartphone Pro Max“,\n "description": „Smartphone puissant avec 128 Go de stockage“,\n "offers": { ... }\n }\n ]\n}\n```\n\n3. **Markup validieren**: Mit dem Google Rich Results Test wird für jede Sprachversion geprüft, ob das Markup akzeptiert wird. Dabei ist darauf zu achten, dass die inLanguage-Angaben mit der tatsächlichen Sprache der Seite übereinstimmen.\n\n4. **Einbindung per Server-Side oder JavaScript**: In der Praxis wird das Markup am besten serverseitig generiert, sodass der Seitenquellcode das komplette JSON-LD enthält. Bei dynamischen Sprachwechseln via JavaScript kann das Markup nachgeladen werden, was jedoch von Suchmaschinen möglicherweise nicht erfasst wird.\n\n5. **Test der Sichtbarkeit**: Nach der Implementierung wird überprüft, ob die strukturierten Daten in der Google Search Console als gültig gemeldet werden und ob die Rich Results in der Suche erscheinen.\n\nDieses Schritt-für-Schritt-Beispiel zeigt, wie Sie konkret vorgehen können. Passen Sie die Struktur an Ihre Technologie an und testen Sie jede Sprachvariante einzeln.

Zusammenarbeit mit Übersetzungs- und Lokalisierungsdienstleistern

Wenn Sie mehrsprachige strukturierte Daten implementieren, arbeiten Sie oft mit Übersetzern oder Lokalisierungsagenturen zusammen. Dabei ist es wichtig, dass auch die Schema.org-Markups Teil des Lokalisierungsprozesses werden. Besprechen Sie mit Ihrem Dienstleister, dass nicht nur der sichtbare Inhalt, sondern auch die Werte in JSON-LD (z. B. „name“, „description“) übersetzt werden müssen. Ein häufiger Fehler: Die Agentur erhält nur den Text der Seite, nicht aber die strukturierten Daten. Stellen Sie daher ein separates Dokument mit allen Schema-Feldern bereit – idealerweise im JSON-Format – und legen Sie fest, welche Felder sprachspezifisch übersetzt werden (z. B. „offers“ oder „review“ können global bleiben, während „name“ je nach Sprache variiert).

Praxistipp: Nutzen Sie Glossare und Translation Memories auch für Ihre strukturierten Daten. So stellen Sie sicher, dass Produktnamen und Fachbegriffe einheitlich in allen Markups erscheinen. Bitten Sie den Dienstleister zudem, die sprachlichen Codes (inLanguage) gemäß Ihrer Vorgabe zu setzen – etwa „de-DE“ statt nur „de“. Nach der Lieferung sollten Sie stichprobenartig prüfen, ob alle übersetzten Feldwerte in den Markups korrekt hinterlegt sind. Ein automatisierter Test mit dem Rich Results Test von Google kann hier erste Hinweise geben.

Ein weiterer Aspekt: Die Zusammenarbeit bei der Qualitätssicherung. Vereinbaren Sie, dass die übersetzten Schema-Daten vor der Veröffentlichung von einem muttersprachlichen Redakteur gegengelesen werden. Denn falsch übersetzte Produktattribute oder Anweisungen in FAQ-Fragen können im internationalen Ranking schaden. Dokumentieren Sie den gesamten Prozess – von der Extraktion der Quelltexte bis zur Einspielung – und aktualisieren Sie Ihre Checkliste für jede Sprachversion. So vermeiden Sie, dass bei späteren Content-Updates die strukturierten Daten veralten.

Rechtlicher Hinweis: Die Verantwortung für korrekte Übersetzungen liegt bei Ihnen. Lassen Sie sich die Einhaltung Ihrer Vorgaben schriftlich bestätigen und klären Sie Haftungsfragen bei Fehlübersetzungen vertraglich. Eine unabhängige Rechtsberatung wird empfohlen.

Budgetplanung und Aufwandsschätzung für mehrsprachige Schema-Implementierung

Die Einführung von strukturierten Daten in mehreren Sprachen verursacht einmalige und laufende Kosten. Neben der reinen Übersetzung der Markup-Inhalte fallen Aufwände für technische Integration, Testing und Wartung an. Für eine realistische Budgetplanung müssen Sie folgende Posten berücksichtigen:

1. Übersetzung der Schema-Felder: Pro Sprachversion entstehen Kosten für die Übersetzung aller relevanten JSON-LD-Elemente (Titel, Beschreibungen, Fragen, Antworten etc.). Da es sich um kurze, oft technische Texte handelt, können Übersetzungsagenturen spezielle Preise anbieten. Kalkulieren Sie mit einem Aufschlag von 10–20 % für die Einarbeitung in die Schema-Definitionen.

2. Technische Anpassung: Die Auszeichnung muss pro Sprache entweder in separaten JSON-LD-Blöcken oder über mehrsprachige Felder erfolgen. Je nach System benötigt Ihr Entwicklerteam zusätzlich Zeit, um die Logik für Sprachwechsel und Fallbacks zu implementieren. Erfahrungsgemäß liegt der initiale Aufwand für eine Website mit fünf Sprachversionen zwischen 15 und 25 Personentagen in der Entwicklung.

3. Testing und Qualitätssicherung: Jede Sprachversion muss einzeln validiert werden – mit Google Rich Results Test, Schema.org-Validatoren und manuellen Stichproben. Planen Sie pro Sprache etwa 1–2 Tage für die erste Einrichtung und eine halbe Stunde pro Änderung ein.

4. Laufende Wartung: Bei Aktualisierungen des Produktsortiments oder FAQ-Inhalts müssen auch die Markups zeitnah angepasst werden. Legen Sie fest, ob das Übersetzungsteam bei neuen Inhalten stets die Schema-Daten mittliefert. Ein Content-Management-System, das strukturierte Daten automatisch generiert, reduziert den Langzeitaufwand, erfordert aber eine entsprechende Einrichtung.

5. Werkzeuge und Lizenzen: Falls Sie spezielle Tools zur Überwachung der strukturierten Daten (z. B. Webmaster-Tools-APIs oder eigene Dashboards) nutzen, fallen ggf. Abogebühren an.

Als Faustregel sollten Sie für den gesamten Prozess (Einführung in drei Hauptsprachen) mit einem Budget von 5.000 bis 15.000 Euro rechnen, abhängig vom Umfang der Seite und der Anzahl der Produkte. Bei kleinen Projekten mit wenigen FAQ-Seiten kann der Betrag auch niedriger ausfallen.

Rechtlicher Hinweis: Die genannten Zahlen dienen nur der Orientierung. Lassen Sie sich individuelle Angebote von Entwicklern und Übersetzern geben und beachten Sie, dass die tatsächlichen Kosten je nach Komplexität abweichen können. Für verbindliche Aussagen wenden Sie sich an Ihre Rechts- und Steuerberatung.