@id (Schema.org)

1. Kurzdefinition

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.

2. Ausführliche Erklärung

@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/<slug>#person für Personen, https://www.example.ch/blog/<slug>#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/<slug>#person für Personen, /blog/<slug>#article für Posts. Diese Konventionen einmal definieren, in der Layout-Template-Logik fest verankern, nie wieder ändern.

3. 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.

4. Typische Fehler & Missverständnisse

×@id als relativen Pfad (<code>/team/anna</code>) 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 (<code>#org</code> statt <code>https://www.example.ch/#organization</code>) — fehlt die globale Eindeutigkeit.
×@id ohne Anchor-Suffix gestalten (<code>https://www.example.ch/</code> 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.

5. 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 <code>/<path>/<slug>#<type></code> — 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.

6. 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. <code>#organization</code> 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.

Definition von Marco Biner · Certified GEO Expert

Marco Biner — Founder geoquality.ai, Certified GEO Expert

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

GEO Importance Rank

Wie wichtig ist dieser Begriff für Generative Engine Optimization?

64 /100

Wichtig Range 50–69

FAQs

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: <code>/#organization</code> 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: <code>#organization</code> für die Site-Hauptorganisation, <code>#website</code> für Site-Identität, <code>#person</code> für Personen, <code>#article</code> für Articles, <code>#term</code> 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 <code>/team/anna</code>, Person-@id <code>/team/anna#person</code>, ProfilePage-@id <code>/team/anna</code> selbst. Klare Trennung.