@id Semantische Infrastruktur

@id

In einem JSON-LD-Block definiert @id den Uniform Resource Identifier, unter dem die beschriebene Entität im Linked-Data-Netz identifiziert wird. Ohne @id ist eine Entität ein anonymer (Blank-)Knoten, der nicht von außen referenziert werden kann. Durch die Vergabe einer @id wird die Entität adressierbar und kann von anderen JSON-LD-Blöcken auf derselben oder anderen Seiten referenziert werden. Best Practice ist die Verwendung der kanonischen URL der Entity Home als @id. In der semantischen Infrastruktur ist @id das Mittel, um lokale Entitätsbeschreibungen in das globale Wissensnetz einzubinden. Wenn mehrere Seiten dieselbe @id für eine Entität verwenden, signalisiert dies Suchmaschinen, dass es sich um dasselbe Ding handelt. Die konsequente Verwendung von @id über alle Seiten hinweg stärkt die Entitätsidentität und erleichtert die Konsolidierung von Informationen im Knowledge Graph. In Kombination mit sameAs schafft @id die Grundlage für die eindeutige Identifikation im strukturierten Web.

@id und Blank Nodes: Warum Anonymität im Wissensgraph scheitert

Eine Entität ohne @id existiert im Linked-Data-Netz de facto nicht. Sie ist ein Blank Node: eine lokale, nicht adressierbare Struktur, die Suchmaschinen zwar parsen, aber nicht mit externen Quellen verknüpfen können. Das ist der Unterschied zwischen einer Karteikarte im verschlossenen Schrank und einem öffentlichen Datensatz mit eindeutiger Kennung.

Der URI in @id muss nicht die aktuelle Browser-URL sein. Er muss die kanonische, persistente Adresse der beschriebenen Entität sein. Für eine Organization ist das typischerweise die Homepage, für eine Person die offizielle Profilseite, für ein Produkt die kanonische Produktseite. Entscheidend ist die Konsistenz: Wenn drei verschiedene Seiten dieselbe Organization beschreiben, müssen alle drei dieselbe @id verwenden.

Suchmaschinen behandeln übereinstimmende @id-Werte als Signal, dass dieselbe Entität gemeint ist. Variationen wie mit oder ohne Trailing-Slash, HTTP versus HTTPS, oder www gegen non-www erzeugen im schlimmsten Fall mehrere konkurrierende Knoten im Knowledge Graph statt eines einzigen starken.

Absolute URIs sind Pflicht. Relative Pfade wie /ueber-uns sind kein gültiger @id-Wert, auch wenn JSON-LD-Parser sie intern auflösen könnten. Wer @id konsequent und konsistent einsetzt, legt das Fundament für eine kohärente Entitätsidentität, die über einzelne Seiten und Domänen hinaus wirkt.

@id in der Praxis: Konsistenz als strategischer Vorteil

Die häufigste Schwachstelle in produktiven JSON-LD-Implementierungen ist keine fehlende Property, sondern eine inkonsistente @id. CMS-Systeme generieren dynamisch URLs mit Parametern, Trailing-Slashes oder Sprachpräfixen, die von Seite zu Seite variieren. Das Ergebnis: mehrere Blank-Node-ähnliche Fragmente statt einer kohärenten Entität im Knowledge Graph.

Die Lösung ist technisch einfach, strategisch aber konsequent durchzuhalten. Definiere pro Entitätstyp genau eine kanonische URI und verwende sie seitenübergreifend. Für die primäre Organization auf jeder Seite im Footer-JSON-LD, auf der About-Seite, in Breadcrumbs und in Produktbeschreibungen immer dieselbe @id.

Besonders wirksam ist die Kombination von @id mit sameAs. Während @id die interne Identität festlegt, verankert sameAs die Entität in externen Wissensgraphen: Wikidata, DBpedia, der Google Knowledge Graph. Eine Organization mit korrekter @id und sameAs auf den Wikidata-Eintrag ist für Suchmaschinen wesentlich einfacher zu disambiguieren als eine ohne diese Verknüpfungen.

In Kombination mit dem WebPage-Typ entfaltet @id seine volle Stärke: WebPage hat @id gleich der kanonischen URL der Seite, die beschriebene Entität hat ihre eigene @id, und via mainEntity oder about wird die Beziehung zwischen Seite und Entität explizit gemacht. Dieses Muster ist das Rückgrat jeder professionellen semantischen Infrastruktur.