Iniezione di Schema all’Edge

1) Configura una regola di routing sul CDN per attivare un worker sugli URL /*product*. 2) All’interno del worker, recupera l’HTML di origine usando `cacheTtlByStatus` in modo che l’HTML possa comunque essere memorizzato in cache a valle. 3) Analizza l’HTML con uno streaming HTMLRewriter o un’API simile per evitare il costo di un parsing DOM completo. 4) Estrai SKU, prezzo, disponibilità e brand dall’HTML (utilizzando query di selettori o regex di fallback). 5) Crea un oggetto JSON-LD conforme a Schema.org/Product e alle linee guida di Google su prezzo e disponibilità. 6) Inietta il blocco `<script type="application/ld+json">` subito prima di `</head>` usando lo stesso stream per mantenere basso il TTFB. 7) Imposta gli header `cache-control` appropriati affinché la risposta modificata venga memorizzata in cache all’edge, non solo all’origine. 8) Registra un hash dello schema iniettato in un KV store o in un servizio di logging per il debug. 9) Esegui un test live con `curl -H "User-Agent: Googlebot"` per confermare che lo schema compaia nelle risposte in cache. Risultato: le pagine prodotto ora restituiscono uno schema valido senza modificare i template di origine e con solo pochi microsecondi di latenza aggiuntiva.

L’Edge Schema Injection inserisce i dati strutturati nell’HTML grezzo prima che questo raggiunga il browser, così Googlebot (che analizza principalmente l’HTML iniziale) vede lo schema senza dover eseguire un secondo passaggio di rendering. Ciò evita i ritardi nella coda di rendering JavaScript e conserva il crawl/render budget. Centralizza inoltre la manutenzione nell’edge worker, eliminando la necessità di ridistribuire l’intero sito per modificare lo schema. L’iniezione lato client, invece, si affida al rendering differito di Google; lo schema resta invisibile fino alla fase di rendering, aumentando la latenza di crawl e il rischio di indicizzazione parziale. Tuttavia, l’iniezione via JavaScript può risultare più semplice se già si controlla il codice front-end e non si dispone di scripting all’edge. Scegli l’iniezione edge quando: (a) i template di origine non sono modificabili, (b) occorre visibilità immediata per il crawler, oppure (c) si desidera testare A/B lo schema a livello di CDN. Opta per l’iniezione lato client quando disponi di un’infrastruttura SPA moderna e non hai controllo sullo scripting CDN o quando lo schema dipende da dati disponibili solo dopo l’hydration lato client.

Causa 1: cold start del worker. Mitigazione: mantieni il worker leggero, utilizza variabili globali per gli oggetti riutilizzati e abilita un keep-alive/ping per mantenere caldi gli edge. Causa 2: buffering completo dell’HTML in memoria. Mitigazione: passa a riscritture in streaming che modificano i chunk al volo invece di assemblare l’intero documento. Causa 3: il fetch all’origine non fa più cache-hit perché hai bypassato il caching con `cache-control: private`. Mitigazione: imposta correttamente gli header `cacheTtl` e rispetta le surrogate key affinché il worker possa servire l’HTML dalla cache e iniettare lo schema solo sui cache hit.

Per prima cosa recupera l’HTML renderizzato con `curl -A 'Googlebot'` per verificare che siano presenti due oggetti Organization: uno derivante dai microdati del CMS e uno iniettato dall’edge. Successivamente confronta i loro ID (`"@id"`) e i rispettivi set di proprietà. Poiché Google unisce i nodi del grafo che condividono lo stesso valore `@id`, la duplicazione si verifica quando l’edge inietta un secondo Organization senza fare riferimento al primo. Correzione: nel worker rileva se i microdati includono un valore `url` o `@id`; usa quel valore come `@id` nel JSON-LD iniettato e aggiungi solo le proprietà mancanti. In alternativa, sopprimi l’iniezione di Organization nelle pagine che lo espongono già, individuando un selettore microdata `itemtype="http://schema.org/Organization"` prima della scrittura. Esegui nuovamente il Rich Results Test; l’errore di duplicazione dovrebbe essere risolto perché Google vede ora un unico nodo unificato.