Rifare il sito senza perdere posizionamento: la checklist della migrazione

Mi è capitato di ereditare un sito rifatto da poco: design nuovo, veloce, pulito. E un traffico organico che dalla messa online in avanti era sceso senza più risalire. Il cliente pensava che Google dovesse «riassestarsi». Aprendo Search Console il motivo era meno misterioso: il vecchio sito aveva molte più pagine del nuovo, e nessuno dei vecchi indirizzi portava da qualche parte. Solo pagine 404.

È l'errore più comune quando si rifà un sito, e il più costoso, perché si scopre a cose fatte. Il posizionamento non sta nel design e nemmeno nel CMS: sta negli URL. Ogni indirizzo che ha vissuto qualche anno online ha accumulato link da altri siti, segnali, storico. Se lo cambi senza dire a Google dove è finito, è come traslocare senza lasciare il nuovo indirizzo: la posta continua ad arrivare alla vecchia casa e trova la porta chiusa.

Prima di disegnare una pagina, l'inventario

La migrazione comincia prima del design, quando ancora non esiste una riga del nuovo sito. La prima cosa che faccio è tirare giù l'elenco completo degli URL del sito vecchio, da più fonti, perché nessuna da sola è completa: la sitemap, un crawl con uno strumento tipo Screaming Frog, il rapporto delle pagine di Search Console, le pagine di ingresso di Analytics e le pagine che ricevono link da altri siti.

Tutto in un foglio, una riga per URL, con accanto clic e impression dell'ultimo anno e il numero di link esterni. È a questo punto che saltano fuori le sorprese: il PDF di un catalogo vecchio che si posiziona ancora, un articolo del blog di anni prima che porta una quota di traffico che nessuno in azienda sospettava, una pagina che il committente vorrebbe eliminare e che invece è tra le più visitate.

Per ogni riga si prende una decisione, e va scritta: l'URL resta uguale, viene reindirizzato a una pagina equivalente del nuovo sito, oppure si lascia morire di proposito. Anche l'ultima è una scelta legittima. Quella che non lo è mai è non decidere.

Gli URL che valgono non si toccano

Se una pagina si posiziona, il modo più sicuro per non perdere quel posizionamento è tenerle lo stesso indirizzo. Sembra ovvio, e invece ogni nuovo CMS spinge a fare il contrario: la struttura «più pulita», la sezione servizi che diventa «cosa facciamo», gli slug accorciati. Ogni cambio di URL è un rischio a fronte di un guadagno nullo. Google non premia l'indirizzo più elegante.

Quando cambiare è inevitabile, perché la piattaforma nuova impone una sua struttura o perché cambia il dominio, si fa un redirect 301 uno a uno: ogni vecchio URL verso la pagina nuova che risponde alla stessa domanda. Non verso la home. Il redirect di massa verso la home è la scorciatoia che vedo più spesso, e Google la tratta per quello che è: una pagina non trovata con un altro nome.

Un'attenzione in più per i redirect che il vecchio sito aveva già. Se A rimandava a B e ora B rimanda a C, la catena si accorcia e A va puntato direttamente a C. Le catene rallentano il crawl, e ogni passaggio è un punto in cui qualcosa può rompersi.

La mappa dei redirect è un file, non un'intenzione

La mappa è il foglio di prima ridotto a due colonne: vecchio URL, nuovo URL. Si scrive prima della messa online e si prova in staging, non dopo, con il sito in produzione e il cliente che chiama. Nella forma finale è una lista di regole per il server, per esempio in un file .htaccess:

Redirect 301 /servizi/realizzazione-siti-web/ /servizi/sviluppo-web/
Redirect 301 /chi-siamo.html /chi-siamo/
Redirect 301 /blog/2019/03/nuovo-sito-online/ /blog/nuovo-sito-online/

Dopo la messa online, ogni regola va vista funzionare. Basta una richiesta e le prime righe della risposta:

curl -sI https://esempio.it/chi-siamo.html | grep -iE "^(HTTP|location)"
HTTP/2 301
location: https://esempio.it/chi-siamo/

Se la prima riga dice 200 il redirect non c'è. Se dice 302 è temporaneo, e Google non sposta il posizionamento. Per liste lunghe questa verifica la faccio con uno script, ma il principio non cambia: ogni riga della mappa va controllata, non presunta.

C'è un'altra cosa da tenere ferma insieme agli URL: title, H1 e testo principale delle pagine che si posizionano. Rifare il design non obbliga a riscrivere tutto lo stesso giorno. Se cambi indirizzi, template e testi in una volta e il traffico cala, non sai quale dei tre l'ha causato. Dove si può, un cambiamento alla volta.

Il giorno della messa online

Il giorno della pubblicazione ha una sua lista, corta e sempre uguale, perché gli errori sono sempre gli stessi:

• il robots.txt di produzione non è quello dello staging, che di solito blocca tutto;
• nessuna pagina ha ancora il meta robots noindex ereditato dallo staging;
• i canonical puntano al dominio di produzione, non a quello di prova;
• i redirect da www e da http verso la versione unica del dominio funzionano;
• la nuova sitemap è inviata a Search Console, e quella vecchia resta raggiungibile ancora qualche settimana, così Google ripassa dai vecchi URL e trova i 301;
• i codici di tracciamento sono al loro posto, altrimenti il confronto prima/dopo non si può fare.

Il confronto, appunto. Prima della messa online scatto una fotografia delle posizioni: le query che portano traffico, con clic e impression, esportate da Search Console. Senza il «prima», ogni discussione sul «dopo» diventa una questione di sensazioni.

Le sei settimane dopo

Google non ripassa tutto in un giorno. Le settimane dopo la messa online sono il periodo in cui i problemi emergono, e in cui vale la pena aprire Search Console ogni pochi giorni. Nel rapporto sulle pagine, i «non trovata (404)» in salita sono URL sfuggiti alla mappa: si aggiungono e si ricontrolla. Le «pagine con reindirizzamento» sono invece la migrazione che funziona.

Sulle query, una flessione lieve e temporanea è normale: è il tempo che Google impiega a ricalcolare. Quella che non è normale è la sparizione di intere query. Significa che la pagina che rispondeva non ha un equivalente nel nuovo sito, o che l'equivalente dice un'altra cosa.

E i redirect non si tolgono. Né dopo sei mesi né dopo un anno, perché «ormai Google ha capito»: i link da altri siti continueranno a puntare ai vecchi indirizzi per anni. Quando un sito viene rifatto per la seconda volta, la mappa dei redirect precedente si eredita e si aggiorna, non si butta.

Cosa chiedere a chi ti rifà il sito

Secondo me il posizionamento è un patrimonio del committente, e in un preventivo di rifacimento la migrazione va scritta come voce a sé, con le sue ore. Quando rifacciamo un sito la mettiamo lì, e non alla fine come dettaglio tecnico: è la parte del lavoro che decide se il sito nuovo parte da dove era arrivato il vecchio o da zero.

Le domande da fare sono poche: c'è un inventario degli URL attuali? Esiste una mappa dei redirect, e posso vederla? Cosa guarderemo insieme nelle settimane dopo la messa online? Se chi ti rifà il sito non ti ha ancora chiesto l'accesso a Search Console, il momento di chiedere perché è adesso. Il resto è lavoro SEO ordinario, e vale più di qualunque scelta di design: il sito nuovo si vede subito, il traffico perso si vede settimane dopo.