Kako dve domeni postaneta ena Google-Entity: JSON-LD @id cross-reference razložene
Imamo zer0one.codes (Studio) in zer0onelab.com (Cloud-Product). Za Google sta bila to dolgo časa dve ločeni podjetji — čeprav gre za isti d.o.o. Popravek je ena sama vrstica na JSON-LD-Node: stabilni @id-URI-ji plus parentOrganization/subOrganization-reference. Nato Googlov Knowledge Graph obe domeni razreši kot isto Entity.
Imamo eno ZER0ONE-podjetje in dve domeni. Studio-consulting teče na zer0one.codes, Cloud-Render-Product na zer0onelab.com. Obe sta pravno isto podjetje. Za Google sta dolgo bili dve ločeni entiteti.
Problem ni Duplicate Content — strani imata popolnoma ločeno vsebino. Problem je Entity-Resolution: Google na zer0one.codes vidi `Organization` z imenom „ZER0ONE“ in na zer0onelab.com `Organization` z imenom „ZER0ONE Lab“. Dve podobni imeni, brez eksplicitnih signalov povezave. Googlova privzeta heuristika je: „verjetno dve podobni podjetji, brez razmerja.“
To vodi v split-rankinge: ko nekdo išče „ZER0ONE“, vidi obe strani, a trust-score se porazdeli na dve mali entiteti, namesto da bi se konsolidiral na eno veliko podjetje.
Tehnična rešitev
Schema.orgov `@id` je stabilen URI, ki deluje kot entity-identifier. Dva Node-a z istim `@id` sta za iskalnike ista Entity — ne glede na to, na kateri domeni stojita.
Našo JSON-LD strukturo smo predelali tako:
```json { "@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" } ] } ```
Na zer0onelab.com paralelno teče:
```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://zer0onelab.com/#organization", "name": "ZER0ONE Lab", "url": "https://zer0onelab.com", "parentOrganization": { "@id": "https://zer0one.codes/#organization" } } ```
Kaj se dogaja interno: Googlov crawler na zer0one.codes vidi Master-Organization-Node z referenco na `zer0onelab.com/#organization`. Na zer0onelab.com vidi Sub-Organization-Node z referenco nazaj na `zer0one.codes/#organization`. Obe referenci se ujemata, brez nasprotij → oba Node-a se konsolidirata v eno samo Entity v Knowledge Graphu, z Master-Sub-razmerjem.
Stranski učinek na Author-Entity
Isti trik uporabimo za founder-Person. Michael Jajagin je omenjen na obeh domenah (kot Author v BlogPosting, kot Founder v Organization). Brez `@id` Google vidi dve „Michael Jajagin“-osebi s potencialno različnimi signali.
Z `@id`:
```json { "@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" ] } ```
Na vsakem BlogPosting-Node-u je nato kot Author zgolj referenca:
```json "author": { "@id": "https://zer0one.codes/#founder" } ```
To pomeni: vsa avtorstva vseh blog-postov na obeh domenah so prepoznana kot „od iste osebe“. E-E-A-T-trust-score se konsolidira na eno samo osebo, namesto da se razcepi.
Kaj to pomeni za LocalBusiness-signal
Dodatno smo Organization-Type-Array razširili v `["Organization", "LocalBusiness", "ProfessionalService"]`. To odklene Local-Pack-rankinge — ko nekdo v Bogojevu, RS išče „engineering-svetovanje“, nas Google lahko v Map-rezultatu prikaže z našimi geo-koordinatami.
Za DACH-usmerjen consulting-Studio to iskreno ni pomembno — noben CTO v Münchnu ne išče na Google Maps studia iz Bogojeva. Pomembno je kaskadiranje: LocalBusiness Googlu signalizira „to je pravo podjetje s fizičnim naslovom, ne shell-konstrukt za SEO-optimizacijo.“ Trust-signal višjega reda.
Bug, ki smo ga pri tem našli
Ko smo prvič deployjali, je Lab-domena kazala napačen WebSite-@id — namreč Studio-URL. Root Cause: `render/page.tsx` je bil konfiguriran s `force-static`. Pri Static Generation se page pri buildu renderira brez HTTP-konteksta, `headers().get("host")` vrne `null`, naš `isLabHost()`-check je zato vedno pristal v Studio-veji.
Popravek je bil strukturen: host-specifični JSON-LD-Node-i (WebSite per domena, LabOrg-definicija) so se preselili iz Root-Layouta v posamezne landing pages. Layout zdaj emitira samo shared Entities (Organization + Person), ki so na obeh hostih identične. Domain-specific JSON-LD živi v Domain-specific page.
Test-metoda: `curl https://zer0one.codes/de | grep '"@id":"[^"]*"' | sort -u` — imamo Puppeteer-audit-script, ki teče preko 12 URL-jev (2 domeni × 6 lokalizacij) in preverja konsistentnost cross-referenc.
Kdaj se to splača
Celotna arhitektura trust-chaina je overhead, če imate le eno domeno. Trud se izplača, če:
- Vodite eno podjetje na dveh ali več domenah (Consulting + Product, ali Multi-Brand)
- Imate Author-Byline-e na več domenah
- Ranking-ate v niši, kjer je Entity-Confidence kritičen (specializirani consulting, nišni SaaS)
Če ste Single-Domain-Blog z enim Author-jem: ni potrebno. Standardni JSON-LD brez stabilnih @id-jev zadošča.
Meta-lekcija
Googlov Knowledge Graph ni ranking-sistem — je entity-resolution-sistem, ki na rankinge vpliva. Če vodite podjetje na več domenah in eksplicitno ne poveste „to je isto podjetje“, potem Google odloči heuristično. Heuristike včasih delujejo, pogosto ne. Eksplicitne @id-cross-reference so način, kako lastno Entity-Confidence postavite na trdne temelje.
Za studie, ki imajo lastne Multi-Domain-Setup-e in bi ta trust-chain radi replicirali: celoten JSON-LD-setup je del ZER0ONE Studio Engineering Services. Ravnokar smo šli sami skozi to, vemo, kje gre narobe.