SEO per un CMS headless

TL;DR — Un CMS headless separa dove scrivi i contenuti da dove vengono mostrati. Questa separazione va bene per la SEO, ma solo se la parte del sito web consegna ai motori di ricerca HTML completamente costruito. La regola principale: renderizza le tue pagine su un server o al momento della build (SSR o SSG), non interamente nel browser del visitatore (CSR). E tutte le cose SEO che un plugin WordPress faceva per te — titoli, sitemap, robots.txt — ora devi configurarle da solo.

Cosa significa realmente “headless”

In una configurazione tradizionale come WordPress, il luogo in cui scrivi i contenuti e il luogo che li trasforma in una pagina web sono lo stesso sistema. Un CMS headless separa questi due compiti. Il CMS diventa solo un archivio di contenuti (Contentful, Sanity, Strapi e altri), e un sito web separato — costruito con un framework come Next.js, Nuxt, Astro o Gatsby — recupera quei contenuti e costruisce le pagine effettive. Evidence for this claim A headless CMS separates content management from the presentation frontend and exposes content through APIs. Scope: Contentful as a representative headless CMS architecture. Confidence: high · Verified: 2026-07-14 Contentful: What is a headless CMS?

Le persone temono che questo sia negativo per la SEO. Non lo è, di per sé. Il CMS che sta nel backend non ha quasi alcun effetto sul tuo posizionamento. Ciò che conta è come la parte frontend costruisce la pagina.

La decisione che conta: il rendering

Quando qualcuno (o Googlebot) richiede una pagina, dove viene prodotto l’HTML finale? Ci sono fondamentalmente due risposte sicure e una rischiosa:

• Al momento della build (SSG) — le pagine vengono costruite in anticipo in file HTML statici. Veloce e favorevole alla ricerca.
• Su un server, per richiesta (SSR) — il server costruisce la pagina completa e la invia. Anche favorevole alla ricerca e sempre aggiornata.
• Nel browser del visitatore (CSR) — il server invia una shell quasi vuota, e JavaScript la riempie successivamente. Questa è quella rischiosa per la SEO.

Google può eseguire JavaScript, ma il rendering è una fase di elaborazione separata e JavaScript può ancora fallire o essere bloccato. Altri crawler hanno capacità di rendering diverse, quindi l’HTML renderizzato lato server o pre-renderizzato è il modo più portabile per consegnare contenuti critici. Evidence for this claim Google processes JavaScript through a rendering stage, and blocked or failed resources can prevent expected content from rendering. Scope: Google Search; other crawlers have their own capabilities. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Il problema “dove sono finite le mie impostazioni SEO?”

In WordPress, un plugin come Yoast gestiva silenziosamente titoli, meta description, sitemap e tag canonici. Un sito headless non ha un livello di plugin. Ciò significa che uno sviluppatore deve deliberatamente:

• Aggiungere campi SEO (titolo, descrizione, ecc.) al modello di contenuto nel CMS.
• Collegare quei campi all’HTML della pagina.
• Creare una sitemap e un robots.txt.

Niente di tutto questo è difficile — semplicemente non accadrà da solo. Molte storie di “il mio sito headless ha perso la SEO” sono in realtà “nessuno ha ricostruito le cose che faceva il plugin”.

Un paio di cose che si rompono silenziosamente

• Siti di anteprima/staging indicizzati. Le configurazioni headless spesso creano URL di anteprima pubblici. Se Google li trova, può indicizzare un’intera copia duplicata del tuo sito. Questi devono essere bloccati dall’indicizzazione.
• Link che non sono veri link. I motori di ricerca seguono solo veri link <a href>. Un <div> cliccabile che naviga con JavaScript non verrà indicizzato.

Vuoi la versione completa — i quattro modi di rendering confrontati, tag canonici, sitemap, la trappola del contenuto obsoleto ISR, Bing e migrazioni? Passa alla scheda Avanzate.

TL;DR — Nella SEO headless, l’architettura è il prodotto: il backend CMS è quasi neutrale per la SEO, e la modalità di rendering del frontend decide tutto. SSG e SSR consegnano HTML completamente renderizzato e sono le scelte sicure; CSR è la più rischiosa; ISR comporta una trappola di contenuto obsoleto alla prima richiesta dopo la rivalidazione. Tutto ciò che Yoast faceva automaticamente — metadati, canonici, sitemap, robots.txt — ora lo costruisci esplicitamente, e la logica canonica si frammenta tra CMS → framework → componente, quindi impostala a livello di rendering da un unico SITE_URL. La stessa separazione si applica al routing locale/hreflang e all’accesso all’anteprima (autentica prima; noindex è secondario, non controllo degli accessi). Google ha deprecato il rendering dinamico (usa SSR/SSG/hydration), il rendering dei crawler AI varia a seconda del fornitore, e gli eventi di pubblicazione/annullamento della pubblicazione richiedono una pulizia della cache attivata da webhook, non un timer.

L’architettura è il prodotto

Un CMS headless è solo un backend: archiviazione dei contenuti, un modello di contenuti, un’interfaccia di modifica e un’API. Il frontend — Next.js, Nuxt, Gatsby, Astro, SvelteKit, Remix — è un ‘applicazione separata che recupera i contenuti tramite REST o GraphQL e li renderizza. Il modello mentale più utile qui è che il CMS che scegli ha quasi nessun impatto SEO diretto; le decisioni di rendering nel frontend determinano tutto. Ogni conversazione SEO headless dovrebbe iniziare con una domanda: come sta renderizzando questo contenuto il frontend? Evidence for this claim A headless CMS supplies content through APIs while a separate frontend controls how pages are rendered. Scope: Contentful as a representative headless CMS architecture. Confidence: high · Verified: 2026-07-14 Contentful: What is a headless CMS?

Ecco perché “headless è negativo per la SEO” è la cornice sbagliata. Headless è neutro. Un sito headless ben costruito su SSR o SSG, con metadati disciplinati, supererà un’installazione WordPress trascurata. Un sito headless che per impostazione predefinita usa il rendering lato client e non ha mai ricostruito il suo livello di metadati crollerà silenziosamente. Questo è lo stesso punto che faccio nella mia guida SEO JavaScript: il web si è spostato dall’HTML semplice, e come SEO puoi abbracciarlo piuttosto che combatterlo.

Chi possiede cosa: CMS, API e frontend

“Il CMS è quasi SEO-neutro” è l’istinto giusto, ma non è una licenza per saltare una vera mappa di proprietà. Un modello di contenuti memorizza tipi e campi strutturati — questo è tutto. Non dimostra che titoli, canonici, schema o link vengano effettivamente emessi; questo accade solo quando il frontend fa il suo lavoro. Evidence for this claim A headless CMS content model defines structured types and fields, but the consuming frontend owns URL routing and the rendered HTML that titles, canonicals, schema, and links depend on. Scope: Contentful content-model docs plus Next.js metadata docs as representative frontend evidence. Confidence: high · Verified: 2026-07-18 Contentful: Data model Next.js: Metadata and OG images Dividere esplicitamente la responsabilità evita le due modalità di errore che vedo più spesso: nessuno possiede un pezzo (non viene mai costruito silenziosamente), o tre livelli pensano tutti di possederlo (si frammenta, come fanno i canonici sotto).

Anche distinto: quale API chiami. Le API di consegna, gestione e anteprima hanno semantiche di pubblicazione e autorizzazione diverse. Il rendering di produzione deve usare solo l’API dei contenuti pubblicati — mai un token/endpoint di gestione o anteprima, che può far trapelare contenuti non pubblicati o accesso in scrittura in una risposta pubblica. Evidence for this claim Delivery, management, and preview APIs have different publication and authorization semantics; production rendering must use the published-content API and must not expose management or preview tokens. Scope: Contentful API basics and Preview API docs as representative headless-API evidence. Confidence: high · Verified: 2026-07-18 Contentful: API basics Contentful: Content Preview API overview

Come Google elabora una pagina JavaScript

Google elabora le pagine JavaScript attraverso crawling, rendering e indicizzazione. Le pagine che dipendono dal rendering lato client non espongono il loro contenuto finale nella risposta HTML iniziale, mentre SSR e SSG mettono quel contenuto nella risposta prima dell’esecuzione del browser. Evidence for this claim Google crawls, renders, and indexes JavaScript pages, while server-side or pre-rendered HTML exposes content in the initial response. Scope: Google Search JavaScript processing; indexing is not guaranteed. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Due fatti correlati contano su larga scala. Google non può renderizzare JavaScript da file bloccati, quindi le risorse .js e .css richieste devono rimanere crawlabili. Il rendering JS è genuinamente costoso — ad Ahrefs eseguiamo il crawling di miliardi di pagine al giorno e il rendering di pagine JavaScript consuma una parte seria della nostra infrastruttura — il che è un buon promemoria che “Googlebot può renderizzarlo” non è la stessa cosa di “dovresti far renderizzare a Googlebot.”

La realtà dei crawler AI

Questa è la novità del 2026 che la maggior parte dei consigli SEO headless ancora ignora. La maggior parte dei crawler AI — i fetcher dietro ChatGPT, Perplexity e simili — non eseguono JavaScript. Uno studio di Vercel lo ha detto chiaramente: nessuno di essi renderizza il contenuto lato client, quindi se le tue pagine critiche sono SPA dipendenti da JavaScript, quelle pagine sono di fatto invisibili alla ricerca AI. Il team di rendering di Google ha dichiarato che renderizza praticamente tutte le pagine HTML, ma quello è Google. Per la visibilità AI, SSR/SSG non è un optional; è il prezzo d’ingresso.

Le quattro modalità di rendering

SSG — Static Site Generation. L’HTML viene generato in fase di build e servito come file statici da una CDN. SEO nel migliore dei casi: HTML completamente renderizzato alla prima richiesta, TTFB molto veloce. Il compromesso è la freschezza: i contenuti nuovi o modificati richiedono una rebuild, e i siti grandi hanno build lente (ISR risolve parzialmente questo problema). Gatsby e Astro sono SSG-first; Next.js lo supporta per rotta; Hugo è un classico.

SSR — Server-Side Rendering. L’HTML viene renderizzato per richiesta su un server o una funzione edge. SEO eccellente: HTML sempre fresco e completamente renderizzato alla prima richiesta. Il compromesso è il costo dell’infrastruttura e un TTFB leggermente più alto rispetto ai file statici. Next.js, Nuxt, SvelteKit e Remix fanno tutto questo.

ISR — Incremental Static Regeneration. Le pagine statiche si rigenerano in background dopo un intervallo di rivalidazione. Buona SEO la maggior parte delle volte, con una vera trappola (prossima sezione). Principalmente una funzionalità di Next.js; Nuxt ha analoghi.

CSR — Client-Side Rendering. Viene servito un guscio HTML minimale, poi JavaScript nel browser recupera i contenuti e costruisce il DOM. Questa è l’opzione SEO peggiore: Googlebot deve mettere in coda la pagina per l’onda di rendering, i tempi sono imprevedibili, e i crawler AI e molti altri bot vedono solo il guscio vuoto. CSR è accettabile per dashboard altamente interattive o pagine solo autenticate che sono dietro un login e non dovrebbero comunque essere indicizzate — non per contenuti che vuoi far trovare. Le SPA React o Vue pure senza Next.js/Nuxt finiscono qui per impostazione predefinita.

La trappola del contenuto stantio ISR

Questa è abbastanza nuova da meritare una sezione dedicata. Con ISR, quando la finestra di rivalidazione scade:

1. La prossima richiesta in arrivo attiva la rigenerazione in background.
2. Quella richiesta — che potrebbe essere Googlebot — riceve ancora la pagina cache stantia.
3. La versione fresca viene servita solo alla richiesta successiva.

Per le pagine crawlate frequentemente, questo può significare che Googlebot vede regolarmente contenuti indietro di un ciclo di rivalidazione. Per dati davvero volatili (prezzi, livelli di stock), SSR è la scelta più sicura. ISR è un ottimo compromesso per contenuti che cambiano nell’ordine di ore o giorni, non secondi.

Il rendering dinamico è deprecato

Anni fa — anche negli interventi che ho tenuto intorno al 2019 — il rendering dinamico, cioè servire ai bot una versione pre-renderizzata tramite strumenti come Puppeteer o Rendertron, era una soluzione temporanea ragionevole. Google ha poi cambiato posizione. Ufficialmente, “dynamic rendering was a workaround and not a long-term solution,” (traduzione) «il rendering dinamico era una soluzione temporanea, non una soluzione a lungo termine» e “creates additional complexities and resource requirements.” (traduzione) «crea complessità aggiuntive e richiede più risorse». Google ora raccomanda invece rendering lato server, rendering statico o hydration. La sfumatura conta: il rendering dinamico non è automaticamente cloaking — Google non lo penalizza solo perché esiste e diventa cloaking soltanto se offre contenuti completamente diversi a utenti e crawler. “Non è cloaking” e “è ufficialmente deprecato” possono quindi essere entrambi veri. Non usarlo in una nuova build.

Metadata — ricostruire ciò che faceva il plugin

In WordPress, Yoast o Rank Math generavano automaticamente un titolo e una descrizione per ogni pagina. Headless non ha un livello plugin, quindi il lavoro è esplicito:

1. Aggiungi i campi SEO al modello di contenuto del CMS — titolo, descrizione, override robots, override canonical, campi Open Graph.
2. Mappa quei campi nel <head> di ogni modello di pagina dalla risposta dell’API.
3. Usa la gestione head nativa del framework — generateMetadata di Next.js (App Router) o l’export metadata; useSeoMeta di Nuxt; il componente <Seo> di Gatsby / react-helmet; <head> di Astro nei file di layout.

Bug comuni: i metadati iniettati lato client vengono visti tardi (post-render) invece che immediatamente; un canonical di layout condiviso che non si aggiorna mai per pagina (quindi tutto canonicalizza alla homepage); e in Next.js App Router, un metadataBase mancante che produce URL canonical relativi rotti. La regola di affidabilità è semplice — i metadati a livello HTML battono i metadati iniettati via JS, perché Google li vede al primo fetch. Moduli come Helmet e Head vanno bene per questo, ma porta i tag critici nell’HTML renderizzato lato server.

Il modello di contenuto stesso ha bisogno di regole, non solo di campi, altrimenti il passaggio di mappatura sopra si rompe silenziosamente:

• Obbligatorio vs. opzionale per campo. Titolo e override canonical dovrebbero essere obbligatori (o derivati automaticamente) così una pagina non può mai essere pubblicata con un <title> vuoto. Descrizione e campi OG possono restare opzionali con un fallback frontend.
• Una catena di fallback definita. Se un campo SEO è vuoto, decidi in anticipo cosa il frontend sostituisce — un estratto del corpo per la descrizione, l’H1 per il titolo — e implementalo nel livello di mappatura, non ad hoc per ogni modello.
• Il fallback locale è una regola separata dal fallback dei campi. L’API dei contenuti può sostituire un valore della locale predefinita quando manca una traduzione; questo è utile per il corpo, ma un campo SEO che ricade silenziosamente sul titolo/descrizione di un’altra locale di solito è sbagliato e vale la pena segnalarlo separatamente.
• Escaping al passaggio di mappatura. I campi di testo del CMS spesso consentono HTML o rich text; rimuovi o esegui l’escape prima che finisca in una stringa <title>, <meta> o JSON-LD, altrimenti spedirai markup rotto o, peggio, script iniettato.
• Test di accettazione per tipo di route. Prima del lancio, conferma come appare il <head> renderizzato per una voce normale, una voce con un campo opzionale vuoto, e una voce interrogata in una locale per cui non ha traduzioni — tre percorsi di codice diversi che un singolo test del percorso felice non catturerà.

Frammentazione canonical — un rischio specifico headless

In WordPress il canonical vive in un unico posto. In headless è suddiviso su tre livelli: il CMS memorizza uno slug, il framework assembla l’URL completo da quello slug più la configurazione dell’ambiente, e un componente renderizza il tag <link rel="canonical">. Se un qualsiasi livello devia — uno slug cambia, un pattern di route cambia, un componente viene rifattorizzato — il canonical può puntare a un URL che non esiste più. Storicamente Google non rispettava nemmeno i canonical inseriti con JavaScript; questo si è allentato in alcuni casi, ma i canonical a livello HTML restano di gran lunga più affidabili, e più tag in conflitto costringono semplicemente Google a scegliere.

La soluzione: possiedi la logica canonical al livello di rendering (il framework), non dentro il CMS, e costruisci URL assoluti da una singola variabile d’ambiente SITE_URL. Un’unica fonte di verità, URL assoluti sempre, mai relativi.

Proprietà della locale: fallback API vs. routing frontend

I siti headless multi-locale hanno una versione della stessa confusione di proprietà dei canonical. La selezione della locale e il fallback dell’API dei contenuti possono sostituire valori di campo — richiedi una locale, ottieni il contenuto di quella locale o un fallback configurato — ma questa è una funzione di sostituzione dei dati, non una funzione SEO. Evidence for this claim Content API locale selection and fallback can substitute field values, but the frontend still owns locale URLs, canonicals, hreflang, x-default, and language negotiation. Scope: Contentful localization docs plus Google rendering/canonical guidance. Confidence: high · Verified: 2026-07-18 Contentful: Localization Google: JavaScript SEO basics Il frontend possiede ancora ogni aspetto rivolto alla ricerca:

• URL localizzate. Se la locale vive in un percorso (/es/page), in un sottodominio, o in un dominio separato è una decisione di routing che prende il frontend — l’API non genera URL.
• Canonical per locale. Ogni versione locale ha il proprio canonical che punta a sé stessa, non tutte che puntano alla locale predefinita.
• hreflang e x-default. Costruisci l’insieme completo di link per lingue alternative dalle rotte locali note del frontend, incluso un x-default per le lingue non corrispondenti — l’API non ha alcun concetto di hreflang.
• Negoziazione del contenuto e comportamento degli stati. Decidi deliberatamente cosa succede quando viene richiesta una locale che non esiste per una data voce: reindirizza alla locale predefinita, servi il contenuto di fallback all’URL di quella locale, o restituisci un vero 404 — e resta coerente su quale, poiché Google tratta “l’API ha sostituito silenziosamente il testo inglese” e “questa variante locale non esiste” come situazioni diverse che richiedono diversi codici di stato HTTP.

La trappola pratica: il fallback a livello di API può far sembrare una traduzione mancante ok nell’anteprima del CMS (vedi sempre contenuto, mai un campo vuoto), il che significa che i vuoti di locale tendono a emergere prima come problemi SEO — titoli nella lingua sbagliata indicizzati sotto l’hreflang sbagliato, o contenuti duplicati tra locale che non hanno mai attivato un avviso editoriale.

Sitemap e robots.txt

Niente Yoast significa niente sitemap automatica. Costruiscila programmaticamente: Next.js App Router genera /sitemap.xml da un file sitemap.ts (interrogando il CMS al momento della build o della richiesta); Nuxt ha moduli sitemap; Gatsby ha gatsby-plugin-sitemap; Astro ha @astrojs/sitemap. La trappola sui siti ad alto volume di pubblicazione sono le sitemap statiche a tempo di build che diventano obsolete — usa sitemap rigenerate con ISR segmentate per tipo di contenuto.

Anche robots.txt deve essere esplicito — un file statico in /public o una rotta generata (robots.ts in Next.js). L’unica regola che non puoi sbagliare: non disalloware mai .js o .css. Bloccarli impedisce del tutto il rendering.

Mantenerlo in sincrono con la pubblicazione

Cache e rivalidazione sono un problema di correttezza editoriale, non solo prestazionale — l’invalidazione per tempo, tag o percorso può servire contenuti obsoleti by design, quindi un’azione di pubblicazione deve raggiungere ogni livello che ha memorizzato una copia, non solo il CMS. Evidence for this claim Time-, tag-, and path-based cache invalidation can serve stale content by design, so publish, unpublish, rename, and locale changes need webhook-triggered purge and rollback handling, not a fixed timer. Scope: Next.js current cache/revalidation model. Confidence: high · Verified: 2026-07-18 Next.js: Revalidating Prima del lancio, scrivi cosa succede a ciascuno di questi su quattro eventi — pubblicazione, annullamento della pubblicazione, rinomina/cambio slug e aggiornamento della locale — e testalo:

• Cache API/CDN per quella voce.
• Cache di pagina del framework (rivalidazione ISR/on-demand, basata su tag o percorso).
• Cache edge CDN davanti al frontend.
• Sitemap — la voce aggiunta, rimossa o rielencata sotto un nuovo URL.
• Metadati — vecchio canonical/URL completamente ritirato, non lasciato risolvere insieme al nuovo.
• Rollback — se una pubblicazione viene annullata, conferma che la pulizia venga eseguita anche al contrario, non solo in avanti.

Il trigger dovrebbe essere un webhook dall’evento di pubblicazione/annullamento della pubblicazione del CMS che chiama la rivalidazione basata su tag o percorso del tuo framework (revalidateTag, revalidatePath, o l’equivalente), non un timer fisso — un timer significa che ognuno di quei quattro eventi aspetta il ciclo successivo invece di aggiornarsi immediatamente.

Link interni e dati strutturati

I link interni devono essere veri tag <a href>. Un <div onClick> o <span> che naviga tramite JavaScript non è indicizzabile — Googlebot segue solo gli anchor reali. E i link renderizzati via JS non vengono scoperti fino all’onda di rendering, il che aggiunge ritardo. Il contenuto guidato dall’API non produce strutture di link da solo, quindi le superfici di link per post correlati, breadcrumb e contenuto devono essere tutte cablate a livello di componente.

I dati strutturati sono il raro ambito in cui headless è più facile di WordPress: JSON-LD va direttamente in un <head> renderizzato lato server con zero costi sul bundle client, è versionato nel codice e non ci sono conflitti di plugin. I tipi usuali per i siti di contenuti — Article/BlogPosting, BreadcrumbList, FAQPage, Organization — valgono tutti. Testa con il Rich Results Test dopo qualsiasi modifica al rendering, poiché i tempi di iniezione JS possono influenzare ciò che il test vede.

Ambienti di anteprima e staging

Gli stack headless generano URL di anteprima e di deploy per branch (deploy di anteprima Vercel/Netlify, endpoint di bozze CMS) che sono spesso raggiungibili pubblicamente. Se Google li indicizza, vede un duplicato completo del tuo sito su un altro host. Le soluzioni: applica un’intestazione HTTP noindex a livello di host (nella configurazione dell’ambiente — non solo un meta tag che una pagina CSR potrebbe iniettare in ritardo), proteggi le anteprime con token firmati, imposta canonicali sensibili all’ambiente così che lo staging non si auto-canonicalizzi mai, e usa host di anteprima a breve durata. Controlla Search Console per domini inaspettati che compaiono — questo è il tuo campanello d’allarme.

Metti nell’ordine giusto le difese, perché è facile ricorrere a noindex per primi e fermarsi lì. noindex funziona solo se a Google è consentito eseguire la scansione della pagina e vedere il tag — è una richiesta sull’indicizzazione, non un controllo di accesso, quindi non serve a nulla contro un crawler determinato o un link trapelato se la pagina stessa è raggiungibile pubblicamente. Evidence for this claim A noindex rule is not access control and requires Google to crawl the page to see it; private headless previews should be authenticated first, with noindex as a secondary indexing safeguard. Scope: Google noindex documentation plus Contentful/Sanity preview-token separation as representative platform evidence. Confidence: high · Verified: 2026-07-18 Google: Block Search indexing with noindex Sanity: Presenting and previewing content Il vero confine deve stare più a monte:

1. Prima l’autenticazione. Gli ambienti di anteprima dovrebbero richiedere un token firmato o un login prima di servire qualsiasi cosa — noindex è una salvaguardia secondaria per la rara pagina che deve restare raggiungibile, non il controllo primario.
2. Token e host separati per ambiente. Anteprima e produzione non dovrebbero mai condividere un token API o un hostname; il token dell’anteprima è quello che può vedere contenuti non pubblicati, e non dovrebbe mai finire in una build di produzione.
3. Interroga la prospettiva di contenuto giusta. Il codice di produzione interroga solo contenuti pubblicati; solo l’ambiente di anteprima interroga la prospettiva bozza/anteprima. Se inverti questo, la produzione può far trapelare voci non pubblicate anche con autenticazione e noindex entrambi attivi.

Bing e IndexNow

Bingbot ora renderizza JavaScript usando Microsoft Edge (Chromium) — la stessa tecnologia di piattaforma web di Googlebot — ma lo fa in modo meno coerente di Google. I test di Screaming Frog hanno giudicato l’indicizzazione JavaScript di Bing “far from reliable,” (traduzione) «tutt’altro che affidabile», con una conclusione netta: “if you care about SEO and sleeping at night, don’t rely on client-side rendering.” (traduzione) «se ti interessano la SEO e il sonno, non affidarti al rendering lato client». SSR e SSG contano quindi ancora di più se il traffico da Bing è importante.

Bing punta anche molto su un modello push. Poiché gli aggiornamenti dei contenuti headless fluiscono attraverso un’API e non avvisano Bing come farebbe un plugin WordPress, IndexNow è particolarmente prezioso qui — collega un trigger IndexNow al webhook di pubblicazione del tuo CMS così che gli URL modificati vengano segnalati istantaneamente. La cornice sull’economia di scansione di Fabrice Canel vale la pena tenere a mente: meno URL, più puliti, sono meglio, quindi non lasciare che la navigazione a faccette guidata da API generi migliaia di URL con parametri non canonicalizzati.

Migrare a headless senza far crollare il traffico

Le migrazioni sono il punto in cui la SEO headless va davvero storta. Secondo l’analisi di settore, le migrazioni da WordPress a headless vedono spesso grandi cali di traffico e lunghi recuperi — tratta cifre come un calo di ~50% e un recupero di ~523 giorni come un avvertimento direzionale su quanto male faccia una migrazione mal eseguita, non come numeri precisi. Le cause principali sono prevedibili: 301 rotti (soprattutto su pagine di categoria, tag e archivi paginati che tutti dimenticano), metadati che non sono stati trasferiti e una modalità di rendering che è silenziosamente tornata a CSR. Fai l’inventario di ogni URL (non solo dei post), crea una mappa completa dei 301 prima del go-live, verifica metadati e canonical sul nuovo frontend, effettua un confronto delle scansioni Screaming Frog pre/post, invia nuovamente le sitemap sia a GSC che a Bing Webmaster Tools e attiva IndexNow. Vedi la scheda della checklist di migrazione per l’elenco completo.

Le letture correlate si trovano negli argomenti JavaScript SEO e rendering — la SEO headless è in realtà un’applicazione specializzata di entrambi.

Riepilogo AI

Una sintesi della versione Advanced:

• L’architettura è il prodotto. Il backend CMS è quasi neutrale per la SEO; la modalità di rendering del frontend decide tutto. “Headless è negativo per la SEO” è un mito.
• Mappa delle proprietà: modello di contenuto CMS = campi strutturati grezzi. API di consegna = contenuto solo pubblicato per la produzione. API di anteprima/gestione = contenuto in bozza, con il proprio token/host. Frontend/build = l’effettivo <head> renderizzato, canonical, sitemap, robots.txt, schema e routing delle locale. La produzione non deve mai chiamare l’API di anteprima/gestione o il token.
• Modalità di rendering: SSG e SSR forniscono HTML completamente renderizzato e sono le scelte sicure. CSR è la più rischiosa (il contenuto esiste solo dopo un’onda di rendering successiva). ISR è un buon compromesso ma ha una trappola.
• La trappola ISR: dopo la finestra di rivalidazione, la richiesta successiva — possibilmente Googlebot — riceve ancora la pagina obsoleta; quella aggiornata viene servita solo alla richiesta successiva. Usa SSR per dati volatili.
• Il rendering dinamico è deprecato — Google ora raccomanda SSR, rendering statico o idratazione. Non è automaticamente cloaking, ma non usarlo su nuove build.
• Il rendering dei crawler AI è specifico del provider — le pagine CSR dipendono dall’esecuzione client che non è coperta da un contratto condiviso. SSR/SSG massimizza la copertura.
• Ricostruisci ciò che faceva il plugin: i campi SEO nel modello di contenuto → mappati nel <head> → sitemap + robots.txt costruiti esplicitamente. Non bloccare mai .js/.css. I metadati a livello HTML battono quelli iniettati via JS. Definisci una catena di fallback e scappa dai campi rich-text prima che finiscano in un <title> o in una stringa JSON-LD.
• I canonical si frammentano tra slug CMS → URL framework → tag componente. Impostali a livello di rendering usando URL assoluti da un singolo SITE_URL.
• La proprietà delle locale si divide allo stesso modo: il fallback delle locale dell’API sostituisce il contenuto, ma il frontend possiede gli URL delle locale, i canonical per locale, hreflang, x-default e cosa succede quando manca una traduzione.
• I link devono essere veri <a href> — <div onClick> non è crawlabile.
• Difesa dell’anteprima in ordine: autentica prima, mantieni separati token e host di anteprima/produzione, interroga contenuti solo pubblicati in produzione — noindex è una salvaguardia secondaria, non un controllo di accesso, poiché Google deve scansionare la pagina per vedere il tag.
• Pubblica/annulla pubblicazione/rinomina/cambi di locale richiedono una purge attivata da webhook su cache API, cache framework, CDN, sitemap e metadati — non un timer fisso — più un percorso di rollback.
• Bing renderizza JS (tramite Edge) ma in modo meno affidabile di Google; usa IndexNow sul webhook di pubblicazione CMS. Google impone un limite di risorse di ~2 MB.
• Le migrazioni falliscono per reindirizzamenti rotti, metadati persi e CSR accidentale — inventario completo degli URL + mappa dei redirect prima del go-live.

Documentazione ufficiale

Documentazione di fonte primaria dai motori di ricerca.

Google

• Comprendere le basi della SEO JavaScript — il processo crawl → render → index, i canonical con JavaScript, gli errori soft “pagina non trovata” nelle SPA e le indicazioni sull’History API.
• Dynamic Rendering (workaround deprecato) — perché Google lo ha deprecato e cosa usare al suo posto (SSR, rendering statico, hydration).
• Risolvere i problemi JavaScript legati alla ricerca — diagnosi dei problemi del DOM renderizzato, rendering stateless e fingerprinting contro la cache aggressiva.
• Rendering per app web basate sui contenuti — compromessi tra SSR, SSG e CSR per i siti di contenuti.
• Rendering sul Web (web.dev — Addy Osmani & Jason Miller) — le definizioni canoniche di SSR, CSR e hydration, oltre alla raccomandazione di preferire SSR o rendering statico rispetto alla reidratazione completa.

Bing / Microsoft

• Il nuovo Bingbot evergreen (Microsoft Edge) — Bingbot che renderizza JavaScript tramite la stessa tecnologia della piattaforma web di Googlebot.
• IndexNow / indexnow.org — il protocollo push da collegare al webhook di pubblicazione del tuo CMS.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e Bing. Ogni link è un deep link che salta al passaggio citato nella pagina di origine.

Google — come vengono elaborate le pagine JavaScript

• “All pages returning a 200 HTTP status code are queued for rendering, no matter whether JavaScript is present on the page.” (traduzione) «Tutte le pagine che restituiscono un codice di stato HTTP 200 vengono messe in coda per il rendering, indipendentemente dalla presenza di JavaScript nella pagina.» — Documentazione di Google Search Central. Vai alla citazione
• “Google Search won’t render JavaScript from blocked files or on blocked pages.” (traduzione) «Google Search non renderizza JavaScript da file bloccati o su pagine bloccate.» — Documentazione di Google Search Central. Vai alla citazione
• “Don’t use fragments to load different page content.” (usa invece l’History API) (traduzione) «Non usare i frammenti per caricare contenuti di pagina diversi.» — Documentazione di Google Search Central. Vai alla citazione

Google — il dynamic rendering è deprecato

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (traduzione) «Il dynamic rendering era un workaround e non una soluzione a lungo termine per i problemi relativi ai contenuti generati da JavaScript nei motori di ricerca.» — Documentazione di Google Search Central. Vai alla citazione
• Consigliato invece: “server-side rendering, static rendering, or hydration.” (traduzione) «rendering lato server, rendering statico o hydration.» — Documentazione di Google Search Central. Vai alla citazione
• Google precisa che il rendering dinamico “creates additional complexities and resource requirements.” (traduzione) «crea complessità aggiuntive e richiede più risorse». — Documentazione di Google Search Central. Vai alla citazione

Google — preferisci SSR / rendering statico (web.dev)

• “We encourage developers to consider server-side rendering or static rendering over a full rehydration approach.” (traduzione) «Incoraggiamo gli sviluppatori a prendere in considerazione il rendering lato server o il rendering statico rispetto a un approccio di reidratazione completa.» — Addy Osmani & Jason Miller, web.dev. Vai alla citazione

Due checklist: salute SEO headless + migrazione

Controllo salute SEO headless

• Le pagine rendono il loro contenuto in HTML alla prima richiesta (SSR o SSG), non solo dopo l’esecuzione di JavaScript lato client.
• Nessuna pagina critica dipende dalla CSR per il suo contenuto principale (ricorda: i crawler AI non eseguono JS).
• I campi SEO (title, description, robots, canonical, OG) esistono nel modello di contenuto del CMS e sono mappati nel <head>.
• I canonical sono URL assoluti costruiti da un singolo SITE_URL, impostato a livello di rendering — e sono per pagina, non un canonical condiviso per la homepage.
• robots.txt esiste e non blocca .js o .css.
• Una sitemap è generata programmaticamente e rimane aggiornata (rigenerata con ISR / segmentata su siti ad alto volume).
• I link interni sono veri tag <a href> — nessuna navigazione con <div onClick>.
• I dati strutturati (JSON-LD) sono nel <head> renderizzato lato server e superano il Rich Results Test.
• Gli host di anteprima/staging restituiscono un’intestazione noindex a livello di host.
• IndexNow scatta sull’evento di pubblicazione del CMS (per Bing e altri).

Checklist di migrazione (CMS tradizionale → headless)

• Inventario completo degli URL — non solo i post: pagine autore, pagine tag, archivi paginati, URL con parametri.
• Mappa di reindirizzamento 301 per ogni URL modificato, costruita prima del go-live.
• Metadati (title, description) migrati e verificati per URL.
• Tag canonical verificati sul nuovo frontend.
• Modalità di rendering confermata come SSR/SSG (non un default CSR accidentale).
• Sitemap ripresentate a Google Search Console e Bing Webmaster Tools.
• Confronto crawl (Screaming Frog) eseguito pre- vs. post-lancio.
• Proprietà Search Console impostata per qualsiasi nuovo dominio/protocollo.
• IndexNow implementato.

I modelli mentali

1. L’architettura è il prodotto. Il backend del CMS è quasi neutrale per la SEO. La modalità di rendering del frontend è il prodotto. Prima di eseguire il debug di qualsiasi cosa in un sito headless, rispondi prima a una domanda: come sta rendendo questo contenuto il frontend? Quasi ogni problema SEO headless si riduce a questo.

2. La regola decisionale sulla modalità di rendering. Scegli in base a quanto spesso cambia il contenuto e a quanto è interattivo:

• Contenuto per lo più statico (blog, documentazione, marketing) → SSG (rebuild o ISR con un timer).
• Contenuto che cambia frequentemente e deve essere sempre fresco (prezzi, stock) → SSR.
• Cambiamenti nell’ordine di ore/giorni, vuoi velocità statica → ISR (attenzione alla trappola dello stale-on-first-request).
• Altamente interattivo, dietro un login, non destinato all’indicizzazione → CSR è accettabile.
• Contenuto pubblico che vuoi classificare o citare con l’AI → mai CSR.

3. “Ricostruisci ciò che faceva il plugin.” Ogni comportamento automatico di Yoast/Rank Math è ora un passaggio di build deliberato: campi metadati nel modello di contenuto → mappati a <head> → sitemap → robots.txt → canonical → dati strutturati. Se qualcosa “manca”, di solito significa che un comportamento del plugin non è mai stato reimplementato.

4. Un’unica fonte di verità per gli URL. Canonical, voci di sitemap e link interni dovrebbero tutti derivare da un singolo SITE_URL e dal routing del framework — non da slug assemblati a mano in tre livelli diversi. Un’unica fonte di verità elimina la frammentazione dei canonical.

5. HTML-first, JS-second. Tutto ciò che conta per il crawling e l’indicizzazione — contenuto, metadati, canonical, link interni, dati strutturati — appartiene all’HTML renderizzato lato server. Tratta i segnali SEO iniettati via JS come un fallback, non come il piano, perché vengono visti tardi da Google e per niente dalla maggior parte dei crawler AI.

SEO headless — cheat sheet

Modalità di rendering a colpo d’occhio

Gestione dei metadati per framework

Regole rapide

• Mai disallow di .js / .css in robots.txt.
• Canonical: URL assoluti da un unico SITE_URL, impostati a livello di rendering.
• In Next.js App Router, imposta metadataBase o i canonical relativi si rompono.
• Link interni = veri <a href>. <div onClick> è invisibile ai crawler.
• Anteprima/staging: header noindex a livello di host, non un meta tag JS tardivo.
• Limite risorse Google: ~2 MB, troncato oltre.
• Rendering dinamico: deprecato — usa SSR / rendering statico / idratazione.
• La maggior parte dei crawler AI: niente JavaScript → il contenuto CSR è invisibile per loro.
• Bing: esegue il rendering di JS (Edge) ma meno affidabilmente; collega IndexNow per pubblicare eventi.

Controlla la risposta servita dal server

Esporta le rotte frontend rappresentative in urls.txt. Questo usa intenzionalmente la risposta grezza piuttosto che un browser, così i metadati mancanti renderizzati lato server non possono nascondersi dietro l’idratazione:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sS -o "$html" -w '%{http_code}' "$url")
  title_count=$(grep -Eio '<title>[^<]*</title>' "$html" | wc -l | tr -d ' ')
  canonical_count=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | wc -l | tr -d ' ')
  jsonld_count=$(grep -Eio '<script[^>]+type=["'"']application/ld\+json["'"']' "$html" | wc -l | tr -d ' ')
  printf '%s\t%s\ttitles=%s\tcanonicals=%s\tjsonld=%s\n' "$status" "$url" "$title_count" "$canonical_count" "$jsonld_count"
  rm -f "$html"
done < urls.txt

Esegui un confronto del rendering separatamente per le rotte che trasmettono o caricano contenuti in streaming più tardi. Non inserire mai token di anteprima CMS nell’elenco URL.

Strumenti per diagnosticare la SEO headless

• URL Inspection (Google Search Console) — vedi come un singolo URL è stato indicizzato e renderizzato. L’HTML renderizzato / lo screenshot ti dice se il tuo contenuto è effettivamente arrivato — essenziale per individuare le lacune CSR.
• Rich Results Test — conferma che JSON-LD sia presente nell’output renderizzato dopo qualsiasi modifica al rendering (i tempi di iniezione JS possono cambiare ciò che viene rilevato).
• Screaming Frog SEO Spider — esegui la scansione con rendering JavaScript attivo/disattivo per confrontare ciò che c’è nell’HTML grezzo rispetto all’HTML renderizzato; costruisci il confronto pre/post scansione per le migrazioni.
• Ahrefs Site Audit — evidenzia catene di reindirizzamento, canonical rotti, metadati mancanti e problemi di indicizzabilità in tutto il frontend.
• Bing Webmaster Tools — la vista di rendering/indicizzazione di Bing, oltre a dove vengono mostrate le sottomissioni IndexNow.

Errori che continuo a vedere nelle build headless

Pubblicare il sito di marketing come SPA renderizzata lato client. Un frontend React o Vue puro senza livello SSR/SSG è l’errore SEO headless più comune. Perché è sbagliato: Googlebot deve mettere in coda la pagina per una seconda ondata di rendering prima che il tuo contenuto esista per lui, mentre i provider AI pubblicano contratti di rendering diversi o incompleti. I fetcher solo HTML vedono il guscio vuoto. Fai invece: scegli un framework che fornisce HTML completamente renderizzato per impostazione predefinita (Next.js, Nuxt, Astro, Gatsby) e usa SSR o SSG per qualsiasi pagina che vuoi venga trovata.

Trattare il campo slug del CMS come URL canonico. Gli sviluppatori spesso costruiscono il <link rel="canonical"> direttamente da ciò che restituisce il CMS. Perché è sbagliato: il canonical poi si frammenta tra slug CMS, routing del framework e logica dei componenti — uno slug rinominato o una rotta refactorizzata lo rompe silenziosamente. Fai invece: costruisci i canonical a livello di rendering da una singola variabile d’ambiente SITE_URL, mai direttamente dall’output del CMS.

Lasciare che le anteprime/le distribuzioni di staging rimangano pubblicamente indicizzabili. Gli URL di anteprima di Vercel/Netlify e gli endpoint di bozza del CMS sono raggiungibili per impostazione predefinita. Perché è sbagliato: se Google ne trova uno, può indicizzare un duplicato completo del tuo sito su un altro host — e un meta tag noindex iniettato tardivamente da JavaScript spesso non è sufficiente per fermarlo. In alternativa: applica noindex come header HTTP a livello di host e proteggi le anteprime con token firmati.

Configurare ISR e presumere che sia sempre aggiornato. I team scelgono ISR per la freschezza “abbastanza buona” e smettono di pensarci. Perché è sbagliato: la richiesta che attiva la rigenerazione dopo la finestra di convalida — possibilmente Googlebot — riceve comunque la pagina cache scaduta; solo la richiesta successiva vede l’aggiornamento. In alternativa: usa ISR per contenuti che cambiano nell’ordine di ore o giorni, e passa i dati realmente volatili (prezzi, livelli di stock) a SSR.

Costruire la navigazione e i link ai contenuti correlati come <div> cliccabili. Le librerie di componenti rendono facile collegare un gestore di navigazione onClick a qualsiasi elemento. Perché è sbagliato: i motori di ricerca seguono solo veri anchor <a href> — un <div onClick> è invisibile ai crawler non importa come appare a un visitatore. In alternativa: renderizza ogni link interno, inclusi i link ai post correlati e i breadcrumb recuperati dall’API, come un vero tag anchor.

Disallow di .js o .css in robots.txt “per risparmiare crawl budget.” Questo si presenta più di quanto ci si aspetterebbe su build headless che hanno ereditato un vecchio robots.txt. Perché è sbagliato: Google non può renderizzare una pagina il cui JavaScript o CSS è bloccato, quindi questo non risparmia crawl budget — rompe completamente il rendering. In alternativa: lascia .js e .css indicizzabili; non c’è alcuna ragione legittima per bloccarli.

Sintomo → causa → soluzione

URL Inspection mostra che la pagina è stata recuperata correttamente, ma l’HTML renderizzato manca di contenuti

Causa: la pagina è renderizzata lato client e il contenuto esiste solo dopo che JavaScript viene eseguito nel browser — lo strumento URL Inspection di Google ti mostra il DOM post-render, e se il tuo contenuto principale è ancora assente lì, l’onda di rendering non lo sta producendo (o non è ancora stata eseguita). Soluzione: conferma la modalità di rendering con lo strumento Render Gap di Patrick, che confronta l’HTML grezzo con l’HTML renderizzato per un URL. Se il divario è reale, sposta quella rotta su SSR o SSG piuttosto che affidarti a fetch lato client.

Il canonico che Google riporta in Search Console non è quello nel tuo codice

Causa: frammentazione canonica — lo slug del CMS, l’assemblaggio URL del framework e il componente che renderizza il tag sono andati fuori sincrono, oppure un layout condiviso sta emettendo lo stesso canonico su ogni pagina. Soluzione: controlla il tag live con il Canonical Checker di Patrick, poi sposta la costruzione del canonico al livello di rendering e costruiscilo da una singola variabile SITE_URL invece di tre pezzi separati.

Il traffico è calato bruscamente subito dopo una migrazione headless

Causa: quasi sempre 301 rotti — specialmente su pagine di categoria, tag e archivi paginati che nessuno ha ricordato di mappare — o metadati che non sono stati trasferiti dal vecchio CMS. Soluzione: esegui ogni vecchio URL attraverso il Redirect Checker di Patrick per confermare che ciascuno risolva con un singolo 301 alla destinazione corretta, non una catena o un 404, poi verifica che titoli e descrizioni siano migrati per URL.

Gli URL di anteprima o staging stanno comparendo in Search Console o in una ricerca site:

Causa: l’host di anteprima/staging non è mai stato bloccato dall’indicizzazione a livello di host — un meta tag noindex iniettato lato client può arrivare troppo tardi perché Google lo veda. Soluzione: applica l’header HTTP noindex nella configurazione dell’ambiente stesso (non solo nel markup della pagina) e proteggi l’host di anteprima con un token firmato così non è affatto pubblicamente indicizzabile.

Il Rich Results Test non rileva dati strutturati che sono chiaramente nel tuo codice sorgente

Causa: il JSON-LD viene iniettato lato client dopo la risposta HTML iniziale, e la tempistica non coincide con ciò che il test — o la prima scansione di Googlebot — vede effettivamente. Correzione: sposta il JSON-LD nel <head> renderizzato lato server, poi ricontrolla con il Schema Validator di Patrick o con il Rich Result Eligibility Checker sulla risposta grezza, non solo sul DOM renderizzato dal browser.

La sitemap elenca ancora URL che hai eliminato o rinominato mesi fa

Causa: una sitemap statica generata in fase di build che si rigenera solo quando l’intero sito viene ricostruito — su un sito ad alto volume di pubblicazioni, può essere in ritardo di giorni o settimane. Correzione: passa a una sitemap che si rigenera con la stessa cadenza dei tuoi contenuti (rigenerata con ISR o segmentata per tipo di contenuto) e conferma l’output attuale con il Sitemap Validator di Patrick.

Quale modalità di rendering dovrebbe usare questa pagina?

La scelta della modalità di rendering è la decisione che determina quasi tutto il resto della SEO di una pagina headless. Affrontala per rotta, non una volta per l’intero sito — un sito di marketing e le sue rotte del dashboard autenticato possono (e dovrebbero) finire in posti diversi.

Traffico in calo dopo una migrazione headless — le prossime mosse

Questo è lo scenario che vedo più spesso, e ha un insieme prevedibile di cause profonde. Segui l’elenco in ordine — ogni passaggio o risolve il problema o lo esclude e ti manda al successivo.

1. Prima tira fuori le statistiche di scansione e il report di copertura in Search Console. Se vedi un picco di 404 o un calo delle pagine indicizzate subito dopo il lancio, vai al passaggio 2. Se l’indicizzazione sembra stabile ma classifiche/traffico sono comunque calati, salta al passaggio 5.
2. Controlla i redirect rotti. Esegui l’intero elenco di URL pre-migrazione — non solo i post, ma anche le pagine autore, le pagine tag e gli archivi paginati — tramite il Redirect Checker di Patrick. Se qualcuno risolve in un 404, una catena di redirect o la destinazione sbagliata, costruisci (o correggi) la mappa 301 prima di fare qualsiasi altra cosa.
3. Se i redirect sono puliti, controlla la migrazione dei metadati. Verifica a campione titoli e descrizioni sui tuoi URL pre-migrazione a più alto traffico rispetto a ciò che è live ora. I metadati che non sono stati trasferiti dal vecchio CMS sono la seconda causa più comune di un calo post-migrazione.
4. Se i metadati sono a posto, controlla la modalità di rendering. Conferma che il nuovo frontend non sia silenziosamente passato al default CSR — usa lo Render Gap tool di Patrick su un campione di pagine per confrontare l’HTML grezzo vs. quello renderizzato. Una configurazione errata del framework che fa scendere SSR/SSG a CSR è esattamente il tipo di cosa che viene pubblicata senza che nessuno se ne accorga.
5. Se tutto quanto sopra è a posto, verifica che i canonical non si siano frammentati. Controlla a campione con il Canonical Checker — un canonical di layout condiviso o uno slug cambiato durante la migrazione può consolidare silenziosamente le classifiche sull’URL sbagliato.
6. Invia di nuovo le sitemap sia a Google Search Console che a Bing Webmaster Tools, e conferma che IndexNow sia collegato al webhook di pubblicazione del tuo CMS così che gli URL nuovi e modificati vengano segnalati in futuro invece di aspettare di essere riscansionati.
7. Se hai seguito i passaggi 2–6 e il traffico non si è ancora ripreso, trattalo come un recupero più lungo, non come un bug da scovare — le migrazioni headless che risolvono tutti i problemi tecnici richiedono comunque in genere tempo reale per recuperare completamente, poiché Google deve riscansionare e rivalutare la nuova struttura del sito.

Prompt per attività SEO headless

Questi sono pensati per essere incollati nell’assistente AI che stai usando, con l’input tra parentesi quadre sostituito. Sono limitati alle attività specifiche trattate in questo articolo — non prompt generici di “audit SEO”.

1. Individua contenuti solo-CSR in un componente di pagina

Incolla il tuo componente di pagina/modello (es. un page.tsx di Next.js o un file .vue di Nuxt) e chiedi:

Here is a page component from my headless CMS frontend. Identify any content
that is fetched or rendered only on the client (inside useEffect, onMounted,
or similar client-only hooks) rather than during server rendering or build.
For each one, tell me whether it would be present in the initial HTML
response or only appear after JavaScript runs in the browser.

[paste component code]

Aspettati un elenco di blocchi di contenuto specifici contrassegnati come renderizzati lato server rispetto a solo client, che ti dice esattamente cosa non sarà visibile ai crawler AI o al primo fetch di Google.

2. Rivedi un’implementazione di URL canonici per il rischio di frammentazione

Incolla il codice che genera il tuo tag canonico (il campo CMS, la logica di assemblaggio dell’URL e il componente che renderizza <link rel="canonical">) e chiedi:

This is how my headless site builds its canonical URL across three layers:
the CMS content model, the framework's URL assembly, and the rendering
component. Identify any point where these could drift out of sync (a slug
change, a route change, a hardcoded fallback) and suggest how to consolidate
this into a single source of truth built from one SITE_URL variable.

[paste canonical-related code from CMS field, framework logic, and component]

Aspettati rischi di deriva specifici legati al tuo codice effettivo, non consigli canonici generici.

3. Bozza dei campi SEO da aggiungere a un modello di contenuto CMS

Descrivi i tuoi tipi di contenuto e chiedi:

I'm setting up SEO fields in a headless CMS content model for [content type,
e.g. "blog post" / "product page"]. List the fields I should add (title,
description, robots override, canonical override, Open Graph fields, etc.),
a sensible field type for each, and which ones should have sensible
auto-generated defaults vs. requiring manual entry.

[describe your content type and any existing fields]

Aspettati un elenco campo per campo che puoi consegnare a chi configura il CMS, limitato al tipo di contenuto che hai descritto piuttosto che a una checklist generica.

4. Confronta HTML grezzo e renderizzato per una crawl di migrazione

Incolla due esportazioni di crawl (crawl HTML grezzo e crawl renderizzato con JS, ad esempio da Screaming Frog eseguito in entrambi i modi) e chiedi:

Here are two crawl exports of the same URL set from my headless site — one
crawled with JavaScript rendering off (raw HTML) and one with it on
(rendered HTML). Compare them and flag any URLs where the title, meta
description, canonical, or main content differs meaningfully between the two,
since that gap indicates content is only appearing after client-side
rendering.

[paste or summarize the two exports]

Aspettati un elenco di URL in cui l’HTML grezzo e quello renderizzato divergono: quelle sono le tue pagine dipendenti da CSR che vale la pena correggere per prime.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Problemi e buone pratiche della SEO JavaScript — il mio riferimento principale sul rendering, direttamente pertinente ai sistemi headless. Copre modalità di rendering, moduli di metadati, canonical JavaScript, sitemap e la regola robots.txt Allow: .js / Allow: .css.
• Guida introduttiva alla SEO tecnica — dove rendering e scansione si inseriscono nel quadro più ampio.

I miei interventi

• JavaScript SEO — Ungagged 2019 (SlideShare) — la mia spiegazione di come i CMS headless/disaccoppiati separano frontend e backend, più il comportamento di rendering stateless di Googlebot. (Disclaimer permanente: la raccomandazione sul dynamic rendering in quella presentazione è ora obsoleta — Google l’ha deprecata.)

Da altri

• Il rendering sul Web (web.dev) — il riferimento di Addy Osmani e Jason Miller sulle modalità di rendering.
• Studio sul rendering JavaScript di Bing (Screaming Frog) — la verifica su quanto Bing indicizzi realmente JavaScript in modo coerente.
• Rendering lato client e lato server (Search Engine Journal) — Martin Splitt spiega perché Google renderizza tutto l’HTML.
• Fallback senza JavaScript nel 2026: meno critici, ma ancora necessari (Search Engine Land, James Allen) — tratta i crawler AI che non eseguono JavaScript e il limite di risorse di 2 MB di Google; cita il risultato di Vercel secondo cui nessuno dei principali crawler AI renderizza contenuti lato client.
• Decisioni architetturali che incidono sul ranking (Focus Reactive) — una delle analisi indipendenti più rigorose sugli effetti SEO di specifiche scelte architetturali headless.
• Guida introduttiva ai CMS headless (Oncrawl, Dan Taylor) — una guida orientata alla SEO tecnica sull’architettura disaccoppiata e le sue implicazioni per la scansione.
• Principi SEO per il commercio headless (Women in Tech SEO, Safia Marmon) — guida pratica per l’e-commerce headless, con metadati, canonical e modelli di sitemap.
• Metadati e immagini Open Graph in Next.js (documentazione Next.js) — riferimento ufficiale per generateMetadata, metadataBase e i modelli di gestione head dell’App Router coperti nella scheda Avanzate.
• r/TechSEO — la community per il debug di rendering/indicizzazione.

Cronologia modifiche