TL;DR: Schema.org/JSON-LD wird 2026 vom Nice-to-have zum Pflichtbaustein – nicht als Ranking-Trick, sondern für Verständnis, Eligibility und korrekte Zuordnung in KI-Features (z. B. AI Overviews). Sichtbarkeit und CTR steigen über klare Entitäten, saubere Relationen und konsistentes Markup – nicht über Hacks.
Organization, WebSite/WebPage, BreadcrumbList, Article/Product (+ ProductGroup), on-page FAQPage.@id/sameAs, Validator + Search Console, bei Commerce Schema + Feed (Merchant Center).Written by Sebastian Geier
Oct. 21, 2025

Kurzfassung in einem Satz:
Strukturierte Daten (Schema.org, ideal per JSON‑LD) werden vom „Nice‑to‑have“ zum Pflichtbaustein – nicht nur für klassische SEO‑Rich‑Results, sondern auch, damit KI‑Features wie AI Overviews und Antwort‑Engines deinen Content sicher erkennen, korrekt einordnen und seriösen Quellen zuweisen können.
Google bestätigt: Strukturierte Daten helfen, Inhalte zu verstehen und für reichhaltige Darstellungen (Rich Results) überhaupt erst in Frage zu kommen. JSON‑LD wird als Implementierungsform empfohlen (neben Microdata & RDFa).
AI Overviews & AI‑Features: Google beschreibt offiziell, wie AI‑Features Inhalte finden – saubere Struktur und klare Entitäten erhöhen die Chance, korrekt zitiert zu werden.
Der Markt bewegt sich: AI Overviews sind live, wurden global ausgerollt und verändern Klickströme – inklusive öffentlicher Debatten und Beschwerden von Verlagen. Schema‑Sauberkeit wird zum Risikopuffer gegen Fehlzuordnungen.
Schemas sind standardisierte, maschinenlesbare Datenmodelle (Vokabular: Schema.org), mit denen du Suchmaschinen mitteilst, was auf einer Seite steht (Produkt, Artikel, Person, Event …) und wie Dinge zusammenhängen. Du implementierst sie idealerweise als JSON‑LD im:
<script type="application/ld+json">
Google hat AI Overviews 2024 in den USA live gestellt und danach sukzessive auf weitere Länder ausgeweitet; es handelt sich um generative Zusammenfassungen mit Quelllinks.
Google erläutert in „AI features and your website“, wie Inhalte in AI‑Erlebnisse gelangen – klare, strukturierte Informationen unterstützen das zuverlässige Erkennen.
Gleichzeitig wurden/werden klassische Rich‑Result‑Oberflächen gestrafft (siehe z. B. HowTo/FAQ, Sitelinks Search Box). Konsequenz: Schema bleibt wichtig – aber du musst aktuell markieren, was Google wirklich nutzt.
Rich Results: Sichtbare Aufwertungen wie Produkt‑Snippets, Review‑Sterne, Videos mit Key Moments, Job‑Kacheln, Local‑Features u. v. m. – nur bei gültigem Markup.
Entitäts‑Klarheit: Organization, Person, Product etc. mit Beziehungen (z. B. provider, founder, isPartOf) machen Content für Such‑ & Antwort‑Systeme eindeutig.
AEO‑Tauglichkeit: KI‑Features extrahieren faktennahe Informationen; korrektes Schema erleichtert Quellenzuordnung und Darstellung in AI‑Erlebnissen.
Plattform‑Breite: Nicht nur Google – Bing unterstützt Schema.org (inkl. JSON‑LD).
Organization: Offizielle Unternehmensdaten, u. a. Logo, rechtliche Namen, Kontakt, Social‑Profile. Tipp: auf der Startseite platzieren.
LocalBusiness (Filialen/Standorte): Adresse, Öffnungszeiten, Geo‑Daten, Reservierungen. Hilft u. a. bei lokalen Features.
WebSite + Site Names: Sauberer Seitenname, alternative Namen.
Product + Offer / AggregateOffer: Preis, Verfügbarkeit, Bewertungen; Merchant Listings & Product Snippets.
Produktvarianten (ProductGroup, hasVariant, variesBy): saubere Abbildung von Größen/Farben usw.
Review / AggregateRating: Review‑Snippets (redaktionelle/benutzerbasierte Bewertungen).
Article / NewsArticle / BlogPosting: bessere Darstellung von Titel/Bild/Datum, News‑Eignung.
VideoObject (+ Clip / SeekToAction): Key‑Moments, LIVE‑Badge.
FAQPage: weiterhin nützlich auf der Seite – in der Suche aber nur noch für Regierungs‑/Gesundheitsseiten sichtbar.
QAPage / EducationQAPage: Lern‑Q&A/Flashcards.
Dataset: Für Datensammlungen (auch ML‑Artefakte).
Speakable (BETA): Ausgewählte Textstellen für Voice/Assistant – limitiert.
ProfilePage: Offizielle Creator/Autor‑Profile – Disambiguierung & bessere Darstellung.
DiscussionForumPosting: Foren/Community‑Beiträge.
JobPosting: Job‑Erlebnis in der Suche.
Event: Termine, Orte, Tickets (Event‑Features).
Priorisieren: Organization/LocalBusiness → WebSite (Site Name) → Kern‑Content‑Typ (z. B. Product/Article/Video) → ergänzende Features (Review, BreadcrumbList, FAQPage nur falls sinnvoll).
FAQ‑Rich‑Results: Sichtbarkeit stark reduziert – nur für „bekannte, autoritative Regierungs‑ oder Gesundheits‑Websites“. Auf anderen Seiten weiterhin sinnvoll für Nutzer*innen, aber ohne SERP‑FAQ‑Box.
HowTo‑Rich‑Results: eingestellt (erst mobil, dann auch Desktop). Entsprechende Boxen erscheinen nicht mehr.
Sitelinks Search Box: abgeschafft (Nov. 2024). Das dazugehörige Markup wird nicht mehr genutzt; Entfernen ist nicht nötig.
Produkt‑Varianten: Neues, offizielles Varianten‑Markup (ProductGroup) für bessere Darstellung und Abgleich mit Merchant Center.
Profile & Foren: Neue Dokumentation & Search Console‑Unterstützung für ProfilePage und DiscussionForumPosting.
Takeaway: Markup‑Strategien regelmäßig prüfen – Google passt Feature‑Sets an, AI‑Features wachsen. Ein Blick in die Search Gallery zeigt, was heute unterstützt ist.
Hinweis: JSON‑LD spiegelt stets sichtbare Inhalte. Keine Fantasie‑Werte, keine versteckten Versprechen – sonst drohen Inaktivität oder Verstöße gegen die Richtlinien.
Ziele: Entität fixieren (Organization), Site‑Name (WebSite), Social‑Profile (sameAs).
<script type="application/ld+json">
{
"@context":"https://schema.org",
"@graph":[
{
"@type":"Organization",
"@id":"https://www.example.com/#org",
"name":"Beispiel GmbH",
"url":"https://www.example.com/",
"logo":"https://www.example.com/logo.svg",
"sameAs":[
"https://www.linkedin.com/company/beispiel",
"https://x.com/beispiel"
]
},
{
"@type":"WebSite",
"@id":"https://www.example.com/#website",
"url":"https://www.example.com/",
"name":"Beispiel",
"publisher":{"@id":"https://www.example.com/#org"}
}
]
}
</script>
Warum so? @id verknüpft deine Entitäten zu einem Graphen (saubere Wiederverwendung). Site‑Name & Organization helfen bei Eindeutigkeit.
<script type="application/ld+json">
{
"@context":"https://schema.org",
"@type":"LocalBusiness",
"@id":"https://www.example.com/berlin/#store",
"name":"Beispiel GmbH – Berlin",
"url":"https://www.example.com/berlin/",
"image":"https://www.example.com/berlin/fassade.jpg",
"address":{
"@type":"PostalAddress",
"streetAddress":"Musterstr. 1",
"postalCode":"10115",
"addressLocality":"Berlin",
"addressCountry":"DE"
},
"geo":{"@type":"GeoCoordinates","latitude":52.532,"longitude":13.384},
"telephone":"+49-30-123456",
"openingHoursSpecification":[
{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"09:00","closes":"18:00"}
],
"parentOrganization":{"@id":"https://www.example.com/#org"}
}
</script>
Für Local‑Features und konsistente NAP‑Daten.
<script type="application/ld+json">
{
"@context":"https://schema.org",
"@type":["WebPage","Service"],
"name":"Webdesign & SEO",
"url":"https://www.example.com/webdesign-seo/",
"provider":{"@id":"https://www.example.com/#org"},
"serviceType":["Webdesign","SEO","AEO"],
"areaServed":["DE","AT","CH"],
"inLanguage":"de"
}
</script>
Mehrfachtyp (WebPage+Service) ist zulässig – solange Inhalte sichtbar sind.
<script type="application/ld+json">
{
"@context":"https://schema.org",
"@graph":[
{
"@type":"ProductGroup",
"@id":"https://shop.example.com/p/hoodie-123#group",
"name":"Hoodie 123",
"productGroupID":"hoodie-123",
"variesBy":["color","size"],
"hasVariant":[
{
"@type":"Product",
"@id":"https://shop.example.com/p/hoodie-123?color=black&size=m#variant",
"sku":"H123-BLK-M",
"color":"Black",
"size":"M",
"isVariantOf":{"@id":"https://shop.example.com/p/hoodie-123#group"},
"brand":{"@type":"Brand","name":"BeispielWear"},
"offers":{"@type":"Offer","priceCurrency":"EUR","price":"49.90",
"availability":"https://schema.org/InStock","url":
"https://shop.example.com/p/hoodie-123?color=black&size=m"}
}
],
"brand":{"@type":"Brand","name":"BeispielWear"}
},
{
"@type":"AggregateRating",
"itemReviewed":{"@id":"https://shop.example.com/p/hoodie-123#group"},
"ratingValue":"4.6",
"reviewCount":"128"
}
]
}
</script>
So unterstützt du Produktvarianten sauber – wichtig für Merchant Listings & Snippets.
<script type="application/ld+json">
{
"@context":"https://schema.org",
"@type":"BlogPosting",
"headline":"Schema-Markup 2025: Was wirklich zählt",
"datePublished":"2025-10-21",
"dateModified":"2025-10-21",
"author":{"@type":"Person","name":"Max Beispiel","url":"https://www.example.com/autoren/max"},
"publisher":{"@id":"https://www.example.com/#org"},
"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.example.com/blog/schema-2025/"}
}
</script>
Autor*innen sollten zusätzlich eine ProfilePage besitzen und intern verlinkt werden.
<script type="application/ld+json">
{
"@context":"https://schema.org",
"@type":"VideoObject",
"name":"SEO-Schema in 10 Minuten",
"description":"In 10 Minuten zu sauberem JSON-LD.",
"thumbnailUrl":["https://www.example.com/thumb.jpg"],
"uploadDate":"2025-10-01",
"contentUrl":"https://www.example.com/video/seo-schema.mp4",
"embedUrl":"https://www.example.com/video/seo-schema/",
"hasPart":[
{"@type":"Clip","name":"Einführung","startOffset":0,"endOffset":60},
{"@type":"Clip","name":"Produktvarianten","startOffset":180,"endOffset":360}
],
"potentialAction":{
"@type":"SeekToAction",
"target":"https://www.example.com/video/seo-schema?t={seek_to_second_number}"
}
}
</script>
Ermöglicht Key‑Moments/Kapitel in der Suche.
Eindeutige Entitäten: Organization/Person sauber definieren und verknüpfen (@id, sameAs).
„Answer‑Ready“ Content: Präzise Absätze, definierte FAQs (auch ohne SERP‑Box nützlich), klare Definitionen, Zahlen mit Quelle. Schema stützt das Verständnis, ersetzt aber keine Qualität.
Profil‑Signale: ProfilePage für Autorinnen/Expertinnen anlegen, Foren/UGC via DiscussionForumPosting sauber beschreiben.
Medien aufwerten: Video‑Chapters via Clip/SeekToAction – KI und Nutzer finden schneller zum relevanten Teil.
Produktdaten doppelt absichern: Markup + Merchant Center‑Feed – höhere Abdeckung in Shopping‑Erlebnissen.
Validieren:
– Rich Results Test (Google) prüft Feature‑Eligibility.
– Schema Markup Validator (Schema.org) prüft Schema‑Syntax/Graph.
Überwachen: Search Console – Rich‑Result‑Reports & „Unparsable structured data“. Fehler/Warnungen zeitnah beheben.
Richtlinien: Halte dich an die General Structured Data Guidelines – nur Sichtbares markieren, korrekte Typen, keine Täuschung.
Nur „WebPage“ ausrollen: Nutzt Potenzial nicht. Ergänze konkrete Typen (z. B. Service, Product, Article).
Unverknüpfte Entitäten: Ohne @id/Bezüge entsteht ein Fragment‑Zoo. Baue einen zusammenhängenden Graphen.
Unsichtbare oder falsche Inhalte markieren: Verstößt gegen Richtlinien; macht Rich‑Results unwahrscheinlich.
Veraltete Features (z. B. HowTo‑Boxen, Sitelinks Search Box) weiter „erzwingen“: kostet Zeit, bringt nichts. Fokus auf unterstützte Features.
Inventur: Seitentypen & Ziele (Brand, Produkte, Standorte, Content, Video, Jobs).
Datenmodell: Definiere Entitäten & Beziehungen (Org ↔ Standorte ↔ Services/Produkte ↔ Content).
Implementierung: JSON‑LD‑Templates (CMS‑Felder → Markup).
QA‑Schleife: Validatoren, Staging‑Tests, Rollout in Wellen.
Monitoring: Search Console Reports & Logfiles, regelmäßige Schema‑Audits (halbjährlich).
Aktualität: Search Gallery beobachten – Features ändern sich.
Organization + WebSite (Site Name) auf der Startseite.
LocalBusiness auf Standortseiten.
Kern‑Content‑Schemas (Product, Article, VideoObject, JobPosting …) korrekt & vollständig.
Varianten‑Logik bei E‑Com (ProductGroup).
Reviews & Ratings sauber (keine Selbstbewertungen).
ProfilePage/DiscussionForumPosting für Creator/Community.
Rich Results Test bestanden; Validator grün.
Search‑Console‑Reports ohne kritische Fehler.
Weil sich Suche rasant Richtung Antwort-Engines bewegt (AI Overviews, Copilot, Perplexity, Chatbots) und saubere Entitäten/Beziehungen die Erkennung, Attribution & Zitierfähigkeit verbessern. Gleichzeitig wurden einige klassische Rich Results beschnitten – was strukturelle Qualität wichtiger macht als Feature-Jagd.
Schema.org ist ein gemeinsames Vokabular, mit dem Inhalte maschinenlesbar ausgezeichnet werden (z. B. Product, Article, Organization). Suchmaschinen verstehen dadurch Wer? Was? Wie hängt es zusammen? – nicht nur Wörter, sondern Entitäten & Relationen.
Weniger Pixel für klassische Snippets, mehr Antwortkarten. Strukturierte Daten stützen Entity-Resolution, Quellenzuordnung und Snippet-Generierung in KI-Systemen – kritisch für Sichtbarkeit und Brand Attribution, obwohl kein direkter Ranking-Boost.
SEO: Eligibility für Rich-Results, bessere CTR, robustere Kanonisierung/Disambiguierung. AEO: klare Entitäten (@id, sameAs), Beziehungen (about, mentions), wahrheitsgetreue Properties – damit KI-Antworten dich korrekt erkennen und zitieren.
Must-have: Organization, WebSite/WebPage, BreadcrumbList, Article/BlogPosting (Content), Product/Offer (Commerce). Situativ: FAQPage (UX), ProfilePage (Autor*innen), Dataset (Daten), VideoObject, Event. Varianten: ProductGroup mit hasVariant.
HowTo & einige Rich-Features stark reduziert/entfallen; FAQ-Box meist nur noch für Regierungs-/Gesundheitsseiten; Sitelinks Search Box wird ignoriert; Speakable sehr limitiert. Fundamentale Typen bleiben relevant.
Nutze WebPage als Container (isPartOf, primaryImageOfPage) und setze die Hauptentität als mainEntity (z. B. Product, Service, Article). Verknüpfe mit stabilen @id-URIs, konsistenten sameAs und sinnvollen Relationen (publisher, itemReviewed, isVariantOf).
Klare Entitäten, vollständige Properties, konsistente IDs, sichtbare Inhalte (no hidden markup), präzise Zusammenfassungen (Intro/FAQ), und autorisierte Profile (ProfilePage für Autor*innen). Ergänze about/mentions für thematische Einordnung.
Rich Results Test (Feature-Eligibility & Rendering) + Schema Markup Validator (Schema.org-Konformität). Danach Search Console (Fehler/Warnungen, Suchauftritte). Nach Deploys immer live-URLs prüfen, nicht nur Staging.
Search-Console-Berichte zu Rich-Results & Performance (Filter „Suchauftritte“), plus Analytics-Metriken (CTR, CR, Micro-KPIs). Nutze Vor/Nach-Vergleiche auf Template-Ebene und beobachte SERP-Layout-Änderungen.
„Unparsable structured data“ in der Search Console. Im Validator reproduzieren, fixen (JSON-Kommas/Typen/@context/@type), neu ausrollen, erneut validieren. Rendereffekte (hydration) im Blick behalten.
Eligibility ≠ Garantie. Es zählen auch Richtlinien, Seitenqualität (EEAT-Signale), Query-Relevanz, Nachfrage und SERP-Platz. Prüfe die Search-Gallery-Voraussetzungen und ob Inhalte/Preise/Verfügbarkeit sichtbar sind.
Nein. Ignoriertes Markup (z. B. Sitelinks Search Box) verursacht keine Fehler. Entfernen nur, wenn es Wartung vereinfacht. Strukturelle Kerntypen beibehalten.
So viele empfohlene Felder wie sinnvoll. Vollständig, aber wahrheitsgemäß. Falsche Daten schaden mehr als sie nützen.
Definiere Owner, Typen-Prioritäten, Quellen der Wahrheit (PIM/CMS), QA-Pipeline (Validator → Staging → Live), Monitoring (SC-Reports), Change-Log & Deprecation-Handling. Feature-Flags und Versionierung (Git) nutzen.
Ja – aber mit klarer Ownership, Versionskontrolle, sauberem Timing und Inhaltswahrheit. Kritische Commerce-Typen bevorzugt serverseitig ausspielen, um Flicker/Inkonsistenzen zu vermeiden.
Empfohlen: name, url, logo, contactPoint, sameAs. Konsistente NAP-Daten, eindeutige @id pro Entität, und saubere sameAs auf offizielle Profile.
Regelmäßig Search-Gallery/Docs prüfen, Changelogs verfolgen, Deprecations tracken, QA-Routine mit Automatisierung (Deploy-Hooks, regelmäßige Re-Validierung) etablieren.
Nein. Sie sind Eligibility-Faktoren und helfen beim Verstehen. Indirekte Effekte via Sichtbarkeit/CTR sind möglich, aber kein direkter „Boost“.
Alle werden unterstützt; JSON-LD ist entkoppelt vom HTML, wartungsärmer und von Google empfohlen – ideal für Versionierung & QA.
Kein Garantieschalter – aber saubere Struktur & klare Entitäten unterstützen Erkennung, Zitat & Zuordnung.
Auf der Seite ja (UX). In der Suche wird die Box fast nur noch bei Regierungs-/Gesundheitsseiten gezeigt.
Als Rich Result: ja. Inhalte weiter veröffentlichen – nur nicht auf das SERP-Feature setzen.
Nicht nötig. Google nutzt sie nicht mehr, aber das Vorhandensein schadet nicht.
Über stabile @id-URIs und Relationen (publisher, isPartOf, itemReviewed, isVariantOf, about, mentions). sameAs zu offiziellen Profilen ergänzen.
ProductGroup mit hasVariant/variesBy. Varianten müssen auf der Seite sichtbar und auswählbar sein.
Rich Results Test (Eligibility) und Schema Markup Validator (Konformität) + Search Console Monitoring.
Eligibility ≠ Garantie. Richtlinien, Qualität, Relevanz, Nachfrage & SERP-Layout spielen mit rein.
Ja, wenn beides sichtbar vorkommt. WebPage als Container, mainEntity als Hauptentität.
Schemas werden wichtiger denn je – nicht als Ranking‑Trick, sondern als Datengrundlage für Such‑ und Antwortsysteme.
Wer saubere Entitäten modelliert, richtige Typen nutzt und aktuelle Features im Blick behält, bleibt in SERPs sichtbar – und wird für KI‑Antworten korrekt erkannt und zitiert.
Google Search Central: Intro zu Structured Data; Search Gallery; General Guidelines; Organization; LocalBusiness; Article; Product/Variants; Review Snippet; Video; FAQ; ProfilePage; Discussion Forum; AI‑Features; Rich‑Results‑Test.
Schema.org (Vokabular & Validator).
Bing Webmaster Tools: Structured‑Data‑Hinweise.
AI Overviews: Launch/Erklärung & Umfeld.