Imamo jednu ZER0ONE tvrtku i dvije domene. Studio consulting radi na zer0one.codes, cloud render proizvod na zer0onelab.com. Obje su pravno ista tvrtka. Za Google su dugo bile dva odvojena entiteta.

Problem nije duplicate content — siteovi imaju potpuno odvojen sadržaj. Problem je entity resolution: Google na zer0one.codes vidi `Organization` s imenom „ZER0ONE" i na zer0onelab.com `Organization` s imenom „ZER0ONE Lab". Dva slična imena, nikakvi eksplicitni signali povezanosti. Googleova default heuristika je: „vjerojatno dvije slične tvrtke, bez odnosa."

To vodi do split-rankinga: kad netko traži „ZER0ONE", vidi oba sitea, ali trust score dijeli se na dva mala entiteta umjesto da se konsolidira na jednu veliku tvrtku.

Tehničko rješenje

Schema.org `@id` je stabilan URI koji funkcionira kao entity identifier. Dva nodea s istim `@id` su za tražilice isti entitet — bez obzira na kojoj domeni stoje.

Prestrukturirali smo naš JSON-LD ovako:

```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" } ] } ```

Paralelno, na zer0onelab.com radi:

```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" } } ```

Što se događa iznutra: Googleov crawler na zer0one.codes vidi master-Organization node s referencom na `zer0onelab.com/#organization`. Na zer0onelab.com vidi sub-Organization node s referencom natrag na `zer0one.codes/#organization`. Obje reference se slažu, nema kontradikcija → oba nodea se konsolidiraju u jedan jedinstveni entitet u Knowledge Graphu, s master-sub odnosom.

Nuspojava na Author-Entity

Isti trik primjenjujemo za founder Person. Michael Jajagin spomenut je na obje domene (kao Author na BlogPostingu, kao Founder na Organization). Bez `@id`-a Google vidi dvije „Michael Jajagin" osobe, s potencijalno različitim signalima.

S `@id`-om:

```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 svakom BlogPosting nodeu tada kao Author stoji samo referenca:

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

To znači: sva autorstva kroz sve blog postove kroz obje domene prepoznaju se kao „od iste osobe". E-E-A-T trust score konsolidira se na jednu osobu umjesto da se dijeli.

Što to znači za LocalBusiness-signal

Dodatno smo Organization-Type-Array proširili na `["Organization", "LocalBusiness", "ProfessionalService"]`. To otključava Local-Pack rankinge — kad netko u Bogojevu, RS traži „engineering-savjetovanje", Google nas može prikazati u Map-rezultatu s našim geo-koordinatama.

Za DACH-fokusirani consulting studio to je iskreno nevažno — nijedan CTO u Münchenu ne traži na Google Mapsu studio iz Bogojeva. Važna je kaskadicija: LocalBusiness signalizira Googleu „ovo je stvarna tvrtka s fizičkom adresom, ne shell konstrukt za SEO optimizaciju." To je trust-signal višega reda.

Bug koji smo pritom pronašli

Kad smo prvi put deployali, Lab domena je emitirala krivi WebSite-`@id` — naime Studio URL. Root cause: `render/page.tsx` bio je konfiguriran s `force-static`. Kod Static Generation stranica se pri buildu renderira bez HTTP konteksta, `headers().get("host")` vraća `null`, naš `isLabHost()` check zato je uvijek završavao u Studio grani.

Fix je bio strukturan: host-specifični JSON-LD nodeovi (WebSite po domeni, LabOrg definicija) preselili su se iz root layouta u pripadajuće landing pages. Layout sada emitira samo shared entitete (Organization + Person), koji su identični na oba hosta. Domain-specifični JSON-LD živi na domain-specifičnom pageu.

Test-metoda: `curl https://zer0one.codes/de | grep '"@id":"[^"]*"' | sort -u` — imamo Puppeteer-audit skriptu koja prolazi kroz 12 URL-ova (2 domene × 6 locales) i provjerava konzistentnost cross-referenca.

Kada se to isplati

Cijela ova trust-chain arhitektura je overhead ako imaš samo jednu domenu. Trud se isplati ako:

Vodiš jednu tvrtku na dvije ili više domena (consulting + proizvod, ili multi-brand)
Imaš author-bylines na više domena
Rankiraš u nišnom području u kojem je entity confidence kritičan (stručno savjetovanje, nišni SaaS)

Ako si single-domain blog s jednim autorom: nije potrebno. Standardni JSON-LD bez stabilnih @id-ova je dovoljan.

Meta-lekcija

Googleov Knowledge Graph nije ranking sistem — to je sistem za entity resolution koji utječe na rankinge. Ako imaš jednu tvrtku na više domena i eksplicitno ne kažeš „ovo je ista tvrtka", Google odluku donosi heuristički. Heuristike ponekad rade, često ne. Eksplicitne @id cross-reference način su da vlastiti entity confidence postaviš na čvrst temelj.

Za studije koji sami imaju multi-domain setupove i žele izgraditi ovaj trust-chain: kompletan JSON-LD setup dio je ZER0ONE Studio Engineering Services. Upravo smo sami to prošli, znamo gdje stvari idu krivo.

Kako dvije domene postaju jedan Google entitet: JSON-LD @id cross-reference objašnjen