Benchmark de Web Crawler para Alimentar Sites com IA
Avaliamos quatro APIs de rastreamento em três domínios de dificuldade variada, em três níveis de profundidade máxima (5, 10, 20), com um limite de 1.000 páginas, medindo cobertura de rastreamento, tempo de execução, descoberta de links, qualidade dos links em markdown e precisão da extração de títulos.
Se você deseja:
- Transformar páginas web em dados estruturados, consulte nosso guia sobre web scraping.
- Rastrear sites inteiros, continue lendo.
Benchmark de web crawlers
Você pode ler nossa metodologia de benchmark.
Média de páginas rastreadas vs custo por 1.000 páginas
Páginas rastreadas entre domínios por profundidade máxima
Firecrawl rastreou consistentemente cerca de 100 páginas em theregister.com, independentemente da profundidade máxima, aproximadamente 90 páginas em entrepreneur.com em todos os níveis de profundidade, e apenas cerca de 30 páginas em amazon.com, provavelmente devido à proteção agressiva contra bots da Amazon. Notavelmente, aumentar a profundidade máxima praticamente não teve impacto no número de páginas que o 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 nenhuma dificuldade aparente, mesmo em sites fortemente protegidos como o Amazon.
Cloudflare apresentou comportamento inconsistente entre os testes:
- Em theregister.com, na profundidade máxima 5, rastreou apenas 100 páginas, mas na profundidade máxima 20 chegou a quase 1.000 páginas.
- Como observamos em testes anteriores, o Cloudflare ocasionalmente rastreia apenas 1 página e, em seguida, encerra o trabalho completamente. Confirmamos que isso não é um problema de cache (o cache foi desativado) e testamos com tempos de espera entre execuções de até 1 minuto, mas o comportamento persistiu. Na profundidade máxima 10 em theregister.com, esse mesmo problema ocorreu, e o Cloudflare rastreou apenas 1 página antes de parar.
- Em entrepreneur.com, o Cloudflare rastreou 780 páginas na profundidade 5, aumentou para 885 na profundidade 10, mas depois caiu bruscamente para apenas 172 páginas na profundidade 20. Essa queda pode estar relacionada ao agendador de rastreamento do Cloudflare desprioritizar ou expirar cadeias de links mais profundas, ou pode refletir um limite interno de concorrência que faz o trabalho terminar prematuramente quando a fronteira de rastreamento cresce demais em profundidades maiores.
- Em amazon.com, o Cloudflare rastreou 905 páginas na profundidade 5, mas o número caiu constantemente conforme a profundidade máxima aumentou, diminuindo para 809 na profundidade 10 e 795 na profundidade 20, sugerindo que configurações de rastreamento mais profundas podem fazer o Cloudflare gastar mais tempo com sobrecarga de descoberta de links do que com a recuperação real de páginas.
Nimble atingiu ou se aproximou do limite de 1.000 páginas em theregister.com em todos os níveis de profundidade (1.000 / 1.000 / 999). Em 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 porque o tempo limite de 7 horas foi atingido antes da conclusão do rastreamento completo em níveis mais profundos; todas as execuções do Nimble terminaram com status de tempo limite. O Amazon se mostrou mais desafiador:
- Na profundidade 5, conseguiu apenas 319 páginas, mas na profundidade 10 saltou para 988 páginas e depois caiu para 906 na profundidade 20
- Essa inconsistência provavelmente reflete a combinação dos mecanismos de proteção contra bots da Amazon e das restrições de tempo limite do Nimble, já que 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 entre domínios por profundidade máxima
Firecrawl foi o provedor mais rápido em todos os domínios, concluindo os rastreamentos em menos de 5 minutos, normalmente entre 75 e 265 segundos. Essa velocidade tem o custo da cobertura, já que o Firecrawl também rastreou o menor número de páginas. Essencialmente, ele termina rápido porque para cedo.
Apify levou cerca de 2.200 a 2.400 segundos (~40 minutos) em theregister.com, independentemente da profundidade. Em entrepreneur.com e amazon.com, os tempos de execução foram significativamente mais longos, entre 8.300 e 15.900 segundos (2-4 horas), refletindo estruturas de site maiores e mais complexas. Apesar dos tempos mais longos, o Apify atingiu consistentemente o limite de 1.000 páginas, tornando-o o mais confiável em termos de relação cobertura-tempo.
Cloudflare apresentou tempos que refletem suas contagens de rastreamento inconsistentes:
- Em theregister.com, na profundidade 10, concluiu em apenas 1 segundo, porque rastreou apenas 1 página antes de parar.
- Em entrepreneur.com, na profundidade 20, terminou em 10 segundos após rastrear apenas 172 páginas.
- Quando o Cloudflare conclui um rastreamento completo, os tempos variam de 3.500 a 25.200 segundos.
- À medida que a profundidade máxima aumenta, o Cloudflare parece priorizar alcançar páginas mais profundas em detrimento da amplitude, rastreando menos páginas, mas concluindo mais rápido. Em 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 as páginas rastreadas também diminuíram de 905 para 795. Isso sugere que o crawler do Cloudflare muda sua estratégia em profundidades maiores, gastando menos tempo em descoberta ampla e mais em travessia profunda.
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 1, o Nimble concluiu sem atingir o tempo limite. No benchmark completo, com profundidades de 5 a 20 e limite de 1.000 páginas, ele executou consistentemente até o tempo limite ser atingido. Apesar disso, o Nimble ainda conseguiu rastrear um alto número de páginas na maioria dos casos (~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 de link por provedor e profundidade máxima
Para avaliar a qualidade da saída em markdown, medimos qual porcentagem de links no markdown de cada provedor contém texto âncora, a parte clicável de um link. A ausência de texto âncora (por exemplo, [](/about) em vez de [About Us](/about)) significa que o crawler não conseguiu extrair o rótulo do link.
- Nimble: 100% em todas as profundidades
- Cloudflare: 91-94%
- Firecrawl: 90%
- Apify: 77-78% , cerca de 1 em cada 5 links sem texto âncora
A profundidade de rastreamento teve impacto mínimo nas taxas de preenchimento de qualquer provedor, sugerindo que isso é uma característica do mecanismo de parsing de cada provedor, e não uma configuração de rastreamento.
Taxa de preenchimento de texto de link por provedor e 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.
- Apify apresentou a maior variação, 89% em amazon.com, mas caindo para 66% em entrepreneur.com, o que significa que um terço dos links nesse site estava sem texto âncora. Isso sugere que o Apify tem mais dificuldade com sites ricos em conteúdo e com estruturas de navegação complexas.
- Firecrawl teve o melhor desempenho em theregister.com (98%), mas caiu para 81% em entrepreneur.com, seguindo um padrão semelhante ao do Apify.
- Cloudflare foi o mais consistente depois do Nimble, permanecendo entre 89-94%, independentemente do domínio.
Entrepreneur.com provou ser o domínio mais desafiador para a extração de texto de link; tanto o Apify (66%) quanto o Firecrawl (81%) tiveram suas menores pontuações ali, provavelmente devido ao uso intenso de menus de navegação aninhados e elementos de conteúdo dinâmico que são mais difíceis de converter de forma limpa em markdown.
Total de links na saída em markdown por domínio e profundidade máxima
A variação na contagem de links entre 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 contagem total de links em markdown por provedor.
- Apify retornou o maior número de links no geral, particularmente em amazon.com, com mais de 420K links na profundidade 5 (~423 por página). Em entrepreneur.com, estabilizou-se em torno de 63K, independentemente da profundidade. Sua saída inclui rastreadores de anúncios e pixels de rastreamento junto com links de conteúdo da página.
- Cloudflare atingiu o pico de 303K em entrepreneur.com na profundidade 10, mas caiu para 53K na profundidade 20. Na mesma página inicial de entrepreneur.com, o Cloudflare extraiu 434 links, em comparação com Apify, que extraiu 143, capturando menus de navegação e submenus completos.
- Firecrawl retornou consistentemente de 5 a 9K links em todas as configurações, limitado por sua baixa contagem de páginas.
- Nimble retornou de 3 a 40K links no total, com uma média de 5 a 28 links por página, em comparação com 60-420 dos outros provedores. Na página inicial de entrepreneur.com, o Nimble retornou 13 links contra Cloudflare com 434, limitando-se às principais manchetes de artigos. Sua taxa de preenchimento de 100% reflete que os links que ele incluiu tinham todos texto âncora, em vez de indicar cobertura abrangente de links. O Nimble não produz links de markdown padrão. Sua contagem inclui links HTML escapados encontrados na saída em markdown.
Taxa de presença de título por provedor
A similaridade de títulos entre provedores apresentou desvio de menos de 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ítulo também permaneceu entre 98 e 100% em todos os níveis de profundidade máxima, mostrando que a profundidade de rastreamento não tem impacto significativo na extração de títulos.
Quando discriminado por domínio, algumas diferenças surgiram:
Em entrepreneur.com e theregister.com, a maioria dos provedores alcançou taxas de presença de título de 99 a 100%. O amazon.com foi o único domínio em que diferenças significativas apareceram: o Firecrawl caiu para 93% e o Nimble para 95.9%, enquanto o Apify manteve 99.6%. Isso está alinhado com a proteção mais rígida contra bots da Amazon, que pode bloquear ou distorcer respostas de página, fazendo com que alguns provedores retornem páginas sem títulos extraíveis.
O que é um web crawler?
Um web crawler, às vezes chamado de “aranha” ou “agente”, é um bot que navega pela internet para indexar conteúdo.
Os crawlers foram além dos mecanismos de busca e agora atuam como a Camada de Dados Agêntica. Eles funcionam como os olhos de agentes autônomos de IA, como o Claude Code e o OpenAI Operator, auxiliando em tarefas em tempo real, como pesquisa competitiva e transações de várias etapas.
O que um web crawler faz?
O web crawling foi dividido em três modos, cada um projetado para um objetivo diferente do crawler.
- Modo de descoberta (tradicional): Bots de mecanismos de busca, como o Googlebot, rastreiam URLs para indexação, ajudando as pessoas a encontrar resultados nos mecanismos de busca.
- Modo de recuperação (RAG): Bots de IA, como o ChatGPT-User ou o PerplexityBot, buscam páginas específicas em tempo real para responder aos prompts dos usuários. Eles usam markdown em vez de HTML para se adequar aos limites de tokens do modelo de IA.
- Modo agêntico (orientado a ações): Esse novo tipo de crawler em 2026 faz mais do que apenas ler conteúdo. Usando o Model Context Protocol (MCP), esses bots podem interagir com sites para reservar voos ou executar comandos de software.
No passado, os crawlers usavam seletores como XPath ou CSS para extrair dados. A extração nativa de IA tornou-se a norma.
Ferramentas como o Firecrawl e o Crawl4AI usam instruções em linguagem natural para encontrar dados. Em vez de escrever regras para cada elemento, os desenvolvedores podem dizer ao crawler para “extrair o preço do produto”, e a IA encontrará o valor correto mesmo que o código do site mude.
Construir vs. comprar web crawlers na era da IA
1. Construindo seu próprio crawler
Ideal para proteger a propriedade intelectual central e permitir personalização profunda. Hoje, construir exige desenvolver uma camada de agente proprietária, não apenas escrever scripts básicos em Scrapy.
- Quando construir: Escolha essa abordagem se o seu crawler oferecer uma vantagem competitiva única. Por exemplo, construa o seu próprio se você estiver desenvolvendo um mecanismo de busca especializado ou precisar de controle total sobre dados sensíveis ou regulados.
- O conjunto de ferramentas: Você não precisa mais começar do zero. Os desenvolvedores agora aproveitam o Model Context Protocol (MCP) para permitir que agentes internos de IA interajam com a web.
2. Usando ferramentas de web crawling e APIs
Ferramentas gerenciadas evoluíram de scrapers básicos para agentes autônomos.
- Extração com manutenção zero: Ferramentas modernas, como Kadoa e o Firecrawl, usam IA autorreparadora. Você especifica os dados necessários, como “Preço do Produto”, em vez da localização no código. Se o layout do site mudar, a ferramenta se adapta automaticamente.
- Conformidade como serviço: Muitos provedores oferecem conformidade integrada com a Lei de IA da UE. Eles gerenciam os registros de auditoria exigidos e as verificações de opt-out de direitos autorais, que são desafiadoras de implementar de forma independente.
- Velocidade para gerar valor: Comprar uma plataforma pode levar seu projeto do conceito à produção em semanas.
Os web crawlers são legais?
Em geral, o web crawling é legal, mas, dependendo de como e do que você rastreia, você pode rapidamente se encontrar em um problema jurídico. Quatro pilares principais determinam se o rastreamento (e o scraping que normalmente se segue) é legal:
1. Público vs. privado: Rastreie apenas dados publicamente disponíveis sem a necessidade de conta.
2. Informações pessoais: Evite PII (nomes, e-mails e endereços), a menos que você tenha uma base legal.
3. Saúde do servidor: Use limites de taxa para evitar sobrecarregar o servidor; evite “DDOSing” em um site.
4. Direitos autorais: Artigos e imagens são protegidos por direitos autorais, mas fatos (preços, datas) não.
Qual é a diferença entre web crawling e web scraping?
Web scraping é usar web crawlers para varrer e armazenar todo o conteúdo de uma página da web alvo. Em outras palavras, web scraping é um caso de uso específico de web crawling para criar um dataset direcionado, como extrair todas as notícias de finanças para análise de investimentos e buscar nomes específicos de empresas.
Tradicionalmente, depois que um web crawler rastreava e indexava todos os elementos de uma página da web, um web scraper extraía dados da página indexada. No entanto, hoje em dia os termos scraping e crawling são usados de forma intercambiável, com a diferença de que crawler tende a se referir mais aos crawlers de mecanismos de busca. À medida que empresas além dos mecanismos de busca passaram a usar dados da web, o termo web scraper começou a substituir o termo web crawler.
Adicionar como fonte preferencialQuais são os desafios do web crawling?
1. Atualização do banco de dados
O conteúdo dos sites é atualizado regularmente. Páginas web dinâmicas, por exemplo, mudam 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 depois que você o rastreia. Para fornecer as informações mais atualizadas ao usuário, o web crawler deve rastrear novamente essas páginas com mais frequência.
2. Armadilhas de crawler
Os sites empregam técnicas diferentes, como armadilhas de crawler, para impedir que web crawlers acessem e rastreiem certas páginas da web. Uma armadilha de crawler, ou armadilha de aranha, faz com que um web crawler faça um número infinito de requisições e fique preso em um ciclo vicioso de rastreamento. Os sites também podem criar armadilhas de crawler sem intenção. Em qualquer caso, quando um crawler encontra uma armadilha de crawler, ele entra em algo como um loop infinito que desperdiça os recursos do crawler.
3. Largura de banda de rede
Baixar um grande número de páginas web irrelevantes, utilizar um web crawler distribuído ou rastrear muitas páginas novamente resultam em alto consumo de capacidade de rede.
4. Páginas duplicadas
Os bots de web crawler rastreiam principalmente todo o conteúdo duplicado na web; no entanto, apenas uma versão de uma página é indexada. Conteúdo duplicado dificulta que os bots dos mecanismos de busca determinem qual versão do conteúdo duplicado indexar e classificar. Quando o Googlebot descobre um grupo de páginas da web idênticas nos resultados de busca, ele indexa e seleciona apenas uma dessas páginas para exibir em resposta à consulta de um usuário.
As 3 melhores práticas de web crawling
1. Polidez/Taxa de rastreamento
Os sites definem uma taxa de rastreamento para limitar o número de requisições feitas por bots de web crawler. A taxa de rastreamento indica quantas requisições um web crawler pode fazer ao seu site em um determinado intervalo de tempo (por exemplo, 100 requisições por hora). Ela permite que os proprietários de sites protejam a largura de banda de seus servidores web e reduzam a sobrecarga do servidor. Um web crawler deve respeitar o limite de rastreamento do site de destino.
2. Conformidade com o robots.txt
Um arquivo robots.txt é um arquivo de texto colocado na raiz de um site que informa aos crawlers quais páginas eles têm permissão ou não para acessar. É um padrão voluntário, o que significa que bots compatíveis o respeitam, mas ele não impede tecnicamente o acesso. Seguir o robots.txt de um site é considerado uma prática recomendada e, em muitas jurisdições, ignorá-lo pode expô-lo a riscos legais ou de reputação.
3. Rotação de IP
Os sites empregam diferentes técnicas anti-scraping, como CAPTCHAs para gerenciar o tráfego de crawlers e reduzir 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 visitantes, como duração da sessão ou visualizações de página.
Esse 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 residenciais proxies, ao seu web crawler.
Metodologia do benchmark de web crawlers
Testamos quatro APIs de rastreamento (Apify, Nimble, Cloudflare, Firecrawl) em três domínios de dificuldade variada: amazon.com (proteção pesada contra bots), entrepreneur.com (site de conteúdo complexo) e theregister.com (site de notícias).
Configuração compartilhada
Todos os provedores receberam as mesmas configurações essenciais para garantir uma comparação justa:
- Sitemap: desativado, os provedores devem descobrir páginas apenas por meio de links HTML
- Links externos: desativados, os crawlers permanecem dentro do domínio de destino
- Subdomínios: ativados, páginas de subdomínios são seguidas (por exemplo, india.entrepreneur.com)
- Renderização de JavaScript: ativada, todos os provedores usam um navegador headless
- Cache: desativado
- Limite de páginas: 1.000 páginas por execução
- Tempo limite: 7 horas (25.200 segundos)
- Tratamento de limite de taxa: espera de 20 segundos com até 3 novas tentativas em HTTP 429
Cada provedor foi testado em três níveis de profundidade máxima (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 consultado a cada 1 segundo.
O Apify foi configurado com o ator website-content-crawler usando Playwright/Firefox como navegador headless. O acesso a subdomínios foi controlado por padrões glob, e o proxy integrado do Apify foi usado para todas as requisições.
O Nimble, o Cloudflare e o Firecrawl foram configurados usando suas respectivas APIs REST com as configurações compartilhadas descritas acima. Nenhuma configuração específica de provedor foi aplicada além dos parâmetros padronizados.
Para o Cloudflare, usamos o plano Workers Paid. O custo relatado reflete o que gastamos para rastrear 1.000 páginas neste plano. O Cloudflare cobra com base no tempo de renderização do navegador, e não na contagem de páginas.
Para o Firecrawl, usamos o plano Hobby. O custo relatado é o valor rateado para 1.000 créditos dos créditos fornecidos neste plano. O custo efetivo por página varia de acordo com o nível do plano e se pacotes extras de créditos são adquiridos.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Benchmark de Web Crawler para Alimentar Sites com IA}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/web-crawler}},
note = {AIMultiple. Acessado em 11 Agosto 2026}
}Registro de alterações
9 atualizações- 2026
Removidas as seções de tendências do setor, tipos de rastreadores e exemplos de rastreamento web.
Adicionado um benchmark de quatro APIs de rastreamento em três domínios e três níveis de profundidade, com gráficos de cobertura, velocidade, links e títulos.
Adicionada uma seção de metodologia detalhando a configuração de rastreamento em quatro fornecedores, três domínios e três níveis de profundidade.
Adicionada uma seção, Os rastreadores da web são legais?, ao artigo.
Atualizada a seção "O que é um rastreador da web?" com novas tendências e modos de operação.
- 2024
Atualizado o ano na seção "Os melhores rastreadores da web".
- 2023
Adicionado um resumo rápido dos melhores rastreadores da web de 2023 à introdução.
Removida a seção "Por que o rastreamento da web é importante?".
Expandida a introdução com uma definição de web crawler e web scraping.
O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]
Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.
Ele liderou a estratégia de tecnologia e as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia líderes como TechCrunch e Business Insider.
Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University e possui um MBA pela Columbia Business School.
A seguir, leia
Scraping no eBay: Comparação dos 6 Principais Provedores
Os 4 principais provedores de scraping do Google Play comparados
Top 5 Scrapers de Avaliações da Amazon Comparados
Comentários 1
Compartilhe suas ideias
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.
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.