Valides JSON-LD reicht nicht: 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

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:

1. Kann ein Parser den Code lesen?
2. Verwendet der Code Typen und Eigenschaften aus dem vorgesehenen Vokabular?
3. Erfüllt die Seite die dokumentierten Anforderungen für ein bestimmtes Suchfeature?
4. 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?

Öffentliche Arbeitsvorlage: Entity Map als CSV

Für die technische Umsetzung wird eine Entity Map belastbar, wenn jede Relation eine Zieladresse und einen sichtbaren Beleg hat. Eine bloße Liste aus Namen und Schema-Typen lässt diese Prüfung offen.

Entity-Map-ArbeitsvorlageCSV · 8 Beispielzeilen · offen bearbeitbarCSV herunterladen

Die Datei enthält diese sieben Pflichtspalten:

Spalte	Zweck	Abnahmekriterium
Entitätsname	Menschlich lesbarer, kanonischer Name	Stimmt mit der verantwortlichen Quellseite überein
Kanonische URL	Primäre Seite der Entität	Absolut, indexierbar und eindeutig zugeordnet
@id-URI-Muster	Stabiler Identifikator im Seitengraphen	Wird in allen relevanten Blöcken identisch geschrieben
Primärer Schema-Typ	Präzisester tragfähiger Schema.org-Typ	Beschreibt den sichtbaren Inhalt, keine Wunschidentität
Eigenschaft	Gerichtete Beziehung zur Zielentität	Für den Quelltyp auf Schema.org zulässig
Ziel-@id	Identifikator des Zielknotens	Existiert genau einmal als definierter Knoten oder bewusste Referenz
DOM-Selektor oder sichtbarer Beleg	Exakter Selektor oder wörtlicher Beleg	Ein Prüfer findet die Aussage ohne Interpretation auf der Seite

Ich lasse die Vorlage bewusst als CSV offen. Sie funktioniert in Excel, Google Sheets, LibreOffice und Datenpipelines. Prüfen Sie nach einem Import in Notion oder ein anderes Tabellentool, ob @id- und URL-Spalten als Text vorliegen und die Beispiel-URIs unverändert geblieben sind.

Der Abnahmeprozess ist simpel: Filtern Sie zuerst nach leeren Belegfeldern. Diese Zeilen dürfen noch nicht in JSON-LD übersetzt werden. Filtern Sie danach nach identischen Entitätsname-Werten mit unterschiedlichen @id-Werten. Dort liegen die wahrscheinlichsten Dubletten.

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.

1. Sichtbaren Inhalt erfassen. Welche Namen, Rollen, Leistungen, Daten und Beziehungen stehen tatsächlich auf der Seite?
2. Entitäten trennen. Welche eigenständigen Dinge beschreibt der Inhalt?
3. Beziehungen benennen. Wer arbeitet für wen, wer veröffentlicht was, welcher Artikel gehört zu welcher Website?
4. Entity Map dokumentieren. Jede Aussage erhält eine Quellseite oder ein sichtbares Seitenelement als Beleg.
5. Schema.org zuordnen. Für jede Entität und Beziehung werden passende Typen und Eigenschaften gewählt.
6. JSON-LD verbinden. Wiederkehrende Entitäten erhalten konsistente @id-Werte und werden referenziert statt kopiert.
7. Mehrstufig prüfen. Syntax, Verarbeitung, Vokabular, Feature-Anforderungen und semantische Wahrheit werden getrennt getestet.
8. 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. Jedes Codebeispiel in diesem Guide steht für ein eigenes fiktives System. Gleichlautende example.com-Fragmente aus verschiedenen Abschnitten dürfen nicht zu einem gemeinsamen Graphen zusammengeführt werden.

{
  "@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.

FIG 01 · VON DER ENTITY MAP ZUM JSON-LD-GRAPHEN

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.

Wie modelliert man einen B2B-Holdinggraphen mit Töchtern, Werken und Marken?

Wenn eine Website Tochtergesellschaften, Werke und eigenständige Produktmarken ausweist, modellieren Sie diese als getrennte Knoten. Die Mutter-Tochter-Beziehung läuft über subOrganization und parentOrganization. Ein Werk ist als Place über location an die betreibende Organisation gebunden. Eine eigenständige Produktmarke erhält einen Brand-Knoten und wird über brand referenziert.

Ein typischer Modellierungsfehler besteht darin, alles unter einem großen Organization-Objekt zu verschachteln. Dann verschwimmen drei verschiedene Fragen: Wer ist juristisch verantwortlich? Wo findet eine Tätigkeit statt? Unter welchem Markennamen wird ein Angebot geführt?

Das folgende Beispiel trennt diese Ebenen. Es ist illustrativ. Namen, Seiten und Beziehungen müssen auf der realen Website sichtbar belegt sein.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Beispiel Holding SE",
      "url": "https://example.com/",
      "subOrganization": [
        { "@id": "https://example.com/unternehmen/produktion/#organization" },
        { "@id": "https://example.com/unternehmen/services/#organization" }
      ],
      "brand": [
        { "@id": "https://example.com/marken/aquila-industrial/#brand" },
        { "@id": "https://example.com/marken/nova-process/#brand" }
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/unternehmen/produktion/#organization",
      "name": "Beispiel Produktion GmbH",
      "url": "https://example.com/unternehmen/produktion/",
      "parentOrganization": { "@id": "https://example.com/#organization" },
      "location": [
        { "@id": "https://example.com/standorte/werk-sued/#place" },
        { "@id": "https://example.com/standorte/werk-nord/#place" }
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/unternehmen/services/#organization",
      "name": "Beispiel Industrial Services GmbH",
      "url": "https://example.com/unternehmen/services/",
      "parentOrganization": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Place",
      "@id": "https://example.com/standorte/werk-sued/#place",
      "name": "Werk Süd",
      "url": "https://example.com/standorte/werk-sued/",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Industriestraße 10",
        "postalCode": "70173",
        "addressLocality": "Stuttgart",
        "addressCountry": "DE"
      }
    },
    {
      "@type": "Place",
      "@id": "https://example.com/standorte/werk-nord/#place",
      "name": "Werk Nord",
      "url": "https://example.com/standorte/werk-nord/",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Werkstraße 4",
        "postalCode": "20095",
        "addressLocality": "Hamburg",
        "addressCountry": "DE"
      }
    },
    {
      "@type": "Brand",
      "@id": "https://example.com/marken/aquila-industrial/#brand",
      "name": "Aquila Industrial",
      "url": "https://example.com/marken/aquila-industrial/"
    },
    {
      "@type": "Brand",
      "@id": "https://example.com/marken/nova-process/#brand",
      "name": "Nova Process",
      "url": "https://example.com/marken/nova-process/"
    }
  ]
}

Drei Grenzen sind wichtig:

1. subOrganization bildet eine organisatorische Einbeziehung ab, etwa eine Tochtergesellschaft. Ein Vertriebspartner oder Lieferant gehört nicht allein wegen der Zusammenarbeit in diese Beziehung.
2. Ein Werk wird nicht automatisch zum LocalBusiness. Schema.org definiert LocalBusiness als bestimmtes physisches Geschäft oder eine Filiale. Ein Produktionsstandort ohne lokalen Kundenbetrieb lässt sich neutral als Place modellieren.
3. Brand ersetzt weder Organization noch Product. Die Marke bezeichnet die Markenidentität. Juristische Verantwortung und konkrete Angebote bleiben eigene Knoten.

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 modelliert man komplexe B2B-Leistungen: Service statt erfundenem Product?

Für eine individuelle, fortlaufende oder projektbezogene B2B-Leistung ist Service häufig die präzisere Ausgangsentität. Die Eigenschaften provider, areaServed, serviceType und hasOfferCatalog beschreiben Anbieter, Marktgebiet, Leistungsart und ein gegliedertes Portfolio. Sie zwingen keine feste Preisdarstellung.

Ein Offer mit price: "0" ist kein Platzhalter für „Preis auf Anfrage“. Er behauptet einen Nullpreis. Steht diese Aussage nicht sichtbar auf der Seite, ist sie sachlich falsch. Google verlangt für strukturierte Daten sichtbare, repräsentative Angaben. Ein weggelassener Preis ist ehrlicher als ein erfundener.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Beispiel Cloud AG",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/managed-cloud/#service",
      "name": "Managed Cloud Services",
      "url": "https://example.com/services/managed-cloud/",
      "serviceType": "Managed Infrastructure und Cloud Operations",
      "provider": { "@id": "https://example.com/#organization" },
      "areaServed": ["CH", "DE", "AT"],
      "hasOfferCatalog": {
        "@type": "OfferCatalog",
        "name": "Leistungsbausteine",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "@id": "https://example.com/services/managed-cloud/#operations",
              "name": "Cloud Operations"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "@id": "https://example.com/services/managed-cloud/#migration",
              "name": "Cloud Migration"
            }
          }
        ]
      }
    }
  ]
}

hasOfferCatalog bedeutet nicht, dass Google daraus automatisch ein Preis- oder Produkt-Rich-Result erzeugt. Google führt in seiner Übersicht unterstützter strukturierter Daten kein allgemeines Rich Result für den Typ Service. Der Schema.org Validator prüft den Vokabulargebrauch; der Rich Results Test kann nur unterstützte Google-Features beurteilen.

Die Typentscheidung folgt aus dem sichtbaren Angebot:

Sichtbare Realität	Tragfähiger Starttyp	Was Sie vermeiden sollten
Beratungs-, Betriebs- oder Projektleistung	Service	Fiktives Product nur wegen eines Rich-Result-Wunsches
Standardisiertes physisches oder digitales Produkt	Product	Angebotseigenschaften ohne sichtbare Produktdaten
Nutzungsbasierte Cloud-Leistung ohne festen Seitenpreis	Service + OfferCatalog	Offer.price: "0" als Ersatz für „auf Anfrage“
Kaufbares Paket mit sichtbarem Preis und Bedingungen	je nach Gegenstand Product oder Service + passendes Offer	Preis, Währung oder Verfügbarkeit aus Backendwerten, die der Nutzer nicht sieht

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.

Fünf harte Kriterien für ein sameAs-Ziel

Ich nehme eine URL nur auf, wenn alle fünf Fragen mit Ja beantwortet sind:

1. Identifiziert die Seite dieselbe Entität? Eine Konzernseite ist kein Ersatz für den Datensatz der Tochter. Ein Autorenprofil ist kein Profil des Arbeitgebers.
2. Nennt sie ein stabiles Identitätsmerkmal? Dazu gehören Register- oder Normdaten-ID, offizieller Name, belastbare Namensvarianten, Sitz oder eindeutig zuordenbare Biografie.
3. Ist die URL öffentlich und dauerhaft erreichbar? Login-Wände, temporäre Suchergebnisse, JavaScript-Leerseiten für einfache Clients und private Profile sind schlechte Referenzen.
4. Ist der Herausgeber für diese Identitätsaussage zuständig? Ein Handelsregister belegt eine juristische Person. VIAF oder GND können eine publizierende Person oder Körperschaft disambiguieren. Ein Branchenblog belegt primär seine eigene Veröffentlichung.
5. Wird die Seite gepflegt? Verwaiste Social-Profile mit altem Namen oder falschem Arbeitgeber können mehr Widerspruch als Klarheit erzeugen.

Die Quellen erfüllen unterschiedliche Aufgaben:

Referenztyp	Wofür er stark ist	Grenze
Deutsches Registerportal oder Schweizer Zefix	juristischer Name, Rechtsform, Sitz und Registeridentität einer Organisation	Identifiziert keine Produktmarke und belegt keine fachliche Autorität
GND	normierte Namen von Personen und Körperschaften im Bibliothekskontext	Nur geeignet, wenn bereits ein Datensatz zur exakt richtigen Entität existiert
VIAF	Zusammenführung mehrerer Normdateien und Namensvarianten	Ein Cluster kann fehlerhaft oder für eine nicht publizierende Fachperson schlicht nicht vorhanden sein
Wikidata	verknüpfte Identität mit Aussagen und Quellen	Zulässigkeit, Interessenkonflikte und Datenqualität müssen geprüft werden
Offizielles Social- oder Plattformprofil	aktuelle Selbstdarstellung und direkter Bezug zur Entität	URLs, Namen und Arbeitgeber ändern sich; öffentliche Abrufbarkeit variiert
Presseartikel oder Verzeichniseintrag	externe Erwähnung oder Kontext	Eine Erwähnung ist noch keine Identitätsseite

Soziale Profile sind also nicht pauschal Rauschen. Ein öffentliches, aktuelles LinkedIn-Unternehmensprofil kann die richtige Organisation eindeutig anzeigen. Ein leeres Profil, ein privater Account oder eine Seite, die nur denselben Namen trägt, gehört nicht in sameAs. Entscheidend ist die Identitätsfunktion der konkreten URL.

Auch Indexierung allein ist kein hartes Eignungskriterium. Eine offizielle Registerseite kann in der Websuche schwach sichtbar und trotzdem eine präzise Identitätsreferenz sein. Problematisch wird eine URL, wenn sie für relevante Clients nicht abrufbar, instabil oder inhaltlich zu dünn für die eindeutige Zuordnung ist.

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 trennt man Autor, Redaktion und fachliche Prüfung?

Bei Experteninhalten sollten die sichtbaren Rollen getrennt modelliert werden: author für die Urheberschaft, editor für die redaktionelle Bearbeitung und reviewedBy für die fachliche Prüfung. Schema.org ordnet author und editor einem CreativeWork wie Article oder TechArticle zu. reviewedBy ist enger definiert und gehört auf den WebPage-Knoten.

Das ist für Medizin, Recht, Technik und andere Fachgebiete relevant, in denen ein Redakteur den Text schreibt und ein Spezialist die fachliche Richtigkeit prüft. Der Reviewer wird dadurch nicht automatisch zum Mitautor. Seine Qualifikation muss auf der Seite sichtbar und über eine eigene Profilseite nachvollziehbar sein.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.com/fachartikel-a/#webpage",
      "url": "https://example.com/fachartikel-a/",
      "mainEntity": { "@id": "https://example.com/fachartikel-a/#article" },
      "reviewedBy": { "@id": "https://example.com/team/nils-berger/#person" }
    },
    {
      "@type": "TechArticle",
      "@id": "https://example.com/fachartikel-a/#article",
      "headline": "Korrosionsschutz für Anlagenkomponenten",
      "author": { "@id": "https://example.com/team/lea-sommer/#person" },
      "editor": { "@id": "https://example.com/team/mara-vogel/#person" },
      "mainEntityOfPage": { "@id": "https://example.com/fachartikel-a/#webpage" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/lea-sommer/#person",
      "name": "Lea Sommer",
      "jobTitle": "Fachredakteurin",
      "url": "https://example.com/team/lea-sommer/"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/mara-vogel/#person",
      "name": "Mara Vogel",
      "jobTitle": "Leiterin Fachredaktion",
      "url": "https://example.com/team/mara-vogel/"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/nils-berger/#person",
      "name": "Dr.-Ing. Nils Berger",
      "jobTitle": "Werkstoffingenieur",
      "url": "https://example.com/team/nils-berger/",
      "knowsAbout": ["Korrosionsschutz", "Werkstofftechnik"],
      "hasCredential": {
        "@type": "EducationalOccupationalCredential",
        "name": "Promotion in Werkstofftechnik"
      }
    }
  ]
}

Der sichtbare Artikel braucht dazu mindestens drei klare Angaben: „Von Lea Sommer“, „Redaktion: Mara Vogel“ und „Fachlich geprüft von Dr.-Ing. Nils Berger, Werkstoffingenieur“. Die Profilseite des Reviewers sollte die genannte Qualifikation belegen. Ein hasCredential-Block ohne denselben sichtbaren Nachweis würde das Problem nur in den Code verschieben.

Google führt reviewedBy in seiner Article-Dokumentation nicht als empfohlenes Feld für Article-Rich-Results. Die saubere Rollentrennung ist daher eine semantische Modellierung, kein versprochenes Suchfeature.

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.

FIG 02 · FÜNF VALIDIERUNGSEBENEN

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.

Was Schema Markup nicht repariert

Ein sauberer Graph kann vorhandene Aussagen präziser ausdrücken. Er erzeugt keine fehlende Substanz.

Problem	Was Schema leisten kann	Was außerhalb des Markups gelöst werden muss
Schwache oder unbekannte Marke	Namen, URL und Beziehungen konsistent auszeichnen	belastbare externe Erwähnungen, Nachfrage, Bekanntheit und eindeutige Positionierung
Dünner Fachtext	Autor, Datum und Inhaltstyp explizit benennen	eigene Expertise, nachvollziehbare Belege, klare Antworten und originäre Information
Keine externen Identitätsquellen	vorhandene, passende Identitätsseiten über sameAs referenzieren	echte öffentliche Präsenz und zulässige Norm- oder Registerdaten
Widersprüchliche Website	Konflikte in der Entity Map sichtbar machen	Namen, Rollen, Angebote und Verantwortlichkeiten im sichtbaren Inhalt bereinigen
Fehlendes Retrieval	maschinenlesbare Fakten bereitstellen	Crawlbarkeit, Indexierung, interne Verlinkung, Query-Abdeckung und Quellenrelevanz

Meine operative Reihenfolge ist deshalb: zuerst sichtbare Wahrheit und Quellenlage, danach konsistentes Markup, anschließend Messung. Wer die Reihenfolge umdreht, optimiert den Übersetzer, bevor der Ausgangstext stimmt.

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.

Drei Schema-Antipatterns mit unterschiedlichen Belegstufen

Die folgenden Fälle haben unterschiedliche Belegstufen. Der WebPage-Fall lag direkt in einem industriellen B2B-Audit vor. Der Cloud-Fall stammt aus dem Auditkontext eines Schweizer IaaS-Anbieters, in dem vor allem die Drift zwischen Product und offers dokumentiert war. Person-Dubletten sind ein wiederkehrender Fehlerklassentyp; dafür liegt mir im zugänglichen Ticketbestand kein einzelner Fall vor. Ich trenne das offen, statt drei Geschichten gleich sicher klingen zu lassen.

1. Eine Person wird durch Namensvarianten mehrfach angelegt

Muster: Martin Keller, Martin Keler und ein dritter manuell gepflegter Block erhalten verschiedene @id-Werte. Technisch entstehen drei Person-Knoten. Ob eine Suchmaschine sie später zusammenführt, ist nicht kontrollierbar. Die Website selbst liefert jedenfalls widersprüchliche Identifikatoren.

Risiko: Artikel, Profile und externe Referenzen verteilen sich auf verschiedene Knoten. Das erschwert eine konsistente interne Entity Map. Eine automatische Aussage wie „Google behandelt das garantiert als drei Menschen“ wäre trotzdem zu stark.

Korrektur: Einen kanonischen Person-Knoten definieren. Jede Autorenrelation verweist auf denselben @id-Wert. Namensvarianten werden nur dann als alternateName aufgenommen, wenn sie real verwendet und belegbar sind.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://person.example.com/#organization",
      "name": "Beispiel GmbH",
      "url": "https://person.example.com/"
    },
    {
      "@type": "Person",
      "@id": "https://person.example.com/team/martin-keller/#person",
      "name": "Martin Keller",
      "url": "https://person.example.com/team/martin-keller/",
      "worksFor": { "@id": "https://person.example.com/#organization" }
    }
  ]
}

Prüfung vor dem Rollout: Für jede reale Person existiert im Seitengraphen genau ein kanonischer @id-Wert. Alle author-, editor- und reviewedBy-Relationen referenzieren ihn.

2. Ein Artikel hat nur den Yoast-Standardknoten WebPage

Auditbeobachtung: Auf den geprüften Blog- und Case-Seiten eines industriellen WordPress-B2B-Auftritts fehlte der Article-Inhaltsknoten; der Yoast-Graph lieferte nur Seiten-, Website- und Navigationsknoten. Der WebPage-Knoten war dabei kein Fehler. Überschrift, Autor und Publikationsdaten waren lediglich nicht als Eigenschaften eines Article-Objekts verbunden.

Korrektur: WebPage bleibt die Seite. Ein Article oder der präzisere Untertyp TechArticle beschreibt den redaktionellen Inhalt. Beide Knoten werden über mainEntity und mainEntityOfPage verbunden.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://example.com/pvd-vs-galvanik/#webpage",
      "url": "https://example.com/pvd-vs-galvanik/",
      "mainEntity": { "@id": "https://example.com/pvd-vs-galvanik/#article" }
    },
    {
      "@type": "TechArticle",
      "@id": "https://example.com/pvd-vs-galvanik/#article",
      "headline": "PVD-Beschichtung und galvanische Beschichtung im Vergleich",
      "author": { "@id": "https://example.com/team/lea-sommer/#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "datePublished": "2026-03-14",
      "dateModified": "2026-04-02",
      "mainEntityOfPage": { "@id": "https://example.com/pvd-vs-galvanik/#webpage" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/lea-sommer/#person",
      "name": "Lea Sommer",
      "url": "https://example.com/team/lea-sommer/"
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Beispiel GmbH",
      "url": "https://example.com/"
    }
  ]
}

Ein frei erfundener Typ CaseStudy wäre keine Lösung: Unter https://schema.org/CaseStudy existiert in Schema.org 30.0 kein Typ. Für eine Fallstudie muss der tatsächliche Inhalt entscheiden, etwa zwischen Article, TechArticle oder Report.

3. Bei einem Cloud-Angebot driften Product und offers auseinander

Auditbeobachtung: Bei einem Schweizer IaaS-Anbieter drifteten Angebotstyp und Angebotsdaten auseinander: Die Leistung erschien als Product; der offers-Block enthielt einen Preiswert, obwohl die Abrechnung nutzungsbasiert war und dieser Preis nicht auf der Seite stand. Genau dieser Product/offers-Konflikt ist im zugänglichen Auditmaterial belegt.

Verwandte Typfalle: Bei reinen Cloud- oder SaaS-Anbietern wird außerdem gelegentlich aus einer Impressumsadresse ein LocalBusiness abgeleitet. Für den vorliegenden Auditfall behaupte ich das nicht als dokumentierten Befund. Schema.org beschreibt LocalBusiness als bestimmtes physisches Geschäft oder eine Filiale; eine Postanschrift allein beantwortet diese Typfrage nicht.

Korrektur: Eine juristische oder kontaktbezogene Adresse kann auf Organization stehen. Für den remote erbrachten Cloud-Betrieb ist Service mit provider, areaServed und einem sichtbaren Leistungskatalog die präzisere Modellierung. Preisfelder bleiben weg, solange kein wahrer, sichtbarer Preis vorliegt.

Die grobe Entscheidungsregel lautet:

• Adresse im Impressum oder als Postanschrift: Organization.address prüfen.
• Tatsächlicher physischer Geschäfts- oder Filialstandort: passenden LocalBusiness-Untertyp prüfen.
• Remote oder projektbezogene Leistung: Service prüfen.
• Sichtbarer, kaufbarer Gegenstand mit passenden Angebotsdaten: Product und Offer prüfen.

Das sind Typentscheidungen. Keine davon beweist eine bessere Platzierung oder ein KI-Zitat.

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.

Arbeitsstand

Ihre Entity Map in 10 Schritten

0 von 10Schritte erledigt

0 von 10

1. Seite festlegenWählen Sie eine strategisch relevante Seite mit klarer Aufgabe, etwa Startseite, Teamseite, Fachartikel oder Produktseite.
2. Sichtbare Aussagen erfassenNotieren Sie Namen, Rollen, Angebote, Daten und Beziehungen, die ein Leser auf der Seite prüfen kann.
3. Entitäten trennenLegen Sie fest, welche Aussagen zur Organisation, Person, Website, Seite, zum Artikel oder Produkt gehören.
4. Beziehungen belegenVerknüpfen Sie jede geplante Beziehung mit einem sichtbaren Element oder einer verantwortlichen Quellseite.
5. Bestehende Identifikatoren inventarisierenSuchen Sie vorhandene @id-Werte und vermeiden Sie neue Varianten für dieselbe Entität.
6. Schema.org zuordnenWählen Sie den präzisesten passenden Typ und nur Eigenschaften, die der Inhalt trägt.
7. Graph verbindenReferenzieren Sie wiederkehrende Entitäten über @id, statt sie in jedem Block neu anzulegen.
8. Fünf Ebenen prüfenTesten Sie Syntax, JSON-LD-Verarbeitung, Vokabular, Feature-Eligibility und semantische Wahrheit getrennt.
9. Änderung protokollierenHalten Sie Datum, betroffene Seiten, vorherige Fassung und erwartete Wirkung fest.
10. Ergebnis beobachtenPrüfen Sie technische Berichte und sichtbare Ergebnisse über mehrere Messpunkte. Markieren Sie Kausalität als offen, solange das Setup sie nicht belegt.

Auswahl zurücksetzen

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.

Braucht ein B2B-Service ein Offer mit Preis?

Nein. Service kann mit provider, areaServed, serviceType und hasOfferCatalog modelliert werden. Ein sichtbarer Preis wird in diesem Service-Modell über ein passendes Offer oder dessen PriceSpecification abgebildet. Nicht sichtbare oder erfundene Preisangaben bleiben weg. „Preis auf Anfrage“ darf nicht als Nullpreis codiert werden.

Wo gehört reviewedBy hin?

Schema.org 30.0 führt reviewedBy für WebPage. author und editor gehören zum CreativeWork, etwa Article oder TechArticle. Verknüpfen Sie Seite und Inhaltsobjekt über mainEntity und mainEntityOfPage.

Ist eine Postadresse ein ausreichender Grund für LocalBusiness?

Nein. Schema.org beschreibt LocalBusiness als bestimmtes physisches Geschäft oder eine Filiale. Eine juristische oder postalische Adresse kann auf Organization stehen. Entscheidend ist die reale Funktion des Standorts, nicht die bloße Existenz einer Anschrift im Impressum.

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

• 23. Juli 2026 · 17 Min. · Praxis & Zahlen

  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.

• 15. Juli 2026 · 14 Min. · Anleitung

  Ein Skill weiß nichts: Markenwissen als OKF-Bundle

  Ein offenes Markdown-Format für konsistentes Markenwissen, Beziehungen und wiederverwendbaren Kontext.

• 5. Juli 2026 · 11 Min. · Analyse & Einordnung

  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.