Um especialista em SEO inicia uma auditoria técnica de um grande site — e após 10 minutos, o Screaming Frog começa a retornar apenas 403 Forbidden ou 429 Too Many Requests. O servidor de proteção confundiu o crawler com um bot atacante e bloqueou o endereço IP. O resultado — a auditoria terá que ser reiniciada, e o cliente terá que ser informado sobre o atraso no relatório. O problema é resolvido com a configuração adequada de proxies para o crawler — vamos analisar como exatamente.
Por que os sites bloqueiam o Screaming Frog durante a auditoria
Screaming Frog, Sitebulb, JetOctopus e Netpeak Spider tecnicamente funcionam da mesma forma que os bots dos motores de busca: eles percorrem rapidamente milhares de URLs consecutivamente, baixam HTML, CSS, JS e imagens, verificam redirecionamentos e códigos de status. Do ponto de vista da proteção do site (Cloudflare, Qrator, DDoS-Guard, WAF embutido do provedor de hospedagem), isso parece uma atividade suspeita — muitos pedidos de um único IP em um curto espaço de tempo.
Bloqueios ocorrem especialmente durante auditorias de:
- grandes lojas online em uma infraestrutura semelhante à Wildberries com sua própria proteção contra scraping;
- sites atrás do Cloudflare com o modo "Under Attack" ativado ou um alto nível de Security Level;
- portais com conteúdo dinâmico, onde cada solicitação gera carga no servidor (busca, filtros, listagem de produtos);
- sites de concorrentes que você está analisando de um domínio diferente — eles não têm motivos para confiar no seu IP.
Uma dificuldade adicional: se a agência tem um único IP estático de escritório e as auditorias de sites ocorrem regularmente (vários clientes por dia), esse IP rapidamente entra em listas negras dos sistemas de proteção. Depois disso, são bloqueadas não apenas as auditorias atuais, mas também futuras do mesmo endereço — mesmo para sites que anteriormente abriam sem problemas.
Como reconhecer bloqueios pelos códigos de resposta
Antes de alterar as configurações do proxy, é importante entender o que está acontecendo. O Screaming Frog mostra o código de resposta na coluna Status Code — é fácil determinar a razão pela qual o crawling foi interrompido.
| Código de resposta | O que isso significa | O que fazer |
|---|---|---|
| 403 Forbidden | IP bloqueado pela proteção do site | Mudar IP, reduzir a velocidade do crawling |
| 429 Too Many Requests | Limite de solicitações excedido em um período de tempo | Reduzir o número de threads, adicionar atraso |
| 503 Service Unavailable | Servidor sobrecarregado ou proteção contra bots ativada | Mudar User-Agent, usar IP residencial |
| Sem resposta / Timeout | IP na lista negra, solicitações não chegam | Substituição completa do pool de proxies |
Se o relatório apresenta massivamente o mesmo código em milhares de URLs consecutivas — isso quase sempre indica um bloqueio por IP, e não um problema real do site. Para verificar a hipótese, basta abrir a URL problemática em um navegador comum a partir do mesmo IP. Se a página abrir normalmente, enquanto o Screaming Frog recebe 403 — o problema está no crawler, e não no site.
Quais proxies são adequados para SEO-crawling
A escolha do tipo de proxy depende da tarefa: auditoria pontual do seu site, monitoramento regular de concorrentes ou escaneamento de um marketplace protegido. Vamos analisar três tipos principais e sua aplicabilidade para crawlers.
| Tipo de proxy | Velocidade | Risco de bloqueio | Quando usar |
|---|---|---|---|
| Proxies de data center | Alta | Médio-alto em sites protegidos | Auditoria do próprio site sem proteção rigorosa |
| Proxies residenciais | Média | Baixo | Auditoria de concorrentes, sites atrás do Cloudflare, marketplaces |
| Proxies móveis | Média-baixa | Mínimo | Proteções mais agressivas, auditoria pontual rara |
Para a maioria das auditorias técnicas regulares, o equilíbrio ideal é fornecido por proxies residenciais — eles usam endereços IP reais de provedores, portanto, a proteção do site percebe as solicitações do crawler como tráfego de um usuário comum. Isso é especialmente importante se você estiver analisando não seu domínio, mas o site de um concorrente ou um marketplace com um sistema anti-bot rigoroso.
Proxies de data center continuam sendo uma boa opção quando você audita seu próprio site e pode adicionar previamente o intervalo de IP à lista branca no nível do WAF ou Cloudflare — assim, a velocidade de escaneamento será máxima sem risco de bloqueios.
Configuração passo a passo de proxies no Screaming Frog
O Screaming Frog suporta proxies "pronto para uso", a configuração leva alguns minutos:
- Abra o programa e vá para o menu Configuration → System → Proxy.
- Marque a opção Use Proxy Server for All Traffic.
- Insira o endereço e a porta do servidor proxy, obtidos do provedor.
- Se o proxy exigir autenticação por login e senha — forneça-os na janela pop-up na primeira solicitação.
- Clique em OK e reinicie o crawling para aplicar as configurações.
Um detalhe importante: o Screaming Frog nas versões gratuita e paga só consegue trabalhar com um servidor proxy por vez através da interface embutida. Se você precisar de rotação de IP em tempo real (relevante ao escanear a partir de 50.000 páginas), use proxies com troca automática de IP do lado do provedor — isso é configurado não no próprio crawler, mas no painel pessoal do serviço de proxy, onde se define o intervalo de troca de IP (por exemplo, a cada 10 minutos ou a cada nova solicitação).
Esse esquema alivia a carga de um único endereço: o crawler continua trabalhando com uma porta, enquanto o IP muda automaticamente, e o site não percebe uma frequência anormalmente alta de solicitações de um endereço específico.
Configurações de velocidade e threads para grandes sites
Mesmo com um proxy funcional, configurações de velocidade de crawling muito agressivas provocarão bloqueios. No Screaming Frog, isso é tratado na seção Configuration → Speed. Valores recomendados para sites com mais de 100.000 páginas:
- Max Threads: 2–5 para sites protegidos, 10–15 para sites sem proteção rigorosa;
- Max URI/s: limite a 2–3 solicitações por segundo no início, aumentando gradualmente, observando os códigos de resposta;
- Custom User-Agent: na seção Configuration → HTTP Header, use um User-Agent de um navegador real em vez do padrão "Screaming Frog SEO Spider", se o site bloquear crawlers pelo cabeçalho;
- Respect robots.txt / crawl-delay: considere a diretiva Crawl-delay, se estiver especificada — ignorá-la frequentemente leva a bloqueios no nível do servidor.
Para sites com proteção agressiva contra bots, também é útil ativar o modo JavaScript Rendering apenas onde realmente necessário (sites SPA em React/Vue) — a renderização de JS aumenta drasticamente a carga no servidor e eleva a chance de bloqueio ao crawlar através de um único IP.
Rotação de IP ao escanear 100.000+ páginas
Quanto maior o site, mais importante é distribuir a carga de forma adequada entre os endereços IP. Para auditorias dessa magnitude, funcionam dois esquemas:
Rotação por tempo. O IP muda automaticamente a cada 5–15 minutos, independentemente do número de solicitações. Adequado para crawling prolongado e uniforme, quando o escaneamento se estende por várias horas.
Rotação por solicitação. Cada nova solicitação HTTP é feita a partir de um novo IP do pool. Esse modo oferece a máxima proteção contra bloqueios, mas pode interferir no funcionamento correto com autenticação baseada em cookies ou parâmetros de sessão do site — para uma auditoria técnica pura (coleta de códigos de status, redirecionamentos, meta-tags), isso não é crítico.
Para agências que realizam auditorias paralelas de vários sites de clientes, é sensato dividir os pools de IP por projetos — isso evita a situação em que um bloqueio em um domínio "por engano" se espalha pela reputação do IP ao trabalhar com outro site.
Dica prática: antes de uma grande auditoria, execute um crawling de teste em 500–1000 URLs com as configurações atuais de velocidade e proxy. Se durante esse tempo não aparecerem erros 403/429, você pode escalar a varredura para todo o site sem preocupações.
Checklist antes de iniciar a auditoria
- ✅ Proxy conectado e testado quanto à acessibilidade (verificação via curl ou navegador separado);
- ✅ Max Threads e Max URI/s definidos conservadoramente para a primeira execução;
- ✅ User-Agent configurado corretamente, não levanta suspeitas no WAF;
- ✅ Respect robots.txt ativado, se o site pede claramente para respeitar o Crawl-delay;
- ✅ JavaScript Rendering ativado apenas quando realmente necessário;
- ✅ Rotação de IP configurada para sites com volume a partir de 20.000–30.000 páginas;
- ✅ Salvamento do progresso do crawling ativado (Configuration → Save Crawl) para o caso de interrupção da sessão;
- ✅ Para auditoria de marketplaces e portais protegidos, escolhidos proxies residenciais ou móveis em vez de data center.
Erros comuns ao crawlar através de proxies
Velocidade muito alta no início. Especialistas frequentemente configuram o máximo de threads de imediato, esperando acelerar a auditoria. Como resultado, a proteção do site reage rapidamente, e em poucos minutos todo o pool de proxies acaba na lista negra.
Um IP estático para todos os projetos de clientes. Se a agência usa o mesmo proxy de data center para dezenas de auditorias por mês, a reputação desse IP rapidamente cai — sistemas de proteção de diferentes sites trocam dados sobre endereços suspeitos através de bancos de dados comuns (por exemplo, Cloudflare IP Reputation).
Ignorar geo-targeting. Se o site auditado está configurado para uma região específica (por exemplo, uma loja online russa com bloqueio geográfico de tráfego estrangeiro), usar proxies com IP de outro país por si só provocará restrição de acesso — mesmo sem crawling agressivo.
Falta de monitoramento durante o processo. Ao iniciar um crawling por várias horas, os especialistas frequentemente não verificam os códigos de resposta intermediários. Como resultado, descobrem o problema apenas ao final, quando metade do relatório consiste em erros de bloqueio, e não em dados reais sobre o site.
Conclusão
Bloqueios durante a auditoria técnica no Screaming Frog quase sempre são resolvidos por uma combinação de três fatores: o tipo correto de proxy, uma velocidade de crawling razoável e uma rotação de IP adequada. Para sites próprios sem proteção rigorosa, proxies de data center são suficientes com a adição à lista branca. Para auditorias de concorrentes, marketplaces e sites atrás do Cloudflare, são necessários IPs que se pareçam com tráfego de usuários comuns.
Se você audita regularmente domínios de terceiros ou plataformas protegidas, recomendamos começar com proxies residenciais — eles reduzem o risco de bloqueio em sistemas anti-bot mais agressivos. Para tarefas pontuais em recursos altamente protegidos, vale a pena considerar proxies móveis, enquanto para auditorias em larga escala de sua própria infraestrutura, proxies de data center continuam sendo uma solução boa e rápida.