Schema.org-Entitätsgraphen mit @graph und @id modellieren

Ein Entitätsgraph verbindet die Dinge, die eine Seite tatsächlich beschreibt: etwa eine Webseite, einen Fachartikel, dessen Autorin, das veröffentlichende Unternehmen und das Thema des Beitrags. Jedes Objekt erhält eine stabile Kennung. Beziehungen verweisen auf diese Kennung. So bleibt erkennbar, dass dieselbe Person in mehreren Eigenschaften und auf mehreren Seiten dieselbe Person meint.

Diese Anleitung richtet sich an Teams, die JSON-LD bereits aus sichtbaren Seitendaten ausführen und nun Entitätsbeziehungen mit @graph und @id modellieren. JSON-LD verwendet @id, um Knoten zu identifizieren; ein Knotenverweis kann allein aus dieser Kennung bestehen. @graph fasst mehrere Knoten in einer Graphstruktur zusammen.

Arbeitsdefinition: Ein Entitätsgraph ist ein JSON-LD-Modell aus eindeutig benannten Knoten und fachlich begründeten Beziehungen. Er beschreibt ausschließlich Entitäten und Relationen, die die veröffentlichte Seite trägt.

Aufgabe und Grenze des Entitätsgraphen

Der Graph ergänzt die sichtbare Information einer URL. Er macht nicht aus ähnlichen Namen dieselbe Entität und erzeugt keine Fakten, die auf der Seite oder in einer Quelle fehlen. Google fordert, dass strukturierte Daten den sichtbaren Hauptinhalt repräsentieren. Korrektes Markup begründet keinen Anspruch auf eine bestimmte Suchdarstellung.

Die Anleitung JSON-LD implementieren und validieren behandelt Auswahl, Ausgabe und Grundprüfung eines einzelnen Datenblocks. Der Hub Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet ein, wie Content-Modell, Template und Auslieferung zusammenwirken. Dieser Beitrag übernimmt die engere Aufgabe: mehrere begründete Objekte als konsistenten Graphen zu verbinden.

1. Das Entitätsmodell vor dem Markup festlegen

Starte mit den Dingen, über die die Seite überprüfbare Aussagen macht. Für eine Artikelseite reichen meist fünf Knoten. Ein Produkt, eine Veranstaltung oder ein Video kommt hinzu, wenn das Objekt auf der URL als eigener Gegenstand vorkommt und eine relevante Beziehung zum Hauptinhalt besitzt.

Ein Knoten braucht eine fachliche Existenz außerhalb des einzelnen JSON-LD-Skripts. Frage vor der Implementierung: Würde das Team dieselbe Person, Organisation oder Sache auf einer anderen URL erneut meinen? Wenn ja, ist eine wiederverwendbare @id sinnvoll. Wenn nein, reicht ein einfacher Wert oder eine Verschachtelung innerhalb des Hauptobjekts.

Beziehungen als Sätze formulieren

Formuliere jede Kante zuerst als prüfbaren Satz. Aus „Autor ist Max Muster“ wird zum Beispiel: „Der Artikel wurde von der Person mit der Kennung …/#person verfasst.“ Erst danach wählst du die Schema.org-Eigenschaft. Das trennt die fachliche Aussage von der Syntax.

mainEntity bezeichnet laut Schema.org die primäre Entität, die eine Seite oder ein anderes CreativeWork beschreibt. Die Gegenrichtung drückt mainEntityOfPage aus. about bezeichnet den Gegenstand eines Objekts. Verwende about nicht für eine Marke, ein Werkzeug oder eine Person, die im Text nur als Beispiel vorkommt. Für beiläufige Nennungen eignet sich mentions; häufig ist für eine Randnennung kein eigener Knoten nötig.

2. Stabile @id-Kennungen vergeben

@id bildet die Identität eines JSON-LD-Knotens im Graphen und unterscheidet sich von url: url verweist auf eine Webadresse, während @id ein Objekt benennt. JSON-LD erlaubt einen Knotenverweis, der ausschließlich aus @id besteht.

Nutze im öffentlichen Website-Markup absolute, stabile HTTP(S)-URIs. Eine kanonische URL mit Fragment macht die Rolle deutlich und vermeidet eine Verwechslung von Seite und Objekt:

https://www.beispiel.de/magazin/entity-graph/          → kanonische Seite
https://www.beispiel.de/magazin/entity-graph/#webpage → WebPage-Knoten
https://www.beispiel.de/magazin/entity-graph/#article → Article-Knoten
https://www.beispiel.de/autor/max-muster/#person      → Person-Knoten
https://www.beispiel.de/#organization                 → Organization-Knoten

Die Fragmente bilden ein Benennungsschema, keine zusätzlichen Seiten. Die Kennung für dieselbe Entität darf nicht je Template, Sprachversion oder Release wechseln. Dokumentiere das Schema zentral: Wer darf eine neue globale Entität anlegen? Welche Kennung hat Vorrang? Wann wird eine Kennung weitergeführt?

sameAs nur für eindeutige Gleichheit einsetzen

sameAs bildet keine allgemeine Linkliste. Die Eigenschaft steht für eine Referenzseite, die die Identität des Gegenstands eindeutig anzeigt, etwa eine offizielle Website, ein Wikidata-Eintrag oder ein verifiziertes Organisationsprofil. Ein Branchenverzeichnis, ein Social-Media-Konto mit gleichem Namen oder eine thematisch ähnliche Wikipedia-Seite genügt nicht automatisch.

Prüfe jede externe Referenz manuell gegen Name, Website, Beschreibung, Rechtsform und Standort. Fehlt diese Eindeutigkeit, verzichte auf sameAs. Eine fehlende Beziehung bleibt zuverlässiger als eine falsche Identitätsbehauptung.

3. Die Knoten mit @graph verbinden

Ein @graph-Array bündelt die Knoten eines zusammenhängenden Seitenmodells. Das Format ordnet das Modell: Die Definition eines Objekts steht einmal im Graphen; andere Knoten verweisen darauf mit {"@id": "…"}. Google verarbeitet mehrere Objekte auch verschachtelt oder als einzelne Items. Für Objekte mit nachvollziehbaren Beziehungen empfiehlt Google die Verbindung über @id.

Das folgende Beispiel modelliert eine Artikelseite. Die URLs, Namen und Daten dienen als Beispiel. Übernehme Eigenschaften, für die die veröffentlichte Seite und das Content-Modell Nachweise besitzen.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://www.beispiel.de/magazin/entity-graph/#webpage",
      "url": "https://www.beispiel.de/magazin/entity-graph/",
      "name": "Schema.org-Entitätsgraphen mit @graph und @id modellieren",
      "isPartOf": { "@id": "https://www.beispiel.de/#website" },
      "mainEntity": { "@id": "https://www.beispiel.de/magazin/entity-graph/#article" }
    },
    {
      "@type": "Article",
      "@id": "https://www.beispiel.de/magazin/entity-graph/#article",
      "headline": "Schema.org-Entitätsgraphen mit @graph und @id modellieren",
      "mainEntityOfPage": {
        "@id": "https://www.beispiel.de/magazin/entity-graph/#webpage"
      },
      "author": { "@id": "https://www.beispiel.de/autor/max-muster/#person" },
      "publisher": { "@id": "https://www.beispiel.de/#organization" },
      "about": { "@id": "https://www.beispiel.de/themen/entity-graph/#term" },
      "isPartOf": { "@id": "https://www.beispiel.de/#website" },
      "datePublished": "2026-09-11",
      "dateModified": "2026-09-11"
    },
    {
      "@type": "Person",
      "@id": "https://www.beispiel.de/autor/max-muster/#person",
      "name": "Max Muster",
      "url": "https://www.beispiel.de/autor/max-muster/",
      "worksFor": { "@id": "https://www.beispiel.de/#organization" }
    },
    {
      "@type": "Organization",
      "@id": "https://www.beispiel.de/#organization",
      "name": "Beispiel GmbH",
      "url": "https://www.beispiel.de/"
    },
    {
      "@type": "WebSite",
      "@id": "https://www.beispiel.de/#website",
      "name": "Beispiel GmbH",
      "url": "https://www.beispiel.de/",
      "publisher": { "@id": "https://www.beispiel.de/#organization" }
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://www.beispiel.de/themen/entity-graph/#term",
      "name": "Entitätsgraph",
      "description": "Modell aus Entitäten und ihren Beziehungen."
    }
  ]
}
</script>

Jede Definition steht hier einmal. Die Eigenschaften mainEntity, author, publisher, about, isPartOf und worksFor enthalten Knotenverweise. Damit lässt sich beim Lesen des Graphen eine Beziehung verfolgen:

WebPage ──mainEntity──> Article
Article ──author──────> Person ──worksFor──> Organization
Article ──publisher───> Organization
Article ──about───────> DefinedTerm
Article ──isPartOf────> WebSite ──publisher──> Organization

Das Beispiel setzt sameAs bewusst nicht. Füge die Eigenschaft an dem Knoten ein, dessen externe Identität geprüft wurde. Der Organization-Knoten kann eine Liste verifizierter externer Referenzen tragen; sie gehört nicht pauschal an WebPage, Article oder WebSite.

Verschachteln oder referenzieren?

Eine verschachtelte Struktur genügt, wenn ein Unterobjekt nur in einem Kontext gebraucht wird und keine eigene Identität im Modell benötigt. Ein ImageObject kann direkt am Artikel stehen, wenn es nicht auf anderen Knoten referenziert wird. Verwende eine eigene @id mit Referenz, wenn mindestens eine Bedingung zutrifft:

1. →Dieselbe Entität erscheint an mehreren Stellen im Graphen oder auf mehreren URLs.
2. →Die Entität besitzt eine eigene Profil-, Detail- oder Stammdatenquelle.
3. →Mehrere Templates müssen dieselbe Entität ausgeben.
4. →Die Beziehung wird automatisiert geprüft oder gepflegt.

4. Beziehungen modellieren

Ein großer Graph ist nicht automatisch ein gutes Modell. Füge eine Beziehung hinzu, wenn sie den Hauptinhalt der URL genauer beschreibt und sich gegen sichtbare Daten prüfen lässt.

Thema und Marke trennen

Ein Artikel kann über eine Software, eine Organisation oder eine Methode handeln. Das rechtfertigt nicht, jede im Text genannte Marke mit about oder sameAs zu verknüpfen. Die Seitenrolle bestimmt die Beziehung: Ein Testbericht über eine Software hat diese Software als Gegenstand. Ein allgemeiner Beitrag, der die Software in einer Tabelle nennt, verfolgt ein anderes Thema.

Das Gleiche gilt für Autoren- und Organisationsdaten. Ein Firmenlogo im Header beweist nicht, dass jede redaktionelle Aussage von dieser Organisation stammt. Das sichtbare Impressum, Autorenprofil, die Byline und das Redaktionsmodell tragen die Beziehungen. Die Redaktionelle SEO hilft beim Prüfen dieser sichtbaren Grundlage.

5. Eine Pflegekette für IDs und Beziehungen einrichten

Ein Graph bleibt konsistent, wenn Redaktion, Content-Modell und Template dieselbe Quelle verwenden. Lege für globale Entitäten wie Organisation, Website, Personen und wiederkehrende Produkte einen Entitätskatalog an. Eine versionierte Tabelle oder ein Content-Type mit Verantwortlichkeiten genügt, wenn sie diese Fragen beantwortet:

Die Content-Redaktion legt fest, welche URL welche Aufgabe hat und wer Inhalte pflegt. Für die fachliche Freigabe einer überarbeiteten Fassung strukturiert der Human-in-the-Loop-Prozess den Verantwortungsnachweis. Beide Prozesse liefern dem Graphen verlässliche sichtbare Daten.

Ablauf der Umsetzung

1. →Entitäten inventarisieren: Liste pro Seitentyp nur die Objekte auf, die die Seite tatsächlich beschreibt.
2. →Kennungen festlegen: Definiere die kanonische @id für wiederkehrende Knoten und dokumentiere Namensschema sowie Ownership.
3. →Beziehungen belegen: Formuliere jede Kante als Satz und ordne eine sichtbare Quelle oder eine verantwortete Stammdatenquelle zu.
4. →Graph im Template ausgeben: Definiere zentrale Knoten einmal und referenziere sie über @id.
5. →Referenzen testen: Prüfe, ob jeder Verweis auf einen existierenden Knoten zeigt und ob jeder Knoten zu einem Seitenelement passt.
6. →Änderungen nachziehen: Bei Wechsel von Autorenschaft, Publisher, Organisation, URL oder Hauptthema aktualisierst du die betroffenen Knoten und Kanten gemeinsam.

Die SEO-Strategie hilft, solche Arbeiten nach Risiko, Abhängigkeiten und Ressourcen einzuordnen.

6. Den Graphen auf Identität und Beziehung prüfen

Ein JSON-Parser bestätigt nur die Syntax. Ein Schema-Validator zeigt, ob die Knoten extrahierbar sind. Prüfe Struktur, Referenzen und Fachlichkeit getrennt:

Der Schema Markup Validator zeigt extrahierte Knoten und Verbindungen. Der Rich Results Test prüft Google-spezifische Funktionen. Google unterscheidet zwischen strukturiertem Markup und einer tatsächlichen Darstellung in Suchergebnissen.

Die Anleitung SEO-Prüfungen mit Python automatisieren behandelt die technische Automatisierung wiederkehrender Kontrollen im CI-System (fehlende Ziele, doppelte IDs, verwaiste Referenzen).

Release-Checkliste für den Entitätsgraphen

• →Jede @id beschreibt genau einen Knoten; Seite, Artikel, Person und Organisation bleiben getrennt.
• →Wiederkehrende Entitäten verwenden in allen betroffenen Templates dieselbe dokumentierte Kennung.
• →Jede Referenz mit @id zeigt auf eine definierte oder im Entitätskatalog belegte Entität.
• →mainEntity und mainEntityOfPage benennen den Hauptgegenstand der kanonischen URL.
• →about, author, publisher, worksFor und sameAs beruhen auf sichtbaren oder verantworteten Daten.
• →Externe sameAs-URLs wurden auf eindeutige Identität geprüft; unklare Einträge fehlen.
• →Der Graph wurde im ausgelieferten HTML, im Schema Markup Validator und im Rich Results Test kontrolliert.
• →Änderungen an Autorenprofil, Organisation, URL-Struktur oder Hauptthema lösen eine erneute Prüfung aus.

Häufige Fragen zur Modellierung

Muss jede Seite einen großen @graph enthalten?

Nein. @graph ist sinnvoll, sobald mehrere Knoten auf derselben Seite dieselben Entitäten verwenden oder ihre Beziehungen nachvollziehbar sein müssen. Eine einfache Seite mit einer Hauptentität kann mit einem einzelnen JSON-LD-Objekt auskommen.

Ist ein separater JSON-LD-Block pro Typ falsch?

Nein. Google verarbeitet verschachtelte und einzelne Items auf einer Seite. @graph mit stabilen @id-Referenzen macht diese Verbindung in einem gemeinsamen Modell leichter lesbar und testbar.

Stellt @id eine Verbindung zum Google Knowledge Graph her?

Nein. @id benennt einen Knoten im JSON-LD-Modell. Die Eigenschaft sagt nicht, dass eine Suchmaschine die Entität extern erkannt, zusammengeführt oder in einem bestimmten System gespeichert hat.

Wie lässt sich die Wirkung eines Roll-outs messen?

Dokumentiere, welche Templates und URLs wann den Graphen erhielten und ob die Referenzen gültig waren. Beobachte Suchdaten getrennt nach Seitentyp und Roll-out-Gruppe.

Ein guter Entitätsgraph endet nicht bei einem Validator. Er bleibt ein gepflegtes Modell der Seite: Eine stabile Kennung bezeichnet dieselbe Entität, jede Kante beschreibt eine reale Beziehung, und jede Änderung lässt sich gegen sichtbare Daten und verantwortete Quellen prüfen.

DPP-Daten mit Entitäten und JSON-LD verbindet der Beitrag Digitaler Produktpass und Structured Data.

Nächster Schritt

OLDSCHOOLSEO prüft Entitäten, JSON-LD und technische Ausgaben im Rahmen einer nachhaltigen Betreuung. Die Übersicht aller Leistungen steht unter Suchmaschinenoptimierung Stuttgart.

Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen

Sandra Krone und Michael Kienzler | Seriöse Suchmaschinenoptimierung aus Stuttgart | Seit 2018

Über den Autor: Sandra Krone

Sandra Krone ist Partnerin und Gründerin von OLDSCHOOLSEO. Ihre Arbeit beginnt bei der Analyse der Nutzerintention und der Content-Strategie, um daraus die Anforderungen für die redaktionelle und technische Umsetzung abzuleiten.

Mehr über die GründerProfil auf LinkedIn