Correggere la SEO dopo una migrazione da WordPress ad Astro: catene di redirect, sitemap e pulizia di GSC

Dopo una migrazione da WordPress ad Astro, il sito compila più velocemente, si carica più velocemente e costa meno da ospitare. Se però durante la migrazione sono cambiati i percorsi degli URL — ad esempio da /post-slug/ a /insights/post-slug — è probabile che tu abbia problemi SEO che emergono solo settimane dopo, quando Google finisce di ri-scansionare il sito.

Google Search Console inizierà a inviare email su "Duplicato, Google ha scelto una canonical diversa da quella dell'utente" e "Non trovato (404) - convalida non riuscita". Le pagine con le migliori performance potrebbero perdere link equity a causa di redirect non necessari in sequenza. Potresti avere due sitemap in conflitto tra loro senza nemmeno saperlo.

Questa guida mostra come individuare e risolvere questi problemi. Li abbiamo incontrati tutti durante la nostra pulizia SEO post-migrazione da WordPress ad Astro e abbiamo documentato le soluzioni qui.

Cosa ti serve

Accesso SSH al server (configurazione nginx)
Accesso a Google Search Console per la tua proprietà
curl installato in locale
Uno strumento di analytics (noi usiamo Plausible self-hosted)

Cosa risolve questa guida

Catene di redirect con più hop (2+) ridotte a singoli 301
Sitemap in conflitto consolidate in un'unica sorgente generata automaticamente
Pagine con noindex rimosse dalla sitemap
Proprietà GSC obsolete e sitemap WordPress legacy eliminate
Confusione sulle canonical tra vecchia e nuova struttura degli URL

Passo 1: diagnosticare le catene di redirect

Verifica quanti redirect attraversano i tuoi URL principali. Se i vecchi URL WordPress avevano lo slash finale e i nuovi URL Astro non ce l'hanno, probabilmente hai una catena a due hop: un redirect rimuove lo slash, un altro aggiunge il nuovo prefisso del percorso.

curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/old-post-slug/"

Se l'output mostra Hops: 2, hai una catena di redirect. Esegui questo controllo per le cinque pagine con più traffico — sono quelle in cui la perdita di link equity ha più impatto.

Incrocia i dati con il tuo strumento di analytics. Se vedi lo stesso articolo comparire sotto più varianti di URL (con slash, senza slash, con il nuovo prefisso), i tuoi redirect non stanno consolidando il traffico. Nel nostro caso abbiamo visto l'articolo più visitato distribuito su tre varianti di URL in Plausible, il che ha confermato il problema delle catene.

Passo 2: correggere nginx per redirect a singolo hop

La regola standard di nginx per rimuovere lo slash finale è questa:

location ~ ^(.+)/$ { return 301 $1; }

Questa regola rimuove lo slash finale ma non sa nulla del cambio di percorso del blog. La richiesta colpisce poi una seconda regola che reindirizza /slug a /insights/slug. Due hop.

Sostituiscila con una regola consapevole del blog, che controlla se lo slug corrisponde a un post e reindirizza direttamente all'URL finale:

# Slug blog con slash finale — singolo hop verso /insights/
location ~ ^/([^/]+)/$ {
    set $slug $1;
    if (-f /usr/share/nginx/html/insights/$slug/index.html) {
        return 301 https://yourdomain.com/insights/$slug;
    }
    return 301 https://yourdomain.com/$slug;
}
# Percorsi multi-segmento — rimuovi solo lo slash
location ~ ^(.+)/$ { return 301 $1; }

La prima regola gestisce gli slug a livello radice (i vecchi URL WordPress del blog). Controlla se esiste una pagina corrispondente sotto /insights/ e reindirizza direttamente lì. I percorsi che non appartengono al blog ricadono nella rimozione generica dello slash. Dopo aver effettuato il deploy, verifica:

curl -sL -w "Hops: %{num_redirects}\n" -o /dev/null \
  "https://yourdomain.com/your-top-post-slug/"
# Expected: Hops: 1

Passo 3: consolidare le sitemap

Controlla se hai più di una sitemap. Un pattern comune dopo la migrazione: una sitemap.xml statica creata manualmente durante il trasferimento, più una sitemap-index.xml generata automaticamente dall'integrazione @astrojs/sitemap di Astro.

# Controlla entrambe
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1

Se entrambe restituiscono 200, hai sitemap in conflitto. Controlla quale delle due è referenziata nel robots.txt:

curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap

La soluzione: elimina la sitemap.xml statica dalla directory public/, aggiorna il robots.txt per referenziare sitemap-index.xml e lascia che l'integrazione di Astro gestisca tutto. I nuovi articoli compariranno automaticamente ad ogni build.

Controlla anche la sitemap statica alla ricerca di pagine con noindex. Se la tua sitemap.xml elenca pagine come /legal o /privacy-policy che hanno il tag <meta name="robots" content="noindex">, stai inviando segnali contraddittori a Google. La sitemap generata automaticamente da @astrojs/sitemap può essere configurata con regole di filtro per escludere correttamente queste pagine.

Passo 4: fare pulizia in Google Search Console

Apri GSC e controlla due cose: le proprietà e le sitemap.

Proprietà: Se hai sia una proprietà di dominio (sc-domain:yourdomain.com) che una di prefisso URL (https://www.yourdomain.com/), riceverai avvisi duplicati per gli stessi problemi. Scegli una sola. Se i tuoi sottodomini sono progetti separati, la proprietà con prefisso URL è più pulita — riporta solo il traffico di produzione.

Sitemap: Vai su Indicizzazione → Sitemap. Rimuovi le vecchie sitemap WordPress ancora registrate lì (post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml, ecc.). Invia la nuova sitemap-index.xml come unica sitemap.

Errori 404: Vai su Indicizzazione → Pagine → "Non trovato (404)" e controlla quali URL sono elencati. Se si tratta di vecchi percorsi WordPress che non esistono più e non devono esistere (pagine prodotto WooCommerce, pagine autore, URL dei feed), verranno de-indicizzati nel tempo. Se invece sono post del blog che dovrebbero essere reindirizzati, le tue regole nginx vanno aggiornate. Dopo aver corretto i redirect, clicca su "Convalida correzione" per avviare una nuova scansione.

Passo 5: verificare tutto

Esegui questi controlli dopo aver effettuato il deploy delle correzioni:

# 1. Catene di redirect risolte
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\n" \
  -o /dev/null "https://yourdomain.com/your-top-post/"
# Expected: Hops: 1, URL ends in /insights/your-top-post

# 2. robots.txt punta alla sitemap generata
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Expected: sitemap-index.xml

# 3. La sitemap statica restituisce 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Expected: 404

# 4. La sitemap generata restituisce 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Expected: 200

# 5. Non-www reindirizza a www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  "https://yourdomain.com/insights"
# Expected: 301 https://www.yourdomain.com/insights

Quanto tempo ci vuole perché Google si aggiorni

I redirect a singolo hop hanno effetto immediatamente per le nuove scansioni. Le modifiche alle sitemap vengono recepite nel giro di pochi giorni. La confusione sulle canonical — dove Google preferisce il vecchio URL rispetto al nuovo — richiede più tempo per risolversi. Google tratta il tag <link rel="canonical"> come un suggerimento, non come una direttiva. Se il vecchio URL ha più backlink e dati storici di clic, Google potrebbe continuare a sceglierlo come canonical per diverse settimane.

La combinazione di redirect puliti, una singola sitemap autorevole e una proprietà GSC consolidata fornisce a Google il segnale più chiaro possibile. Nel nostro caso, gli avvisi "Canonical duplicata" hanno iniziato a diminuire entro due settimane dall'applicazione di queste correzioni.

Gestiamo regolarmente questo tipo di migrazioni nell'ambito del nostro lavoro sulle prestazioni e le migrazioni WordPress. Se stai affrontando problemi SEO post-migrazione, contattaci.