Redirect 301 su WordPress: preservare la SEO quando cambi URL o migri il sito

Il redirect 301 è l'operazione più delicata di una migrazione WordPress. Fatto bene, trasferisce il posizionamento SEO dalla vecchia URL alla nuova senza perdere una posizione. Fatto male — o non fatto — perdi anni di lavoro di indicizzazione in una notte. Il redirect non è un dettaglio tecnico: è la differenza tra una migrazione invisibile agli utenti e una che fa crollare il traffico del 60%.

Il primo concetto da chiarire è la differenza tra 301 e 302. Il 301 è permanente: dice a Google 'questa pagina si è trasferita definitivamente, trasferisci tutto il valore SEO alla nuova URL'. Il 302 è temporaneo: dice 'questa pagina è momentaneamente altrove, non trasferire il valore'. Usare il 302 quando serve il 301 è un errore che non trasferisce il posizionamento — la nuova URL non riceve il valore della vecchia, e la vecchia resta in indice anche se non esiste più.

Redirect a livello di server: il modo corretto

Il modo più efficiente di gestire i redirect è a livello di server, non con un plugin WordPress. Un redirect nel .htaccess viene processato da Apache prima ancora di caricare WordPress — è istantaneo. Un redirect con un plugin richiede il caricamento completo di WordPress, l'esecuzione di PHP, e poi il redirect. Su un sito con molti redirect, la differenza di performance è misurabile. Ecco i pattern principali per .htaccess:

# Redirect 301 nel .htaccess — pattern principali

# 1. Redirect singolo: vecchia URL → nuova URL
Redirect 301 /vecchia-pagina https://www.example.com/nuova-pagina

# 2. Redirect con pattern (RedirectMatch): cattura parte dell'URL
# /blog/2024/articolo → /articolo (rimuovi /blog/2024/)
RedirectMatch 301 ^/blog/[0-9]{4}/(.*)$ https://www.example.com/$1

# 3. Redirect di un'intera sezione
# /vecchia-categoria/* → /nuova-categoria/*
RedirectMatch 301 ^/vecchia-categoria/(.*)$ https://www.example.com/nuova-categoria/$1

# 4. Redirect da HTTP a HTTPS (se non già gestito dal hosting)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# 5. Redirect da non-www a www (o viceversa — scegline uno)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

# 6. Redirect da vecchio dominio a nuovo dominio (migrazione completa)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^vecchio-dominio\.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www\.vecchio-dominio\.com$ [NC]
RewriteRule ^(.*)$ https://www.nuovo-dominio.com/$1 [R=301,L]

Redirect a catena: il problema silenzioso

Un redirect a catena è quando una URL reindirizza a una seconda, che reindirizza a una terza. Google segue fino a 5 redirect, ma ogni hop perde un po' di valore SEO e aggiunge latenza. Una catena di 3 redirect aggiunge 300-600ms al tempo di caricamento — e su mobile, ogni 100ms conta. Le catene si formano quando aggiungi redirect senza controllare quelli esistenti:

# Verifica le catene di redirect con curl

# Mostra solo gli header di redirect
curl -sILk https://www.example.com/vecchia-pagina | grep -iE 'HTTP|location'

# Output di una catena (PROBLEMA):
# HTTP/1.1 301 Moved Permanently
# location: https://example.com/intermedia
# HTTP/1.1 301 Moved Permanently
# location: https://example.com/final
# HTTP/1.1 200 OK
#
# 2 hop = catena. Risolvi puntando /vecchia-pagina direttamente a /final.

# Output corretto (un solo redirect):
# HTTP/1.1 301 Moved Permanently
# location: https://example.com/final
# HTTP/1.1 200 OK

# Trova tutti i redirect nel .htaccess e verifica le catene:
grep -i '^Redirect\|RedirectMatch' .htaccess | while read line; do
  url=$(echo "$line" | awk '{print $2}')
  echo "Checking: $url"
  curl -sILk "https://www.example.com$url" | grep -iE 'HTTP|location'
done

Quando usare un plugin invece del .htaccess

Il .htaccess è il modo più efficiente, ma non sempre il più pratico. Se hai centinaia di redirect che cambiano spesso (es. un e-commerce che ritira prodotti e li reindirizza a categorie), gestirli nel .htaccess diventa insostenibile. In quel caso, un plugin come Redirection (di WordPress.org) è più pratico: gestisce i redirect nel database con un'interfaccia admin, e li serve con un overhead minimo.

La regola: per redirect stabili e pochi (migrazione, cambio struttura permalink), .htaccess. Per redirect dinamici e molti (e-commerce, contenuti che cambiano), plugin. La differenza di performance tra i due, su un sito con caching, è trascurabile — perché le pagine cachate non passano dal redirect. I redirect contano solo per le URL non cachate, che sono una minoranza.

Il test post-migrazione: cosa verificare

Dopo una migrazione con redirect, tre verifiche non negoziabili. Primo: Google Search Console → Copertura. Controlla che le vecchie URL non restituiscano 404 e che le nuove vengano indicizzate. Secondo: verifica che il traffico non crolli nei giorni successivi — un calo del 20%+ nelle prime 48 ore indica redirect mancanti. Terzo: controlla le pagine più importanti (quelle con più traffico) una per una con curl -I per verificare che restituiscano 301 alla URL corretta.

I redirect 301 sono l'assicurazione della tua SEO. Non prevengono i problemi — li gestiscono quando il cambiamento è inevitabile. Ma senza di loro, ogni cambio di URL è una perdita di posizionamento che può richiedere mesi per recuperare. Con i redirect corretti, la migrazione è invisibile agli utenti e a Google. La differenza è nel metodo: mappare ogni URL importante, testare ogni redirect, e monitorare nei giorni successivi. Non è glamour, ma è il lavoro che protegge anni di indicizzazione.