Benchmark de rastreadores web de 2026: da indexação à inteligência agética Intel
Avaliamos quatro APIs de rastreamento em três domínios de dificuldade variável (amazon.com, entrepreneur.com, theregister.com) em três níveis máximos de profundidade (5, 10, 20) com um limite de 1.000 páginas, medindo a cobertura do rastreamento, o tempo de execução, a descoberta de links, a qualidade dos links em Markdown e a precisão da extração de títulos.
Se o seu objetivo é:
- Transforme páginas da web em dados estruturados; consulte nosso guia sobre web scraping .
- Analise sites inteiros e continue lendo.
benchmark de rastreadores da web
Você pode ler nossa metodologia de avaliação comparativa.
Média de páginas rastreadas versus custo por 1.000 páginas
Páginas rastreadas em todos os domínios por profundidade máxima
O robô Firecrawl rastreou consistentemente cerca de 100 páginas no theregister.com, independentemente da profundidade máxima, aproximadamente 90 páginas no entrepreneur.com em todos os níveis de profundidade e apenas cerca de 30 páginas no amazon.com, provavelmente devido à proteção agressiva contra bots da Amazon. Notavelmente, aumentar a profundidade máxima não teve praticamente nenhum impacto no número de páginas que o robô Firecrawl conseguiu rastrear em qualquer domínio.
Apify demonstrou o desempenho mais consistente, atingindo o limite máximo de rastreamento de 1.000 páginas em todos os domínios e em todos os níveis de profundidade sem qualquer dificuldade aparente, mesmo em sites fortemente protegidos como a Amazon.
Cloudflare apresentou comportamento inconsistente entre os testes:
- No site theregister.com, com profundidade máxima de 5, o mecanismo de busca rastreou apenas 100 páginas, mas com profundidade máxima de 20, alcançou quase 1.000 páginas.
- Como observamos em testes anteriores, o Cloudflare ocasionalmente rastreia apenas uma página e, em seguida, encerra a tarefa completamente. Confirmamos que não se trata de um problema de cache (o cache estava desativado) e testamos com intervalos de espera entre as execuções de até 1 minuto, mas o comportamento persistiu. Na profundidade máxima de 10 páginas em theregister.com, esse mesmo problema ocorreu: o Cloudflare rastreou apenas uma página antes de parar.
- No entrepreneur.com, o Cloudflare rastreou 780 páginas na profundidade 5, aumentou para 885 na profundidade 10, mas caiu drasticamente para apenas 172 páginas na profundidade 20. Essa queda pode estar relacionada ao agendador de rastreamento do Cloudflare despriorizando ou atingindo o tempo limite de cadeias de links mais profundas, ou pode refletir um limite de concorrência interno que faz com que o trabalho termine prematuramente quando a fronteira de rastreamento se torna muito grande em profundidades maiores.
- Na amazon.com, o Cloudflare rastreou 905 páginas na profundidade 5, mas esse número diminuiu constantemente à medida que a profundidade máxima aumentou, caindo para 809 na profundidade 10 e 795 na profundidade 20. Isso sugere que configurações de rastreamento mais profundas podem fazer com que o Cloudflare gaste mais tempo com a sobrecarga de descoberta de links do que com a recuperação real de páginas.
O rastreador Nimble atingiu ou se aproximou do limite de 1.000 páginas no theregister.com em todos os níveis de profundidade (1.000 / 1.000 / 999). No entrepreneur.com, rastreou 1.000 páginas na profundidade 5, mas apresentou pequenas quedas em profundidades maiores (896 na profundidade 10, 983 na profundidade 20), possivelmente devido ao seu tempo limite de 7 horas ter sido atingido antes de concluir o rastreamento completo em níveis mais profundos. Todas as execuções do Nimble terminaram com um status de tempo limite excedido. A Amazon se mostrou mais desafiadora.
- Na profundidade 5, conseguiu apenas 319 páginas, mas na profundidade 10 saltou para 988 páginas, caindo para 906 na profundidade 20.
- Essa inconsistência provavelmente reflete a combinação dos mecanismos de proteção contra bots da Amazon e as restrições de tempo limite do Nimble, onde rastreamentos mais profundos levam mais tempo para processar cada página e podem encontrar mais desafios anti-bot ao longo do caminho.
Tempo de execução em todos os domínios por profundidade máxima
O provedor Firecrawl foi o mais rápido em todos os domínios, concluindo as buscas em menos de 5 minutos, geralmente entre 75 e 265 segundos. Essa velocidade tem um custo em termos de abrangência, já que o Firecrawl também rastreou o menor número de páginas. Essencialmente, ele termina rapidamente porque para antes do tempo.
A consulta Apify levou cerca de 2.200 a 2.400 segundos (aproximadamente 40 minutos) no theregister.com, independentemente da profundidade. No entrepreneur.com e no amazon.com, os tempos de execução foram significativamente maiores, entre 8.300 e 15.900 segundos (2 a 4 horas), refletindo as estruturas maiores e mais complexas dos sites. Apesar dos tempos mais longos, a consulta Apify atingiu consistentemente o limite de 1.000 páginas, tornando-se a mais confiável em termos de relação entre cobertura e tempo.
Cloudflare apresentou uma cronometragem que reflete suas contagens de rastreamento inconsistentes:
- No site theregister.com, na profundidade 10, o processo foi concluído em apenas 1 segundo, pois rastreou apenas uma página antes de parar.
- No entrepreneur.com, com uma profundidade de 20, o processo foi concluído em 10 segundos após rastrear apenas 172 páginas.
- Quando o Cloudflare completa um rastreamento completo, os tempos variam de 3.500 a 25.200 segundos.
- À medida que a profundidade máxima aumenta, o rastreador Cloudflare parece priorizar o acesso a páginas mais profundas em detrimento da abrangência, rastreando menos páginas, mas concluindo mais rapidamente. No amazon.com, o tempo de execução caiu de 25.200 segundos (tempo limite) na profundidade 5 para apenas 5.660 segundos na profundidade 20, enquanto o número de páginas rastreadas também diminuiu de 905 para 795. Isso sugere que o rastreador do Cloudflare altera sua estratégia em profundidades maiores, dedicando menos tempo à descoberta ampla e mais à busca profunda.
O processo Nimble atingiu o tempo limite de 7 horas (25.200 segundos) em todas as execuções, em todos os domínios e níveis de profundidade. Isso é notável porque, em nossos testes rápidos anteriores com profundidade máxima de 1, o Nimble foi concluído sem atingir o tempo limite. No teste completo, com profundidades de 5 a 20 e um limite de 1.000 páginas, ele foi executado consistentemente até atingir o tempo limite. Apesar disso, o Nimble ainda conseguiu rastrear um grande número de páginas na maioria dos casos (cerca de 900 a 1.000 em theregister.com e entrepreneur.com), o que significa que ele rastreia ativamente durante as 7 horas, mas simplesmente nunca sinaliza a conclusão.
Taxa de preenchimento de texto do link entre provedores por profundidade máxima
Para avaliar a qualidade da saída em Markdown, medimos a porcentagem de links em Markdown de cada provedor que contêm texto âncora, ou seja, a parte clicável do link. A ausência de texto âncora (por exemplo, [](/about) em vez de [About Us](/about)) significa que o rastreador não conseguiu extrair o rótulo do link.
- Nimble : 100% em todas as profundidades
- Cloudflare : 91-94%
- Firecrawl : 90%
- Apify : 77-78%, aproximadamente 1 em cada 5 links sem texto âncora
A profundidade de rastreamento teve um impacto mínimo nas taxas de preenchimento para qualquer provedor, sugerindo que isso é uma característica do mecanismo de análise de cada provedor, e não uma configuração de rastreamento.
Taxa de preenchimento de texto de links entre provedores por domínio
Analisar as taxas de preenchimento em diferentes domínios revela como a complexidade do site afeta a qualidade da extração de links de cada provedor.
- Nimble manteve 100% em todos os domínios.
- A página Apify apresentou a maior variação, 89% no amazon.com, mas caindo para 66% no entrepreneur.com, o que significa que um terço de seus links nesse site não possuía texto âncora. Isso sugere que a página Apify tem mais dificuldades com sites que possuem muito conteúdo e estruturas de navegação complexas.
- Firecrawl teve o melhor desempenho no theregister.com (98%), mas caiu para 81% no entrepreneur.com, seguindo um padrão semelhante ao de Apify.
- Cloudflare foi o mais consistente depois de Nimble, mantendo-se entre 89-94% independentemente do domínio.
O domínio Entrepreneur.com provou ser o mais desafiador para a extração de texto de links; tanto Apify (66%) quanto Firecrawl (81%) tiveram suas pontuações mais baixas, provavelmente devido ao uso intenso de menus de navegação aninhados e elementos de conteúdo dinâmicos que são mais difíceis de converter corretamente em Markdown.
Total de links na saída Markdown em todos os domínios por profundidade máxima
A variação na quantidade de links entre os provedores foi consistentemente alta (74-97%), indicando que os provedores extraem números muito diferentes de links das mesmas páginas. Para obter uma visão mais detalhada dessa disparidade, medimos a quantidade total de links em Markdown por provedor.
- O resultado do Apify foi o que retornou o maior número de links no geral, principalmente no amazon.com, com mais de 420 mil links na profundidade 5 (aproximadamente 423 por página). No entrepreneur.com, estabilizou-se em torno de 63 mil, independentemente da profundidade. Seus dados incluem rastreadores de anúncios e pixels de rastreamento, além de links no conteúdo da página.
- O termo Cloudflare atingiu um pico de 303 mil no entrepreneur.com na profundidade 10, mas caiu para 53 mil na profundidade 20. Na mesma página inicial do entrepreneur.com, o termo Cloudflare extraiu 434 links, em comparação com os 143 do termo Apify, capturando menus de navegação completos e submenus.
- Firecrawl retornou consistentemente de 5 a 9 mil links em todas as configurações, limitado pelo seu baixo número de páginas.
- O serviço Nimble retornou um total de 3 a 40 mil links, com uma média de 5 a 28 links por página, em comparação com 60 a 420 para outros provedores. Na página inicial do entrepreneur.com, o Nimble retornou 13 links, contra 434 do Cloudflare, limitados aos títulos dos artigos principais. Sua taxa de preenchimento de 100% reflete o fato de que os links incluídos possuíam texto âncora, e não uma cobertura abrangente de links. O Nimble não gera links Markdown padrão. Sua contagem inclui links HTML escapados encontrados na saída Markdown.
O título apresenta a taxa entre os fornecedores.
A similaridade de títulos entre os provedores apresentou um desvio inferior a 1% em todos os testes e domínios, confirmando que, quando os provedores extraem um título, eles retornam consistentemente o mesmo resultado. A taxa de presença de títulos também permaneceu entre 98% e 100% em todos os níveis de profundidade máxima de rastreamento, demonstrando que a profundidade de rastreamento não tem impacto significativo na extração de títulos.
Ao analisar por domínio, algumas diferenças emergiram:
Nos sites entrepreneur.com e theregister.com, a maioria dos provedores alcançou taxas de apresentação de títulos entre 99% e 100%. Amazon.com foi o único domínio em que diferenças significativas foram observadas: Firecrawl caiu para 93% e Nimble para 95,9%, enquanto Apify manteve 99,6%. Isso está de acordo com a proteção mais robusta contra bots da Amazon, que pode bloquear ou distorcer as respostas das páginas, fazendo com que alguns provedores retornem páginas sem títulos extraíveis.
O que é um rastreador web?
Um rastreador web, também chamado de "aranha" ou "agente", é um robô que navega na internet para indexar conteúdo.
Os rastreadores evoluíram para além dos mecanismos de busca e agora servem como a Camada de Dados Agentes. Eles atuam como os olhos de agentes de IA autônomos, como Claude Code e OpenAI Operator, auxiliando em tarefas em tempo real, como pesquisas de mercado e transações complexas.
O que faz um rastreador web?
A coleta de dados na web foi dividida em três modos, cada um projetado para um objetivo diferente do rastreador.
- Modo de descoberta (tradicional): Bots de mecanismos de busca como o Googlebot rastreiam URLs para indexação, ajudando as pessoas a encontrar resultados por meio de mecanismos de busca.
- Modo de Recuperação (RAG): Bots de IA como ChatGPT-User ou PerplexityBot buscam páginas específicas em tempo real para responder às solicitações do usuário. Eles usam Markdown em vez de HTML para se adequarem aos limites de tokens do modelo de IA.
- Modo Agético (Orientado à Ação): Este novo tipo de rastreador, previsto para 2026, faz mais do que apenas ler conteúdo. Utilizando o Protocolo de Contexto de Modelo (MCP), esses bots podem interagir com sites para reservar voos ou executar comandos de software.
No passado, os rastreadores usavam seletores como XPath ou CSS para extrair dados. A extração nativa por IA tornou-se a norma.
Ferramentas como Firecrawl e Crawl4AI usam instruções em linguagem natural para encontrar dados. Em vez de escrever regras para cada elemento, os desenvolvedores podem dizer ao rastreador para "extrair o preço do produto", e a IA encontrará o valor correto mesmo que o código do site seja alterado.
Construir ou comprar rastreadores web na era da IA
1. Construindo seu próprio veículo de rastreamento
Ideal para proteger a propriedade intelectual essencial e permitir personalização profunda. Agora, a construção exige o desenvolvimento de uma camada de agente proprietária, e não apenas a escrita de scripts básicos do Scrapy.
- Quando construir: Selecione esta abordagem se o seu rastreador proporcionar uma vantagem competitiva única. Por exemplo, construa o seu próprio se estiver desenvolvendo um mecanismo de busca especializado ou se precisar de controle total sobre dados sensíveis ou regulamentados.
- O conjunto de ferramentas: Você não precisa mais começar do zero. Os desenvolvedores agora utilizam o Protocolo de Contexto de Modelo (MCP) para permitir que agentes de IA internos interajam com a web.
2. Utilizando ferramentas e APIs de rastreamento da web
As ferramentas gerenciadas evoluíram de simples extratores de dados para agentes autônomos.
- Extração sem manutenção: Ferramentas modernas como Kadoa e Firecrawl usam IA de autorreparação. Você especifica os dados necessários, como "Preço do Produto", em vez de sua localização no código. Se o layout do site mudar, a ferramenta se adapta automaticamente.
- Conformidade como serviço: Muitos fornecedores oferecem conformidade integrada com a Lei de IA da UE. Eles gerenciam os registros de auditoria necessários e as verificações de exclusão de direitos autorais, que são difíceis de implementar de forma independente.
- Rapidez na obtenção de valor: A aquisição de uma plataforma pode levar seu projeto do conceito à produção em questão de semanas.
Figura 5: Uma explicação de como funciona uma fronteira de URL.
Os rastreadores da web são legais?
Em geral, a coleta de dados na web é legal , mas dependendo de como e o que você coleta, você pode rapidamente se encontrar em apuros legais. Quatro pilares principais determinam se a coleta de dados (e a extração de dados que normalmente se segue) é legal:
1. Público vs. privado: Rastreie apenas dados que estejam abertamente disponíveis ao público sem a necessidade de uma conta.
2. Informações pessoais: Evite o envio de informações pessoais identificáveis (nomes, e-mails e endereços), a menos que você tenha uma base legal para tal.
3. Saúde do servidor: Utilize limites de taxa para evitar sobrecarregar o servidor; evite ataques DDoS contra um site.
4. Direitos autorais : Artigos e imagens são protegidos por direitos autorais, mas fatos (preços, datas) não são.
Qual a diferença entre web crawling e web scraping?
A extração de dados da web (web scraping) utiliza ferramentas de rastreamento da web para escanear e armazenar todo o conteúdo de uma página específica. Em outras palavras, a extração de dados da web é um caso de uso específico do rastreamento da web para criar um conjunto de dados direcionado, como coletar todas as notícias financeiras para análise de investimentos e pesquisar nomes de empresas específicas.
Tradicionalmente, depois que um rastreador web rastreava e indexava todos os elementos de uma página web, um web scraper extraía dados da página indexada. No entanto, hoje em dia, os termos "scraping" e "crawling" são usados como sinônimos, com a diferença de que "crawler" tende a se referir mais aos rastreadores de mecanismos de busca. À medida que empresas além dos mecanismos de busca começaram a usar dados da web, o termo "web scraper" passou a substituir o termo "web crawler".
Quais são os desafios da indexação web?
1. Atualização do banco de dados
O conteúdo dos sites é atualizado regularmente. Páginas web dinâmicas, por exemplo, alteram seu conteúdo com base nas atividades e comportamentos dos visitantes. Isso significa que o código-fonte do site não permanece o mesmo após a indexação. Para fornecer as informações mais atualizadas ao usuário, o rastreador web precisa rastrear essas páginas com mais frequência.
2. Armadilhas para lagartas
Os sites empregam diferentes técnicas, como armadilhas para rastreadores, para impedir que os rastreadores da web acessem e rastreiem determinadas páginas. Uma armadilha para rastreadores, ou armadilha para spiders, faz com que um rastreador da web faça um número infinito de solicitações e fique preso em um ciclo vicioso de rastreamento. Os sites também podem criar armadilhas para rastreadores involuntariamente. Em qualquer caso, quando um rastreador encontra uma armadilha para rastreadores, ele entra em algo como um loop infinito que desperdiça seus recursos.
3. Largura de banda da rede
Baixar um grande número de páginas da web irrelevantes, utilizar um rastreador da web distribuído ou rastrear novamente muitas páginas da web, tudo isso resulta em uma alta taxa de consumo de capacidade da rede.
4. Páginas duplicadas
Os robôs de busca geralmente rastreiam todo o conteúdo duplicado na web; no entanto, apenas uma versão de cada página é indexada. O conteúdo duplicado dificulta que os robôs dos mecanismos de busca determinem qual versão do conteúdo duplicado indexar e classificar. Quando o robô Google encontra um grupo de páginas web idênticas nos resultados de busca, ele indexa e seleciona apenas uma dessas páginas para exibir em resposta à consulta de busca do usuário.
As 3 principais práticas recomendadas para rastreamento da web
1. Taxa de polidez/rastejamento
Os sites definem uma taxa de rastreamento para limitar o número de solicitações feitas por robôs de rastreamento da web. Essa taxa indica quantas solicitações um robô de rastreamento pode fazer ao seu site em um determinado intervalo de tempo (por exemplo, 100 solicitações por hora). Isso permite que os proprietários de sites protejam a largura de banda de seus servidores e reduzam a sobrecarga. Um robô de rastreamento deve respeitar o limite de rastreamento do site de destino.
2. Conformidade com o robots.txt
Um arquivo robots.txt é um arquivo de texto localizado na raiz de um site que informa aos rastreadores quais páginas eles têm permissão para acessar ou não. Trata-se de um padrão voluntário, o que significa que os bots que o seguem o respeitam, mas ele não impede tecnicamente o acesso. Seguir as diretrizes do robots.txt de um site é considerado uma boa prática e, em muitas jurisdições, ignorá-las pode expor o site a riscos legais ou de reputação.
3. Rotação de IP
Os sites utilizam diferentes técnicas anti-raspagem, como CAPTCHAs, para gerenciar o tráfego de rastreadores e reduzir as atividades de web scraping. Por exemplo, a impressão digital do navegador é uma técnica de rastreamento usada por sites para coletar informações sobre os visitantes, como duração da sessão ou visualizações de página.
Este método permite que os proprietários de sites detectem "tráfego não humano" e bloqueiem o endereço IP do bot. Para evitar a detecção, você pode integrar proxies rotativos , como proxies residenciais , ao seu rastreador web.
Metodologia de avaliação comparativa de rastreadores da Web
Testamos quatro APIs de rastreamento (Apify, Nimble, Cloudflare, Firecrawl) em três domínios de diferentes níveis de dificuldade: amazon.com (forte proteção contra bots), entrepreneur.com (site com conteúdo complexo) e theregister.com (site de notícias).
Configuração compartilhada
Todos os fornecedores receberam configurações básicas idênticas para garantir uma comparação justa:
- Mapa do site: Desativado; os provedores devem descobrir as páginas somente por meio de links HTML.
- Links externos: Desativados; os rastreadores permanecem dentro do domínio de destino.
- Subdomínios: Ativados, as páginas de subdomínio são seguidas (ex.: india.entrepreneur.com)
- Renderização JavaScript: Ativada, todos os provedores usam um navegador sem interface gráfica.
- Cache: Desativado
- Limite de páginas: 1.000 páginas por tiragem
- Tempo limite: 7 horas (25.200 segundos)
- Tratamento de limite de taxa: espera de 20 segundos com até 3 tentativas no HTTP 429
Cada provedor foi testado em três níveis máximos de profundidade (5, 10, 20) em todos os três domínios, totalizando 36 execuções de rastreamento. Os provedores foram testados sequencialmente (não em paralelo), cada combinação foi executada uma vez e o status do rastreamento foi verificado a cada 1 segundo.
O servidor Apify foi configurado com o ator website-content-crawler usando o Playwright/Firefox como navegador sem interface gráfica. O acesso ao subdomínio foi controlado por meio de padrões glob, e o proxy integrado do Apify foi usado para todas as requisições.
Os provedores Nimble, Cloudflare e Firecrawl foram configurados usando suas respectivas APIs REST com as configurações compartilhadas descritas acima. Nenhuma configuração adicional específica do provedor foi aplicada além dos parâmetros padronizados.
Para o serviço Cloudflare, utilizamos o plano Workers Paid. O custo apresentado reflete o que gastamos para rastrear 1.000 páginas com esse plano. O serviço Cloudflare cobra com base no tempo de renderização do navegador, e não na quantidade de páginas.
Para o código Firecrawl, utilizamos o plano Hobby. O custo apresentado é o valor proporcional a 1.000 créditos, dentre os créditos oferecidos neste plano. O custo efetivo por página varia de acordo com o plano escolhido e se pacotes de créditos adicionais foram adquiridos.
Comentários 1
Compartilhe suas ideias
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.
Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.