20 por cento de todas as respostas web ‘OK’ recebidas pela IA não estão OK

Meus experimentos recentes com raspagem da web assistida por IA me fizeram perceber a dimensão crescente do bloqueio da web. O motivo dessa retração, é claro, é o crescimento impressionante da raspagem da web por IA, cuja demanda incessante por novos dados pode acabar tirando domínios do ar.

Isso é um bom motivo para que os domínios façam o que muitos deles desejam há muito tempo: permitir o acesso ao conteúdo apenas quando o usuário tiver iniciado sessão (embora, naturalmente, o Googlebot geralmente tenha acesso livre). O Facebook concluiu a adoção gradual dessa política em 2023, e o Twitter/X fez o mesmo naquele mesmo ano. O Reddit adotará a medida mais tarde neste mês.

Assim, fica um pouco mais fácil para o domínio cumprir as exigências específicas de cada país relativas à aplicação de restrições etárias, já que o usuário está registrado. Mais importante ainda, os dados do usuário podem ser armazenados, explorados para análises locais e — se a legislação local permitir — vendidos a corretores de dados e empresas de IA.

Em outros lugares, as medidas voltadas especificamente à defesa contra bots (em vez de ao cadastro de usuários) aumentaram mais de 58% em relação ao ano anterior, segundo a Cloudflare; e toda essa atividade crescente de bots naturalmente incentiva os sites a examinar com atenção os endereços de VPN e proxy, podendo impedir o acesso de usuários legítimos, junto com o de todo o tráfego ‘malicioso’.

O aspecto anedótico disso é que parece que me deparo cada vez mais com respostas de ‘bloqueio’ ou desafios, a ponto de talvez até abandonar um site que comece a carregá-los; e, como já se constatou que as paredes de CAPTCHA afastam usuários e possíveis clientes, é possível imaginar a pressão que leva os proprietários de domínios a adotá-las, apesar dessa desvantagem.

Um CAPTCHA do archive.is, um dos muitos sites que adotaram desafios, muitas vezes em resposta a um volume excessivo de solicitações automatizadas (e não humanas).

Todo esse atrito novo e crescente é, em parte, uma questão logística (porque nem todos os domínios conseguem resistir à enxurrada), mas também costuma ser uma tática de negociação para descobrir se as empresas de IA oferecerão uma forma de remuneração individual ou coletiva por todos os dados que tanto desejam e que foram gratuitos por tanto tempo, até agora.

Como os rastreadores de IA precisam operar em grande escala, costumam usar instâncias ‘headless’ do Chrome com a estrutura Playwright. Hoje em dia, em um número cada vez maior de domínios, isso resulta em um erro 403 (‘proibido’) (ou seja, o servidor sabe que você é tráfego automatizado e manda você cair fora):

Uma instalação local do changedetection.io tenta consultar um site, mas o site não aceita o navegador detectado que a estrutura usa e retorna uma resposta 403 (‘Proibido’).

O que se busca é a resposta do cliente ‘200’ (‘OK’), mesmo que seja preciso entregar uma pilha de dinheiro a uma rede de proxies residenciais, em conjunto com outros truques furtivos e variados que não envolvem pessoas, para obtê-la.

Não há nada melhor do que a resposta 200; em outras palavras, não existe código de resposta do cliente com um sinal positivo mais forte. Tampouco é uma resposta ambígua: nunca é ‘quase tudo certo’, ‘vai ficar tudo certo mais tarde’ nem ‘ficando cada vez mais certo’; é ‘tudo certo!’. Se não está tudo certo, não é uma resposta 200.

Olá! Vá embora

Mas, segundo um novo artigo, essa falta de granularidade pode distorcer significativamente os conjuntos de dados de IA, as estimativas estatísticas e a indicação de um status ‘bom’ quando não é esse o caso.

O estudo* estima que cerca de um quinto das respostas da categoria 200 não contém nenhum conteúdo útil da página, oferecendo, em vez disso, estruturas vazias de sites, desafios CAPTCHA, restrições de acesso ou páginas substitutas.

O artigo afirma:

‘20,9% das páginas que um cliente estático recebe com status 200 não contêm o conteúdo principal da página: estruturas de aplicativos, desafios contra bots, páginas de bloqueio, páginas de erro e de preenchimento, e conteúdo parcial.’

Nesse sentido, os sistemas automatizados impacientes tropeçam na própria superficialidade, pois a resposta ‘200’ pode ser equiparada a uma busca bem-sucedida, mesmo quando a busca resulta apenas em uma parede de CAPTCHA, um acesso pago ou algum outro obstáculo.

O artigo descreve os sete tipos de conteúdo que costumam complicar uma resposta 200:

As sete categorias de conteúdo que estão longe de ser ‘aceitáveis’ em uma resposta 200. Fonte

No estudo, ao longo de três dias, foram testados 10.307 endereços da web usando tanto um programa básico de coleta de páginas quanto um navegador capaz de carregar JavaScript. As respostas foram classificadas de acordo com o conteúdo obtido, e não com base nos códigos de status HTTP.

As maiores categorias de respostas 202 «inutilizáveis» foram páginas vazias com a estrutura básica de um site e páginas de erro ou substitutas, que, juntas, representaram mais de dois terços das falhas.

No caso das páginas vazias com a estrutura básica de um site, o site pode exibir os menus e a navegação, mas deixar em branco o artigo ou a lista de produtos solicitados; no segundo caso, uma página sem relação com o pedido ou a página inicial pode aparecer no lugar do conteúdo solicitado. Ainda assim, ambos os casos podem receber o mesmo status HTTP 200 que uma resposta bem-sucedida, com conteúdo útil e utilizável.

Como solução, o artigo recomenda que as ferramentas de coleta de páginas informem o que foi realmente obtido, em vez de se basearem nos códigos de status HTTP, pois verificações simples de páginas excepcionalmente curtas, redirecionamentos suspeitos e conteúdo semelhante ao de páginas inexistentes poderiam identificar a maioria das falhas.

Ferramentas de navegador que consomem mais recursos poderiam então ser usadas apenas quando uma página aparentasse não ter sido carregada corretamente. Além disso, as avaliações de IA poderiam verificar se as fontes citadas realmente contêm as informações esperadas, em vez de presumir que uma resposta HTTP 200 significa que o conteúdo foi obtido com sucesso.

O autor do novo estudo também observa que «heurísticas baratas» podem identificar facilmente cerca de 86% das respostas inutilizáveis, por meio de verificações básicas do tamanho das páginas, dos redirecionamentos e da semelhança com páginas inexistentes:

Comparação de estratégias de coleta de páginas: renderizar apenas as páginas sinalizadas como suspeitas recuperou um pouco mais de conteúdo utilizável (81,4%) do que renderizar todas as páginas (80,3%), reduzindo, ao mesmo tempo, o tempo médio de recuperação de 20,6 para 5,8 segundos por página. 

Por que tantas respostas 200 incorretas?

Ao longo dos anos, houve alguma discussão em comunidades de desenvolvedores sobre a possibilidade de o erro 202 («Aceito») («Solicitação aceita, mas ainda não concluída») ajudar a distinguir essas solicitações com status 200 que «falharam». Na prática, porém, o 202 não abrange todos os casos descritos no novo artigo, e não existe nenhum código que consiga fazê-lo.

Embora o artigo não trate da questão em profundidade, vale investigar mais a fundo, em trabalhos futuros relacionados, por que os proprietários de domínios permitem erros 200.

Uma das razões pode ser que qualquer resposta que não seja 200 consista essencialmente em algum tipo de página de erro ou impedimento, incluindo os erros mais comuns, 404 («não encontrado»), nos quais o conteúdo procurado simplesmente não está disponível. Alguns usuários acreditam que um excesso desses erros resultará em penalizações de SEO (e, presumivelmente, de GEO), embora o Google negue que isso aconteça.

Na verdade, o Google considera os erros 200 incorretos como erros 404 «suaves», que claramente tendem a ser tratados como um problema maior do que os erros 404 comuns, pois são, em essência, resultados «enganosos», intencionais ou não.

Deriva das citações

Se tudo isso parece preciosismo, é preciso considerar a escala de petabytes dos dados que são coletados rotineiramente (ou cuja coleta é tentada) para treinar sistemas de IA. Se um quinto desses dados for pouco confiável ou francamente enganoso, é difícil descartar as consequências posteriores como algum tipo de «imprecisão colateral». Essas respostas falsas podem, na verdade, afetar de forma significativa e negativa a distribuição dos conjuntos de dados e os resultados do treinamento de modelos de IA com esses dados.

Por exemplo, um problema notável relacionado às respostas 200 incorretas é a «deriva das citações», situação em que uma resposta gerada por IA deixa de ser respaldada pela página da web originalmente citada como evidência. Ou seja, a página pode ter mudado, o texto relevante pode ter sido removido ou o link pode agora levar a outro lugar.

O novo estudo constatou que a aparente deriva das citações aumentou de 5,8% para 21,9% quando todas as respostas HTTP 200 foram aceitas como recuperações bem-sucedidas, independentemente do conteúdo.

Isso significa que uma fonte pode ser julgada erroneamente como tendo mudado, desaparecido ou deixado de respaldar uma afirmação gerada por IA simplesmente porque, em vez do material original, foi obtido um CAPTCHA, uma página vazia ou outro tipo de impedimento.

Basta dizer que existe!

O problema também foi demonstrado por testes com endereços da web deliberadamente inexistentes. Quando caminhos aleatórios e inventados foram solicitados a sites, 13,1% dos que responderam retornaram o status 200 («OK»), embora as páginas solicitadas não existissem^†.

«13,1% dos sites que responderam ao teste com caminhos aleatórios retornaram o status 200 (S1: 10,5%; S2: 13,3%; S3: 17,3%; S4: 13,7%; S5: 13,1%). Por definição, todas essas respostas são erros 404 suaves, mas nem todas informam isso.»

‘Em uma análise exploratória das 172 respostas de soft 404, o avaliador classificou 98 como erro ou página substituta, 32 como estrutura vazia e 28 como conteúdo: uma página inicial ou listagem exibida em um caminho aleatório parece uma página normal.’

Conclusão

Se o problema fosse reconhecido em um nível mais alto, a IANA poderia, em tese, criar um novo código de status HTTP mais adequado, como [X] (‘A solicitação foi bem-sucedida, mas o conteúdo solicitado não foi entregue’). Embora isso descrevesse de fato o que está acontecendo, naturalmente exigiria um grau improvável de compreensão da transação por parte do host.

Já existem códigos semelhantes, embora nenhum se encaixe de verdade: 451 (‘Indisponível por motivos legais’) é ambíguo e bastante alarmante (!); 206 (‘Conteúdo parcial’) é tecnicamente adequado, mas destina-se a dados incompletos (buscas); e o código 203 (‘Informações não oficiais’), cuja existência surpreende, foi criado em 1997 e é apenas tangencial ao caso de uso em questão.

Talvez o candidato mais próximo seja, na verdade, o 103 (‘Dicas antecipadas’), cujo nome não é intuitivo e que indica que nem todos os recursos da URL foram carregados ainda (embora isso claramente representasse uma interpretação muito equivocada da intenção do código).

* Intitulado ‘Quando 200 OK não é uma resposta: falhas silenciosas de busca na aquisição agêntica de conteúdo da Web.’ Vale observar que o artigo aparentemente foi escrito sobretudo para ser legível por máquina, talvez para ser consultado por IA, e não é de leitura fácil.

^† Peço desculpas pela citação mecanicista, mas o artigo inteiro é escrito dessa maneira, como observo acima, para ser ‘legível por máquina’ em vez de interpretável por humanos, embora não chegue a ser apresentado em formato JSON.

Publicado originalmente na quarta-feira, 4 de novembro de 2026