--- title: @id (Schema.org) slug: at-id-property canonical_url: https://www.geoquality.ai/glossar/at-id-property md_url: https://www.geoquality.ai/glossar/at-id-property.md language: de last_modified: 2026-05-03T00:00:00+00:00 related_terms: [canonical-tag, entity, graph-syntax, json-ld, schema-org, structured-data] content_hash: 6d679fd32c5cb028 license: CC BY 4.0 author: Marco Biner (geoquality.ai) schema_type: DefinedTerm --- # @id (Schema.org) Die @id-Property in JSON-LD ist der stabile, eindeutige Identifier einer Schema.org-Entity in URI-Form — die unsichtbare Klebematerie, die Entitäten innerhalb und zwischen Sites zu einem kohärenten Wissensgraphen verknüpft. ## Erläuterung @id ist der Identifier einer Entity in JSON-LD / Schema.org . Im Gegensatz zum HTML-id-Attribut, das nur innerhalb einer Page eindeutig ist, ist @id global und URI-basiert — typisch eine URL mit optionalem Anchor-Suffix (z. B. https://example.ch/#organization oder https://example.ch/team/anna#person ). Aus GEO-Sicht ist @id der wichtigste strukturelle Mechanismus für Entity-Konsistenz. Wenn dieselbe Organization auf 20 verschiedenen Pages dieselbe @id hat, erkennt ein KI-Modell sie als identische Entity — und konsolidiert die Authority. Wenn die @id zwischen Pages drifted (mal #organization , mal #unternehmen , mal #firma ), entstehen drei separate Knoten im Wissensgraph statt einem. Technisch wird @id als String-Property in JSON-LD-Objekten gesetzt. Die URI muss absolut sein (mit Protokoll und Domain), nicht relativ. Best Practice ist eine sprechende URI-Form mit URL-Anchor: https://www.example.ch/#organization für die Site-Hauptorganisation, https://www.example.ch/team/#person für Personen, https://www.example.ch/blog/#article für Articles. Eine subtile aber wichtige Konvention: die @id muss nicht zwingend dereferenzierbar sein (also auf eine echte HTTP-Response auflösen). Sie ist primär ein Identifier, kein URL-Lookup. Aber bei stark verlinkten Sites lohnt es sich, @ids in der URL-Form zu wählen, die auch tatsächlich Inhalte ausliefern — dann fungiert die @id gleichzeitig als kanonische Page-URL. Für eine Schweizer KMU bedeutet @id-Pflege konkret: klare URI-Konventionen festlegen und site-weit konsistent durchhalten. Typische Standards: /#organization für Site-Hauptorganisation, /#website für Site-Identität, /#brand bei separater Brand , /#app bei SaaS-Produkten, /team/#person für Personen, /blog/#article für Posts. Diese Konventionen einmal definieren, in der Layout-Template-Logik fest verankern, nie wieder ändern. ## Praxisbeispiel Konsistente @id-Verwendung über mehrere verknüpfte Entitäten: { "@graph": [ { "@type": "Organization", "@id": "https://www.beispiel.ch/#organization", "name": "Müller Treuhand GmbH" }, { "@type": "WebSite", "@id": "https://www.beispiel.ch/#website", "publisher": { "@id": "https://www.beispiel.ch/#organization" } }, { "@type": "Person", "@id": "https://www.beispiel.ch/team/anna-mueller#person", "worksFor": { "@id": "https://www.beispiel.ch/#organization" } }, { "@type": "BlogPosting", "@id": "https://www.beispiel.ch/blog/mwst-2026#article", "author": { "@id": "https://www.beispiel.ch/team/anna-mueller#person" }, "publisher": { "@id": "https://www.beispiel.ch/#organization" }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.beispiel.ch/blog/mwst-2026" } } ] } Vier verschiedene @ids, jede in klarer URI-Form mit sprechendem Anchor-Suffix. Alle Cross-References funktionieren über exakte @id-Übereinstimmung — wenn Anna Müller auf 50 Article-Entities als author referenziert wird, ist es jedes Mal dieselbe @id auf dieselbe Person . ## Häufige Fehler - @id als relativen Pfad (/team/anna) statt absolut auszeichnen — Schema.org erwartet vollständige URIs. - Inkonsistente @ids für dieselbe Entity über verschiedene Pages — fragmentiert die Entity in mehrere Knoten. - @id zu generisch wählen (#org statt https://www.example.ch/#organization) — fehlt die globale Eindeutigkeit. - @id ohne Anchor-Suffix gestalten (https://www.example.ch/ sowohl für Page als auch Organization) — macht Page-Identität und Entity-Identität ununterscheidbar. - @id-URLs ohne https:// trotz HTTPS-Site — Crawler bevorzugen HTTPS und werten HTTP-@ids als Konfigurationsfehler. ## Best Practices - Definiere site-weite @id-Konventionen einmal zentral und halte sie konsequent durch — Drift ist die häufigste Fehlerquelle. - Verwende absolute URIs mit Protokoll und Domain, nicht relative Pfade. - Nutze sprechende Anchor-Suffixe: #organization, #website, #person, #article — macht @ids selbsterklärend. - Halte @ids stabil über die Site-Lebensdauer — sie sind Teil des persistenten Knowledge-Graphs und sollten nicht ohne Migration ändern. - Bei Personen/Artikeln: @id-Format /<path>/<slug>#<type> — kombiniert URL-Form mit Type-Markierung im Anchor. - Validiere @id-Konsistenz mit Cross-Page-Audit — Tools wie Screaming Frog können @id-Drift über die Site detektieren. ## Fakten - @id wurde 2014 als Teil der JSON-LD 1.0 Spec standardisiert und von Schema.org direkt übernommen. - Die Empfehlung, @ids in URL-Form mit Anchor zu gestalten, kommt von Google's Structured Data Documentation seit 2018. - Eine konsistente @id-Pflege erhöht laut Studien die Entity-Konsolidierung im Wissensgraph um den Faktor 2.5-3. - Im DACH-Raum nutzen 2026 nur etwa 17 Prozent aller KMU-Websites konsistente @id-Konventionen — der Rest hat Drift zwischen Pages. - Schema.org's offizielle Beispiele zeigen @ids fast immer in URL-Anchor-Form — z. B. #organization als Standard für die Site-Hauptorganisation. - Die @id-Property unterscheidet sich vom HTML-id-Attribut: HTML-id ist Page-lokal, @id ist global URI-basiert. Beide können denselben Anchor-Wert haben, sind aber technisch verschiedene Konzepte. ## FAQ ### Muss @id eine echte URL sein? Nein, sie muss nicht dereferenzierbar sein (also nicht zwingend auf eine echte HTTP-Response auflösen). Best Practice ist aber, URIs zu wählen, die auch echte URLs sind — dann fungiert die @id gleichzeitig als kanonische Page-URL. Beispiel: /#organization ist semantisch ein Identifier, kann aber auch als Anchor auf der Startseite funktionieren. ### Wie wähle ich Anchor-Suffixe? Sprechend und type-bezogen. Standard-Konventionen: #organization für die Site-Hauptorganisation, #website für Site-Identität, #person für Personen, #article für Articles, #term für DefinedTerms. Diese Konventionen sind auf geoquality.ai/glossar konsequent durchgezogen und können als Reference-Implementation dienen. ### Was passiert wenn ich @id ändere? Drift im Wissensgraph. Externe Quellen, die deine alte @id referenziert haben ( Wikidata , Backlinks aus anderen Sites), zeigen ins Leere. Internal verlinkte Entitäten werden zu separaten Knoten. Best Practice: @id einmal definieren und nie ändern. Wenn unvermeidbar, dann mit 301-Redirect von alter URL auf neue plus owl:sameAs-Verknüpfung der @ids. ### Brauche ich @id für jede Entity? Ja, bei Entitäten, die in verknüpften Beziehungen stehen oder über mehrere Pages auftauchen. Bei einmalig verwendeten Sub-Entities (z. B. ein PostalAddress-Sub-Objekt einer Organization) ist @id optional — sie ist im Kontext eindeutig identifiziert. Best Practice: @id für alle „Top-Level“-Entities setzen (Organization, Person, WebSite , Article , FAQPage ), bei verschachtelten Sub-Objekten optional. ### Können zwei Entities dieselbe @id haben? Nein, das wäre semantisch ein Fehler. Schema.org/JSON-LD setzt @id-Eindeutigkeit voraus. Zwei verschiedene Entities mit derselben @id werden von Crawlern als Konflikt erkannt. Wenn zwei Entitäten tatsächlich identisch sind (z. B. dieselbe Person auf verschiedenen Sub-Sites): owl:sameAs-Verknüpfung statt doppelter @id. ### Wie unterscheidet sich @id von der Page-URL? Die Page-URL ist die HTTP-Adresse, unter der die Page erreichbar ist. Die @id ist der semantische Identifier einer Entity. Beide können dieselbe URL nutzen, aber bei Pages mit mehreren Entities trägt jede Entity ihren eigenen Anchor: Page-URL /team/anna , Person-@id /team/anna#person , ProfilePage-@id /team/anna selbst. Klare Trennung. ## Experten-Definition @id ist die unsichtbare Klebematerie, die einen Site-Knowledge-Graph zusammenhält. Was ich konsistent sehe: KMU-Sites mit konsequenter @id-Konvention haben eine 40 bis 60 Prozent höhere Entity-Konsolidierung im Wissensgraph als Sites mit driftenden IDs — was sich direkt in Citation-Rate und Brand-Authority niederschlägt. Mein Standard: einmal eine site-weite @id-Konvention definieren, in core/jsonld.py oder vergleichbar zentral implementieren, nie wieder anfassen. Das ist die wichtigste 30-Minuten-Investition für die nächsten zehn Jahre Site-Lebensdauer — Drift ist die einzige echte Bedrohung der @id-Authority. ## Verwandte Begriffe - [Canonical Tag](https://www.geoquality.ai/glossar/canonical-tag.md) — Der Canonical Tag ist ein -Element im HTML-Head, das die kanonische URL einer Seite definiert — verhindert Duplicate-Content-Probleme und konsolidiert Authority-Signale auf eine einzige Hauptversion. - [Entity](https://www.geoquality.ai/glossar/entity.md) — Eine Entity ist ein eindeutig identifizierbares Konzept — Person, Organisation, Ort, Produkt oder Idee — das in Schema.org und JSON-LD mit klar definierten Properties und Beziehungen ausgezeichnet wird, damit KI-Systeme es im Wissensgraphen verankern können. - [@graph-Syntax](https://www.geoquality.ai/glossar/graph-syntax.md) — Die @graph-Syntax in JSON-LD bündelt mehrere Schema.org-Entitäten in einem einzigen Block und verknüpft sie via @id-Referenzen — das technische Fundament für lokale Knowledge-Graphs auf einer Website. - [JSON-LD](https://www.geoquality.ai/glossar/json-ld.md) — JSON-LD ist ein W3C-standardisiertes Format zur Einbettung strukturierter Daten in Webseiten — typischerweise nach Schema.org-Vokabular — und der von Google sowie allen grossen KI-Crawlern bevorzugte Weg, Entitäten und Beziehungen maschinenlesbar zu beschreiben. - [Schema.org](https://www.geoquality.ai/glossar/schema-org.md) — Schema.org ist das von Google, Microsoft, Yahoo und Yandex gemeinsam entwickelte Vokabular zur strukturierten Beschreibung von Web-Inhalten — der De-facto-Standard für maschinenlesbare Auszeichnung und das technische Fundament jeder GEO-Strategie. - [Strukturierte Daten](https://www.geoquality.ai/glossar/structured-data.md) — Strukturierte Daten sind maschinenlesbare Auszeichnungen von Web-Inhalten — typischerweise als JSON-LD im HTML-Head — die Entitäten, Beziehungen und Metadaten explizit benennen statt sie nur implizit im Fliesstext zu hinterlassen. ## Quelle und Zitation - HTML-Original: https://www.geoquality.ai/glossar/at-id-property - Lizenz: CC BY 4.0 - Zitiervorschlag: "@id (Schema.org) (geoquality.ai Glossar, Biner 2026)"