Web Design

Checklist Rifacimento Sito: 12 Cose da Sistemare

Rifare il sito senza perdere traffico: checklist in 12 punti, dai redirect 301 al monitoraggio post-lancio. L'errore che costa più caro e come evitarlo.

Foto di Alessandro Zoncada - Web Design Milano
Alessandro Zoncada
Web Designer
30 Agosto 20259 min
Checklist Rifacimento Sito: 12 Cose da Sistemare — Web Design, articolo di Alessandro Zoncada
Indice dei contenuti

L'errore che costa più caro nel rifacimento di un sito è cambiare gli indirizzi delle pagine senza impostare i redirect 301. Il sito nuovo entra online e il traffico crolla, perché ogni pagina che Google conosceva risponde "non trovata". È un danno evitabile con qualche ora di lavoro fatta prima, non dopo.

Perché i rifacimenti vanno male

Nella maggior parte dei casi il sito nuovo è oggettivamente migliore di quello vecchio: più bello, più veloce, più chiaro. Il traffico però scende, e a quel punto si dà la colpa al fornitore o a Google.

La causa quasi sempre è la stessa: il sito vecchio aveva pagine che, negli anni, avevano accumulato visite nel tempo. Se quelle pagine cambiano indirizzo senza che nessuno colleghi il vecchio al nuovo, quel patrimonio si azzera. Non è un rischio ipotetico ed è la ragione per cui la fase di preparazione conta più della fase di sviluppo.

Prima di toccare qualsiasi cosa: fotografa la situazione

  • Elenco completo degli URL attuali: senza questo non puoi sapere cosa stai perdendo
  • Quali pagine ricevono traffico, da Search Console o dalle statistiche
  • Quali pagine generano contatti: non sempre coincidono con quelle più visitate
  • Da dove arrivano i link esterni: sono le pagine su cui i redirect sono più urgenti
  • Un backup completo di file e database, verificato prima di iniziare

La checklist in 12 punti

  1. Backup completo del sito attuale, e prova che sia ripristinabile
  2. Audit dei contenuti: cosa tenere, cosa aggiornare, cosa eliminare — con criteri, non a sensazione
  3. Mappa dei redirect 301 vecchio URL → nuovo URL, una riga per ogni pagina che cambia indirizzo
  4. Nuova architettura di pagine e menu, decisa prima dello sviluppo
  5. Struttura degli heading coerente: un solo H1 per pagina, gerarchia rispettata
  6. Title e description unici per ogni pagina, entro le lunghezze utili
  7. Link interni aggiornati: se puntano ai vecchi indirizzi passano tutti da un redirect inutile
  8. Prestazioni: immagini ottimizzate, codice inutilizzato rimosso, Core Web Vitals verificati
  9. Accessibilità minima: contrasti leggibili, testi alternativi sulle immagini, navigazione da tastiera
  10. Test su dispositivi reali, non solo ridimensionando la finestra del browser
  11. Chiamate all'azione chiare e moduli testati davvero, inviando un messaggio di prova
  12. Statistiche configurate prima del lancio, così hai un termine di paragone dal primo giorno

I redirect, spiegati bene

Un redirect 301 dice al browser e ai motori di ricerca che una pagina si è spostata in modo permanente. È lo strumento che porta al nuovo indirizzo chi arrivava sul vecchio, invece di lasciarlo davanti a una pagina inesistente.

Tre regole che fanno la differenza:

  • Punta alla pagina più affine, non tutto alla homepage. Un redirect di massa verso la home viene trattato di fatto come una pagina non trovata
  • Evita le catene: pagina A che rimanda a B che rimanda a C. Aggiorna A perché punti direttamente a C
  • Usa il 301, non il 302: il secondo indica uno spostamento temporaneo e non trasferisce il valore allo stesso modo

Le pagine che davvero non hanno un equivalente vanno lasciate rispondere come "non trovate", con una pagina di errore utile che riporti l'utente verso i contenuti principali. È più corretto che inventare una destinazione a caso.

Il giorno del lancio

  • Verifica una per una che le pagine principali rispondano correttamente
  • Controlla che il certificato di sicurezza sia attivo e che non ci siano avvisi nel browser
  • Invia un messaggio di prova da ogni modulo e accertati che arrivi davvero
  • Assicurati che le pagine non siano rimaste bloccate all'indicizzazione dall'ambiente di test
  • Invia la nuova sitemap a Search Console

Quel penultimo punto merita un'insistenza: il blocco all'indicizzazione dimenticato dopo il passaggio dall'ambiente di prova a quello reale è uno degli errori più frequenti e più costosi. Il sito funziona perfettamente e semplicemente non compare su Google, a volte per settimane prima che qualcuno se ne accorga.

Le prime settimane dopo

Il monitoraggio è la parte che quasi tutti saltano, ed è quella che determina se il rifacimento è riuscito. Nelle prime quattro-sei settimane vale la pena controllare gli errori di scansione in Search Console, l'andamento delle pagine che prima portavano traffico, e i redirect che generano errori.

Un assestamento nelle prime settimane è normale: Google deve rielaborare la struttura nuova. Un calo che non recupera dopo un mese, invece, indica un problema tecnico da cercare — di solito tra i redirect.

Domande frequenti

Rifare il sito fa perdere traffico?

Può succedere se gli indirizzi cambiano senza redirect 301 verso le pagine corrispondenti. Con una mappatura fatta bene si conserva gran parte del valore accumulato, salvo un assestamento fisiologico nelle prime settimane.

Devo mantenere gli stessi indirizzi delle pagine?

Se sono già chiari e sensati, cambiarli non porta vantaggi. Se cambiarli serve davvero, va fatto mappando ogni vecchio indirizzo al nuovo con un redirect 301.

Quanto dura il calo di traffico dopo un rifacimento?

Un assestamento di qualche settimana è normale mentre i motori rielaborano la struttura. Se dopo un mese il traffico non risale, quasi sempre c'è un problema tecnico da cercare tra redirect e indicizzazione.

Posso rifare il sito mantenendo i contenuti vecchi?

Sì, ed è spesso la scelta giusta per le pagine che già funzionano. L'audit dei contenuti serve proprio a distinguere cosa vale la pena conservare da cosa è meglio riscrivere o eliminare.

Vuoi una mano?

Se preferisci non rischiare cali durante il passaggio, posso affiancarti nelle fasi critiche — mappatura dei redirect e verifiche post-lancio in particolare. Scrivimi e vediamo da dove partire.

Disclaimer: Le informazioni di questo articolo hanno finalità informative e orientative. Dati, costi e riferimenti sono indicativi e possono variare in base a settore, periodo ed esigenze specifiche del progetto. Non costituiscono consulenza personalizzata né promessa di risultati.
Logo di Alessandro Zoncada

Alessandro Zoncada

Web Designer

Web designer e sviluppatore frontend specializzato in progetti scritti su misura, senza template. Mi occupo di trasformare idee in siti web professionali, curati nel codice e nelle prestazioni.