Benchmark de Web Crawlers para Alimentar Sites com IA
Comparamos 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 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 na extração de títulos.
Se você pretende:
- Para transformar páginas web em dados estruturados, consulte nosso guia sobre web scraping.
- Para 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 qualquer dificuldade aparente, mesmo em sites fortemente protegidos como a Amazon.
Cloudflare apresentou comportamento inconsistente entre os testes:
- Em theregister.com, na profundidade máxima 5, ele 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 depois encerra completamente a tarefa. Confirmamos que isso não é um problema de cache (o cache estava 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 exato problema ocorreu: 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 despriorizar ou expirar cadeias de links mais profundas, ou pode refletir um limite interno de concorrência que faz a tarefa 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 aumentava, caindo 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 em vez da efetiva recuperação 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 de concluir o rastreamento completo em níveis mais profundos; todas as execuções do Nimble terminaram com status de tempo limite. A Amazon se mostrou mais desafiadora:
- 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 limitações de tempo limite do Nimble, em que rastreamentos mais profundos levam mais tempo para processar cada página e podem encontrar mais desafios antibot 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 rastreamentos em menos de 5 minutos, normalmente entre 75-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 rapidamente porque interrompe cedo.
O Apify levou cerca de 2.200-2.400 segundos (~40 minutos) em theregister.com, independentemente da profundidade. Em entrepreneur.com e amazon.com, os tempos de execução foram significativamente maiores, de 8.300-15.900 segundos (2 a 4 horas), refletindo as estruturas de site maiores e mais complexas. Apesar dos tempos mais longos, o Apify consistentemente atingiu 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 inconsistentes de rastreamento:
- Em theregister.com na profundidade 10, ele concluiu em apenas 1 segundo, porque rastreou apenas 1 página antes de parar.
- Em entrepreneur.com na profundidade 20, ele 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.
- Conforme a profundidade máxima aumenta, o Cloudflare parece priorizar alcançar páginas mais profundas em vez 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 rastreador 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 estourar o tempo. No benchmark completo com profundidades de 5-20 e limite de 1.000 páginas, ele consistentemente rodou 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-1.000 em theregister.com e entrepreneur.com), o que significa que ele está rastreando ativamente durante as 7 horas, mas simplesmente nunca sinaliza conclusão.
Taxa de preenchimento de texto de link entre provedores por 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 rastreador não conseguiu extract 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 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 link entre provedores por domínio
Observar 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 seus links nesse site estava sem texto âncora. Isso sugere que o Apify tem mais dificuldade com sites ricos em conteúdo que possuem 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 Apify.
- Cloudflare foi o mais consistente depois do Nimble, mantendo-se entre 89-94%, independentemente do domínio.
Entrepreneur.com se mostrou o domínio mais desafiador para a extração de texto de link; tanto o Apify (66%) quanto o Firecrawl (81%) tiveram suas pontuações mais baixas lá, 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 de forma limpa em markdown.
Total de links na saída markdown entre domínios por profundidade máxima
A variação na contagem de links entre provedores foi consistentemente alta (74-97%), indicando que os provedores extract 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, principalmente 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 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 143 do Apify, capturando menus de navegação completos e submenus.
- Firecrawl retornou consistentemente de 5 a 9K links em todas as configurações, limitado pelo seu baixo número de páginas.
- Nimble retornou de 3 a 40K links no total, com média de 5 a 28 links por página, em comparação com 60-420 de outros provedores. Na página inicial de entrepreneur.com, o Nimble retornou 13 links, contra 434 do Cloudflare, limitando-se às manchetes dos artigos principais. 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 markdown padrão. Sua contagem inclui links HTML escapados encontrados na saída markdown.
Taxa de presença de título entre provedores
A similaridade de títulos entre provedores apresentou menos de 1% de desvio em todos os testes e domínios, confirmando que, quando os provedores extract um título, eles retornam consistentemente o mesmo resultado. A taxa de presença de título também permaneceu entre 98-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 detalhado 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-100%. Amazon.com foi o único domínio em que surgiram diferenças significativas: o Firecrawl caiu para 93% e o Nimble para 95,9%, enquanto o Apify manteve 99,6%. Isso está alinhado com a proteção antibot mais pesada 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.
Recursos das melhores APIs de web crawler
Decodo oferece rastreamento por meio de /crawl, um endpoint de sua Web Data API. Todos os endpoints da Web Data API rodam sob uma única API e uma única chave de API. Uma tarefa /crawl coleta até 10.000 páginas e retorna cada página como Markdown ou HTML.
- Os usuários definem a profundidade máxima, filtram caminhos com expressões regulares e mantêm o rastreamento em um host, seus subdomínios ou todos os domínios.
- O rastreador usa o sitemap, os links da página ou ambos e solicita páginas de um país e localidade escolhidos.
- Uma duração máxima interrompe a tarefa e mantém as páginas coletadas até o momento.
- Uma página que falha sem JavaScript ganha mais uma tentativa com renderização via JavaScript.
O endpoint /map lista até 147.000 URLs de uma página e do sitemap de nível superior do site sem buscar conteúdo, para que um rastreamento possa ter como alvo apenas caminhos selecionados. O gratuito plano inclui 10.000 solicitações por mês sem cartão de crédito.
Comece com 10K gratuito solicitações/mês para testar a Decodo Web Data API
Visite o siteO Apify rastreia sites por meio do Website Content Crawler, um Ator na plataforma Apify. Por padrão, ele busca páginas estáticas via HTTP simples e muda para um navegador headless para páginas que precisam de JavaScript. Os usuários também podem executá-lo no modo somente navegador ou somente HTTP.
- Os usuários definem URLs iniciais, profundidade máxima, máximo de páginas e padrões de URL a incluir ou excluir, e podem adicionar sitemaps para descoberta.
- Uma data “modificado desde” limita o rerastreamento a páginas alteradas.
- Um seletor CSS remove navegação, cabeçalhos e rodapés antes da conversão.
- O rastreador retorna texto, Markdown, HTML e capturas de tela, e pode baixar arquivos PDF, Word e Excel vinculados.
O Apify conecta a saída ao LangChain, LlamaIndex, Pinecone e Qdrant, e oferece o rastreador como uma ferramenta MCP.
O Cloudflare oferece um endpoint /crawl em seu serviço Browser Rendering. Uma tarefa cobre até 100.000 páginas e é executada por até sete dias, e os resultados permanecem disponíveis por 14 dias.
- O rastreador encontra páginas por meio de sitemaps, links de páginas ou ambos, e filtra URLs com padrões curinga.
- Ele renderiza páginas em um navegador headless por padrão e, em vez disso, pode buscar HTML simples sem JavaScript.
- A saída é HTML, Markdown ou JSON.
O rastreador obedece ao robots.txt, incluindo crawl-delay, e se identifica com um user agent fixo. O Cloudflare afirma que não ignora CAPTCHAs ou proteção contra bots.
O endpoint /crawl do Firecrawl descobre e raspa as subpáginas de uma URL inicial e retorna Markdown, HTML ou JSON para cada página.
- Os usuários definem um limite de páginas, uma profundidade de descoberta e filtros de caminho por regex.
- O rastreamento pode se estender a caminhos pais, subdomínios ou um salto de links externos.
- O rastreador combina o sitemap com links de página ou usa apenas um dos dois.
- Um parâmetro de prompt transforma uma instrução em linguagem simples em configurações de rastreamento.
Os resultados chegam por polling, eventos de webhook por página ou um observador de SDK, e permanecem disponíveis por 24 horas.
O Nimble Crawl executa cada rastreamento como uma tarefa em segundo plano de até 10.000 páginas e 20 saltos de link, e retorna HTML ou Markdown para cada página.
- Os usuários filtram caminhos com expressões regulares e escolhem se devem seguir subdomínios.
- O rastreador usa o sitemap, links de página ou ambos como origem.
- URLs que diferem apenas nos parâmetros de consulta podem contar como uma página.
- Cada rastreamento pode ser executado a partir de um país e localidade escolhidos.
Uma chamada de status informa quantas páginas estão pendentes, concluídas ou com falha, e o conteúdo de cada página vem de sua própria chamada de resultado. Callbacks são disparados quando o rastreamento começa, para cada página e no final.
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 básicas para garantir uma comparação justa:
- Sitemap: desativado; os provedores devem descobrir páginas apenas por links HTML
- Links externos: desativados; os rastreadores permanecem dentro do domínio de destino
- Subdomínios: ativados; páginas de subdomínios são seguidas (ex.: 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 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 verificado 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 solicitaçõ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 adicional específica do provedor foi aplicada além dos parâmetros padronizados.
Para o Cloudflare, usamos o plano Workers Paid. O custo reportado reflete o que gastamos para rastrear 1.000 páginas nesse 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 reportado é o valor proporcional de 1.000 créditos do total de créditos fornecidos nesse plano. O custo efetivo por página varia dependendo do nível do plano e da compra ou não de pacotes de crédito extras.
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 Crawlers para Alimentar Sites com IA}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/web-crawler}},
note = {AIMultiple. Acessado em 22 outubro 2026}
}Resultados e carimbos de data/hora de 152 pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 16 arquivos CSV.
Quer os dados granulares por trás disso? Assine o Premium
Registro de alterações
9 atualizaçõesRemovidas 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.
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.
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.