Inhalt
- Warum Schema Markup ab 2026 wieder auf der Agenda steht
- Was ist Schema Markup? Grundlagen, die du wirklich brauchst
- Schema und KI-Crawler
- Die 5 Schema-Typen mit dem höchsten Impact
- Den Entity-Graph aufbauen: der Unterschied zwischen Schema-Inseln und einem konsistenten Profil
- Schema implementieren, auch ohne Entwickler
- Validieren, messen und kontinuierlich verbessern
- Was du 2026 nicht mehr implementieren solltest
Warum Schema Markup ab 2026 wieder auf der Agenda steht
Suchergebnisse haben sich verändert, und Schema ist mittendrin
Die Google-Suchergebnisse sehen im Jahr 2026 anders aus als noch vor zwei Jahren. Rich Results, AI Overviews, Bing Copilot-Antworten: Ein wachsender Teil der Sichtbarkeit verlagert sich weg vom klassischen blauen Link. Daraus hat sich eine neue Logik ergeben: 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. Für Marken, die ihren Traffic schützen wollen, ist das heute Realität.
Schema Markup ist in diesem Kontext wieder relevant, weil es genau an dieser Schnittstelle arbeitet: zwischen klassischer Suchbarkeit und KI-Ausgaben. Der Weg dorthin ist aber indirekter, als viele erwarten.
Der zweistufige Wirkmechanismus
- Schema verbessert klassische Rankings durch CTR-Erhöhung und Rich Results in den Suchergebnissen.
- Bessere klassische Rankings erhöhen die Wahrscheinlichkeit, in KI-Ausgaben zitiert zu werden.
Diese Zweistufigkeit ist der entscheidende Punkt. 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 dagegen als technischen Anker im klassischen Suchindex versteht, kann daraus echten Nutzen ziehen.
Was ist Schema Markup? Grundlagen, die du wirklich brauchst
Schema.org, Structured Data und JSON-LD
Diese drei Begriffe werden häufig vermischt, bezeichnen aber unterschiedliche Dinge. 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 sowie 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-Markup verschachtelt und lässt sich unabhängig vom sichtbaren Inhalt warten und aktualisieren. Microdata und RDFa erfordern dagegen, dass Attribute direkt in HTML-Elemente eingebettet werden, was Wartung und Fehlersuche deutlich aufwändiger macht. Für Neuimplementierungen gibt es keinen Grund, nicht mit JSON-LD zu starten.
Was du für JSON-LD brauchst (Minimalbeispiel)
Jeder JSON-LD-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"
}
Das Pflichtfeld-Set variiert je nach Typ. Die vollständige Referenz liefert Google Search Central.
Schema und KI-Crawler
Was die Branche glaubt: KI liest deine JSON-LD-Snippets
Die verbreitete Annahme lautet: Wenn ich gutes Schema Markup implementiere, lesen ChatGPT, Perplexity und Co. das direkt aus meinem JSON-LD und zitieren mich entsprechend öfter. Intuitiv klingt das plausibel. Strukturierte Daten sind maschinenlesbar, KI-Systeme verarbeiten strukturierte Daten, also sollte der Zusammenhang direkt sein. Er ist es nicht. Google selbst weist darauf hin, dass Structured Data für die KI-Suche keine Voraussetzung ist:
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, 15.05.2026
Was Studien zeigen: JSON-LD wird aktiv herausgefiltert
Das Technical SEO-Unternehmen SearchVIU hat in einem kontrollierten Experiment getestet, was KI-Systeme bei direktem Seitenabruf tatsächlich 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 vorlagen, wurden von keinem der fünf getesteten Systeme gefunden. Ähnliches zeigt ein Experiment von Ahrefs: Kein System zeigte einen messbaren Anstieg bei KI-Zitierungen, nachdem Schema hinzugefügt wurde.
Schema wirkt für KI-Ausgaben also nicht direkt. Wer Schema implementiert, tut es (zumindest aktuell) für den klassischen Suchindex, nicht für den direkten KI-Fetch.
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 und eine ohne Schema. Nur die Seite mit korrektem Schema erschien in einem AI Overview und rankte für mehrere Keywords. Die Seite ohne Schema wurde zwar gecrawlt, aber nicht indexiert und erschien in keiner KI-Ausgabe. Kein Beweis für einen kausalen Direkteffekt, aber ein Indiz dafür, dass Schema die Indexierungsqualität beeinflusst, die wiederum KI-Sichtbarkeit ermöglicht.
Beim Thema Bing Copilot ist der Wirkmechanismus direkter bestätigt: Microsofts Principal Product Manager Fabrice Canel hat auf der SMX Munich 2025 öffentlich bestätigt, dass Schema Markup den LLMs von Bing/Copilot hilft, Inhalte zu verstehen. Bing verarbeitet strukturierte Daten aus seinem Suchindex, nicht aus dem direkten Fetch.
Das JavaScript-Problem für AI-Crawler
Viele Implementierungen laden JSON-LD per JavaScript nach, entweder durch Tag Manager oder durch serverseitiges Rendering, das erst im Browser ausgeführt wird. Die meisten AI-Crawler rendern aber zum aktuellen Zeitpunkt (noch?) kein JavaScript. Was dynamisch nachgeladen wird, landet nicht im Index. Schema muss statisch im <head> des ausgelieferten HTML stehen, bevor der Browser irgendetwas rendert.
Die 5 Schema-Typen mit dem höchsten Impact
Wie du bei begrenzten Ressourcen priorisierst
Nicht jeder Schema-Typ rechtfertigt den gleichen Aufwand. Die Entscheidungslogik: Rich-Result-Potenzial (erzeugt dieser Typ messbare SERP-Features?), Entity-Klarheit (hilft dieser Typ, Entitäten eindeutig zu definieren?) und Branchenfit (ist dieser Typ für mein Geschäftsmodell relevant?).
| Schema-Typ | Hauptnutzen | Priorität |
|---|---|---|
| Organization | Entity-Definition, Knowledge Graph | Immer, als erstes |
| Article / BlogPosting | Inhalte als Entitäten, E-E-A-T | Content-Sites, Ratgeberseiten |
| FAQPage | Konversationelle Anfragen, Long-Tail | Seiten mit Frage-Antwort-Struktur |
| Product | Sternebewertungen, Preis in SERP | E-Commerce, Produktseiten |
| LocalBusiness | Local Pack, Maps-Sichtbarkeit | Stationäre Betriebe, lokale Services |
Organization: dein digitaler Steckbrief
Organization-Schema definiert, wer du bist: Name, Logo, Kontaktdaten, Social Profiles, Gründungsjahr. Das klingt nach Pflichtübung, ist aber die Grundlage für Knowledge Graph-Einträge. Suchmaschinen können eine Marke nur dann eindeutig einem Entity 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.
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. Besonders wirkungsvoll ist die Ergänzung mit Person-Schema für Autoren: Name, Biografie, Verlinkung auf Profile stärken das E-E-A-T-Signal und helfen dabei, Autorinnen und Autoren als eigenständige Entitäten zu etablieren.
Entitäten?
Yes, Entitäten. Wenn das Gerede über Entitäten hier noch unklar ist, würden wir empfehlen einmal kurz in unseren Artikel zum Thema Entitäten-SEO reinzuschauen (Entity-SEO für KI-SEO (GEO): Was steckt dahinter und warum machen es gute SEOs wahrscheinlich schon?) und anschließend hierhin zurückzukommen.
FAQPage: für konversationelle KI-Anfragen gebaut
FAQ-Schema bildet das Format ab, das KI-Systeme für ihre Antworten verwenden: eine Frage, eine strukturierte Antwort, sauber gepaart. FAQPage passt daher besonders gut für Long-Tail-Anfragen und sprachbasierte Suchen. Die Implementierung folgt einem klaren Muster: ein FAQPage-Typ als Container, darin mehrere Question-Objekte, jedes mit name (die Frage) und acceptedAnswer mit einem Answer-Objekt mit text.
Hinweis: Google hat FAQPage für allgemeine Sites in seinen Rich Results eingeschränkt. Der Typ bleibt aber relevant für den semantischen Index und für Behörden- und Gesundheitsseiten, wo Rich Results weiterhin erscheinen.
Product: E-Commerce-Sichtbarkeit im SERP
Product-Schema ermöglicht es, Sternebewertungen, Preise und Verfügbarkeitsstatus direkt in den Suchergebnissen anzuzeigen. Google setzt für Rich Results bestimmte Pflichtfelder voraus: darunter 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.
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 aber nicht. Beide Kanäle müssen konsistente Daten liefern, weil Widersprüche zwischen Schema und GBP-Daten die Entity-Klarheit schwächen.
Branchenspezifische Empfehlungen im Überblick
| Branche | Empfohlene Schema-Typen |
|---|---|
| E-Commerce | Product + AggregateRating + Organization |
| Lokal / Handwerk | LocalBusiness + Service + Event |
| B2B / Professional Services | Organization + Article + Person |
Den Entity-Graph aufbauen: der Unterschied zwischen Schema-Inseln und einem konsistenten Profil
Warum einzelne, isolierte Schemas nicht reichen
Eine Organisation, die auf der Startseite Organization-Schema hat, auf Blogartikeln Article-Schema und auf Produktseiten Product-Schema, aber diese Blöcke nicht miteinander verknüpft, hat zwar Datenpunkte, aber kein kohärentes Profil. Suchmaschinen sehen dann Daten, aber keine Beziehungen. Das Ergebnis: die Maschine kann z.B. die Autorin eines Artikels nicht sicher dem Unternehmen zuordnen, das auf der Startseite definiert ist.
@graph und @id: verknüpfte Schema-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. Ein konkretes Beispiel: Das Organization-Objekt bekommt die @id https://example.com/#organization. Das Article-Objekt auf einem Blogartikel referenziert dann denselben Identifier im publisher-Feld. Suchmaschinen können so erkennen, dass Artikel und Organisation zusammengehören, auch wenn sie auf verschiedenen Seiten definiert sind.
Das Grundprinzip
Was im JSON-LD steht, muss auch im sichtbaren Seitentext stehen. Schema ist Spiegelung des Inhalts, kein Ersatz. 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 Entsprechungen explizit als potenzielle Manipulation und ignoriert oder wertet sie ab.
Schema, Knowledge Graph und Entity SEO
Konsistentes, verknüpftes Schema ist die technische Basis für Entity-Autorität. Wenn eine Marke, eine Autorin oder ein Produkt über viele Seiten hinweg mit konsistenten @id-Referenzen beschrieben wird, 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. Das Konzept des Generative Engine Optimization (GEO) 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: maßgeschneiderte 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-Schema 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
- Schema-Typ auf Schema.org bestimmen und die Pflichtfelder sowie empfohlenen Felder lesen.
- JSON-LD-Block erstellen. Schema.org dokumentiert alle Typen mit Beispielen, Google Search Central zeigt, welche Felder für Rich Results relevant sind.
- Den fertigen Block statisch in den
<head>des HTML-Dokuments einbinden. Kein JavaScript-Rendering, kein nachträgliches Laden über Tag Manager. - 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 unterschiedliche Dinge. 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 Schema-Typen sinnvoll ist, auch wenn sie kein Rich Result erzeugen. 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-6 Wochen zu beobachten.
Knowledge Graph-Einträge lassen sich durch eine Markensuche auf Google prüfen: erscheint ein Knowledge Panel? Wenn ja, welche Informationen werden dort gezogen?
KI-Zitierungen manuell zu tracken ist aufwändig, aber möglich: Perplexity und ChatGPT mit aktivierter Quellenanzeige nach Markennamen und relevanten Fachbegriffen befragen, manuell 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 ein 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 Januar 2026: sieben Typen, die Google abgekündigt hat
Im November 2025 hat Google angekündigt, ab Januar 2026 den Rich-Result-Support für mehrere Schema-Typen einzustellen. Betroffen sind unter anderen: SitelinksSearchBox, Q&A, SpecialAnnouncement, Practice Problem und Dataset (für allgemeine Suche). John Mueller hat auf Reddit klargestellt, dass es sich dabei nicht um eine Abwertung von Schema insgesamt handelt: "Google is not killing schema." Bestehende Implementierungen dieser Typen müssen nicht aktiv entfernt werden; sie erzeugen schlicht keine Rich Results mehr, aber auch keine Penalties.
Wer diese Typen noch aktiv befüllt und wartet, kann die Ressourcen also 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, keine SEO-Nachrichtenseite.
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.
