Can AI agents use your website?

Um novo tipo de visitante

Durante trinta anos, um site teve exatamente um tipo de visitante que importava: uma pessoa, num navegador, a olhar para páginas renderizadas. Tudo na web moderna — os pacotes de JavaScript, os banners de cookies, os desafios visuais antibots — foi construído para esse visitante. Os agentes de IA quebram o pressuposto. Um agente que trabalha para um utilizador costuma obter HTML bruto sem executar JavaScript, identifica-se honestamente com um agente de utilizador como GPTBot ou ClaudeBot, lê os ficheiros orientados para máquinas que um site publica (robots.txt, mapas do site, llms.txt, especificações OpenAPI) e decide em poucos pedidos se este site pode sequer ser compreendido e usado. Os sites que chumbam esse teste não são punidos em voz alta; o agente simplesmente vai para outro lado, e a visita nunca aparece em nenhum painel de análises que possua.

Isto importa agora, e não eventualmente, porque os agentes estão a tornar-se um canal real: assistentes que pesquisam compras, agentes que reservam e compram, agentes de suporte que leem a sua documentação para responder a clientes, rastreadores que constroem os índices a partir dos quais esses sistemas respondem. Cada um deles classifica o seu site pela legibilidade para máquinas, e a maioria dos sites nunca foi desenhada para ser lida assim. A lacuna raramente é malícia ou negligência — é que a superfície orientada para máquinas (as regras de rastreio, o HTML bruto, as descrições de API) cresceu por acidente enquanto a superfície orientada para pessoas recebia toda a atenção de desenho. A preparação para agentes é a disciplina de fechar essa lacuna de propósito.

As quatro camadas da preparação para agentes

O verificador pontua quatro camadas, pela ordem em que um agente as experimenta. A descoberta (20 pontos) é se o agente consegue encontrar o mapa do site: um robots.txt analisável e o que ele diz aos principais rastreadores de IA, um mapa do site alcançável, um ficheiro llms.txt, dados estruturados, um URL canónico que aponta para si próprio. O acesso (30 pontos) é se o agente consegue entrar depois de chegar: páginas que respondem a um cliente HTTP simples, nenhuma recusa de agentes de utilizador de IA, nenhum intersticial de desafio antibots, conteúdo real no HTML bruto em vez de uma casca vazia à espera de JavaScript, um redirecionamento limpo para HTTPS e códigos de estado honestos — um 404 verdadeiro para o que não existe, porque um agente que não consegue distinguir uma página em falta de uma real não pode confiar em mais nada que o site diga.

A usabilidade (40 pontos) é a maior camada, porque chegar não é o mesmo que transacionar. Pergunta se o site expõe maquinaria através da qual um agente possa agir: uma especificação OpenAPI nos caminhos que os agentes procuram, documentação que uma máquina possa encontrar, um endpoint MCP que responde a uma sonda de protocolo, metadados de descoberta de autenticação quando há uma API onde entrar, e os humildes formulários web — registo, contacto, leads — alcançáveis sem desafio e etiquetados bem o suficiente para serem preenchidos corretamente. Os pagamentos (10 pontos) perguntam se um agente conseguiria pagar: um ficheiro de descoberta para um dos protocolos emergentes de comércio agentivo (ACP, UCP, AP2, x402) e um checkout que não planta um desafio na cara do agente. Os pagamentos só são pontuados quando um site vende mesmo alguma coisa; num site sem sinais de comércio, a camada inteira não é aplicável e a pontuação é reescalada sem ela.

Como ler uma pontuação

A pontuação vai de 0 a 100, com notas em letras A a partir de 85, B de 70, C de 55, D de 40 e F abaixo — e 70, o limiar do B, é onde a convenção da categoria põe a linha de «pronto para agentes». Trate o número como um resumo, não como o produto. O produto é a lista de achados: cada verificação que falhou ou avisou, a evidência recolhida para ela, o que significa, a correção e os pontos que a correção recupera. A ordenação «corrija primeiro» é simplesmente essa lista ordenada por pontos recuperáveis, o que quase nunca é a ordem que uma lista genérica daria — um llms.txt em falta pode valer mais do que três avisos cosméticos juntos, e a ordenação é o que lho diz.

Dois hábitos de leitura mantêm o número honesto. Primeiro, respeite o mecanismo de não aplicável: verificações e camadas inteiras saem quando a sua pré-condição está ausente, e a pontuação renormaliza, por isso um site de documentação não está a ser classificado pelo seu checkout. Uma pontuação só tem sentido face às camadas que se aplicaram. Segundo, lembre-se do que significa um veredito: «não encontrado» é sempre «não encontrado nos caminhos que um agente tentaria, a partir da rede do analisador, no momento da análise». Os agentes tentam os caminhos convencionais — é esse o sentido do exercício —, mas uma análise é uma amostra da superfície orientada para máquinas, não uma auditoria de tudo o que um agente determinado poderia acabar por descobrir com um humano a orientá-lo.

As falhas que mais custam, e as suas correções

O mesmo punhado de falhas explica a maioria dos pontos perdidos em sites reais. Rastreadores de IA bloqueados por omissão: um robots.txt copiado de um modelo, ou uma predefinição de segurança de um CDN, recusa liminarmente GPTBot, ClaudeBot e companhia — por vezes o contrário do que o proprietário pretende, já que os mesmos rastreadores alimentam os motores de respostas onde o proprietário quer aparecer. A correção é uma política de robots deliberada: decida por rastreador, escreva-a, mantenha o mapa do site permitido. A casca vazia: a página inicial devolve um pacote de JavaScript e uma roda a girar, com o conteúdo real renderizado só no cliente; os humanos nunca reparam, os agentes veem uma página vazia. Renderize no servidor, ou pré-renderize, o conteúdo que importa. Sem mapa para máquinas: sem mapa do site, sem llms.txt, sem dados estruturados — cada um barato de acrescentar, cada um um achado separado até o fazer.

O segundo punhado é sobre agir, não ler. Segurança de desafio primeiro: uma muralha antibots que desafia cada cliente desconhecido também desafia cada agente; a correção é desafiar por comportamento e sinais de risco em vez de só por desconhecimento, e manter alcançável a superfície pública só de leitura. APIs não documentadas ou não descobríveis: a API existe, mas não há especificação OpenAPI num caminho encontrável, por isso cada integração de um agente se torna um jogo de adivinhas à medida; publicar a especificação é uma exportação única na maioria das frameworks. Formulários que um agente não consegue preencher: campos sem etiqueta, dicas só no marcador de posição, e fluxos de submissão que exigem resolver um puzzle visual para um formulário de contacto rotineiro. Nenhuma destas correções exige redesenhar o site humano — a camada orientada para máquinas é quase inteiramente aditiva, e é por isso que os pontos estão lá para quem os quiser.

Estudo de caso: este site, analisado

Uma divulgação antes do número. O próprio sysosx.com não pode ser analisado com o verificador público acima: como cada verificação da sysosx, o endpoint recusa sysosx.com como alvo bloqueado, por desenho, para que a ferramenta não possa ser apontada à sua própria infraestrutura. O estudo de caso abaixo foi portanto produzido de outro modo — o mesmo motor de análise, com as mesmas verificações e pontuação, corrido localmente contra o site sysosx.com ao vivo. A pontuação é saída real do motor, não uma estimativa; só o ponto de vista difere.

Para onde foram os pontos: os principais achados

Perguntas frequentes