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 viene generato 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 scansionare nuovamente il sito.

Google Search Console inizierà a inviare email su «Duplicato, Google ha scelto una pagina canonica diversa da quella indicata dall’utente» e «Non trovato (404) — convalida non riuscita». Le pagine con i migliori risultati potrebbero attraversare redirect non necessari in sequenza. Potresti mantenere due sitemap con contenuti sovrapposti 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 analisi dei dati (noi usiamo Plausible gestito sulla nostra infrastruttura)

Cosa risolve questa guida

Catene di redirect con più passaggi (2+) ridotte a singoli 301
Sitemap duplicate 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 passaggi: 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 i passaggi aggiuntivi hanno 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 ci ha spinto a eseguire il controllo dei redirect descritto sopra.

Passo 2: correggere nginx per redirect a singolo passaggio

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 incontra poi una seconda regola che reindirizza /slug a /insights/slug. Due passaggi.

Sostituiscila con una regola specifica per il 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://www.yourdomain.com/insights/$slug;
    }
    return 301 https://www.yourdomain.com/$slug;
}
# Percorsi multi-segmento — rimuovi solo lo slash
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$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ì. Gli altri percorsi a livello radice ricevono dalla stessa regola un unico redirect che rimuove lo slash; i percorsi con più segmenti vengono gestiti dalla seconda regola, quella generica. Dopo la distribuzione, 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, stai mantenendo due sitemap che possono perdere la sincronizzazione. Controlla quale delle due è indicata 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 indicare sitemap-index.xml e lascia che l'integrazione di Astro gestisca tutto. I nuovi articoli compariranno automaticamente a 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. Puoi mantenerle entrambe, ma se le email duplicate creano confusione, scegline una. Se i tuoi sottodomini sono progetti separati, la proprietà con prefisso URL offre una vista più mirata — riporta solo gli URL sotto quello specifico prefisso, ad esempio quelli dell’host www 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 rimossi dall’indice 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 la distribuzione 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 passaggio 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 e una singola sitemap autorevole fornisce a Google il segnale più chiaro possibile; una proprietà GSC consolidata rende più semplice seguire i report rimanenti. 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.