Welches Schema-Markup wird 2026 von KI zitiert?

Rund um KI-Suchmaschinen kursiert ein hartnäckiger Mythos: Es gäbe ein magisches Schema-Markup, das ChatGPT, Perplexity und Google AI Overviews zum Zitieren bewegt. Es gibt keines. Google schreibt in der eigenen Doku zur KI-Optimierung wörtlich, dass für generative Features kein spezielles schema.org-Markup nötig ist (Google AI Optimization Guide). Wer seine Strategie auf einen vermeintlichen Zitations-Trick baut, baut auf Sand.

Belastbar ist etwas Unspektakuläreres: sauberes, server-gerendertes JSON-LD, das Ihre Entitäten ehrlich miteinander verknüpft. Genau das lässt sich in einem Headless-Frontend kontrollierter bauen als in einem theme-basierten Setup mit gestapelten Plugins — und genau dieser Emission-Pattern ist das eigentliche Thema dieses Beitrags. Wie Meta-Tags, Sitemaps und die Yoast- bzw. Rank-Math-Daten im Headless-Setup wandern, behandelt ein eigener Beitrag; hier geht es um die strukturierten Daten selbst.

Eine Begriffsklärung vorab: Akademisch heisst dieses Feld Generative Engine Optimization (GEO). Wir nutzen im Folgenden den Begriff "KI-Suchmaschinen" für ChatGPT, Perplexity, Gemini und Google AI Overviews. Was zählt, sind die Muster, nicht die Akronyme.

Schema-Markup gehört dabei in dieselbe Mythen-Kategorie wie die Frage, ob Sie eine llms.txt brauchen: Google nennt in derselben Doku auch llms.txt-Dateien ausdrücklich als für seine KI-Features unnötig. Beide Themen lohnen eine nüchterne Einordnung statt eines Trick-Versprechens.

Welches Schema-Markup zitiert KI 2026 wirklich — und welches nicht?

Kein Schema-Typ erzwingt ein KI-Zitat. Google sagt ausdrücklich, dass für AI Overviews und AI Mode kein spezielles schema.org-Markup nötig ist und es keinen eigenen KI-Typ gibt. Belastbar sind die etablierten Typen — Article, Person, Organization, BreadcrumbList —, weil sie Maschinen Fakten sauber extrahierbar machen, nicht weil sie ein Ranking-Hebel wären.

Die relevante Formulierung steht in Googles AI-Optimization-Guide unmissverständlich: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add" (Google AI Optimization Guide). Es gibt keinen AIPage-Typ, keine LLMOptimized-Property und keine geheime Auszeichnung, die ein Sprachmodell zum Zitieren zwingt. Wer das verspricht, verkauft einen Mythos.

Was kursiert, sind Hinweise aus SEO-Vendor-Analysen — etwa, dass Google und Microsoft Schema-Markup für ihre generativen Funktionen nutzen und dass Seiten nach sauberer Entity-Auszeichnung bessere Sichtbarkeit melden (Schema App, AI Search 2025). Solche Beobachtungen sind frühe Hinweise, nicht kausal und nicht als direkter Ranking-Effekt von Google bestätigt. Plausibler als ein direkter Schema-Effekt ist, dass dieselben Seiten ohnehin technisch sauber arbeiten — Schema ist dann Symptom guter Arbeit, nicht ihre Ursache. Bauen Sie Ihre Entscheidung deshalb nicht auf solche Korrelationen, sondern auf den defensiven Kern: Markup, das Fakten extrahierbar macht.

Es gibt kein Zitations-Schema. Es gibt nur sauberes Markup, das Maschinen die Fakten leichter macht — der Rest ist Marketing.

Die fünf Schema-Typen, die im Headless-Stack tragen

Fünf Typen decken den redaktionellen Headless-Fall ab: Article (bzw. BlogPosting) für den Beitrag, Person für den Autor, Organization für den Herausgeber, BreadcrumbList für die Pfad-Logik und FAQPage für extrahierbare Frage-Antwort-Paare. Jeder erfüllt eine klare Extraktionsaufgabe — keiner ist ein Ranking-Hebel.

Google unterstützt für den Beitrag selbst Article, NewsArticle und BlogPosting mit denselben empfohlenen Properties: headline, image, datePublished, dateModified und author. Der Autor kann eine Person oder eine Organization sein, idealerweise mit url oder sameAs zur Disambiguierung (Google, Article Structured Data). Genau diese sameAs-Verweise auf LinkedIn, GitHub oder ein Fachprofil sind es, die eine Person für eine Maschine identifizierbar machen — entscheidend für E-E-A-T-Signale.

Die folgende Übersicht ordnet jedem Typ seine Aufgabe, seine Kern-Properties, seinen Ort im Next.js-Frontend und seinen Status 2026 zu:

Die Tabelle macht das Muster sichtbar: Jeder Typ erledigt eine Extraktionsaufgabe, und jeder hat einen festen Ort im Frontend. Genau dieser Ort ist im Headless-Setup die eigentliche Frage — denn anders als bei klassischem WordPress rendert kein Theme das Schema für Sie.

Wo lebt das JSON-LD, wenn WordPress nicht rendert?

Im Headless-Setup liefert WordPress nur Daten — das JSON-LD erzeugt das Frontend. In Next.js gehört es als server-gerendertes <script type="application/ld+json"> in die Server-Component, also in page.tsx oder layout.tsx, nicht in einen Client-Hook. So steht das Markup im initialen HTML, bevor ein Crawler überhaupt JavaScript ausführt.

Das ist der Punkt, an dem die meisten Headless-Migrationen straucheln: Bei klassischem WordPress lebt das Schema von Yoast oder Rank Math im Theme und wird serverseitig mitgerendert. Schalten Sie das Frontend ab, ist dieses Schema ersatzlos weg — die Plugins liefern weiterhin die Rohdaten, aber niemand gibt sie mehr als JSON-LD aus. Diese Lücke muss das Frontend schliessen.

Next.js empfiehlt dafür exakt den Weg, den die offizielle Doku beschreibt: das strukturierte Datum als <script>-Tag in layout.js oder page.js rendern und beim Serialisieren jedes <-Zeichen durch die Unicode-Escape-Sequenz < ersetzen, um XSS zu verhindern (Next.js, JSON-LD Guide). Ein typisches Muster sieht so aus:

// app/blog/[slug]/page.tsx (Server Component)
const jsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  datePublished: post.date,
  dateModified: post.modified,
  author: { "@id": "https://wp-headless.ch/#person-daniel" },
};
 
return (
  <script
    type="application/ld+json"
    dangerouslySetInnerHTML={{
      __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
    }}
  />
);

Wer Typsicherheit will, setzt beim Bauen der Objekte schema-dts ein — das gibt dem TypeScript-Compiler die schema.org-Typen an die Hand und fängt Tippfehler in Property-Namen ab. Welche Datenquelle das Frontend dabei bedient, ob WPGraphQL als Datenquelle fürs Frontend oder die REST-API, ändert am Emission-Pattern nichts: Die Daten kommen aus WordPress, das JSON-LD entsteht im Server-Render.

@id-Verdrahtung: vom losen Markup zum Entity-Graph

Einzelne Schema-Blöcke ohne Bezug sind für Maschinen Inseln. Über @id geben Sie jeder Entität eine stabile URI — etwa https://wp-headless.ch/#organization oder /#person-daniel — und referenzieren sie überall identisch. author, publisher und worksFor zeigen so auf dieselbe Organisation: ein konsistenter Graph statt redundanter Duplikate.

Das Prinzip stammt direkt aus der JSON-LD-Spezifikation: @id identifiziert einen Knoten per IRI, und identische @id-Werte verknüpfen Entitäten über Dokumentgrenzen hinweg (W3C, JSON-LD 1.1). Praktisch heisst das: Sie definieren die Organization einmal global im layout.tsx, die Person einmal pro Autor — und referenzieren beide im Article nur noch per @id, statt Name, Logo und URL bei jedem Beitrag zu wiederholen.

Die Verdrahtung folgt einem festen Muster: Article.author zeigt auf die Person@id, Person.worksFor auf die Organization@id, und Article.publisher teilt sich dieselbe Organization@id. So entsteht eine Kette, die eine Maschine eindeutig auflösen kann — vom Beitrag über den Autor zur herausgebenden Organisation. Optional bündeln Sie alle Knoten in einem @graph-Array und liefern sie als einen zusammenhängenden Block aus, was die Wartung vereinfacht.

Dieser Graph ist der eigentliche Mehrwert sauberen Markups gegenüber zusammengewürfelten Plugin-Ausgaben: Nicht die Menge der Typen entscheidet, sondern ihre konsistente Verknüpfung. Warum strukturierte, verknüpfte Inhalte ein Headless-Frontend grundsätzlich für Headless-Inhalte, die für KI-Suchmaschinen zitierbar werden, prädestinieren, vertieft ein eigener Beitrag.

Schema ehrlich halten: deckungsgleich mit sichtbarem Inhalt

Markup muss den sichtbaren Seiteninhalt wahrheitsgemäss abbilden — Googles Richtlinie ist hier eindeutig. Daten, die nicht im sichtbaren HTML stehen, oder Preise und Autoren, die vom Sichtbaren abweichen, riskieren eine manuelle Massnahme und kosten die Rich-Result-Eligibility. Im Headless-Stack heisst das: Dieselbe Datenquelle speist Sichtbares und JSON-LD.

Die Quality-Guidelines formulieren das in zwei Sätzen, die man sich merken sollte: "Don't mark up content that is not visible to readers of the page" und "Your structured data must be a true representation of the page content" (Google, Structured Data Guidelines). Ein Verstoss ist kein Kavaliersdelikt — er kann eine manuelle Massnahme nach sich ziehen und die Seite aus allen Rich Results entfernen.

Im Headless-Setup ist die Versuchung real, weil sichtbares Rendering und Markup aus getrennten Code-Pfaden entstehen können. Die Disziplin lautet deshalb: eine Datenquelle für beides. Das Veröffentlichungsdatum im JSON-LD kommt aus demselben WordPress-Feld wie das sichtbar gerenderte Datum, der Autorname aus demselben Objekt, der Beitragstitel aus demselben String. Wo diese Kopplung fehlt, driften sichtbarer Inhalt und Markup auseinander — meist unbemerkt, bis die Search Console eine manuelle Massnahme meldet.

Ein zweiter, oft übersehener Punkt: Setzen Sie alle von Google als erforderlich markierten Properties. Fehlt eine Pflicht-Property, ist die Seite für das jeweilige Rich Result schlicht nicht eligibel — das Markup ist dann valide, aber wirkungslos.

FAQ-Markup nach dem Rich-Result-Aus (Mai 2026): noch sinnvoll?

Ja, mit realistischer Erwartung. Google hat FAQ-Rich-Results zum 7. Mai 2026 abgeschaltet; das sichtbare SERP-Snippet entfällt damit. FAQPage-Markup schadet aber nicht und liefert weiterhin sauber strukturierte Q&A-Paare, die KI-Systeme leichter extrahieren. Optimieren Sie für die Extraktion, nicht für ein verschwundenes Snippet.

Die Abschaltung ist über die Primärquelle datiert: In der FAQPage-Doku steht "This feature will no longer appear in Google Search starting May 7, 2026" (Google, FAQPage). Die Doku-Seite trägt seit dem 8. Mai 2026 einen Deprecation-Hinweis, bleibt aber inhaltlich erhalten; im Juni 2026 entfernt Google zusätzlich den FAQ-Filter in der Suche sowie die Unterstützung im Rich-Results-Bericht der Search Console und im Rich Results Test. Das betrifft ausschliesslich die sichtbare SERP-Darstellung und die Test-Werkzeuge — nicht die Gültigkeit des Markups.

Für die KI-Extraktion bleibt FAQPage nützlich, weil es genau das tut, was Sprachmodelle bei der Antwort-Generierung brauchen: Es markiert, welche Frage zu welcher Antwort gehört. Ein strukturiertes Q&A-Paar ist für eine Maschine leichter zu zerlegen als ein Fliesstext-Absatz. Die Bedingung: Halten Sie das Frage-Antwort-Format auch im sichtbaren Inhalt — sonst verletzen Sie die Deckungsgleichheits-Regel aus dem vorigen Abschnitt. Markup ohne sichtbares Pendant ist hier kein Gewinn, sondern ein Risiko.

Pre-Publish-Checkliste: valides JSON-LD im Headless-Frontend

Vor dem Deploy gilt eine schlanke Vier-Schritte-Routine: jeden Typ validieren, die @id-Referenzen auf Konsistenz prüfen, den sichtbaren Inhalt gegen das Markup abgleichen und sicherstellen, dass das <script> server-seitig im initialen HTML steht. Diese vier Schritte machen das Markup belastbar — unabhängig vom KI-Hype.

1. Validieren. Prüfen Sie jeden Typ im Rich Results Test und im Schema Markup Validator. Ersterer zeigt die Google-Eligibility, Letzterer die reine schema.org-Validität (Google, Strukturierte Daten).
2. @id-Konsistenz prüfen. Stellen Sie sicher, dass author, publisher und worksFor über alle Blöcke hinweg auf dieselben URIs zeigen — ein einziger Tippfehler in einer @id zerreisst den Graph.
3. Initial-HTML kontrollieren. Prüfen Sie das JSON-LD über "Seitenquelltext anzeigen" (View Source), nicht über das DevTools-DOM. Nur Ersteres zeigt, was wirklich server-gerendert ausgeliefert wird, bevor JavaScript läuft.
4. Datumsfelder verifizieren. datePublished und dateModified kommen aus den echten WordPress-Feldern, nicht hartkodiert — sonst weichen sie früher oder später vom sichtbaren Inhalt ab.

Wer diese Routine einmal in den Build- und Review-Prozess giesst, hält das Markup dauerhaft sauber. Ob Ihr aktuelles Setup hier bereits trägt, lässt sich mit einem Website-Check, der Ihr strukturiertes Markup prüft, in unter einer Minute einschätzen.

Nächster Schritt

Die belastbare Antwort auf die Eingangsfrage ist unbequem ehrlich: Es gibt kein KI-Zitations-Schema, das Sie kaufen oder einbauen könnten. Was es gibt, ist ein sauberer Emission-Pattern — server-gerendertes JSON-LD, ein über @id verknüpfter Entity-Graph, deckungsgleich mit dem sichtbaren Inhalt. Diesen Pattern kontrolliert ein Headless-Frontend präziser als ein theme-basiertes Setup mit gestapelten Plugins. Wie dieser Ansatz im Ganzen aussieht, zeigt unser Headless-WordPress-Ansatz im Überblick.

Wenn Sie wissen wollen, wie Ihr aktuelles Markup beim Thema Article-, Person- und Organization-Schema dasteht, liefert der kostenlose Website-Check eine erste Orientierung — ohne dass Sie Daten preisgeben müssen. Und wenn Sie die strukturierten Daten Ihres Headless-Frontends konkret durchsprechen wollen, klären wir das gerne in einem Erstgespräch — 15 Minuten, kostenlos: welche Felder Sie heute pflegen, wie sie im Frontend gerendert werden und wo der Entity-Graph noch Lücken hat.