Un esperto SEO avvia un audit tecnico di un grande sito — e dopo 10 minuti Screaming Frog inizia a restituire solo 403 Forbidden o 429 Too Many Requests. Il server di protezione ha scambiato il crawler per un bot attaccante e ha bloccato l'indirizzo IP. Risultato: l'audit deve essere riavviato e il cliente deve essere informato del ritardo nel rapporto. Il problema si risolve con una corretta configurazione dei proxy per il crawler — vediamo come fare.
Perché i siti bloccano Screaming Frog durante l'audit
Screaming Frog, Sitebulb, JetOctopus e Netpeak Spider funzionano tecnicamente come i bot dei motori di ricerca: eseguono rapidamente migliaia di URL consecutivi, scaricano HTML, CSS, JS e immagini, controllano i reindirizzamenti e i codici di stato. Dal punto di vista della protezione del sito (Cloudflare, Qrator, DDoS-Guard, WAF integrato dell'hosting) questo appare come un'attività sospetta: troppe richieste da un solo IP in poco tempo.
I blocchi si verificano particolarmente spesso durante l'audit di:
- grandi negozi online su infrastrutture simili a Wildberries con protezione contro il parsing;
- siti dietro Cloudflare con la modalità "Under Attack" attivata o un alto livello di Security Level;
- portali con contenuti dinamici, dove ogni richiesta genera un carico sul server (ricerca, filtri, elenco prodotti);
- siti dei concorrenti che stai analizzando non dal tuo dominio — non hanno motivi per fidarsi del tuo IP.
Ulteriore complessità: se l'agenzia ha un solo IP statico per l'ufficio e gli audit dei siti avvengono regolarmente (diversi clienti al giorno), questo IP viene rapidamente inserito nelle liste nere dei sistemi di protezione. Dopo di che vengono bloccati non solo gli audit attuali, ma anche quelli futuri dallo stesso indirizzo — anche per i siti che prima si aprivano senza problemi.
Come riconoscere il blocco dai codici di risposta
Prima di modificare le impostazioni del proxy, è importante capire cosa sta realmente accadendo. Screaming Frog mostra il codice di risposta nella colonna Codice di Stato — da esso è facile determinare la causa dell'interruzione del crawling.
| Codice di risposta | Cosa significa | Cosa fare |
|---|---|---|
| 403 Forbidden | IP bloccato dalla protezione del sito | Cambia IP, riduci la velocità di crawling |
| 429 Too Many Requests | Superato il limite di richieste in un dato intervallo di tempo | Riduci il numero di thread, aggiungi un ritardo |
| 503 Service Unavailable | Server sovraccarico o protezione contro i bot attivata | Cambia User-Agent, utilizza IP residenziale |
| Nessuna risposta / Timeout | IP nella blacklist, le richieste non arrivano | Sostituzione completa del pool di proxy |
Se nel rapporto appare ripetutamente lo stesso codice su migliaia di URL consecutivi — si tratta quasi sempre di un blocco per IP, non di un reale problema del sito. Verificare l'ipotesi è semplice: apri l'URL problematico in un normale browser dallo stesso IP. Se la pagina si apre normalmente, mentre Screaming Frog riceve 403 — il problema è nel crawler, non nel sito.
Quali proxy sono adatti per il crawling SEO
La scelta del tipo di proxy dipende dall'obiettivo: audit una tantum del proprio sito, monitoraggio regolare dei concorrenti o scansione di un marketplace protetto. Analizziamo tre tipi principali e la loro applicabilità per i crawler.
| Tipo di proxy | Velocità | Rischio di blocco | Quando utilizzare |
|---|---|---|---|
| Proxy di data center | Alta | Media-alta sui siti protetti | Audit del proprio sito senza protezione rigorosa |
| Proxy residenziali | Media | Basso | Audit dei concorrenti, siti dietro Cloudflare, marketplace |
| Proxy mobili | Media-bassa | Minimo | Protezioni più aggressive, audit mirati rari |
Per la maggior parte degli audit tecnici regolari, il miglior equilibrio è fornito dai proxy residenziali — utilizzano indirizzi IP reali dei provider, quindi la protezione del sito percepisce le richieste del crawler come traffico di un normale utente. Questo è particolarmente importante se stai analizzando non il tuo dominio, ma il sito di un concorrente o un marketplace con un rigoroso sistema anti-bot.
I proxy di data center rimangono una buona opzione quando stai auditando il tuo sito e puoi aggiungere in anticipo l'intervallo IP nella whitelist a livello di WAF o Cloudflare — in tal modo la velocità di scansione sarà massima senza rischio di blocchi.
Configurazione passo-passo dei proxy in Screaming Frog
Screaming Frog supporta i proxy "out of the box", la configurazione richiede un paio di minuti:
- Apri il programma e vai al menu Configuration → System → Proxy.
- Seleziona la casella Use Proxy Server for All Traffic.
- Inserisci l'indirizzo e la porta del server proxy forniti dal provider.
- Se il proxy richiede autenticazione tramite nome utente e password — indicali nella finestra pop-up alla prima richiesta.
- Clicca OK e riavvia il crawling per applicare le impostazioni.
Un'importante nota: Screaming Frog nelle versioni gratuita e a pagamento può lavorare solo con un server proxy alla volta tramite l'interfaccia integrata. Se hai bisogno di rotazione IP al volo (attuale durante la scansione di oltre 50.000 pagine), utilizza proxy con cambio automatico di IP da parte del provider — questo si configura non nel crawler stesso, ma nel pannello personale del servizio proxy, dove si imposta l'intervallo di cambio IP (ad esempio, ogni 10 minuti o ad ogni nuova richiesta).
Questo schema allevia il carico da un indirizzo: il crawler continua a lavorare con una sola porta, mentre l'IP cambia automaticamente, e il sito non vede una frequenza anormalmente alta di richieste da un indirizzo specifico.
Impostazioni di velocità e thread per grandi siti
Anche con un proxy funzionante, impostazioni di velocità di crawling troppo aggressive possono provocare blocchi. In Screaming Frog questo è gestito dalla sezione Configuration → Speed. I valori raccomandati per siti da 100.000 pagine:
- Max Threads: 2–5 per siti protetti, 10–15 per siti senza protezione rigorosa;
- Max URI/s: limita a 2–3 richieste al secondo all'inizio, aumenta gradualmente osservando i codici di risposta;
- Custom User-Agent: nella sezione Configuration → HTTP Header utilizza un User-Agent di un browser reale invece del standard "Screaming Frog SEO Spider", se il sito blocca i crawler in base all'intestazione;
- Respect robots.txt / crawl-delay: considera la direttiva Crawl-delay, se è specificata — ignorarla spesso porta a un ban a livello di server.
Per i siti con protezione aggressiva contro i bot, è utile anche attivare la modalità JavaScript Rendering solo dove è realmente necessario (siti SPA su React/Vue) — il rendering JS aumenta drasticamente il carico sul server e aumenta il rischio di blocchi durante il crawling tramite un solo IP.
Rotazione IP durante la scansione di oltre 100.000 pagine
Più grande è il sito, più è importante distribuire correttamente il carico tra gli indirizzi IP. Per audit di tale portata funzionano due schemi:
Rotazione temporale. L'IP cambia automaticamente ogni 5–15 minuti indipendentemente dal numero di richieste. Adatto per crawling prolungati e uniformi, quando la scansione si estende per diverse ore.
Rotazione per richiesta. Ogni nuova richiesta HTTP parte da un nuovo IP del pool. Questa modalità offre la massima protezione contro i blocchi, ma può interferire con il corretto funzionamento dell'autenticazione basata su cookie o con i parametri di sessione del sito — per un audit tecnico puro (raccolta di codici di stato, reindirizzamenti, meta-tag) questo non è critico.
Per le agenzie che conducono audit paralleli di più siti dei clienti, è ragionevole separare i pool di IP per progetti — questo previene situazioni in cui un blocco su un dominio si "propaga per errore" alla reputazione dell'IP quando si lavora con un altro sito.
Consiglio pratico: prima di un grande audit, avvia un crawling di prova su 500–1000 URL con le attuali impostazioni di velocità e proxy. Se in questo tempo non compaiono errori 403/429, puoi tranquillamente scalare la scansione su tutto il sito.
Checklist prima di avviare l'audit
- ✅ Proxy connesso e testato per accessibilità (verifica tramite curl o browser separato);
- ✅ Max Threads e Max URI/s impostati in modo conservativo per il primo passaggio;
- ✅ User-Agent configurato correttamente, non suscita sospetti presso il WAF;
- ✅ Respect robots.txt attivato, se il sito chiede esplicitamente di rispettare il Crawl-delay;
- ✅ JavaScript Rendering attivato solo in caso di reale necessità;
- ✅ Rotazione IP configurata per siti da 20.000–30.000 pagine;
- ✅ Salvataggio del progresso del crawling attivato (Configuration → Save Crawl) in caso di interruzione della sessione;
- ✅ Per l'audit di marketplace e portali protetti, scelti proxy residenziali o mobili invece di quelli di data center.
Errori comuni durante il crawling tramite proxy
Velocità troppo alta all'inizio. Gli specialisti spesso impostano il massimo di thread subito, sperando di accelerare l'audit. Di conseguenza, la protezione del sito reagisce immediatamente, e dopo pochi minuti l'intero pool di proxy finisce nella blacklist.
Un solo IP statico per tutti i progetti dei clienti. Se l'agenzia utilizza lo stesso proxy di data center per decine di audit al mese, la reputazione di questo IP diminuisce rapidamente — i sistemi di protezione di diversi siti scambiano dati sugli indirizzi sospetti tramite database comuni (ad esempio, Cloudflare IP Reputation).
Ignorare il geo-targeting. Se il sito auditato è impostato per una regione specifica (ad esempio, un negozio online russo con geo-blocco del traffico estero), l'uso di proxy con IP di un altro paese provoca di per sé una limitazione dell'accesso — anche senza un crawling aggressivo.
Assenza di monitoraggio durante il processo. Avviando un crawling per diverse ore, gli specialisti spesso non controllano i codici di risposta intermedi. Di conseguenza, scoprono il problema solo al termine, quando metà del rapporto è composta da errori di blocco, e non da dati reali sul sito.
Conclusione
I blocchi durante un audit tecnico in Screaming Frog si risolvono quasi sempre con una combinazione di tre fattori: il tipo di proxy corretto, una velocità di crawling ragionevole e una rotazione IP ben gestita. Per i propri siti senza protezione rigorosa, sono sufficienti i proxy di data center con aggiunta in whitelist. Per audit di concorrenti, marketplace e siti dietro Cloudflare sono necessari IP che appaiono come traffico di un normale utente.
Se esegui regolarmente audit di domini altrui o piattaforme protette, ti consigliamo di iniziare con proxy residenziali — riducono il rischio di blocchi sui sistemi anti-bot più aggressivi. Per compiti mirati su risorse altamente protette, è opportuno considerare proxy mobili, mentre per audit su larga scala della propria infrastruttura, i proxy di data center rimangono una soluzione valida e veloce.