Priorisieren · Ziel-Fokus
Schema Markup: Strukturierte Daten mit Entity Maps planen
Schema Markup übersetzt sichtbare Informationen einer Website in maschinenlesbare Aussagen. Dafür stellt Schema.org ein gemeinsames Vokabular bereit. JSON-LD ist das von Google empfohlene Format, um dieses Vokabular in eine Seite einzubetten. Der Code ist allerdings der letzte Übersetzungsschritt, nicht der Anfang.
Valides JSON-LD bedeutet noch nicht, dass das Entitätsmodell korrekt ist. Ein Validator kann fehlerfreie Syntax bestätigen, während im Graphen die falsche Organisation als Herausgeber steht, dieselbe Person mehrfach angelegt wurde oder Eigenschaften ausgezeichnet sind, die auf der Seite gar nicht sichtbar sind. Meine Methode setzt deshalb vor dem Code an: Eine Entity Map hält fest, welche Entitäten existieren, welche Beziehungen belegbar sind und welche Seite welchen Teil davon sichtbar trägt.
Dieser Guide führt durch die ganze Kette: sichtbarer Inhalt → Entitäten und Beziehungen → Entity Map → Schema.org-Typen und Eigenschaften → verbundener JSON-LD-Graph → mehrstufige Prüfung → Beobachtung des Ergebnisses.
Neue Analysen und Anleitungen
Die Produktseite ist nicht die ganze Gleichung
Ein Datenschnitt über fünf Website-Kategorien zeigt, welche Belege KI-Antworten jenseits einzelner Produktseiten heranziehen.
Ein Skill weiß nichts: Markenwissen als OKF-Bundle
Wie Sie Markenwissen als verbundene Markdown-Struktur ablegen, statt bei jeder Aufgabe wieder lose Dateien in den Chat zu laden.
Der Prompt als Lego-Figur
Warum KI-Systeme Fragen in Sub-Queries zerlegen und eine konsistente Entitätsstruktur mehr abdeckt als ein einzelnes Keyword.
Das Wichtigste in Kürze
- Schema Markup bezeichnet die Auszeichnung von Inhalten mit dem Schema.org-Vokabular. Strukturierte Daten sind der Oberbegriff; JSON-LD, Microdata und RDFa sind mögliche Formate.
- Eine Entity Map ist meine Arbeitsmethode vor der Implementierung. Sie beschreibt reale Entitäten, ihre Attribute, ihre Beziehungen und den sichtbaren Beleg auf der Website. Sie ist kein Standard von Google, Schema.org oder W3C.
- Technische Validität ist nur eine Prüfebene. Gültiges JSON, korrekt verarbeitbares JSON-LD und zulässige Schema.org-Eigenschaften beweisen noch nicht, dass der Graph den sichtbaren Inhalt wahrheitsgemäß abbildet.
- Strukturierte Daten garantieren weder bessere Rankings noch Rich Results. Google bezeichnet sie für sich genommen nicht als allgemeinen Rankingfaktor und garantiert auch bei korrektem Markup keine erweiterte Darstellung. Für einen kausalen Effekt auf KI-Zitate enthält die geprüfte Quellenbasis ebenfalls keine belastbare plattformübergreifende Dokumentation.
Was ist Schema Markup und was sind strukturierte Daten?
Strukturierte Daten sind maschinenlesbare Angaben über den Inhalt einer Seite. Schema Markup ist die konkrete Verwendung des Schema.org-Vokabulars innerhalb solcher Daten. JSON-LD ist eines der Formate, in denen diese Angaben ausgedrückt werden.
Die Begriffe beschreiben verschiedene Ebenen:
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| Strukturierte Daten | Oberbegriff für formal organisierte, maschinenlesbare Angaben | Ein Artikel hat einen Autor und ein Veröffentlichungsdatum |
| Schema.org | gemeinsames Vokabular für Typen und Eigenschaften | Article, author, datePublished |
| Schema Markup | Anwendung dieses Vokabulars auf einer Webseite | Eine sichtbare Autorenangabe wird als author ausgezeichnet |
| JSON-LD | JSON-basierte Serialisierung für Linked Data | Ein <script type="application/ld+json"> mit einem verbundenen Graphen |
Die W3C-Empfehlung JSON-LD 1.1 definiert JSON-LD als JSON-basiertes Format zur Serialisierung von Linked Data. Google unterstützt zusätzlich Microdata und RDFa, kennzeichnet JSON-LD in seiner Einführung zu strukturierten Daten aber als empfohlenes Format. Ein praktischer Grund: Das Markup bleibt vom sichtbaren HTML getrennt und lässt sich bei verschachtelten Entitäten übersichtlicher pflegen.
Diese Trennung darf nicht zur inhaltlichen Trennung werden. Was im JSON-LD steht, muss durch den sichtbaren Seiteninhalt gedeckt sein. Andernfalls beschreibt der Code eine andere Seite als der Mensch vor sich sieht.
Strukturierte Daten sind außerdem kein generischer Rankinghebel. Google formuliert ausdrücklich, dass strukturierte Daten für sich genommen kein allgemeiner Rankingfaktor sind. Sie können Google helfen, den Inhalt einer Seite zu verstehen und die Seite für bestimmte Suchdarstellungen qualifizieren. Qualifikation bedeutet noch keine Anzeige.
Warum reicht valides JSON-LD nicht aus?
Weil „valide“ je nach Werkzeug etwas anderes bedeutet. Ein JSON-Prüfer beantwortet eine Syntaxfrage. Der Schema.org Validator prüft ein Vokabular. Der Google Rich Results Test prüft Anforderungen ausgewählter Google-Suchergebnisformate. Keines dieser Werkzeuge kennt automatisch die geschäftliche Wahrheit hinter einer Seite.
Ein technisch gültiger Block kann zum Beispiel behaupten:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Strategieberatung",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "EUR"
}
}Die Syntax ist gültig. Das Modell kann trotzdem falsch sein. Wenn die Seite keinen Preis von null und kein entsprechend beschriebenes Angebot zeigt, passt der offers-Block nicht zum sichtbaren Inhalt. Ob für die Dienstleistung Product, Service oder ein anderer Typ fachlich präziser ist, muss separat anhand des konkreten Angebots geprüft werden. Ein grüner Haken würde in diesem Fall nur bestätigen, dass der Fehler ordentlich formatiert ist.
Die allgemeinen Google-Richtlinien für strukturierte Daten verlangen, dass ausgezeichnete Inhalte für Nutzer sichtbar und repräsentativ für den Hauptinhalt der Seite sind. Google garantiert auch bei korrektem Markup kein Rich Result. Genau deshalb muss die Prüfung über Syntax und Feature-Anforderungen hinausgehen.
Ich trenne vier Fragen:
- Kann ein Parser den Code lesen?
- Verwendet der Code Typen und Eigenschaften aus dem vorgesehenen Vokabular?
- Erfüllt die Seite die dokumentierten Anforderungen für ein bestimmtes Suchfeature?
- Beschreibt der Graph tatsächlich das, was auf der Seite und im Unternehmen belegbar ist?
Die vierte Frage ist die teuerste. Sie lässt sich nicht an einen Validator delegieren.
Was ist eine Entity Map?
Eine Entity Map ist eine Arbeitsunterlage, die relevante Entitäten, ihre Attribute, ihre Beziehungen und die sichtbaren Belege auf der Website vor der technischen Auszeichnung festhält. Ich verwende den Begriff für eine Planungsmethode. Er bezeichnet keine offizielle Architektur von Google, Schema.org oder W3C.
Eine Entität ist dabei ein unterscheidbares Ding: eine Organisation, eine Person, ein Angebot, ein Artikel, eine Website oder ein Ort. Ein Attribut beschreibt die Entität, etwa Name oder Berufsbezeichnung. Eine Beziehung verbindet zwei Entitäten, etwa „Person arbeitet für Organisation“ oder „Artikel wurde von Person verfasst“.
Für eine B2B-Website kann eine kleine Entity Map so beginnen:
| Entität | Relevante Attribute | Beziehung | Sichtbarer Beleg | Geplante Schema.org-Abbildung |
|---|---|---|---|---|
| Beispiel GmbH | Name, URL, Logo | veröffentlicht die Website | Impressum, Footer, Startseite | Organization |
| Lea Sommer | Name, Position | arbeitet für Beispiel GmbH | Teamseite, Autorenbox | Person + worksFor |
| Fachartikel A | Titel, Datum | wurde von Lea Sommer verfasst | Artikelkopf, Autorenbox | Article + author |
| Unternehmenswebsite | Name, URL | wird von Beispiel GmbH veröffentlicht | Domain, Footer | WebSite + publisher |
Die Spalte „sichtbarer Beleg“ ist entscheidend. Sie verhindert, dass die Modellierung zu einer Wunschliste wird. Wenn eine Beziehung auf keiner relevanten Seite nachvollziehbar ist, gibt es zwei saubere Wege: den sichtbaren Inhalt ergänzen oder die Beziehung nicht auszeichnen.
Was häufig als Entity SEO oder Entitäten-SEO bezeichnet wird, beginnt damit nicht beim Einbau möglichst vieler Typen. Es beginnt mit einer konsistenten Antwort auf eine einfachere Frage: Welche Aussagen über dieses Unternehmen kann ein Mensch auf der Website prüfen?
Wie wird aus einer Entity Map ein verbundener Schema.org-Graph?
Der Graph entsteht durch eine kontrollierte Übersetzung. Jede Stufe übernimmt nur Aussagen, die in der vorherigen Stufe belegt wurden. Die Reihenfolge ist eine methodische Empfehlung, keine von Google offengelegte Systemarchitektur.
- Sichtbaren Inhalt erfassen. Welche Namen, Rollen, Leistungen, Daten und Beziehungen stehen tatsächlich auf der Seite?
- Entitäten trennen. Welche eigenständigen Dinge beschreibt der Inhalt?
- Beziehungen benennen. Wer arbeitet für wen, wer veröffentlicht was, welcher Artikel gehört zu welcher Website?
- Entity Map dokumentieren. Jede Aussage erhält eine Quellseite oder ein sichtbares Seitenelement als Beleg.
- Schema.org zuordnen. Für jede Entität und Beziehung werden passende Typen und Eigenschaften gewählt.
- JSON-LD verbinden. Wiederkehrende Entitäten erhalten konsistente
@id-Werte und werden referenziert statt kopiert. - Mehrstufig prüfen. Syntax, Verarbeitung, Vokabular, Feature-Anforderungen und semantische Wahrheit werden getrennt getestet.
- Ergebnis beobachten. Search Console, Suchdarstellungen und gegebenenfalls eigene Retrieval-Messungen zeigen Veränderungen. Sie beweisen ohne kontrolliertes Setup keine Kausalität.
Illustratives Beispiel: Person, Organisation, Website und Artikel
Der folgende Code ist kein universelles Template. Er zeigt nur, wie vier sichtbare Entitäten über stabile Identifikatoren verbunden werden können.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Beispiel GmbH",
"url": "https://example.com/"
},
{
"@type": "Person",
"@id": "https://example.com/team/lea-sommer/#person",
"name": "Lea Sommer",
"jobTitle": "Leiterin Fachredaktion",
"worksFor": {
"@id": "https://example.com/#organization"
}
},
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"name": "Beispiel Fachportal",
"url": "https://example.com/",
"publisher": {
"@id": "https://example.com/#organization"
}
},
{
"@type": "Article",
"@id": "https://example.com/fachartikel-a/#article",
"headline": "Fachartikel A",
"author": {
"@id": "https://example.com/team/lea-sommer/#person"
},
"publisher": {
"@id": "https://example.com/#organization"
},
"isPartOf": {
"@id": "https://example.com/#website"
}
}
]
}Der Code legt Lea Sommer nur einmal als Person an. Der Artikel verweist über author auf denselben Knoten. Website und Artikel verweisen über publisher auf dieselbe Organisation. So bleibt die Identität konsistent, ohne Namen und Eigenschaften in jedem Block neu zu erfinden.
Für Shops endet diese Modellierung nicht an der Produktseite. Welche Seiten jenseits des Angebots als Belege dienen können, behandelt der Beitrag „Die Produktseite ist nicht die ganze Gleichung“. Der vorliegende Guide bleibt bei der Modellierung und technischen Übersetzung.
Welche Schema.org-Typen braucht eine B2B-Website?
Es gibt keine universelle Liste, die jede B2B-Website vollständig einbauen muss. Der richtige Typ folgt aus dem sichtbaren Inhalt und der Funktion der Seite. Ein kleiner, konsistenter Graph ist wertvoller als ein breites Typeninventar ohne Belege.
| Seitentyp | Mögliche primäre Entität | Typische Schema.org-Typen | Sinnvolle Beziehungen | Vor der Umsetzung prüfen |
|---|---|---|---|---|
| Startseite | Unternehmen und Website | Organization, WebSite | publisher, url, gegebenenfalls belastbare sameAs-Ziele | Stimmen Name, URL und Organisation mit Impressum und Footer überein? |
| Über-uns- oder Teamseite | Person | Person | worksFor, jobTitle | Sind Rolle und Arbeitgeber sichtbar genannt? |
| Fachartikel | redaktioneller Beitrag | Article oder BlogPosting | author, publisher, isPartOf | Sind Autor, Datum und Herausgeber sichtbar und konsistent? |
| Kategorie- oder Themenseite | Sammlung | CollectionPage, gegebenenfalls ItemList | Beziehungen zu den gelisteten Artikeln | Entspricht die Liste dem sichtbaren Archiv und der Reihenfolge? |
| Produktseite | konkretes Produkt | Product | brand, offers, Identifikatoren, gegebenenfalls Bewertungen | Sind Preis, Verfügbarkeit und Bewertungen sichtbar und aktuell? |
| Navigation | Breadcrumb-Pfad | BreadcrumbList | geordnete itemListElement | Entspricht der ausgezeichnete Pfad der sichtbaren Navigation? |
LocalBusiness ist keine Standardwahl für jedes Unternehmen mit einer Postadresse. Der Typ sollte zu einem tatsächlich lokalen Geschäft oder Standort passen. Für eine reine B2B-Organisation kann Organization die präzisere Aussage sein.
Auch Eigenschaften sind keine Wunschfelder. Ein aggregateRating ohne sichtbare Bewertungen, ein offers-Block ohne dargestelltes Angebot oder ein sameAs-Link auf eine bloße Erwähnung machen den Graphen umfangreicher und zugleich schwächer.
Wie verbinden @id und sameAs die Entitäten?
@id identifiziert einen Knoten im JSON-LD-Graphen. sameAs verweist auf eine externe oder andere Webseite, die die Identität dieses Knotens eindeutig anzeigt. Beide lösen Identitätsfragen, aber auf unterschiedlichen Ebenen.
Die JSON-LD-1.1-Spezifikation beschreibt @id als Schlüssel zur Identifikation eines Knotens. In der Praxis kann eine Website damit ihre Organisation unter https://example.com/#organization anlegen und von Artikeln, Personen oder der Website-Entität auf genau diesen Knoten verweisen.
Ein guter @id-Wert sollte konsistent und eindeutig sein. Er ist keine sichtbare Überschrift und kein Rankingversprechen. Er verhindert vor allem, dass dieselbe Entität in mehreren Blöcken als scheinbar unterschiedliche Objekte auftaucht.
Die Schema.org-Eigenschaft sameAs ist enger definiert: Sie erwartet die URL einer Referenzseite, die die Identität des ausgezeichneten Elements eindeutig anzeigt. Das kann eine offizielle Profilseite, ein passender Wikidata-Eintrag oder eine andere eindeutige Identitätsseite sein. Eine Presseerwähnung reicht nicht allein deshalb, weil der Firmenname dort vorkommt.
Schlecht / Besser / Warum besser
Schlecht
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"sameAs": "https://news.example.org/artikel-mit-kurzer-firmenerwaehnung"
}Besser
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"sameAs": "https://profile.example.org/organisation/beispiel-gmbh"
}Warum besser: Die zweite URL steht im Beispiel für eine Seite, deren Zweck die eindeutige Identifikation der Organisation ist. Die erste URL belegt nur, dass die Organisation in einem Artikel erwähnt wurde. Ob eine reale Profilseite als sameAs geeignet ist, muss trotzdem einzeln geprüft werden.
sameAs ist kein Backlink-Ersatz. Die Eigenschaft sagt „dies ist dieselbe Entität“, nicht „übertrage Autorität auf diese Domain“. Wer externe Erwähnungen pauschal in sameAs sammelt, vermischt Identifikation mit Linkbuilding.
Wann ist Wikidata sinnvoll, und wann nicht?
Wikidata ist ein sinnvolles sameAs-Ziel, wenn bereits ein zulässiger, sauber belegter Eintrag zur richtigen Entität existiert. Einen Eintrag nur für SEO oder ein Knowledge Panel anzulegen, ist keine belastbare Strategie.
Die Notability-Policy von Wikidata nennt drei Wege, über die ein Item zulässig sein kann: ein gültiger Sitelink zu einem Wikimedia-Projekt, eine klar identifizierbare Entität mit ernsthaften und öffentlich verfügbaren Referenzen oder ein struktureller Bedarf innerhalb von Wikidata. Grenzfälle entscheidet die Community. Das ist differenzierter als die verkürzte Regel „Jede Firma mit zwei Presseartikeln darf hinein“.
Bei eigener Betroffenheit kommt der Interessenkonflikt hinzu. Wikidata rät in seinem Dokument „Self-promotion“ stark davon ab, Items über sich selbst, die eigene Organisation oder die eigene Arbeit zu erstellen. Dieses Dokument ist als Essay gekennzeichnet, nicht als Policy. Verbindlich geregelt ist dagegen die Offenlegung bezahlter Beiträge: Wer für Bearbeitungen bezahlt wird, muss den Auftraggeber offenlegen.
Meine Einschätzung: Prüfen Sie zuerst, ob ein bestehender Eintrag eindeutig zur Entität gehört und belastbar gepflegt ist. Falls kein Eintrag existiert, behandeln Sie das als Quellen- und Governance-Frage, nicht als technische SEO-Aufgabe. Ein ungeeigneter oder gelöschter Selbsteintrag löst kein Identitätsproblem. Er schafft ein neues.
Ein Wikidata-Link garantiert weder ein Knowledge Panel noch bessere Rankings. sameAs kann bei der Disambiguierung helfen. Was Google daraus in seinem Knowledge Graph übernimmt oder sichtbar zeigt, bleibt außerhalb der direkten Kontrolle einer Website.
Wie prüft man strukturierte Daten richtig?
Prüfen Sie strukturierte Daten in mehreren Ebenen und notieren Sie, welche Aussage jedes Werkzeug überhaupt treffen kann. Mein Prüfmodell umfasst fünf Schichten. Es ist eine Arbeitsmethode, kein offizieller Standard der genannten Anbieter.
| Ebene | Geeignetes Werkzeug | Prüft | Prüft nicht |
|---|---|---|---|
| 1. JSON-Syntax | JSON-Parser oder JSONLint | Klammern, Kommas, Strings, gültige JSON-Struktur | Schema.org-Vokabular oder Bedeutung |
| 2. JSON-LD-Verarbeitung | JSON-LD Playground | Kontextauflösung, Expansion und Linked-Data-Verarbeitung | Übereinstimmung mit dem sichtbaren Inhalt |
| 3. Schema.org-Vokabular | Schema.org Markup Validator | extrahierte Entitäten, Typen, Eigenschaften und Syntaxhinweise | Google-spezifische Feature-Anforderungen |
| 4. Google-Feature-Eligibility | Google Rich Results Test | dokumentierte Anforderungen für unterstützte Rich-Result-Typen | tatsächliche Anzeige eines Rich Results |
| 5. Semantische Wahrheit | manueller Abgleich mit Seite und Entity Map | Identitäten, Beziehungen, Aktualität und sichtbare Belege | lässt sich nicht vollständig automatisieren |
Der Schema.org Markup Validator dokumentiert seine Grenze selbst: Er konzentriert sich auf Schema.org und interpretiert bei JSON-LD keine anderen @context-URLs. Ein Fehler in einem Crawl-Tool kann daher zunächst etwas über dessen Parser aussagen. Er beweist noch keinen Fehler im Markup.
Einen konkreten Fall, in dem Toolbefund und Diagnose auseinanderlaufen, beschreibe ich im Beitrag „KI-Audit mit Screaming Frog: Claude liest die Daten sauber und erfindet die Diagnose“. Für diesen Guide übernehme ich den Fall nicht als Codebeispiel, weil der vollständige anonymisierte JSON-LD-Block und eine reproduzierbare Testkette hier nicht vorliegen.
Nach der technischen Prüfung folgt die Beobachtung. Dokumentieren Sie, wann sich Markup, sichtbarer Inhalt oder Seitentyp geändert haben. Prüfen Sie danach Search Console, Rich-Result-Berichte und die tatsächliche Darstellung. Eine zeitliche Folge allein beweist keine Ursache, besonders wenn gleichzeitig Inhalte, interne Links oder Templates verändert wurden.
Hilft Schema Markup bei der Sichtbarkeit in KI-Systemen?
Eine allgemeine, bestätigte Kausalität zwischen Schema Markup und Zitaten in ChatGPT, Perplexity oder Google AI Overviews ist derzeit nicht öffentlich dokumentiert. Aussagen wie „vollständiges Schema erhöht Ihre KI-Zitate“ gehen über die verfügbare Evidenz hinaus.
Bestätigt ist die technische Ebene: JSON-LD stellt Daten in einem standardisierten, maschinenlesbaren Format bereit. Google verlangt für seine AI Features kein besonderes KI-Markup und verweist in der Dokumentation zu AI Features auf dieselben Grundlagen wie in Search, darunter strukturierte Daten, die mit dem sichtbaren Text übereinstimmen.
Eine plausible Arbeitshypothese lautet: Explizite, konsistente Angaben können die Extraktion bestimmter Fakten erleichtern. Daraus folgt noch nicht, dass eine Engine diese Fakten für einen konkreten Prompt abruft, in die Antwort übernimmt oder mit einem sichtbaren Link zitiert. Maschinenlesbarkeit, Retrieval, Verwendung und Citation sind verschiedene Stufen.
Die Kategorie LLM Retrieval Gaps zeigt, wie sich diese Stufen getrennt diagnostizieren lassen. Für Schema Markup gilt dieselbe Disziplin: erst eine überprüfbare Implementierung bauen, dann das beobachtete Ergebnis messen, und eine Veränderung nicht vorschnell dem Markup zuschreiben.
Praktische Checkliste: Entity Map vor JSON-LD
Beginnen Sie mit einer wichtigen Seite. Eine vollständige Website auf einmal zu modellieren, erhöht vor allem die Zahl der Stellen, an denen Identitäten auseinanderlaufen können.
- Seite festlegen: Wählen Sie eine strategisch relevante Seite mit klarer Aufgabe, etwa Startseite, Teamseite, Fachartikel oder Produktseite.
- Sichtbare Aussagen erfassen: Notieren Sie Namen, Rollen, Angebote, Daten und Beziehungen, die ein Leser auf der Seite prüfen kann.
- Entitäten trennen: Legen Sie fest, welche Aussagen zur Organisation, Person, Website, Seite, zum Artikel oder Produkt gehören.
- Beziehungen belegen: Verknüpfen Sie jede geplante Beziehung mit einem sichtbaren Element oder einer verantwortlichen Quellseite.
- Bestehende Identifikatoren inventarisieren: Suchen Sie vorhandene
@id-Werte und vermeiden Sie neue Varianten für dieselbe Entität. - Schema.org zuordnen: Wählen Sie den präzisesten passenden Typ und nur Eigenschaften, die der Inhalt trägt.
- Graph verbinden: Referenzieren Sie wiederkehrende Entitäten über
@id, statt sie in jedem Block neu anzulegen. - Fünf Ebenen prüfen: Testen Sie Syntax, JSON-LD-Verarbeitung, Vokabular, Feature-Eligibility und semantische Wahrheit getrennt.
- Änderung protokollieren: Halten Sie Datum, betroffene Seiten, vorherige Fassung und erwartete Wirkung fest.
- Ergebnis beobachten: Prüfen Sie technische Berichte und sichtbare Ergebnisse über mehrere Messpunkte. Markieren Sie Kausalität als offen, solange das Setup sie nicht belegt.
Das Ergebnis dieser Übung ist zunächst keine große Ontologie. Es ist eine belastbare Karte für eine Seite. Wenn sie stimmt, lässt sie sich kontrolliert auf weitere Seitentypen ausweiten.
Häufige Fragen
Ist Schema Markup dasselbe wie JSON-LD?
Nein. Schema Markup bezeichnet die Verwendung des Schema.org-Vokabulars; JSON-LD ist ein mögliches Format dafür. Google unterstützt auch Microdata und RDFa, empfiehlt für strukturierte Daten aber JSON-LD.
Kann eine Seite ohne Fehler im Rich Results Test trotzdem falsch ausgezeichnet sein?
Ja. Der Test prüft die technischen Anforderungen unterstützter Google-Suchergebnisformate. Ob Entitäten und Beziehungen mit dem sichtbaren Inhalt und der Realität des Unternehmens übereinstimmen, braucht einen zusätzlichen manuellen Abgleich.
Muss jede Unterseite einen eigenen vollständigen Organization-Block enthalten?
Nein, nicht als mehrfach dupliziertes Objekt innerhalb desselben Seitengraphen. Die Organization kann dort einmal vollständig definiert und danach über denselben @id-Wert referenziert werden. Daraus folgt nicht, dass Google eine nur auf einer anderen Seite definierte Entität automatisch dereferenziert oder für Rich-Result-Anforderungen ergänzt.
Welche URL eignet sich für sameAs?
Geeignet ist eine Seite, die die Identität der Entität eindeutig anzeigt, etwa ein offizielles Profil oder ein passender Wikidata-Eintrag. Eine beliebige Erwähnung, ein Gastbeitrag oder ein Backlink ist nicht automatisch eine Identitätsseite.
Braucht ein B2B-Unternehmen einen Wikidata-Eintrag?
Nein. Ein Eintrag muss die Zulässigkeitskriterien von Wikidata erfüllen und sollte nicht als SEO-Pflicht behandelt werden. Existiert ein sauber belegter Eintrag bereits, kann er als eindeutige Referenz dienen; seine bloße Existenz garantiert keine Darstellung bei Google.
Garantiert korrektes Product Markup Sterne, Preis oder Verfügbarkeit im Suchergebnis?
Nein. Korrektes Markup kann eine Seite für ein unterstütztes Rich Result qualifizieren. Google entscheidet weiterhin, ob und wie die erweiterte Darstellung erscheint.
Sollte sichtbarer Inhalt an Schema.org angepasst werden?
Nur wenn die Ergänzung auch für Leser fachlich sinnvoll ist. Sichtbaren Inhalt ausschließlich für zusätzliche Markup-Felder aufzublähen, kehrt die Reihenfolge um. Zuerst steht eine wahre, nützliche Aussage auf der Seite; danach wird sie ausgezeichnet.
Alle Beiträge zum Thema
Die Produktseite ist nicht die ganze Gleichung
Was fünf Website-Kategorien darüber zeigen, welche Seiten KI-Antworten im E-Commerce als Belege verwenden.
Ein Skill weiß nichts: Markenwissen als OKF-Bundle
Ein offenes Markdown-Format für konsistentes Markenwissen, Beziehungen und wiederverwendbaren Kontext.
Der Prompt als Lego-Figur
Wie Query Fan-out die Keyword-Logik erweitert und Entity Mapping zur neuen Planungsgrundlage macht.
Nächster Schritt
Die verlinkten Vertiefungen helfen bei drei Anschlussfragen: Welche Seiten tragen die Beweise jenseits eines einzelnen Angebots, wo endet die Aussagekraft von Audit-Werkzeugen, und wie trennt man Maschinenlesbarkeit von Retrieval und Citation?
Wenn Sie daraus eine priorisierte Umsetzung für Ihre eigene Website ableiten möchten, finden Sie den fachlichen Rahmen unter KI-Sichtbarkeit systematisch optimieren.