Come due domini diventano una sola entity Google: le cross-reference JSON-LD @id spiegate

Abbiamo una sola azienda ZER0ONE e due domini. Il consulting Studio gira su zer0one.codes, il prodotto Cloud Render su zer0onelab.com. Legalmente sono la stessa azienda. Per Google sono state a lungo due entity separate.

Il problema non è il duplicate content — i due siti hanno contenuti completamente separati. Il problema è l’entity resolution: Google vede su zer0one.codes una `Organization` chiamata „ZER0ONE“ e su zer0onelab.com una `Organization` chiamata „ZER0ONE Lab“. Due nomi simili, nessun segnale esplicito di collegamento. L’euristica di default di Google è: „probabilmente due aziende simili, nessuna relazione.“

Questo porta a ranking splittati: quando qualcuno cerca „ZER0ONE“ vede entrambi i siti, ma il trust score si distribuisce su due piccole entity invece di consolidarsi su una grande azienda.

La soluzione tecnica

Lo `@id` di Schema.org è un URI stabile che funge da entity identifier. Due nodi con lo stesso `@id` sono per i motori di ricerca la stessa entity — indipendentemente dal dominio su cui si trovano.

Abbiamo ristrutturato il nostro JSON-LD in questo modo:

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

Su zer0onelab.com gira in parallelo:

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

Cosa succede internamente: il crawler di Google vede su zer0one.codes un nodo Master-Organization con una reference a `zer0onelab.com/#organization`. Su zer0onelab.com vede un nodo Sub-Organization con una reference di ritorno a `zer0one.codes/#organization`. Entrambe le reference combaciano, nessuna contraddizione → entrambi i nodi vengono consolidati in una singola entity nel Knowledge Graph, con una relazione master-sub.

L’effetto collaterale sull’Author-Entity

Lo stesso trucco lo applichiamo alla Person del founder. Michael Jajagin è menzionato su entrambi i domini (come Author su BlogPosting, come Founder su Organization). Senza `@id` Google vede due persone „Michael Jajagin“, con segnali potenzialmente diversi.

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

Su ogni nodo BlogPosting come Author c’è solo la reference:

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

Significa: tutte le authorship su tutti i blog post attraverso entrambi i domini vengono riconosciute come „della stessa persona“. Il trust score E-E-A-T si consolida su una singola persona invece di splittarsi.

Cosa significa per il segnale LocalBusiness

Abbiamo inoltre esteso l’array del tipo Organization a `["Organization", "LocalBusiness", "ProfessionalService"]`. Questo sblocca i ranking del Local Pack — se qualcuno a Bogojevo, RS cerca „Engineering-Beratung“, Google può mostrarci nel Map-Result con le nostre coordinate geografiche.

Per uno studio di consulting focalizzato DACH questo è onestamente irrilevante — nessun CTO di Monaco cerca su Google Maps uno studio a Bogojevo. Ciò che conta è la cascata: LocalBusiness segnala a Google „è un’azienda vera con indirizzo fisico, non un costrutto shell per SEO-optimization.“ È un segnale di trust di ordine superiore.

Il bug che abbiamo trovato lungo la strada

Al primo deploy, il dominio Lab mostrava lo `@id` WebSite sbagliato — cioè l’URL Studio. Root cause: `render/page.tsx` era configurato con `force-static`. Con Static Generation la pagina viene renderizzata al build senza contesto HTTP, `headers().get("host")` ritorna `null`, il nostro check `isLabHost()` finiva quindi sempre nel branch Studio.

Il fix è stato strutturale: i nodi JSON-LD host-specifici (WebSite per dominio, LabOrg definition) sono migrati fuori dal root layout e nelle rispettive landing page. Il layout emette ora solo le shared entities (Organization + Person), identiche su entrambi gli host. Il JSON-LD dominio-specifico vive nella pagina dominio-specifica.

Test method: `curl https://zer0one.codes/de | grep '"@id":"[^"]*"' | sort -u` — abbiamo uno script Puppeteer di audit che gira su 12 URL (2 domini × 6 locale) e verifica la coerenza delle cross-reference.

Quando ne vale la pena

Tutta questa architettura di trust chain è overhead se hai un solo dominio. Il lavoro ha senso quando:

• Gestisci un’unica azienda su due o più domini (consulting + prodotto, oppure multi-brand)
• Hai byline di autore su più domini
• Rank in un ambito di nicchia in cui l’entity confidence è critica (consulting specialistico, SaaS di nicchia)

Se sei un blog single-domain con un solo autore: non serve. Basta il JSON-LD standard senza @id stabili.

Meta-lezione

Il Knowledge Graph di Google non è un ranking system — è un entity-resolution system che agisce sui ranking. Se hai un’azienda su più domini e non dici esplicitamente „è la stessa azienda“, allora Google prende la decisione euristicamente. Le euristiche funzionano a volte sì, spesso no. Le cross-reference @id esplicite sono un modo di poggiare l’entity confidence su un fondamento solido.

Per gli studi che hanno anch’essi setup multi-domain e vogliono ricostruire questa trust chain: il setup JSON-LD completo fa parte degli ZER0ONE Studio Engineering Services. Ci siamo appena passati, sappiamo dove si rompono le cose.