Cosa trovi in questa pagina

Cosa succede a Google

Perché cambiare sito può far calare temporaneamente le posizioni – e perché è normale.

Come funzionano i redirect 301

La meccanica passo per passo: dal mapping degli URL alla Search Console.

Checklist pre e post lancio

Le operazioni concrete da fare prima di andare online e nei giorni successivi.

Cosa monitorare dopo

Tempi reali, segnali da tenere d'occhio, quando preoccuparsi (e quando no).

Perché Google «perde» il tuo sito quando lo sposti

Quando cambi piattaforma, URL o struttura, Google si trova davanti a pagine che non ha mai visto.

Il vecchio URL esisteva, aveva un peso, forse compariva in prima pagina. Il nuovo URL è un'entità nuova. Googlebot deve trovarlo, scansionarlo, capire che è lo stesso contenuto di prima – e poi ricalcolare il peso.

Questo processo richiede tempo. Di solito 2–4 settimane per i siti piccoli, 4–8 settimane per quelli più grandi. In quel lasso di tempo, le posizioni possono calare.

Un esempio tipico: un'impresa edile di Pordenone rifà il sito. La terza settimana dopo il lancio le visite da Google si dimezzano. Il titolare chiama in panico. Tre settimane dopo sono tornate dove stavano – e nel giro di due mesi avevano superato i valori precedenti.

Non è un'anomalia. È la meccanica normale del ricrawl.

Il problema nasce quando la migrazione è fatta male: redirect mancanti, pagine 404, noindex rimasto attivo per sbaglio. Lì il calo non è temporaneo. Diventa permanente.

Per questo la migrazione si prepara, non si improvvisa. Perché su un sito vecchio la SEO e il posizionamento locale non partono.

Come si fa una migrazione corretta: i passi

Non è complicato, ma va fatto nell'ordine giusto.

  • 01. Esporta tutti gli URL del vecchio sito

    Scarica l'elenco completo da Google Search Console (Sitemaps → URL ispezionati) o con Screaming Frog. Ogni URL che Google conosce va mappato. Nessuno escluso.

  • 02. Crea il mapping: vecchio URL → nuovo URL

    Un documento semplice, anche un foglio di calcolo. Per ogni vecchio indirizzo, scrivi dove deve andare quello nuovo. Le pagine con posizioni in top 30 sono priorità assoluta.

  • 03. Configura i redirect 301 sul server

    Solo a livello server: .htaccess per Apache, nginx.conf per Nginx. Mai via JavaScript, mai meta refresh. I redirect a catena (A→B→C) vanno eliminati: ogni hop fa perdere una parte del peso. L'obiettivo è un salto diretto.

  • 04. Prepara il nuovo sito prima del lancio

    Canonical corretti su ogni pagina (puntano a se stessi, non al vecchio URL). Sitemap.xml aggiornata con soli nuovi URL. robots.txt senza blocchi accidentali – il sito di staging spesso ha Disallow: / che nessuno rimuove prima di andare live. Controllalo.

  • 05. Notifica Google dopo il lancio

    Invia il nuovo sitemap in Search Console. Usa «Ispeziona URL» per richiedere il crawl delle pagine principali. Da quel momento inizia il conteggio: 3–14 giorni per il primo passaggio di Googlebot, 4–8 settimane per il ricalcolo completo del peso.

I quattro errori che trasformano un calo normale in un disastro

Questi si vedono spesso. Ognuno ha un costo.

  • Redirect via JavaScript o meta refresh
  • Nessun mapping: 404 su URL che avevano peso
  • Redirect a catena
  • noindex rimasto attivo dallo staging

Redirect via JavaScript o meta refresh

Google legge il JS in ritardo o non lo legge affatto. Il redirect deve stare sul server, non nel codice della pagina. Se te lo consegna in JS, rimandalo indietro.

Nessun mapping: 404 ovunque

Un idraulico a Portogruaro aveva 40 pagine di servizi sul vecchio sito. Il nuovo sito le ha riscritte con URL diversi, senza redirect. Risultato: 40 errori 404, tutte le posizioni azzerate. Il recupero ha richiesto mesi.

Redirect a catena

A→B è corretto. A→B→C è un problema. Ogni salto intermedio può disperdere parte del peso che stavi cercando di conservare. Si risolve in fase di mapping: la destinazione finale, sempre direttamente.

noindex rimasto attivo

Il sito di test gira sempre con Disallow: / o con il tag noindex su tutte le pagine – giustamente, non si vuole che Google lo indicizzi durante lo sviluppo. Il problema è quando si dimentica di rimuoverlo prima del lancio. Google arriva, vede il sito, non indicizza nulla. Silenzio totale per settimane, fino a quando qualcuno se ne accorge.

Il rifacimento del sito senza rischi parte da qui: da una migrazione pensata prima, non rattoppata dopo.

Checklist migrazione: pre e post lancio

Prima di andare live e nelle ore successive. In ordine.

  • Esporta tutti gli URL correnti

    Nessuna pagina con posizioni deve sparire senza redirect.

  • Verifica i redirect 301 con uno strumento

    Controlla che ogni vecchio URL risponda 301, non 404 o 200 vuoto.

  • Rimuovi noindex e Disallow dall'ambiente di staging

    È l'errore più silenzioso e più costoso.

  • Controlla i canonical su ogni pagina del nuovo sito

    Devono puntare a se stessi, non al vecchio dominio.

  • Invia il nuovo sitemap.xml in Search Console

    Subito dopo il lancio, non il giorno dopo.

  • Richiedi il crawl delle pagine chiave tramite «Ispeziona URL»

    Accelera il primo passaggio di Googlebot sulle pagine più importanti.

  • Monitora Coverage e posizioni per 6–8 settimane

    Un calo nelle prime tre settimane è normale. Un calo che continua dopo la sesta è il segnale che qualcosa non va.

I redirect 301 non trasferiscono il peso in tempo reale. Google deve trovare il nuovo URL, scansionarlo, confrontarlo con il vecchio e ricalcolare tutto il grafo. Questo richiede settimane. Chi ti promette zero cali garantiti mente – o non capisce come funziona. Noi diciamo: aspettati un calo nelle prime 2–4 settimane. Poi risale. Di solito oltre il punto di partenza. Ma non possiamo prometterti né il quando né il quanto.

Richiedi un preventivoScrivi su WhatsApp

Cosa guardare dopo il lancio – e quando preoccuparsi davvero

Hai lanciato. I redirect ci sono. Il sitemap è inviato. Adesso?

Nelle prime 2 settimane: calo di posizioni atteso. Non agire. Non toccare i redirect. Non aggiungere redirect sopra ai redirect.

Dalla terza alla sesta settimana: le posizioni dovrebbero iniziare a stabilizzarsi. In Search Console, sotto Coverage, il numero di pagine indicizzate deve avvicinarsi al totale del nuovo sito.

Segnali da tenere d'occhio:

  • Errori 404 in aumento in Coverage → hai URL non mappati
  • Pagine in «Escluse» con motivo «Reindirizzamento» → redirect che punta al contrario
  • Il numero di pagine indicizzate è molto inferiore al totale → canonical sbagliati o sitemap incompleta

Quando preoccuparsi davvero: se dopo 8 settimane le posizioni non si sono riprese e il Coverage mostra ancora errori strutturali. Quello non è il calo fisiologico – è un problema da risolvere.

Se il tuo sito opera sul mercato locale in Veneto o FVG, l'impatto si sente anche sulla scheda Google: durante il ricrawl, la coerenza tra sito e profilo locale conta. Tienilo aggiornato nel periodo di transizione.

WordPress vecchio, lento o pieno di plugin: rattoppare o rifare?

Pavel Lidum – Web strategist, Preveli Web Studio (Concordia Sagittaria, Venezia) Ho gestito migrazioni per siti di piccole imprese in tutto il Veneto e il Friuli. Il momento più delicato non è mai il lancio – è la settimana dopo, quando il titolare vede le posizioni calare e chiama in panico. Per questo spiego sempre cosa aspettarsi prima ancora di iniziare. Questa pagina è la versione scritta di quella conversazione.
Pavel Lidum CEO | Preveli
Richiedi un preventivo gratuito
Domande frequenti

Domande frequenti sulla migrazione SEO

Hai altre domande? Scrivi su WhatsApp

Quanto tempo ci vuole perché Google reindicizzi il nuovo sito?

Dipende dalla dimensione del sito e da quanto spesso Googlebot lo visita già. Come orientamento, ci sono tre fasi distinte:

  • Primo crawl: 3–14 giorni dalla notifica tramite sitemap. Googlebot trova i nuovi URL, legge i redirect, registra le destinazioni.
  • Indicizzazione progressiva: 2–4 settimane. Le pagine cominciano a comparire nei risultati, ma il peso non è ancora ricalcolato.
  • Stabilizzazione delle posizioni: 4–8 settimane dal lancio. È qui che si vede se la migrazione ha tenuto.

Per i siti locali tipici – 20, 50 pagine – il ciclo si chiude di solito entro sei-otto settimane. Non c'è modo di accelerarlo in modo significativo: il ritmo lo decide Googlebot, non noi.

Cambiare anche il dominio è la stessa cosa?

No. Stessa piattaforma, dominio invariato – rischi minimi. Se cambia anche il dominio, serve lo strumento «Change of Address» in Search Console e il doppio dell'attenzione sui redirect. È un'operazione separata, non impossibile.

Il vecchio sito rimarrà visibile su Google durante la transizione?

Sì, per settimane o anche mesi. Google è lento ad aggiornare il suo indice. È normale vedere il vecchio sito nelle SERP anche dopo il lancio di quello nuovo, finché Googlebot non passa su tutti i vecchi URL e li vede rispondere 301. Non è un problema – è la meccanica del ricrawl.

Ho già delle 404. Cosa faccio adesso?

Prima di tutto: non toccare nulla a caso. Le 404 post-lancio sono recuperabili, ma vanno affrontate nell'ordine giusto.

  1. Esporta la lista. In Search Console vai su Indicizzazione → Pagine, filtra per «Non trovato (404)». Scarica tutto.
  2. Dai priorità. Le pagine che erano in top 30 prima. Gli URL senza posizioni hanno meno urgenza.
  3. Crea i redirect mancanti a livello server, uno per uno. Ogni redirect aggiunto è una pagina che smette di perdere peso.
  4. Aspetta 2–3 settimane prima di controllare i risultati. Googlebot deve passare, leggere il redirect, aggiornare l'indice.

Non si recupera tutto in un giorno. Ma si recupera.

Quando devo davvero preoccuparmi?

Se dopo 8 settimane dal lancio le posizioni non si sono stabilizzate e i Coverage errors rimangono alti, c'è un problema strutturale. Un calo nelle prime 3–4 settimane è normale. Un calo che continua oltre la sesta settimana senza segnali di ripresa – no.

Chi fa tecnicamente la migrazione?

Dipende da chi rifà il sito. Se lo fa un'agenzia, la migrazione SEO dovrebbe essere inclusa nel processo – non un'aggiunta dell'ultimo momento. Noi la gestiamo internamente: mapping, redirect, Search Console, monitoraggio post lancio. Il cliente non deve sapere cos'è un .htaccess.

Altri articoli sul tema