Edge SEO: la SEO all’edge

In breve — Edge SEO significa apportare modifiche tecniche per la SEO sul CDN, la rete che si trova davanti al sito, invece di intervenire sul sito stesso. Un piccolo script, chiamato “worker”, in esecuzione sul CDN può aggiungere un reindirizzamento, correggere un tag o riscrivere robots.txt prima che la pagina raggiunga un visitatore o Google. È il modo in cui i professionisti SEO pubblicano rapidamente correzioni su piattaforme che non possono modificare o mentre attendono gli sviluppatori. La regola fondamentale: qualsiasi modifica deve valere per tutti. Mostrare a Google qualcosa di diverso da ciò che vedono gli utenti reali è cloaking e viola le norme.

Che cos’è l’edge SEO

La maggior parte dei siti si trova dietro un CDN (content delivery network), una rete globale di server che memorizza il sito nella cache e lo distribuisce rapidamente agli utenti. Cloudflare è il più noto. Poiché il CDN è l’ultimo elemento tra il server reale, detto “origine”, e il mondo esterno, può vedere e modificare ogni risposta in uscita.

L’edge SEO sfrutta questa posizione. Invece di chiedere a uno sviluppatore di cambiare il codice del sito, si inserisce sul CDN un piccolo programma, un worker, che modifica la pagina mentre transita. Può aggiungere un reindirizzamento, inserire un tag mancante, sostituire un titolo o riscrivere il file robots.txt. La modifica va online in pochi minuti senza toccare il sito vero e proprio.

Viene chiamata anche SEO serverless, perché il worker viene eseguito sull’infrastruttura del CDN, non su un server gestito da te.

Perché viene utilizzata

Per due motivi principali:

• Sei bloccato in una coda di sviluppo. I professionisti SEO aspettano spesso mesi prima che una raccomandazione venga implementata. L’edge SEO consente di pubblicare la modifica in autonomia.
• Non puoi modificare la piattaforma. Alcune piattaforme, come Shopify o determinati sistemi aziendali, non permettono di intervenire su robots.txt, impostare reindirizzamenti personalizzati o aggiungere certi tag. Un worker posto davanti alla piattaforma può farlo comunque.

La regola più importante

Questo è il punto da ricordare: Google deve vedere la stessa pagina dei visitatori.

L’edge SEO è del tutto accettabile quando il worker applica la stessa modifica a tutti: se inserisci un tag canonical, lo ricevono sia il bot sia la persona. Nel momento in cui il worker verifica “è Google?” e mostra a Google qualcosa di diverso da ciò che vedono gli utenti reali, si tratta di cloaking, una violazione delle norme di Google.

Quindi modifica la pagina per tutti. Non modificarla mai soltanto per il motore di ricerca.

Altri due aspetti da conoscere

• Il CDN può anche bloccare Google per errore. Le funzioni di sicurezza, come i firewall e le opzioni per “bloccare i bot dannosi”, a volte considerano Googlebot una minaccia: quando le attivi, ricontrolla che Google riesca ancora ad accedere.
• Non usare l’edge per eseguire il “pre-rendering” delle pagine soltanto per Google. È una vecchia tecnica da cui Google si è ufficialmente allontanata. Maggiori dettagli nella scheda Avanzato.

Vuoi il quadro completo: come i worker intercettano davvero le richieste, quali piattaforme sono disponibili, i casi d’uso reali e dove si nascondono i rischi? Passa alla scheda Avanzato.

In breve — L’edge SEO, o SEO serverless, implementa la SEO tecnica al livello del worker CDN/edge: reindirizzamenti, canonical, hreflang, robots.txt, X-Robots-Tag, JSON-LD e test A/B suddivisi per pagina. Intercetta e riscrive la risposta prima che raggiunga l’utente o il crawler, senza distribuire modifiche sull’origine o sul CMS. Il worker opera in tre fasi: modifica della richiesta in entrata, modifica delle intestazioni in uscita e modifica del corpo della risposta. Risolve i ritardi delle code di sviluppo e i limiti di piattaforme bloccate come Shopify e Salesforce CC. Il confine invalicabile è il cloaking: applica ogni modifica a tutto il traffico e non mostrare mai a Googlebot qualcosa di diverso dagli utenti. Altre due insidie sono specifiche dell’edge: le regole WAF e anti-bot del CDN possono bloccare Googlebot in silenzio prima dell’esecuzione del worker, quindi vanno controllate rispetto agli intervalli IP di Google; inoltre, il pre-rendering riservato ai bot è strutturalmente rendering dinamico, ormai deprecato da Google. Il worker è anche un singolo punto di guasto sul percorso di ogni richiesta: versionalo, limitane l’ambito e predisponi un rollback con un clic.

Che cos’è davvero l’edge SEO

L’edge SEO consiste nell’implementare modifiche tecniche per la SEO — meta tag, canonical, hreflang, reindirizzamenti, modifiche a robots.txt, inserimento di dati strutturati, test A/B e, con cautela, pre-rendering — al livello CDN/edge tramite script worker serverless, invece di modificare il server di origine o il CMS. Il CDN diventa un intermediario attivo che intercetta, riscrive e ridistribuisce richieste e risposte prima che raggiungano utenti o crawler.

L’intuizione architetturale fondamentale è che Google vede soltanto ciò che il CDN serve. Non può sapere se è intervenuto un worker: la risposta edge è la verità canonica su ciò che contiene la pagina. È proprio questo a rendere l’edge un livello SEO tanto potente e a rendere altrettanto importante il confine del cloaking: tecnicamente nulla impedisce di servire due contenuti diversi; lo impediscono le norme.

Ho lavorato con questo approccio su larga scala. In un’intervista a Marketing Speak ho descritto in modo diretto ciò che permettono di fare i Cloudflare Workers: in pratica consentono di eseguire JavaScript per fare qualunque cosa. La differenza rispetto a un tag manager è la tempistica: all’edge si riscrive la pagina prima che l’utente la veda, mentre Google Tag Manager deve prima caricarsi nella pagina e poi apportare modifiche lato client. Su una proprietà molto grande si può puntare HTML Rewriter al sito, individuare errori su larga scala e scrivere regole per correggerli: pagine erroneamente impostate su noindex che dovrebbero essere indicizzate, nofollow che dovrebbe essere follow, titoli e meta description da riscrivere, il tutto senza distribuire nuovo codice.

Un po’ di storia aiuta a non esagerarne la portata: il termine “edge SEO” è stato coniato da Dan Taylor di SALT.agency e presentato pubblicamente al TechSEO Boost di Boston nel 2018, dove SALT ha vinto il primo premio per la ricerca sul ricorso ai Cloudflare Workers nella SEO. Come spiegò Dan, l’obiettivo era ridurre, tramite worker come quelli di Cloudflare, gli ostacoli creati da vecchie piattaforme web, code di sviluppo congestionate e sviluppatori poco collaborativi. La sua definizione canonica descrive l’edge SEO come l’implementazione di raccomandazioni SEO e correzioni tecniche e il superamento dei limiti della piattaforma tramite un’applicazione serverless su un server edge del CDN.

Perché il problema della coda di sviluppo è reale

La causa alla base è concreta. SALT citò una ricerca Moz del 2016 di Will Critchlow, secondo cui la maggior parte dei professionisti SEO vedeva implementate le proprie raccomandazioni circa sei mesi dopo averle formulate, perché le richieste del marketing passavano in secondo piano rispetto alle priorità degli altri team. L’edge SEO affronta direttamente il problema: invece di attendere uno sprint di ingegneria, si distribuisce un worker.

Le piattaforme in cui conta di più sono quelle bloccate: Shopify, che storicamente aveva un robots.txt codificato rigidamente, Salesforce Commerce Cloud e gli stack aziendali legacy in cui semplicemente non è possibile modificare ciò che serve.

Come i worker edge intercettano richieste e risposte

Un worker si trova sul percorso di richiesta e risposta e può applicare trasformazioni componibili prima di restituire il risultato.

Fase 1 — Modifica della richiesta. L’utente o Googlebot invia una richiesta e il CDN la riceve prima dell’origine. Il worker può riscrivere l’URL, restituire immediatamente un reindirizzamento (un 3xx direttamente dall’edge, senza raggiungere l’origine), modificare le intestazioni della richiesta oppure lasciarla passare.

Fase 2 — Modifica delle intestazioni della risposta. L’origine restituisce una risposta; il worker può aggiungere o modificare le intestazioni di risposta: X-Robots-Tag, Link: rel=canonical, intestazioni di caching e intestazioni di sicurezza.

Fase 3 — Modifica del corpo della risposta. Il worker analizza il flusso HTML e lo riscrive: inserisce <link rel="canonical">, alternative hreflang, <title>, <meta name="robots">, <meta name="description"> o <script type="application/ld+json">; rimuove o sostituisce contenuti. HTML Rewriter di Cloudflare è lo strumento standard; le interfacce pubblicate da SALT (RequestFilter, ResponseFilter, BodyFilter) sono indipendenti e componibili.

Nei test di SALT, la latenza aggiunta era in media nell’ordine di circa 10 ms, con casi estremi fino a circa 50 ms; il team non ha rilevato variazioni statisticamente significative nella latenza di produzione con i filtri sul corpo attivi. Per la maggior parte dei siti il compromesso è trascurabile e la vicinanza del CDN all’utente può compensarlo.

Piattaforme e strumenti

L’ecosistema dei worker edge è ampio. In sintesi:

La distinzione tra Cloudflare Snippets e Workers è poco trattata altrove. Regola pratica per la SEO: usa Snippets per reindirizzamenti e modifiche alle intestazioni, perché sono leggeri, gratuiti nei piani a pagamento e privi di archiviazione persistente. Usa Workers per inserire contenuti nel corpo HTML, come canonical, hreflang e JSON-LD, per grandi tabelle di reindirizzamenti in KV o per test A/B con persistenza.

Una nota sugli strumenti aziendali per i test A/B: JetStream di SearchPilot è un binario WASM che, secondo la società, si colloca all’edge senza aggiungere nuovi livelli allo stack web e suddivide le pagine, non gli utenti. È questo che lo mantiene dal lato sicuro del confine del cloaking, approfondito più avanti.

Casi d’uso comuni

• Reindirizzamenti all’edge. Conserva una tabella di reindirizzamenti in KV/EdgeKV; il worker cerca l’URL in entrata e restituisce un 301/302 direttamente dal CDN. Fastly sostiene che l’edge sia il posto migliore per i reindirizzamenti, così possono essere serviti il più velocemente possibile. È anche una soluzione per le piattaforme che non supportano i 301 e per le enormi mappe di reindirizzamento delle migrazioni.
• Inserimento di meta tag, canonical e hreflang. Analizza in streaming <head> e inserisce ciò che il CMS non permette di impostare.
• Modifica di robots.txt. Intercetta /robots.txt e restituisce una risposta modificata o sintetica: il classico modo per superare i limiti di Shopify e Salesforce CC.
• Intestazioni X-Robots-Tag. Aggiunge o modifica le direttive di indicizzazione per file non HTML, come PDF e immagini, che non possono contenere un meta tag robots.
• Inserimento di dati strutturati (JSON-LD). Aggiunge o modifica lo schema nel corpo della risposta quando la piattaforma non lo supporta o durante un blocco delle modifiche al codice.
• Test A/B SEO nel modo corretto. Suddivide le pagine tra controllo e variante, assegnando a ogni pagina una versione vista sia da Googlebot sia da tutti gli utenti; non suddivide mai per utente. La suddivisione per pagina è sicura per Google, quella per utente è cloaking.
• Pre-rendering dei siti JavaScript, con una riserva. È possibile servire snapshot HTML pre-renderizzati dall’edge, ma farlo soltanto per i crawler equivale al rendering dinamico.
• Raccolta di log su piattaforme bloccate. Cloudflare Logpush e Workers possono acquisire dati di richiesta e risposta quando la piattaforma non espone log del server.
• Ottimizzazione del crawl budget. Elimina i parametri di tracciamento dalla risposta e reindirizza i crawler dalle varianti scarne alle versioni canoniche.

Il rischio principale: il cloaking

Questo punto deve essere inequivocabile. Le norme antispam di Google definiscono il cloaking come la presentazione di contenuti diversi agli utenti e ai motori di ricerca con l’intento di manipolare il posizionamento e ingannare gli utenti. Prova a sostegno di questa affermazione Google's spam policy defines cloaking as presenting different content to users and search engines with an intent to manipulate rankings and mislead users. Ambito: Google Search spam policy. Attendibilità: alta · Verificato: 2026-07-14 Google: Spam policies — cloaking Per esempio, inserire testo o parole chiave in una pagina soltanto quando lo user agent che effettua la richiesta è un motore di ricerca anziché un visitatore umano.

Applicato all’edge SEO, significa:

• Sicuro: inserire lo stesso tag canonical in ogni <head>; bot e utenti ricevono HTML identico.
• Non sicuro: rilevare User-Agent: Googlebot e inserire contenuti visibili al bot ma non agli utenti.
• Zona grigia: eseguire il pre-rendering dei contenuti JavaScript soltanto per i crawler; è strutturalmente identico al rendering dinamico.

Il test mentale: se un normale utente disconnesso che usa un dispositivo comune non può raggiungere gli stessi contenuti principali e link visibili a Googlebot, ti stai avvicinando al cloaking.

Per contestualizzare, John Mueller ha osservato che servire contenuti tramite un CDN equivale sostanzialmente a servirli normalmente. È comunissimo avere un CDN separato, per esempio per i video, e dal punto di vista di Google non c’è alcun problema se funziona per gli utenti e il contenuto è correttamente accessibile per l’indicizzazione. Il CDN non è il problema: lo è servire contenuti diversi ai bot.

Rendering dinamico e conseguenze per il pre-rendering all’edge. Google ha deprecato il rendering dinamico. La documentazione lo definisce ora una soluzione alternativa, non una risposta a lungo termine ai problemi posti ai motori dai contenuti generati con JavaScript, e consiglia invece rendering lato server, rendering statico o hydration. Il pre-rendering all’edge rivolto ai crawler è rendering dinamico trasferito sul CDN: non considerare quindi l’edge una soluzione duratura e pulita per un sito JavaScript. Le modifiche edge apportate all’HTML effettivo ricevuto da tutti equivalgono al rendering lato server e sono accettabili; il pre-rendering riservato ai bot porta con sé i problemi della deprecazione.

Altri rischi, compresi quelli specifici dell’edge

WAF e blocco dei bot, un rischio specifico dell’edge. Il livello di sicurezza del CDN opera prima del worker, quindi una richiesta bloccata non lo raggiunge affatto. Le regole WAF di Cloudflare e i controlli per i bot IA (la vecchia singola opzione “Block AI Bots” è stata sostituita dalle norme granulari Search/Agent/Training in “Configure AI bot policies”, anche se per alcuni account l’opzione precedente esiste ancora) possono prevalere su quanto indicato da robots.txt e bloccare crawler legittimi, Googlebot compreso, al livello di rete. Ciò coincide con le indicazioni “Crawling December” pubblicate da Google nel dicembre 2024: Google aumenta automaticamente la frequenza di scansione quando rileva un CDN, un vantaggio che può essere annullato se il CDN blocca per errore Googlebot tramite regole WAF o interstitial per i bot. Vale la pena seguire alla lettera le raccomandazioni di Google: per un’indisponibilità temporanea preferisci un vero 503/429 a un interstitial morbido di verifica dei bot (i timeout di rete vengono trattati come errori gravi e possono infine causare la rimozione dell’URL); controlla regolarmente le liste di blocco del WAF rispetto agli intervalli IP ufficiali di Googlebot e verifica i bot reali con il DNS inverso.

Singolo punto di guasto. Ora il worker si trova sul percorso di ogni richiesta. Un bug può rendere indisponibili tutte le pagine in una volta e gli ambienti edge possono essere più difficili da sottoporre a debug rispetto al codice di origine. Riduci il rischio limitando i worker a specifici pattern URL tramite il route matching, testando in staging, mantenendo un rollback con un clic e inserendo i worker nel controllo versione.

Insidie della cache. Se il CDN memorizza nella cache la risposta precedente al worker, le richieste successive possono ricevere la versione non modificata. Anche l’output del worker può essere memorizzato nella cache, rallentando la propagazione. Includi lo svuotamento della cache nel processo di distribuzione di ogni worker che inserisce contenuti.

Limiti di esecuzione. Nel piano gratuito, Cloudflare Workers limita a 10 ms il tempo CPU per richiesta HTTP; nei piani a pagamento il valore predefinito è 30 secondi e può essere configurato fino a 5 minuti. Cloudflare Snippets, lo strumento gemello più leggero, è limitato a 5 ms e 2 MB di memoria: è il limite da ricordare quando si analizzano HTML di grandi dimensioni. Analisi HTML molto estese o inefficienti possono comunque raggiungere il limite: i worker edge non sono adatti a elaborazioni pesanti.

Costi su larga scala. Il piano gratuito di Cloudflare, con 100k richieste al giorno, copre molti siti piccoli e medi, ma le aziende ad alto traffico devono confrontare il volume delle richieste con la tariffazione dei Workers.

Governance. Dan Taylor chiarisce che l’edge SEO non è pensata per aggirare le pratiche di sviluppo tradizionali e non dovrebbe escludere il team di ingegneria. Senza gestione delle modifiche, i worker entrano in conflitto con gli interventi del CMS, per esempio quando entrambi impostano la stessa intestazione, restano attivi dopo la correzione del problema sottostante e diventano shadow IT se non sono nel controllo versione. Mantieni un changelog, assegna un unico responsabile e informa gli sviluppatori di ogni distribuzione.

Alcuni miti da sfatare

• “Cloudflare danneggia la SEO.” Dan Taylor ha affrontato direttamente il tema: esistono convinzioni errate secondo cui Cloudflare e altri provider sarebbero dannosi per la SEO, ma l’esperienza non le conferma. Google aumenta persino la frequenza di scansione quando rileva un CDN. Il rischio sono le regole WAF configurate male, non il CDN in sé.
• “L’edge SEO è cloaking.” Lo è soltanto se la logica del worker serve ai bot contenuti diversi. Modifiche identiche per tutti non sono cloaking.
• “Bisogna saper programmare.” La dashboard di Cloudflare permette di gestire comuni reindirizzamenti e modifiche alle intestazioni e alle regole di sicurezza senza creare un’applicazione personalizzata.

Come si inserisce nel quadro generale

L’edge SEO tocca molti argomenti adiacenti: i problemi di SEO JavaScript e rendering che può nascondere, e che talvolta non dovrebbe; il rendering dinamico e il motivo della sua deprecazione; i reindirizzamenti che si possono servire dall’edge durante una migrazione; hreflang e canonicalizzazione che si possono inserire; le direttive robots.txt e X-Robots-Tag che si possono riscrivere. Ognuno merita un approfondimento, ma la struttura portante dell’edge SEO è sempre la stessa: modifica la risposta prima che lasci l’edge, applica ogni cambiamento a tutti e non permettere mai al worker di mostrare a Googlebot una pagina diversa da quella degli utenti.

Riepilogo IA

Una sintesi della versione avanzata:

• Edge SEO (SEO serverless) significa apportare modifiche tecniche per la SEO al livello del worker CDN/edge — reindirizzamenti, canonical, hreflang, robots.txt, X-Robots-Tag, JSON-LD e test A/B — prima che la risposta raggiunga l’utente o il crawler, senza distribuire modifiche sull’origine o sul CMS.
• Perché: superare i ritardi della coda di sviluppo, in cui le raccomandazioni SEO aspettavano storicamente circa 6 mesi, e modificare piattaforme bloccate come Shopify e Salesforce CC. Il termine è stato coniato da Dan Taylor (SALT.agency) al TechSEO Boost 2018.
• Come funziona, in 3 fasi: modifica della richiesta in entrata, come reindirizzamenti e riscritture URL → modifica delle intestazioni della risposta, come X-Robots-Tag e link canonical → modifica del corpo, con inserimento di tag, hreflang e JSON-LD tramite HTML Rewriter. La latenza è di circa 10 ms e spesso non è misurabile in produzione.
• Piattaforme: Cloudflare Workers, la soluzione più matura, e Snippets, più leggeri; Akamai EdgeWorkers, Fastly Compute, AWS Lambda@Edge e soluzioni edge Vercel/Netlify. Usa Snippets per reindirizzamenti e intestazioni e Workers per inserire HTML, grandi tabelle di reindirizzamenti e test A/B.
• La regola inderogabile, il cloaking: Google deve vedere gli stessi contenuti degli utenti. Applica le modifiche a tutti e non mostrare mai qualcosa di diverso a Googlebot. I test A/B suddivisi per pagina sono sicuri; quelli per utente sono cloaking.
• Riserva sul rendering dinamico: il pre-rendering all’edge soltanto per i bot equivale al rendering dinamico, che Google ha deprecato definendolo una soluzione alternativa, non duratura. Non è una soluzione pulita e permanente per JavaScript.
• Insidie specifiche dell’edge: i controlli WAF e per i bot IA del CDN, come le norme granulari Search/Agent/Training di Cloudflare o la vecchia opzione “Block AI Bots”, possono bloccare Googlebot in silenzio prima del worker e prevalere su robots.txt. Controlla le liste rispetto agli intervalli IP di Google e preferisci 503 agli interstitial per i bot, secondo le indicazioni CDN di Google del dicembre 2024. Quando rileva un CDN, Google aumenta la frequenza di scansione.
• Rischi operativi: singolo punto di guasto, da limitare, versionare e dotare di rollback con un clic; svuotamento della cache nella distribuzione; limiti CPU; costi su larga scala; governance. Coinvolgi gli sviluppatori e non lasciare che i worker diventino shadow IT.

Documentazione ufficiale

Documentazione proveniente da fonti primarie e direttamente pertinente all’edge SEO.

Google

• Norme antispam — Cloaking — la definizione che traccia il confine: servire contenuti diversi a utenti e motori per manipolare il posizionamento.
• Rendering dinamico (deprecato) — Google lo definisce ora “a workaround and not a long-term solution,” (traduzione): «una soluzione alternativa e non a lungo termine», e consiglia invece SSR, rendering statico o hydration. È direttamente pertinente al pre-rendering all’edge.
• Crawling December — CDN e scansione (2024) — i CDN possono aumentare la frequenza di scansione, ma anche bloccare Googlebot tramite regole WAF o per i bot; è preferibile un 503 a un blocco morbido.
• Crawling December — Cache HTTP (2024) — come le intestazioni di caching influiscono su ciò che Googlebot recupera di nuovo, un aspetto rilevante quando l’output del worker è memorizzato nella cache.
• Panoramica della serie Crawling December (2024) — l’intera raccolta di spiegazioni sulla scansione.
• Bloccare i bot IA? Elenco dei bot IA e dei crawler Google — verifica quali user agent Google consentire quando si configurano le regole per i bot del CDN.

Cloudflare / Fastly, documentazione dei provider utile per l’implementazione

• Cloudflare — Quando usare Snippets o Workers — indicazioni ufficiali sullo strumento adatto a ciascuna attività.
• Fastly — Casi d’uso SEO — un provider CDN che indica esplicitamente l’edge per reindirizzamenti e metadati.

Bing / Microsoft

• Linee guida per webmaster di Bing — Bing non offre indicazioni specifiche per l’edge, ma consiglia i CDN per le prestazioni.
• IndexNow — il complemento naturale dell’edge SEO: inviare a Bing gli URL modificati nel momento in cui si distribuisce una modifica al worker.

Citazioni dalle fonti

Dichiarazioni ufficiali pertinenti all’edge SEO. Ogni collegamento di Google è un link diretto al passaggio citato nella pagina di origine.

Google — cloaking, la condizione limite

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (traduzione): «Il cloaking è la pratica di presentare contenuti diversi agli utenti e ai motori di ricerca con l’intento di manipolare il posizionamento e ingannare gli utenti». — Google Search Central, Norme antispam. Vai alla citazione

Google — deprecazione del rendering dinamico, pertinente al pre-rendering all’edge

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (traduzione): «Il rendering dinamico era una soluzione alternativa, non una risposta a lungo termine ai problemi posti ai motori di ricerca dai contenuti generati con JavaScript». — Google Search Central, Rendering dinamico. Vai alla citazione

Dan Taylor, SALT.agency — ideatore del termine “edge SEO”

• “Edge SEO refers to the technique of implementing SEO recommendations, technical fixes, and navigating platform restrictions through using a serverless application (Cloudflare Workers) on a CDN edge server.” (traduzione): «Edge SEO indica la tecnica di implementare raccomandazioni SEO e correzioni tecniche e superare i limiti della piattaforma tramite un’applicazione serverless, Cloudflare Workers, su un server edge del CDN». — Dan Taylor, SALT.agency. Fonte
• “By using workers, like Cloudflare Workers, we can reduce the obstacles of legacy website platforms and tech stacks, congested development queues, and unhelpful developers.” (traduzione): «Usando worker come Cloudflare Workers possiamo ridurre gli ostacoli creati da piattaforme e stack web legacy, code di sviluppo congestionate e sviluppatori poco collaborativi». — Dan Taylor, SALT.agency. Fonte
• “Edge SEO isn’t designed to be a circumvention of traditional development practices.” (traduzione): «L’edge SEO non è pensata per aggirare le pratiche di sviluppo tradizionali». — Dan Taylor, SALT.agency. Fonte

SearchPilot — test A/B all’edge

• “JetStream sits on the edge without adding new layers to your web stack.” (traduzione): «JetStream si trova all’edge senza aggiungere nuovi livelli allo stack web». — SearchPilot. Fonte

Fastly — l’edge come luogo ideale per i reindirizzamenti

• “Ensuring URLs never die is one of the most important aspects of a good SEO strategy, and the edge is the best place for redirects, so that they can be served as fast as possible.” (traduzione): «Garantire che gli URL non muoiano mai è uno degli aspetti più importanti di una buona strategia SEO e l’edge è il posto migliore per i reindirizzamenti, così da servirli il più rapidamente possibile». — Fastly. Fonte

Checklist per la distribuzione e la sicurezza dell’edge SEO

Esegui questi controlli prima, durante e dopo la messa online di qualsiasi worker.

Prima della distribuzione

• Conferma che sia davvero preferibile apportare la modifica all’edge anziché alla fonte; consulta la scheda Modelli.
• Scegli tra Snippets e Workers: Snippets per reindirizzamenti e intestazioni; Workers per inserire contenuti nel corpo, gestire grandi tabelle di reindirizzamenti o eseguire test A/B.
• Scrivi il worker affinché la modifica si applichi a tutto il traffico, senza diramazioni per user agent che servano contenuti diversi ai bot.
• Limita il worker agli specifici pattern URL su cui deve intervenire tramite route matching, anziché applicarlo per impostazione predefinita all’intero sito.
• Inserisci il worker nel controllo versione e documenta che cosa fa e perché.
• Pianifica il comportamento della cache: il CDN memorizzerà la risposta precedente o successiva al worker? Aggiungi un passaggio di svuotamento della cache.
• Conferma che la pagina non sia abbastanza grande da rischiare il limite CPU o di esecuzione nei worker che riscrivono il corpo.
• Esegui test in staging e verifica l’output con lo strumento Controllo URL di GSC, che mostra ciò che Googlebot ha effettivamente ricevuto.

Sicurezza specifica dell’edge: non saltare questi controlli

• Controlla le regole WAF e di gestione dei bot del CDN; conferma che Googlebot e Bingbot non vengano bloccati prima dell’esecuzione del worker.
• Verifica che i controlli del CDN per i bot IA e le opzioni anti-bot non prevalgano su robots.txt al livello di rete; su Cloudflare si tratta delle impostazioni Search/Agent/Training di “Configure AI bot policies” o della vecchia opzione “Block AI Bots”.
• Confronta le liste di blocco WAF con gli intervalli IP di Googlebot pubblicati da Google; verifica i bot reali con il DNS inverso.
• Per un’indisponibilità temporanea intenzionale, usa un vero 503/429, non un interstitial di verifica dei bot.

Misure di protezione dal cloaking

• Stesso output canonical, hreflang, title e robots per bot e persone, verificato effettuando il fetch in entrambi i modi.
• Suddividi i test A/B per pagina, mai per utente.
• Non servire il pre-rendering all’edge soltanto ai crawler: è rendering dinamico deprecato.

Dopo il lancio

• Recupera di nuovo gli URL interessati con Controllo URL di GSC e conferma che gli elementi inseriti o modificati siano presenti.
• Conferma che la cache del CDN serva la risposta modificata, successiva al worker.
• Mantieni pronto un rollback con un clic e aggiorna il changelog.
• Informa il team di sviluppo che il worker è attivo, così non entrerà in conflitto con future modifiche al CMS e verrà ritirato quando il problema sarà corretto alla fonte.
• Se distribuisci una modifica che Bing deve rilevare rapidamente, attiva IndexNow per gli URL interessati.

I modelli mentali

1. La risposta edge è la pagina. Google vede soltanto ciò che serve il CDN e non sa che è intervenuto un worker. È la fonte della potenza dell’edge SEO e del suo rischio maggiore: considera quindi ogni output del worker la verità letterale e pubblica della pagina.

2. Edge o correzione alla fonte: la decisione. L’edge è la scelta giusta quando sei bloccato: piattaforma chiusa come Shopify o Salesforce CC, coda di sviluppo misurata in mesi, mappa di reindirizzamenti di una migrazione che nessuno distribuisce o correzione da pubblicare oggi. Correggi alla fonte quando la modifica è permanente e centrale e il team può distribuirla, perché ogni worker aggiunge un elemento al percorso critico e un altro sistema da mantenere. Regola pratica: edge per ciò che è urgente o impossibile alla fonte; origine per ciò che è permanente e centrale. Un worker che sopravvive al problema risolto è debito tecnico.

3. Applicalo a tutti, altrimenti è cloaking. La domanda di conformità non è “sto usando l’edge?”, ma “la mia logica serve gli stessi contenuti a bot e persone?”. Le modifiche identiche per tutti sono sicure; qualunque diramazione specifica per i bot supera il confine. Nel dubbio, applica il test di Google: un normale utente disconnesso può raggiungere gli stessi contenuti principali e link visibili a Googlebot?

4. Suddivisione per pagina, mai per utente. Nei test A/B SEO, assegna ogni pagina al controllo o alla variante affinché Googlebot e tutti gli utenti vedano la stessa versione di quella pagina. La suddivisione per utente, con una cosa per i bot e un’altra per le persone, è cloaking travestito da esperimento.

5. Il livello di sicurezza opera prima del worker. Una richiesta bloccata dal WAF o dalle regole per i bot del CDN non raggiunge il worker: un worker perfetto e un robots.txt perfetto sono inutili se il firewall ha già fermato Googlebot. Controlla il livello di sicurezza in ogni configurazione edge SEO, non come ripensamento.

6. Snippets o Workers: abbina lo strumento all’attività. Leggero e senza stato, per reindirizzamenti, modifiche alle intestazioni e cache → Snippets. Con stato o riscrittura dei contenuti, per inserimento nel corpo HTML, tabelle di reindirizzamenti supportate da KV e test A/B persistenti → Workers. Usare un Worker completo quando basta uno Snippet aggiunge soltanto superficie operativa.

Scheda di sintesi sull’edge SEO

Confronto tra piattaforme

Snippets o Workers di Cloudflare: scelta rapida

È cloaking?

Dati essenziali

• Il termine “edge SEO” è stato coniato da Dan Taylor (SALT.agency) al TechSEO Boost 2018.
• Latenza: in genere circa 10 ms, fino a circa 50 ms nei casi estremi; spesso nessuna variazione misurabile in produzione.
• Piano gratuito di Cloudflare Workers: 100k richieste/giorno; CPU per richiesta: 10 ms nel piano gratuito / 30 s predefiniti nei piani a pagamento, configurabili fino a 5 min. Cloudflare Snippets è limitato a 5 ms / 2 MB.
• Quando vengono rilevati, i CDN aumentano la frequenza di scansione di Googlebot, ma le regole WAF e per i bot, compresi i controlli per i bot IA, possono bloccarlo.
• Il livello di sicurezza opera prima del worker; confronta il WAF con gli intervalli IP di Google.

Risorse che meritano il tuo tempo

I miei contenuti correlati

• Guida introduttiva alla SEO tecnica — dove si inserisce l’edge SEO nel quadro generale.
• Problemi e best practice della SEO JavaScript — l’aspetto del rendering che molti cercano di risolvere all’edge.
• Perfezionare la SEO tecnica, intervista a Marketing Speak — la mia spiegazione dell’uso su larga scala di Cloudflare Workers e HTML Rewriter.

Da Dan Taylor e SALT.agency, che hanno dato il nome alla tecnica

• Edge SEO — Dan Taylor — la definizione canonica dell’ideatore del termine.
• Approfondimento sulla SEO tecnica con Cloudflare Workers — Igor Krestov e Dan Taylor di SALT.agency sul blog di Cloudflare; analisi approfondita dell’implementazione della catena di filtri.
• SEO on the Edge — riepilogo del webinar — governance, rischi e casi d’uso.

Test A/B all’edge

• Presentazione di JetStream — SearchPilot — test SEO in WASM su Cloudflare.
• Che cos’è lo split test SEO — SearchPilot — metodologia di suddivisione per pagina rispetto a quella per utente e motivo per cui la prima evita il cloaking.

Provider e fonti ufficiali

• Cloudflare — Snippets e Workers a confronto.
• Fastly — 3 modi in cui l’edge semplifica la SEO.
• Google — Crawling December: CDN e scansione.

Dal settore

• r/TechSEO — discussioni sulle implementazioni edge e sui casi limite del cloaking.
• Che cos’è l’edge SEO — Search Engine Land — panoramica solida dei principali casi d’uso e buon riferimento su come il settore inquadra l’argomento.
• Edge SEO — Dan Taylor su SEJ (2018) — l’articolo originale che presenta il concetto, scritto dall’ideatore del termine.
• Google spiega l’impatto dei CDN sulla scansione — SEJ — analisi delle indicazioni di Google del dicembre 2024 sulla scansione tramite CDN, compresi i rischi di blocco WAF e anti-bot.
• Intervista sull’edge SEO — Conductor — domande e risposte con Dan Taylor e citazioni di professionisti sul problema risolto dall’edge SEO.
• Guida completa all’edge SEO — reSignal — analisi approfondita piattaforma per piattaforma, utile per confrontare implementazioni Cloudflare, Akamai e Fastly.
• Casi d’uso di Akamai EdgeWorkers — documentazione ufficiale Akamai sui casi d’uso aziendali dei worker edge, compresi scenari SEO relativi a reindirizzamenti e metadati.

Cronologia modifiche