Il sito mostra “429 Troppe richieste”: come capire chi viene bloccato

Registrare l’errore prima di ripetere le prove

Annota l’indirizzo completo, l’orario con fuso, il messaggio e l’azione appena eseguita. Indica se è successo aprendo una pagina, inviando un modulo, usando filtri o accedendo all’area clienti. Conserva l’eventuale identificativo della richiesta mostrato nella schermata: può aiutare il gestore a trovare l’evento nei log.

Evita di ricaricare continuamente la pagina. Se la risposta contiene un’indicazione di attesa, rispettala prima di una nuova prova. Non chiedere al cliente password o dati riservati per ricostruire il problema: servono il percorso e il contesto, non l’accesso al suo account.

Verifica con pochi tentativi controllati se l’errore riguarda anche altre pagine. Il codice 429 è distinto dal 403 Accesso negato: confonderli può indirizzare l’analisi verso la regola sbagliata.

Capire quale componente restituisce il codice 429

Tra visitatore e applicazione possono esserci hosting, CDN, firewall, plugin e servizi esterni. Il fatto che il messaggio appaia nel browser non dimostra che provenga dal programma del sito. Il tecnico può confrontare intestazioni della risposta, identificativi e registri dei diversi livelli.

Occorre anche distinguere la richiesta principale da quelle secondarie. Una pagina potrebbe aprirsi regolarmente mentre una mappa, una ricerca o un sistema di prenotazione riceve un 429. In quel caso il visitatore vede un componente fermo, anche senza una pagina di errore completa.

Identificare chi viene limitato e con quale regola

Un limite può contare richieste per indirizzo IP, utente, credenziale, percorso o altri criteri. Chiedi quale criterio è effettivamente applicato e su quale intervallo. Più persone possono condividere un accesso di rete: una regola troppo ampia può quindi coinvolgere un gruppo di clienti anziché un singolo visitatore.

Allo stesso tempo, un volume elevato può derivare da bot, controlli automatici, un’applicazione configurata male o tentativi indesiderati. Il numero degli accessi non basta a classificare il traffico. Per l’analisi preliminare puoi usare la guida sulle visite anomale e i bot.

Prepara un campione limitato di eventi con percorso, codice, frequenza e regola attivata. Chi gestisce i log deve trattare le informazioni in modo appropriato; per discutere la correzione sono spesso sufficienti riepiloghi privi di dati identificativi superflui.

Verificare se il sito sta creando richieste ripetute

Prima di aumentare una soglia, controlla se una funzione chiama lo stesso servizio troppo spesso. Filtri che inviano una richiesta a ogni carattere, aggiornamenti continui o tentativi automatici immediati dopo un errore possono alimentare il problema. Va esaminata la sequenza, non soltanto il totale.

In un esempio ipotetico, una disponibilità aggiornata ininterrottamente da tutte le schede aperte può consumare il limite del servizio di prenotazione. Il tecnico dovrebbe verificare quando serve un aggiornamento, come condividere i risultati dove consentito e come gestire il fallimento senza moltiplicare i tentativi.

La risposta può includere Retry-After, che indica quando riprovare. Il suo uso effettivo e la strategia dei tentativi devono rispettare il servizio coinvolto. Non risolvere una quota esaurita distribuendo richieste su account o indirizzi diversi per eludere il limite.

Controllare se le limitazioni coinvolgono i motori di ricerca

Se gli eventi riguardano Googlebot o altri crawler, verifica prima che siano autentici. Un nome dichiarato nello user-agent può essere imitato. Gli strumenti e le procedure ufficiali del motore aiutano il tecnico a distinguere richieste verificate da traffico che usa soltanto quel nome.

Google documenta l’uso temporaneo di risposte 429 o 503 per rallentare una scansione durante un sovraccarico. Un errore che persiste può però ridurre la scansione e compromettere la presenza degli URL interessati. Non lasciare quindi una limitazione generale attiva senza controllo dopo la fine dell’emergenza.

Usa la guida ai log di scansione di Google e Bing per collegare pagine, orari e risposte. Se il blocco riguarda assistenti AI, verifica anche le regole di accesso al sito da ChatGPT e Claude, senza supporre che tutti i crawler abbiano lo stesso comportamento.

Correggere il limite nel punto giusto

La soluzione dipende dalla causa: ridurre richieste ridondanti, correggere tentativi automatici, rivedere l’ambito di una regola o concordare risorse e quote adeguate al servizio. Chiedi quale elemento verrà modificato e come sarà verificata la protezione che deve restare attiva.

Non disabilitare tutto il firewall o tutti i controlli antiabuso per far scomparire il messaggio. Una modifica circoscritta a percorso, metodo o soggetti verificati può essere più appropriata, quando supportata dal sistema e giustificata dalle prove. La configurazione concreta va affidata a chi conosce hosting e applicazione.

Prepara un ripristino e prova un cambiamento alla volta. Se il limite è imposto da un fornitore esterno, conserva la documentazione delle richieste e contatta il referente con esempi precisi; una modifica al server del sito potrebbe non avere alcun effetto.

Verificare il ritorno al funzionamento e mantenere un controllo

Ripeti il percorso che produceva il problema con un numero normale di operazioni. Prova navigazione, ricerca, modulo e servizi collegati pertinenti. Non serve generare un nuovo picco per dimostrare che un cliente riesce a usare il sito; eventuali prove di carico richiedono un ambiente e un piano concordati.

Controlla nei log se il codice continua a comparire e su quali richieste. Distingui le limitazioni ancora intenzionali dagli errori che ostacolano visite legittime. Se il problema era collegato a un crawler, segui nel tempo la ripresa delle visite alle pagine interessate senza aspettarti un effetto immediato sull’indice.

Documenta regola corretta, referente, data e criteri per intervenire di nuovo. Il risultato utile è un sito raggiungibile per l’uso previsto, con un comportamento comprensibile quando un limite viene effettivamente raggiunto.

Domande frequenti

Un errore 429 significa che il sito è stato attaccato?

Non necessariamente. Può derivare da una protezione, da una quota di un servizio o da richieste ripetute generate involontariamente. Occorre leggere gli eventi prima di attribuirne la causa.

Cambiare hosting risolve sempre il problema?

No. Il limite può provenire da una CDN, da un plugin o da un servizio esterno. Prima di decidere un trasferimento bisogna identificare chi restituisce la risposta.

Posso autorizzare qualsiasi richiesta che si presenta come Googlebot?

Il nome dello user-agent non basta a provare l’identità. Le eventuali regole dedicate devono basarsi su verifiche affidabili e sulla documentazione del motore, senza aprire indiscriminatamente l’accesso.