429 è rate limiting. 503 è un server non pronto. Retry-After porta una data o i secondi. Si legge in Network, non su Lighthouse.
Un 503 non è un rate limit. Un WAF che butta 403 non è un 429. HTTP 429 Too Many Requests dice che quel client ha mandato troppe richieste in un intervallo. Se c’è Retry-After, si aspetta. Non si insiste. Verifica del 4 ottobre 2026 su MDN (429 e 503, 22 giugno 2026; Retry-After, 21 novembre 2025).
In breve: 429 = rate limiting. 503 = il server non è pronto (manutenzione o sovraccarico). Retry-After accetta una data HTTP o i secondi. L’esempio MDN del 429 usa 3600 secondi. Googlebot, in scheda Retry-After, rispetta l’header su un 503. Non è Lighthouse. Non è il banner cookie.
Cosa trovi in questo articolo
429 è rate limiting (non è 503, non è 403)
MDN, voce 429 Too Many Requests, ultima modifica 22 giugno 2026: il client ha inviato troppe richieste in un dato intervallo. Il meccanismo si chiama rate limiting. Un header Retry-After may be included: indica quanto aspettare prima di riprovare.
In pagina: le implementazioni variano. Il limite può essere su tutto il server o per risorsa. Di solito si basa sull’IP del client; può essere per utente o per applicazione se le richieste sono autenticate o portano un cookie. Specifica in calce MDN: RFC 6585, sezione 4. Il cluster è Operatività. Non è il WAF: quello decide se una richiesta entra. Non è la protezione DDoS: un 429 su un client noto non è un attacco volumetrico. Non è Server-Timing: quello scrive i millisecondi del backend, non un stop.
Esempio MDN, stesso pezzo: un client mal configurato in loop. Rate limiting server-wide. Risposta 429 con Retry-After che riapre dopo 3600 secondi (60 minuti). Si legge in Network, colonna stato e header di risposta. Non nel punteggio Lighthouse.
Retry-After: data oppure secondi
MDN, header Retry-After, ultima modifica 21 novembre 2025: quanto deve aspettare lo user agent prima di una richiesta di follow-up. Tre casi, in pagina.
| Caso MDN | Cosa indica |
|---|---|
| 503 Service Unavailable | quanto il servizio dovrebbe restare non disponibile |
| 429 Too Many Requests | quanto aspettare prima di una nuova richiesta |
| redirect, es. 301 | tempo minimo chiesto prima della richiesta reindirizzata |
Due forme. <http-date>: una data dopo la quale riprovare (formato dell’header Date). <delay-seconds>: intero decimale non negativo, secondi di attesa dopo aver ricevuto la risposta. Specifica in calce: HTTP Semantics, campo retry-after (RFC 9110).
Nota in pagina: il supporto di Retry-After, client e server, è ancora inconsistente. Alcuni crawler, Googlebot citato, lo rispettano. Su un 503 di downtime pianificato serve a far sì che i motori continuino a indicizzare quando il fermo finisce. Rinvio MDN: guida Google del 2011 su downtime pianificato.
Quando resta il 503
MDN, voce 503 Service Unavailable, 22 giugno 2026: il server non è pronto. Cause comuni: manutenzione o sovraccarico. In manutenzione si può instradare tutto su una pagina 503; in overload l’applicazione può rifiutare quando memoria, CPU o pool di connessioni superano una soglia. Si crea backpressure. Poi la frase che chiude il dubbio: se si limitano le richieste di client specifici per rate limiting, la risposta corretta è 429 Too Many Requests.
Il 503 è per condizioni temporanee. Se possibile, Retry-After con il tempo stimato di recupero. Una pagina comprensibile nel body. Nota sul cache: un 503 è temporaneo; di solito non si cache-a, altrimenti i client tengono una pagina di errore dopo il ripristino. Specifica: RFC 9110, status.503. Il monitoraggio resta un altro mestiere: monitoring del sito.
Errori da evitare
Rispondere 503 a un client che ha solo superato la quota: MDN, sul 503, manda al 429.
Rispondere 403 o una pagina WAF e chiamarlo «rate limit» senza 429.
Omettere Retry-After e pretendere che il client indovini i secondi.
Mandare Retry-After con un valore non data e non intero di secondi.
Cache-are un 503 come una pagina normale.
Leggere il 429 su Lighthouse o su CrUX: si vede in Network.
Confondere 429 con il banner cookie o con Server-Timing.
In sintesi
429 = troppe richieste da quel client. 503 = il server non è pronto. Retry-After porta una data o i secondi; nell’esempio MDN del 429 sono 3600. Si legge in Network. Si rilegge MDN 429, 503 e Retry-After il giorno in cui si configura il limiter. Verifica del 4 ottobre 2026.
