Un errore 404 WordPress non richiede sempre la stessa correzione. Può segnalare un URL digitato male, una pagina rimossa, un permalink non risolto oppure una regola server incoerente. Prima di cambiare plugin o file, bisogna capire quali URL falliscono e quale risultato dovrebbe ottenere l’utente.
Questa guida propone una diagnosi progressiva: parte dai controlli reversibili, distingue i casi più comuni e aiuta a scegliere tra ripristino della pagina, redirect permanente e risposta 404 corretta.
Errore 404 WordPress: cosa controllare in breve
Il primo controllo non riguarda il file .htaccess, ma l’estensione del problema. Apri l’URL in una finestra privata, prova un secondo collegamento interno e verifica se la homepage e l’area amministrativa funzionano.
- copia l’URL esatto che restituisce 404 e annota da dove proviene;
- controlla se il contenuto esiste ancora ed è pubblicato;
- verifica se fallisce un solo URL, un gruppo di pagine o tutte le pagine interne;
- ricostruisci cosa è cambiato prima dell’errore: slug, plugin, migrazione, dominio o configurazione server;
- decidi il risultato corretto: mostrare il contenuto, reindirizzare verso un equivalente oppure mantenere il 404.
Questa classificazione evita il riflesso di reindirizzare tutto alla homepage o di sostituire configurazioni che potrebbero essere corrette.
Capire se il 404 riguarda un URL o l’intero sito
La distribuzione dell’errore è il dato più utile per scegliere il percorso di diagnosi.
| Sintomo | Prima verifica | Area probabile |
|---|---|---|
| Un solo articolo o pagina restituisce 404 | Stato del contenuto, slug, link di origine e cestino | URL o contenuto specifico |
| Tutte le pagine interne falliscono, la homepage funziona | Impostazioni dei permalink e regole di riscrittura | Routing WordPress o server |
| Fallisce un tipo di contenuto, una categoria o un archivio | Slug duplicati, rewrite del plugin o del tema | Custom post type e regole specifiche |
| Il 404 compare dopo una migrazione | Dominio, sottocartella, mappa URL e configurazione del nuovo server | Migrazione o ambiente hosting |
| Anche wp-admin o il sito mostrano altri errori | Messaggio HTTP, log e disponibilità del server | Problema generale, non un semplice 404 |
Quando il malfunzionamento non è limitato agli URL pubblici, è più utile seguire la diagnosi per un sito WordPress bloccato. Se invece il 404 compare in una richiesta dell’editor a blocchi, il percorso corretto è quello dedicato a Gutenberg e alla REST API.
Quando l’errore 404 WordPress riguarda una sola pagina
Apri il contenuto in WordPress e verifica che sia pubblicato, che non si trovi nel cestino e che lo slug corrisponda all’URL richiesto. Controlla anche il link che ha portato all’errore: potrebbe contenere un refuso, un vecchio percorso o parametri aggiunti da una campagna.
Se lo slug è stato modificato, non ripristinarlo automaticamente. Prima individua i collegamenti interni, le campagne e gli eventuali backlink che usano il vecchio indirizzo. Quando esiste una nuova pagina realmente equivalente, un redirect permanente può accompagnare utenti e motori verso la destinazione corretta. La documentazione Google sui redirect indica i redirect permanenti lato server come soluzione appropriata quando una risorsa si è spostata stabilmente.
Se il contenuto è stato eliminato e non esiste un sostituto pertinente, una risposta 404 può essere corretta. Reindirizzare ogni URL mancante alla home nasconde il problema senza offrire una destinazione utile.
Quando tutte le pagine interne restituiscono 404
Homepage funzionante e pagine interne non trovate indicano spesso che WordPress non riesce a tradurre i permalink nei contenuti corrispondenti. In questo scenario controlla Impostazioni → Permalink senza cambiare la struttura scelta. La documentazione ufficiale della schermata Permalink chiarisce che la visita alla schermata aggiorna le regole di riscrittura; il salvataggio serve quando si modificano effettivamente le impostazioni.
Dopo il controllo prova più URL e svuota soltanto le cache coinvolte. Se il problema resta, verifica quale web server gestisce il sito. Su Apache le regole possono dipendere da .htaccess; su Nginx la configurazione è a livello server e WordPress non può modificarla automaticamente. La guida WordPress per Nginx documenta questa differenza.
Non sostituire alla cieca il contenuto di .htaccess e non applicare configurazioni Nginx trovate online senza verificare installazione, sottocartelle, multisito, cache e proxy. Prima conserva una copia del file e, se il server è gestito dal provider, coinvolgi l’assistenza hosting.
Errore 404 dopo migrazione, aggiornamento o nuovo plugin
La vicinanza temporale aiuta a stabilire la priorità dei controlli, ma non dimostra da sola la causa. Dopo una migrazione confronta dominio, protocollo, percorso di installazione e struttura degli URL prima e dopo il trasferimento. Verifica inoltre che la nuova infrastruttura applichi le regole adatte al web server effettivamente in uso.
Quando il problema interessa soltanto contenuti creati da un plugin, come un tipo di contenuto personalizzato, controlla conflitti tra slug e pagine esistenti. La guida ufficiale agli errori comuni di WordPress tratta separatamente i 404 dei permalink e quelli dei custom post type: è un buon motivo per non usare una sola soluzione per entrambi.
Prima di disattivare componenti su un sito operativo, predisponi backup e rollback. Quando possibile, riproduci l’errore in staging e testa un elemento alla volta. Annotare URL, orario, modifica recente ed esito rende la diagnosi ripetibile.
Ripristino, redirect o 404: quale risposta scegliere
| Stato reale della risorsa | Azione coerente | Errore da evitare |
|---|---|---|
| Il contenuto esiste e dovrebbe essere raggiungibile | Correggere routing, permalink o configurazione | Reindirizzare altrove senza ripristinare la pagina |
| La risorsa si è spostata e ha un equivalente diretto | Usare un redirect permanente verso la nuova destinazione | Inviare ogni vecchio URL alla homepage |
| La risorsa è stata rimossa senza sostituto | Restituire 404 o 410 e offrire navigazione utile | Mostrare una pagina di errore con codice 200 |
| La pagina esiste ma Google la considera soft 404 | Controllare contenuto, rendering, risorse e codice HTTP | Aggiungere testo generico senza risolvere il problema |
Google spiega che una pagina inesistente dovrebbe restituire 404 o 410, mentre una risorsa trasferita con un sostituto chiaro può usare un 301. Una pagina che comunica un errore ma restituisce 200 può essere classificata come soft 404. La scelta dipende quindi dallo stato reale del contenuto, non dal desiderio di eliminare qualsiasi segnalazione da Search Console.
Come verificare che l’errore 404 WordPress sia risolto
La comparsa della pagina nel browser è soltanto il primo controllo. Dopo l’intervento:
- prova l’URL originale e la destinazione finale in una finestra privata;
- verifica più pagine, articoli, archivi e tipi di contenuto coinvolti;
- controlla menu, breadcrumb e link interni che puntavano al vecchio indirizzo;
- verifica il codice HTTP e l’assenza di catene o loop di redirect;
- svuota e ritesta separatamente cache WordPress, server e CDN quando presenti;
- controlla che editor, form e funzioni critiche non abbiano subito regressioni;
- documenta causa, correzione e procedura di ripristino.
Per URL importanti già pubblici, l’ispezione URL di Search Console può aiutare a verificare la risposta osservata da Google. Non è però necessario richiedere l’indicizzazione di ogni 404 corretto e la richiesta non garantisce inclusione o ranking.
Quando fermarsi e chiedere assistenza
Conviene evitare tentativi diretti in produzione quando non esiste un backup, il sito gestisce ordini o lead, non conosci il web server, il problema è comparso dopo una migrazione oppure servono modifiche a file e configurazioni. Anche un errore intermittente, un redirect loop o differenze tra utenti e crawler richiedono evidenze e log, non una sequenza casuale di correzioni.
BNZ Solutions offre consulenza e assistenza WordPress per delimitare il problema, individuare la causa e definire un intervento controllato. Per rendere la diagnosi più utile, prepara gli URL coinvolti, l’orario del primo errore, le modifiche recenti e i test già eseguiti.
