Todo guia de “Scrapy vs. Selenium” na internet acaba dizendo mais ou menos a mesma coisa: o Scrapy é mais rápido, o Selenium aguenta JavaScript, então é só escolher o remédio. A linha geral até faz sentido, mas aquelas promessas genéricas de páginas por minuto não se sustentam. O desempenho depende do alvo, da rede, da concorrência, do ciclo de vida do navegador, dos waits e dos controles anti-bot.
Este guia compara as arquiteturas e os trade-offs operacionais que realmente fazem diferença de um projeto para outro. Também entra no que a maioria das comparações costuma deixar de lado: como a automação de navegador muda o modelo de recursos, por que a renderização seletiva muitas vezes é melhor do que um crawl inteiro baseado em navegador e quando uma API de extração gerenciada faz mais sentido do que qualquer um dos frameworks.
Veredito rápido: Scrapy vs. Selenium em 2026
Se você quiser a versão curta: o Scrapy vence em velocidade, escala e eficiência de recursos para qualquer coisa renderizada no servidor. O Selenium vence quando você precisa de um navegador real fazendo coisas de navegador de verdade — clicar, digitar, esperar um modal aparecer. Nenhum dos dois é especialmente forte contra defesas anti-bot modernas por padrão, e o Playwright acabou assumindo, de forma silenciosa, a maior parte dos casos de uso que antes iam para o Selenium.
Aqui está a matriz de decisão que eu realmente uso:
| Sua situação | Escolha |
|---|---|
| Páginas estáticas ou renderizadas no servidor, alto volume | Scrapy |
| SPA pesada em JS com login, cliques e fluxos em várias etapas | Selenium ou Playwright |
| Site misto — principalmente estático, com algumas áreas só em JS | Híbrido Scrapy-Playwright |
| URLs conhecidas, só precisa de dados estruturados e pouca manutenção | API de extração com IA (Thunderbit e similares) |
Em meados de 2026, o Scrapy 2.17.0 já está disponível, o Selenium 4 continua ampliando o suporte ao WebDriver BiDi, e o scrapy-playwright oferece uma forma mantida de encaminhar solicitações selecionadas do Scrapy por um navegador. Guarda essa matriz de decisão — o resto do artigo explica por que ela funciona.
O que são Scrapy e Selenium (e por que os desenvolvedores ainda discutem sobre eles)
Comparar Scrapy com Selenium é um pouco como comparar um caminhão de entrega com um carro. Os dois levam algo do ponto A ao ponto B, mas um foi feito para transportar volume com eficiência, enquanto o outro foi pensado para ser conduzido por alguém que realmente precisa interagir com a estrada. A discussão continua porque as duas ferramentas conseguem fazer scraping — só que foram desenhadas para trabalhos diferentes, e muita gente escolhe a opção errada antes de perceber isso.
Scrapy: o motor assíncrono de crawling
O Scrapy é um framework em Python construído sobre o modelo assíncrono e não bloqueante orientado a eventos do Twisted. Ele não é um navegador — nunca foi —, só dispara requisições HTTP e faz o parsing do HTML que volta. Esse é o truque inteiro. Como não precisa esperar um navegador renderizar nada, ele consegue disparar dezenas de solicitações ao mesmo tempo sem travar.
De fábrica, o Scrapy já traz spiders, item pipelines, exporters de feed, middleware de retry e limitação de taxa. Não é um framework em que você vai precisar montar tudo do zero — muita coisa importante para produção já vem resolvida. A documentação de arquitetura do Scrapy separa Engine, Scheduler, Downloader e Item Pipeline como componentes independentes e intercambiáveis, o que explica bem por que ele envelheceu tão bem: dá para encaixar peças sem reescrever o núcleo.
O problema é que, sem navegador, não existe execução de JavaScript. Se os seus dados carregam por uma chamada fetch do lado do cliente depois que a página renderiza, o Scrapy não vê nada disso. Ele lê só o HTML inicial, ponto final.
Selenium: o navegador que você pode programar
O Selenium controla navegadores reais — Chrome, Firefox, Edge — por meio do protocolo W3C WebDriver, a especificação padronizada que torna o Selenium agnóstico em relação à linguagem e ao navegador, em vez de um truque exclusivo do Chrome. Ele renderiza JavaScript, executa chamadas AJAX e consegue clicar, rolar e digitar exatamente como uma pessoa faria.
Isso faz do Selenium a escolha certa para tudo que depende de interação: logins em várias etapas, assistentes, infinite scroll, menus suspensos que disparam chamadas de API. Mas cada uma dessas sessões de navegador pesa bastante. A própria orientação de dimensionamento do Selenium Grid sugere reservar cerca de 1 GB de RAM por sessão de navegador apenas como ponto de partida — e isso antes mesmo de considerar a carga de CPU de realmente renderizar páginas.
Um detalhe que confunde muita gente: o carregamento da página terminar não significa que a interface está pronta. A própria documentação do Selenium alerta contra misturar waits implícitos e explícitos porque os timeouts resultantes podem ficar imprevisíveis muito rápido. Se o seu script com Selenium está instável, normalmente é por isso.
Scrapy vs. Selenium: desempenho sem números universais inventados
Um benchmark confiável precisa informar as páginas-alvo, o estado do cache, as condições de rede, a concorrência, a estratégia de reutilização do navegador, as condições de espera e o código completo. Sem esse contexto, um número de páginas por minuto é marketing, não evidência. Ainda assim, a comparação arquitetural é útil:
| Característica da carga de trabalho | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML renderizado no servidor | Caminho HTTP direto | Caminho completo via navegador | Usa o caminho direto do Scrapy |
| Conteúdo renderizado em JavaScript | Exige um renderizador adicional | Execução nativa no navegador | Renderização seletiva no navegador |
| Modelo de concorrência | Agendador assíncrono de requisições | Sessões de navegador gerenciadas pelo seu código ou Grid | Agendador do Scrapy + contextos de navegador |
| Perfil de recursos | Sem sobrecarga de renderização do navegador | Sobrecarga de CPU e memória do navegador | Custo de navegador só para requisições marcadas |
| Melhor métrica | Itens por minuto com taxa de erro segura | Fluxos concluídos por minuto com taxa de erro segura | Throughput separado para requisições estáticas e renderizadas |
A configuração padrão de requisições concorrentes do Scrapy é um teto, não uma promessa de throughput. A velocidade real é governada por latência, limites por domínio, throttling, retries, tamanho das respostas, trabalho de parsing e taxa de requisições aceitável do alvo. O Selenium pode reutilizar uma sessão de navegador, então ele não fica preso, por definição, a abrir um navegador novo por página — mas cada sessão ativa ainda executa e renderiza um ambiente completo de navegador.
O modelo híbrido chama atenção porque mantém as requisições comuns no caminho HTTP do Scrapy e manda só as páginas que precisam de renderização para um navegador. Isso normalmente reduz o peso do navegador, mas não quer dizer que seja automaticamente mais rápido: meça separadamente os caminhos estático e renderizado, inclua taxas de falha e retry e ajuste a concorrência com base tanto na segurança para o site-alvo quanto na memória disponível.
Diferenças centrais que influenciam sua decisão
Velocidade não é a única variável. Alguns fatores práticos pesam quase tanto quanto quando o assunto é produção.
Renderização de JavaScript e conteúdo dinâmico
O Scrapy sozinho é cego para qualquer coisa renderizada no cliente. O Selenium vê tudo porque é um navegador real. O meio-termo — Scrapy-Splash (mais antigo, com scripts em Lua) e scrapy-playwright (mais moderno, recomendado) — permite renderizar JS de forma seletiva dentro do fluxo de crawl do Scrapy, em vez de dedicar um navegador completo para cada requisição. Se 80–90% das suas páginas-alvo são HTML estático e só algumas precisam de JS, a renderização seletiva é a arquitetura mais óbvia. Renderizar tudo em navegador porque algumas páginas precisam disso é desperdício de processamento.
Escalabilidade e concorrência
Escalar o Scrapy de 1.000 para 1.000.000 de páginas é, em grande parte, uma conversa sobre provisionamento — adicionar mais requisições concorrentes, talvez distribuir entre workers com Redis. Escalar o Selenium significa adicionar instâncias de navegador de forma linear, o que também quer dizer aumentar RAM e CPU na mesma proporção. Em outras palavras: você passa a administrar uma fazenda de navegadores com Selenium Grid e ainda lidar com recuperação de falhas. Não é que o Selenium não escale — é que escalar o Selenium é um projeto de infraestrutura, não uma simples mudança de configuração.
Pipelines de dados e exportação
O item pipeline do Scrapy cuida de validação, deduplicação e exportação para JSON, CSV ou banco de dados como recurso nativo. O Selenium não traz nada disso — você precisa escrever sua própria lógica de serialização e armazenamento do zero. Se qualidade dos dados e integração posterior importam para você (e deveriam importar), isso é uma vantagem real que o Scrapy entrega de graça.
Manutenção e confiabilidade de longo prazo
Um padrão que eu venho observando: spiders em Scrapy tendem a envelhecer relativamente bem porque a arquitetura baseada em middleware impõe alguma estrutura. Scripts em Selenium ficam frágeis — atualizações do navegador quebram drivers, problemas de timing geram execuções instáveis e qualquer mudança no DOM exige ajustar seletores. Já vi desenvolvedores em fóruns dizerem sem rodeios que um scraper baseado em Selenium “parece não ser a melhor escolha para algo que vamos vender para um cliente”, e, sinceramente, esse instinto está certo se o projeto precisa sobreviver por mais de alguns meses sem mexidas.
Verificação da realidade anti-bot: como cada ferramenta se sai contra as defesas de 2026
Esta é a parte que quase toda comparação deixa de lado — e é justamente a que determina se o seu scraper funciona ou não. Nem Scrapy nem Selenium foram criados pensando na infraestrutura anti-bot moderna, e fingir o contrário só prepara você para uma surpresa ruim em produção.
| Camada de defesa | Scrapy | Selenium | Scrapy-Playwright | API Thunderbit |
|---|---|---|---|---|
| Renderização de JS | ❌ Precisa de middleware | ✅ | ✅ | ✅ Integrado |
| Fingerprint TLS | ⚠️ Detectável | ⚠️ Detectável | ⚠️ Melhor, mas não resolve | ✅ Tratado |
| Resolução de CAPTCHA | ❌ Manual | ❌ Manual | ❌ Manual | ✅ Integrado |
| Rotação de rate limit | ⚠️ Proxies por conta própria | ⚠️ Proxies por conta própria | ⚠️ Proxies por conta própria | ✅ Gerenciado |
O Scrapy falha diretamente nas verificações de fingerprint de navegador porque, na prática, não há navegador para fingerprintar — ele é só um cliente HTTP, e muitos fornecedores anti-bot sinalizam tráfego que não parece vir de um navegador real. O Selenium passa nos checks básicos de JS porque é um navegador real, mas ainda pode ser detectado por sinais como navigator.webdriver, uma flag padronizada que fica verdadeira sob automação. Patches como undetected-chromedriver tentam mascarar isso, mas é uma guerra de gato e rato contra fornecedores de detecção que atualizam suas assinaturas com frequência.
A corrida da furtividade (e por que o DIY é frágil)
A verdade incômoda sobre patches de anti-detecção é esta: eles são uma esteira de manutenção, não uma solução. undetected-chromedriver e playwright-stealth funcionam até o Cloudflare Turnstile ou o DataDome lançar uma atualização que pegue a técnica usada. Aí você precisa corrigir tudo de novo. Já vi equipes gastarem mais tempo de engenharia para manter a camada furtiva viva do que gastaram construindo o scraper em si.
Rate limiting também merece atenção própria. Quando um servidor retorna 429 Too Many Requests, o cabeçalho Retry-After é uma sugestão, não uma ordem — muitos sites nem o enviam, e alguns limitam você por outros sinais completamente diferentes. O AutoThrottle do Scrapy ajuda ajustando o delay com base na latência observada, mas ele é reativo, não preventivo.
É aqui que uma API de extração gerenciada começa a compensar — o tratamento anti-bot deixa de ser seu problema de engenharia e passa a ser de outra equipe. Mais sobre isso adiante.
O fator Playwright: por que “Scrapy vs. Selenium” já não conta a história toda
Tratar isso como uma disputa entre duas ferramentas ignora o que realmente aconteceu na comunidade de scraping nos últimos anos. Fóruns de desenvolvedores estão cheios de variações da frase “mudei do Selenium para o Playwright e fiquei bem satisfeito” — e, ainda assim, a maioria dos artigos de comparação menciona o Playwright só de passagem, se mencionar.
O Playwright, criado pela Microsoft, controla Chromium, Firefox e WebKit por meio de uma única API. Seu modelo de actionability espera que os elementos estejam visíveis, estáveis e realmente interativos antes de executar uma ação — o que reduz bastante a instabilidade de timing que afeta muitos scripts em Selenium. Ele também lida com browser contexts de forma mais eficiente, permitindo criar sessões isoladas sem o peso de iniciar um navegador totalmente novo a cada vez.
Quando o Playwright substitui o Selenium por completo
Para scraping especificamente — não testes de navegador com infraestrutura Selenium já existente — o Playwright costuma ser simplesmente a melhor ferramenta em 2026. Criação de contextos mais rápida, menor consumo de recursos por página, suporte assíncrono nativo e interceptação de rede embutida. Se você está começando um projeto de scraping do zero, sem uma suíte de testes em Selenium para preservar, não há muito motivo para escolher Selenium primeiro.
A exceção: se sua equipe já tem uma infraestrutura de testes com Selenium, ou se você precisa de uma personalização de perfil de navegador muito específica que o Playwright não suporta com a mesma elegância, o Selenium ainda faz sentido.
Como o scrapy-playwright funciona
O scrapy-playwright é um download handler para Scrapy que encaminha apenas as requisições marcadas com meta={"playwright": True} por um navegador real — todo o resto continua no caminho HTTP rápido e assíncrono do Scrapy. Aqui está um spider simplificado que faz crawl de um catálogo paginado em que os cards de produto são renderizados via JS no cliente:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Só as páginas que realmente precisam de renderização passam pelo navegador. Essa é a essência da abordagem híbrida — você não paga o custo do navegador em cada requisição, só nas que exigem isso.
Scrapy-Splash vs. Scrapy-Playwright: qual middleware usar
O Scrapy-Splash exige subir um serviço Splash em Docker separado e escrever scripts em Lua para interações — funciona, mas é uma configuração mais pesada e antiga. O scrapy-playwright se integra diretamente ao loop de eventos assíncrono do Scrapy, suporta os três principais motores de navegador e lida com interações complexas sem exigir uma segunda linguagem de script acoplada. Se você está começando um projeto novo em 2026, realmente não há motivo para recorrer ao Splash.
Arquitetura híbrida pronta para produção
A maioria dos artigos diz “você pode combinar Scrapy e Selenium” e para por aí. Isso não é arquitetura. É só uma sugestão. Veja como uma configuração real de produção se parece.
O fluxo: um agendador do Scrapy encaminha requisições por um roteador de URLs que verifica se a página é estática ou dinâmica. As requisições estáticas seguem direto pelo downloader padrão do Scrapy. As dinâmicas são marcadas e enviadas ao middleware do Playwright, que gerencia um pool de contextos de navegador. Os dois caminhos convergem de volta para o mesmo item pipeline para validação, deduplicação e exportação — seja de HTML bruto ou de um DOM renderizado, tudo termina no mesmo output JSON, CSV ou banco de dados.
Algumas observações de implantação se você for levar isso para produção: containerize com Docker para que os binários do Playwright sejam entregues de forma consistente entre ambientes, limite os contextos concorrentes do Playwright com base na RAM disponível (eu não passaria de 8 a 10 contextos em uma máquina padrão de 4 GB) e execute jobs agendados via cron ou por um pipeline de CI/CD, em vez de deixar um processo rodando indefinidamente.
Essa estrutura dá o máximo de controle. Mas também quer dizer que agora você é responsável por atualizações de binários do navegador, bugs no ciclo de vida de contextos (páginas não fechadas travam o crawl), rotação de proxies e qualquer patch anti-bot que precise acoplar. Isso é um compromisso real de engenharia, e vale ser honesto sobre isso antes de assumir essa responsabilidade.
Para equipes que querem a saída estruturada sem assumir essa infraestrutura, a CLI do Thunderbit enfrenta o mesmo problema por outro ângulo:
thunderbit batch extract --schema schema.json --file urls.txt
Mesmo output JSON estruturado. Sem código de spider, sem pool de navegadores, sem infraestrutura anti-bot para manter. Você troca parte da personalização por velocidade de ida para produção — é um trade-off legítimo, não uma melhoria universal, e depende totalmente de quanto controle o seu projeto realmente precisa.
O caminho de “pular o framework”: quando uma API de scraping com IA supera os dois
Em algum momento, um desenvolvedor percebe que, na verdade, não precisa de um framework de crawling. Precisa de dados estruturados de 500 URLs conhecidas, e montar um spider, um pool de navegadores e uma camada anti-bot para isso soa exagerado — porque normalmente é mesmo.
Essa é a lacuna que a Thunderbit foi criada para preencher, e digo logo de início: ela não substitui o Scrapy em um crawl complexo, recursivo e com lógica customizada. É outra ferramenta para um problema diferente e mais estreito.
API aberta: o POST /extract recebe um JSON Schema e devolve dados estruturados compatíveis com ele — não HTML bruto, nem um monte de Markdown que você precisa interpretar por conta própria. O POST /distill faz a operação inversa, retornando Markdown limpo pronto para alimentar um pipeline de RAG ou um LLM. O serviço gerenciado oferece suporte a renderização de JavaScript e tratamento anti-bot, então você não precisa manter essa infraestrutura internamente. O guia atual de Distill vs. Extract informa 1 crédito por página no Distill e 20 por página no Extract; confira a documentação ao vivo antes de orçar, porque os termos do produto podem mudar.
Servidor MCP: para agentes de IA como Claude ou Cursor, o servidor MCP da Thunderbit expõe distillation, extração estruturada, sugestão de campos e jobs em lote como ferramentas, permitindo que o agente busque dados frescos da web no meio da tarefa sem sair do seu ambiente.
CLI: a CLI da Thunderbit documentada oferece comandos como thunderbit extract <url> --schema schema.json e se encaixa bem em fluxos de terminal e jobs agendados. Você pode encaminhar o Markdown distillado para outra ferramenta em tarefas rápidas e pontuais de pesquisa.
Se preferir pular o código por completo, a extensão Chrome da Thunderbit cobre a mesma necessidade com uma interface de apontar e clicar — algo especialmente útil se sua equipe inclui pessoas não técnicas que precisam de dados sem mexer em terminal. Escrevi mais sobre o cenário geral de web scraping com IA e web scraping sem código se você quiser uma visão mais completa.
Seja honesto consigo mesmo sobre em qual grupo você está: o Scrapy ainda é a melhor escolha para crawls complexos entre vários sites, com lógica customizada e seguimento recursivo de links. Selenium ou Playwright para fluxos com muita interação. Mas “preciso de dados estruturados dessas URLs conhecidas” é um problema mais específico do que qualquer uma dessas ferramentas foi feita para resolver, e uma API realmente pode eliminar o código do spider, a infraestrutura anti-bot e a manutenção contínua que vem junto quando você assume tudo isso sozinho.
Scrapy vs. Selenium vs. Playwright vs. API de IA: comparação lado a lado
| Recurso | Scrapy | Selenium | Scrapy-Playwright | API Thunderbit |
|---|---|---|---|---|
| Suporte a linguagem | Apenas Python | Python, Java, C#, JS, Ruby | Python | REST (qualquer linguagem) |
| Renderização de JS | Não (precisa de middleware) | Sim | Sim | Sim, nativa |
| Async/concorrência | Nativo, alto | Limitado por instância | Nativo via Scrapy | Gerenciado no servidor |
| Tratamento anti-bot | Faça você mesmo | Faça você mesmo | Parcial | Integrado |
| Pipeline/exportação de dados | Integrado | Faça você mesmo | Integrado | JSON estruturado na saída |
| Complexidade de setup | Moderada | Baixa para começar, alta em escala | Moderada a alta | Mínima |
| Carga de manutenção | Baixa a moderada | Alta | Moderada | Quase zero |
| Melhor para | Crawls estáticos em alto volume | Fluxos com muita interação | Sites mistos, estáticos e dinâmicos | URLs conhecidas, saída estruturada |
Se você estiver avaliando outras opções de scraper além dessas quatro, também vale dar uma olhada em como as alternativas ao Instant Data Scraper e os melhores scrapers web com IA se comparam — o mercado ficou lotado, e nem toda ferramenta resolve o mesmo problema.
Observações legais e éticas sobre web scraping em 2026
Vou ser breve porque esse não é o foco principal, mas isso importa. A configuração ROBOTSTXT_OBEY do Scrapy faz o spider respeitar as regras do robots.txt — é uma boa prática, embora valha lembrar que o próprio Robots Exclusion Protocol diz explicitamente que essas regras não constituem autorização legal de acesso. Selenium e Playwright não têm qualquer conformidade com robots.txt embutida — isso fica totalmente por sua conta implementar. Independentemente da ferramenta, verifique os termos de serviço do site e a legislação aplicável na sua jurisdição antes de raspar e reutilizar dados; “está público” não significa automaticamente sinal verde legal em todo lugar.
Escolhendo a ferramenta certa para seu projeto de scraping em 2026
A decisão realmente se resume a quatro perguntas: qual é o tipo de conteúdo, qual é a escala, quanta interação você precisa e quanto de manutenção contínua você está disposto a assumir. Páginas estáticas em escala real, vá de Scrapy. Páginas pesadas em JS com interação real, vá de Selenium ou Playwright. Uma mistura dos dois, monte o híbrido. URLs conhecidas em que você só precisa de dados estruturados com pouca manutenção, uma API como a da Thunderbit provavelmente economiza mais tempo do que custa.
“Scrapy vs. Selenium” nunca foi, de fato, a pergunta completa — era só a única forma de enquadrar o problema disponível na época. O Playwright mudou o meio do caminho, e as APIs de extração com IA abriram uma trilha totalmente nova para quem percebeu que estava montando infraestrutura em vez de resolver um problema de negócio. Vale testar o plano gratuito antes de se comprometer com qualquer abordagem — o suggest-fields é grátis e o distill consome um único crédito, então você consegue validar se o caminho por API faz sentido antes de escrever uma linha de código de spider.
FAQs
O Scrapy é mais rápido que o Selenium para web scraping? Nos meus testes, sim — muitas vezes por uma ordem de grandeza em páginas estáticas, já que a arquitetura assíncrona do Scrapy elimina totalmente a sobrecarga do navegador. Essa diferença diminui quando o Scrapy usa middleware do Playwright para páginas pesadas em JS, mas o Scrapy ainda vence no throughput geral em cargas mistas porque as páginas sem JS continuam no caminho rápido.
O Scrapy consegue lidar com páginas renderizadas em JavaScript?
Não sozinho — o Scrapy vê apenas o HTML inicial. Adicionar scrapy-playwright ou o mais antigo Scrapy-Splash como middleware permite renderizar seletivamente requisições específicas por meio de um navegador real, mantendo o restante do crawl no caminho nativo e mais rápido do Scrapy.
Quando devo usar Selenium em vez de Scrapy? Quando você precisa de interação completa com o navegador — logins em várias etapas, clicar em assistentes, preencher formulários — e o volume de páginas é moderado, não massivo. Também é a escolha sensata se você já tem uma infraestrutura de testes baseada em Selenium que queira reaproveitar para scraping.
O Playwright é melhor que o Selenium para scraping em 2026? Para scraping especificamente, geralmente sim — o Playwright tende a oferecer melhor desempenho, auto-wait embutido e menor consumo de recursos por contexto de navegador. O Selenium ainda mantém vantagem para equipes que já operam suítes consolidadas de testes cross-browser que o Playwright não foi feito para substituir.
O que é uma API de scraping com IA e quando ela substitui Scrapy ou Selenium? Uma API de scraping com IA, como a Open API da Thunderbit, trata renderização de JS, defesas anti-bot e extração de dados no servidor, devolvendo JSON estruturado que corresponde a um esquema que você define. É a escolha certa quando você tem URLs conhecidas e precisa de saída estruturada sem construir ou manter a infraestrutura de crawl — mas não substitui o Scrapy em crawls complexos, recursivos e com lógica customizada.
Saiba mais
