Structured Data Audit: Warum JSON-LD allein keine gute Sichtbarkeit garantiert
internet aiKnowledge
Viele Websites haben inzwischen irgendwo ein Stück JSON-LD im Quellcode. Oft wird daraus geschlossen: „Structured Data ist erledigt.“
Das ist ein gefährlicher Kurzschluss.
Ein gültiger JSON-LD-Block bedeutet nur, dass maschinenlesbare Daten technisch geparst werden können. Er sagt noch nicht, ob die Daten zur Seite passen, ob sie vollständig sind, ob sie für Google relevant sind, ob sie sichtbare Inhalte korrekt beschreiben oder ob sie eine Marke bzw. ein Angebot eindeutig als Entität verständlich machen.
Ein Structured Data Audit prüft deshalb nicht nur die Syntax. Es prüft, ob strukturierte Daten tatsächlich helfen, Inhalte für Suchmaschinen, Rich Results und KI-basierte Antwortsysteme verständlicher zu machen.
Kurzdefinition: Was sind strukturierte Daten?
Strukturierte Daten sind maschinenlesbare Informationen über den Inhalt einer Webseite. Sie beschreiben zum Beispiel, dass eine Seite ein Artikel, ein Produkt, eine Organisation, ein Event, eine Software-Anwendung oder eine FAQ-Seite ist.
In der Praxis wird dafür häufig Schema.org verwendet. Schema.org ist ein gemeinsames Vokabular für strukturierte Daten im Web und kann mit Formaten wie JSON-LD, Microdata oder RDFa eingesetzt werden. Google empfiehlt JSON-LD, wenn das technische Setup es erlaubt, weil es für Website-Betreiber meist am einfachsten skalierbar und wartbar ist.
Quellen:
- Google Search Central: Introduction to structured data markup
- Google Search Central: General structured data guidelines
- Schema.org: Getting started with schema.org
- JSON-LD.org: JSON-LD
Warum das Thema für SEO und AI Search wichtiger wird
Klassisches SEO hat lange vor allem darauf gezielt, Seiten crawlbar, indexierbar und für Suchanfragen relevant zu machen. Das bleibt zentral. Aber mit AI Overviews, AI Mode, ChatGPT Search, Perplexity und anderen Antwortsystemen kommt eine zweite Ebene dazu: Inhalte müssen nicht nur gefunden, sondern auch korrekt extrahiert, zusammengefasst und einer Entität zugeordnet werden können.
Strukturierte Daten lösen dieses Problem nicht allein. Sie sind kein Ranking-Zauberstab. Aber sie können helfen, Informationen expliziter zu machen:
- Welche Organisation steht hinter der Website?
- Welches Produkt oder welche Dienstleistung wird beschrieben?
- Wer ist Autor oder Herausgeber?
- Welche Seite ist Teil welcher Website-Struktur?
- Welche Entitäten sind mit der Marke verbunden?
- Welche Inhalte auf der Seite sind Frage-Antwort-Strukturen, Artikel, Produkte oder Angebote?
- Welche offiziellen Profile gehören zur Organisation?
Genau deshalb ist Structured Data heute nicht nur ein Rich-Snippet-Thema. Es ist auch ein Thema für Generative Engine Optimization, Entity SEO und maschinenlesbare Content-Architektur.
Das Missverständnis: „Wir haben JSON-LD, also ist alles gut“
Ein Beispiel:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example GmbH",
"url": "https://example.com"
}
Dieser Code kann technisch valide sein. Trotzdem kann er strategisch schwach sein.
Warum?
Er sagt nur: Es gibt eine Organisation mit diesem Namen und dieser URL. Er erklärt aber nicht, ob die Organisation konsistent mit der sichtbaren Website ist, welche offiziellen Social- oder Knowledge-Graph-Profile dazugehören, welche Produkte angeboten werden, ob es mehrere widersprüchliche Organization-Markups auf verschiedenen Seiten gibt oder ob wichtige Page Types gar nicht ausgezeichnet sind.
Ein Structured Data Audit fragt deshalb nicht: „Ist JSON-LD vorhanden?“
Sondern: „Ist die Seite für Maschinen eindeutig, vollständig und glaubwürdig beschreibbar?“
Was Google selbst über strukturierte Daten sagt
Google beschreibt strukturierte Daten als standardisiertes Format, um Informationen über eine Seite bereitzustellen und den Seiteninhalt zu klassifizieren. Gleichzeitig gibt Google mehrere Einschränkungen vor, die für Audits entscheidend sind:
- JSON-LD wird empfohlen, wenn es technisch möglich ist.
- Strukturierte Daten müssen den allgemeinen und typ-spezifischen Richtlinien entsprechen.
- Valides Markup garantiert kein Rich Result.
- Strukturierte Daten dürfen nicht irreführend sein.
- Markup muss die sichtbaren Inhalte der Seite repräsentieren.
- Inhalte, die im Markup beschrieben werden, dürfen nicht vor Nutzer:innen versteckt sein.
- Rich-Result-Fähigkeit ist nicht gleich Ranking-Garantie.
Quelle: Google Search Central – General structured data guidelines
Das ist wichtig, weil viele Audits nur mit einem Validator enden. Ein Validator kann aber vor allem technische Fehler finden. Er beantwortet nicht zuverlässig, ob das Markup inhaltlich sinnvoll, markenkonsistent und strategisch vollständig ist.
Problem → Risiko → Check → Maßnahme
| Problem | Risiko | Check | Maßnahme |
|---|---|---|---|
| JSON-LD ist syntaktisch valide, beschreibt aber nicht den Hauptinhalt der Seite | Google oder andere Systeme ignorieren das Markup oder werten es als wenig hilfreich | Passt @type zum eigentlichen Page Purpose? |
Pro URL den Haupttyp definieren: z. B. Article, Product, Service, Organization, WebPage |
| Markup enthält Inhalte, die für Nutzer:innen nicht sichtbar sind | Verstoß gegen Qualitätsrichtlinien, Verlust von Rich-Result-Fähigkeit | Sind alle ausgezeichneten Aussagen auch im sichtbaren Content vorhanden? | Sichtbaren Content und JSON-LD inhaltlich synchronisieren |
| Mehrere Seiten verwenden widersprüchliche Organization-Daten | Schwache Entitätssignale, uneinheitliche Brand-Interpretation | Name, URL, Logo, sameAs, Kontakt- und Profilangaben vergleichen |
Zentrales Organization-Markup definieren und konsistent ausrollen |
| FAQPage-Markup wird als SEO-Abkürzung eingesetzt | Erwartete Rich Results bleiben aus, weil FAQ-Rich-Results stark eingeschränkt sind | Ist FAQ-Inhalt sichtbar, hilfreich und wirklich passend? | FAQ-Markup nur nutzen, wenn es die Seite korrekt beschreibt; nicht als reinen SERP-Hack |
| Bilder im Markup sind nicht crawlbar | Rich Results können unvollständig bleiben | Sind Bild-URLs erreichbar, indexierbar und passend zur Seite? | Crawlbare, relevante Bilder mit korrekten URLs verwenden |
| JavaScript rendert Markup inkonsistent | Crawler oder Testtools sehen andere Daten als Nutzer:innen | Gerenderten HTML-Stand mit dem erwarteten Markup vergleichen | Rendering, SSR/Prerendering oder saubere clientseitige Einbindung prüfen |
| Keine Verbindung zwischen Website, Brand und offiziellen Profilen | Schwache Entity-Signale für AI Search und Knowledge Graph | Gibt es sameAs, konsistente Organisationsdaten und klare About-/Contact-Seiten? |
Organization, WebSite, About-Seite, Social-/Profil-Links und Markennamen harmonisieren |
| Keine Messung nach Implementierung | Kein Nachweis, ob die Änderung wirkt | Search Console, Rich Results, CTR, Impressionen und Check-Historie prüfen | Vorher-nachher messen und strukturierte Daten regelmäßig re-auditen |
Was ein guter Structured Data Audit prüfen sollte
1. URL-Inventar und Seitentypen
Der Audit beginnt nicht im Code, sondern mit einer einfachen Frage: Welche Arten von Seiten gibt es?
Typische Seitentypen:
- Startseite
- Produktseiten
- Leistungsseiten
- Blog-Artikel
- Ratgeberseiten
- Case Studies
- Kategorie- oder Übersichtsseiten
- Kontaktseite
- Über-uns-Seite
- Preis- oder Planseiten
- Eventseiten
- Jobseiten
- Dokumentationsseiten
Jeder Seitentyp braucht eine andere Markup-Strategie. Eine Produktseite sollte nicht wie ein Blog-Artikel ausgezeichnet werden. Eine Leistungsseite ist nicht automatisch ein Produkt. Eine FAQ-Sektion rechtfertigt nicht immer eine komplette FAQPage-Strategie.
2. Hauptentität pro Seite
Jede wichtige URL sollte eine klare Hauptentität haben.
Beispiele:
- Eine Blogseite:
BlogPostingoderArticle - Eine Produktseite:
ProductoderSoftwareApplication, je nach Kontext - Eine Unternehmensseite:
Organization - Eine Standortseite:
LocalBusiness, falls passend - Eine Navigationsstruktur:
BreadcrumbList - Eine Suchfunktion:
WebSitemitSearchAction, falls sinnvoll
Der häufigste Fehler ist nicht, dass gar kein Schema vorhanden ist. Der häufigste Fehler ist, dass Schema beliebig wirkt.
3. Sichtbarer Content und Markup müssen übereinstimmen
Google verlangt, dass strukturierte Daten die sichtbaren Inhalte der Seite repräsentieren. Das ist ein zentraler Audit-Punkt.
Typische Fehler:
- Bewertungen im JSON-LD, aber keine sichtbaren Bewertungen auf der Seite
- FAQ-Antworten im Markup, aber nicht im sichtbaren Content
- Produktdaten im Markup, aber keine klaren Produktinformationen auf der Seite
- Autor:innenangaben im Markup, aber keine sichtbare Autorenschaft
- Preise, Verfügbarkeiten oder Daten, die nicht mehr aktuell sind
Die Regel ist einfach: Was Maschinen lesen sollen, sollten Menschen ebenfalls nachvollziehen können.
4. Vollständigkeit der Pflicht- und empfohlenen Felder
Viele Schema-Implementierungen enthalten nur minimale Felder. Das ist besser als nichts, aber oft nicht ausreichend.
Ein Audit prüft:
- Sind alle erforderlichen Felder vorhanden?
- Sind empfohlene Felder ergänzt, wenn sie sinnvoll sind?
- Gibt es korrekte URLs, IDs und Referenzen?
- Sind Bilder erreichbar und relevant?
- Sind Datumsfelder korrekt formatiert?
- Sind Autor, Publisher und Organisation sauber verbunden?
- Sind Produkte, Preise und Verfügbarkeiten aktuell?
Je besser die Daten strukturiert und vollständig sind, desto leichter können Suchsysteme sie einordnen.
5. Entity-Konsistenz
Für SEO und AI Search ist Entity-Konsistenz besonders wichtig. Eine Marke sollte überall gleich beschrieben werden.
Prüfpunkte:
- Wird der Unternehmensname konsistent geschrieben?
- Stimmen Logo, URL und Profilangaben überein?
- Gibt es
sameAs-Links zu offiziellen Profilen? - Ist die About-Seite eindeutig?
- Gibt es widersprüchliche Markup-Blöcke auf verschiedenen Seiten?
- Sind Produktnamen und Leistungsbezeichnungen konsistent?
- Ist die Beziehung zwischen Organisation, Website, Produkt und Autor:innen logisch modelliert?
Gerade bei KI-Antwortsystemen kann eine uneindeutige Entität dazu führen, dass Inhalte schlechter zugeordnet oder mit ähnlichen Marken verwechselt werden.
6. Crawlability und Indexierbarkeit
Strukturierte Daten helfen wenig, wenn die Seite oder ihre Ressourcen nicht sauber zugänglich sind.
Ein Audit prüft deshalb:
- Ist die Seite indexierbar?
- Blockiert
robots.txtrelevante Ressourcen? - Gibt es
noindex? - Verweist Canonical auf eine andere URL?
- Ist das Markup im gerenderten HTML sichtbar?
- Können Googlebot und andere relevante Crawler die Seite abrufen?
- Sind Bild-URLs erreichbar?
- Funktioniert die Seite auch bei JavaScript-Rendering?
Das ist besonders wichtig für moderne Websites mit React, Vue, Angular oder anderen JavaScript-Frameworks.
7. Validierung mit mehreren Perspektiven
Ein guter Audit nutzt nicht nur ein Tool.
Sinnvoll sind mindestens:
- Google Rich Results Test
- Google Search Console
- Schema.org Validator
- gerenderter HTML-Check
- Crawl-Test
- manueller Abgleich mit sichtbarem Content
- regelmäßige Re-Checks nach Deployments
Der wichtigste Punkt: Ein Test „ohne Fehler“ ist kein fertiger Audit. Es ist nur ein technischer Zwischenstand.
Welche Schema-Typen für B2B- und SaaS-Websites besonders relevant sind
Für viele B2B- und SaaS-Websites sind folgende Typen besonders interessant:
Organization
Beschreibt das Unternehmen hinter der Website.
Wichtige Felder können sein:
nameurllogosameAscontactPointfoundingDateaddress, falls relevantbrand, falls sinnvoll
WebSite
Beschreibt die Website als Ganzes. Kann mit Suchfunktion oder Publisher-Informationen verbunden werden.
WebPage
Beschreibt eine einzelne Seite und kann mit mainEntity verbunden werden.
BreadcrumbList
Hilft, Seiten in der Website-Struktur einzuordnen.
Article oder BlogPosting
Relevant für Ratgeber, Blogartikel, News und Thought-Leadership-Content.
Wichtige Felder:
headlinedescriptiondatePublisheddateModifiedauthorpublisherimage
Product, SoftwareApplication oder Service
Relevant für Produkt-, SaaS- oder Leistungsseiten. Hier ist besondere Vorsicht nötig: Nicht jedes SaaS-Angebot passt sauber in Product, nicht jede Leistungsseite sollte wie ein Produkt behandelt werden. Entscheidend ist, was die Seite tatsächlich anbietet und wie sichtbar die Informationen sind.
FAQPage
FAQPage-Markup sollte nur verwendet werden, wenn die Seite sichtbare Fragen und Antworten enthält. Außerdem sollte man nicht erwarten, dass FAQ-Markup für die meisten kommerziellen Websites automatisch sichtbare FAQ-Rich-Results erzeugt. Google hat FAQ-Rich-Results 2023 stark eingeschränkt und zeigt sie vor allem für bekannte, autoritative Regierungs- und Gesundheitsseiten.
Quelle: Google Search Central – Changes to HowTo and FAQ rich results
Warum Structured Data auch für LLM-Sichtbarkeit relevant sein kann
LLM-Sichtbarkeit funktioniert nicht identisch wie klassische Google-Rankings. Es gibt nicht den einen „Schema-Rankingfaktor“ für KI-Antworten. Trotzdem ist strukturiertes Markup relevant, weil es Maschinen klare Hinweise liefert.
Für AI Search sind vor allem diese Fragen wichtig:
- Kann ein System die Seite zuverlässig auslesen?
- Ist klar, wer der Herausgeber ist?
- Ist klar, worum es auf der Seite geht?
- Sind wichtige Entitäten eindeutig benannt?
- Sind Quellen, Nachweise und Kontext sichtbar?
- Gibt es kompakte, extrahierbare Antworten?
- Sind strukturierte Daten, Überschriften und sichtbarer Content konsistent?
Das bedeutet: JSON-LD ist nicht die ganze GEO-Strategie. Aber es ist ein Baustein, der mit Content-Struktur, semantischen Überschriften, interner Verlinkung, klaren Definitionen und glaubwürdigen Belegen zusammenspielen muss.
Audit-Checkliste für Teams
Technischer Check
- [ ] JSON-LD ist syntaktisch valide.
- [ ] Markup verwendet passende Schema.org-Typen.
- [ ] Pflichtfelder für relevante Google-Features sind vorhanden.
- [ ] Empfohlene Felder sind ergänzt, sofern sinnvoll.
- [ ] Markup ist im gerenderten HTML sichtbar.
- [ ] Seiten sind crawlbar und indexierbar.
- [ ] Bild-URLs im Markup sind erreichbar.
- [ ] Canonicals und hreflang widersprechen dem Markup nicht.
Inhaltlicher Check
- [ ] Markup beschreibt den sichtbaren Hauptinhalt der Seite.
- [ ] Keine versteckten Bewertungen, FAQs, Preise oder Claims.
- [ ] Inhalte sind aktuell.
- [ ] Datumsangaben stimmen mit dem sichtbaren Content überein.
- [ ] Autor:innen, Publisher und Organisation sind nachvollziehbar.
- [ ] Page Purpose und Schema-Typ passen zusammen.
Entity-Check
- [ ] Organization-Markup ist konsistent.
- [ ]
sameAs-Links zeigen auf offizielle Profile. - [ ] Produkt- und Leistungsnamen sind eindeutig.
- [ ] About-, Contact- und Legal-Seiten widersprechen dem Markup nicht.
- [ ] Wichtige Entitäten werden im sichtbaren Content genannt.
- [ ] Interne Links stärken zentrale Entitäten und Themencluster.
Monitoring-Check
- [ ] Rich Results und strukturierte Daten werden in der Search Console überwacht.
- [ ] Änderungen an Templates werden nach Deployments neu geprüft.
- [ ] Wichtige URLs werden regelmäßig re-auditiert.
- [ ] Ergebnisse sind für SEO, Content und Entwicklung verständlich dokumentiert.
- [ ] Fehler werden nicht nur exportiert, sondern als konkrete Issues verfolgt.
Typische Fehler in Structured-Data-Projekten
Fehler 1: Schema wird als einmaliges Entwickler-Ticket behandelt
Structured Data ist kein einmaliger Einbau. Sobald sich Templates, Inhalte, Produkte, Preise, CMS-Plugins oder Frontend-Rendering ändern, kann Markup kaputtgehen oder veralten.
Besser: Strukturierte Daten als wiederkehrenden Bestandteil von Website-Qualität behandeln.
Fehler 2: Alles wird mit Schema ausgezeichnet, aber nichts wird priorisiert
Mehr Markup ist nicht automatisch besser. Wichtig ist, die relevantesten Seitentypen zuerst sauber zu modellieren.
Priorisierung:
- Startseite und Organization/WebSite
- wichtigste Produkt- oder Leistungsseiten
- wichtigste Ratgeber- und Blogartikel
- Seiten mit hohem organischem Potenzial
- Seiten, die für AI Search oder Vergleichsfragen wichtig sind
Fehler 3: Markup und sichtbarer Content driften auseinander
Das passiert häufig bei CMS-basierten Websites. Content wird redaktionell geändert, JSON-LD bleibt aber gleich. Oder ein Plugin generiert Markup, das nicht zur tatsächlichen Seite passt.
Besser: Markup aus denselben Datenquellen erzeugen wie sichtbaren Content oder regelmäßig automatisiert prüfen.
Fehler 4: FAQ-Markup wird als Shortcut missverstanden
FAQ-Markup kann helfen, Frage-Antwort-Strukturen maschinenlesbar zu machen. Aber es ist kein garantierter SERP-Booster. Seit Googles Einschränkung von FAQ-Rich-Results sollte FAQPage-Markup nicht als isolierte Taktik verkauft werden.
Besser: FAQs sichtbar, hilfreich und thematisch relevant schreiben. Markup nur ergänzen, wenn es die Seite korrekt beschreibt.
Fehler 5: Keine Verbindung zur Marke
Viele Websites markieren einzelne Seiten, aber vergessen die übergeordnete Entität. Für LLM- und Entity-Verständnis ist das schwach.
Besser: Organization, WebSite, About-Seite, offizielle Profile, Produktnamen und interne Linkstruktur zusammendenken.
Verbindung zu +Analytics Pro
+Analytics Pro eignet sich als operativer Layer für Structured-Data-, SEO- und GEO-Checks. Der Nutzen liegt nicht nur im einmaligen Test, sondern in der Kombination aus Analyse, Interpretation, Wiederholung und Nachweisbarkeit.
Basic SEO Checker
Der Basic SEO Checker analysiert grundlegende On-Page-Faktoren wie Title Tags, Meta Descriptions, Heading-Struktur, Alt-Texte und interne bzw. externe Links. Das ist wichtig, weil strukturierte Daten nur dann sinnvoll wirken, wenn die sichtbare Seite selbst sauber strukturiert ist.
Basic GEO Checker
Der Basic GEO Checker prüft, wie gut eine URL für AI Search und Generative Engine Optimization vorbereitet ist. Dazu gehören laut Produktseite unter anderem Extraction Quality, AI-Bot-Access, Content Architecture, JSON-LD, Core Entity Schema, SameAs Links, Identity Signals, Summary Readiness und Answerability.
Wiederkehrende Checks statt Einmal-Test
+Analytics Pro verbindet Web Analytics, Core Web Vitals und Website Audits in einem System. Checks können wiederholt, Ergebnisse geteilt und Issues zentral verfolgt werden. Für Structured Data ist das besonders relevant, weil Markup nach Relaunches, CMS-Updates oder Template-Änderungen leicht regressieren kann.
Empfohlener Workflow
-
Wichtige URLs auswählen
Startseite, wichtigste Produktseiten, wichtigste Ratgeberseiten und Seiten mit hohem organischem Potenzial. -
Basic SEO Check durchführen
Prüfen, ob Title, Description, Headings, Links und sichtbare Struktur sauber sind. -
Basic GEO Check durchführen
Prüfen, ob Maschinen die Seite gut extrahieren, Entitäten erkennen und klare Antwortsignale finden können. -
Structured Data manuell gegen sichtbaren Content abgleichen
Nicht nur Validator-Ergebnis akzeptieren, sondern Page Purpose, Hauptentität und sichtbare Aussagen prüfen. -
Korrigieren und priorisieren
Kritische Fehler zuerst: falscher Seitentyp, versteckte Inhalte, widersprüchliche Entity-Daten, fehlende Pflichtfelder. -
Ergebnisse teilen
SEO, Content, Entwicklung und Management brauchen unterschiedliche Detailgrade. Executive Summary und Developer Guidance sollten getrennt nutzbar sein. -
Regelmäßig erneut prüfen
Nach Deployments, CMS-Updates, Template-Änderungen und größeren Content-Updates.
Beispiel: Gute Fragen für ein internes Structured Data Audit
- Welche Entität soll diese Seite eindeutig repräsentieren?
- Ist der wichtigste Inhalt der Seite auch im Markup abgebildet?
- Gibt es Inhalte im Markup, die Nutzer:innen nicht sehen?
- Ist der gewählte Schema-Typ wirklich der spezifischste passende Typ?
- Sind Organization- und Website-Daten über alle Templates hinweg konsistent?
- Sind Bilder, URLs und Profile crawlbar?
- Sind Produkt-, Preis- oder Verfügbarkeitsangaben aktuell?
- Ist der Markup-Block auch im gerenderten HTML vorhanden?
- Gibt es widersprüchliche JSON-LD-Blöcke?
- Können Content-Team und Entwicklung die Findings in konkrete Aufgaben übersetzen?
Fazit
JSON-LD ist ein gutes Format. Aber JSON-LD allein ist keine Sichtbarkeitsstrategie.
Ein wirksamer Structured Data Audit prüft, ob strukturierte Daten technisch valide, inhaltlich korrekt, sichtbar belegbar, crawlbar, vollständig und entitätsstark sind. Erst dann helfen sie Suchmaschinen und KI-Systemen, Inhalte besser einzuordnen.
Für Unternehmen, Agenturen und SEO-Teams liegt der eigentliche Hebel nicht im einmaligen Einbau eines Schema-Plugins. Der Hebel liegt in einem wiederholbaren Prozess:
prüfen, interpretieren, korrigieren, messen, erneut prüfen.
Genau an dieser Stelle passt +Analytics Pro: als System, das SEO-, GEO- und Website-Checks nicht als isolierte Momentaufnahme behandelt, sondern als laufende Qualitäts- und Sichtbarkeitsarbeit.
Häufig gestellte Fragen
- Ist JSON-LD besser als Microdata oder RDFa?
Google unterstützt JSON-LD, Microdata und RDFa. Google empfiehlt JSON-LD, wenn das Setup es erlaubt, weil es meist einfacher zu implementieren und bei größeren Websites besser wartbar ist.
Quelle: Google Search Central – Introduction to structured data
- Garantieren strukturierte Daten Rich Results?
Nein. Google sagt ausdrücklich, dass korrektes Markup keine Garantie für Rich Results ist. Rich Results hängen von vielen Faktoren ab, darunter Suchkontext, Gerät, Qualitätsrichtlinien und die Frage, ob Google das Feature für diese Seite bzw. diesen Inhalt ausspielen möchte.
Quelle: Google Search Central – General structured data guidelines
- Sind strukturierte Daten ein Rankingfaktor?
Strukturierte Daten sollten nicht als direkter Ranking-Hebel verstanden werden. Ihr primärer Nutzen liegt darin, Inhalte maschinenlesbarer zu machen und die Berechtigung für bestimmte Suchdarstellungen zu ermöglichen. Indirekt können bessere Verständlichkeit, bessere SERP-Darstellung und bessere Content-Struktur natürlich positive Effekte haben.
- Sollte jede Website FAQPage-Markup verwenden?
Nein. FAQPage-Markup sollte nur eingesetzt werden, wenn die Seite sichtbare, echte Fragen und Antworten enthält. Außerdem zeigt Google FAQ-Rich-Results seit 2023 nur noch stark eingeschränkt, vor allem für bekannte, autoritative Regierungs- und Gesundheitsseiten.
Quelle: Google Search Central – Changes to HowTo and FAQ rich results
- Was ist der Unterschied zwischen SEO-Check und GEO-Check?
Ein SEO-Check prüft klassische On-Page-Signale wie Title, Description, Überschriften, Links und Bildoptimierung. Ein GEO-Check prüft zusätzlich, wie gut Inhalte für KI-basierte Antwortsysteme extrahierbar, verständlich und entitätsklar sind. Dazu gehören unter anderem JSON-LD, SameAs-Links, Content-Architektur und Answerability.
- Wie oft sollte man strukturierte Daten prüfen?
Mindestens nach jedem größeren Deployment, CMS-Update, Template-Änderung oder Relaunch. Für wichtige kommerzielle Seiten ist ein wiederkehrender monatlicher oder quartalsweiser Check sinnvoll. Bei dynamischen Websites, Shops oder SaaS-Marketingseiten können häufigere Checks sinnvoll sein.