Pagine 404 dopo la migrazione di WordPress

Jacopo Giorgini
Illustrazione di due server collegati da una freccia, con al centro una finestra del browser con una catena spezzata e una chiave inglese che la ripara

Hai spostato il sito su un nuovo hosting, apri la home e sembra tutto a posto. Poi clicchi su un articolo e compare una pagina 404 (l’errore “pagina non trovata”), e lo stesso succede con le pagine e gli archivi.

Qui trovi l’ordine in cui controllo un sito WordPress appena migrato, spiegato passo per passo.

Importante: Questa guida vale per un sito WordPress singolo. Se il tuo è un multisite (più siti nella stessa installazione), molti passaggi cambiano e ti conviene farti seguire.

Prima cosa che faccio quando le pagine danno 404

La prima cosa che faccio è rigenerare i permalink (gli indirizzi delle pagine, come tuosito.it/chi-sono/). Serve a ricostruire le regole che collegano ogni indirizzo alla pagina giusta e, su Apache/Litespeed, a riscrivere il file .htaccess, un piccolo file di configurazione nella cartella del sito.

Non devi cambiare niente, basta salvare.

  1. Entra nella bacheca di WordPress (tuosito.it/wp-admin).
  2. Nel menu a sinistra vai in Impostazioni > Permalink.
  3. Scorri in fondo e clicca Salva modifiche, senza toccare le opzioni.
  4. Apri una finestra anonima del browser (Ctrl+Maiusc+N su Chrome) e prova un articolo che dava 404. Se ora si apre, hai finito.

Se non riesci a entrare in bacheca, il modo più semplice è il File Manager dell’hosting. Apri il file .htaccess nella cartella principale del sito (quella con wp-config.php), incolla questo blocco e salva: ha lo stesso effetto del salvataggio dei permalink.

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Importante: Questo blocco funziona solo su server Apache o LiteSpeed. Su nginx il .htaccess viene ignorato e serve una regola diversa, che trovi più sotto nella parte su nginx.

Se invece la bacheca ti rimanda al vecchio dominio, la causa è l’indirizzo del sito salvato nel database, e la soluzione è nella sezione sul database.

Se il 404 resta, il problema non sta nelle impostazioni di WordPress. Prima di toccare altro, capisci chi sta rispondendo.

Chi risponde con il 404, il server o WordPress?

Guarda la pagina d’errore. Se ha la grafica del tuo sito, con menu e logo, la richiesta arriva a WordPress e la causa sta nei dati o nei tipi di contenuto aggiuntivi.

Se è una pagina bianca e spoglia con scritto Not Found, magari con la parola Apache o nginx in fondo, la richiesta si ferma prima. La causa è nel server (il computer dell’hosting che ospita il sito), e WordPress non la vede nemmeno.

C’è anche una seconda prova, che richiede dieci secondi.

  1. In bacheca apri Articoli > Tutti gli articoli e passa il mouse sul titolo di un articolo.
  2. In basso a sinistra del browser compare un indirizzo che contiene post=123. Quel numero è l’ID dell’articolo.
  3. Apri https://tuosito.it/?p=123, con il tuo dominio e il tuo numero.

Se l’articolo si apre così ma non con il suo indirizzo normale, i contenuti ci sono tutti. Il problema è solo nel modo in cui il server legge gli indirizzi.

Aeroplanino di carta fermo ai piedi di un cartello con tre frecce che puntano in direzioni diverse, come una richiesta che non sa dove andare

Il server passa davvero le richieste a WordPress?

Gli indirizzi delle pagine di WordPress non sono file veri sul disco. Il server deve girare ogni richiesta a WordPress, e se questo passaggio manca la home funziona e tutto il resto no.

Su Apache il .htaccess manca o viene ignorato

Il punto davanti a .htaccess significa che è un file nascosto. Molti client FTP non lo mostrano di default e alcuni archivi zip o plugin di migrazione lo saltano, così sul nuovo server non arriva.

Per controllarlo ti basta il File Manager, la sezione del pannello dell’hosting che mostra i file del sito (su cPanel si chiama Gestione file).

  1. Apri il File Manager e vai nella cartella principale del sito, quella che contiene wp-config.php e le cartelle wp-admin e wp-content. Di solito si chiama public_html o httpdocs.
  2. Attiva la visualizzazione dei file nascosti. Su cPanel la trovi in Impostazioni, in alto a destra.
  3. Cerca .htaccess. Se c’è, aprilo con Modifica. Se non c’è, crea un nuovo file con quel nome esatto, punto compreso.
  4. Controlla che contenga il blocco qui sotto, che è quello standard di WordPress (WordPress Developer Resources, Apache HTTPD / .htaccess, consultata a ottobre 2026). Se manca, incollalo e salva.
  5. Ricarica in finestra anonima un articolo che dava 404.
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Se il sito sta in una sottocartella, per esempio tuosito.it/blog/, aggiungi il nome della cartella in due righe: RewriteBase /blog/ e RewriteRule . /blog/index.php [L].

Attenzione: Prima di toccare il .htaccess scaricane una copia sul tuo computer con il tasto Scarica del File Manager. Se contiene altre regole e qualcosa si rompe, ricarichi la copia e torni come prima.

Se il file c’è, è corretto e il 404 resta, il server lo sta ignorando. Su Apache 2.4 la lettura del .htaccess è spenta di default e va attivata a mano (Apache HTTP Server, tutorial .htaccess files, consultata a ottobre 2026).

La prova arriva dalla stessa documentazione. Scrivi una parola a caso nella prima riga del .htaccess, per esempio prova123, salva e ricarica il sito: se non compare un errore 500 (la pagina di errore del server), il file non viene letto. Togli subito la parola.

Su un hosting condiviso qui ti fermi e scrivi all’assistenza: “Il file .htaccess non viene letto, potete attivare AllowOverride All e mod_rewrite per il mio sito?”. Su un server tuo, un VPS con Ubuntu o Debian, lo attivi tu.

# /etc/apache2/sites-available/tuosito.conf
<Directory /var/www/tuosito>
    AllowOverride All
    Require all granted
</Directory>
sudo a2enmod rewrite              # attiva il modulo che legge le regole
sudo systemctl restart apache2    # riavvia Apache

Sei passato da Apache a nginx

nginx è un altro tipo di server, molto usato dagli hosting veloci. Non legge il .htaccess, quindi anche se l’hai copiato alla perfezione non serve a niente, e salvare i permalink dalla bacheca non cambia nulla (WordPress Developer Resources, Nginx, consultata a ottobre 2026).

Per sapere che server hai, il modo più rapido è la bacheca di WordPress: vai in Strumenti > Salute del sito, apri la scheda Info e, nella sezione Server, guarda la voce del server web. In alternativa cerca la stessa voce nel pannello dell’hosting o chiedilo all’assistenza. Molti siti che sembrano nginx sono in realtà Apache con nginx davanti come reverse proxy, e in quel caso il .htaccess funziona.

Con nginx la regola giusta va nella configurazione del server. La riga che conta è questa:

try_files $uri $uri/ /index.php?$args;

In pratica dice al server di cercare prima un file vero e, se non lo trova, di passare la richiesta a WordPress. Su un server tuo va nel file di configurazione del sito, dentro il blocco location /.

server {
    server_name tuosito.it www.tuosito.it;
    root /var/www/tuosito;          # cartella del sito
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;   # cambia in base alla tua versione PHP
    }
}

Dopo la modifica controlla la configurazione e ricaricala. Se nginx -t segnala un errore, non ricaricare e correggi prima la riga indicata.

sudo nginx -t && sudo systemctl reload nginx

Se nel vecchio .htaccess c’erano altre regole, come redirect o blocchi di sicurezza, vanno riscritte nel formato di nginx. Qui conviene farsi aiutare da chi gestisce il server.

Se il server è nginx e non puoi toccare la configurazione

Qui questa guida non basta. Nessuna impostazione di WordPress e nessun plugin può aggiungere quella regola al server.

  1. Apri un ticket all’assistenza dell’hosting e chiedi di aggiungere nella location / del sito la riga try_files $uri $uri/ /index.php?$args;, spiegando che il sito è WordPress e i permalink danno 404.
  2. Nel frattempo cerca nel pannello una voce come “Preset WordPress” o “Direttive nginx personalizzate”, che molti hosting hanno già pronta.
  3. Quando ti rispondono, ricarica un articolo in finestra anonima. Deve aprirsi con la grafica del sito.

Come tampone esistono permalink con index.php nell’indirizzo, che imposti in Impostazioni > Permalink > Struttura personalizzata scrivendo /index.php/%postname%/ (WordPress.org, Customize permalinks). Funzionano senza toccare il server, ma cambiano tutti gli indirizzi del sito, quindi li userei solo per qualche giorno.

Se l’hosting rifiuta, il problema è il servizio. Un hosting nginx che non configura i permalink di WordPress non è adatto a un sito in produzione, e la scelta sensata è cambiare piano o fornitore.

Scatolone del trasloco accanto a una casetta nuova color menta, che guarda ancora la vecchia casa blu sullo sfondo

Il database punta ancora al vecchio sito?

Il database è dove WordPress salva testi, impostazioni e indirizzi. Se la pagina 404 ha la grafica del sito, o se il sito ti rimanda al vecchio dominio, il problema di solito è lì.

siteurl e home non corrispondono al nuovo indirizzo

WordPress salva due indirizzi principali. Uno è quello che il visitatore digita, l’altro è dove stanno i file di WordPress, ed entrambi vanno scritti con https:// e senza barra finale (WordPress Developer Resources, Migrating WordPress, consultata a ottobre 2026).

Se riesci a entrare in bacheca, li controlli da lì.

  1. Vai in Impostazioni > Generali.
  2. Guarda i campi Indirizzo WordPress (URL) e Indirizzo sito (URL).
  3. Controlla che contengano il nuovo dominio, per esempio https://www.tuosito.it, senza barra alla fine.
  4. Se sono sbagliati, correggili e clicca Salva modifiche. WordPress ti chiederà di rifare il login.
  5. Apri un articolo in finestra anonima per verificare.

Se i due campi sono grigi e non si possono modificare, l’indirizzo è scritto nel file wp-config.php. Aprilo dal File Manager e cerca due righe che iniziano con define( 'WP_HOME' e define( 'WP_SITEURL': se contengono il vecchio dominio vincono sul database, quindi correggile lì.

Se non riesci nemmeno a entrare in bacheca, perché ti rimanda al vecchio sito, aggiungi queste due righe nel wp-config.php, sopra la riga che dice That’s all, stop editing!.

define( 'WP_HOME', 'https://www.tuosito.it' );     // il tuo nuovo indirizzo
define( 'WP_SITEURL', 'https://www.tuosito.it' );  // di solito uguale al primo

Scegli una versione sola del dominio, con o senza www, sempre con https. Se il sito risponde a più versioni diverse è facile finire in un loop, cioè una pagina che rimanda a se stessa all’infinito.

Il cambio di dominio nel database è stato fatto male

Quando cambi dominio, il vecchio indirizzo resta scritto in centinaia di punti del database: link negli articoli, immagini, impostazioni dei plugin. Va sostituito tutto, ma nel modo giusto.

I sintomi di una sostituzione fatta male sono link che portano al vecchio dominio, widget spariti, impostazioni del page builder azzerate. La causa quasi sempre è un “trova e sostituisci” fatto a mano sul file del database.

Il motivo è semplice da capire. Molte impostazioni sono salvate insieme alla loro lunghezza in caratteri: se cambi vecchio.it con nuovo-dominio.it a mano, il testo cambia ma la lunghezza registrata no, e WordPress scarta l’intera impostazione.

Dalla bacheca uso il plugin gratuito Better Search Replace, che la documentazione di WordPress indica proprio per questo lavoro e che gestisce il problema della lunghezza da solo.

  1. Fai un backup completo del sito dal pannello dell’hosting o con un plugin di backup.
  2. Installa Better Search Replace da Plugin > Aggiungi nuovo plugin e aprilo da Strumenti > Better Search Replace.
  3. Nel campo di ricerca scrivi il vecchio indirizzo completo, per esempio https://vecchio-dominio.it. Nel campo di sostituzione scrivi quello nuovo, per esempio https://www.nuovo-dominio.it.
  4. Seleziona tutte le tabelle dell’elenco tenendo premuto Ctrl (Cmd su Mac).
  5. Lascia spuntata l’opzione di prova (dry run) e avvia. Il plugin ti dice quante modifiche farebbe, senza toccare nulla.
  6. Se i numeri ti sembrano sensati, togli la spunta e avvia di nuovo.
  7. Ripeti per le altre varianti del vecchio indirizzo, come http:// e la versione con o senza www.
  8. Apri qualche articolo e controlla che link e immagini puntino al nuovo dominio.

Importante: Scrivi sempre l’indirizzo completo con https://, mai solo vecchio.it. Il nome nudo compare anche negli indirizzi email e in altri testi, e lo cambieresti dove non devi.

Se usi il terminale, lo stesso lavoro lo fa WP-CLI, che gestisce i dati salvati con la loro lunghezza (WP-CLI, wp search-replace, consultata a ottobre 2026).

wp db export prima-del-replace.sql     # backup del database

# prova a vuoto: mostra cosa cambierebbe, non salva nulla
wp search-replace 'https://vecchio-dominio.it' 'https://www.nuovo-dominio.it' \
  --skip-columns=guid --all-tables-with-prefix --dry-run

# esecuzione reale: stesso comando senza --dry-run
wp search-replace 'https://vecchio-dominio.it' 'https://www.nuovo-dominio.it' \
  --skip-columns=guid --all-tables-with-prefix

wp cache flush                          # svuota la cache dei dati

L’opzione --skip-columns=guid lascia stare il GUID, un codice univoco di ogni articolo che la documentazione di WordPress dice di non cambiare mai. Se lo cambi, chi segue il sito via RSS rivede tutti i vecchi articoli come se fossero nuovi.

Perché danno 404 solo prodotti, portfolio o eventi?

Se articoli e pagine funzionano e danno 404 solo sezioni come /prodotti/ o /portfolio/, il problema è il custom post type. È un tipo di contenuto aggiuntivo creato da un plugin o dal tema, come i prodotti di WooCommerce o gli eventi di un calendario.

Questi indirizzi esistono solo se il plugin o il tema che li crea è attivo. Dopo una migrazione capita spesso che non lo sia.

  1. Vai in Plugin > Plugin installati e guarda se ci sono plugin disattivati, soprattutto quelli che gestiscono prodotti, eventi o portfolio. Attivali.
  2. Vai in Aspetto > Temi e controlla che sia attivo lo stesso tema del vecchio sito, compreso il child theme (la versione personalizzata del tema) se lo usavi.
  3. Se avevi creato questi contenuti con plugin come CPT UI o ACF, controlla che le loro impostazioni ci siano ancora.
  4. Torna in Impostazioni > Permalink e clicca di nuovo Salva modifiche. Va fatto dopo aver attivato il plugin, non prima.
  5. Apri una scheda prodotto o portfolio in finestra anonima. Deve aprirsi con la sua grafica.

Con WP-CLI la stessa verifica richiede tre comandi.

wp post-type list --fields=name,public,rewrite   # tipi di contenuto registrati
wp plugin list --status=inactive                 # plugin rimasti spenti
wp rewrite list --format=csv | grep prodotti     # l'indirizzo è tra le regole?

Ho sistemato tutto, perché vedo ancora 404?

Se la correzione funziona per te ma non per altri, o i 404 compaiono e spariscono, quasi sempre c’entra una cache. È una copia salvata delle pagine che serve a velocizzare il sito, e a volte continua a mostrare le versioni vecchie.

Le svuoto in quest’ordine, dalla più vicina a WordPress alla più lontana.

  1. Svuota il plugin di cache, se usi WP Rocket, LiteSpeed Cache, W3 Total Cache o WP Super Cache. Di solito trovi il pulsante (Svuota cache, Purge All o simile) nella barra nera in alto della bacheca.
  2. Svuota la cache dell’hosting. Cerca nel pannello una voce come “Cache”, “Svuota cache” o “Purge”.
  3. Svuota Cloudflare, se lo usi. Entra nel tuo account, apri il dominio, vai in Caching > Configuration e clicca Purge Everything.
  4. Apri l’articolo in una finestra anonima. Deve aprirsi con la grafica del sito.

L’ordine conta. Se svuoti Cloudflare prima del plugin, la prima visita lo riempie di nuovo con le pagine vecchie.

Se hai accesso al terminale, wp cache flush svuota la cache interna dei dati e wp transient delete --all cancella i transient, valori temporanei che WordPress salva nel database. La documentazione di WordPress nota che possono conservare il vecchio indirizzo e che si rigenerano da soli.

Di default Cloudflare non conserva le pagine HTML, solo immagini, fogli di stile e altri file. Se vedi pagine vecchie probabilmente è attiva una regola che salva tutto, e quando il sito non dà istruzioni diverse Cloudflare tiene un 404 per 3 minuti e un redirect permanente per 120 minuti (Cloudflare Docs, Default cache behavior, aggiornata a settembre 2026).

In pratica un 404 in cache sparisce da solo in pochi minuti, mentre un redirect sbagliato può restare per due ore.

Consiglio: Fai le prove in una finestra anonima, non nella scheda aperta da ore. Il browser ricorda i redirect a lungo e può continuare a seguirne uno che hai già corretto.

Macchinina giocattolo che segue un cartello di deviazione, mentre una transenna blocca la strada dritta

Hai cambiato anche gli indirizzi delle pagine?

Se nel trasloco hai cambiato dominio, struttura dei permalink o nome di alcune pagine, i 404 sui vecchi indirizzi sono normali. Salvare i permalink non li sistema, servono redirect 301.

Un redirect 301 è un rimando permanente: chi apre il vecchio indirizzo, persona o motore di ricerca, finisce in automatico su quello nuovo. Google consiglia questo tipo di redirect, precisa che non fa perdere il valore dei link ricevuti e chiede di mantenerlo almeno un anno (Google Search Central, Site moves with URL changes, aggiornata ad agosto 2026).

Come preparo l’elenco dei vecchi indirizzi?

Prima di creare i redirect preparo un foglio di calcolo con due colonne, indirizzo vecchio e indirizzo nuovo.

  1. Apri Google Search Console, vai in Indicizzazione > Pagine ed esporta l’elenco degli indirizzi del vecchio sito.
  2. Se hai ancora la vecchia sitemap (di solito vecchio-sito.it/sitemap.xml), aggiungi anche quegli indirizzi.
  3. Accanto a ogni vecchio indirizzo scrivi la pagina nuova che ne prende il posto.
  4. Lascia vuota la seconda colonna per le pagine che non esistono più e non hanno un equivalente.

Le pagine senza equivalente possono restare in 404. Google sconsiglia di mandarle tutte alla home, perché le tratta comunque come pagine inesistenti (stessa fonte).

Come creo i redirect?

Per un sito normale uso il plugin gratuito Redirection, che si gestisce tutto dalla bacheca.

  1. Installa Redirection da Plugin > Aggiungi nuovo plugin e completa la configurazione guidata.
  2. Vai in Strumenti > Redirection e aggiungi un nuovo redirect.
  3. Come indirizzo di origine scrivi il vecchio percorso senza dominio, per esempio /vecchia-pagina/. Come destinazione scrivi l’indirizzo nuovo.
  4. Controlla che il tipo di redirect sia 301 e salva.
  5. Se hai molti indirizzi, salva il foglio come CSV, con vecchio e nuovo indirizzo su ogni riga, e caricalo dalla sezione Importa/Esporta del plugin.
  6. Apri un vecchio indirizzo in finestra anonima. Deve portarti alla pagina nuova.

Redirection ha anche un registro dei 404, che ti mostra quali vecchi indirizzi le persone stanno ancora cercando. Nel primo mese lo controllo una volta a settimana.

Se hai cambiato dominio, il plugin funziona solo se il vecchio dominio punta ancora al sito. In quel caso conviene una regola sul server, che rimanda tutto il vecchio dominio al nuovo in un colpo solo. Su Apache/Litespeed va in cima al .htaccess del vecchio dominio, prima di # BEGIN WordPress.

RewriteEngine On
# rimanda ogni pagina del vecchio dominio alla stessa pagina sul nuovo
RewriteCond %{HTTP_HOST} ^(www\.)?vecchio-dominio\.it$ [NC]
RewriteRule ^(.*)$ https://www.nuovo-dominio.it/$1 [R=301,L]

Su nginx la stessa regola va chiesta all’hosting, oppure scritta da chi gestisce il server.

server {
    server_name vecchio-dominio.it www.vecchio-dominio.it;
    return 301 https://www.nuovo-dominio.it$request_uri;
}

Dopo i redirect aggiorna anche i link interni con Better Search Replace, con la stessa procedura del cambio di dominio. Così le pagine puntano direttamente ai nuovi indirizzi, senza passare dal rimando.

Quali errori evito con i redirect?

  • Redirect a catena. Il vecchio indirizzo rimanda a un secondo, che rimanda a un terzo. Google consiglia di puntare sempre direttamente alla pagina finale.
  • Loop. Succede quando https o www vengono forzati in due posti diversi, per esempio nel plugin e in Cloudflare. Decidi un solo posto che se ne occupa.
  • 302 al posto di 301. Il 302 è un rimando temporaneo, e alcuni plugin lo usano come predefinito. Per un trasloco definitivo serve il 301.
  • 301 messi troppo presto. Prova le regole con un 302 e passa al 301 quando sei sicuro, perché un 301 sbagliato resta in memoria nel browser e su Cloudflare.

Per controllare un redirect senza strumenti tecnici usa un verificatore gratuito come httpstatus.io. Incolli il vecchio indirizzo e vedi tutti i passaggi: deve esserci un solo 301 seguito da un 200, cioè la pagina trovata.

Il primo passo resta la diagnosi. Apri un articolo che dà 404, guarda se la pagina d’errore ha la grafica del sito o è spoglia e prova lo stesso articolo con ?p=ID: in due minuti sai in quale sezione di questa guida cercare.

Se preferisci delegare il trasloco o la sistemazione dei 404, scrivimi e controllo io server, database e redirect.

Leggi anche…

Contattami

Non perdere tempo prezioso, contattami oggi stesso per discutere delle tue esigenze e richiedere un preventivo.

Iniziamo!