429 Too Many Requests: guida al rate limiting

TL;DR — Un 429 Too Many Requests significa che il server ha detto a un visitatore o a un bot: “stai chiedendo troppe pagine troppo velocemente, rallenta”. Si chiama rate limiting. La buona notizia per la SEO è che 429 è l’unico errore della sua famiglia che Google gestisce con cautela. Invece di rimuovere le pagine, Googlebot rallenta e per un po’ esegue il crawl più lentamente. Diventa un problema solo se il server continua a inviare 429 per giorni.

Che cosa comunica davvero un 429

Ogni volta che un browser, uno script o un crawler di un motore di ricerca chiede una pagina al server, il server risponde con un codice di stato. 200 significa “ecco la pagina”. Un 429 significa “hai fatto troppe richieste in una finestra breve, quindi a questa non rispondo: torna più tardi”.

I server usano 429 intenzionalmente per proteggersi. Se un visitatore (o un bot) martella il sito abbastanza da rallentarlo per tutti gli altri, restituire 429 è il modo in cui il server dice smettila per un po’. Una risposta 429 ben formata include anche un’intestazione Retry-After, cioè una nota che dice al client quanti secondi attendere prima di riprovare. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Perché 429 è l’errore “gentile” per la SEO

Ecco la parte che sorprende molte persone. 429 appartiene al gruppo degli “errori client 4xx”, accanto a codici come 403 Forbidden e 404 Not Found. Questi ultimi sono una cattiva notizia se Google continua a vederli: alla fine Google rimuove quelle pagine dai risultati.

429 è l’eccezione. Google legge un 429 come “server overloaded, slow down” (traduzione) «il server è sovraccarico, rallenta», proprio come legge un errore server 503 o 500. Invece di rimuovere le pagine, Googlebot esegue il crawl del sito più lentamente per un periodo. Google raccomanda proprio 429 come modo corretto per rallentare un crawler e avverte espressamente di non usare 403 o 404 per farlo. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Quando 429 diventa un problema

Un 429 occasionale è del tutto normale e si risolve da solo: quando il server smette di inviarlo, Google aumenta nuovamente la velocità di scansione senza che tu debba chiedere nulla.

Il pericolo è quando i 429 persistono. Se Googlebot continua a ricevere 429 sulle stesse pagine per più di uno o due giorni, Google può iniziare a rimuoverle dall’indice, perché dal lato di Google il sito sembra guasto e non disponibile da giorni. Quindi 429 è uno strumento a breve termine, non un’impostazione permanente.

Che cosa fare

• Se non volevi inviare 429 (compaiono a sorpresa in Google Search Console o nel tuo strumento di crawl), qualcosa sta applicando un limite troppo aggressivo, spesso un plugin di sicurezza, un firewall (WAF) o il tuo hosting/CDN. Trovalo e allenta il limite, così smette di bloccare i motori di ricerca reali.
• Se invece volevi inviarli — per esempio perché il server è sotto carico pesante — va bene: limita il periodo e aggiungi un’intestazione Retry-After. Disattiva il comportamento entro uno o due giorni.

Vuoi le istruzioni di configurazione del server, la formulazione esatta di Google e i miti più comuni? Passa alla scheda Avanzato.

TL;DR — 429 è l’unico codice 4xx che Google tratta come un 5xx: quando incontra un numero significativo di risposte 500/503/429, lo interpreta come un segnale di sovraccarico del server e limita il crawl rate di Googlebot a livello dell’intero hostname, invece di rimuovere i contenuti. È l’unico codice che Google approva per rallentare un crawler: mai 403 o 404. La documentazione di Google suggerisce per le emergenze “a couple of hours, or 1–2 days.” (traduzione) «un paio d’ore o 1–2 giorni.», non una finestra garantita come sicura; 429 persistenti sugli stessi URL possono farli rimuovere dall’indice e la limitazione ricomincia ad aumentare (non necessariamente subito o fino al livello precedente) quando il volume di errori diminuisce. RFC 6585 dice che un 429 DOVREBBE spiegare la condizione e PUÒ includere Retry-After: inviarlo è una buona pratica raccomandata, non un requisito di conformità. Limita il traffico giusto e verifica l’identità dei crawler prima di scrivere eccezioni.

Che cos’è 429 a livello di protocollo

Direttamente dalla specifica, nelle parole di MDN: “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (traduzione) «Il codice di stato di errore client HTTP 429 Too Many Requests indica che il client ha inviato troppe richieste in un certo intervallo di tempo. Questo meccanismo per chiedere al client di rallentare si chiama comunemente rate limiting.» Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests Gloss italiano: Il codice 429 indica che il client ha inviato troppe richieste in un determinato intervallo; chiedere al client di rallentare si chiama comunemente rate limiting.

RFC 6585 §4 è più precisa di quanto lo siano molte sintesi. Una rappresentazione 429 DOVREBBE spiegare la condizione e PUÒ includere un’intestazione Retry-After con il numero concreto di secondi (RFC 9110 ammette anche una data HTTP) da attendere prima di riprovare: Retry-After è una pratica raccomandata, non un requisito di conformità. La specifica non definisce neppure come identificare un client o come contare le richieste; lo lascia a chi emette la risposta (per IP, sessione, chiave API, risorsa: è una policy di implementazione, non di protocollo). Un’ultima regola facile da perdere: RFC 6585 dice che una risposta 429 non deve essere memorizzata da una cache. Se vedi un 429 apparentemente memorizzato o riprodotto mentre l’origine è sana, il problema è un intermediario (CDN, proxy), non una nuova decisione dell’origine.

Nella mia guida Codici di stato HTTP e relativo impatto SEO l’ho sempre formulato in modo semplice: 429 è “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (traduzione) «una forma di rate limiting per proteggere il server perché il client gli ha inviato troppe richieste troppo rapidamente.» Tecnicamente è un errore del client: il client ha sbagliato chiedendo troppo. Ma è proprio qui che la storia SEO diverge dalla specifica. Gloss italiano: 429 è una forma di rate limiting per proteggere il server quando il client invia richieste troppo velocemente.

L’unica eccezione tra i codici 4xx

Il fatto più importante di questa pagina è: Google non tratta 429 come il resto della famiglia 4xx. Gary Illyes ha scritto un intero post sul blog Google Search Central nel febbraio 2023, perché abbastanza siti e CDN stavano usando male i 404 per limitare Googlebot e Google ha dovuto dire loro di smettere.

La sua regola è: “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (traduzione) «L’unica eccezione è 429, che sta per “troppe richieste”. Questo errore segnala chiaramente a qualsiasi robot corretto, compreso Googlebot, che deve rallentare perché sta sovraccaricando il server.» E, sul rovescio della medaglia, il riferimento di Google sui codici di stato dice: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (traduzione) «Non usare i codici di stato 401 e 403 per limitare il crawl rate. I codici 4xx, tranne 429, non hanno effetto sul crawl rate.» Gloss italiano: 429 è l’eccezione: segnala a un bot corretto, compreso Googlebot, di rallentare perché sta sovraccaricando il server; 401 e 403 non limitano il crawl rate.

Quindi, nello stesso momento in cui 403 e 404 fanno rimuovere i contenuti da Search, 429 produce un rallentamento temporaneo. Google lo raggruppa letteralmente con gli errori server: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traduzione) «I crawler di Google trattano il codice di stato 429 come un segnale che il server è sovraccarico e lo considerano un errore server.» Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate Gloss italiano: 429 segnala un sovraccarico e viene trattato come errore server per la scansione, mentre 403 e 404 rimuovono il contenuto.

Questo rende 429 il parente utile di 503 Service Unavailable (il segnale tradizionale di manutenzione o indisponibilità temporanea) e l’opposto esatto di 403 Forbidden, che è lo strumento sbagliato per il rate limiting, nonostante molti firewall lo usino come valore predefinito.

L’impatto sul crawl rate riguarda l’intero hostname, oltre una soglia

Qui vengono confusi due ambiti diversi, che conviene separare. Il modo in cui tu conti e applichi un rate limit — per IP, sessione, chiave API, risorsa o server — è una tua policy: la specifica HTTP non lo definisce. Ciò che Google fa con gli errori che osserva è un comportamento documentato distinto, condizionato dal volume, non da una singola risposta: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (traduzione) «L’infrastruttura di scansione di Google riduce il crawl rate del sito quando incontra un numero significativo di URL con codici di stato HTTP 500, 503 o 429.» Quando la soglia viene raggiunta, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (traduzione) «il crawl rate ridotto riguarda l’intero hostname del sito, sia gli URL che restituiscono errori sia quelli che restituiscono contenuti.»

In altre parole, se restituisci 429 a un sottoinsieme di pagine (per esempio un percorso API pesante) con un volume reale, Googlebot rallenta il crawl dell’intero hostname, comprese le pagine che continuano a restituire 200. Di solito è l’effetto voluto quando vuoi ridurre il carico totale. Ma un solo 429 isolato su un percorso non dimostra da sé un effetto a livello hostname: la formulazione di Google parla di “a significant number” di risposte d’errore, non di una singola risposta. Evidence for this claim When Google encounters a significant number of 500, 503, or 429 responses, its documented crawl-rate reduction affects the whole hostname, including error URLs and URLs still returning content; one isolated 429 does not establish that site-wide effect. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

L’indicazione di 1–2 giorni: quando 429 diventa rischioso

429 è un segnale a breve termine e Google offre un’indicazione concreta per le emergenze, non una finestra garantita come sicura né un limite rigido: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traduzione) «Se devi ridurre urgentemente il crawl rate per un breve periodo (per esempio alcune ore o 1–2 giorni), restituisci agli accessi dei crawler un codice di risposta HTTP 500, 503 o 429 invece di 200.» Gloss italiano: Per ridurre urgentemente il crawl rate, Google indica un periodo breve, per esempio qualche ora o 1–2 giorni, usando 500, 503 o 429 invece di 200.

Oltre quel periodo entri in una zona più rischiosa, anche se Google lo presenta come possibilità, non come certezza: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (traduzione) «Non raccomandiamo di farlo per un periodo lungo, cioè oltre 1–2 giorni, perché potrebbe avere un effetto negativo sulla presenza del sito nei prodotti Google… se Googlebot osserva questi codici sullo stesso URL per più giorni, l’URL potrebbe essere rimosso dall’indice di Google.» Il riferimento sui codici di stato dice lo stesso per 5xx e 429: “already indexed URLs are preserved in the index, but eventually dropped.” (traduzione) «gli URL già indicizzati vengono conservati nell’indice, ma alla fine rimossi.»

Il modello di rischio, espresso onestamente: un 429 a breve termine rientra nella finestra che Google raccomanda per le emergenze; un 429 persistente sugli stessi URL per più giorni è il caso in cui Google passa a “may” ed “eventually dropped”: un rischio documentato, non un esito garantito in un senso o nell’altro. È la stessa dinamica di un 503 prolungato.

Il crawl rate si riprende automaticamente

Il lato rassicurante è che non esiste un contrassegno di penalizzazione che segue il sito. Quando gli errori diminuiscono, Google dice: “the crawl rate will automatically start increasing again.” (traduzione) «il crawl rate inizierà automaticamente ad aumentare di nuovo.» Non devi inviare nulla né chiedere nuovamente la scansione. Nota però la formulazione esatta: Google dice «inizia ad aumentare», non “instantly returns to your prior rate.” (traduzione) «torna immediatamente al ritmo precedente.» Considera il recupero una direzione documentata senza tempi fissi o punto finale garantito, non uno SLA. Evidence for this claim Google says crawl rate automatically starts increasing after the number of overload responses falls; this describes direction, not an immediate return, fixed recovery time, or guaranteed prior crawl rate. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

(A confronto, l’altro problema è voler fare in modo che Google ti scansioni permanentemente meno. Se servire errori non è praticabile, Google dice di “file a special request to report a problem with unusually high crawl rate” (traduzione) «inviare una richiesta speciale per segnalare un problema di crawl rate insolitamente elevato»: un percorso manuale che può richiedere giorni e non è garantito. Per il recupero non c’è questo attrito.)

Come gestisce Bing i 429

È ampiamente riportato che Bingbot si comporti in modo simile — segnali di sovraccarico 429/500/503 e rallentamento di Bingbot — ma in questa fase non ho potuto confermare autonomamente la formulazione corrente sulle pagine di assistenza di Bing (sono SPA renderizzate in JavaScript che non hanno fornito testo statico recuperabile). Considera quindi la parità una notizia riportata dal settore, non qualcosa che ho verificato sulla documentazione Bing attuale. Ciò che Bing conferma nelle sue indicazioni storiche sono due controlli proattivi che Google non offre nella stessa forma:

• Crawl Control in Bing Webmaster Tools, una griglia di richieste al secondo in cui imposti la velocità di Bingbot per ora del giorno.
• La direttiva crawl-delay di robots.txt. Le indicazioni correnti di Bing Webmaster documentano valori da 1 a 20 secondi. È specifica di Bing e non limita Googlebot.

Su Bing puoi quindi limitare proattivamente con crawl-delay o Crawl Control invece di reagire con i codici di stato. (Google ha ritirato il proprio cursore manuale del crawl rate nel 2024 e ora si affida interamente alle risposte del server.)

Quando invieresti deliberatamente un 429

Motivi legittimi per restituire 429 intenzionalmente:

• Carico d’emergenza sul server — un picco di traffico, una migrazione riuscita male o un’interruzione per cui hai bisogno che Googlebot rallenti subito per qualche ora.
• Protezione di API ed endpoint non HTML dall’abuso di crawler e bot — crawler dei motori, crawler SEO di terze parti (Ahrefs, Screaming Frog) e scraper possono tutti raggiungere limiti pensati per fermare gli abusi.

A che cosa non serve 429: bloccare per sempre i bot che non vuoi affatto. Se non vuoi mai che qualcosa venga scansionato, è un compito di disallow in robots.txt, non di 429. Se vuoi mantenere una pagina ma escluderla dall’indice, usa noindex. 429 significa solo “più tardi”, non “mai”.

429 involontari: le cause più comuni

Quando i 429 compaiono nel report Indicizzazione delle pagine o Crawl Stats di GSC senza che tu li abbia configurati, la causa è in genere una di queste. Non conosco prove solide per ordinare universalmente le frequenze, quindi considerale candidate da confermare o escludere, non una diagnosi:

• Regole WAF/firewall che scattano erroneamente sugli intervalli IP dei crawler legittimi.
• Limiti predefiniti di hosting condiviso o CDN troppo stretti per un crawl reale.
• Strumenti di bot management che classificano Googlebot o Bingbot come traffico abusivo.
• Middleware di rate limiting aggressivo pensato per l’abuso delle API che intercetta i tuoi crawler.

Prima di modificare una soglia o scrivere una regola che esenti i motori di ricerca reali, stabilisci la provenienza: non indovinare quale livello possieda la risposta. Recupera le intestazioni raw, le righe esatte dei log di accesso (non un riepilogo della dashboard), l’identificatore della regola o della zona di rate limit scattata, la chiave client usata per il conteggio (IP, sessione, chiave API), la route, il POP o edge CDN e la finestra temporale. Questa combinazione ti dice quale livello ha emesso davvero il 429 e che cosa stava contando: solo dopo ha senso allentare il limite o aggiungere un’eccezione. Verifica l’identità del crawler con DNS inverso e diretto (il metodo ufficiale di Google), non con la sola stringa user agent: gli user agent “Googlebot” falsificati sono comuni. La scheda Scripts contiene i comandi esatti.

La versione breve del playbook

1. Usa 429 o 503 con Retry-After per rallentare un crawler: mai 403 o 404.
2. Limita il periodo a ore o 1–2 giorni: oltre, gli URL possono essere rimossi.
3. Ricorda che il limite è a livello hostname e il recupero è automatico quando gli errori finiscono.
4. Limita il traffico giusto e verifica l’identità del crawler prima di esentare i bot.

Riepilogo dell’AI

Una sintesi della versione Avanzata:

• 429 Too Many Requests significa che il server dice a un client (browser, script o crawler) che ha inviato troppe richieste troppo rapidamente: è una limitazione della frequenza, formalmente un errore 4xx del client.
• A livello di protocollo: RFC 6585 dice che una risposta 429 DOVREBBE spiegare la condizione e PUÒ includere Retry-After: è raccomandato, non obbligatorio. Inoltre NON DEVE essere memorizzata in una cache; un 429 memorizzato o riprodotto indica un bug dell’intermediario, non dell’origine. Come contare e definire la chiave del limite (IP, sessione, chiave API, risorsa) è una policy propria: la specifica non lo definisce.
• L’unica eccezione 4xx: Google tratta 429 come un errore server 5xx, non come 403/404. Lo interpreta come “server overloaded, slow down” (traduzione) «server sovraccarico, rallenta» e limita il crawl rate invece di rimuovere i contenuti.
• Google approva 429 (e 500/503) per rallentare i crawler: mai 403 o 404. Gary Illyes ha scritto un post nel 2023 proprio per chiedere a siti e CDN di smettere di usare 404 per limitare Googlebot.
• Il rallentamento riguarda l’intero hostname sopra una soglia: Google condiziona l’effetto sull’hostname al rilevamento di “un numero significativo” di risposte 500/503/429, non a un singolo 429. Sopra la soglia, vengono scansionate più lentamente anche le pagine che restituiscono 200.
• Guida 1–2 giorni, non limite rigido: la documentazione Google suggerisce per le emergenze «alcune ore o 1–2 giorni». 429 persistenti sugli stessi URL per più giorni espongono al rischio che quegli URL vengano rimossi dall’indice: «possono» ed «eventualmente», non una garanzia, come per un 503 prolungato.
• Il recupero è progressivo, non istantaneo: smetti di inviare 429 e Google dice che il crawl rate “inizia ad aumentare di nuovo”: nessuna richiesta ulteriore e nessuna penalizzazione persistente, ma neppure la promessa di un ripristino immediato e completo entro tempi fissi.
• Retry lato client: rispetta un Retry-After valido quando presente; se manca, RFC 6585 non prescrive una formula: usa un backoff limitato con jitter, limita i tentativi e controlla l’idempotenza prima di ripetere richieste non idempotenti.
• Limita il traffico corretto e verifica l’identità del crawler (DNS inverso + DNS diretto) prima di esentare i bot.
• Bing viene ampiamente descritto come un bot che rallenta in modo simile su 429, ma in questa ricerca la parità non è stata verificata autonomamente nella documentazione Bing corrente; la guida storica Bing conferma crawl-delay e la griglia Crawl Control come alternative proattive.
• 429 non significa blocco: significa “più tardi”, non “mai”. Usa robots.txt per tenere fuori i bot e noindex per togliere una pagina dall’indice.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca e della specifica HTTP.

Google

• Non usare 403 o 404 per il rate limiting — il post di Gary Illyes del febbraio 2023; la dichiarazione canonica che 429 è l’eccezione e 403/404 sono gli strumenti sbagliati.
• Ridurre il crawl rate di Google — le indicazioni “restituisci 500, 503 o 429”, la finestra di 1–2 giorni, il rallentamento sull’intero hostname e il recupero automatico.
• Codici di stato HTTP, errori di rete e DNS — come Google gestisce ciascun codice; 429 è raggruppato con gli errori server (disponibile anche al precedente percorso search/docs/crawling-indexing/http-network-errors).
• Ridurre il crawl rate di Google — percorso per la richiesta speciale — il percorso manuale “segnala un problema con un crawl rate insolitamente alto” quando non è possibile servire errori.

Bing / Microsoft

• Crawl Control — il programmatore delle richieste al secondo di Bingbot in Bing Webmaster Tools.
• Guida Bingbot — le indicazioni Bing correnti su crawl-delay (1–20 secondi).

Specifica HTTP

• MDN — 429 Too Many Requests — definizione del protocollo, Retry-After e nozioni di base sul rate limiting.

Citazioni dalla fonte

Dichiarazioni attribuibili di Google, Bing e della specifica HTTP. Ogni link è un collegamento diretto che porta al passaggio citato nella pagina.

Google — Gary Illyes, “Non usare 403 o 404 per il rate limiting” (febbraio 2023)

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (traduzione) «Negli ultimi mesi abbiamo notato un aumento dei proprietari di siti e di alcune reti di distribuzione dei contenuti (CDN) che tentano di usare 404 e altri errori client 4xx, ma non 429, per ridurre il crawl rate di Googlebot.» Jump to quote
• «429 è l’eccezione: segnala a ogni robot conforme, Googlebot compreso, che deve ridurre il ritmo perché sta sovraccaricando il server». (Traduzione italiana dell’originale citato nella sezione Advanced.) Jump to quote
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (traduzione) «Tutti i codici di stato HTTP 4xx (di nuovo, tranne 429) faranno rimuovere i tuoi contenuti da Google Search.» Jump to quote
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (traduzione) «Usa Search Console per ridurre temporaneamente il crawl rate. Restituisci a Googlebot 500, 503 o 429 quando esegue il crawl troppo velocemente.» Jump to quote Gloss italiano: Illyes osserva che siti e CDN stavano tentando di usare 404 e altri 4xx (tranne 429) per ridurre il crawl rate; chiarisce che 429 è l’eccezione, un segnale chiaro per un robot ben educato di rallentare perché sta sovraccaricando il server, e che tutti gli altri 4xx rimuovono i contenuti. Per rallentare Googlebot raccomanda di restituire temporaneamente 500, 503 o 429.

Google — Ridurre il crawl rate / riferimento ai codici di stato

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (traduzione) «Se devi ridurre urgentemente il crawl rate per un breve periodo, per esempio alcune ore o 1–2 giorni, restituisci ai crawler un codice di risposta HTTP 500, 503 o 429 invece di 200.» Jump to quote
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (traduzione) «Il crawl rate ridotto riguarda l’intero hostname del sito; quando gli errori diminuiscono, il crawl rate ricomincia automaticamente ad aumentare.» Jump to quote
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (traduzione) «Non raccomandiamo di farlo per un periodo lungo, cioè oltre 1–2 giorni, perché potrebbe avere un effetto negativo sulla presenza del sito nei prodotti Google… l’URL potrebbe essere rimosso dall’indice di Google.» Jump to quote
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (traduzione) «I crawler di Google trattano 429 come un segnale che il server è sovraccarico e come un errore server.» Jump to quote
• «Non usare 401 o 403 per ridurre il crawl rate: tra i codici 4xx, l’eccezione che produce questo effetto è 429». (Traduzione italiana dell’originale citato nella sezione Advanced.) Jump to quote Gloss italiano: Google raccomanda 500, 503 o 429 per ridurre urgentemente il crawl rate per alcune ore o 1–2 giorni; il rallentamento riguarda l’intero hostname, inizia a recuperare quando gli errori diminuiscono, e un periodo più lungo può far uscire l’URL dall’indice. Google tratta 429 come un errore server e dice di non usare 401/403 per il crawl rate.

MDN — definizione del protocollo

• «HTTP 429 Too Many Requests indica che il client ha inviato troppe richieste in un determinato intervallo; chiedergli di rallentare è il meccanismo comunemente chiamato rate limiting». (Traduzione italiana dell’originale citato nella sezione Beginner.) Jump to quote

Bing — guida Webmaster corrente

• La guida Bingbot documenta valori crawl-delay da 1 a 20 secondi. Considerala una guida specifica di Bing, non un limite generico per i crawler.

Conferme dal settore della dichiarazione Google

• Il post di Illyes del febbraio 2023 è stato ripreso integralmente da Search Engine Land, Search Engine Roundtable e Search Engine Journal: tutti presentano 429 come “l’unica eccezione”. Sono articoli della stampa di settore sullo stesso post Google; la fonte primaria è il post di Illyes citato sopra.

Inviare un 429 corretto, con Retry-After

L’elemento più importante di un 429 ben comportato è l’intestazione Retry-After. Dice a qualsiasi client conforme, compreso Googlebot, quanto tempo attendere. Può contenere un numero di secondi oppure una data HTTP:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Omettere Retry-After non viola la conformità, ma includerlo è una buona pratica e offre ai crawler un segnale concreto di backoff.

nginx — rate limiting che restituisce 429

Per impostazione predefinita limit_req di nginx restituisce 503. Per una semantica più adatta ai crawler, sovrascrivila a 429 e aggiungi un’intestazione Retry-After. Questo esempio consente 10 richieste al secondo per IP con un piccolo burst:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — rate limiting con mod_ratelimit / mod_evasive

Il mod_ratelimit principale di Apache limita la larghezza di banda, non il numero di richieste; per limitare la frequenza delle richieste si usa di solito mod_evasive (o un WAF). Per fare in modo che la risposta limitata restituisca 429 con Retry-After, impostalo esplicitamente:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Nota il caveat: le versioni meno recenti di mod_evasive impostano di default la risposta di blocco a 403, proprio il codice che Google dice di non usare per il rate limiting. Verifica che la tua versione restituisca 429 oppure anteponi un CDN/WAF che lo faccia.

Cloudflare / CDN — limitare la frequenza a 429

A livello CDN, imposta l’azione della regola di rate limiting su una risposta 429 (molte configurazioni predefinite usano 403 o una challenge). Nelle regole Rate Limiting di Cloudflare il codice di stato della risposta per i limiti superati è configurabile — scegli 429 e, quando supportato, aggiungi Retry-After. Lo stesso principio vale per Fastly, Akamai o un gateway API: l’azione quando si supera il limite deve essere 429 Too Many Requests, non 403 Forbidden.

Lato client: riprovare dopo un 429 senza una formula

Se scrivi il client, RFC ti dà una sola regola rigida e nessun algoritmo di fallback: rispetta un Retry-After valido quando è presente. Quando manca, RFC 6585 non prescrive intervallo, formula di backoff, distribuzione del jitter, numero di tentativi o condizione di “successo”: sono policy da definire, non requisiti della specifica. Non presentare una formula particolare (compresa quella seguente) come legge HTTP: è un default ragionevole e limitato, non l’unica scelta corretta.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Gli elementi importanti, qualunque siano i numeri scelti, sono: un tetto al tempo totale di attesa e al numero di tentativi (non riprovare per sempre), il jitter (per evitare che una flotta di client riprovi sincronizzata e riattivi il limite) e un controllo di idempotenza prima di ripetere operazioni non sicure da ripetere (un POST non idempotente richiede una chiave di deduplicazione, non un retry cieco).

Verifica che un bot sia davvero Googlebot prima di esentarlo

Se stai scrivendo eccezioni al rate limit per i motori di ricerca, conferma l’identità con un controllo DNS inverso + DNS diretto: gli user agent “Googlebot” falsificati sono comuni e la sola stringa UA non dimostra nulla.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Se la ricerca inversa non termina in un dominio Google o quella diretta non corrisponde all’IP originale, non è Googlebot. Puoi anche confrontare l’IP con gli intervalli pubblicati da Google (googlebot.json).

Miti comuni su 429 e SEO

Mito: “Any 429 will hurt my SEO / get me deindexed.” No. Google ha progettato 429 come un segnale di throttling sicuro e previsto. I 429 di breve durata o intermittenti sono normali e si correggono da soli. Il rischio di deindicizzazione compare solo con 429 persistenti sugli stessi URL per più giorni — la guida di Google di 1–2 giorni è la soglia.

Mito: “429 e 503 sono praticamente intercambiabili per la SEO.” Per il throttling della frequenza di scansione Google li tratta in modo simile. Ma hanno significati diversi: 503 Service Unavailable è il segnale tradizionale di “temporaneamente non disponibile / manutenzione”, mentre 429 comunica nello specifico un sovraccarico di frequenza/volume. Usare il codice semanticamente corretto è importante per il tuo monitoraggio, i tuoi strumenti e tutto ciò che legge i codici di stato a valle — anche se Googlebot rallenta in entrambi i casi.

Mito: “Puoi usare 403 o 404 per rallentare Googlebot proprio come 429.” Il post di Illyes del febbraio 2023 lo smentisce direttamente: era una pratica abbastanza comune da spingere Google a pubblicare un articolo dedicato. 403/404 non hanno alcun effetto sulla frequenza di scansione e rimuovono attivamente i contenuti dall’indice. 429 è l’unico codice 4xx che applica il throttling.

Mito: “Limitare la frequenza dei bot di ricerca causa un taglio permanente del crawl budget.” La riduzione è temporanea e si recupera automaticamente quando il volume di errori cala. Non rimane alcun contrassegno sul sito dopo la fine degli errori: la documentazione di Google dice che il crawl rate “will automatically start increasing again.”

Mito: “Se Googlebot riceve 429, abbandona definitivamente quell’URL.” Google riprova più tardi. La preoccupazione riguarda 429 persistenti per più giorni per URL, non un rate limit occasionale o isolato, che Googlebot semplicemente rispetta e da cui si riprende.

Domande frequenti

Un errore 429 danneggia la mia SEO? Non di per sé. I 429 di breve durata o intermittenti rallentano temporaneamente Googlebot e si risolvono da soli. Il rischio compare solo quando gli stessi URL restituiscono 429 per più giorni.

Per quanto tempo posso restituire un 429 prima che Google deindicizzi le mie pagine? La documentazione di Google dice di limitarlo a “a couple of hours, or 1–2 days.” (traduzione) «alcune ore o 1–2 giorni.» Oltre quel limite, “the URL may be dropped from Google’s index.” (traduzione) «l’URL potrebbe essere rimosso dall’indice di Google.» Considera 1–2 giorni un limite massimo, non un obiettivo.

Qual è la differenza tra 429 e 503 per la SEO? Google limita la scansione in modo simile per entrambi. Ma 503 Service Unavailable significa “temporarily unavailable / maintenance”, mentre 429 significa nello specifico «stai inviando troppe richieste.» Usa il codice semanticamente corretto, così il tuo monitoraggio e i tuoi strumenti lo interpretano correttamente.

Devo bloccare Googlebot con un 429 se voglio che esegua meno scansioni in modo permanente? No: 429 è un segnale a breve termine, non un’impostazione permanente. Per una riduzione duratura Google consiglia di inviare una richiesta speciale relativa a una frequenza di scansione elevata. Per tenere completamente fuori i bot usa robots.txt; per rimuovere una pagina dall’indice usa noindex.

Bingbot rispetta 429 nello stesso modo di Googlebot? Anche Bingbot rallenta davanti a segnali di sovraccarico come 429/500/503. Bing offre inoltre controlli proattivi che Google non offre: la direttiva crawl-delay di robots.txt e la griglia delle richieste al secondo di Crawl Control in Bing Webmaster Tools.

Che cos’è l’header Retry-After e mi serve? Retry-After dice al client quanto tempo attendere prima di riprovare (un numero di secondi o una data HTTP). Non è strettamente obbligatorio, ma è una best practice e offre ai crawler un segnale concreto per il back-off.

Google riprenderà la scansione normale dopo che avrò smesso di restituire 429? Sì, automaticamente. Quando il volume degli errori diminuisce, “the crawl rate will automatically start increasing again.” (traduzione) «il crawl rate inizierà automaticamente ad aumentare di nuovo.» Non serve una nuova richiesta e non rimane alcuna penalizzazione.

Gli strumenti WAF o CDN possono restituire accidentalmente 429 a Googlebot? Molto spesso. Regole firewall aggressive, limiti predefiniti di CDN/hosting e strumenti di gestione dei bot possono classificare erroneamente Googlebot o Bingbot. Verifica l’identità del crawler (DNS inverso + diretto) prima di creare eccezioni e allenta i limiti che colpiscono i motori di ricerca reali.

429 è un errore client o un errore server? Tecnicamente è un errore client 4xx secondo la specifica HTTP. Ma Google lo tratta come un errore server ai fini della scansione: è l’unico codice 4xx raggruppato con i 5xx.

Che cosa deve fare il mio client se riceve un 429 senza header Retry-After? Non esiste una formula imposta dall’HTTP: la specifica lascia la scelta alla policy. Un default ragionevole e limitato è un backoff esponenziale con jitter, un limite massimo al tempo totale di attesa e al numero di tentativi per non riprovare all’infinito, più un controllo di idempotenza prima di ripetere una richiesta che non è sicuro inviare due volte. Vedi la scheda Scripts per una versione in pseudocodice completa.

Che cosa devo fare per un 429?

Problemi comuni con 429

Googlebot riceve 429 ma i visitatori normali no

Sintomo: i report del crawler mostrano 429 mentre i controlli dal browser restituiscono 200. Probabile causa: gestione dei bot, una regola UA o un rate limiting basato sull’IP. Correzione: collega gli eventi WAF agli IP dei crawler verificati, poi restringi o correggi la regola responsabile; non inserire in allowlist solo una stringa user-agent.

La frequenza di scansione dell’intero hostname diminuisce

Sintomo: la scansione rallenta oltre gli URL che hanno restituito 429. Probabile causa: Google applica il segnale di sovraccarico a livello di hostname. Correzione: interrompi i 429 non intenzionali, ripristina risposte di successo stabili e lascia che la frequenza di scansione si riprenda automaticamente.

Le risposte 429 continuano dopo l’incidente

Sintomo: il server è sano ma gli URL restituiscono ancora 429. Probabile causa: una cache CDN, una regola edge o lo stato di un limiter hanno superato la durata dell’evento. Correzione: disabilita o fai scadere la regola temporanea, svuota una risposta memorizzata erroneamente e verifica percorsi e regioni rappresentativi.

Retry-After è assente o inutilizzabile

Sintomo: i client sanno di essere stati limitati ma non quando riprovare. Probabile causa: la risposta è stata generata da una regola di sicurezza generica. Correzione: fai in modo che il livello che emette la risposta invii un ritardo valido o una data HTTP e verifica l’header grezzo.

Prompt: verifica una regola di rate limiting

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: diagnostica 429 inspiegabili

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Strumenti per analizzare i 429

• Bulk HTTP Status Code Checker: verifica un insieme rappresentativo di URL ed esporta i percorsi che attualmente restituiscono 429.
• HTTP Header Checker: esamina Retry-After, le impronte della CDN e i passaggi dei redirect nella risposta limitata.
• Googlebot Verifier: convalida le prove IP prima di creare un’eccezione per un crawler.
• Log File Analyzer: segmenta lo spreco dei codici di stato per bot e sezione mantenendo i log caricati nel browser.
• Statistiche di scansione di Search Console: confronta la tempistica dei 429 con i cambiamenti nelle richieste di scansione e nel comportamento delle risposte dell’host.

Convalida una configurazione 429

Test del contratto di risposta

Test da eseguire: attiva il limite in sicurezza in un ambiente controllato e ispeziona la risposta grezza. Risultato atteso: 429 con un Retry-After valido e nessun redirect o codice di successo accidentale. Interpretazione del fallimento: il livello o il template di errore sbagliato è proprietario della risposta. Finestra di monitoraggio: immediata. Trigger di rollback: le richieste normali vengono limitate oppure il test destabilizza il servizio.

Test dell’ambito

Test da eseguire: prova un client volutamente limitato, utenti normali e traffico di crawler verificati su classi rappresentative di URL. Risultato atteso: solo il traffico definito supera il limite. Interpretazione del fallimento: la chiave del rate limit o l’ambito della regola è troppo ampio. Finestra di monitoraggio: durante il test controllato e la propagazione sull’edge. Trigger di rollback: percorsi, utenti o host non correlati ricevono 429.

Test di recupero

Test da eseguire: interrompi il trigger, attendi l’intervallo di retry configurato e ripeti le richieste. Risultato atteso: risposte normali stabili riprendono senza una correzione manuale per URL. Interpretazione del fallimento: le risposte 429 memorizzate in cache o lo stato del limiter persistono. Finestra di monitoraggio: l’intervallo configurato più la propagazione del deployment. Trigger di rollback: l’hostname resta limitato dopo che il carico sottostante è scomparso.

Test di memorizzazione in cache

Test da eseguire: metti una cache o un edge CDN davanti al percorso limitato, attiva un 429, poi richiedi di nuovo lo stesso URL dopo che la condizione sottostante si è risolta. Risultato atteso: la seconda richiesta viene valutata da zero: nessun 429 memorizzato o riprodotto viene servito dall’edge. Interpretazione del fallimento: un intermediario sta memorizzando una risposta che RFC 6585 dice di non memorizzare; controlla gli header cache-control e la configurazione della regola edge, non l’origine. Finestra di monitoraggio: immediata, su un insieme rappresentativo di nodi/POP edge. Trigger di rollback: viene servito un 429 memorizzato dopo il recupero dell’origine.

Test della policy di retry del client

Test da eseguire: invia un client attraverso un 429 sia con un header Retry-After valido sia senza. Risultato atteso: con l’header il client attende l’intervallo specificato; senza, applica una policy di backoff con jitter e limiti, rispetta un numero massimo di tentativi e controlla l’idempotenza prima di ripetere una richiesta non idempotente. Interpretazione del fallimento: un client che riprova immediatamente, senza limiti o che ripete alla cieca una richiesta non idempotente ha una policy di retry difettosa, non un problema di conformità HTTP. Finestra di monitoraggio: per l’intera sequenza di retry limitata. Trigger di rollback: il client riattiva lo stesso rate limit con retry immediati o senza limiti.

Risorse che vale la pena consultare

I miei articoli correlati

• Codici di stato HTTP e relativo impatto SEO — la mia guida completa a come ogni codice di stato influisce sulla SEO, incluso il ruolo di 429.
• Guida introduttiva alla SEO tecnica — dove si collocano i controlli di scansione e i codici di stato nel quadro più ampio.
• La storia del blocco di 2 pagine ad alto posizionamento con robots.txt — il mio esperimento di prima mano su ciò che accade quando si bloccano i crawler.

I miei interventi

• How Search Works (SlideShare) — il mio percorso attraverso scansione, rendering, indicizzazione e ranking, compreso il modo in cui i server segnalano ai crawler di rallentare. (Si applica la mia dichiarazione standard: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Dal settore

• Non usare 403 o 404 per il rate limiting (Google Search Central, Gary Illyes) — la dichiarazione di riferimento secondo cui 429 è l’eccezione.
• Ridurre il crawl rate di Google (Google) — la finestra di 1–2 giorni, il throttling a livello di hostname e il recupero automatico.
• Google mette in guardia dall’uso dei codici 403 o 404 per limitare il crawl rate di Googlebot (Search Engine Land) — la copertura della stampa specializzata sul post di Illyes.
• Google dice di smettere di usare 403 o 404 per ridurre il crawl rate di Googlebot (Search Engine Roundtable) — il riepilogo di Barry Schwartz che presenta 429 come «l’unica eccezione».
• Google: non usare risposte di errore 403/404 per limitare il rate di Googlebot (Search Engine Journal) — un terzo articolo indipendente sulla stessa indicazione.
• MDN — 429 Too Many Requests — la definizione della specifica HTTP e il riferimento a Retry-After.
• Indicazioni per Bingbot — le indicazioni attuali di Bing per la direttiva crawl-delay.

Mettiti alla prova: 429 Too Many Requests

Cinque domande rapide su come funziona 429 e su come lo tratta Google. Scegli una risposta per ciascuna domanda, poi controlla.

Cronologia modifiche