Strukturierte Daten für KI-Suche mit Schema.org

Schema.org und JSON-LD für die KI-Suche: Organization mit sameAs, Article, FAQPage, Product und BreadcrumbList – mit Beispielen, Grenzen und Validierung.

Aktualisiert am 25. September 2026 · von Fabian Stratenhoff

Strukturierte Daten (Schema.org als JSON-LD) machen für Maschinen eindeutig, wer hinter einer Seite steht, wovon sie handelt und wann sie aktualisiert wurde. Pflicht für KI-Suchen sind sie nicht – aber sie sind eines der saubersten Signale, das du kontrollieren kannst.

Warum JSON-LD für KI-Suchen?

Sprachmodelle lesen Text. Text ist aber mehrdeutig: Ist „Merkur“ ein Planet, ein Gott, eine Zeitung oder eine Bank? Ist „Fabian“ der Autor der Seite oder nur ein Kunde, der in einem Testimonial zitiert wird? Strukturierte Daten beantworten solche Fragen maschinenlesbar. Mit Schema.org beschreibst du Entitäten (Organisation, Person, Produkt, Artikel) und ihre Beziehungen in einem festen Vokabular, das Suchmaschinen seit Jahren verstehen.

Wichtig ist eine ehrliche Einordnung:

• Google nutzt strukturierte Daten nachweislich – für Rich Results und um Seiteninhalte besser zu verstehen. Für die KI-Funktionen (AI Overviews, AI Mode) schreibt Google aber ausdrücklich, dass es kein spezielles Schema.org-Markup braucht. Voraussetzung ist lediglich, dass eine Seite indexiert ist und mit Snippet angezeigt werden darf.
• Ob und wie LLM-Antwortmaschinen (ChatGPT, Perplexity, Claude) JSON-LD direkt auswerten, ist öffentlich nicht vollständig dokumentiert. Viele Systeme arbeiten mit Suchindizes, die strukturierte Daten kennen – ein direkter Ranking-Vorteil in KI-Antworten ist aber nicht belegt.

JSON-LD ist dabei das empfohlene Format: Es steht in einem eigenen <script type="application/ld+json">-Block, ist unabhängig vom HTML-Markup und lässt sich leicht per Template erzeugen. Microdata und RDFa funktionieren ebenfalls, sind aber fehleranfälliger in der Pflege.

Organization & sameAs: Wer steckt dahinter?

Die wichtigste Entität deiner Website bist du selbst – als Unternehmen (Organization oder ein Untertyp wie LocalBusiness) oder als Person. Dieses Markup gehört typischerweise auf die Startseite, oft kombiniert mit WebSite. Mit @graph packst du mehrere Knoten in einen Block und verknüpfst sie per @id.

Besonders wertvoll ist sameAs: Eine Liste von URLs, die dieselbe Entität an anderer Stelle beschreiben – etwa ein Wikidata-Eintrag, das LinkedIn-Unternehmensprofil, ein Handelsregister- oder Branchenverzeichnis-Eintrag. So kann eine Maschine deine Firma eindeutig mit bekanntem Wissen verbinden, statt zu raten.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.beispiel.de/#organization",
      "name": "Beispiel GmbH",
      "url": "https://www.beispiel.de/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://www.beispiel.de/logo.png"
      },
      "description": "Softwarehaus für Buchhaltungslösungen im Mittelstand.",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q00000000",
        "https://www.linkedin.com/company/beispiel-gmbh",
        "https://github.com/beispiel-gmbh"
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "email": "support@beispiel.de",
        "telephone": "+49-30-1234567",
        "availableLanguage": ["de", "en"]
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://www.beispiel.de/#website",
      "url": "https://www.beispiel.de/",
      "name": "Beispiel GmbH",
      "inLanguage": "de",
      "publisher": { "@id": "https://www.beispiel.de/#organization" }
    }
  ]
}

Worauf du achten solltest

• Nur Profile in sameAs aufnehmen, die wirklich dir gehören und aktiv sind. Tote oder fremde Profile verwässern das Signal.
• Name, Adresse und Kontaktdaten müssen mit Impressum und sichtbaren Angaben übereinstimmen.
• Nur eine Organization-Definition pro Website pflegen und auf Unterseiten per @id referenzieren – statt auf jeder Seite leicht abweichende Varianten auszugeben.
• Einen Wikidata-Eintrag solltest du nur anlegen, wenn deine Organisation die Relevanzkriterien erfüllt; ein Wikidata-Eintrag ist kein Werbeprofil.

Article: Autor, Datum und Überschrift

Für Ratgeber, Blogposts und News ist Article (oder BlogPosting, NewsArticle) der passende Typ. Für KI-Suchen sind hier drei Dinge relevant, weil sie Glaubwürdigkeit und Aktualität transportieren: wer den Text geschrieben hat, wann er erschienen ist und wann er zuletzt inhaltlich geändert wurde.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Buchhaltung automatisieren: Ein Leitfaden für KMU",
  "image": ["https://www.beispiel.de/bilder/leitfaden-1200x675.jpg"],
  "datePublished": "2026-03-02T08:00:00+01:00",
  "dateModified": "2026-09-18T10:30:00+02:00",
  "author": {
    "@type": "Person",
    "name": "Anna Muster",
    "url": "https://www.beispiel.de/team/anna-muster",
    "sameAs": ["https://www.linkedin.com/in/anna-muster"]
  },
  "publisher": { "@id": "https://www.beispiel.de/#organization" },
  "mainEntityOfPage": "https://www.beispiel.de/ratgeber/buchhaltung-automatisieren"
}

• author als Person mit url zu einer echten Autorenseite (Bio, Qualifikation, Kontakt). Ein bloßer Name als String ist erlaubt, aber schwächer.
• datePublished und dateModified im ISO-8601-Format, am besten mit Zeitzone. Das sichtbare Datum auf der Seite sollte dazu passen.
• dateModified ehrlich halten: Nur ändern, wenn sich der Inhalt wirklich geändert hat. Ein automatisch auf „heute“ gesetztes Datum ohne inhaltliche Änderung ist irreführend.
• headline sollte der sichtbaren Überschrift entsprechen, image auf ein crawlbares Bild zeigen.

Mehr dazu, wie Autorschaft und Aktualität in KI-Antworten wirken, liest du im Guide In ChatGPT & AI Overviews zitiert werden.

FAQPage & HowTo: gültig, aber ohne Rich Results

Lange galten FAQ- und HowTo-Markup als SEO-Geheimtipp, weil Google daraus aufklappbare Fragen oder Schrittanleitungen in den Suchergebnissen baute. Das hat sich grundlegend geändert:

• HowTo: Google hat im August 2023 angekündigt, HowTo-Rich-Results einzustellen; seit September 2023 werden sie weder mobil noch am Desktop angezeigt.
• FAQPage: Ebenfalls ab August 2023 zeigte Google FAQ-Rich-Results nur noch für bekannte, maßgebliche Behörden- und Gesundheitswebsites. Im Mai 2026 hat Google das Feature komplett eingestellt – seit dem 7. Mai 2026 erscheinen FAQ-Rich-Results gar nicht mehr in der Google-Suche.

Heißt das, du solltest das Markup löschen? Nicht zwingend. Google sagt selbst, dass nicht genutzte strukturierte Daten keine Probleme verursachen, und FAQPage bzw. HowTo bleiben gültige Schema.org-Typen. Sie können Maschinen weiterhin helfen, Frage-Antwort-Paare oder Arbeitsschritte zu erkennen. Einen sichtbaren Effekt in der Google-Suche solltest du aber nicht mehr erwarten.

Wenn du FAQ-Markup nutzt, gelten weiterhin die Grundregeln: Jede Question braucht einen name und eine acceptedAnswer mit text; die Fragen und Antworten müssen genau so sichtbar auf der Seite stehen. Unabhängig vom Markup ist eine klar gegliederte FAQ-Sektion mit direkten Antworten ohnehin gut für KI-Suchen – der Inhalt zählt, nicht das Rich Result.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Wie lange dauert die Einrichtung?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Die Einrichtung dauert in der Regel einen Arbeitstag."
      }
    }
  ]
}

Product & BreadcrumbList in Kürze

Product

Für Shops und Produktseiten ist Product nach wie vor einer der wertvollsten Typen – hier gibt es in der Google-Suche weiterhin Produkt-Snippets und Händlereinträge. Pflicht ist ein name; für Produkt-Snippets verlangt Google zusätzlich mindestens eines von offers, review oder aggregateRating. Bei offers gehören price (bzw. priceSpecification) und priceCurrency dazu, sinnvoll sind außerdem availability, sku/gtin und brand. Preise im Markup müssen mit dem sichtbaren Preis übereinstimmen.

BreadcrumbList

Breadcrumbs zeigen, wo eine Seite in deiner Struktur liegt – für Menschen und Maschinen. Pflicht ist eine itemListElement-Liste aus ListItem-Einträgen mit position und name; alle Einträge außer dem letzten brauchen zusätzlich ein item (die URL).

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Ratgeber", "item": "https://www.beispiel.de/ratgeber/" },
    { "@type": "ListItem", "position": 2, "name": "Buchhaltung automatisieren" }
  ]
}

Validieren und typische Fehler

Markup, das nicht geparst werden kann, ist wertlos. Prüfe deshalb jede Änderung mit mindestens einem dieser Werkzeuge:

• Google Rich Results Test (search.google.com/test/rich-results): zeigt, welche Rich-Result-Typen Google erkennt und welche Pflichtfelder fehlen. Er prüft aber nur Typen, für die Google Rich Results anbietet.
• Schema Markup Validator (validator.schema.org): prüft allgemein gegen das Schema.org-Vokabular, auch für Typen ohne Google-Feature.
• PageScore: Der Tab „GEO“ listet alle gefundenen JSON-LD-Typen inklusive @graph, meldet ungültiges JSON und fehlende Felder – etwa Article ohne Autor oder Datum, Organization ohne sameAs. Den Hintergrund zu allen GEO-Faktoren findest du im GEO Check.

Die häufigsten Fehler

• Ungültiges JSON: Ein vergessenes Komma, ein Komma zu viel nach dem letzten Element (trailing comma), einfache statt doppelter Anführungszeichen oder unmaskierte Zeilenumbrüche in Texten. Ein einziger Fehler macht den ganzen Block unlesbar.
• Markup passt nicht zum sichtbaren Inhalt: Bewertungen, Preise, Autoren oder FAQ-Antworten, die nur im JSON-LD stehen. Google wertet das als Richtlinienverstoß; für KI-Systeme ist es ein Widerspruch, der Vertrauen kostet.
• Mehrere widersprüchliche Organization-Knoten: Theme, SEO-Plugin und Cookie-Tool geben jeweils eigene Organization-Daten aus – mit unterschiedlichem Namen oder Logo. Konsolidiere auf eine Quelle.
• Veraltete Werte: dateModified von 2019 auf einer frisch überarbeiteten Seite oder ein Logo-Pfad, der 404 liefert.
• Falscher Typ: Product auf einer Kategorieseite oder Article auf der Startseite.

Strukturierte Daten sind ein Baustein unter mehreren. Genauso wichtig sind der Zugriff für KI-Crawler, Inhalte ohne JavaScript-Zwang und klare Antworten im Text. Wenn du zusätzlich eine kuratierte Übersicht für Sprachmodelle anbieten möchtest, lies den Guide zu llms.txt; für die klassischen Meta-Angaben den Meta-Tags Guide.