Structured Data Audit: Warum JSON-LD allein keine gute Sichtbarkeit garantiert

internet ai

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:

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:

  1. JSON-LD wird empfohlen, wenn es technisch möglich ist.
  2. Strukturierte Daten müssen den allgemeinen und typ-spezifischen Richtlinien entsprechen.
  3. Valides Markup garantiert kein Rich Result.
  4. Strukturierte Daten dürfen nicht irreführend sein.
  5. Markup muss die sichtbaren Inhalte der Seite repräsentieren.
  6. Inhalte, die im Markup beschrieben werden, dürfen nicht vor Nutzer:innen versteckt sein.
  7. 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: BlogPosting oder Article
  • Eine Produktseite: Product oder SoftwareApplication, je nach Kontext
  • Eine Unternehmensseite: Organization
  • Eine Standortseite: LocalBusiness, falls passend
  • Eine Navigationsstruktur: BreadcrumbList
  • Eine Suchfunktion: WebSite mit SearchAction, 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.txt relevante 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:

  • name
  • url
  • logo
  • sameAs
  • contactPoint
  • foundingDate
  • address, falls relevant
  • brand, 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:

  • headline
  • description
  • datePublished
  • dateModified
  • author
  • publisher
  • image

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:

  1. Startseite und Organization/WebSite
  2. wichtigste Produkt- oder Leistungsseiten
  3. wichtigste Ratgeber- und Blogartikel
  4. Seiten mit hohem organischem Potenzial
  5. 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

  1. Wichtige URLs auswählen
    Startseite, wichtigste Produktseiten, wichtigste Ratgeberseiten und Seiten mit hohem organischem Potenzial.

  2. Basic SEO Check durchführen
    Prüfen, ob Title, Description, Headings, Links und sichtbare Struktur sauber sind.

  3. Basic GEO Check durchführen
    Prüfen, ob Maschinen die Seite gut extrahieren, Entitäten erkennen und klare Antwortsignale finden können.

  4. Structured Data manuell gegen sichtbaren Content abgleichen
    Nicht nur Validator-Ergebnis akzeptieren, sondern Page Purpose, Hauptentität und sichtbare Aussagen prüfen.

  5. Korrigieren und priorisieren
    Kritische Fehler zuerst: falscher Seitentyp, versteckte Inhalte, widersprüchliche Entity-Daten, fehlende Pflichtfelder.

  6. Ergebnisse teilen
    SEO, Content, Entwicklung und Management brauchen unterschiedliche Detailgrade. Executive Summary und Developer Guidance sollten getrennt nutzbar sein.

  7. 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.