Redesign senza perdite di traffico

Il redesign è una delle cause più comuni di crolli improvvisi del traffico organico. Il sito è bellissimo, il team è contento — e un mese dopo GSC mostra meno 40%. La causa è quasi sempre la stessa: URL cambiati senza redirect, oppure il motore di ricerca non ha ancora re-indicizzato la nuova struttura. Ecco la guida passo per passo a un redesign sicuro, senza perdite.

Perché il redesign uccide il traffico

I motori di ricerca indicizzano URL specifici. Se /blog/seo-guide/ è esistito per anni, Google ha accumulato per quell'URL valore dei link, autorevolezza e storico dei clic. Un redesign che cambia la struttura degli URL equivale a distruggere tutto questo: agli occhi del crawler, la pagina è semplicemente sparita.

zoom_in

Dopo un redesign, cinque cause di perdita di traffico ricorrono più spesso:

Audit pre-lancio: cosa registrare

Prima di toccare il design — almeno due settimane di audit. Serve fissare lo stato attuale per avere una baseline con cui confrontarsi dopo il lancio. Quattro strumenti essenziali:

A parte, segna le pagine con più traffico e link in entrata — sono le priorità della mappa dei redirect. Perdere le top 10 pagine per traffico significa perdere il 70–80% del traffico organico.

Cosa fissare prima del redesign

Architettura degli URL e mappa dei redirect

La struttura degli URL è la parte più delicata di un redesign. Se la struttura cambia (es. /services/seo/ diventa /seo-services/), ogni vecchio URL deve ricevere un redirect 301 esplicito. La mappa dei redirect è una tabella vecchio URL → nuovo URL: si costruisce prima del lancio, si verifica a mano, si consegna allo sviluppatore.

Se una pagina non serve più e il suo contenuto non è duplicato altrove — usa 410, non 404. Il 410 comunica a Google che l'eliminazione è intenzionale, quindi il crawl budget viene speso meglio: il crawler smette prima di tornare sull'URL morto.

# Nginx: redirect a specific page
location = /old-services/ {
    return 301 /services/;
}

# Nginx: redirect an entire section
location /old-blog/ {
    rewrite ^/old-blog/(.*)$ /blog/$1 permanent;
}

# Test redirect with curl
curl -I https://example.com/old-url/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/new-url/

Per Apache usa .htaccess con le direttive Redirect 301 o RewriteRule. Testa ogni redirect prima del lancio pubblico — un solo URL mancante tra le top 10 pagine per traffico significa perdite reali.

Setup tecnico post-lancio

Le prime 48–72 ore dopo il lancio del nuovo design sono critiche. Verifica che il crawler veda esattamente ciò che intendi — non una versione di staging con l'indicizzazione disattivata.

1. Controlla robots.txt — assicurati che la produzione non sia bloccata con Disallow: /
2. Rigenera la sitemap XML con i nuovi URL e inviala a GSC dalla sezione Sitemaps
3. Richiedi l’indicizzazione delle pagine chiave via GSC → Controllo URL → Richiedi indicizzazione
4. Verifica i meta tag — title, description, canonical su ogni pagina prioritaria
5. Passa in rassegna la mappa dei redirect — testa ogni 301 con curl o DevTools Network
6. Misura i Core Web Vitals — PageSpeed Insights sulle top 20 pagine per traffico

Controlla anche i tag canonical. Nel cambio di CMS o template tornano spesso a percorsi relativi o spariscono del tutto. Il canonical deve contenere l'URL assoluto del dominio di produzione: https://example.com/page/ — non /page/.

<!-- Correct canonical in <head> -->
<link rel="canonical" href="https://example.com/services/seo/">

<!-- Wrong — relative path (common CMS migration error) -->
<link rel="canonical" href="/services/seo/">

Monitoraggio post-lancio

Il redesign non è un evento — è un processo. I primi tre mesi dopo il lancio sono un periodo di instabilità, mentre Google rivaluta il sito. Il tuo compito è osservare i segnali e reagire in fretta.

Tabella diagnostica — se qualcosa va storto dopo il lancio, parti da qui: