Rifacimento del sito web: checklist per proteggere SEO e lead

Il rifacimento del sito web nasce quasi sempre come progetto di design e finisce per diventare un problema di traffico e di vendite. Il nuovo sito è più bello, poi le richieste calano: un form non invia più, una pagina che portava contatti è sparita, i vecchi indirizzi non portano da nessuna parte. Questa checklist tratta il rifacimento come un cambiamento di business, con un rischio sulla visibilità e uno sui lead, e indica chi decide cosa.

Cosa deve contenere la checklist per il rifacimento del sito web?

La checklist per il rifacimento del sito web deve coprire quattro cose: quali pagine e URL esistono oggi e cosa rende ciascuna, dove andrà ogni vecchio URL, quali form, sistemi di tracciamento e integrazioni CRM devono continuare a funzionare, e come si monitorerà il risultato dopo il lancio. La qualità del design conta, ma sono questi quattro punti a decidere se l'azienda perde terreno.

Si parte da un inventario, non da un moodboard. Si elencano tutte le pagine indicizzabili con traffico organico, link in entrata e richieste generate. Le pagine che non producono nulla si possono accorpare o eliminare con cognizione di causa. Quelle che portano richieste qualificate vanno protette, qualunque sia il nuovo layout.

Google distingue due casi. Se gli URL cambiano, vale la guida sulla migrazione di un sito con cambio di URL: costruire e testare il nuovo sito, associare a ogni vecchio URL il suo equivalente, impostare redirect lato server e monitorare vecchi e nuovi URL in Search Console, nei log del server e in analytics. Se gli URL restano uguali e cambia solo l'hosting, c'è un'altra guida, sulle migrazioni senza cambio di URL, limitata all'infrastruttura di hosting. Un restyling con gli stessi indirizzi cambia comunque template, testi e link interni, quindi va collaudato con la stessa cura di una migrazione.

Chi decide cosa in un restyling o rifacimento del sito?

Il marketing director decide le questioni commerciali: quali pagine e offerte contano, cosa si considera un lead, cosa il lancio non deve rompere e quando si può andare online. Gli sviluppatori si occupano di redirect, prestazioni, implementazione del tracciamento e integrazioni. L'agenzia cura design, struttura dei contenuti e coordinamento tra le parti. La mappa dei redirect non può essere di una persona sola, perché richiede tutti e tre i punti di vista.

Una ripartizione che funziona:

Decisione	Chi decide	Chi esegue
Pagine da tenere, accorpare o eliminare	Marketing director, con il contributo SEO	Agenzia (contenuti), sviluppatori
Struttura degli URL e mappa dei redirect	Il marketing director approva, gli sviluppatori verificano la fattibilità	Sviluppatori
Cosa è un lead e quali eventi si tracciano	Marketing director, con le vendite	Sviluppatori, responsabile analytics
Form e integrazione con il CRM	Marketing director e responsabile vendite	Sviluppatori
Data di lancio e piano di rollback	Marketing director	Sviluppatori, agenzia
Design e gerarchia dei contenuti	L'agenzia propone, il marketing director approva	Agenzia

La tabella serve a stabilire le responsabilità. Se dopo il lancio manca un redirect o un form non risponde, qualcuno deve essere stato indicato in anticipo come la persona che controlla.

Qual è la checklist prima, durante e dopo il lancio?

La checklist si divide in tre fasi: prima del lancio si fanno inventario, mappatura e collaudo; il giorno del lancio si passa al nuovo sito, si verifica e si monitora; dopo il lancio si osservano i dati di ricerca e di lead e si correggono i problemi. L'elenco numerato segue questo ordine.

1. Prima: inventario di tutte le pagine. Esportare gli URL indicizzabili con traffico, link e conversioni, per sapere cosa si sta proteggendo.
2. Prima: decidere cosa resta. Segnare ogni pagina come da tenere, da accorpare o da eliminare. Non cancellare pagine che portano richieste solo per semplificare la struttura.
3. Prima: mappare i vecchi URL sui nuovi. Ogni vecchio URL ha una destinazione diretta con contenuto coerente. Google sconsiglia di mandare molti vecchi URL su una pagina non correlata, come la nuova home, e indica che i contenuti accorpati possono puntare a un'unica nuova pagina (Google Search Central).
4. Prima: cambiare una cosa alla volta, dove si può. Google consiglia di cambiare un elemento per volta, per esempio prima il dominio e poi il layout (fonte). Se il brief chiede nuovo dominio, nuova struttura e nuovo design insieme, bisogna dire chiaramente che il rischio è più alto e pianificare più monitoraggio.
5. Prima: costruire e collaudare in un ambiente chiuso. Tenerlo fuori dall'indice durante i test e controllare pagine, immagini, form e download. Anche la guida di Google sull'hosting invita a verificare form e download e a usare noindex sull'ambiente temporaneo (fonte).
6. Prima: testare ogni form, evento e integrazione. Inviare richieste vere di prova e controllare che arrivino nel CRM o nella casella giusta con i dati di provenienza.
7. Prima: scegliere la finestra di lancio. Google consiglia, quando possibile, di fare la migrazione in un periodo di poco traffico (fonte).
8. Durante: togliere i blocchi di test. Rimuovere i tag noindex e le regole del robots.txt messi sull'ambiente di staging: è un classico errore del giorno del lancio.
9. Durante: attivare i redirect lato server. Google raccomanda redirect permanenti lato server (301 o 308) quando tecnicamente possibile e afferma che i redirect permanenti non causano perdita di PageRank (fonte). Puntare direttamente alla destinazione finale ed evitare catene lunghe.
10. Durante: inviare la nuova sitemap. Elencare i nuovi URL in una sitemap e inviarla in Search Console. Google dice che la vecchia sitemap si può rimuovere dopo l'invio della nuova; per il monitoraggio suggerisce anche una sitemap con i vecchi URL, per vederli uscire dall'indice, e precisa che gli avvisi sui loro redirect si possono ignorare (fonte).
11. Durante: ripetere i test di form e tracciamento sul sito online. Un collaudo riuscito in staging non dimostra nulla sulla produzione.
12. Dopo: monitorare vecchi e nuovi URL. Controllare Search Console, log del server e analytics, come indica Google (fonte), confrontando con i dati di partenza raccolti prima del lancio.
13. Dopo: correggere subito 404, form rotti e pagine perse. Partire dalle pagine che portavano più richieste.
14. Dopo: tenere i redirect. Google dice di mantenerli in genere per almeno un anno, e che dal punto di vista degli utenti tenerli a tempo indeterminato è altrettanto ragionevole (fonte).

Se cambia il dominio c'è un passaggio in più: lo strumento Cambio di indirizzo di Search Console. La guida di Google dice di usarlo dopo aver spostato e reindirizzato il sito, e di non usarlo per il passaggio da http a https, da www a non-www o per lo spostamento di alcune pagine nello stesso sito.

Come non perdere i lead durante un rifacimento del sito?

Per non perdere lead, ogni form, evento di tracciamento e integrazione CRM va trattato come una funzione da collaudare prima del lancio, non come un dettaglio del template. La visibilità sui motori di ricerca può recuperare nel tempo, ma un form di contatto muto fa perdere richieste dal giorno in cui si rompe, e spesso se ne accorge solo l'ufficio commerciale quando chiede dove sono finiti i contatti.

Prima del lancio conviene scrivere l'elenco di tutti i percorsi che generano un lead: moduli di contatto, richieste di preventivo, iscrizioni alla newsletter, download, link a telefono ed email, widget di prenotazione, chat. Per ciascuno si annota dove vanno i dati (casella di posta, CRM, marketing automation) e quale evento di tracciamento scatta. Poi si confronta l'elenco con la nuova versione.

Tre abitudini evitano la maggior parte dei guai. Mantenere gli stessi nomi di evento, dove possibile, così i report prima e dopo restano confrontabili. Provare con invii reali che arrivino fino al CRM, compresi i campi di fonte e campagna. E stabilire chi controlla ogni giorno il volume dei lead nelle prime settimane, con una soglia oltre la quale scatta l'allarme. Anche campagne a pagamento e link nelle email puntano a vecchie landing page: vanno aggiornati o reindirizzati prima del lancio.

Per i negozi online il ragionamento vale per le schede prodotto, dove la conversione dipende da contenuti e struttura che un restyling può appiattire facilmente. Il nostro approfondimento sulle buone pratiche per le schede prodotto e-commerce spiega cosa portarsi dietro.

Quanto ci vuole perché le posizioni si stabilizzino dopo un rifacimento?

Nessuno può indicare un tempo affidabile, e un'agenzia che promette una data per il recupero delle posizioni sta tirando a indovinare. Google scrive che le posizioni possono oscillare durante una migrazione e dovrebbero stabilizzarsi col tempo, e che per i siti di medie dimensioni possono servire alcune settimane o più perché i nuovi URL compaiano al posto dei vecchi, e di più per i siti grandi (Google Search Central).

La stessa pagina ne spiega la ragione: Googlebot deve visitare almeno una volta sia i vecchi sia i nuovi URL perché la migrazione si possa considerare conclusa, quindi un sito più grande richiede più tempo. In caso di cambio dominio, la guida di Google sul Cambio di indirizzo dice che gli effetti proseguono per 180 giorni dall'avvio della migrazione, e consiglia di tenere i redirect almeno per quel periodo e il vecchio dominio registrato per almeno un anno.

Ciò che si controlla è la qualità della mappa dei redirect, la rapidità con cui si correggono gli errori e i dati di partenza con cui confrontarsi. I tempi con cui Google elabora il cambiamento non dipendono da noi, e nessuno può promettere un risultato di posizionamento.

Quando il rifacimento completo è la scelta sbagliata?

Rifare tutto è la scelta sbagliata quando il problema è più piccolo del sito. Se il sito si posiziona e converte in modo accettabile ma un template, un tipo di pagina o l'esperienza mobile rendono poco, intervenire su quella parte costa meno e ha molto meno rischio che ricostruire l'intero sito.

Meglio diffidare del rifacimento chiesto perché il sito «sembra vecchio», perché un nuovo dirigente non lo ama o perché un concorrente ha rifatto il suo. Sono motivi per guardare meglio, non prove che una ricostruzione migliorerà le richieste. Il rifacimento è più giustificato quando la piattaforma blocca il business: il CMS non regge ciò che serve alle vendite, le integrazioni sono impossibili, la struttura non può crescere o il sito non è più gestibile in sicurezza.

Il miglioramento a piccoli passi funziona meglio in questi casi:

• Traffico e richieste sono buoni e la critica è soprattutto estetica.
• Poche pagine chiave convertono male: si testano e si riscrivono prima quelle.
• Il sito è lento o poco adatto al mobile: si sistemano le prestazioni prima di cambiare identità.
• Il team non ha tempo per monitorare dopo il lancio: un rifacimento senza monitoraggio è la versione più rischiosa.
• Il brand sta per cambiare: prima si chiude la decisione sul brand, poi si costruisce il sito una volta sola.

Un percorso graduale mantiene stabili gli URL, e questo elimina il principale rischio SEO. I template si possono sostituire uno alla volta, misurando ogni cambiamento e fermandosi se uno peggiora i risultati.

Da dove si comincia?

Si comincia dall'inventario e dall'elenco dei percorsi dei lead, poi si stabilisce con sviluppatori e agenzia chi risponde di ogni voce della checklist. Se il lavoro riguarda web design, sviluppo, e-commerce o integrazioni con CRM e gestionali, la nostra pagina su siti web, e-commerce e piattaforme digitali spiega come lavora BVG, e il Journal tratta temi collegati. Se volete ragionare su un rifacimento prima di impegnarvi, iniziamo a parlarne.

Questo articolo descrive le indicazioni pubblicate da Google nel 2026 ed è un'informazione generale, non una garanzia su alcun risultato di ricerca.