Wir haben eine ZER0ONE-Firma und zwei Domains. Studio-Consulting läuft auf zer0one.codes, das Cloud-Render-Product auf zer0onelab.com. Beide sind rechtlich dieselbe Firma. Für Google waren sie lange zwei separate Entitäten.

Das Problem ist nicht Duplicate Content — die Sites haben komplett getrennten Content. Das Problem ist Entity-Resolution: Google sieht auf zer0one.codes eine Organization mit Namen „ZER0ONE" und auf zer0onelab.com eine Organization mit Namen „ZER0ONE Lab". Zwei ähnliche Namen, keine expliziten Verbindungs-Signale. Google's default heuristic ist: „wahrscheinlich zwei ähnliche Firmen, keine Beziehung."

Das führt zu split-Rankings: wenn jemand nach „ZER0ONE" sucht, sieht er beide Sites, aber der Trust-Score verteilt sich auf zwei kleine Entitäten statt sich auf eine große Firma zu konsolidieren.

Die technische Lösung

Schema.org's @id ist eine stabile URI die als Entity-Identifier fungiert. Zwei Nodes mit dem gleichen @id sind für Suchmaschinen dieselbe Entity — egal auf welcher Domain sie stehen.

Wir haben unsere JSON-LD-Struktur so umgebaut:

{
  "@context": "https://schema.org",
  "@type": ["Organization", "LocalBusiness", "ProfessionalService"],
  "@id": "https://zer0one.codes/#organization",
  "name": "ZER0ONE",
  "url": "https://zer0one.codes",
  "subOrganization": [
    { "@id": "https://zer0onelab.com/#organization" }
  ]
}

Auf zer0onelab.com läuft parallel:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://zer0onelab.com/#organization",
  "name": "ZER0ONE Lab",
  "url": "https://zer0onelab.com",
  "parentOrganization": { "@id": "https://zer0one.codes/#organization" }
}

Was passiert intern: Google's Crawler sieht auf zer0one.codes einen Master-Organization-Node mit einer Referenz auf zer0onelab.com/#organization. Auf zer0onelab.com sieht er einen Sub-Organization-Node mit einer Referenz zurück auf zer0one.codes/#organization. Beide Referenzen stimmen überein, keine Widersprüche → beide Nodes werden zu einer einzigen Entity im Knowledge Graph konsolidiert, mit einer Master-Sub-Beziehung.

Der Nebeneffekt auf Author-Entity

Denselben Trick machen wir für die Founder-Person. Michael Jajagin ist auf beiden Domains erwähnt (als Author auf BlogPosting, als Founder auf Organization). Ohne @id sieht Google zwei „Michael Jajagin"-Personen, mit potenziell unterschiedlichen Signalen.

Mit @id:

{
  "@type": "Person",
  "@id": "https://zer0one.codes/#founder",
  "name": "Michael Jajagin",
  "worksFor": { "@id": "https://zer0one.codes/#organization" },
  "sameAs": [
    "https://github.com/0xxCool",
    "https://www.linkedin.com/in/zer0one"
  ]
}

Auf jedem BlogPosting-Node steht dann als Author nur die Referenz:

"author": { "@id": "https://zer0one.codes/#founder" }

Das heißt: alle Autorschaften über alle Blog-Posts über beide Domains werden als „von derselben Person" erkannt. Der E-E-A-T-Trust-Score konsolidiert sich auf einer einzigen Person statt sich zu splitten.

Was das für LocalBusiness-Signal heißt

Wir haben zusätzlich das Organization-Type-Array erweitert zu ["Organization", "LocalBusiness", "ProfessionalService"]. Das entsperrt Local-Pack-Rankings — wenn jemand in Bogojevo, RS nach „Engineering-Beratung" sucht, kann uns Google im Map-Result mit unseren geo-Koordinaten anzeigen.

Für ein DACH-fokussiertes Consulting-Studio ist das ehrlich unwichtig — kein CTO in München sucht auf Google Maps nach einem Bogojevo-Studio. Wichtig ist die Kaskadierung: LocalBusiness signalisiert Google „das ist eine echte Firma mit physischer Adresse, nicht ein Shell-Konstrukt zur SEO-Optimierung." Das ist ein Trust-Signal höher Ordnung.

Der Bug den wir dabei fanden

Als wir das erste Mal deployten, zeigte die Lab-Domain die falsche WebSite-@id — nämlich die Studio-URL. Root Cause: render/page.tsx war mit force-static konfiguriert. Bei Static Generation wird die Page beim Build ohne HTTP-Kontext gerendert, headers().get("host") gibt null zurück, unser isLabHost()-Check landete deshalb immer im Studio-Zweig.

Der Fix war strukturell: die host-spezifischen JSON-LD-Nodes (WebSite pro Domain, LabOrg-Definition) wanderten aus dem Root-Layout in die jeweiligen Landing-Pages. Der Layout emittiert jetzt nur noch die shared Entities (Organization + Person), die auf beiden Hosts identisch sind. Domain-spezifisches JSON-LD lebt in der Domain-spezifischen Page.

Test-Method: curl https://zer0one.codes/de | grep '"@id":"[^"]*"' | sort -u — wir haben ein Puppeteer-Audit-Skript das über 12 URLs (2 Domains × 6 Locales) läuft und Cross-Reference-Konsistenz prüft.

Wann sich das lohnt

Diese ganze Trust-Chain-Architektur ist Overhead, wenn du nur eine einzelne Domain hast. Der Aufwand lohnt sich wenn du:

Eine Firma auf zwei oder mehr Domains betreibst (Consulting + Product, oder Multi-Brand)
Author-Bylines auf mehreren Domains hast
In einem Nischen-Bereich rankst wo Entity-Confidence kritisch ist (Fach-Consulting, Nischen-SaaS)

Wenn du Single-Domain-Blog bist mit einem Author: nicht nötig. Standard-JSON-LD ohne stabile @ids reicht.

Meta-Lektion

Google's Knowledge Graph ist kein Ranking-System — es ist ein Entity-Resolutions-System, das auf Rankings wirkt. Wenn du eine Firma auf mehreren Domains hast und nicht explizit sagst „das ist dieselbe Firma", dann macht Google die Entscheidung heuristisch. Heuristiken funktionieren manchmal, oft nicht. Explizite @id-Cross-Referenzen sind ein Weg, deiner eigenen Entity-Confidence auf ein solides Fundament zu stellen.

Für Studios die selbst Multi-Domain-Setups haben und diesen Trust-Chain nachbauen wollen: der komplette JSON-LD-Setup ist Teil der ZER0ONE Studio Engineering Services. Wir haben es gerade selbst durchgemacht, wir wissen was schief geht.

Wie zwei Domains eine Google-Entity werden: JSON-LD @id-Cross-Referenzen erklärt