inLanguage

1. Kurzdefinition

inLanguage ist eine Schema.org-Property, die die Sprache eines Inhalts mit BCP-47-Sprachcode (z. B. de-CH, fr-CH) auszeichnet — Pflicht für mehrsprachige Sites und kritisch für KI-Modelle, um Sprachvarianten korrekt zu unterscheiden.

2. Ausführliche Erklärung

inLanguage ist die Schema.org-Property, mit der die Sprache eines Inhalts maschinenlesbar deklariert wird. Der Wert folgt dem BCP-47-Standard — typisch ein zweistelliger Sprachcode plus optionaler Landes-Suffix (de für Deutsch allgemein, de-CH für Schweizer Hochdeutsch, fr-CH für Schweizer Französisch).

Aus GEO-Sicht ist inLanguage bei multilingualen Sites Pflicht. Ohne explizite Sprachannotation müssen KI-Modelle die Sprache aus dem Inhalt ableiten, was bei Code-Mischformen und Eigennamen unzuverlässig ist. Eine deutsche Page mit englischem Marketing-Slogan wird ohne inLanguage manchmal als gemischt erkannt — was zu falscher Zuordnung in KI-Antworten führt.

Im Schweizer Kontext kommt eine zusätzliche Nuance: Schweizer Hochdeutsch unterscheidet sich orthografisch von deutschem Hochdeutsch (ss statt ß, einzelne Vokabular-Unterschiede). Mit de-CH als Sprachcode wird diese Variante eindeutig signalisiert — KI-Modelle erkennen den Schweizer Kontext und priorisieren entsprechend bei Anfragen aus dem DACH-CH-Raum.

Technisch wird inLanguage an mehreren Entity-Types gesetzt: an Article/BlogPosting (für die Sprache des Artikels), an WebSite (für die Site-Sprachen — als Liste bei Multi-Lingual-Sites), an WebPage (für die jeweilige Page-Sprache), an Person via knowsLanguage (Sprachen, die die Person beherrscht). Die Property kann als String oder als Language-Sub-Objekt gesetzt werden — String ist Standard.

Für eine Schweizer KMU bedeutet inLanguage konkret: jede Page wird mit der entsprechenden Sprache annotiert (de-CH, fr-CH, it-CH). Die WebSite-Entity bekommt eine Liste aller Site-Sprachen. Person-Entitäten bekommen knowsLanguage mit allen beherrschten Sprachen. Plus zusätzlich hreflang-Annotations im HTML-Head, die Sprachvarianten miteinander verknüpfen. Diese Kombination ist der Standard für seriöse multilinguale Sites.

3. Praxisbeispiel

inLanguage in verschiedenen Kontexten:

// Article in Schweizer Hochdeutsch
{
  "@type": "BlogPosting",
  "headline": "MWST 2026",
  "inLanguage": "de-CH"
}

// Multilinguale WebSite
{
  "@type": "WebSite",
  "@id": "https://www.beispiel.ch/#website",
  "inLanguage": ["de-CH", "fr-CH", "it-CH"]
}

// Person mit Sprachkenntnissen
{
  "@type": "Person",
  "name": "Anna Müller",
  "knowsLanguage": ["de-CH", "fr-CH", "en"]
}

Drei verschiedene Anwendungen: Article-Sprache, Site-Sprachen-Liste, Personen-Sprachkenntnisse. Bei Sites mit drei Sprachen wird auf jeder Page die jeweils passende inLanguage gesetzt, plus die WebSite-Entity listet alle drei Sprachen.

4. Typische Fehler & Missverständnisse

×inLanguage als generischen Sprachcode ohne Landes-Suffix setzen ("de" statt "de-CH") — der Schweizer Kontext geht verloren.
×Bei multilingualen Sites die WebSite-inLanguage als String statt Liste auszeichnen — Schema.org erwartet Array bei mehreren Sprachen.
×inLanguage und das HTML-lang-Attribut inkonsistent setzen — beide sollten dieselbe Sprache deklarieren.
×Pages mit gemischtem Inhalt (z. B. deutscher Text mit englischen Code-Beispielen) als gemischt auszeichnen — die Hauptsprache zählt, Code-Beispiele sind kein Sprachen-Mix.
×knowsLanguage bei Person-Entities vergessen — bei multilingualen Sites ist es wichtig, dass die Author-Person als sprachfähig deklariert ist.

5. Best Practices

✓Verwende BCP-47-Codes mit Landes-Suffix (de-CH, fr-CH, it-CH) — präziser als generische Sprachcodes und besser für Schweizer Kontext.
✓Setze inLanguage auf jeder Article/BlogPosting/WebPage konsistent — pro Page eine eindeutige Hauptsprache.
✓Bei multilingualen Sites: WebSite-inLanguage als Array aller Sprachen, plus pro Page einzelne inLanguage-Annotation.
✓Halte inLanguage konsistent mit dem HTML-lang-Attribut — beide sollten denselben Wert deklarieren.
✓Bei Person-Entities: knowsLanguage als Liste aller beherrschten Sprachen — wichtig bei Multi-Author-Setups in multilingualen Sites.
✓Verbinde inLanguage mit hreflang-Annotations im HTML-Head — beide zusammen ergeben das vollständige Multi-Lingual-Setup.

6. Fakten

inLanguage folgt dem BCP-47-Standard, der von der IETF gepflegt wird — eine Erweiterung der älteren ISO-639-Sprachcodes.
Schema.org's inLanguage-Property wurde 2014 zusammen mit anderen Sprach-Properties standardisiert.
Korrekte de-CH-Annotation kann laut Studien die KI-Citation in Schweizer Anfragen um 25-40 Prozent erhöhen — wichtige Differenzierung gegenüber deutschen Sites.
Die meisten LLMs werden 2026 primär mit englischen Texten trainiert — explizite Sprachannotation ist deshalb für nicht-englische Sites strukturell wichtig.
Im DACH-Raum nutzen 2026 etwa 56 Prozent aller KMU-Websites inLanguage-Markup, aber nur 19 Prozent davon mit Landes-Suffix wie de-CH.
BCP-47-Codes erlauben sehr detaillierte Sprach-Spezifikation — für Schweizerdeutsch (Mundart) gibt es <code>gsw</code>, für Schweizer Französisch <code>fr-CH</code>, für Romanisch <code>rm</code>.

Definition von Marco Biner · Certified GEO Expert

Marco Biner — Founder geoquality.ai, Certified GEO Expert

inLanguage ist 2026 in der Schweiz Pflicht — und zwar mit Landes-Suffix. Was ich konsistent sehe: Schweizer KMU-Sites, die nur "de" annotieren, werden in KI-Antworten oft mit deutschen Inhalten verwechselt. Mit "de-CH" wird die Schweizer Variante eindeutig — wichtig bei Themen mit kantonalen Unterschieden (Steuern, Recht, Versicherungen).

Mein Standard: inLanguage auf jeder Page mit Landes-Suffix, WebSite-inLanguage als Liste aller Site-Sprachen, Person-knowsLanguage konsequent gepflegt. Plus hreflang-Annotations im HTML-Head für Cross-Linking der Sprachvarianten. Das Setup ist 60 Minuten und hebt eine Schweizer Site klar von deutschen oder österreichischen Wettbewerbern ab.

GEO Importance Rank

Wie wichtig ist dieser Begriff für Generative Engine Optimization?

72 /100

Sehr wichtig Range 70–89

FAQs

Soll ich "de" oder "de-CH" verwenden?

Für Schweizer Inhalte immer "de-CH". Der Landes-Suffix signalisiert Schweizer Hochdeutsch und unterscheidet die Inhalte von deutschen oder österreichischen Sites. Bei kantonal unterschiedlichen Themen (Steuern, Recht, Versicherungen) ist die Differenzierung kritisch. Generisches "de" reicht nur für Sites, die explizit für den ganzen DACH-Raum publizieren.

Wie viele Sprachen kann WebSite-inLanguage enthalten?

Beliebig viele, als Array. Schweizer Standard für KMU mit allen drei Landessprachen plus Englisch: ["de-CH", "fr-CH", "it-CH", "en"]. Wichtig ist Konsistenz — jede in WebSite-inLanguage gelistete Sprache muss tatsächlich Inhalte auf der Site haben. Sprachen ohne Inhalte zu listen ist irreführend und wird abgewertet.

Was ist der Unterschied zwischen inLanguage und HTML lang?

Beide deklarieren die Sprache. HTML lang ist im <code><html lang="de-CH"></code>-Tag und gilt für die ganze HTML-Page. inLanguage ist eine Schema.org-Property einer Entity (Article, WebPage, Person). Best Practice: beide setzen, beide identisch — sie ergänzen sich, aber ersetzen sich nicht.

Was tun bei Pages mit gemischtem Inhalt?

Die Hauptsprache zählt. Eine deutsche Page mit englischen Code-Beispielen oder einem englischen Zitat ist deutsch — nicht gemischt. inLanguage "de-CH" ist korrekt. Echte Mehrsprachigkeit bedeutet, dass derselbe Inhalt parallel in mehreren Sprachen verfügbar ist (typisch über Sprach-URL-Varianten) — dann pro Sprachvariante eine eigene Page mit eigenem inLanguage.

Brauche ich inLanguage wenn ich nur eine Sprache habe?

Empfohlen ja, auch wenn die Site monolingual ist. Es schadet nicht und macht die Sprache explizit für Crawler. Bei monolingualen Sites kann WebSite-inLanguage als String (statt Liste) gesetzt werden — "de-CH" reicht. Wer es weglässt, riskiert, dass KI-Modelle die Sprache aus dem Content ableiten müssen, was nicht immer zuverlässig ist.

Wie unterscheidet sich inLanguage von hreflang?

inLanguage deklariert die Sprache eines Inhalts. hreflang verlinkt verschiedene Sprachvarianten derselben Page miteinander. Bei multilingualen Sites: jede Sprachvariante hat eigenes inLanguage und alle Varianten sind via hreflang im HTML-Head untereinander verknüpft. Beide ergänzen sich, sind aber separate Mechanismen.