Il codice di stato HTTP è il messaggio breve che accompagna ogni risposta del server e che mi dice, in pochi millisecondi, se una pagina è stata trovata, spostata, bloccata o se il problema sta nel browser, nel tema o nell’hosting. In un sito ben tenuto non serve memorizzarli tutti: basta saper leggere quelli che incidono davvero su traffico, crawling e manutenzione. Qui metto ordine tra le classi principali, i casi più utili su siti web e WordPress e il metodo pratico che uso per capire dove intervenire senza andare a tentativi.
Le informazioni essenziali da tenere a mente
- I codici HTTP si leggono per classi: 1xx informativi, 2xx ok, 3xx redirect, 4xx errore lato client, 5xx errore lato server.
- Non tutti i numeri segnalano un problema: 301, 304, 201 e 204 possono essere perfettamente normali.
- Su WordPress i casi più frequenti sono 404, 500, 503, 403 e 429, spesso legati a permalink, plugin, cache o sicurezza.
- Il primo controllo utile è sempre il contesto: una singola pagina, tutto il sito, solo gli utenti non loggati o solo alcune richieste API.
- Per diagnosticare bene servono tre elementi: intestazioni HTTP, log del server e stato di WordPress (plugin, tema, permalink, cache).
Come leggere le risposte HTTP
Nella documentazione MDN la logica è molto chiara: ogni risposta racconta l’esito di una richiesta, e il numero iniziale ti dice subito in quale zona guardare. Io parto sempre da qui, perché un 404 non va letto come un 500 e un 301 non va trattato come un errore. La differenza tra classi è il primo filtro che evita diagnosi sbagliate.
| Classe | Cosa indica | Lettura pratica |
|---|---|---|
| 1xx | Risposta informativa | Il server ha ricevuto la richiesta e sta ancora elaborando o preparando la risposta. |
| 2xx | Successo | La richiesta è andata a buon fine. Qui rientrano 200, 201 e 204. |
| 3xx | Redirezione | La risorsa è altrove oppure la risposta è stata servita da cache. Qui contano 301, 302, 304, 307 e 308. |
| 4xx | Errore lato client | La richiesta è sbagliata, incompleta, non autorizzata o il contenuto non esiste più. |
| 5xx | Errore lato server | Il problema è quasi sempre nella configurazione, nel PHP, nel proxy, nel server o in un componente che non risponde bene. |
La parte che molti sottovalutano è che il numero non basta da solo: 401 e 403 non raccontano la stessa situazione, così come 404 e 410 non hanno lo stesso significato operativo. Una volta capita la classe, bisogna scendere sui codici che contano davvero nella gestione quotidiana di un sito.
I codici che contano davvero nella gestione di un sito
Quando gestisco un sito, i numeri che controllo per primi sono quelli che influenzano accessibilità, SEO, performance e manutenzione. Qui sotto trovi i casi più importanti con una lettura concreta, non teorica.
| Codice | Significato pratico | Cosa controllo per primo |
|---|---|---|
| 200 OK | La pagina o la risorsa è stata servita correttamente. | Controllo solo se il contenuto è quello giusto e se non arriva una versione vecchia dalla cache. |
| 201 Created | Una risorsa è stata creata con successo, spesso in API o form avanzati. | Verifico che l’oggetto creato sia davvero presente e che l’endpoint restituisca i dati attesi. |
| 204 No Content | L’azione è riuscita, ma non c’è corpo nella risposta. | È normale in molte chiamate di backend e REST API. |
| 301 Moved Permanently | La risorsa si è spostata in modo permanente. | Controllo destinazione finale, canonical e assenza di catene o loop di redirect. |
| 302 Found | Redirezione temporanea. | Verifico che sia davvero temporanea, altrimenti preferisco una regola più esplicita. |
| 304 Not Modified | Il browser o la CDN riutilizzano una copia già valida. | Non è un errore: controllo solo che la cache non stia servendo contenuti obsoleti. |
| 400 Bad Request | La richiesta è malformata o non leggibile come dovrebbe. | Guardo query string, parametri, filtri di sicurezza e integrazioni API. |
| 401 Unauthorized | Serve autenticazione. | Controllo credenziali, token, basic auth, cookie e sessioni. |
| 403 Forbidden | Il server ha capito la richiesta ma rifiuta l’accesso. | Verifico permessi, plugin di sicurezza, firewall applicativi e regole lato server. |
| 404 Not Found | La risorsa non esiste all’indirizzo richiesto. | Guardo slug, permalink, rewrite rules e link rotti. |
| 410 Gone | La risorsa è stata rimossa in modo intenzionale. | Lo uso quando non voglio lasciare ambiguità ai motori di ricerca o agli utenti. |
| 429 Too Many Requests | La richiesta è stata limitata per eccesso di traffico o frequenza. | Controllo rate limiting, bot protection, API e plugin di sicurezza. |
| 500 Internal Server Error | Errore generico lato server. | Vado subito su log PHP, plugin, tema e configurazione. |
| 502 Bad Gateway | Un proxy o un gateway ha ricevuto una risposta non valida dal server a monte. | Controllo hosting, reverse proxy, PHP-FPM e CDN. |
| 503 Service Unavailable | Servizio non disponibile, spesso per manutenzione o sovraccarico. | Guardo manutenzione, picchi di carico, timeout e cache. |
| 504 Gateway Timeout | Il gateway ha atteso troppo a lungo una risposta. | Indago lentezza del backend, query pesanti e limiti di timeout. |
Nel lavoro con contenuti e siti editoriali, 301, 304, 404, 500 e 503 sono quelli che tornano più spesso. Sono anche quelli che fanno la differenza tra una migrazione ben fatta e un sito che perde traffico o fiducia. Da qui il passaggio naturale è WordPress, perché è lì che questi codici emergono in modo più visibile.
Perché WordPress genera 404, 500 e 503 più spesso di altri errori
WordPress è dinamico: gli URL vengono riscritti, i plugin intervengono sulle richieste, il tema può influenzare il rendering e la cache può cambiare completamente il comportamento percepito. La documentazione WordPress ricorda che i permalink sono URL permanenti e che, se la struttura non è allineata al server, le pagine possono rispondere con un 404 anche quando il contenuto esiste davvero. In pratica, il numero che vedi non sempre descrive il problema profondo: spesso descrive solo il punto in cui il flusso si è rotto.
404 dopo il cambio dei permalink
Questo è il caso più comune. Se cambio gli slug, migro un sito, altero la struttura dei permalink o il server non applica correttamente le rewrite rules, WordPress può continuare a pubblicare la pagina ma il percorso pubblico non la raggiunge. Qui la prima prova utile è sempre semplice: verifico la struttura dei permalink, rigenero le regole salvando le impostazioni e controllo se il problema riguarda una singola URL o tutto il sito.
500 quando un plugin rompe il caricamento
Il 500 è il campanello d’allarme più ambiguo, perché non mi dice quale componente ha fallito. Nella pratica, però, le cause più frequenti sono un plugin incompatibile, un tema con errore PHP, una modifica manuale nel file di configurazione o un limite di memoria troppo stretto. WordPress Recovery Mode aiuta proprio in questi casi: permette di rientrare nell’area admin quando un errore fatale blocca il normale accesso e indica spesso il componente da isolare.
503 tra manutenzione e sovraccarico
Il 503 non è sempre negativo. Può comparire durante una manutenzione programmata, un deploy o un periodo di carico elevato. Il problema nasce quando resta attivo più del dovuto, oppure quando una cache mal configurata lo serve anche agli utenti che non dovrebbero vederlo. In un sito editoriale o ad alto traffico, questo codice merita attenzione perché segnala una disponibilità solo temporaneamente compromessa, non un semplice errore di contenuto.
Leggi anche: Cos'è un blog? Guida completa per farlo crescere con WordPress
403 e 401 quando l’accesso è bloccato
Su WordPress questi codici emergono spesso in aree amministrative, API, media protetti o richieste filtrate da plugin di sicurezza. Il 401 dice, in sostanza, che manca l’autenticazione corretta; il 403 dice che l’autenticazione può anche esserci, ma l’accesso è negato. Se li confondo, finisco per controllare il posto sbagliato: credenziali e token nel primo caso, permessi, firewall e regole di accesso nel secondo. Il passaggio successivo è quindi capire come diagnosticare tutto con ordine.
Come diagnostico il problema senza andare a tentativi
Quando devo capire perché una risposta HTTP non torna, parto sempre da una sequenza precisa. Mi evita il classico errore di cambiare dieci cose insieme senza sapere quale abbia davvero funzionato.
- Controllo il contesto: il problema riguarda una sola pagina, tutto il sito, una sola lingua, gli utenti non loggati o solo il backend?
-
Guardo le intestazioni nel pannello Network del browser o con un controllo tipo
curl -I: il codice è corretto, c’è un redirect, c’è unLocation, la cache sta intervenendo? - Distinguo frontend e backend: se una pagina pubblica va in errore ma il pannello admin funziona, il problema è spesso su tema, cache o routing; se cade tutto, salgo subito verso plugin, PHP e hosting.
- Svuoto le cache solo dopo aver capito quale layer le produce: browser, plugin, server, CDN. Farlo alla cieca non serve.
- Su WordPress verifico i permalink: se c’è un 404 dopo un cambio di struttura o di tema, io riparto quasi sempre da lì prima di cercare colpe altrove.
- Controllo i log: errore PHP, log del web server, debug log di WordPress e, se serve, log del proxy o della CDN.
- Disattivo temporaneamente plugin o tema solo quando il quadro mi suggerisce un conflitto reale, non come gesto automatico.
Ci sono casi in cui questo flusso si chiude in pochi minuti: per esempio, un 301 che finisce in un loop, un 404 dopo un cambio di slug o un 500 causato da un plugin appena aggiornato. In altri casi serve più pazienza, ma la logica non cambia: prima osservo la risposta, poi cerco il punto del sistema che la produce. Da qui vale la pena chiarire un equivoco molto comune.
Quando il codice non indica un guasto
Molti problemi nascono non dal server, ma da una lettura frettolosa del numero. Un 301 ben impostato durante una migrazione è corretto, non sospetto. Un 304 significa spesso che cache e browser stanno lavorando bene. Un 201 o un 204, soprattutto nelle API o nei flussi di back office, sono segnali normali di successo. Anche un 410 può essere una scelta precisa se voglio rimuovere una pagina senza lasciare ambiguità.
Io faccio attenzione soprattutto a due casi. Il primo è il 301 che funziona ma porta alla destinazione sbagliata, o peggio entra in catena con altri redirect: qui il numero è giusto, il percorso no. Il secondo è il 304 che, in un sito con contenuti aggiornati spesso, può nascondere problemi di cache troppo aggressiva. In entrambi i casi non bisogna “correggere il codice”: bisogna correggere la logica del flusso.Questa distinzione è utile anche in chiave editoriale e SEO, perché evita falsi allarmi e interventi distruttivi. Non tocco un redirect solo perché vedo un 3xx; lo tocco se la destinazione, la permanenza o la catena non sono quelle che voglio davvero. È l’ultima verifica che farei prima di intervenire sul sito.
Le verifiche che farei prima di toccare il sito
Se dovessi ridurre tutto a una routine pratica, partirei sempre da cinque controlli: URL esatto, codice restituito, catena di redirect, stato della cache e presenza di errori nei log. Su WordPress aggiungo subito permalink, plugin di sicurezza, tema attivo e, quando serve, Recovery Mode. È un ordine che mi fa risparmiare tempo perché separa il sintomo dal punto in cui nasce.
La regola più utile è semplice: se il problema riguarda una sola risorsa, penso prima a URL, rewrite rules e redirect; se riguarda tutto il sito, salgo verso hosting, PHP, plugin e proxy. Quando tengo fermo questo schema, il numero nella risposta diventa un indizio affidabile e non un’etichetta generica. Ed è proprio così che i codici di risposta smettono di sembrare rumore e diventano uno strumento operativo.
