SEO AI

Migrazione del sito web senza perdere traffico: La guida di sopravvivenza SEO, GEO e AEO per il 2026

13 aprile 2026

Ogni anno migliaia di aziende decidono che è finalmente giunto il momento di abbandonare la piattaforma obsoleta. I conflitti tra plugin, le patch di sicurezza continue, il checkout macchinoso — tutto si accumula. E alla fine si decide di migrare.

Poi il traffico scompare.

Non si tratta di un caso isolato. Le ricerche mostrano che la maggior parte delle migrazioni di siti web perde silenziosamente tra il 20% e il 40% del proprio valore di ricerca organica. Uno studio su 892 migrazioni di dominio ha rilevato che il tempo medio di recupero è di 523 giorni — e il 17% di quei siti non si è mai ripreso del tutto.

Ma ecco la parte che rende il 2026 fondamentalmente diverso da qualsiasi anno precedente: non si sta più proteggendo solo il posizionamento su Google. Si sta proteggendo la visibilità su un livello di discovery completamente nuovo — i motori di ricerca AI come ChatGPT, Perplexity, Google AI Overviews e Claude. Se si perdono i dati strutturati o si rompe l'architettura dei contenuti durante una migrazione, non si scende soltanto su Google. Si scompare dalle risposte AI nel complesso.

Questa guida affronta ciò che conta davvero — dalla mappa tecnica dei redirect al layer di visibilità AI che il 95% delle guide alla migrazione ignora ancora.

Perché le migrazioni vanno storte: il problema del decadimento silenzioso

La cosa più pericolosa di una migrazione fallita non è un crollo drammatico del traffico. È il lento, invisibile dissanguamento che inizia intorno al giorno 10.

Ecco cosa accade tipicamente: le keyword branded mantengono le loro posizioni. I dashboard di analytics sembrano stabili. Tutti tirano un sospiro di sollievo. Ma sotto la superficie, le query long-tail — quelle che generano traffico ad alta intenzione e alta conversione — cominciano a erodere. Le impression calano all'interno di cluster di keyword specifici. Le pagine ricevono ancora visite, ma l'engagement diminuisce. Quando il traffico complessivo riflette il danno, la perdita di valore SEO è ormai radicata e molto più difficile da invertire.

Un caso documentato ha visto un sito e-commerce perdere il 67% del traffico in due settimane dalla migrazione a una nuova piattaforma senza redirect adeguati. Quel sito ha perso oltre 340 posizioni per le keyword principali. Il recupero parziale ha richiesto sei mesi. Un'altra software company ha perso il 44% del traffico organico post-migrazione — circa 500.000 utenti mensili.

E poi c'è la migrazione di WooCommerce verso Woo.com nel novembre 2023: un calo immediato di oltre il 90% della visibilità organica dal quale non si è mai pienamente ripresa.

Il contrasto? TransferWise ha migrato oltre un milione di pagine indicizzate verso Wise.com nel marzo 2021. Il traffico è inizialmente calato da circa 32 milioni di visite mensili a 12,9 milioni. Ma grazie a una strategia rigorosa — migrazione graduale, test pre-migrazione, pre-indicizzazione del dominio — si è ripreso in otto mesi ed è cresciuto fino a oltre 200 milioni di visite mensili. Il nuovo dominio è diventato circa 5 volte più efficace dell'originale.

La differenza non è mai la fortuna. È la preparazione.

Il contesto 2026: perché quest'anno è diverso

Tre elementi hanno cambiato il calcolo delle migrazioni nel 2026.

Il core update di Google di marzo 2026 ha alzato l'asticella. Rilasciato tra il 10 e il 22 marzo (con una seconda ondata dal 27 marzo), questo aggiornamento ha inasprito le soglie dei Core Web Vitals, rafforzato la valutazione E-E-A-T e coinciso con un aggiornamento anti-spam — generando la massima volatilità delle SERP dell'anno. I siti con debito tecnico irrisolto, contenuti sottili o scarsa esperienza mobile sono stati i più colpiti. Se si migra verso un sito che non soddisfa le nuove soglie, si migra verso una penalizzazione.

Gli AI Overviews appaiono ora in oltre il 40% delle query di ricerca. Gli stessi segnali di contenuto che Google valuta per la ricerca web determinano sempre più se i propri contenuti vengono mostrati negli AI Overviews, citati da ChatGPT o referenziati in Perplexity. Le sessioni provenienti da referral AI sono cresciute del 527% anno su anno nella prima metà del 2025, e circa il 31% della popolazione statunitense utilizza oggi la ricerca AI generativa. Perdere i dati strutturati durante una migrazione significa diventare invisibili per questo canale in rapida crescita.

Il mobile-first indexing è ora un requisito rigido. Dal luglio 2026, i siti privi di una versione mobile funzionante saranno esclusi dall'indice di Google. Una migrazione è l'ultima opportunità pulita per sistemare questo aspetto.

Fase 1: l'audit pre-migrazione

Non è possibile proteggere ciò che non si conosce. L'intera migrazione dipende da ciò che si documenta prima di toccare una singola riga di codice.

Definire la baseline delle prestazioni attuali

Esportare tutto. Questo diventa il proprio benchmark e la propria polizza assicurativa:

Inventario completo degli URL. Eseguire la scansione del sito attuale con Screaming Frog o Sitebulb. Ogni URL, ogni status code, ogni catena di redirect già in essere. Per i siti e-commerce, questo include pagine prodotto, pagine categoria, URL di filtro/navigazione sfaccettata, contenuti blog e pagine statiche — ciascuno con la propria logica di migrazione.
Snapshot di Search Console. Esportare le prime 500 keyword con click, impression, CTR e posizione media. Separare il traffico branded da quello non branded — le query branded spesso mascherano il decadimento non-brand.
Profilo dei backlink. Esportare l'intero profilo dei backlink da Ahrefs o Semrush. Le pagine con link esterni sono le più critiche da reindirizzare correttamente; il 94–95% delle pagine non ha backlink, il che rende quelle che li hanno esponenzialmente più preziose.
Audit dei dati strutturati. Effettuare la scansione di tutti gli schema markup attualmente implementati. Registrare Organization, Product, Article, FAQ e qualsiasi markup di recensione. Questi dovranno trasferirsi 1:1 sulla nuova piattaforma.
Baseline dei Core Web Vitals. Eseguire PageSpeed Insights sulle 20 principali landing page. Il nuovo sito dovrà eguagliare o superare questi numeri. La nuova soglia LCP è più stringente, e un TTFB superiore a 600ms è ora un segnale di ranking diretto.
Baseline di visibilità AI. Questo è il passaggio che nessuno compie. Interrogare ChatGPT, Perplexity e Google AI Overviews con i prompt che i propri clienti utilizzerebbero. Annotare quali pagine vengono citate. Documentarlo — è il benchmark GEO.

Effettuare l'audit del debito tecnico attuale

Eseguire un audit tecnico completo e registrare ogni errore, avvertimento e notifica. Il nuovo sito dovrebbe essere lanciato con un numero di problemi preesistenti vicino allo zero. Consegnare questa lista agli sviluppatori in modo che sappiano esattamente cosa non portare con sé. Una migrazione è l'occasione per risolvere i problemi ereditati, non per ripropaglicarli.

Fase 2: URL mapping e redirect

Questo è il nucleo tecnico di una migrazione. Farlo correttamente significa preservare l'autorità. Farlo male significa vanificare tutto il resto.

Mappare ogni URL

Creare una mappa di redirect completa — una tabella che assegna ogni vecchio URL al suo equivalente sulla nuova piattaforma. Classificare gli URL per tipo, poiché ciascuno segue una logica di mapping diversa:

Pagine prodotto
Pagine categoria/collezione
URL di filtro e navigazione sfaccettata
Pagine blog/contenuto
Pagine statiche (chi siamo, contatti, spedizioni, FAQ)
URL delle immagini

Comprendere le differenze di URL tra piattaforme

Ogni piattaforma struttura gli URL in modo diverso. È fondamentale conoscerle prima di scrivere un singolo redirect:

Magento: /catalog/product/product-name.html
Shopify: /products/product-name
WooCommerce: /product/product-name/
PrestaShop: /it/category-name/product-name.html
Headless/custom: Qualunque cosa si definisca nel proprio layer di routing

I nomi di categoria possono comparire o scomparire dagli URL prodotto a seconda della piattaforma. Slash finali, estensioni dei file, sensibilità alle maiuscole — tutti questi elementi creano disallineamenti se non mappati esplicitamente.

Regole di redirect che proteggono l'autorità

Ogni redirect deve seguire queste regole non negoziabili:

Usare 301, mai 302. I redirect temporanei non trasferiscono il link equity. Questo è l'errore di migrazione più comune in assoluto.
Nessuna catena di redirect. Se /old-url-1/ reindirizza a /intermediate-url/ che reindirizza a /new-url/, si diluiscono i segnali a ogni passaggio. Ogni redirect dovrebbe puntare direttamente alla destinazione finale.
Verificare che ogni destinazione restituisca 200. Un 301 verso un 404 non trasferisce nulla. Google ignora completamente il redirect.
Aggiornare i link interni direttamente. Non affidarsi ai redirect per la navigazione interna. Puntare tutti i link interni ai nuovi URL dal primo giorno.
Non reindirizzare tutto alla homepage. Questo viene trattato come un soft 404. Mappare ogni vecchio URL al suo equivalente più vicino: prima la corrispondenza esatta, poi contenuto simile, poi la pagina di categoria più pertinente. Il redirect alla homepage è l'ultima risorsa.

Dove implementare i redirect

La scelta influisce sulle prestazioni:

CDN/server level (Cloudflare, Fastly, Vercel): Il più veloce. Elaborato prima che il layer applicativo venga anche solo caricato. Il file _redirects di Cloudflare gestisce migliaia di regole in meno di 1ms.
Application level: Il redirect manager nativo di Shopify supporta fino a 20.000 regole (espandibile tramite API). WooCommerce utilizza plugin come Redirection. Funzionale, ma più lento.
Web server level: Blocchi di configurazione Apache .htaccess o Nginx. Funziona, ma più difficile da mantenere su larga scala.

Fase 3: preservare il SEO tecnico

I redirect sono necessari ma non sufficienti. Il nuovo sito deve trasferire ogni segnale che i motori di ricerca e i sistemi AI utilizzano per comprendere i contenuti.

Cosa deve trasferirsi 1:1

Meta title e description. Questi non si trasferiscono sempre automaticamente tra piattaforme. Verificare manualmente ogni pagina prioritaria.
Gerarchia degli heading. Preservare la struttura H1, H2, H3. Non permettere che un redesign appiattisca l'architettura dei contenuti.
Schema markup. Migrare tutti i dati strutturati — Product, Organization, Article, FAQ, Review, BreadcrumbList. Nel 2026 i dati strutturati hanno un duplice scopo: aiutano Google e aiutano i sistemi AI a comprendere i contenuti per le citazioni.
Architettura dei link interni. Preservare il flusso di link equity. I link interni interrotti creano pagine orfane e diluiscono il PageRank.
Testo alternativo delle immagini. Spesso perso durante la migrazione. Verificare che sia trasferito, soprattutto per le immagini dei prodotti e-commerce.
Tag canonical. Assicurarsi che puntino ai corretti nuovi URL, non a percorsi residui del vecchio sito.
Tag hreflang. Se si servono più lingue o regioni, ogni versione necessita di un mapping di redirect separato e della verifica degli hreflang.

Prestazioni: eguagliare o migliorare

La nuova piattaforma deve eguagliare o superare la velocità del vecchio sito. L'aggiornamento di Google di marzo 2026 ha inasprito le soglie dei CWV. Le ricerche mostrano che il 53% degli utenti mobile abbandona una pagina che impiega più di 3 secondi a caricarsi, e 2 secondi aggiuntivi possono aumentare il bounce rate di oltre il 100%.

Effettuare il benchmark prima della migrazione. Ripeterlo dopo. Se le prestazioni peggiorano, si perderanno posizioni anche con redirect perfetti.

Fase 4: il layer GEO/AEO — ciò che tutti gli altri tralasciano

È qui che la guida alla migrazione 2026 diverge da ogni checklist scritta in precedenza.

Le guide tradizionali alla migrazione assumono che si stia proteggendo solo il posizionamento su Google. In realtà si sta anche proteggendo la visibilità su motori di risposta AI che citano, sintetizzano e raccomandano contenuti in modi che le metriche SEO tradizionali non catturano.

Come i motori AI scoprono e citano i contenuti

Le piattaforme di ricerca AI non funzionano come Google. Quando qualcuno pone una domanda a ChatGPT o Perplexity, il sistema la scompone in sotto-query ("fan-out queries"), effettua una ricerca per ciascuna, recupera i contenuti rilevanti, valuta l'autorità delle fonti e sintetizza una risposta — citando le fonti di cui si fida maggiormente.

Durante una migrazione, si rischia di perdere la fiducia dei sistemi AI se:

Contenuti precedentemente citati vengono rimossi, fusi o spostati senza preservarne l'identità
I dati strutturati che l'AI utilizza per il contesto scompaiono
Il robots.txt o il CDN (in particolare Cloudflare) inizia a bloccare i crawler AI sul nuovo sito
I contenuti passano da server-side rendered a JavaScript client-side che i crawler AI non riescono a interpretare

La checklist per i crawler AI

Prima di lanciare il nuovo sito, verificare:

Il robots.txt consente l'accesso ai crawler AI. Controllare di non stare bloccando GPTBot, PerplexityBot, ClaudeBot o Google-Extended. Molte piattaforme e CDN li bloccano per impostazione predefinita. Cloudflare ha recentemente modificato il suo default per bloccare i bot AI — se si usa Cloudflare, verificarlo esplicitamente.
I contenuti sono server-side rendered. I crawler AI non eseguono JavaScript come fanno i browser. Se il nuovo sito headless rende tutto client-side, i contenuti sono invisibili ai sistemi AI. Utilizzare SSR o generazione statica per tutte le pagine indicizzabili.
I contenuti non sono nascosti dietro interazioni. Tab, accordion e dropdown che richiedono clic per rivelare il contenuto sono invisibili ai crawler AI. Se contenuti importanti si trovano in elementi richiudibili, è necessario ristrutturarli.
Considerare l'implementazione di llms.txt. Si tratta di un file di testo semplice collocato nella root del sito che fornisce ai sistemi AI una mappa strutturata delle pagine più importanti. È ancora presto — solo il 5–15% dei siti lo utilizza e i principali provider AI non si sono ancora pienamente impegnati a rispettarlo. Ma è a basso rischio, basso costo e posiziona avanti rispetto alla concorrenza. Pensarlo come una sitemap progettata specificamente per i modelli linguistici.
Lo schema markup è intatto e migliorato. I sistemi AI ponderano fortemente i dati strutturati per determinare cosa citare. Gli schema FAQ, HowTo, Product e Review influenzano direttamente se i propri contenuti appaiono nelle risposte AI.

Struttura dei contenuti per le citazioni AI

I motori AI estraggono singoli frammenti, non pagine intere. Strutturare i contenuti in modo che ogni sezione sia autonoma come risposta citabile:

Iniziare ogni sezione con una risposta diretta prima di fornire il contesto
Utilizzare heading H2/H3 chiari che corrispondano al modo in cui gli utenti formulano le domande
Mantenere i paragrafi a 2–3 frasi
Includere dati specifici, statistiche e fonti nominative — i sistemi AI privilegiano contenuti con affermazioni concrete rispetto alle generalità
Mantenere nomi di entità coerenti (il proprio brand, i prodotti, le persone) — i sistemi AI costruiscono grafi di entità da questi pattern

Misurare la visibilità AI dopo la migrazione

Post-lancio, aggiungere queste misurazioni allo stack di monitoraggio accanto alle metriche SEO tradizionali:

Citation tracking. Interrogare le piattaforme AI settimanalmente con i propri prompt target. Si è ancora citati? Un competitor ha preso il posto?
Traffico da referral AI. Controllare in analytics il traffico da ChatGPT (registrato come referrer chatgpt.com), Perplexity e altre fonti AI. Queste sessioni convertono a tassi superiori alla media del traffico organico — i referral da ChatGPT convertono a circa il 15,9%.
Attività dei crawler AI. Controllare i log del server per gli user agent GPTBot, ClaudeBot, PerplexityBot. Se spariscono post-migrazione, qualcosa li sta bloccando.

Fase 5: test pre-lancio

Individuare i problemi prima del lancio, non dopo.

Protocollo dell'ambiente di staging

Configurare un sito di staging che rispecchi l'ambiente di produzione, ma assicurarsi che i motori di ricerca non possano indicizzarlo. Un sito di staging che appare nei risultati di ricerca crea problemi massicci di contenuto duplicato.

Testare tutti i redirect in staging prima di andare live
Effettuare la scansione del sito di staging con Screaming Frog — cercare link interrotti, metadati mancanti, pagine orfane e catene di redirect
Verificare che il robots.txt consenta la scansione in produzione ma la blocchi in staging
Confermare che la sitemap XML si generi correttamente con tutti i nuovi URL
Testare i Core Web Vitals rispetto ai propri benchmark
Verificare che tutti gli schema markup siano validi (utilizzare il Google's Schema Validator)
Controllare gli errori 404 su tutti i tipi di pagina
Testare su dispositivi mobile reali, non solo anteprime responsive

Fase 6: il giorno del lancio

Quando si preme l'interruttore, ogni minuto conta.

La checklist di lancio

Distribuire tutti i redirect simultaneamente con il nuovo sito
Aggiornare i link interni in modo che puntino ai nuovi URL
Inviare la nuova sitemap XML a Google Search Console
Aggiornare il tracciamento Google Analytics/GA4
In caso di cambio di dominio, aggiornare l'indirizzo della proprietà in Search Console
Monitorare i log del server in tempo reale per gli errori
Verificare che i redirect funzionino in produzione (testare un campione di URL prioritari)
Assicurarsi che il robots.txt sul sito live consenta l'accesso a tutti i crawler previsti — sia tradizionali che AI

Fase 7: monitoraggio post-lancio

I 90 giorni successivi al lancio determinano se ci si riprende o si declina.

Settimana 1 (critica)

Monitorare Search Console quotidianamente per gli errori di crawl
Verificare la copertura dei redirect — tutti i vecchi URL si risolvono ai nuovi?
Tracciare e correggere gli errori 404 immediatamente
Controllare lo stato di indicizzazione delle pagine prioritarie
Monitorare il traffico organico quotidianamente, con segmenti branded e non-branded separati

Settimane 2–8

Tracciare le variazioni di posizionamento per i cluster di keyword target
Monitorare i trend del traffico rispetto alla baseline pre-migrazione
Correggere eventuali link interni o esterni interrotti
Aggiornare le sitemap XML se vengono aggiunte nuove pagine
Inviare nuovamente le pagine importanti per l'indicizzazione se tardano ad apparire
Documentare la timeline di recupero — questi dati sono preziosi per la pianificazione futura

Continuativo

Continuare a monitorare la visibilità AI mensilmente
Aggiornare i contenuti trimestralmente per mantenere i segnali di freschezza (i motori AI ponderano fortemente la recency)
Mantenere attive le regole di redirect per almeno 12 mesi — rimuoverle troppo presto causa la riemergenza di 404 man mano che i link in cache scadono

Percorsi di migrazione comuni: considerazioni specifiche per piattaforma

PrestaShop → Shopify (o Medusa)

PrestaShop utilizza URL inclusivi del nome di categoria (/it/category/product.html), mentre Shopify appiattisce a /products/product-name. Ogni URL di prodotto cambia. Pianificare una mappa di redirect su larga scala. La struttura URL multilingua di PrestaShop richiede inoltre un mapping di redirect separato per ogni lingua.

Magento → Shopify

La migrazione comune più complessa. Magento utilizza /catalog/product/product-name.html rispetto a /products/product-name di Shopify. Le aziende enterprise spesso hanno migliaia di URL di filtro che necessitano di gestione esplicita. Valutare Shopify Plus con un headless CMS (come Contentful o Strapi) se si dispone di pagine di contenuto estese che generano traffico organico — il blogging nativo di Shopify è funzionale ma limitato per strategie di contenuto SEO intensive.

WordPress → Headless (Next.js, Webflow, Astro)

Il rischio principale qui è il rendering. WordPress consegna HTML server-rendered per impostazione predefinita. Molti framework headless eseguono il rendering client-side, il che interrompe sia l'accesso di Google che quello dei crawler AI. Se si passa a headless, assicurarsi che SSR o la generazione statica siano implementati per tutte le pagine di contenuto. Verificare inoltre che i plugin che gestiscono redirect, schema e generazione di sitemap abbiano equivalenti nel nuovo stack.

Bitrix/1C → stack moderno

Comune nel mercato CIS. Le sfide principali sono la migrazione dei dati da integrazioni ERP strettamente accoppiate e la preservazione delle strutture URL in cirillico. Pianificare test estensivi della codifica dei caratteri nei redirect.

Qualsiasi piattaforma → qualsiasi piattaforma

Indipendentemente dal percorso di migrazione specifico, i principi sono universali: mappare ogni URL, reindirizzare correttamente, preservare i dati strutturati, verificare l'accesso dei crawler AI e monitorare intensamente post-lancio.

La matrice decisionale per la migrazione

Non ogni sito ha bisogno di una ricostruzione completa. Prima di impegnarsi, valutare onestamente la situazione:

Migrare quando: La piattaforma attuale ha limitazioni tecniche irrisolvibili, le vulnerabilità di sicurezza non possono essere corrette, la piattaforma si sta avvicinando alla fine del ciclo di vita, oppure si spende più del 40% delle risorse di sviluppo in manutenzione anziché in crescita.

Riprogettare invece quando: I problemi sono principalmente estetici o legati alla UX. Un redesign sulla stessa piattaforma comporta una frazione del rischio SEO.

Fare entrambe le cose — con cautela: Se è necessario cambiare piattaforma e riprogettare, non fare tutto insieme. L'ideale è migrare prima con modifiche di design minime, stabilizzare il posizionamento, poi iterare sul design. Cambiare piattaforma, struttura URL, contenuti e design simultaneamente moltiplica ogni rischio.

In sintesi

Una migrazione del sito web fatta correttamente non si limita a preservare il traffico — può essere il catalizzatore per una crescita esponenziale. Wise lo ha dimostrato. Ma una migrazione fatta con superficialità può farLa regredire di mesi o anni.

Nel 2026 la posta in gioco è più alta che mai. Non si sta migrando solo un sito web. Si sta migrando la propria presenza in un intero ecosistema di ricerca — tradizionale, AI-generativa, vocale e agentica. Ogni redirect mancato, ogni dato strutturato perso, ogni crawler AI accidentalmente bloccato è una perdita cumulativa su tutte queste superfici.

Pianificare come se avesse importanza. Perché ce l'ha.

Se sta pianificando una migrazione — o sta recuperando da una andata storta — è esattamente la conversazione che facciamo ogni settimana su areza.digital. Eseguiamo audit pre-migrazione che coprono SEO, GEO e AEO in modo che non si sopravviva semplicemente al cambio di piattaforma, ma si esca più forti. Prenota una chiamata conoscitiva di 30 minuti →

Scritto da Nikita Janochkin, fondatore di areza.digital — consulenza SEO, AEO e GEO per aziende che navigano le migrazioni di piattaforma. Ultimo aggiornamento 13 aprile 2026.

Smetti di perdere lead a causa di un sito lento

Prenota un audit di attrito gratuito e scopri esattamente dove il tuo sito perde denaro.

Prenota una chiamata →