Un URL che restituisce un codice di errore HTTP non indica sempre lo stesso malfunzionamento. Tra una richiesta malformata (400), una pagina eliminata (404) e un server sovraccarico (503), la causa, l’impatto sull’indicizzazione e le misure da adottare sono radicalmente diversi. Valutare le differenze tra questi codici permette di dare priorità alle correzioni e limitare i danni alla SEO.
Codici di errore HTTP: differenze d’impatto tra le famiglie 4xx e 5xx
La prima cifra del codice di stato indica da quale parte si trova il problema. Le famiglie 4xx e 5xx hanno un impatto molto diverso sulla scansione di un sito da parte dei robot di Google.
| Codice | Famiglia | Origine del problema | Conseguenze sull’indicizzazione |
|---|---|---|---|
| 400 | 4xx (client) | URL malformato, caratteri non codificati, parametro mancante | La pagina viene trattata come inesistente e rimossa dall’indice dopo alcuni tentativi |
| 403 | 4xx (client) | Accesso negato dal server (autorizzazioni, .htaccess) | La pagina non viene indicizzata finché l’accesso resta bloccato |
| 404 | 4xx (client) | Pagina eliminata, URL modificato senza reindirizzamento, link non funzionante | La pagina viene rimossa gradualmente dall’indice |
| 500 | 5xx (server) | Errore interno: script difettoso, configurazione compromessa | Rallentamento della scansione dell’intero sito |
| 502 | 5xx (server) | Risposta non valida ricevuta dal proxy o dal gateway | Come per il 500, la scansione rallenta |
| 503 | 5xx (server) | Server non disponibile (manutenzione, sovraccarico) | Scansione sospesa; le pagine già indicizzate potrebbero essere rimosse se l’errore persiste |
Il punto da ricordare: un errore 5xx persistente può comportare la rimozione di pagine già indicizzate. Un 404 isolato, invece, non ha conseguenze concrete sul resto del sito.
Google specifica che le risposte 5xx e 429 rallentano temporaneamente i suoi robot di scansione. Se il problema persiste, l’impatto si estende agli altri URL dell’host. Una guida dettagliata spiega come correggere un URL non valido del server, distinguendo con precisione ogni famiglia di codici.
Errore in robots.txt: il caso che blocca la scansione dell’intero sito
I concorrenti trattano raramente questo scenario, che può però causare i danni più estesi. Una risposta 5xx al file robots.txt sospende la scansione dell’intero host. Google prova a recuperare questo file prima di ogni sessione di scansione. Se riceve un errore del server, preferisce non eseguire la scansione piuttosto che rischiare di accedere a pagine vietate.
La diagnosi parte quindi da questo file. Verificarne l’accessibilità richiede solo pochi secondi: basta inviare una richiesta diretta dal browser (votredomaine.com/robots.txt). Se la pagina restituisce un codice 200 con contenuti leggibili, il problema si trova altrove.
Quando il proxy nasconde la vera causa
Un errore 502 o 504 su robots.txt può dipendere da un intermediario (reverse proxy, CDN) e non dal server applicativo. Per individuare l’origine del problema, occorre esaminare la comunicazione tra il proxy e il server upstream. I log del proxy (Nginx, Varnish, Cloudflare) indicano se la richiesta ha raggiunto il server di origine o se è scaduta durante il percorso.
Confondere un timeout del proxy con un guasto dell’applicazione porta a correzioni inutili del codice, quando il problema riguarda invece la configurazione di rete.
Rilevare gli URL non validi: metodi e strumenti da confrontare
Un solo strumento non basta. Ogni fonte offre una prospettiva diversa sul rilevamento e confrontarle permette di evitare punti ciechi.
- Il rapporto «Statistiche di scansione» di Google Search Console mostra la frequenza degli errori riscontrati da Googlebot, il tipo di errore (5xx, 404, timeout DNS) e la sua evoluzione nel tempo. È la prospettiva del motore di ricerca.
- I log del server (access.log, error.log) forniscono i dati grezzi nel dettaglio: indirizzo IP del client, URL richiesto, codice restituito, ora esatta. Permettono di individuare picchi di errori legati a un rilascio o a un sovraccarico.
- Un crawler come Screaming Frog o Sitebulb esplora il sito seguendo i link interni e segnala tutti gli URL che restituiscono un codice anomalo. Rileva anche i link non funzionanti nella struttura dei collegamenti interni, invisibili da Search Console.
Confrontare Search Console e i log del server resta il metodo più affidabile. Search Console segnala gli URL che Google non è riuscito a raggiungere; i log rivelano perché e quando il server ha restituito l’errore.
Errore DNS o timeout: distinguere i falsi positivi
Un problema DNS non significa che il server sia fuori servizio. Il server DNS potrebbe essere temporaneamente irraggiungibile anche se il sito funziona normalmente. Google segnala questi casi in Search Console come «Errore DNS». Prima di apportare modifiche all’applicazione, verificare la risoluzione DNS con uno strumento come dig o nslookup permette di escludere questa ipotesi.
Correggere gli errori del server: stabilire le priorità in base al codice e alla durata
Non tutti gli errori richiedono la stessa urgenza. Un 503 temporaneo con un’intestazione Retry-After è meno grave di un 500 permanente su una pagina con molto traffico organico.
Manutenzione programmata e intestazione Retry-After
Lo standard HTTP prevede che un server possa rispondere con un 503 e includere un’intestazione Retry-After per indicare ai robot quando riprovare. Senza questa intestazione, Google tratta il 503 come un normale incidente e rallenta la scansione senza sapere quando riprovare. Aggiungere questa intestazione durante una manutenzione programmata limita le conseguenze sull’indicizzazione.
Reindirizzamenti 301 per i 404 ricorrenti
Una pagina eliminata che riceveva link in entrata perde tutto il suo valore SEO se resta in 404. Un reindirizzamento 301 alla pagina più pertinente trasferisce la maggior parte dei segnali. Reindirizzare tutti i 404 alla homepage, invece, è controproducente: Google finisce per ignorare questi reindirizzamenti generici.
La selezione si effettua confrontando due dati: il numero di link in entrata verso l’URL in errore (tramite Search Console o Ahrefs) e il volume di traffico che generava prima di essere eliminato. Gli URL senza link e senza traffico possono restare in 404 senza conseguenze.
Il dato che emerge nel complesso è questo: gli errori 5xx persistenti compromettono la scansione dell’intero sito, mentre gli errori 4xx restano circoscritti alla pagina interessata. Verificare l’accessibilità di robots.txt e confrontare i rapporti di Search Console con i log del server sono i due controlli da eseguire per primi in caso di incidente.
