Quando a IA Não Te Consegue Ver: Um Caso Real de Falha de Acesso LLM

Um site totalmente público. Sem autenticação. 200 OK em todos os testes. User-agent ClaudeBot aceite. E ainda assim: o Claude.ai devolveu "WebFetch blocked." Este é um caso documentado, executado neste domínio, e revela algo importante sobre como a visibilidade em IA funciona realmente — e como pode ser mal diagnosticada.

O que aconteceu

Durante testes de validação AEO em aeostudio.io, o Claude.ai falhou ao recuperar conteúdo do site. O erro era inequívoco: "WebFetch blocked." O site era publicamente acessível, sem login, sem filtragem CDN, sem restrições de user-agent. A falha parecia um bloqueio server-side. Não era.

Um processo de eliminação sistemática confirmou o seguinte:

• Acesso por browser: sucesso, página carregada completamente
• Pedido HTTP com user-agent padrão (Mozilla/5.0): 200 OK, HTML completo devolvido
• Pedido HTTP com user-agent ClaudeBot: 200 OK, HTML completo devolvido
• Vercel firewall: Bot Protection inactivo, zero regras personalizadas
• Cloudflare: modo DNS-only, sem proxy, sem WAF activo
• robots.txt: Allow explícito para todos os principais crawlers de IA incluindo ClaudeBot e anthropic-ai

Nada no servidor estava a bloquear o pedido. A falha estava noutro lugar.

Onde a falha realmente vivia

O suporte da Anthropic confirmou o diagnóstico:

"O problema é provavelmente o nosso filtro interno e não o teu servidor a bloquear-nos."

O domínio estava a ser bloqueado dentro da camada WebFetch do Claude.ai por uma regra de filtragem interna — provavelmente automatizada, provavelmente um falso positivo na categorização do domínio. Não um bloqueio de crawling. Não um bloqueio de indexação. Um bloqueio de camada de retrieval específico à ferramenta WebFetch interactiva do Claude.ai.

Essa distinção importa mais do que parece.

O que este caso prova e não prova

É tentador ler "WebFetch blocked" como uma falha total de visibilidade em IA. Não é.

O que está provado: o WebFetch interactivo do Claude.ai não conseguia aceder ao domínio. A filtragem interna da Anthropic era a causa.

O que não está provado: se o ClaudeBot estava activamente a fazer crawl do domínio. Se o domínio estava indexado internamente. Se o domínio era elegível para citation nas respostas geradas. Se o mesmo bloqueio se aplicava a outros sistemas da Anthropic para além do WebFetch interactivo.

A ferramenta WebFetch no Claude.ai é uma superfície entre muitas. Uma falha aí não se propaga automaticamente para crawling, indexação ou geração de respostas. Tratá-la como uma falha total de visibilidade levaria ao diagnóstico errado — e à correcção errada.

O que revela sobre a arquitectura LLM

Os LLMs não operam como leitores web neutros. Decidem activamente o que aceder, o que ignorar, e em que confiar — através de camadas de filtragem que são opacas, específicas da plataforma, e frequentemente automatizadas.

As consequências práticas são não-triviais:

• Um domínio pode passar todos os testes padrão de acessibilidade web e ainda assim ser bloqueado na camada do modelo
• O mesmo domínio pode comportar-se de forma diferente entre testes de bot, chat interactivo e geração de respostas
• Uma falha de acesso numa superfície não se propaga automaticamente às outras — mas sinaliza risco estrutural

Para SEO, a assunção é: se um crawler consegue aceder, consegue indexar. Para AEO, essa assunção está errada. O acesso é condicional, específico da plataforma, e frequentemente opaco.

A taxonomia de falhas

Nem todas as falhas de visibilidade em IA são iguais. O maior erro de diagnóstico é tratá-las como se fossem. Modos de falha diferentes requerem intervenções diferentes.

Bloqueado. O modelo ou a camada de retrieval recusa aceder ao URL. Sinais: "WebFetch blocked", domínio rejeitado antes da recuperação de conteúdo. Este é um problema da camada do vendor, não um problema de conteúdo. Resposta: escalar para a plataforma, pedir revisão manual, construir redundância de fontes externas para que a marca apareça mesmo que o domínio seja inacessível.

Ignorado. O URL é acessível, mas o modelo não o usa. Sem erro, sem citation, fontes de concorrentes usadas em vez. Resposta: melhorar a clareza de entidade, reforçar a corroboração de terceiros, reestruturar a fonte.

Alucinado. O modelo menciona a marca mas de forma imprecisa. Posicionamento errado, serviços inventados, afirmações falsas. Resposta: apertar a definição de entidade, publicar âncoras factuais explícitas, aumentar a consistência entre fontes.

Parcialmente interpretado. O modelo acede à página mas extrai apenas fragmentos. Título compreendido, corpo ignorado. Resposta: melhorar o HTML renderizado no servidor, simplificar a estrutura de conteúdo, garantir que a informação crítica aparece no início do documento sem dependência de JavaScript.

A taxonomia determina se a solução é remediação técnica, redesenho de fonte, clarificação de entidade, construção de citations ou escalamento ao vendor. Saltar o passo de diagnóstico e avançar directamente para correcções é como organizações desperdiçam meses no problema errado.

O que fazer quando encontras este erro

Se o Claude.ai devolver "WebFetch blocked" para o teu domínio, dois tracks correm em paralelo.

Track A — Escalamento à plataforma. Contactar o suporte da Anthropic. Documentar a discrepância: mostrar que o domínio devolve 200 OK, que o ClaudeBot não está bloqueado, que o robots.txt permite explicitamente o acesso. Pedir revisão manual e perguntar qual regra interna despoletou o bloqueio. A resolução é do lado do vendor, não do servidor. Nenhuma quantidade de optimização técnica da tua parte remove uma regra de filtragem dentro dos sistemas da Anthropic.

Track B — Validação independente de visibilidade. Enquanto o escalamento está em curso, testar se a marca aparece nas respostas de IA independentemente do bloqueio WebFetch. Executar prompts estruturados no ChatGPT, Perplexity e Gemini. Testar se o domínio é citado directamente ou se uma fonte de terceiros transporta a citation. Um bloqueio WebFetch no Claude.ai não significa necessariamente invisibilidade em todo o ecossistema de IA.

Checklist prático de 8 camadas de acesso

Se suspeitas que o teu domínio tem um problema de acesso LLM, trabalha estas camadas por ordem. Cada uma pode produzir um falso negativo se testada isoladamente.

Camada 1 — Acesso raw. Teste de browser e HTTP. Confirmar 200 OK. Descartar erros de servidor, redirects e paredes de autenticação.

Camada 2 — Acesso por user-agent de bot. Testar com user-agents ClaudeBot, GPTBot, PerplexityBot via curl. Verificar se o servidor devolve conteúdo ou headers diferentes para pedidos de bot. Confirmar que o robots.txt permite acesso para cada crawler relevante.

Camada 3 — Legibilidade HTML. Confirmar que títulos e parágrafos descritivos estão presentes no HTML fonte sem execução de JavaScript. Informação crítica de definição de entidade deve ser visível no início do documento. Um modelo que não consegue recuperar conteúdo renderizado por JS recebe uma página vazia.

Camada 4 — Retrieval em produto. Testar dentro da interface LLM real. O modelo faz fetch do URL quando pedido? Cita a página? Reflecte o posicionamento correcto? É aqui que as falhas WebFetch se tornam visíveis.

Camada 5 — Visibilidade ao nível de resposta. Testar se a marca aparece nas respostas geradas mesmo que um fetch directo falhe. Executar prompts sobre a categoria, o problema que a marca resolve, e o nome da marca directamente. Uma citation pode vir de dados de treino ou de fontes de terceiros indexadas, não apenas de fetch em tempo real.

Camada 6 — Teste comparativo de plataformas. Executar os mesmos prompts no ChatGPT, Claude, Perplexity e Gemini. Quais sistemas acedem, citam ou distorcem a fonte? Falhas específicas de plataforma estreitam o diagnóstico.

Camada 7 — Sensibilidade ao contexto. Testar se o acesso depende do framing da conversa. Mencionar o URL mais cedo na conversa antes de pedir ao modelo que faça fetch. Em alguns casos, a menção prévia do URL reduz o bloqueio.

Camada 8 — Prontidão para escalamento. Recolher resultados HTTP raw, resultados de user-agent de bot, screenshots de falha em produto, e respostas do vendor num único lugar. Se precisares de escalar, a evidência precisa de mostrar claramente que o problema não é server-side.

A mudança estrutural

Este caso não é um edge case. É uma demonstração de uma propriedade estrutural de como os sistemas de IA funcionam. A visibilidade tem múltiplas camadas — acesso HTTP, crawling de bots, indexação interna, filtragem da camada de retrieval, ponderação da geração de respostas — e uma aprovação numa camada não garante aprovação na seguinte.

O trabalho sério de AEO trata cada camada como uma questão de diagnóstico separada. As marcas que gerem bem a visibilidade em IA não são apenas as que têm HTML limpo e bom structured data. São as que sabem em que camada o seu problema vive — e corrigem a coisa certa.