Migrare gli URL Senza Perdere il Tuo Ranking

La migrazione che "non dovrebbe influenzare la SEO" la influenza sempre

Immagina un team che decide che `/products.php?id=4471&cat=12` debba diventare `/products/oak-dining-table`. Tutti concordano che sia un cambiamento atteso da tempo — i nuovi URL sono più puliti, più condivisibili, migliori per il redesign. Il marketing dà il via libera perché è "solo un cambio di URL, il contenuto è lo stesso". Settimane dopo il lancio, il traffico organico è crollato bruscamente e nessuno l'aveva previsto.

Questa è la perdita di ranking più evitabile in assoluto nella SEO, e succede continuamente, perché una migrazione di URL sembra una nota tecnica marginale invece di quello che è realmente: stai chiedendo a Google di trasferire anni di fiducia accumulata da un insieme di indirizzi a un altro, indirizzo per indirizzo, senza margine per il "più o meno corretto".

Fatta con disciplina, una migrazione è quasi invisibile — un breve calo che si recupera nel giro di settimane. Fatta con leggerezza, diventa un buco di traffico di più mesi che un redesign non avrebbe mai dovuto causare. La differenza sta quasi interamente in tre elementi poco affascinanti: la mappa dei redirect, i tag canonical e la sitemap. Sistema bene questi tre e il resto della migrazione è normale lavoro tecnico.

Costruisci la mappa dei redirect prima di toccare anche un solo URL

La mappa dei redirect è un foglio di calcolo, non una regola generica. Ogni vecchio URL ottiene un nuovo URL specifico. Non un pattern, non un fallback verso la homepage, non "il redirect si arrangerà" — una riga per URL, dal vecchio al nuovo, verificata da una persona.

Questo conta soprattutto proprio dove è più forte la tentazione di saltarlo: gli URL con query string. `?category=lighting&sort=price_asc&page=2` non è un singolo URL, è un'esplosione combinatoria di URL, e la maggior parte di queste varianti non ha alcun valore di ranking reale — sono rumore di crawling generato per errore dal tuo CMS. La disciplina consiste nel separarli in due gruppi:

• URL che effettivamente posizionano e generano traffico. Estraili dal report Rendimento di Search Console e dalla tua analytics, non da un export del database. Se un URL parametrizzato ha ottenuto impression e click negli ultimi 12-16 mesi, riceve un redirect esplicito, uno a uno, verso il suo equivalente pulito.
• URL che sono puro rumore. Filtri sfaccettati, ID di sessione, parametri di tracciamento, ordinamenti. Questi dovrebbero restituire un 404 o reindirizzare alla pagina di categoria più vicina — non hanno mai guadagnato un valore SEO degno di essere preservato, e mapparli singolarmente a migliaia fa perdere tempo che va speso su quelli che contano davvero.

Saltare questa selezione è il motivo per cui i team finiscono per reindirizzare tutto alla homepage (che Google tratta come un pattern da soft 404 una volta superato un certo volume) oppure per tentare un 301 su ogni combinazione di parametri mai esistita (il che gonfia la mappa dei redirect fino a renderla impossibile da mantenere o verificare).

Redirect: un solo salto, il codice giusto, nessuna eccezione

Una volta che la mappa esiste, le regole per implementarla sono semplici e non negoziabili:

• 301, non 302. Un 302 comunica ai crawler che lo spostamento è temporaneo, il che influisce su quale URL Google considera canonico e sulla velocità con cui avviene il passaggio — Google ha dichiarato che 301 e 302 trasferiscono i segnali di ranking in modo simile, quindi il vero costo di un 302 qui non è l'equity persa, ma una transizione più lenta e meno certa. Per un cambio permanente della struttura degli URL, il 301 resta il segnale corretto e inequivocabile da inviare fin dal primo giorno.
• Sempre un solo salto. A reindirizza a B, non A a B a C. Ogni salto in più nella catena diluisce il segnale, rallenta il crawling, ed è una delle cose più comuni che risultano rotte nelle migrazioni che qualcun altro ha già dichiarato "finite". Passa l'intera mappa dei redirect in un crawler come Screaming Frog prima del lancio, cercando specificamente catene e loop.
• Aggiorna anche i link interni. Un redirect corretto non giustifica lasciare la navigazione, il footer e i link nel contenuto puntati verso i vecchi URL. Ogni link interno che punta ancora a un redirect è una richiesta di crawling sprecata e un segnale leggermente più debole rispetto a un link diretto. Correggi i link; lascia che il redirect sia una rete di sicurezza, non il percorso principale.
• Mantieni i redirect attivi ben oltre il minimo indicato da Google. Le linee guida di Google stesse richiedono almeno un anno di manutenzione dei redirect dopo uno spostamento del sito. Vecchi backlink, segnalibri e link in cache non scadono secondo il tuo calendario, quindi considera un anno come una soglia minima, non un obiettivo — rimuovere i redirect esattamente a quella scadenza è un modo comune per perdere equity da link ancora in circolazione.

I tag canonical fanno una pulizia che la mappa dei redirect non può fare

I siti con query string hanno quasi sempre problemi di contenuto duplicato che la migrazione dovrebbe risolvere, non trascinarsi dietro. Se `/product?id=4471` e `/product?id=4471&ref=email` esistono entrambi, entrambi devono risolversi — dopo il redirect — nello stesso URL pulito, e quell'URL pulito deve avere un tag canonical auto-referenziale. Non lasciare che le vecchie varianti con parametri sopravvivano come pagine canonicalizzate su se stesse; questo sposta semplicemente il problema di duplicazione nella nuova struttura di URL invece di risolverlo.

Verifica questo aspetto prima del lancio, non dopo: estrai ogni URL indicizzato dal report Pagine di Search Console (sotto Indicizzazione), raggruppali in base alla destinazione pulita in cui dovrebbero confluire, e conferma che il tag canonical su quella destinazione punti a se stesso, non a un vecchio pattern preservato per errore da un template.

La sequenza della sitemap conta più di quanto si pensi

L'ordine in cui intervieni sulla sitemap cambia realmente la velocità con cui Google rielabora la migrazione:

1. Prima del lancio: verifica che la sitemap attuale rifletta fedelmente ciò che è live oggi. Una sitemap pre-migrazione non aggiornata è una brutta base di confronto in seguito.
2. Al lancio: pubblica una nuova sitemap contenente solo i nuovi URL puliti — niente URL reindirizzati, niente varianti con parametri. Inviala subito in Search Console.
3. Per 2-4 settimane dopo: mantieni accessibile (non eliminata) la vecchia sitemap, così il crawler di Google può ancora trovare ed elaborare i redirect che elenca, invece di scoprirli solo tramite un crawling incidentale più lento.
4. Dopo quella finestra: ritira la vecchia sitemap. I redirect restano attivi; smetti semplicemente di indirizzare attivamente i crawler verso la vecchia mappa una volta che ha svolto il suo scopo.

Controlla ogni giorno il report Pagine durante questa finestra, cercando conteggi crescenti di "Pagina con reindirizzamento" e conteggi stabili di "Non trovata (404)". Un picco di 404 a metà migrazione indica un buco nella mappa dei redirect, non qualcosa che Google risolverà da solo.

Come appare davvero il calo di ranking quando hai fatto tutto bene

Anche una migrazione impeccabile causa un calo reale — non è un campanello d'allarme, è Google che ricrawla e riassocia i segnali ai nuovi indirizzi. Ecco cosa mostra una migrazione sana: il ranking si ammorbidisce per qualche settimana, poi la maggior parte delle posizioni recupera, e nel giro di un paio di mesi sei a parità o meglio (URL puliti più qualsiasi altra cosa introdotta dal redesign) — anche se la tempistica esatta varia in base alla frequenza di crawling e alle dimensioni del sito. Ecco invece cosa mostra una migrazione problematica: il calo continua ad aggravarsi ben oltre il primo mese, compaiono 404 nel report Pagine, e il traffico non si è ripreso al terzo mese. Quel divario tra "calo atteso" ed "errore che costa traffico" è spiegato interamente da mappa dei redirect, audit dei canonical e sequenza della sitemap descritti sopra — raramente c'è una quarta causa misteriosa.

In sintesi

Una migrazione di URL non è una regola di redirect e una preghiera. È un foglio di calcolo che mappa ogni URL che ha guadagnato traffico verso esattamente una nuova destinazione, un audit dei canonical che chiude le lacune di contenuto duplicato che la vecchia struttura nascondeva, e una sequenza di sitemap che comunica a Google cosa è cambiato senza seppellire il segnale nel rumore. Fai queste tre cose con disciplina e il calo dura poche settimane, non parecchi trimestri. Se stai pianificando un cambio di struttura degli URL e vuoi che la mappa dei redirect venga costruita e verificata prima del lancio invece che rattoppata dopo il calo di traffico, il nostro team SEO pianifica esattamente questo tipo di migrazione prima del lancio, non dopo il calo di traffico.