Schema Markup für KI-SEO: Was wirklich funktioniert und was nicht

Warum Schema Markup 2026 wieder auf der Agenda steht

Die Suchergebnisse haben sich verändert, und Schema sitzt mittendrin

Die Google-Suche sieht 2026 anders aus als vor zwei Jahren. Rich Results, AI Overviews, Bing-Copilot-Antworten: Ein wachsender Teil der Sichtbarkeit verlagert sich weg vom blauen Link. Daraus ergibt sich eine neue Logik. Zitiert werden statt nur ranken. Wer in einer AI Overview oder einer Copilot-Antwort namentlich referenziert wird, bekommt Aufmerksamkeit, die unabhängig von der eigenen Klickrate existiert.

Schema Markup arbeitet genau an dieser Schnittstelle zwischen klassischer Suchbarkeit und KI-Ausgaben. Der Weg dorthin ist aber indirekter, als die meisten erwarten.

Der zweistufige Wirkmechanismus

1. Schema verbessert klassische Rankings über Rich Results und eine höhere Klickrate in den Suchergebnissen.
2. Bessere klassische Rankings erhöhen die Wahrscheinlichkeit, in KI-Ausgaben zitiert zu werden.

Diese Zweistufigkeit ist der Kern. Schema ist kein direkter Ranking-Faktor. Wer erwartet, dass ein JSON-LD-Block direkt zu mehr KI-Zitierungen führt, wird enttäuscht. Wer Schema als technischen Anker im klassischen Suchindex versteht, zieht daraus echten Nutzen.

Zur Größenordnung der ersten Stufe: Branchenübliche Fallstudien nennen CTR-Zuwächse durch Rich Results in der Spanne von 20 bis 40 Prozent, abhängig vom Rich-Result-Typ und der Branche. Das sind Momentaufnahmen einzelner Seiten, kein garantierter Effekt, aber die Richtung ist über viele Tests hinweg konsistent. Die zweite Stufe lässt sich nicht sauber quantifizieren, weil kein KI-System offenlegt, wie es Quellen auswählt. Belegbar ist nur die Kausalkette: keine Indexierung, keine Zitierung.

Was ist Schema Markup? Die Grundlagen, die du wirklich brauchst

Schema.org, Structured Data und JSON-LD

Diese drei Begriffe werden oft vermischt, meinen aber Verschiedenes. Schema.org ist das gemeinsam von Google, Microsoft, Yahoo und Yandex entwickelte Vokabular, das festlegt, wie Entitäten wie Organisationen, Artikel, Produkte oder Personen maschinenlesbar beschrieben werden. Structured Data ist das übergeordnete Konzept: maschinenlesbare Informationen, die über das sichtbare HTML hinausgehen. JSON-LD, Microdata und RDFa sind die drei Formate, in denen dieses Vokabular technisch umgesetzt wird.

Warum JSON-LD der einzige sinnvolle Standard ist

Google empfiehlt JSON-LD explizit, nicht als eine Option unter dreien, sondern als klare Präferenz. Der Grund ist einfach: JSON-LD liegt als separater <script>-Block im <head> des Dokuments, ist nicht mit dem HTML verschachtelt und lässt sich unabhängig vom sichtbaren Inhalt warten. Microdata und RDFa verlangen, dass Attribute direkt in HTML-Elemente eingebettet werden, was Wartung und Fehlersuche aufwändiger macht. Für Neuimplementierungen gibt es keinen Grund, nicht mit JSON-LD zu starten.

Was jeder JSON-LD-Block braucht

Jeder Block braucht mindestens drei Felder: @context (immer https://schema.org), @type (der Schema-Typ, z.B. Article) und die für diesen Typ vorgeschriebenen Pflichtfelder. Ein minimales Article-Schema sieht so aus:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titel des Artikels",
  "author": {
    "@type": "Person",
    "name": "Name der Autorin"
  },
  "datePublished": "2026-01-15"
}

Welche Felder Pflicht sind, hängt vom Typ ab. Das Schema.org-Vokabular umfasst über 800 Typen, die allermeisten davon wirst du nie brauchen. Welche Felder für Google-Rich-Results relevant sind, dokumentiert Google Search Central je Typ.

Schema und KI-Crawler

Was die Branche glaubt: KI liest deine JSON-LD-Snippets

Die verbreitete Annahme: Wenn ich gutes Schema Markup implementiere, lesen ChatGPT, Perplexity und Co. das direkt aus meinem JSON-LD und zitieren mich öfter. Intuitiv klingt das plausibel. Strukturierte Daten sind maschinenlesbar, KI-Systeme verarbeiten strukturierte Daten, also müsste der Zusammenhang direkt sein.

Er ist es nicht. Und das kommt nicht von SEO-Bloggern, sondern von Google selbst. In der offiziellen KI-Leitlinie steht schwarz auf weiß, dass strukturierte Daten für die generative Suche keine Voraussetzung sind:

Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search. (Google Search Central, 2026)

Das stützt die zweistufige These direkt. Google baut seine KI-Features auf Retrieval Augmented Generation (RAG) und denselben Ranking-Systemen wie die normale Suche auf. Es gibt kein spezielles Schema für die KI. Schema wirkt, wenn überhaupt, über den Umweg Index, nicht über einen direkten Draht in die generative Antwort.

Was Studien zeigen: JSON-LD wird beim direkten Fetch herausgefiltert

Das Technical-SEO-Unternehmen SearchVIU hat in einem kontrollierten Experiment getestet, was KI-Systeme beim direkten Seitenabruf verarbeiten. Das Ergebnis: ChatGPT, Claude, Gemini, Perplexity und Google AI Mode extrahieren beim direkten Fetch ausschließlich sichtbaren HTML-Inhalt. Informationen, die nur im JSON-LD-Block standen, fand keines der fünf Systeme. Ein Experiment von Ahrefs zeigt Ähnliches: kein messbarer Anstieg bei KI-Zitierungen, nachdem Schema hinzugefügt wurde.

Schema wirkt für den direkten KI-Fetch also nicht. Wer Schema implementiert, tut es für den klassischen Suchindex.

Was trotzdem nachweislich funktioniert

Der indirekte Weg funktioniert. Search Engine Land hat in einem kontrollierten Test drei inhaltlich identische Seiten verglichen: eine mit gut implementiertem Schema, eine mit fehlerhaftem Schema, eine ohne. Nur die Seite mit korrektem Schema erschien in einer AI Overview und rankte für mehrere Keywords. Die Seite ohne Schema wurde gecrawlt, aber nicht indexiert und tauchte in keiner KI-Ausgabe auf. Kein Beweis für einen kausalen Direkteffekt, aber ein Indiz, dass Schema die Indexierungsqualität beeinflusst, die wiederum KI-Sichtbarkeit ermöglicht.

Bei Bing Copilot ist der Wirkmechanismus direkter bestätigt. Microsofts Principal Product Manager Fabrice Canel hat auf der SMX München 2025 öffentlich bestätigt, dass Schema Markup den LLMs von Bing und Copilot hilft, Inhalte zu verstehen. Bing verarbeitet strukturierte Daten aus seinem Suchindex, nicht aus dem direkten Fetch.

Das JavaScript-Problem für KI-Crawler

Viele Setups laden JSON-LD per JavaScript nach, über Tag Manager oder clientseitiges Rendering. Das ist ein Problem, weil die meisten KI-Crawler kein JavaScript ausführen. Stand 2026 verarbeiten GPTBot, ClaudeBot und PerplexityBot ausschließlich das initiale HTML (SearchOptimo, 2026). Vercel-Messungen zeigen, dass GPTBot und ClaudeBot JavaScript-Dateien teils herunterladen, aber nie ausführen.

Eine Unterscheidung ist wichtig, sonst zieht man den falschen Schluss: Nicht alle relevanten Systeme sind blind für JavaScript. Google-Extended (der Gemini-Crawler) nutzt Googlebots Rendering-Infrastruktur und kann JavaScript ausführen, mit denselben Timing- und Ressourcen-Einschränkungen wie Googlebot. Und weil AI Overviews und AI Mode auf Googles regulärem Index aufsetzen, greift dort ohnehin Googlebot, der JavaScript rendert. Für alles außerhalb des Google-Kosmos gilt: Was dynamisch nachgeladen wird, sehen die meisten KI-Crawler nicht.

Konsequenz: Schema gehört statisch in den <head> des ausgelieferten HTML, bevor der Browser irgendetwas rendert. Damit bist du in beiden Welten auf der sicheren Seite.

Die 5 Schema-Typen, auf die es zuerst ankommt

Wie du bei begrenzten Ressourcen priorisierst

Nicht jeder Schema-Typ rechtfertigt den gleichen Aufwand. Die Entscheidungslogik: Rich-Result-Potenzial (erzeugt der Typ messbare SERP-Features?), Entity-Klarheit (hilft er, Entitäten eindeutig zu definieren?) und Branchenfit (ist er für mein Geschäftsmodell relevant?).

Organization: dein digitaler Steckbrief

Organization-Schema definiert, wer du bist: Name, Logo, Kontaktdaten, Social Profiles, Gründungsjahr. Klingt nach Pflichtübung, ist aber die Grundlage für Knowledge-Graph-Einträge. Suchmaschinen können eine Marke nur dann eindeutig einer Entität zuordnen, wenn es eine konsistente, maschinenlesbare Definition gibt. Organization-Schema wird einmal seitenübergreifend eingebunden, idealerweise auf der Startseite oder in einer globalen Komponente, und wirkt überall.

Zentral ist das sameAs-Attribut. Es verlinkt auf externe Profile und ist der maschinenlesbare Klebstoff, der isolierte Außenpräsenzen zu einer einzigen Entität zusammenführt. Neben LinkedIn und Bewertungsportalen gehört hier auch die Wikidata-QID hinein, sofern vorhanden. Wie du einen Wikidata-Eintrag für GEO erstellst, steht im eigenen Artikel. So sieht ein sauberes Organization-Schema aus:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Beispiel GmbH",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "foundingDate": "2015",
  "description": "Kurzbeschreibung des Unternehmens in einem Satz.",
  "sameAs": [
    "https://www.linkedin.com/company/beispiel-gmbh",
    "https://www.wikidata.org/wiki/Q12345678",
    "https://www.provenexpert.com/beispiel-gmbh"
  ]
}

Article / BlogPosting: Inhalte als Entitäten kennzeichnen

Article eignet sich für redaktionelle Inhalte und Nachrichtenartikel, BlogPosting ist die semantisch präzisere Wahl für Magazin-Inhalte ohne Newscharakter. Der Unterschied ist graduell, aber Google wertet ihn aus. Wirkungsvoll ist die Ergänzung mit Person-Schema für Autoren: Name, Biografie und Verlinkung auf Profile stärken das E-E-A-T-Signal und etablieren Autorinnen und Autoren als eigenständige Entitäten.

Wenn dir das Gerede über Entitäten hier zu abstrakt ist, lohnt ein kurzer Blick in unseren Artikel zu Entity-SEO für KI-SEO und danach zurück hierher.

Product: E-Commerce-Sichtbarkeit im SERP

Product-Schema bringt Sternebewertungen, Preise und Verfügbarkeit direkt in die Suchergebnisse. Google setzt für Rich Results bestimmte Pflichtfelder voraus: unter anderem name, image, ein valides offers-Objekt mit Preis und Währung sowie aggregateRating, wenn Bewertungen angezeigt werden sollen. Fehlende oder fehlerhafte Felder führen dazu, dass Google das Schema zwar liest, aber kein Rich Result ausspielt. Ein vollständiges Beispiel:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Beispielprodukt",
  "image": "https://example.com/produkt.jpg",
  "description": "Kurzbeschreibung des Produkts.",
  "brand": {
    "@type": "Brand",
    "name": "Beispiel GmbH"
  },
  "offers": {
    "@type": "Offer",
    "price": "199.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/produkt"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "128"
  }
}

LocalBusiness: lokale Sichtbarkeit strukturieren

LocalBusiness-Schema liefert Öffnungszeiten, Adresse, Telefonnummer und Geschäftskategorie in strukturierter Form. Das verbessert die Darstellung im Local Pack und in Google Maps. Wichtig: LocalBusiness-Schema ergänzt das Google Business Profile, ersetzt es nicht. Beide Kanäle müssen konsistente Daten liefern, weil Widersprüche zwischen Schema und GBP die Entity-Klarheit schwächen.

FAQPage: der Sonderfall mit gedämpfter Erwartung

FAQ-Schema bildet auf den ersten Blick genau das Format ab, das KI-Systeme für ihre Antworten nutzen: eine Frage, eine strukturierte Antwort, sauber gepaart. Trotzdem gehört FAQPage 2026 nicht in dieselbe Liga wie die vier Typen oben, und das aus einem konkreten Grund: Google hat FAQ-Rich-Results schon 2023 auf Behörden- und Gesundheitsseiten beschränkt. Für die allermeisten Sites erzeugt FAQPage keine sichtbaren Rich Results mehr.

Was bleibt, ist der semantische Wert. Der Typ hilft weiterhin, Frage-Antwort-Paare maschinenlesbar zu strukturieren, und schadet nicht. Nur die Erwartung an ein SERP-Feature solltest du streichen. Die Implementierung folgt einem klaren Muster: ein FAQPage-Container, darin mehrere Question-Objekte, jedes mit name (die Frage) und acceptedAnswer mit einem Answer-Objekt:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was kostet Schema Markup?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nichts. Schema.org ist ein offenes Vokabular. Aufwand entsteht nur bei der Implementierung."
      }
    },
    {
      "@type": "Question",
      "name": "Brauche ich einen Entwickler dafür?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Für Standardtypen reichen Plugins wie Yoast oder RankMath. Für verknüpfte @graph-Strukturen ist Handarbeit sinnvoll."
      }
    }
  ]
}

Branchenspezifische Empfehlungen im Überblick

Den Entity-Graph aufbauen: Schema-Inseln vs. konsistentes Profil

Warum einzelne, isolierte Schemas nicht reichen

Eine Organisation mit Organization-Schema auf der Startseite, Article-Schema auf Blogartikeln und Product-Schema auf Produktseiten, aber ohne Verknüpfung dieser Blöcke, hat Datenpunkte, aber kein kohärentes Profil. Suchmaschinen sehen dann Daten, aber keine Beziehungen. Die Maschine kann etwa die Autorin eines Artikels nicht sicher dem Unternehmen zuordnen, das auf der Startseite definiert ist.

@graph und @id: verknüpfte Knoten statt Einzelschritte

@graph erlaubt es, mehrere Schema-Typen in einem einzigen JSON-LD-Block zu definieren. @id gibt jedem Objekt eine eindeutige URL als Identifier, über die es seitenübergreifend referenziert werden kann. Konkret: Das Organization-Objekt bekommt die @id https://example.com/#organization. Das Article-Objekt referenziert dann denselben Identifier im publisher-Feld. Suchmaschinen erkennen so, dass Artikel und Organisation zusammengehören, auch wenn sie auf verschiedenen Seiten definiert sind.

So sieht ein verknüpfter Block aus. Das Article-Objekt zeigt über @id auf Organisation und Website, statt die Daten zu wiederholen:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Beispiel GmbH",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Beispiel GmbH",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/schema-guide/#article",
      "headline": "Schema Markup richtig einsetzen",
      "author": {
        "@type": "Person",
        "@id": "https://example.com/#autorin",
        "name": "Name der Autorin"
      },
      "publisher": { "@id": "https://example.com/#organization" },
      "isPartOf": { "@id": "https://example.com/#website" },
      "datePublished": "2026-01-15"
    }
  ]
}

Das Grundprinzip: Schema spiegelt den Inhalt, es ersetzt ihn nicht

Was im JSON-LD steht, muss auch im sichtbaren Seitentext stehen. Wenn ein Preis im Schema steht, muss er auf der Seite sichtbar sein. Wenn ein Autor im Article-Schema genannt wird, muss er auf der Seite erkennbar sein. Google bezeichnet Schema-Informationen ohne sichtbare Entsprechung explizit als potenzielle Manipulation und wertet sie ab oder ignoriert sie.

Genau deshalb greifen Schema und sauber strukturierter Text ineinander. Der sichtbare Text ist es, den KI-Crawler beim direkten Fetch tatsächlich lesen. Wie du diesen Text so aufbaust, dass ein Modell einzelne Absätze isoliert als Antwort verwenden kann, steht unter Content Chunking für KI-SEO.

Schema, Knowledge Graph und Entity SEO

Konsistentes, verknüpftes Schema ist die technische Basis für Entity-Autorität. Wird eine Marke, eine Autorin oder ein Produkt über viele Seiten hinweg mit konsistenten @id-Referenzen beschrieben, kann Google sie als eigenständige Entität erkennen und in den Knowledge Graph aufnehmen. Das erhöht die Wahrscheinlichkeit, in KI-Ausgaben als verlässliche Quelle behandelt zu werden. Generative Engine Optimization (GEO), im deutschsprachigen Raum oft KI-SEO genannt, baut auf genau diesem Fundament auf.

Schema implementieren, auch ohne Entwickler

WordPress, Shopify, Webflow: was Plugins leisten und wo sie aufhören

In WordPress übernehmen Plugins wie Yoast SEO, RankMath oder Schema Pro die Grundimplementierung automatisch: Article-Schema auf Blogseiten, Organization auf der Startseite, BreadcrumbList in der Navigation. Was sie nicht leisten: individuelle Entity-Verknüpfungen über @graph, branchenspezifische Typen wie LocalBusiness mit Servicegebieten, oder FAQ-Schema auf Inhalten, die nicht als FAQ-Post-Typ angelegt sind.

Shopify liefert eingebautes Product-Schema für Produktseiten, aber Organization- und FAQ-Schema müssen manuell über Theme-Liquid oder Custom Apps ergänzt werden. Webflow bietet keinen nativen Schema-Support, aber über den Custom Code Embed lässt sich statisches JSON-LD problemlos in den <head> einbinden.

Manuell implementieren in vier Schritten

1. Schema-Typ auf Schema.org bestimmen und Pflichtfelder sowie empfohlene Felder lesen.
2. JSON-LD-Block erstellen. Schema.org dokumentiert alle Typen mit Beispielen, Google Search Central zeigt, welche Felder für Rich Results relevant sind.
3. Den fertigen Block statisch in den <head> einbinden. Kein JavaScript-Rendering, kein nachträgliches Laden über Tag Manager.
4. Vor dem Livegang validieren.

Offizielle Dokumentationsquellen

• Schema.org: vollständiges Typ-Vokabular mit allen Feldern
• Google Search Central: welche Typen Rich Results erzeugen, mit Anforderungen
• Bing Webmaster Guidelines: Copilot-spezifische Hinweise

Validieren, messen und kontinuierlich verbessern

Zwei Pflicht-Tools vor jedem Livegang

Vor dem Livegang sind zwei Tools unverzichtbar, und sie testen Unterschiedliches. Der Google Rich Results Test prüft, ob Google aus dem Schema ein Rich Result rendern würde. Relevant, wenn Rich Results das Ziel sind. Der Schema Markup Validator prüft die Konformität mit der Schema.org-Spezifikation unabhängig von Google, was für alle Typen sinnvoll ist, auch für solche ohne Rich Result. Wer nur den Rich Results Test nutzt, übersieht Fehler bei Typen, die Google nicht für Rich Results unterstützt, aber trotzdem für den Index auswertet.

Schema-Impact messen jenseits der Search Console

Die Google Search Console zeigt Rich-Result-Status pro URL und CTR-Veränderungen nach Typ. Für einen sauberen Vorher-Nachher-Vergleich lohnt es sich, ein Segment aus Seiten mit frisch implementiertem Schema gegen eine Kontrollgruppe ohne Schema über 4 bis 6 Wochen zu beobachten.

Knowledge-Graph-Einträge lassen sich durch eine Markensuche prüfen: Erscheint ein Knowledge Panel? Wenn ja, welche Informationen zieht Google dort?

KI-Zitierungen manuell zu tracken ist aufwändig, aber möglich: Perplexity und ChatGPT mit aktivierter Quellenanzeige nach Markennamen und relevanten Fachbegriffen befragen und notieren, ob und wie die Domain zitiert wird. Kein Ersatz für ein Tracking-System, aber ein nützlicher Stichprobencheck alle paar Wochen.

Für die seitenübergreifende Schema-Konsistenz empfiehlt sich regelmäßiges Crawling mit Screaming Frog oder Sitebulb: Welche Seiten haben Schema, welche nicht, wo fehlen Pflichtfelder?

Was du 2026 nicht mehr implementieren solltest

Schema-Deprecations: sieben Typen ohne Rich Results

Google hat über 2025 hinweg den Rich-Result-Support für sieben Schema-Typen eingestellt. Der letzte, Practice Problem, wurde im November 2025 angekündigt und verliert den Support ab Januar 2026, inklusive Abschaltung des Reportings in der Search Console (Google Search Central, 2025). Die sieben betroffenen Typen:

• Course Info
• Claim Review
• Estimated Salary
• Learning Video
• Special Announcement
• Vehicle Listing
• Practice Problem

Dazu eine Klarstellung, die oft mit hineingemischt wird: Dataset erzeugt in der normalen Suche ohnehin keine Rich Results, sondern dient nur der Dataset Search. Book Actions stand zwischenzeitlich auf der Liste, wurde aber wieder aufgenommen.

Das reiht sich in einen längeren Trend ein. FAQ-Rich-Results hat Google schon 2023 auf Behörden- und Gesundheitsseiten beschränkt, HowTo-Rich-Results komplett abgeschaltet. Das Muster: Google behält die Typen, die bei einer Kaufentscheidung helfen (Produkt, Bewertung, Unternehmensdaten), und streicht die, die vor allem Nutzer auf der Suchergebnisseite halten.

John Mueller hat auf Reddit klargestellt, dass das keine Abwertung von Schema insgesamt ist: "Google is not killing schema." Bestehende Implementierungen dieser Typen musst du nicht aktiv entfernen. Sie erzeugen schlicht keine Rich Results mehr, verursachen aber auch keine Penalties.

Wer diese Typen noch aktiv befüllt und wartet, kann die Ressourcen umschichten. Wer sie nie hatte, muss nichts tun. Wer informiert bleiben will, wenn Google weitere Typen abkündigt: Der Google Search Central Changelog ist die verlässlichste Quelle.

Die Kerntypen bleiben vollständig unterstützt und werden in den offiziellen Ankündigungen explizit als weiterhin relevant genannt: Product, Article, Organization, Person, Review, LocalBusiness, Event, Video, Recipe und Breadcrumb.