Als ich sameAs zum ersten Mal in strukturierten Daten gesehen habe, wirkte die Property ziemlich unspektakulär. Man trägt LinkedIn ein, ergänzt vielleicht noch Instagram oder ein Autorenprofil und widmet sich wieder den vermeintlich wichtigeren Bestandteilen des Markups.
Ganz so nebensächlich ist sameAs allerdings nicht.
Mit jeder dort eingetragenen URL macht man eine konkrete Aussage: Die Entität, die im Schema-Knoten beschrieben wird, ist dieselbe Entität, die unter dieser anderen URL repräsentiert wird.
Das ist mehr als ein externer Link und auch mehr als ein Hinweis auf weiterführende Informationen. sameAs soll Maschinen dabei helfen, verschiedene Beschreibungen derselben Person, Organisation, Marke, Publikation oder Sache miteinander zu verbinden.
Das kann für Google und Bing relevant sein, aber auch für Knowledge Graphs, Datenbanken, Webcrawler und KI-gestützte Suchsysteme. Trotzdem ist die Property weder ein garantierter Rankingfaktor noch ein magischer Schalter, durch den eine Person plötzlich häufiger in ChatGPT oder Perplexity auftaucht.
Leider heißt die Property nicht pleaseUnderstandWhoIAm. Inhaltlich geht es aber ziemlich genau darum.
Was sameAs wirklich bedeutet
Schema.org definiert sameAs als die URL einer Referenzseite, die die Identität des beschriebenen Objekts eindeutig erkennen lässt. Als Beispiele nennt Schema.org eine Wikipedia-Seite, einen Wikidata-Eintrag oder eine offizielle Website. Die Property kann bei Thing und damit grundsätzlich bei allen davon abgeleiteten Schema.org-Typen verwendet werden.
Dazu gehören beispielsweise:
PersonOrganizationBrandProductPlaceEventCreativeWork
Die technische Verfügbarkeit einer Property bedeutet jedoch nicht, dass sie in jedem denkbaren Fall sinnvoll ist. Entscheidend ist der Teil der Definition, der schnell überlesen wird: Eine eingetragene Seite muss die Identität eindeutig erkennen lassen.
Ein Zeitungsartikel kann ausführlich über eine Person berichten, ihren Beruf nennen und mehrere Zitate enthalten. Trotzdem ist dieser Artikel normalerweise keine Identitätsseite der Person. Er ist ein Dokument über sie.
Ein offizielles Autorenprofil, eine persönliche Website oder ein eindeutig zugeordnetes LinkedIn-Profil repräsentiert die Person dagegen selbst.
Mit sameAs soll daher nicht ausgedrückt werden:
Auf dieser Seite werde ich erwähnt.
Die Aussage lautet vielmehr:
Diese URL repräsentiert dieselbe Entität, die auch in diesem Schema-Knoten beschrieben wird.
Diese Unterscheidung ist nicht nur semantische Haarspalterei. Wird eine beliebige Erwähnung als sameAs markiert, behauptet das Markup eine stärkere Beziehung, als zwischen den beiden Seiten tatsächlich besteht.
Warum Maschinen Unterstützung bei der Identität brauchen
One of the most interesting things I noticed while testing the Knowledge Graph Search API was this: the same entity can aMenschen erkennen Identitäten häufig aus dem Kontext. Wir sehen einen Namen, ein Foto, einen Arbeitgeber und eine Berufsbezeichnung und können daraus meist ableiten, welche Person gemeint ist.
Eine Maschine erhält zunächst einzelne Signale:
- einen Namen,
- eine URL,
- sichtbaren Text,
- strukturierte Daten,
- interne Verknüpfungen,
- externe Profile,
- Erwähnungen auf anderen Domains.
Diese Signale können eindeutig sein, müssen es aber nicht.
Mehrere Menschen können denselben Namen tragen. Eine Firma kann unter ihrem Markennamen, dem vollständigen rechtlichen Namen und verschiedenen Abkürzungen auftreten. Nach einer Umfirmierung können zusätzlich alte und neue Bezeichnungen parallel im Web bestehen.
Das dahinterliegende Problem wird häufig als Entity Resolution oder Entitätsauflösung bezeichnet. Ein System versucht dabei festzustellen, ob mehrere Datensätze oder Webseiten dieselbe reale Person, Organisation oder Sache beschreiben.
sameAs bietet dafür eine explizite Verbindung. Die Property ersetzt jedoch nicht die übrigen Informationen. Ein Name, ein Bild, eine offizielle Website, eine Beschreibung und konsistente Profildaten bleiben notwendig, damit die Zuordnung plausibel ist.
Eine falsche Verbindung wird durch JSON-LD nicht richtiger. Strukturierte Daten formulieren eine Aussage nur in einer Form, die Maschinen leichter verarbeiten können.
Welche Rolle sameAs bei Google, Bing und KI-Systemen spielt
Schema.org ist kein exklusives Google-Format. Das Vokabular wurde dafür entwickelt, strukturierte Informationen in Webseiten einzubetten, damit Suchmaschinen und andere Anwendungen deren Inhalte und Beziehungen besser verarbeiten können.
Google dokumentiert mehrere konkrete Einsatzmöglichkeiten. Bei Organization kann sameAs auf externe Profile verweisen, etwa auf Social-Media- oder Bewertungsseiten. Mehrere URLs sind erlaubt. Google beschreibt strukturierte Organisationsdaten außerdem als Möglichkeit, eine Organisation besser zu verstehen und von anderen Organisationen zu unterscheiden.
Bei Artikeln kann Google sowohl author.url als auch author.sameAs verwenden, um Autoren eindeutig zuzuordnen. Für interne Autorenprofile empfiehlt Google zusätzlich ProfilePage-Markup.
Auch Bing verarbeitet strukturierte Daten und unterstützt unter anderem Schema.org in JSON-LD. Microsoft beschreibt strukturierte Daten als Hinweise, durch die Bing Inhalte und Beziehungen auf einer Seite besser verstehen kann. Microsoft warnt gleichzeitig davor, falsche oder irreführende Angaben in nicht sichtbares Markup einzubauen.
Bei KI-gestützten Such- und Antwortsystemen ist weniger öffentlich dokumentiert.
OpenAI erklärt, dass der OAI-SearchBot Websites erfasst, damit sie in den Suchfunktionen von ChatGPT erscheinen können. Seiten, die diesen Bot ausschließen, werden laut OpenAI nicht in ChatGPT Search angezeigt.
Perplexity beschreibt den PerplexityBot als Crawler, der Websites für die Suchergebnisse von Perplexity erfassen und verlinken soll. Der Anbieter empfiehlt, diesen Bot zuzulassen, wenn eine Website in den Suchergebnissen erscheinen soll.
Anthropic stellt Claude einen Webzugriff zur Verfügung, durch den das System aktuelle Webseiten recherchieren und als Quellen verwenden kann. Die öffentliche Dokumentation beschreibt jedoch keine besondere Auswertung von sameAs.
Für keinen dieser KI-Anbieter ist öffentlich belegt, dass die bloße Ergänzung von sameAs unmittelbar zu mehr Erwähnungen, höheren Positionen oder häufigeren Quellenangaben führt.
Der mögliche Nutzen liegt an einer anderen Stelle: Webbasierte KI-Systeme müssen ebenfalls entscheiden, welche Person mit einem Namen gemeint ist, welche Domain offiziell ist und ob zwei Profile zur gleichen Organisation gehören. Ein konsistenter Schema-Graph kann ihnen dafür zusätzliche maschinenlesbare Hinweise anbieten – sofern das jeweilige System die Daten ausliest und berücksichtigt.
sameAs ist damit kein GEO-Hack, sondern ein Bestandteil sauberer Entity-Daten.
Der Unterschied zwischen sameAs, url, @id und ähnlichen Angaben
Mehrere Eigenschaften in strukturierten Daten scheinen auf den ersten Blick dasselbe zu tun: Sie enthalten URLs oder Kennungen. Tatsächlich erfüllen sie unterschiedliche Aufgaben.
| Element | Aufgabe |
|---|---|
@id | Gibt einem Schema-Knoten eine stabile und wiederverwendbare Kennung |
url | Verweist auf die primäre oder offizielle Webseite einer Entität |
sameAs | Verbindet eine Entität mit weiteren Seiten, die dieselbe Identität repräsentieren |
mainEntityOfPage | Gibt an, dass eine Entität das Hauptthema einer bestimmten Seite ist |
identifier | Enthält eine formale Kennung wie ISBN, GTIN oder UUID |
rel="canonical" | Kennzeichnet die bevorzugte URL unter gleichen oder ähnlichen Dokumenten |
hreflang | Verknüpft sprachliche oder regionale Seitenvarianten |
@id als interne Entitätskennung
@id ist nicht mit einer normalen anklickbaren Profil-URL gleichzusetzen. Die Angabe gibt einem JSON-LD-Knoten eine eindeutige Kennung, auf die andere Teile des Graphen verweisen können.
Eine Person könnte beispielsweise folgende @id erhalten:
"@id": "https://example.com/about/#person"Das Fragment #person muss keine separate sichtbare Seite darstellen. Es dient als Kennung der Person innerhalb des Datenmodells.
Wenn dieselbe Person später als Autor eines Artikels angegeben wird, kann der Artikel auf genau diese @id verweisen. So entsteht nicht auf jeder Seite ein neuer, isolierter Person-Knoten.
url als primäre Seite
url verweist normalerweise auf die zentrale Webseite der beschriebenen Entität.
Bei einer Person kann das die eigene About-Seite sein. Bei einer Organisation ist es in der Regel die offizielle Unternehmenswebsite. Google beschreibt url bei Organisationen ausdrücklich als deren Website und als Hilfe bei der eindeutigen Identifizierung.
sameAs als externe Identitätsverbindung
sameAs ergänzt weitere Seiten, die dieselbe Entität eindeutig repräsentieren. Bei einer Person könnten das LinkedIn, Wikidata oder ein offizielles Autorenprofil sein.
Die Property ersetzt weder @id noch url. Ein sauberer Entitätsknoten kann alle drei Angaben enthalten.
mainEntityOfPage als thematische Beziehung
Eine Seite kann hauptsächlich von einer Person oder einem Unternehmen handeln, ohne selbst die offizielle Repräsentation dieser Entität zu sein.
Ein Unternehmensporträt in einem Magazin könnte das Unternehmen als Hauptentität behandeln. Der Artikel wird dadurch aber nicht zu einer sameAs-Seite des Unternehmens.
identifier als formale Kennung
Schema.org sieht identifier unter anderem für ISBNs, GTINs und UUIDs vor. Ein LinkedIn-Profil ist keine solche formale Kennung und gehört deshalb normalerweise nicht in dieses Feld.
Canonical und hreflang als Dokumentbeziehungen
Ein Canonical-Tag hilft Suchmaschinen, aus mehreren gleichen oder sehr ähnlichen Dokument-URLs eine bevorzugte Version auszuwählen. Es verbindet keine Personen oder Unternehmen.
hreflang kennzeichnet dagegen sprachliche oder regionale Seitenvarianten. Die deutsche und englische Version einer About-Seite sollten deshalb nicht über sameAs miteinander verbunden werden. Sie können aber beide denselben Person-Knoten und dieselbe @id verwenden.
Die kürzeste Merkhilfe lautet:
Canonical und hreflang organisieren Seiten.@id, url und sameAs organisieren Entitäten.
Welche URLs in sameAs gehören – und welche nicht
Eine URL ist geeignet, wenn sie dieselbe Entität so eindeutig repräsentiert, dass kaum Interpretationsspielraum bleibt.
Bei einer Person können das sein:
- eine offizielle persönliche Website,
- ein eindeutig zugeordnetes Social-Media-Profil,
- ein Autorenprofil bei einer Zeitung oder einem Verlag,
- ein Wikidata- oder Wikipedia-Eintrag,
- ein offizielles Profil in einer relevanten Fachdatenbank.
Bei einer Organisation kommen beispielsweise offizielle Unternehmensprofile, Branchenverzeichnisse, Bewertungsplattformen oder Wissensdatenbanken infrage. Google nennt für Organization.sameAs ausdrücklich externe Profile auf Social-Media- und Bewertungsseiten.
Die Plattform allein macht eine URL jedoch nicht geeignet. Ein Profil sollte klar erkennen lassen, wem es gehört. Hilfreich sind übereinstimmende Namen, Bilder, Berufsangaben, Unternehmensdaten und Verlinkungen zur offiziellen Website.
Nicht in sameAs gehören normalerweise:
- einzelne Presseartikel über die Entität,
- Gastbeiträge der Person,
- allgemeine Arbeitgeber- oder Kundenseiten,
- interne Suchergebnisse,
- Kategorieseiten mit mehreren Personen,
- Seiten, auf denen der Name lediglich erwähnt wird,
- Profile ähnlich benannter Personen oder Unternehmen.
Ein Autorenprofil kann die Identität einer Person darstellen. Ein einzelner Artikel desselben Autors stellt dagegen in erster Linie ein Article oder BlogPosting dar.
Ebenso repräsentiert die Homepage eines Arbeitgebers zunächst den Arbeitgeber. Eine konkrete Mitarbeiterseite kann dagegen eine eindeutige Profilseite der Person sein.
Bei Muttergesellschaften, Marken und Tochterunternehmen ist besondere Vorsicht notwendig. Eine Tochtergesellschaft ist nicht automatisch dieselbe Entität wie der Konzern. Eine Produktmarke ist nicht zwingend identisch mit dem Unternehmen, dem sie gehört.
Eine einfache Prüffrage hilft bei fast allen Grenzfällen:
Würde eine unabhängige Person diese URL öffnen und zweifelsfrei sagen, dass dort exakt dieselbe Entität dargestellt wird?
Lautet die Antwort nur „irgendwie schon“, ist sameAs wahrscheinlich nicht die richtige Property.
Wie du sameAs sauber implementierst
Bevor externe Profile gesammelt werden, sollte feststehen, welche zentrale Entität beschrieben wird. Handelt es sich um eine Person, eine Organisation, eine Marke oder ein Werk?
Danach braucht die Entität eine stabile @id und eine primäre url.
Ein einfacher Person-Knoten könnte so aussehen:
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/about/#person",
"name": "Max Mustermann",
"url": "https://example.com/about/",
"image": {
"@type": "ImageObject",
"url": "https://example.com/images/max-mustermann.jpg"
},
"jobTitle": "SEO Consultant",
"sameAs": [
"https://www.linkedin.com/in/max-mustermann/",
"https://example-publisher.com/authors/max-mustermann/",
"https://www.wikidata.org/wiki/Q123456"
]
}Die About-Seite ist in diesem Beispiel die primäre url. Die weiteren Profile stehen unter sameAs, weil sie dieselbe Person auf anderen Plattformen repräsentieren.
Wird die Person als Autor eines Blogbeitrags verwendet, muss nicht noch einmal eine unabhängige Person angelegt werden:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/blog/sameas-schema-org/#article",
"headline": "sameAs in Schema.org: Wie Maschinen erkennen, wer oder was gemeint ist",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/blog/sameas-schema-org/"
},
"author": {
"@type": "Person",
"@id": "https://example.com/about/#person"
},
"publisher": {
"@type": "Organization",
"@id": "https://example.com/#organization"
}
}Der Artikel verweist damit auf dieselbe Person, die bereits auf der About-Seite beschrieben wurde. Das ist sauberer, als bei jedem Beitrag einen neuen Autor-Knoten mit leicht abweichenden Angaben zu erzeugen.
Bei der praktischen Umsetzung würde ich in dieser Reihenfolge vorgehen:
- Die zentrale Entität bestimmen.
- Eine dauerhafte
@idfestlegen. - Die offizielle Seite als
urlauswählen. - Nur eindeutige Identitätsprofile für
sameAssammeln. - Bestehendes Markup des Themes oder SEO-Plugins prüfen.
- Doppelte Person- oder Organization-Knoten zusammenführen.
- Das gerenderte JSON-LD validieren.
- Prüfen, ob wichtige Suchmaschinen- und KI-Crawler die Seite erreichen können.
Viele WordPress-Seiten erzeugen bereits über das Theme, Rank Math, Yoast oder andere Plugins einen Schema-Graphen. Ein zusätzlich eingefügter vollständiger JSON-LD-Block kann deshalb unbeabsichtigt eine zweite Version derselben Person oder Organisation erzeugen.
Bevor eigener Code ergänzt wird, sollte also geklärt werden, ob sich der vorhandene Knoten erweitern lässt.
Die Syntax kann mit dem Schema Markup Validator geprüft werden. Googles Rich Results Test kontrolliert dagegen hauptsächlich Markup, das für bestimmte Google-Suchergebnisfunktionen unterstützt wird. Ein gültiges sameAs muss dort deshalb nicht als eigenständige Verbesserung auftauchen.
Häufige Fehler und realistische Grenzen
Der häufigste Fehler besteht darin, sameAs wie eine Social-Link-Sammlung zu behandeln. Ein Theme bietet fünfzehn Profilfelder an, also werden fünfzehn Profile eingetragen.
Die Anzahl ist jedoch kein Qualitätsmerkmal.
Jede zusätzliche URL ist eine weitere Identitätsbehauptung, die korrekt, aktuell und widerspruchsfrei bleiben muss. Drei eindeutige Profile sind deshalb oft sinnvoller als zwölf schwache oder veraltete Verbindungen.
Ein zweiter Fehler ist die Auswahl von Seiten nach Domain-Autorität. Ein Artikel auf einer bekannten Nachrichtenseite wird nicht zur Identitätsseite, nur weil die Domain vertrauenswürdig ist.
Auch widersprüchliche Schema-Knoten sind problematisch. Wenn ein Plugin dieselbe Person unter /#person anlegt, ein eigenes Snippet /about/#author verwendet und ein drittes Tool nur den Namen ohne Kennung ausgibt, entstehen zunächst mehrere Knoten. Suchsysteme können versuchen, sie zusammenzuführen, aber das Markup liefert ihnen keine saubere gemeinsame Grundlage.
Die Informationen im JSON-LD sollten außerdem mit den sichtbaren Seiteninhalten übereinstimmen. Bing warnt ausdrücklich davor, falsche oder irreführende Daten in nicht sichtbares Markup einzubauen.
Wer im Schema zehn Tätigkeitsfelder, mehrere Unternehmen und zahlreiche Profile angibt, auf der sichtbaren About-Seite aber nur einen Namen zeigt, schafft keine überzeugende Entität. Er schafft zwei unterschiedliche Versionen derselben Website: eine für Menschen und eine für Parser.
sameAs kann Maschinen helfen, bereits vorhandene Identitätssignale miteinander zu verbinden. Die Property kann jedoch keine fehlende Bekanntheit, schlechte Inhalte, widersprüchliche Unternehmensinformationen oder mangelnde externe Präsenz ausgleichen.
Sie ist Infrastruktur, kein Verstärker.
Fazit: Präzision ist wichtiger als die Länge des Arrays
ThsameAs sieht im JSON-LD wie eine kleine Liste von URLs aus. Inhaltlich handelt es sich jedoch um eine starke Aussage über die Identität einer Person, Organisation oder Sache.
Die Property sollte deshalb nicht danach befüllt werden, wie viele Profile sich finden lassen. Entscheidend ist, welche Seiten die beschriebene Entität wirklich eindeutig repräsentieren.
Google dokumentiert konkrete Anwendungen zur Zuordnung von Autoren und Organisationen. Bing nutzt strukturierte Daten ebenfalls als Verständnishilfe. ChatGPT, Perplexity und Claude können auf Webinhalte zugreifen, veröffentlichen aber keine Bestätigung, dass sameAs für sie ein eigenständiger Sichtbarkeits- oder Rankingschalter ist.
Das macht die Property nicht unwichtig. Es macht nur eine realistische Einordnung notwendig.
Ein sauberer Entity-Graph beantwortet für Maschinen eine grundlegende Frage, ohne mehr zu versprechen, als technisch belegt ist:
Wer oder was ist hier tatsächlich gemeint?
