O parser está funcionando. HTTP 200 estão fluindo sem parar, os proxies estão vivos, o captcha não aparece, e a fila de links está crescendo. Mas, após uma semana, descobre-se que metade dos preços coletados é fictícia, e gigabytes de tráfego foram desperdiçados em páginas que não existem no site real. Isso não é uma falha do parser nem um pool de IPs ruim. É um novo modo de proteção: o site não bloqueia você, o site alimenta você.
Em um ano e meio, a indústria de proteção contra bots silenciosamente mudou seu foco. O bloqueio é uma medida cara e visível: o scraper vê 403, conserta a impressão digital, muda de sub-rede e volta. É muito mais vantajoso não atrapalhar seu trabalho, mas tornar seu trabalho inútil. Abaixo estão três mecânicas que já estão funcionando em produção em milhões de sites, e um conjunto de verificações que os pegam do seu lado.
Primeira mecânica: tarpit em vez de bloqueio
O tarpit (tarpit, "poça de alcatrão") é um gerador de site infinito. O crawler recebe uma página HTML válida com dezenas de links, cada link leva a uma página gerada semelhante, e a fila de rastreamento nunca fica vazia.
O instrumento aberto mais conhecido é o Nepenthes. Suas configurações mostram bem a intenção: por padrão, o servidor mantém a resposta de 10 a 65 segundos, entrega um texto "de conversa de Markov", gerado a partir de um corpus, e faz isso de forma determinística — o mesmo URL sempre retorna o mesmo lixo, para que as páginas pareçam arquivos estáticos normais, e não uma armadilha. Os dados são entregues em pequenas porções, "alguns bytes", para queimar os timeouts do cliente. O autor apresenta uma medição de uma hora de operação: 1850 clientes diferentes, 10.015 solicitações e 56.020 segundos de latência total — cerca de quinze horas de tempo de máquina de terceiros desperdiçado.
Iocaine é estruturado de forma diferente: ele funciona como um proxy reverso diante do site real, e na primeira interceptação entrega ao bot um link "envenenado" único e o reconhece ao retornar, enquanto o texto é gerado por cadeias de Markov — a expectativa é que esse texto entre no conjunto de treinamento.
Na Cloudflare, a mesma abordagem se tornou um produto — AI Labyrinth, apresentado em março de 2025. As páginas iscas não são geradas em tempo real: um pipeline de pré-geração é usado em Workers AI, o resultado é armazenado no R2 e distribuído rapidamente. Links para o labirinto são embutidos em páginas normais através de transformação HTML, e nas próprias iscas estão diretrizes meta contra indexação, para que a entrega não seja afetada. O principal aqui não é o tempo desperdiçado do bot, mas o sinal: os links, ocultos do humano e marcados com nofollow, são percorridos apenas por automações, e a navegação por três níveis dentro de tal labirinto se torna, por si só, uma impressão de um bot ruim. A escala do problema, para o qual isso foi feito, a Cloudflare estima em mais de 50 bilhões de solicitações de crawlers de IA por dia — pouco menos de 1% de todo o tráfego da rede.
Como o tarpit aparece em seus logs
Uma imagem característica: uma fila de milhares de URLs, que só cresce, o tempo de resposta se mantém consistentemente em torno de um segundo e meio ou mais, os códigos HTTP são todos 200, e o número de registros úteis extraídos é zero. Nenhum 403, nenhum captcha, e nenhuma saída: não importa quantas páginas foram percorridas, novos links aparecem mais rápido do que os antigos são fechados.
Segunda mecânica: conteúdo envenenado para agentes de IA
Se a primeira mecânica consome recursos, a segunda atinge os resultados. Pesquisadores Minghao Luo e Liang Chen publicaram em junho de 2026 um trabalho com o simulador FORGE (Fake Online Recommendations in Generative Environments): eles testaram 12 grandes modelos de linguagem em 225 produtos em 15 categorias — de roupas a eletrônicos. A mecânica do ataque é simples: no texto da página, a marca real é substituída por uma fictícia.
O resultado — uma página falsificada resulta em até 27% dos casos em que o assistente recomenda uma marca inexistente, e a substituição de todos os três primeiros resultados de busca eleva essa proporção para 73,8%. Os modelos não apenas repetiam o nome falso — eles inventavam qualidades para ele, incluindo suposta popularidade em comunidades. As três defesas propostas (prompt para ceticismo, consenso sobre conhecimentos internos do modelo, verificação entre documentos) ou não funcionaram, ou criaram novos problemas. A conclusão dos autores: as verificações devem ser feitas mais acima na corrente — na fase de coleta, e não na fase de raciocínio.
A terceira mecânica fecha o quadro. No trabalho "A Whole New World: Creating a Parallel-Poisoned Web Only AI-Agents Can See" (Shaked Zychlinski) é descrito o cloaking, direcionado especificamente a agentes de IA: o site reconhece o agente por atributos do navegador, assinaturas do framework de automação e características de rede e entrega a ele uma versão diferente da página — com instruções ocultas e fatos alterados. Um humano que abre o mesmo URL vê uma página normal, portanto, uma verificação manual "eu entrei, tudo está bem" não prova nada.
Por que isso é, em primeiro lugar, uma questão de orçamento
O tarpit é projetado para que cada página seja barata para o site e cara para você. Quando o tráfego é pago por gigabytes, o gerador de páginas infinitas se torna um contador de suas despesas: você paga por megabytes de texto de Markov que nunca se tornará uma linha no banco de dados. A aritmética é exatamente a mesma que com solicitações malsucedidas — o preço por gigabyte não diz nada sobre o custo do resultado, até que você comece a contar o custo de um registro bem-sucedido, e não de uma solicitação.
Daqui vem a primeira regra prática: o limite de tráfego deve ser definido no nível do domínio e da tarefa, e não apenas no nível da conta. Um domínio que consumiu mais de um gigabyte e não entregou nenhum registro deve ser interrompido automaticamente — sem isso, uma única armadilha pode consumir o orçamento diário durante a noite.
Sete verificações que pegam lixo
- Conte o yield, não os códigos de resposta. A principal métrica da linha de produção é a proporção de solicitações que resultaram em um registro válido com campos obrigatórios preenchidos. Enquanto você estiver olhando para a proporção de 200s, o tarpit parecerá uma fonte perfeitamente saudável.
- URL canário. A cada N solicitações, solicite um endereço que você sabe que não existe dentro do domínio — com um segmento de caminho aleatório. Um site normal responderá com 404 ou redirecionamento, o gerador entregará uma página completa com texto e links. Esta é a verificação mais barata e confiável.
- Cross-validação de outro perfil de IP. Pegue o mesmo URL por dois caminhos diferentes — por exemplo, através de IP residencial e através de móvel — e compare o hash dos campos-chave: preços, nomes, disponibilidade. Divergências com o mesmo URL e tempos de solicitação próximos significam que você está vendo diferentes versões da página, e pelo menos uma delas não é destinada a humanos.
- Não clique em links invisíveis. Links com nofollow, tamanhos zero,
display:noneou que estão fora da tela — isso é isca, e clicar neles é a própria impressão do bot. Filtre-os na fase de extração de links, e não depois. - Limites rígidos na resposta. Limite não apenas o timeout, mas também o tamanho máximo do corpo e a profundidade máxima de rastreamento a partir do ponto de entrada. Respostas lentas em pequenos pedaços são um sinal típico de uma armadilha, e não de um servidor lento.
- Procure por padrões no texto. A geração de Markov se revela através de estatísticas: comprimento de parágrafos estranhamente uniforme, n-gramas repetidos entre páginas "diferentes", dezenas de links de saída na ausência de elementos estruturais como preço, artigo ou data. Uma simples verificação de shingles repetidos entre páginas adjacentes do domínio elimina essas fontes em massa.
- Verifique os números com senso comum. Preço fora do intervalo histórico, produto sem uma única correspondência em seu próprio banco de marcas, um salto repentino na variedade — essas são regras de validação que devem ser aplicadas antes de gravar no banco, e não em um relatório um mês depois. Especialmente se os dados depois forem usados em um modelo ou em uma decisão automática de compra.
O que fazer com o conjunto de dados já coletado
Se a suspeita surgiu retrospectivamente, classifique não por datas, mas por fontes. Agrupe os registros por domínio e observe três valores: a proporção de páginas sem campos obrigatórios, o número médio de links de saída na página e a variação no comprimento do texto. Domínios armadilha geralmente se destacam imediatamente em todas as três. Em seguida, verifique novamente URLs controversos de outro perfil de IP — se os dados não coincidirem, todo o conjunto desse domínio precisa ser reconstruído, e não corrigido com filtros.
Vale a pena revisar separadamente as regras para cenários de agentes, onde o modelo navega pelas páginas e toma decisões por conta própria. É exatamente lá que a substituição de uma página tem o maior efeito, e não há um intermediário que notaria a estranheza na cadeia. O mínimo de segurança — exigir confirmação do fato de duas fontes independentes e não permitir que o agente atue com dados obtidos de um único domínio.
Resumindo
Os bots há muito superaram os humanos em participação de tráfego, e a proteção respondeu não apenas com filtros: hoje é mais barato alimentar um automático com lixo plausível do que discutir com ele por meio de bloqueios. Há três consequências práticas. Conte os registros úteis, não os status das respostas. Mantenha verificações canárias e limites de tráfego para cada domínio. Compare páginas controversas de diferentes perfis de IP — a divergência entre versões da mesma página é a prova de que você está vendo uma internet separada, preparada especialmente para bots. Proxies nesta configuração resolvem apenas uma tarefa — fornecem uma segunda visão independente da página; todo o resto é feito pela validação do seu lado.