La risposta breve
Un sito mantiene i propri posizionamenti dopo una migrazione quando ogni URL che porta traffico o link continua a rispondere dopo il lancio: lo stesso contenuto allo stesso indirizzo, oppure un redirect permanente lato server verso l'equivalente più vicino. La maggior parte dei problemi di migrazione nasce da un URL che nessuno ha inserito nell'elenco.
La guida di Google ai trasferimenti di sito con cambio di URL fissa le basi: associare ogni vecchio URL a uno nuovo, usare redirect permanenti lato server come 301 o 308, mantenerli "generalmente per almeno 1 anno" e "aspettarsi fluttuazioni temporanee nel posizionamento del sito durante il trasferimento".
La stessa guida consiglia di cambiare una cosa alla volta: prima il nuovo dominio, poi il nuovo layout. La documentazione di Google sul cambio di indirizzo è ancora più netta: se unisci il trasferimento a una riprogettazione dei contenuti e della struttura degli URL, "probabilmente vedrai una perdita di traffico" mentre Google rivaluta ogni pagina. Se servono entrambi, pianifica il redesign come fase a sé.
Tre tipi di migrazione
| Migrazione | Cosa cambia | Redirect | Search Console |
|---|---|---|---|
| Solo hosting | Server o CDN; tutti gli URL restano uguali | Nessuno | Monitorare scansione e indicizzazione |
| Piattaforma (da Wix a WordPress, da WordPress ad Astro) | CMS, template e di solito alcuni schemi di URL | Ogni URL il cui percorso cambia | Nuova sitemap, poi monitoraggio |
| Dominio o sottodominio | Ogni URL | Tutti | Cambio di indirizzo per ogni variante verificata |
Per una migrazione solo di hosting, la guida di Google sull'hosting consiglia di abbassare il TTL del DNS "almeno una settimana prima del trasferimento" e di tenere attivi i vecchi server finché il loro traffico non arriva a zero. Un breve calo della frequenza di scansione dopo il lancio è normale.
Prima della migrazione: elenca tutto ciò che ha un URL
La mappa dei redirect vale quanto l'elenco dei vecchi URL su cui si basa, e ogni fonte dimentica qualcosa.
Scansiona il sito attivo
Scansiona il sito attuale ed esporta ogni URL con codice di stato, title, meta description, tag canonical e hreflang, poi aggiungi tutti gli URL della sitemap XML. Google suggerisce inoltre di controllare i log del server per trovare gli URL visitati almeno una volta di recente.
Recupera le landing page da Search Console e dagli analytics
Nel rapporto Rendimento di Search Console esporta la scheda Pagine con l'intervallo di date più lungo, e fai lo stesso per le landing page organiche negli analytics. Queste pagine portano traffico e contatti, quindi ciascuna va controllata a mano al lancio.
Individua chi ti linka
Il rapporto Link mostra le pagine più linkate, ma le sue tabelle "sono limitate a 1.000 righe" e Google precisa che non è un elenco completo. Combinalo con qualsiasi strumento per i backlink che usi.
Elenca moduli, integrazioni e file multimediali
Annota ogni modulo e la destinazione dei suoi invii, ogni strumento incorporato (prenotazioni, chat, mappe, pagamenti) e ogni file linkato direttamente. La guida di Google dice di includere nel piano "video, immagini, file JavaScript e CSS", perché questi URL si spostano come qualsiasi altro contenuto.
Costruisci la mappa dei redirect
Una riga per ogni vecchio URL: vecchio URL, nuovo URL, codice di stato, note, testato. Quattro regole:
- Associa ogni vecchio URL al suo equivalente più vicino. Reindirizzare molti vecchi URL verso un'unica destinazione non pertinente, come la home page, "potrebbe essere trattato come un errore soft 404".
- Se più pagine vecchie sono state unite in una sola, reindirizzale tutte verso di essa.
- Se una pagina non ha un equivalente, fai restituire un 404 o un 410, non un redirect.
- Mantieni invariati i percorsi ovunque la nuova piattaforma lo consenta.
Durante lo sviluppo: i redirect e ciò che li accompagna
Usa redirect 301 o 308 lato server, uno a uno
La documentazione di Google sui redirect spiega che 301 e 308 indicano che "la destinazione del redirect dovrebbe essere canonica" e raccomanda "un redirect permanente lato server, quando possibile". I codici temporanei (302, 303, 307) non lo indicano, e i redirect JavaScript sono l'ultima risorsa.
Reindirizza direttamente all'URL finale. I crawler di Google seguono fino a 10 passaggi di redirect, ma la guida al trasferimento di sito consiglia di "reindirizzare direttamente alla destinazione finale". Se una migrazione precedente ha lasciato dei redirect, fai puntare anche quelli ai nuovi URL finali.
Controlla il codice di stato predefinito di ciò che gestisce i tuoi redirect. Su Cloudflare Workers, dove Dardo ospita i siti che realizza, un file _redirects usa il 302 a meno che non scrivi 301 su ogni riga, supporta fino a 2.000 redirect statici e 100 dinamici e non può corrispondere ai parametri di query. I permalink semplici di WordPress (/?p=123) richiedono quindi una logica di redirect nel codice del Worker.
Quando restituire invece un 404 o un 410
Pagine povere di contenuto, offerte scadute e duplicati non devono sopravvivere. La guida di Google dice che i contenuti che non sposti dovrebbero "restituire correttamente un HTTP 404 o 410", e i crawler di Google trattano allo stesso modo ogni codice 4xx tranne il 429: l'URL esce dall'indice.
Porta con te metadati, canonical e hreflang
- Title e meta description. Migrali campo per campo invece di lasciare che siano i nuovi template a generarli.
- Canonical. Ogni nuova pagina ha un canonical autoreferenziale con il suo nuovo URL. La guida di Google alla canonicalizzazione definisce il canonical "un suggerimento, non una regola", quindi canonical, redirect e sitemap devono essere coerenti.
- Hreflang. Secondo la guida di Google alle versioni localizzate, ogni versione linguistica "deve elencare sia se stessa sia tutte le altre versioni linguistiche" e "se due pagine non puntano l'una all'altra, i tag verranno ignorati". Aggiorna ogni annotazione con i nuovi URL.
Dati strutturati, link interni e URL delle immagini
- Dati strutturati. Ricostruisci i markup Organization, Breadcrumb, Article o Product nei nuovi template e testali con il Test dei risultati multimediali. La guida di Google al trasferimento non ne parla, quindi si perdono facilmente.
- Link interni. Fai puntare i link ai nuovi URL, non ai redirect.
- Immagini e file. Mantieni nomi dei file e testi alternativi descrittivi, e reindirizza i vecchi URL di immagini e PDF che ricevono link o traffico dalla ricerca per immagini.
Analytics e consenso
Reinstalla analytics, eventi di conversione e pixel pubblicitari e testali in staging. Se il vecchio sito chiedeva il consenso ai cookie, il nuovo deve chiederlo allo stesso modo prima che quei tag vengano attivati.
Cosa si rompe di solito, piattaforma per piattaforma
Queste note derivano dalla documentazione ufficiale di ciascuna piattaforma a ottobre 2026. Descrivono come funzionano le piattaforme, non difetti.
| Piattaforma | Schemi di URL da mappare | Limiti di esportazione e redirect |
|---|---|---|
| WordPress | I permalink possono essere semplici (/?p=N), basati sulla data o sul nome dell'articolo. Gli archivi di categorie e tag mantengono sempre una base come /category/. | Da WordPress 6.4 le pagine degli allegati sono disattivate nelle nuove installazioni, ma restano attive nei siti aggiornati, quindi i siti più vecchi possono avere un URL per ogni file caricato. |
| Webflow | Gli elementi del CMS risiedono nelle pagine Collection. | L'esportazione del codice esclude contenuti CMS, Ecommerce, User Accounts, gestione dei moduli, ricerca interna e pagine localizzate, e richiede un piano Workspace. Le collezioni si esportano separatamente in CSV. |
| Wix | Gli articoli del blog si trovano sotto un prefisso /post/ che può essere rinominato ma non rimosso. Su WordPress, una struttura di permalink personalizzata come /post/%postname%/ li mantiene. | Un sito Wix "deve funzionare sui server di Wix", quindi lasciare Wix significa ricostruire le pagine. |
| Framer | Modificare un sotto-percorso non aggiorna le regole di redirect esistenti, quindi le vecchie regole possono puntare a percorsi inesistenti. | I siti vengono pubblicati come HTML, CSS e JavaScript standard; i contenuti del CMS si esportano tramite plugin in CSV o JSON. |
| Squarespace | Le mappature degli URL accettano una variabile [name] per intere collezioni, come /blog/[name] -> /posts/[name] 301. | L'esportazione è un XML di WordPress con una pagina blog, pagine di layout e gallerie, ma senza pagine del negozio, blocchi prodotto, video o audio, né CSS personalizzato. Le mappature degli URL non possono reindirizzare URL di immagini o file e contengono circa 2.500 righe. |
| Shopify | Gli URL della vetrina si trovano sotto percorsi come /products/, /collections/, /pages/ e /blogs/<blog>/; Shopify considera fissi /products e /collections. | I redirect funzionano solo da URL che non caricano più una pagina, e i negozi ne ottengono al massimo 100.000 (20.000.000 su Plus). |
Lasciare Wix significa ricostruire ogni pagina; lasciare Squarespace significa importare ciò che l'esportazione copre e ricostruire il resto. Passare a Shopify di solito cambia gli URL dei prodotti, quindi la mappa deve coprire ogni prodotto.
Il giorno del lancio
- DNS. Se cambiano hosting o DNS, abbassa il TTL almeno una settimana prima.
- Blocchi alla scansione. Rimuovi i tag
noindexdi staging e i blocchi nel robots.txt. Google consiglia di elencare tutti gli URL in cui hai usatonoindexdurante lo sviluppo. - Redirect. Pubblicali nello stesso rilascio del nuovo sito.
- Test dei redirect. Passa l'intera mappa in uno script: ogni vecchio URL deve restituire 301 o 308 verso l'URL finale corretto in un solo passaggio, e quell'URL deve restituire 200.
- Search Console. Verifica il nuovo sito e invia la nuova sitemap, più una sitemap dei vecchi URL perché vengano ricsottoposti a scansione. Gli avvisi che indicano che quegli URL vengono reindirizzati sono previsti.
- Cambio di indirizzo. In caso di cambio di dominio, invialo da una proprietà che possiedi su entrambi i lati con lo stesso account Google, per ogni variante del vecchio dominio, incluse quelle con e senza www.
- Percorsi che fanno incassare. Invia un vero modulo, esegui un pagamento di prova e verifica che gli eventi di analytics arrivino.
- I tuoi link. Aggiorna profili social, annunci e schede nelle directory.
I 30, 60 e 90 giorni dopo
Giorni 1-30: aspettati oscillazioni
Le posizioni possono oscillare "mentre Google esegue di nuovo la scansione e l'indicizzazione del sito", e "per un sito di piccole o medie dimensioni possono volerci alcune settimane perché la maggior parte delle pagine si assesti, mentre i siti più grandi richiedono più tempo". Tieni d'occhio:
- Report su indicizzazione e sitemap. Gli URL indicizzati calano sul vecchio sito e salgono sul nuovo.
- Rendimento per pagina. I nuovi URL iniziano a ottenere impressioni e clic.
- Log del server e 404. Ogni 404 inatteso è una riga mancante nella mappa. Controlla ogni giorno per due settimane.
Giorni 31-60: confronta con la baseline
Confronta le tue principali landing page con i nuovi URL. Per ogni pagina che ha perso clic, verifica in ordine: il redirect raggiunge la pagina giusta in un solo passaggio, sono cambiati contenuto o titolo, i link interni puntano ancora a quella pagina, è presente nella sitemap. Poi chiedi ai siti dei tuoi backlink più preziosi di aggiornarli.
Dal giorno 90 in poi: mantieni i redirect
La guida di Google dice di mantenere i redirect "in genere per almeno 1 anno" e, dal punto di vista degli utenti, di "valutare di mantenerli a tempo indeterminato". Per i cambi di dominio, la pagina sul cambio di indirizzo fissa un minimo di 180 giorni, dopo i quali Google considera il vecchio sito non correlato se è ancora scansionabile. Raccomanda anche di pagare il vecchio dominio "per almeno un anno" così che nessun altro possa acquistarlo.
La checklist
| Fase | Attività | Completata quando |
|---|---|---|
| Prima | Scansiona sito, sitemap e log del server | Un unico elenco di tutti i vecchi URL con il relativo codice di stato |
| Prima | Esporta landing page e pagine con più link | Pagine principali e destinazioni dei backlink segnalate nella mappa |
| Prima | Elenca moduli, integrazioni, script e file | Ognuno ha un responsabile e un piano sul nuovo sito |
| Prima | Crea la mappa dei redirect | Ogni vecchio URL ha una destinazione o una decisione 404/410 |
| Sviluppo | Redirect 301 o 308 lato server | Un solo passaggio, nessuna catena, nessun redirect di massa verso la home page |
| Sviluppo | Title, description, canonical, hreflang | Corrispondono alle vecchie pagine; canonical e hreflang usano i nuovi URL |
| Sviluppo | Dati strutturati, link interni, URL delle immagini | Il Test dei risultati multimediali passa; nessun link interno punta a un redirect |
| Sviluppo | Analytics, conversioni e consenso | Gli eventi scattano in staging, solo dopo il consenso dove richiesto |
| Lancio | Rimuovi noindex e blocchi nel robots.txt | I nuovi URL sono scansionabili |
| Lancio | Testa la mappa dei redirect | Ogni riga restituisce il codice e la destinazione previsti |
| Lancio | Search Console: verifica, sitemap, cambio di indirizzo | Inviati senza errori critici |
| Dopo | Monitora indicizzazione, 404 e rendimento | I vecchi URL calano, i nuovi ottengono impressioni |
| Dopo | Mantieni i redirect e il vecchio dominio | Almeno un anno |
Come farsi aiutare con una migrazione
Dardo porta i siti su build Astro su misura ospitate su Cloudflare Workers, e la mappa dei redirect è un deliverable che testiamo prima del lancio e consegniamo insieme al sito. Scopri la migrazione del sito web, oppure il restyling del sito web se il passaggio richiede anche un nuovo design. Oppure raccontaci cosa vuoi migrare.