Schema.org 2026: Welche JSON-LD-Typen LLMs als Faktenbasis lesen

Wenn ChatGPT oder Perplexity eine Antwort generieren, ziehen sie ihre Fakten aus zwei Quellen: dem Fließtext einer Seite — und dem strukturierten JSON-LD-Block, der unsichtbar im Quelltext steht. Der zweite Weg ist für LLMs der schnellere und verlässlichere. Wer dort sauber arbeitet, wird zitiert. Wer es Plugins überlässt, hofft.

Dieser Guide zeigt, welche Schema-Typen 2026 wirklich gelesen werden, was Plugins typischerweise weglassen — und wo der Unterschied zwischen “vorhanden” und “zitierfähig” liegt.

Kurz: Was ist Schema.org?

Schema.org ist ein gemeinsames Vokabular von Google, Microsoft, Yahoo und Yandex, mit dem Websites strukturierte Daten ausliefern können. Statt nur Fließtext zu schreiben, hängen Sie an die Seite einen unsichtbaren JSON-LD-Block, der explizit benennt: “Das hier ist ein Unternehmen mit Adresse X, Telefon Y, Bewertung 4.8 von 47 Stimmen.”

Maschinen — Google-Crawler, LLMs, Sprachassistenten — können diese Information ohne Sprachmodell direkt auswerten. Das ist schneller, billiger und weniger fehleranfällig als Text-Parsing.

Welche Typen sind 2026 wirklich relevant?

Aus unserer Arbeit mit GEO-Audits sehen wir drei Kategorien:

Pflicht (ohne diese werden Sie nicht erfasst)

• Organization oder LocalBusiness — wer Sie sind, wo Sie sitzen, wie man Sie erreicht. Ohne diese Basis kein Eintrag in Knowledge Graph oder LLM-Wissen.
• WebSite + WebPage — die Seite selbst, mit Beschreibung und Sprache.
• BreadcrumbList — die Hierarchie, in der die Seite liegt. Wichtig für LLM-Kontext.

Hochwirksam für LLM-Zitierung

• FAQPage — Q&A-Blöcke werden von LLMs überproportional oft wörtlich zitiert. Wenn Sie eine konkrete Frage in Ihrem Artikel beantworten, packen Sie es als FAQPage-Markup ein.
• HowTo — Schritt-für-Schritt-Anleitungen werden von ChatGPT und Perplexity gerne als Antwort-Vorlage übernommen.
• Article + author-Verknüpfung mit Person (E-E-A-T) — LLMs gewichten Quellen mit nachvollziehbarer Autoren-Identität höher.
• Service mit Offer — bei Dienstleistern: konkrete Preise und Verfügbarkeit. Wird in Antworten zu “Was kostet X?” zitiert.

Nice-to-have, kontextabhängig

• Product + AggregateRating — für Shops kritisch, für Service-Sites optional.
• Dataset — wenn Sie eigene Statistiken oder Studien veröffentlichen. Zitiert in Recherche-Antworten.
• VideoObject — wenn Sie Videos einbetten.

Was Plugins typischerweise weglassen

YOAST, RankMath und AIOSEO erzeugen automatisch ein Basis-Schema. Was sie aber selten korrekt machen:

• Verschachtelung. Ein Service-Eintrag, der provider als verlinkten Organization-Knoten referenziert, ist deutlich aussagekräftiger als zwei isolierte Schemas. Plugins lassen die Verlinkung oft weg.
• Author-Identität. Plugins setzen meist "author": "Max Mustermann" als String, nicht als verlinktes Person-Objekt mit sameAs zu LinkedIn, Wikidata oder eigener Über-uns-Seite. Für E-E-A-T-Bewertung in LLMs ist das ein Verlust.
• Preise und Verfügbarkeit. Service-Schemas ohne Offer-Block sind für “Was kostet X?”-Antworten wertlos. Plugins lassen das oft offen, weil es im UI keine Felder dafür gibt.
• Spezifische Typen. Statt LocalBusiness wäre MedicalClinic, LegalService, AutoRepair oder HomeAndConstructionBusiness präziser. Plugins fallen meist auf den generischen Eltern-Typ zurück.

Wie wir es bei webAION lösen

JSON-LD direkt im Build, nicht über Plugin. Konkret:

1. Pro Service-Seite ein zentrales Schema-Helper-Modul (src/utils/schema.ts), das Organization, LocalBusiness, Service, FAQPage und BreadcrumbList aus typisierten Datenquellen erzeugt.
2. Cross-References per @id-Knoten, sodass LLMs Service und Organization als verbundene Entitäten erfassen — nicht als isolierte Inseln.
3. Validation in CI: ein Test prüft, dass jede Service-Page mindestens Service, Organization und BreadcrumbList ausliefert.
4. Manueller Schema-Audit pro Quartal: Was hat Schema.org neu eingeführt? Welche Typen lohnen sich nachzurüsten?

Die häufigsten Fehler, die wir in Audits sehen

• Schema-Markup nur auf der Startseite, nicht auf Unterseiten.
• Veraltete Pflichtfelder (z.B. OpeningHoursSpecification mit veraltetem Format).
• @id fehlt oder wird inkonsistent vergeben — LLMs können Entitäten nicht zusammenführen.
• Schema-Inhalt widerspricht dem Fließtext — z.B. "telephone": "+491234" im Schema, aber im Footer steht eine andere Nummer. LLMs werten das als Vertrauensbruch.

Quick-Check für Ihre Site

1. Öffnen Sie Ihre Startseite und schauen Sie in den Quelltext: Strg+U, dann Strg+F nach application/ld+json.
2. Kopieren Sie den JSON-Block in den Schema Markup Validator.
3. Prüfen Sie: Steht die richtige @type-Klasse? Sind Adresse, Telefon, Bewertungen drin? Gibt es eine BreadcrumbList?
4. Wenn nein: Plugin-Konfiguration prüfen — oder Markup direkt im Code ergänzen.

Wann lohnt sich ein externer Schema-Audit?

Bei Sites über 100 indizierte Pages, bei E-Commerce und bei lokalen Dienstleistern mit Branchenverzeichnis-Auftritten. Hier macht Schema-Tiefe den Unterschied zwischen “vorhanden” und “zitiert”. Für eine Onepager-Visitenkarte reicht der manuelle Quick-Check.

Wer mehr will: Unser GEO-Audit oder das WordPress Performance-Audit prüft Schema-Bestand, Verschachtelungs-Tiefe und Author-Identitäten — und liefert eine Mangelliste mit konkreten JSON-LD-Diffs.