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:
- riducono la velocità di scansione per non sovraccaricare il server;
- riprovano più tardi gli URL che hanno risposto con errore;
- 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 Modifiedalle 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.