A nossa posição, declarada: somos a Geonode e vendemos proxies, pelo que, por interesse comercial, estamos do lado dos rastreadores nesta questão. A verdade é que a maior parte da forma de contornar as armadilhas (honeypots) consiste simplesmente em rastrear corretamente, e a medida mais eficaz de todas é aquela que não custa nada: respeitar robots.txt. Uma grande parte das armadilhas é colocada em caminhos que o site já pediu aos rastreadores para não visitarem, pelo que um rastreador que cumpra as regras nunca as encontra. O restante é evitado através da renderização de CSS, não preenchendo formulários para os quais não foi convidado e limitando o seu rastreio. Nada disso requer a compra de nada da nossa parte, e um rastreador que precise de proxies para sobreviver a um honeypot é um rastreador que já cometeu um erro mais fundamental.
O que é uma armadilha «honeypot»
A definição é comportamental, e não técnica: trata-se de conteúdo com o qual apenas um cliente automatizado irá interagir, colocado ali para que essa interação identifique o cliente como automatizado.
A lógica é simples e bastante difícil de contestar. Um visitante humano utiliza um navegador, que aplica CSS, renderiza um layout e mostra-lhe o que está visível. Um rastreador que analisa HTML vê tudo na marcação da mesma forma — incluindo um link com estilo para ser invisível, um campo de formulário oculto fora do ecrã e um caminho para o qual ninguém cria um link a partir de qualquer local onde uma pessoa possa olhar.
A interação com qualquer um desses elementos constitui um sinal forte. Não é conclusivo, uma vez que as ferramentas de acessibilidade e os navegadores em modo de texto também se comportam de forma diferente, mas é suficientemente forte para que os sites tomem medidas em conformidade.
As consequências variam consoante o site. Alguns registam e ignoram. Outros limitam a frequência de acesso. Outros bloqueiam o endereço. Outros apresentam conteúdo simplificado indefinidamente, o que é o pior resultado, porque parece um sucesso. E alguns fazem agora algo mais elaborado, abordado mais adiante.
Os seis tipos que irá encontrar
1. Links invisíveis. Um link com o estilo display: none, visibility: hidden, dimensões nulas, uma cor que combina com o fundo ou posicionado fora do ecrã. Presente no HTML, mas ausente da página apresentada.
<a href="/trap/do-not-follow" style="display:none">Products</a>
<a href="/hidden" class="visually-hidden">Sitemap</a>
A forma mais comum e a mais fácil de evitar.
2. Caminhos não permitidos. URLs que aparecem apenas em robots.txt sob uma diretiva Disallow, sem qualquer ligação a partir de qualquer outro local. A única forma de encontrar um é ler o ficheiro de exclusão e, em seguida, ignorá-lo — o que torna um pedido para esse caminho um sinal quase perfeito de incumprimento deliberado.
3. Campos de formulário ocultos. Um campo ocultado com CSS que um utilizador humano nunca preenche. Qualquer envio que contenha um valor para esse campo provém de algo que analisa o HTML. É comum em formulários de comentários e processos de registo, onde constitui uma medida antispam legítima e eficaz.
4. Espaços infinitos de URL. Nem sempre deliberados, mas igualmente prejudiciais em qualquer dos casos. Um calendário com um link «próximo mês» gera URLs ilimitadas. A navegação facetada num catálogo extenso produz explosões combinatórias. Um rastreador sem limites de profundidade e de padrões seguirá estas URL até que algo o impeça.
5. Armadilhas de temporização. Conteúdo que só aparece após um atraso, ou formulários que rejeitam envios preenchidos mais rapidamente do que um ser humano conseguiria. Estas armadilhas apanham os clientes que agem instantaneamente, em vez dos clientes que analisam a marcação.
6. Conteúdo contaminado ou gerado. A categoria mais recente, e suficientemente substancial para merecer a sua própria secção.
«Tarpits» de IA e labirintos gerados
Um desenvolvimento verdadeiramente novo e a razão pela qual este tema mudou de forma nos últimos dois anos.
O AI Labyrinth da Cloudflare é o exemplo mais amplamente implementado. A Cloudflare descreve-o como «uma nova abordagem de mitigação que utiliza conteúdo gerado por IA para abrandar, confundir e esgotar os recursos dos rastreadores de IA».
O mecanismo: a IA do Workers gera páginas HTML diversificadas sobre temas variados, armazenadas no R2 para uma entrega rápida, e estas páginas-isca são ligadas a partir de páginas reais através de links ocultos que são «invisíveis para os visitantes humanos, mas acessíveis aos rastreadores de bots».
A explicação da Cloudflare sobre o motivo pelo qual isto funciona é a descrição mais perspicaz do princípio do honeypot que já foi escrita:
Nenhum ser humano real se aventuraria por quatro links de profundidade num labirinto de disparates gerados por IA.
Fundamentalmente, o conteúdo apresentado é «real e relacionado com factos científicos, mas não é relevante nem exclusivo do site que está a ser rastreado» — pelo que um rastreador não o consegue detetar verificando se o texto é coerente. É coerente. Apenas trata de outro assunto.
Está disponível em todos os planos da Cloudflare, incluindo o plano gratuito, e ativá-lo é uma simples opção na secção de gestão de bots, sem «nenhuma configuração adicional».
Ferramentas independentes funcionam com base no mesmo princípio. O Nepenthes gera um labirinto infinito de páginas sem links de saída. O Iocaine funciona como um proxy inverso e dá um passo adicional que vale a pena compreender: corrompe os URLs que serve, de modo que um rastreador que mais tarde regresse disfarçado de navegador ainda pode ser identificado pelo facto de a sua fila de pedidos conter apenas URLs que o tarpit alguma vez distribuiu. Trata-se de um marcador persistente, em vez de momentâneo.
Duas implicações para quem opera um rastreador.
A deteção com base na qualidade do conteúdo não funciona. As páginas são coerentes e factuais. O que as identifica é o facto de serem irrelevantes para o site, sem ligações a partir de qualquer local onde uma pessoa as possa encontrar e em número ilimitado.
Limitar o rastreio é agora essencial, e não apenas uma questão de organização. Um rastreador sem limites de profundidade, sem limites de número de páginas e sem deteção de duplicados pode desperdiçar dias de computação e gigabytes de largura de banda cobrada em conteúdo sem sentido gerado, sem receber qualquer erro em nenhum momento. Com um modelo de preços por gigabyte, isso traduz-se numa fatura real por nada.
Como evitá-las sem recorrer a artimanhas
Todas as medidas aqui referidas são algo que um rastreador bem concebido deveria fazer de qualquer forma.
Respeite o princípio «robots.txt» (Não fazer mal). Isto, por si só, evita uma grande parte das armadilhas, porque os caminhos não permitidos são aqueles que os sites indicam. Atualmente, trata-se de uma norma — RFC 9309 — com correspondência por especificidade em vez de por ordem, e abordámos a forma correta de a ler em como ler um ficheiro robots.txt.
Verifique a visibilidade calculada antes de seguir um link. Num navegador sem interface gráfica, isto é simples:
const links = await page.$$eval('a[href]', els =>
els.filter(el => {
const s = getComputedStyle(el);
const r = el.getBoundingClientRect();
return s.display !== 'none' && s.visibility !== 'hidden' &&
parseFloat(s.opacity) > 0 && r.width > 1 && r.height > 1;
}).map(el => el.href)
);
Repare que se utiliza getComputedStyle em vez de ler o atributo style incorporado — um link oculto por uma regra de folha de estilo não tem estilo incorporado para inspecionar.
Sem um navegador, aplique heurísticas: ignore links cujo estilo inline contenha display:none ou visibility:hidden, ignore texto de âncora vazio, ignore nomes de classe como hidden, visually-hidden e sr-only, e desconfie de links cujo atributo href não apareça em nenhum ponto do texto visível.
Limite o rastreio de forma absoluta. Uma profundidade máxima, um número máximo de páginas e um limite por domínio. Não como um plano de contingência — mas como um limite rígido. Esta é a única defesa contra espaços infinitos que funciona independentemente da forma como são gerados.
Deteta repetições. O hash de conteúdo identifica páginas geradas que diferem superficialmente. A análise de padrões de URL deteta caminhos que crescem sem limites. Se um diretório tiver produzido duzentas páginas e não mostrar sinais de que vai terminar, pare e analise a situação.
Não envie formulários para os quais não foi convidado. As armadilhas de campos ocultos só apanham clientes que preenchem todos os campos de entrada que encontram.
Limite a taxa e o ritmo. Um ritmo semelhante ao humano evita as armadilhas de temporização e reduz, ao mesmo tempo, todos os outros sinais.
Identifique-se. Um rastreador com um nome e um URL de contacto é aquele que um operador pode optar por permitir. Esta não é exatamente uma medida para evitar armadilhas, mas altera o que acontece depois de se tropeçar numa.
Detetar uma armadilha na prática
Sinais de que se meteu numa, por ordem aproximada da rapidez com que surgem.
O número de páginas não está a convergir. A fila continua a crescer em vez de diminuir, o que constitui o aviso mais precoce e o mais fácil de monitorizar.
O conteúdo é coerente, mas irrelevante. Páginas que se lêem bem, mas que nada têm a ver com o tema real do site. Esta é a marca distintiva do «Labirinto da IA».
Os URLs seguem um padrão gerado. Percursos longos, estruturas de segmentos invulgares e ausência de repetição de URLs que seria de esperar num site real.
Não há ligações de entrada provenientes de fontes credíveis. As páginas têm ligações entre si, mas não há ligações externas que apontem para elas.
Os tempos de resposta são suspeitamente uniformes. O conteúdo gerado é servido a partir de uma cache; as páginas reais variam.
A qualidade dos seus dados diminui sem que a sua taxa de erro se altere. O sinal mais claro numa fase avançada e a razão pela qual é importante que tudo devolva um código 200.
O controlo prático consiste numa asserção contínua, em vez de uma verificação manual: se a proporção entre novas URLs descobertas e páginas obtidas não estiver a diminuir ao longo de um rastreio, algo está a gerar URLs mais rapidamente do que consegue consumi-las, e nenhum rastreio de um site finito se comporta dessa forma.
Para proprietários de sites: como implementá-los
A outra perspetiva, resumidamente, uma vez que o mesmo princípio se aplica a ambos.
Os campos de formulário ocultos são a melhor opção. São fáceis de adicionar, eficazes contra o envio automatizado de formulários e não têm impacto nos utilizadores reais. Atribua ao campo um nome inofensivo, oculte-o com CSS numa folha de estilo em vez de o fazer inline e rejeite qualquer envio que o preencha.
Os links ocultos detetam os rastreadores que não fazem a renderização. São eficazes e vale a pena combiná-los com a regra «robots.txt» para que os rastreadores compatíveis não sejam detetados. Penalizar um rastreador que se comporta bem por causa de uma armadilha que não excluiu é um problema autoinfligido.
Os «tarpits» geridos são agora uma opção ativável. O da Cloudflare está disponível em todos os planos, incluindo o gratuito, e não requer configuração, o que o torna acessível a qualquer site.
A acessibilidade é a verdadeira limitação. Os leitores de ecrã e os navegadores de texto não aplicam estilos visuais da mesma forma que o navegador de um utilizador com visão. Uma armadilha que utilize «display: none» é geralmente segura porque a tecnologia de assistência a respeita; uma armadilha que utilize posicionamento fora do ecrã ou texto transparente pode ser anunciada a um utilizador de leitor de ecrã, que a segue e acaba por ser bloqueado. Se implementar estas armadilhas, teste-as com um leitor de ecrã.
E decida o que realmente pretende. Os motores de busca, os parceiros de comparação de preços, as ferramentas de acessibilidade, os serviços de monitorização e os agentes de IA enviam todos tráfego automatizado, e parte desse tráfego é o que pretende. Uma armadilha genérica capta todo esse tráfego. Excluir os rastreadores conhecidos como legítimos através do agente de utilizador e colocar armadilhas apenas nos percursos que robots.txt já proíbe é a configuração que capta o tráfego que não deseja e poupa o resto.
Quando é melhor parar do que adaptar
Esta é uma decisão que vale a pena deixar bem clara, uma vez que somos um fornecedor cujo produto consiste, precisamente, na habitual «adaptação».
Se um site implementou mecanismos de bloqueio, está a transmitir uma mensagem. Em conjunto com as restrições de robots.txt e os termos que proíbem o acesso automatizado, a mensagem não é ambígua, e continuar a tentar contornar esses mecanismos é uma escolha com consequências que vão além do âmbito técnico.
As alternativas são frequentemente melhores e quase sempre mais baratas:
Pergunte. Um e-mail a explicar quem é e o que precisa resolve isto com mais frequência do que as pessoas esperam, e um feed de parceiros elimina o problema por completo.
Verifique se existe uma API oficial. Muitos sites que utilizam proteções agressivas também publicam uma, precisamente para que os utilizadores legítimos tenham para onde recorrer.
Verifique se os dados existem noutro local. Conjuntos de dados públicos, arquivos, registos oficiais, fornecedores licenciados.
Reduza o que precisa. Grande parte da extração de dados recolhe muito mais do que o necessário. Um pedido mais restrito é mais fácil de satisfazer por meios legítimos.
E a questão prática: os «tarpits» são concebidos para lhe custar mais do que custam ao site. A Cloudflare gera as páginas uma vez e serve-as a partir do armazenamento; paga por gigabyte, por hora de computação e em tempo de engenharia. Essa assimetria é deliberada e não melhora com o esforço.
Perguntas frequentes
O que é uma armadilha «honeypot» na extração de dados da Web?
Conteúdo colocado numa página com o qual apenas um cliente automatizado irá interagir — um link invisível, um campo de formulário oculto ou um caminho ligado a partir de um local onde um ser humano nunca iria procurar. A interação com esse conteúdo identifica o cliente como um bot, e os sites respondem registando a atividade, limitando a frequência ou bloqueando o acesso.
Como posso evitar as armadilhas «honeypot»?
Respeite a regra «robots.txt», uma vez que muitas armadilhas se encontram em caminhos não permitidos. Verifique a visibilidade calculada antes de seguir links, em vez de analisar HTML bruto. Não preencha campos de formulário que não lhe tenham sido apresentados. E limite o seu rastreio com limites rígidos de profundidade e de número de páginas, o que constitui a única defesa contra espaços infinitos.
O que é um «tarpit» de IA?
Um sistema que apresenta aos rastreadores automatizados um labirinto interminável de páginas geradas para esgotar os seus recursos. O AI Labyrinth da Cloudflare gera conteúdo coerente e factual que é simplesmente irrelevante para o site, ligado de forma invisível a partir de páginas reais. Está disponível em todos os planos, incluindo o gratuito, através de um único botão.
Posso detetar um honeypot antes de cair nele?
Em parte. A renderização da página e a verificação dos estilos calculados permitem detetar links ocultos de forma fiável. Os labirintos gerados são mais difíceis de detetar, uma vez que o conteúdo é coerente — os sinais são uma fila que não para de crescer, conteúdo irrelevante para o site e padrões de URL que não se repetem. Limitar o rastreamento é a defesa que funciona em qualquer caso.
Os links ocultos prejudicam o SEO ou a acessibilidade?
O texto oculto tem sido historicamente tratado como manipulador pelos motores de busca, pelo que as armadilhas são normalmente acompanhadas por uma instrução «disallow» no ficheiro robots.txt. A acessibilidade é a maior preocupação: o atributo «display: none» é respeitado pela tecnologia de assistência, mas o texto fora do ecrã ou transparente pode ser anunciado a um utilizador de leitor de ecrã, que depois o seguirá.
O que acontece se o meu rastreador encontrar um honeypot?
Varia. Alguns sites registam o evento, outros limitam a frequência de acesso, outros bloqueiam o endereço e outros apresentam conteúdo de qualidade inferior indefinidamente — o que é o pior cenário, porque tudo devolve um código de estado 200 e os seus dados deterioram-se silenciosamente. Os «tarpits» funcionam de forma diferente: continuam a fornecer-lhe conteúdo, para sempre.
As armadilhas «honeypot» são legais?
Colocá-las no seu próprio site é totalmente legal — é você que decide o que fornecer. O que um site faz com a identificação resultante é regido pelos seus termos de utilização. Do ponto de vista do rastreador, ativar uma armadilha não é, por si só, ilegal; pode violar os termos de serviço, o que é uma questão contratual.
Como posso impedir que o meu rastreador desperdice dinheiro num tarpit?
Limites rígidos quanto à profundidade e ao número de páginas por domínio, hash de conteúdo para detetar páginas quase duplicadas e um alerta quando a proporção entre URLs recém-descobertas e páginas obtidas não diminuir. Sem isso, um rastreador com limite de tráfego pode passar dias e gastar gigabytes em páginas geradas, ao mesmo tempo que apresenta uma taxa de sucesso perfeita.
Conclusão
As armadilhas «honeypot» baseiam-se num pressuposto: que um rastreador veja a marcação, enquanto um utilizador humano vê a página renderizada. Tudo o resto é uma variação — um link invisível, um campo oculto, um caminho mencionado apenas em robots.txt ou um labirinto sem fim.
As defesas consistem em tudo o que um rastreador bem construído deve fazer de qualquer forma. Respeite o robots.txt, porque é aí que se encontram muitas armadilhas e o cumprimento das regras não custa nada. Verifique a visibilidade calculada em vez de analisar HTML bruto. Não toque nos formulários, a menos que lhe tenham sido apresentados. E limite o seu rastreio com limites rígidos, que é a única medida que o protege contra labirintos gerados cujo conteúdo é deliberadamente indistinguível da escrita real.
Essa última categoria alterou a economia. Um «tarpit» gerido cria as suas páginas uma vez e serve-as a partir da cache; um rastreador paga por gigabyte e por hora de computação, e recebe um código de estado 200 todas as vezes. A assimetria é o ponto-chave: está agora disponível para qualquer site com um simples clique, e não cede ao esforço.
O que faz com que valha a pena levar a sério esta opção pouco glamorosa. Um site que implementou armadilhas já lhe disse algo, e solicitar um feed, verificar se existe uma API ou encontrar os dados noutro local é, normalmente, mais rápido, mais barato e mais duradouro do que tentar superar alguém que já preparou tudo para que você perca.