⌕ SEO tecnico

Errori 5xx, 429 e manutenzione: come reagiscono i crawler

Cosa succede alla scansione se il server risponde 500, 503 o 429, come gestire una manutenzione e perché firewall e CDN possono bloccare i motori.

Un sito può avere contenuti eccellenti e una struttura impeccabile, ma se il server risponde con errori nel momento in cui passa il crawler, il motore non vede nulla di tutto questo. Gli errori lato server sono un segnale che i motori prendono sul serio: indicano che il sito non è in grado di reggere le richieste, e la loro reazione naturale è rallentare. Se gli errori durano, le pagine possono uscire dall'indice.

I codici da conoscere

Codice Significato Come lo interpreta un crawler
500 errore interno generico problema del server, riprovare più tardi
502 gateway non valido il proxy non riceve risposta valida dal server di origine
503 servizio non disponibile indisponibilità temporanea, riprovare
504 timeout del gateway il server di origine è troppo lento
429 troppe richieste il client deve rallentare

Tutti i 5xx dicono la stessa cosa di fondo: il problema è del server, non della pagina. Il 503 e il 429 aggiungono un'informazione utile: la situazione è temporanea.

Come reagiscono i motori

Davanti a errori frequenti, i crawler:

  1. riducono la velocità di scansione per non sovraccaricare il server;
  2. riprovano più tardi gli URL che hanno risposto con errore;
  3. se l'errore persiste per molto tempo, possono rimuovere le pagine dall'indice, perché non hanno più conferma che esistano.

Il punto delicato è che, dopo la correzione, la velocità di scansione risale gradualmente. Un periodo di errori può quindi rallentare l'aggiornamento dell'indice anche per un po' di tempo dopo che il problema è risolto.

Il caso speciale del robots.txt

Prima di scansionare un sito, il crawler richiede robots.txt. Se questo file risponde con un 404, il motore considera il sito senza restrizioni. Se invece risponde con un errore 5xx, il motore non sa quali regole valgono e, per prudenza, può sospendere la scansione dell'intero sito finché il file non torna disponibile. Un robots.txt servito da un'applicazione lenta o fragile è quindi un punto debole: conviene servirlo come file statico.

Manutenzione programmata

Quando un sito deve andare offline per un aggiornamento, la risposta corretta è:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
  • 503 comunica che l'indisponibilità è temporanea;
  • Retry-After indica dopo quanti secondi, o a quale data e ora, riprovare.

Gli errori da evitare:

  • mostrare una pagina «sito in manutenzione» con codice 200: il motore la scansiona come contenuto normale e può sostituirla, nell'indice, al contenuto reale di tutte le pagine;
  • reindirizzare tutti gli URL a una pagina di manutenzione con un 302;
  • tenere il 503 per giorni: è pensato per interruzioni brevi. Un'indisponibilità prolungata viene trattata come un problema persistente.

Nel mio lavoro preferisco evitare del tutto la manutenzione con sito spento: con un rilascio ben organizzato, preparando la nuova versione accanto alla vecchia e poi scambiandole, il periodo di indisponibilità si riduce a pochi secondi o a zero.

Il codice 429 e la limitazione delle richieste

Un sistema di limitazione delle richieste protegge il server da abusi, ma deve essere tarato in modo da non colpire i crawler legittimi. Rispondere 429 a un crawler gli chiede di rallentare: va bene come misura temporanea, ma se diventa la norma, la scansione si riduce in modo permanente.

Se il server fatica a reggere il ritmo dei crawler, le soluzioni strutturali sono migliori:

  • cache delle pagine più richieste;
  • riduzione degli URL inutili da scansionare, come parametri e filtri;
  • risorse statiche servite da una CDN;
  • risposte 304 Not Modified alle richieste condizionali.

Quando a bloccare è il firewall

Un problema frequente e difficile da vedere: il server funziona benissimo, ma un firewall applicativo, una protezione anti-bot o una CDN risponde ai crawler con un 403, una pagina di verifica o un errore. Dal browser dell'amministratore tutto sembra a posto.

Segnali tipici:

  • negli strumenti per webmaster compaiono errori di scansione che nessuno riesce a riprodurre;
  • nei log della CDN le richieste dei crawler ricevono risposte diverse da quelle degli utenti;
  • lo strumento di controllo URL mostra una pagina di verifica anziché il contenuto.

La soluzione è consentire esplicitamente i crawler verificati, riconosciuti tramite DNS inverso o tramite gli elenchi di indirizzi pubblicati dai motori, e non soltanto in base allo user agent.

Monitorare

  • Rapporto sulle statistiche di scansione negli strumenti per webmaster: mostra le risposte per codice e i tempi medi.
  • Log del server e della CDN: filtra le richieste dei crawler e conta gli errori per giorno.
  • Monitoraggio esterno della disponibilità, con avvisi immediati in caso di errori.
  • Tempo di risposta: un server che rallenta precede spesso un server che va in errore.

In sintesi

  • Gli errori 5xx fanno rallentare la scansione e, se persistono, uscire le pagine dall'indice.
  • Un robots.txt che risponde 5xx può bloccare la scansione dell'intero sito.
  • Per la manutenzione usa 503 con Retry-After, mai una pagina con codice 200.
  • Il 429 è un freno temporaneo; per i carichi alti servono cache e meno URL inutili.
  • Verifica che firewall e CDN non blocchino i crawler legittimi.
MM
Marco Marzaduri

Marco Marzaduri si occupa di cybersecurity, informatica forense e sviluppo web. Laureato in informatica, unisce il rigore dell'analisi tecnica all'attenzione per le persone che usano la tecnologia.

Leggi anche