Una migrazione CMS è uno dei pochi progetti in cui il lavoro tecnico può filare liscio e il risultato essere comunque un disastro. Il sito va online nei tempi previsti, è più bello, carica più in fretta, e il traffico si dimezza, perché qualche centinaio di URL ha cambiato forma e nessuno ha costruito la mappa.

La perdita non la causa la nuova piattaforma. La causa la discontinuità: indirizzi che prima rispondevano ora non rispondono più, pagine che erano riconoscibili sembrano nuove di zecca, e la storia accumulata sui vecchi URL non ha più nessun posto dove andare.

L’unica decisione che determina il risultato: mantieni la struttura degli URL? Se sì, la migrazione si riduce quasi tutta a un lavoro di contenuti e template e il rischio resta contenuto. Se no, ogni indirizzo modificato ha bisogno di un redirect verso il suo equivalente preciso, e la completezza di quella mappa decide se la migrazione sarà invisibile o costosa. Non esiste una terza via in cui gli URL cambiano e va bene lo stesso.

Che cosa rompe davvero una migrazione CMS

Gli URL, ed è il punto grosso. Piattaforme diverse hanno convenzioni diverse per percorsi, paginazione, categorie e date, e adottare le impostazioni predefinite della nuova riscrive in silenzio ogni indirizzo del sito.

I metadati. Titoli e descrizioni scritti negli anni spesso non sopravvivono a un export, e la nuova piattaforma li rigenera dai template. È facile non accorgersene, perché le pagine sembrano perfettamente a posto.

I dati strutturati. Il markup che sulla vecchia piattaforma arrivava da un plugin sparisce insieme al plugin, e gli equivalenti nuovi producono raramente lo stesso output. La nostra guida su come i motori di ricerca IA leggono lo Schema markup spiega che cosa deve sopravvivere.

I link interni. Un corpo testo pieno di link assoluti ai vecchi percorsi continuerà a puntare lì, il che dopo un cambio di URL significa che ognuno di essi passa nel migliore dei casi da un redirect.

Immagini e media. Percorsi di archiviazione diversi, nomi file diversi, e testi alternativi che vivevano nel vecchio database e nell’export non c’erano.

Tutto ciò che faceva un plugin. Redirect configurati negli anni, regole canoniche, formati dei feed e funzionalità che nessuno ha documentato perché erano una casella da spuntare.

Fai l’inventario di tutto questo prima della migrazione, non dopo. L’elenco di ciò che la vecchia piattaforma fa in silenzio al posto tuo è sempre più lungo del previsto.

La mappa dei redirect decide tutto

Se gli URL cambiano, è questo il deliverable che conta, e deve essere completo, non quasi completo.

Costruisci l’elenco di partenza da più fonti. Una scansione del sito online trova ciò che è collegato. Le analytics e la Search Console trovano pagine che ricevono traffico ma possono essere orfane. I log del server trovano ciò che viene davvero richiesto, anche da altri siti che ti linkano. Ogni singola fonte si perde qualcosa, e le pagine perse sono in modo sproporzionato quelle vecchie, quelle con i link addosso.

Associa ogni vecchio URL al suo equivalente nuovo e preciso. Non alla home e non a una pagina di categoria, perché un redirect verso qualcosa che non risponde alla richiesta originale viene trattato come errore soft e trasferisce pochissimo valore. La documentazione di Google sul trasferimento del sito descrive la corrispondenza attesa. Se davvero non corrisponde nulla, restituire una risposta di pagina non trovata è la scelta onesta ed è meglio di un redirect fuorviante.

Usa redirect permanenti, tieni le catene a un solo salto puntando i vecchi indirizzi direttamente alle destinazioni finali, e ricorda che le regole di redirect vengono valutate in ordine, quindi un pattern generico messo sopra a una regola specifica se la mangia.

Poi testa la mappa prima del lancio, sull’elenco completo e non su un campione.

Prima di passare

Scansiona e archivia il vecchio sito. Un registro completo di ogni URL con titolo, descrizione, canonical, codice di stato e conteggio parole. È la tua base di confronto, e a cose fatte non puoi più produrla.

Esporta e verifica i contenuti. Controlla i conteggi, non solo che l’export sia andato a termine. Categorie mancanti, campi personalizzati persi e articoli troncati sono tutti frequenti e tutti silenziosi.

Mettilo in staging su un ambiente bloccato. Un sito di staging che finisce indicizzato crea duplicati dell’intero sito, un problema peggiore di quello che stavi risolvendo.

Verifica che i nuovi template emettano ciò che emettevano i vecchi. Titoli, descrizioni, canonical, dati strutturati e hreflang se gestisci più lingue, come spiegato nella nostra guida al SEO multilingue.

Pianifica il momento. Non prima del periodo di punta e non di venerdì. Vuoi avere diversi giorni lavorativi di attenzione piena subito dopo.

Dopo il passaggio

Le prime quarantotto ore contano più del mese successivo, perché è la finestra in cui un errore rimediabile costa ancora poco.

Osserva i log del server in cerca di risposte di pagina non trovata. È il modo più rapido per trovare gli URL che la mappa ha saltato, e li trova da richieste reali invece che dalle tue ipotesi. Invia la nuova sitemap e controlla che la scansione stia davvero avvenendo, invece di darlo per scontato.

Confronta con la scansione di riferimento. Ogni URL che prima era indicizzabile ora deve rispondere oppure reindirizzare verso qualcosa di preciso. Quello che non fa né l’una né l’altra cosa è un buco.

Aspettati un calo. Qualche settimana di oscillazione è normale anche in una migrazione fatta bene, perché i nuovi indirizzi vanno riscansionati e rivalutati. Non è normale una discesa prolungata che non risale, e quasi sempre si riconduce a redirect saltati o puntati su qualcosa di generico.

Tieni i redirect per sempre. Non sono una misura transitoria: sono l’unica cosa che collega anni di link accumulati alle tue pagine attuali, e rimuoverli un anno dopo riproduce la perdita iniziale.

Mecanik gestisce migrazioni di questo tipo nell’ambito dei nostri servizi di sviluppo web. Lo schema si ripete: il cambio di piattaforma è routine, e tutta la differenza fra un buon esito e uno pessimo sta nella completezza della mappa.

Domande frequenti

Perché il traffico cala dopo una migrazione CMS? Quasi sempre perché gli URL sono cambiati e la mappa dei redirect era incompleta. I vecchi indirizzi smettono di rispondere, così anni di link accumulati e di storico di scansione non hanno più dove andare. La piattaforma in sé causa la perdita di rado; la causa la discontinuità fra vecchi e nuovi indirizzi.

Devo mantenere la struttura degli URL quando cambio CMS? Se puoi, sì. Mantenere la struttura riduce la migrazione a un lavoro di contenuti e template con rischio contenuto. Cambiarla significa che ogni indirizzo modificato ha bisogno di un redirect verso il suo equivalente preciso, e la completezza di quella mappatura determina se la migrazione sarà invisibile o costosa.

Dove trovo l’elenco degli URL da reindirizzare? Da più fonti, perché ognuna si perde qualcosa. Una scansione del sito online trova le pagine collegate, le analytics e la Search Console trovano pagine che ricevono traffico e possono essere orfane, e i log del server trovano ciò che viene davvero richiesto, anche da link esterni. Le pagine che una fonte singola si perde tendono a essere quelle vecchie, con i link addosso.

Posso reindirizzare le vecchie pagine alla home? No. Un redirect verso qualcosa che non risponde alla richiesta originale viene trattato come errore soft e trasferisce pochissimo valore. Associa ogni vecchio URL al suo equivalente preciso e, dove davvero non corrisponde nulla, restituire una risposta di pagina non trovata è più onesto e più utile di un redirect fuorviante.

Quanto a lungo vanno tenuti i redirect di migrazione? Per sempre. Non sono una misura transitoria ma l’unico collegamento fra anni di link in ingresso accumulati e le tue pagine attuali, quindi rimuoverli un anno dopo riproduce esattamente la perdita di traffico che la migrazione doveva evitare.