Correggere i problemi SEO dopo la migrazione di WordPress: inizia dalla verità sugli URL

In sintesi: La tua migrazione WordPress probabilmente non ha “rovinato la SEO”. Ha interrotto il percorso fra vecchi URL, nuovi URL, redirect, canonicals, sitemap, link interni e ora anche citazioni AI. La correzione parte dalla verità sugli URL, non da un altro audit di plugin.

Non è stata la migrazione a uccidere la tua SEO, ma la storia degli URL interrotti.

La maggior parte delle persone analizza i problemi di wordpress migration seo dal lato sbagliato. Si chiedono se WordPress, il nuovo tema, l’hosting o il plugin SEO abbiano causato il calo. A volte uno di questi elementi è coinvolto, di solito perché ha rotto la continuità degli URL.

In mindnow ho visto migrazioni WordPress in cui i contenuti erano intatti ma i ranking crollavano perché 600 vecchi URL venivano silenziosamente puntati alla homepage. Ora controllo quello prima di guardare qualsiasi cosa su seojuice.io o vadimkravcenko.com.

Le vittorie più rapide sono di solito noiose: vecchio URL, nuovo URL, codice di stato, canonical, indicizzabilità, presenza in sitemap e link interni. In quest’ordine — non titoli, non schema, non Core Web Vitals.

Joost de Valk, fondatore di Yoast SEO, descrive le migrazioni di dominio di successo come “circa 90% preparazione e 10% esecuzione”. Quella frase è utile anche dopo un lancio andato male. Se la preparazione non è avvenuta prima dello switch, il lavoro di riparazione è preparazione fatta in ritardo.

Il compito è dimostrare se Google riesce ancora a collegare la domanda esistente alle nuove destinazioni. Se non può, riscrivere i testi è solo teatro.

Prima classifica il calo, poi intervieni

Non tutti i cali di traffico post-migrazione hanno la stessa causa. Cambio di hosting, di dominio, di permalink, ricostruzione del tema, import CMS o sostituzione di plugin SEO possono produrre lo stesso grafico: sessioni organiche giù, tutti in ansia.

Il primo bivio diagnostico è semplice. Google ha perso l’URL, diffida del nuovo URL o interpreta male la relazione fra i due?

Non riscrivere nulla finché non sai se Google può raggiungere, comprendere e fidarsi del nuovo URL. Un post con tag noindex non ha bisogno di un titolo migliore. Una categoria prodotto canonicalizzata al vecchio dominio non ha bisogno di altro testo. Una landing page reindirizzata che ora risolve in homepage non ha bisogno di markup schema.

Prima classifica. Poi ripara.

Ricostruisci la mappa degli URL, anche se la migrazione è già avvenuta

John Mueller ha dato la versione più chiara di questo consiglio durante un SEO Office Hours di Google, riportato da Search Engine Journal:

“Penso che la parte più importante sia davvero tracciare i singoli URL, in modo da avere una mappa chiara di cosa esisteva prima e cosa dovrebbe esserci in futuro.”

“Singoli URL” conta in WordPress. Non significa solo post e pagine. WordPress crea superfici tramite temi, plugin, archivi, gestione media, filtri e vecchi permalink fallback. Se hai migrato solo la struttura di menu visibile, probabilmente ti sei perso metà del sito.

Superfici di URL WordPress che la gente dimentica

• Post e pagine
• URL dei prodotti WooCommerce, categorie prodotto e base /shop
• Categorie, tag e tassonomie personalizzate
• Archivi autore
• Archivi per data se indicizzabili
• Pagine allegato e URL media
• Archivi di custom post type
• Archivi paginati
• URL dei feed
• Vecchi fallback permalink ?p=123 (sì, su installazioni datate risolvono ancora)
• Varianti con e senza slash finale
• Varianti HTTP e HTTPS
• Varianti www e non-www
• Vecchi URL di staging o host temporanei trapelati

Parti dalle evidenze, non dalla memoria. Esporta le landing page da Analytics. Esporta le pagine top da Google Search Console. Fai il crawl del sito attuale. Recupera eventuali crawl pre-migrazione. Aggiungi gli URL con backlink dal tuo indice link se disponibile. Poi unisci tutto in una mappa vecchio-nuovo.

Sì, è la parte noiosa del foglio di calcolo — è anche dove partono la maggior parte dei recuperi (gli audit che ho salvato in mindnow risalivano sempre a una colonna mancante nel foglio di qualcun altro). Usa colonne per vecchio URL, nuovo URL, status HTTP, target del redirect, target canonical, indicizzabilità, presenza in sitemap e note. Se non c’è una destinazione equivalente, dillo. Non nasconderla dietro un fallback alla homepage.

Per siti grandi, dai priorità agli URL con backlink, ricavi, clic organici, conversioni o citazioni AI. Un vecchio archivio tag del 2017 può aspettare. Una categoria prodotto che generava vendite non-brand no.

Correggi i redirect prima di toccare titoli, testi o schema

La documentazione ufficiale di Google sullo spostamento di siti afferma:

“Mantieni i redirect il più a lungo possibile, in genere almeno 1 anno.”

Questa frase andrebbe stampata sopra ogni checklist di migrazione WordPress. I redirect spariscono in modi banali. Qualcuno rimuove il blocco .htaccess. Un plugin di redirect viene disattivato in fase di pulizia. Una migrazione di hosting perde le regole Nginx. Le page rule Cloudflare vengono sostituite. Il vecchio dominio scade. Il dominio di staging viene eliminato. Nessuno se ne accorge finché Search Console non sembra una scena del crimine.

Un redirect è utile solo quando la destinazione risponde alla stessa intenzione. Vecchio post → nuovo post. Vecchio prodotto → prodotto equivalente. Vecchia categoria → categoria equivalente. Vecchia pagina servizio → pagina servizio sopravvissuta più vicina. Se la destinazione è irrilevante, il 301 tecnico non salva il valore SEO.

Se ti serve un processo, usa questo:

1. Crawl della lista vecchi URL registrando ogni codice di stato.
2. Segna ogni catena 3xx più lunga di un salto.
3. Segna ogni vecchio URL che atterra in homepage.
4. Controlla che la destinazione finale sia indicizzabile.
5. Conferma che la pagina finale canonicalizzi a se stessa o al canonical previsto.
6. Sposta i redirect di alto valore da regole fragili di plugin a regole server o edge dove possibile.

Se usi un plugin, esporta le sue regole prima di toccare qualsiasi cosa. Redirection, Rank Math, Yoast Premium e i pannelli redirect a livello hosting possono andare bene. Il problema è di solito la proprietà: nessuno sa quale livello è autorevole.

Il redirect alla homepage non è una rete di sicurezza

La documentazione di Google avverte contro il reindirizzare molti vecchi URL verso un’unica destinazione irrilevante, come la homepage, perché può essere trattato come soft 404. In WordPress questo errore è comune. Un admin vede centinaia di 404 in un plugin e crea un fallback globale a /. La dashboard sembra più pulita — il traffico organico peggiora.

La correzione è più lenta ma più sicura. Mappa i vecchi URL alla destinazione più vicina possibile. Se non esiste equivalente, restituisci un vero 404 o 410. Lascia che gli URL morti muoiano onestamente. Preserva le pagine che contano con redirect uno-a-uno.

Questo è particolarmente doloroso per le migrazioni e-commerce. Un prodotto dismesso può meritare un redirect al prodotto sostitutivo o alla categoria madre. Un prodotto eliminato senza sostituto può meritare un 410. Un prodotto eliminato e reindirizzato alla homepage non insegna nulla a Google.

Occhio alla finestra di 180 giorni dello Strumento Cambio di Indirizzo

Lo Strumento Cambio di Indirizzo in Google Search Console aiuta Google a elaborare uno spostamento di sito, ma non sostituisce i redirect. La guida di Search Console dice che le azioni di migrazione proseguono per 180 giorni dopo l’avvio. Dopo quella finestra, Google non riconosce più vecchio e nuovo sito come correlati se il vecchio è ancora presente e crawlable. Morale pratica: i redirect devono vivere oltre la finestra dei 180 giorni. Se il vecchio host viene chiuso al quinto mese, crei un precipizio.

Controlla le impostazioni WordPress che bloccano silenziosamente il recupero

WordPress raramente rompe una sola pagina alla volta. Rompe i template. Diagnostica per tipo di pagina, non per campione casuale.

Inizia dall’impostazione ovvia perché causa ancora danni reali: Impostazioni → Lettura → Scoraggia i motori di ricerca dall’indicizzare questo sito. I siti di staging la abilitano spesso. Un lancio frettoloso può portarla in produzione. Vale lo stesso per le regole noindex del plugin SEO copiate dallo staging.

Poi controlla i canonical. Una ricostruzione del tema o l’import di un plugin possono lasciare tag canonical che puntano al vecchio dominio, all’host temporaneo o alla versione linguistica sbagliata. Ispeziona l’HTML renderizzato, non solo il campo del plugin. La cache può servire tag obsoleti dopo che la schermata admin sembra a posto.

Le sitemap meritano la stessa diffidenza. I plugin SEO di WordPress dividono le sitemap per tipo di post e tassonomia. Dopo la migrazione, potresti avere URL di post puliti in una sitemap e URL di categoria del vecchio dominio in un’altra. Invia l’indice della sitemap, poi apri manualmente le sitemap figlie.

Robots.txt è un altro killer silenzioso. Bloccare /wp-content/ può impedire a Google di recuperare CSS, JavaScript o immagini necessari a comprendere la pagina. Bloccare un percorso template può danneggiare interi gruppi. Bloccare l’intero sito succede ancora dopo i lanci da staging. L’ho visto più di una volta.

I permalink sono peggio perché sembrano una decisione di contenuto. Passare da /%postname%/ a /blog/%postname%/ senza redirect crea una migrazione URL dentro la migrazione. Cambiare la base categoria, rimuovere lo slash finale o modificare la base prodotto WooCommerce ha lo stesso effetto.

Controlla anche l’ordine delle regole di redirect, le regole CDN, l’output del plugin multilingua, i target hreflang, gli URL filtro WooCommerce, il comportamento delle pagine allegato, la paginazione, i breadcrumb e gli archivi di custom post type. Un template difettoso può sopprimere centinaia di URL.

Se ti sembra una checklist di audit tecnico SEO, bene. Il recupero post-migrazione è un audit tecnico con un timestamp e una lista di sospetti.

Recupera le pagine scomparse dall’indice di Google

Scegli una pagina di valore che ha perso traffico. Non venti. Una.

Ispeziona prima il vecchio URL. Restituisce un 301? Ci sono catene? Atterra sul nuovo URL corretto? La destinazione si carica per Googlebot? Poi ispeziona il nuovo URL. Conferma codice di stato, canonical, direttive robots, HTML renderizzato, link interni, presenza in sitemap e data ultimo crawl.

Usa lo strumento Ispezione URL di Search Console per l’URL live, non solo per la versione indicizzata. La versione indicizzata mostra ciò che Google ha in cache. Il test live mostra cosa può recuperare ora.

Poi scala per template. Se un post migrato ha il canonical sbagliato, forse tutti i post migrati lo hanno. Se una categoria prodotto è noindex, forse tutte le categorie lo sono. Se un archivio autore è improvvisamente indicizzabile, ogni archivio autore potrebbe creare di nuovo pagine sottili.

La validazione Search Console è lenta (giorni o settimane, non ore). Il segnale iniziale migliore è il comportamento di crawl. Controlla i log server se li hai. I vecchi URL reindirizzati vengono ancora richiesti? Le richieste Googlebot raggiungono le destinazioni finali? I 404 calano per vecchi URL di alto valore?

I ranking di solito si riprendono per gruppo. Se le categorie prodotto riparate iniziano a essere scansionate e le impression ritornano, applica la stessa correzione al resto del set. Non continuare a cambiare cose non correlate mentre la prima riparazione è ancora in elaborazione.

Le citazioni AI aggiungono ora un secondo problema di migrazione

Joost de Valk l’ha riassunto bene:

“Non esiste un modulo Cambio di Indirizzo per un modello che ha terminato l’addestramento un anno prima del tuo spostamento.”

Google può seguire i redirect. Search Console può elaborare uno spostamento di sito. Gli LLM e i motori di risposta AI possono comunque conservare vecchi hostname o URL nei dati di training, negli indici di retrieval, negli indici partner o nei layer di citazioni in cache. Un 301 pulito aiuta Google ma non riscrive ogni vecchia citazione archiviata altrove.

La soluzione non è magica. Mantieni vivi i redirect. Fai risolvere i vecchi URL verso il miglior nuovo match. Aggiorna profili ad alta autorità, pagine sorgente canoniche, schema dell’organizzazione, riferimenti sameAs, sitemap XML e link interni. Dove possibile, aggiorna le citazioni sulle piattaforme che i sistemi AI ingeriscono più spesso.

Questo conta più per WordPress di quanto si ammetta (io stesso mi sbagliavo per anni). Molte migrazioni si affidano a plugin o regole host che vengono ripuliti dopo tre mesi. Se le citazioni AI puntano ancora ai vecchi URL, quei redirect sono il ponte. Taglia il ponte e la citazione diventa un vicolo cieco.

Per la pulizia correlata, leggi le guide SEOJuice su catene di redirect e 301, best practice per sitemap XML e errori di tag canonico.

Piano di riparazione in 14 giorni per la SEO di migrazione WordPress

Puoi recuperare una migrazione disordinata senza provare a sistemare tutto in una volta. La sequenza conta più dello stack di strumenti.

Giorno 0-1: fermare l’emorragia

• Conferma la proprietà di vecchio dominio, vecchio host, DNS, CDN e proprietà Search Console.
• Ripristina il controllo dei redirect prima di modificare i contenuti.
• Disabilita i redirect catchall alla homepage.
• Rimuovi tag noindex e blocchi robots accidentali.
• Invia sitemap index pulite per il nuovo sito.
• Testa manualmente un campione di vecchi URL di alto valore.

Se non controlli più il vecchio dominio, il recupero diventa presto difficile. Riprendi il controllo prima di discutere i title tag.

Giorno 2-4: ricostruire la mappa

• Crea la tabella vecchio-nuovo URL.
• Dai priorità agli URL con backlink, clic organici, ricavi, conversioni e citazioni AI.
• Separa gli URL per tipo: post, pagine, prodotti, categorie, tag, media, archivi, feed.
• Correggi i redirect a blocchi, partendo dai gruppi di maggior valore.
• Ritesta ogni blocco dopo il deploy.

Non fidarti di “tutti i redirect importati con successo”. Fai il crawl della lista.

Giorno 5-7: riparare i template

• Audita i canonical per tipo di pagina.
• Controlla direttive robots e regole noindex.
• Revisiona titoli, heading, schema, breadcrumb e link interni.
• Verifica paginazione e template archivio.
• Conferma i target hreflang multilingua se presenti.
• Testa comportamento di categorie, prodotti e filtri WooCommerce.

Qui una review tecnica SEO WordPress dimostra il suo valore. Cerchi fallimenti a livello di template, non stranezze isolate.

Giorno 8-14: dimostrare il recupero

• Monitora copertura e statistiche di crawl in Search Console.
• Controlla i log per l’attività Googlebot sui redirect legacy.
• Traccia i ranking per gruppo di URL, non solo per keyword.
• Confronta le landing page Analytics prima e dopo la riparazione.
• Tieni note su ogni modifica a redirect, template e sitemap.

Se il traffico migliora sui gruppi di URL riparati, scala la stessa correzione. Se nulla cambia, smetti di fare modifiche a caso e ricontrolla la mappa.

Cosa non fare dopo una migrazione WordPress andata male

Non installare altri tre plugin SEO. Creerai canonicals sovrapposti, sitemap duplicate e regole di redirect senza proprietario.

Non reindirizzare ogni 404 alla homepage. Google ha chiarito che i mass redirect irrilevanti possono diventare soft 404.

Non cambiare di nuovo la struttura permalink perché “sembra più pulita”. URL puliti sono inutili se continuano a cambiare.

Non riscrivere i contenuti prima di sistemare accesso, redirect, canonicals e indicizzabilità. La qualità dei contenuti non compensa un percorso rotto.

Non rimuovere i vecchi redirect perché “Google probabilmente lo ha capito”. Le linee guida di Google dicono di mantenerli il più a lungo possibile, in genere almeno un anno.

Non prendere il ranking della homepage come prova che la migrazione è a posto. Il traffico brand può mascherare il collasso dei template. Controlla le landing page che portavano traffico non-brand.

Se i vecchi URL non sanno spiegare dove sono finiti, Google non ha motivo di indovinare per te.

FAQ

Quanto tempo richiede il recupero SEO dopo una migrazione WordPress?

Piccole correzioni possono mostrare variazioni di crawl e impression in pochi giorni. Il recupero dei ranking richiede di solito più tempo perché Google deve ricrawlare i vecchi URL, processare i redirect, aggiornare i canonical e ricostruire la fiducia nel nuovo set di URL. Per siti grandi, pensa in settimane, non in ore.

Devo reinviare la sitemap dopo una migrazione WordPress?

Sì, ma solo quando è pulita. Inviare una sitemap piena di URL del vecchio dominio, URL noindex o mismatch canonici può rallentare la diagnosi. Apri manualmente l’indice sitemap e le sitemap figlie prima di inviare.

I redirect 301 bastano a preservare i ranking?

Sono necessari, ma non sono tutto. La destinazione deve essere rilevante, indicizzabile, collegata internamente, canonicalizzata correttamente e presente in sitemap pulite. Un 301 verso una pagina debole o irrilevante può comunque far perdere traffico.

Cosa succede se ho cambiato la struttura permalink di WordPress?

Trattala come una migrazione di URL. Costruisci una mappa da ogni vecchio permalink alla nuova destinazione. Includi basi categoria, comportamento dello slash finale, basi prodotto, paginazione e vecchi fallback ?p=123 se risolvono.

Posso eliminare il vecchio host dopo la migrazione?

Solo se i redirect sono gestiti altrove e testati. Molti siti perdono traffico perché il vecchio host era l’unico posto dove esistevano i redirect. Prima di dismettere qualcosa, fai il crawl dei vecchi URL e conferma che risolvono ancora correttamente.

Conclusione: Il playbook di riparazione doveva essere la checklist di lancio

Un recupero da migrazione WordPress non è glamour. È contabilità degli URL, disciplina dei redirect, controllo dei template e pazienza. La stessa checklist che ripara il calo sarebbe dovuta esistere prima del lancio.

Su seojuice.io vale la stessa regola. Una noiosa continuità degli URL batte un’eroica pulizia. Usa questo articolo due volte: una per riparare la migrazione attuale e una prima che parta la prossima.

Serve aiuto per trovare il punto di rottura?

Se la tua migrazione WordPress ha fatto crollare il traffico organico e la causa è ancora oscura, parti dalla mappa URL e dall’audit dei redirect. SEOJuice può trasformare il panico in una coda di riparazioni e poi in una checklist di lancio per la prossima migrazione.