WordPress: correggere i permalink rotti e gli errori 404

Quando i permalink si rompono, il problema non è quasi mai il link

In WordPress un errore 404 sulle pagine interne, mentre la home continua a funzionare, quasi sempre indica un guasto nel sistema dei rewrite. Il punto è semplice: il browser chiede un URL “bello”, WordPress deve tradurlo in una richiesta valida per il server web, e qualcosa in questa catena si interrompe. Il risultato tipico è frustrante ma molto riconoscibile: articoli raggiungibili dalla bacheca, ma non dal front-end.

Il vantaggio è che questo tipo di problema si diagnostica bene. Non serve partire a caso cambiando tema, cancellando cache o reinstallando il sito. Serve invece seguire un ordine: verificare se il server risponde, controllare i permalink da WordPress, poi il file di configurazione dei rewrite e infine eventuali conflitti con plugin o regole personalizzate.

Questa guida è pensata per chi amministra un sito WordPress su hosting condiviso, VPS o pannelli come cPanel, Plesk e ambienti simili. L’obiettivo non è solo “far tornare i link”, ma capire perché si sono rotti, così da evitare che il guasto si ripresenti dopo il prossimo aggiornamento o cambio di tema.

Segnali tipici del problema

I sintomi più comuni sono questi:

• la home si apre correttamente, ma gli articoli danno 404;
• le pagine di categoria o tag non si aprono;
• gli URL funzionano solo con il parametro ?p=123;
• dopo aver migrato il sito, i permalink smettono di funzionare;
• dopo aver cambiato dominio, certificato, tema o plugin SEO, compaiono errori sulle pagine interne;
• in alcuni casi l’errore non è 404 ma una pagina bianca, un redirect loop o un 500 legato a regole errate.

Quando il problema riguarda solo gli URL “pretty”, la causa più probabile è una di queste: rewrite non rigenerati, file .htaccess mancante o corrotto, moduli server non attivi, conflitto con plugin di sicurezza o cache, oppure regole personalizzate che sovrascrivono il comportamento standard di WordPress.

Prima diagnosi: distinguere WordPress dal server

Il primo errore da evitare è trattare ogni 404 come se fosse un problema di WordPress. In realtà bisogna capire se il server sta ricevendo la richiesta e se la sta inoltrando correttamente a WordPress. Se il problema è a livello server, cambiare impostazioni nel pannello WordPress serve a poco.

Fai questa verifica semplice:

1. Apri un articolo con permalink “bello”, ad esempio /nome-articolo/.
2. Prova anche un URL con parametro, per esempio la versione con ID o una pagina di test raggiungibile in modo diretto.
3. Se la versione con parametro funziona e quella “bella” no, il problema è quasi certamente nei rewrite.

Se invece anche l’accesso diretto a file statici o a pagine semplici fallisce, il problema può essere più ampio: document root sbagliata, vhost non corretto, proxy, cache esterna, CDN o permessi errati.

Verifiche immediate da fare in WordPress

La prima azione davvero utile è rigenerare le regole dei permalink senza cambiare struttura.

1. Entra in Impostazioni > Permalink.
2. Lascia invariata la struttura attuale.
3. Clicca su Salva le modifiche.

Questo passaggio forza WordPress a riscrivere le regole di rewrite. Su molti siti basta da solo a ripristinare il comportamento corretto. L’esito atteso è immediato: gli URL che prima davano 404 tornano ad aprirsi.

Se non basta, controlla i plugin che toccano URL, sicurezza, cache, redirect o SEO. In particolare possono interferire plugin di:

• cache e ottimizzazione;
• redirect massivi;
• sicurezza con blocco di percorsi o utenti;
• multilingua;
• builder o temi che riscrivono le pagine in modo personalizzato.

Un test pratico e reversibile è disattivare temporaneamente, uno alla volta, i plugin più sospetti e riprovare l’URL che genera 404. Se il problema sparisce dopo la disattivazione di un plugin, hai trovato il conflitto.

Controllo del file .htaccess

Su Apache e LiteSpeed, il file .htaccess è spesso il cuore del problema. Se manca, è vuoto, ha regole sbagliate o è stato sovrascritto da un plugin, WordPress non riesce a gestire i permalink.

Il file si trova normalmente nella root del sito WordPress. Prima di modificarlo, fai un backup.

Percorso tipico: /public_html/.htaccess oppure la cartella document root del sito.

Se usi un file manager da pannello:

1. Apri il File Manager.
2. Mostra i file nascosti, perché .htaccess spesso non è visibile di default.
3. Scarica una copia del file prima di fare cambiamenti.

Il contenuto standard di WordPress per una installazione semplice è questo:

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

Se il file è molto diverso, prova a sostituirlo temporaneamente con questo blocco minimo, sempre dopo il backup. L’esito atteso è che gli URL inizino a funzionare senza 404. Se il sito è in sottocartella, il valore di RewriteBase va adattato.

Su hosting con Apache, verifica anche che il modulo rewrite sia attivo. Su server gestiti da pannello, in genere non lo disattivi tu, ma un problema di configurazione può comunque impedirne il funzionamento. In quel caso il 404 si presenta anche con un .htaccess corretto.

Se il sito è su Nginx o dietro proxy

Con Nginx la logica cambia: .htaccess non viene letto dal web server. Se WordPress è dietro Nginx puro, oppure Nginx come reverse proxy davanti ad Apache, le regole di rewrite devono essere impostate nel blocco server corretto.

Qui il sintomo tipico è lo stesso, ma la causa è diversa: WordPress salva i permalink, però il server non li traduce verso index.php. In questi casi bisogna controllare la configurazione del virtual host o del pannello hosting.

La verifica minima è questa: se sei su Nginx puro, cerca una regola equivalente a una fallback verso /index.php per le richieste che non corrispondono a file o directory reali. Se non hai accesso alla configurazione, il problema va risolto dal pannello o dall’hosting provider.

Permessi, ownership e document root

Un problema meno frequente ma molto reale è il permesso errato dei file o una document root sbagliata dopo una migrazione.

Controlla che:

• la root del sito punti davvero alla cartella di WordPress;
• index.php e .htaccess siano presenti nella directory giusta;
• i permessi siano coerenti con il resto dell’installazione;
• il server legga il file di configurazione corretto e non una copia vecchia.

Se hai migrato manualmente il sito, è abbastanza comune che il virtual host punti alla cartella sbagliata o che WordPress sia stato copiato in una sottocartella senza aggiornare la configurazione. In quel caso la home può persino aprirsi, ma i permalink no, perché le richieste finiscono nel posto sbagliato.

Conflitti con plugin di cache, sicurezza e redirect

Se i permalink funzionavano e hanno smesso di farlo dopo una modifica apparentemente innocua, il sospetto va ai plugin.

I casi più frequenti sono:

• plugin di cache che servono vecchie regole o pagine memorizzate;
• plugin di sicurezza che bloccano richieste verso index.php o determinati pattern di URL;
• plugin SEO o redirect che aggiungono regole duplicate;
• plugin multilingua che cambiano la struttura degli slug.

La procedura migliore è semplice e reversibile:

1. svuota prima la cache del plugin, del server e dell’eventuale CDN;
2. disattiva temporaneamente i plugin che gestiscono URL e redirect;
3. verifica un permalink problematico;
4. riattiva i plugin uno alla volta finché il problema non si ripresenta.

Se usi una CDN, controlla anche che non stia memorizzando una risposta 404 vecchia. In questo caso puoi avere il sito corretto sul server ma l’errore ancora visibile agli utenti per via della cache esterna.

Quando il problema nasce dopo una migrazione

Dopo una migrazione WordPress, i permalink rotti sono quasi un classico. Le cause più comuni sono database parzialmente aggiornato, vecchi URL nel contenuto, file mancanti, permessi incompleti, o configurazione del server non allineata al nuovo hosting.

Le verifiche da fare sono tre:

1. controlla che il dominio punti alla nuova destinazione e non alla vecchia;
2. verifica che il database sia stato importato completamente e che il prefisso delle tabelle sia coerente;
3. controlla che il file .htaccess sia stato copiato oppure rigenerato nel nuovo ambiente.

Se hai cambiato anche da Apache a Nginx, o da un hosting con regole personalizzate a un ambiente più standard, non dare per scontato che il vecchio comportamento dei rewrite sia ancora valido. Va adattato alla nuova piattaforma.

Approccio rapido da pannello hosting

Su cPanel, Plesk e ambienti simili la sequenza più sicura è questa:

1. Apri il File Manager e fai una copia di backup di .htaccess.
2. Verifica che la cartella del sito sia quella corretta.
3. Rinomina temporaneamente .htaccess in .htaccess.old.
4. Entra in WordPress e salva di nuovo i permalink per rigenerare il file.
5. Prova uno o due URL interni per confermare il ripristino.

Se il sito torna a funzionare dopo la rigenerazione, il problema era quasi certamente il file di rewrite o una regola incompatibile. Se invece non cambia nulla, il problema è più probabilmente lato server, proxy, CDN o plugin.

Approccio da terminale, solo se serve

Se hai accesso SSH e vuoi fare una verifica rapida, puoi controllare la presenza del file e il suo contenuto.

cd /percorso/del/sito
ls -la
cat .htaccess

L’esito atteso è vedere un file presente e un blocco WordPress sensato. Se il file manca, WordPress potrebbe non riuscire a gestire i permalink. Se il contenuto è strano o pieno di regole di altri plugin, conviene salvarne una copia e ripartire da una versione minima.

Per fare un backup veloce prima di intervenire:

cp .htaccess .htaccess.backup

Questo ti permette di tornare indietro subito se il nuovo file non risolve o peggiora la situazione.

Rollback sicuro se il fix non funziona

Un buon intervento tecnico deve sempre avere una via di ritorno. Se dopo la modifica il sito peggiora, il rollback più sicuro è:

1. ripristinare il backup di .htaccess;
2. riattivare i plugin disattivati uno alla volta;
3. svuotare di nuovo cache e CDN;
4. ripetere il salvataggio dei permalink da WordPress.

Se il problema nasce da una modifica lato server, non insistere con tentativi casuali. A quel punto bisogna verificare il virtual host, i moduli del web server, eventuali regole di reverse proxy e i log degli errori del server web.

Controlli finali da fare prima di considerare chiuso il problema

Dopo il fix, verifica questi punti:

• un articolo vecchio si apre correttamente;
• una pagina di categoria o tag risponde senza 404;
• la home, gli articoli e le pagine interne hanno comportamento coerente;
• non compaiono redirect anomali o loop;
• la cache del sito e della CDN è stata svuotata.

Se tutto è regolare, il problema era nel sistema di rewrite o in una sua dipendenza. Se invece il 404 resta solo per alcune sezioni, il guasto è selettivo e va cercato in regole specifiche di plugin, tassonomie personalizzate o configurazioni del tema.

In pratica: la sequenza che funziona davvero

La regola migliore è non saltare i passaggi. Prima si verifica se il problema è davvero sui permalink, poi si rigenera la configurazione da WordPress, poi si controlla .htaccess, quindi si isolano plugin e cache. È un ordine semplice, ma riduce molto il tempo perso e soprattutto evita di rompere altro.

Quando un sito WordPress mostra 404 sugli URL interni, il fix più sicuro è quasi sempre uno di questi: salvare di nuovo i permalink, ripristinare un .htaccess corretto, oppure correggere una regola server o un conflitto di plugin. Il resto è contorno, non soluzione.