sameAs-Profil-Abgleich - MetricSpot Docs

Was diese Prüfung macht

Parst das sameAs-Array aus deinem Organization- (oder Person-, LocalBusiness-)JSON-LD und führt für jede URL aus:

Setzt einen HEAD, dann einen GET ab und bestätigt eine 2xx-Antwort (mit Folgen eines Redirects).
Scannt das Ziel-HTML nach deinem Markennamen (name oder alternateName aus demselben JSON-LD).

Die Prüfung schlägt fehl, wenn eine URL 404 zurückgibt, auf eine unverwandte Domain redirected oder zu einer Seite auflöst, deren sichtbarer Inhalt die Marke nicht erwähnt. Das ist eine separate Prüfung von sameAs Social-Profile, die nur die Existenz des Arrays verifiziert.

Warum es zählt

Der ganze Sinn von sameAs ist, Google zu sagen: “Diese URLs verweisen alle auf dieselbe reale Entität wie diese Website.” Ist eine dieser URLs kaputt, scheitert das Entity-Merge — Google kann “Acme Inc auf LinkedIn” nicht mehr verlässlich mit deiner Site verknüpfen, wenn die LinkedIn-URL 404 liefert, und es kann “Acme Industries Ltd” nicht mit deiner “Acme Inc”-Seite verbinden, wenn der LinkedIn-Slug umbenannt wurde und nun einer anderen Firma gehört.

Der Schaden eines kaputten sameAs ist still. Deine strukturierten Daten validieren weiterhin. Der Rich Results Test bleibt grün. Aber der Knowledge Graph verweigert leise die Zuordnung des Profils zu dir — und Knowledge Panels, Marken-Karussells und die Zitations-Herkunft für KI-Agenten lehnen sich genau an diese Zuordnung an.

Die häufigsten Brüche, ungefähr nach Häufigkeit absteigend:

Twitter → X URL-Migration. Profile lösen weiterhin unter twitter.com auf (Twitter redirected), aber manche sameAs-Arrays zeigen auf Unterpfade, die nicht mehr funktionieren. Nutze immer https://x.com/handle.
LinkedIn-/company/-Slug-Umbenennungen. Beim Rebranding eines Unternehmens liefert der alte Slug 404. Die /company/-Numerik-ID redirected stabiler, ist aber hässlich.
Veraltete Profile im Array. Google+-Einträge aus 2018. Vine. Periscope. Audit-and-Prune.
Vanity-Domain-Redirects, die den Pfad fallen lassen. acme.co/twitter → https://x.com/ (ohne Handle). Verlink immer direkt die kanonische Profil-URL.
Groß-/Kleinschreibung-Drift. Manche Plattformen liefern 404 bei falscher Schreibweise im Slug. Teste, was du einfügst.

So behebst du es

1. Array auditen — curl-Schleife:

curl -s https://yourdomain.com/ \
  | grep -oE '"sameAs":\s*\[[^]]+\]' \
  | grep -oE 'https?://[^"]+' \
  | while read url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' -L -A 'Mozilla/5.0' "$url")
      echo "$code  $url"
    done

Alles mit 4xx oder 5xx ist tot. Alles, was per 3xx auf einen anderen Host weiterleitet, ist verdächtig — öffne es im Browser und bestätige, dass das Ziel noch deine Marke repräsentiert.

2. Array auditen — Browser-Skript. In die DevTools-Console auf deiner Homepage einfügen:

const ld = [...document.querySelectorAll('script[type="application/ld+json"]')]
  .map(s => { try { return JSON.parse(s.textContent); } catch { return null; } })
  .filter(Boolean)
  .flatMap(o => Array.isArray(o) ? o : [o]);

const sameAs = ld.flatMap(o => o.sameAs || []);
console.table(sameAs);

await Promise.all(sameAs.map(async url => {
  try {
    const r = await fetch(url, { mode: 'no-cors' });
    console.log(r.type === 'opaque' ? 'opaque' : r.status, url);
  } catch (e) {
    console.error('FAIL', url, e.message);
  }
}));

CORS macht viele Antworten opak, aber Netzwerkfehler (DNS, 5xx) tauchen als Errors auf. Für einen sauberen Statuscode nutze die curl-Schleife oben.

3. Schema.org-Validator. Füge deine URL in validator.schema.org ein — er zeigt JSON-LD-Parse-Fehler und das aufgelöste sameAs-Array. Hilfreich, wenn dein CMS das JSON verbiegt.

4. Pro Plattform ein stabiles kanonisches Handle. Wähle eine URL pro Profil und nutze sie überall — in sameAs, im Footer, in deiner E-Mail-Signatur, in Pressemitteilungen. Die kanonischen Formen, die gut altern:

LinkedIn: https://www.linkedin.com/company/<slug> (nicht /in/, nicht die numerische ID, kein lokalisierter /de.linkedin.com-Redirect).
X / Twitter: https://x.com/<handle> (die twitter.com-Form leitet weiter, aber x.com ist jetzt kanonisch).
YouTube: https://www.youtube.com/@<handle> (die moderne Handle-Form, nicht /channel/UCxxxx und nicht /user/xxxx).
GitHub: https://github.com/<org> (ohne Trailing Slash).
Wikipedia: Die englische en.wikipedia.org-URL, auch wenn du Sprachvarianten hast — sprachspezifische URLs sind nicht die kanonische Entität.
Mastodon: https://<instance>/@<handle> (die föderierte URL, keine gehashte ID).

5. Nach dem Fix doppelt validieren. Lass den Schema Markup Validator für Syntax laufen, danach den Google Rich Results Test, um zu bestätigen, dass Google das JSON-LD abrufen und parsen kann. Der Rich Results Test läuft aus Googles IP — wenn ein sameAs-Ziel den Googlebot-User-Agent oder das Land blockt, scheitert es dort, auch wenn dein curl erfolgreich war.

Siehe auch: Organization sameAs, sameAs Social-Profile, Links zu Social-Profilen.

Häufig gestellte Fragen

Wie oft soll ich mein sameAs-Array auditen?

Zweimal jährlich reicht für die meisten Sites. Plattformen benennen Slugs um (LinkedIn besonders) und Profile verwaisen. Pack die curl-Schleife oben in deine Release-Checkliste oder einen geplanten Monitoring-Job — eine 30-Sekunden-Prüfung.

Meine LinkedIn-URL leitet auf eine “Company not found”-Seite weiter, gibt aber 200 zurück. Besteht die Prüfung?

Es kommt drauf an. Die Prüfung macht den Marken-Match-Schritt genau für diesen Fall — LinkedIn liefert 200 mit einem generischen “Diese Seite existiert nicht”-Body, der Marken-Scan scheitert und die Regel feuert. Aktualisiere die URL auf den aktuellen /company/<slug> oder entfern sie.

Vermeide sie. Wenn Googlebot die Seite nicht anonym abrufen kann, kann es die Entität nicht bestätigen. Die meisten großen Social-Plattformen rendern eine öffentliche Profil-Shell ohne Auth — wenn deine das nicht tut, ist dieses Profil als sameAs-Ziel nutzlos.