Como Tornar Seu Site Legível para Agentes: 4 Camadas, Um Trabalhador

TL;DR

Para tornar seu site legível por agentes, você precisa de quatro camadas — legível, descobrível, chamável, pagável — e três delas são arquivos que você gera no momento da construção, não código que é executado por solicitação. Um gêmeo em Markdown de cada página é 94% menor que o HTML deste site (13.698 bytes contra 227.990), um conjunto de links /.well-known/api-catalog torna esses gêmeos encontráveis, e apenas a camada chamável precisa de um servidor. Se você errar essa última parte, você também conta cada visualização de página humana, que é como este site uma vez ganhou um erro Cloudflare 1027.

O que é um site legível por agentes?

Um site legível por agentes é aquele que publica uma cópia voltada para máquinas de seu conteúdo e um índice legível por máquinas dessa cópia, em seus próprios URLs, para que um agente nunca precise analisar HTML para usá-lo. Essa é toda a definição. É uma propriedade do seu espaço de URL, não do seu servidor — é por isso que quase tudo pode ser pré-renderizado.

O post da Cloudflare sobre a internet agentic de 6 de agosto de 2026 divide o problema em quatro camadas. É um documento de visão, então nomeia produtos mais do que caminhos. Reduzido à implementação, as camadas são:

A ordem importa. Cada camada só vale a pena construir se a camada acima existir — um endpoint chamável que nenhum agente pode descobrir é uma URL que ninguém digita, e uma camada pagável em conteúdo que nenhum agente pode ler é um pedágio em uma estrada fechada.

Camada 1: Legível significa um gêmeo em Markdown, não um redirecionamento

A especificação llms.txt que Jeremy Howard publicou em 3 de setembro de 2024 contém toda a ideia em uma linha: sirva uma versão limpa em Markdown de uma página no mesmo URL com .md anexado. Essa é a camada legível. Tudo o mais é elaboração.

A razão para se preocupar é bytes. Eu medi uma postagem neste site de três maneiras:

O Markdown limpo é 94% menor que o HTML — um fator de 16,6. Essa diferença não é compressão, é exclusão: CSS embutido, a carga do framework, o cabeçalho e o rodapé, três blocos JSON-LD e o alternador de tema. Tudo isso é essencial para um humano e peso morto para um modelo com uma janela de contexto a preencher.

Dois detalhes de implementação são fáceis de errar.

Dê ao Markdown seu próprio URL. Não faça ramificações em User-Agent na borda para decidir o que servir. Isso é disfarce no sentido de mecanismo de busca, e também força cada visualização de página a passar por uma rota dinâmica — veja a seção de roteamento abaixo para o que isso custa. /blog/post.md como um documento separado e publicamente buscável não é disfarce; é publicar dois arquivos.

Gere-o no momento da construção. O gêmeo em Markdown é uma função pura da fonte que você já tem. Renderizá-lo sob demanda não lhe dá nada e custa uma solicitação. A divisão em duas URLs também lhe dá um lugar limpo para colocar a versão honesta: este site mantém uma cópia não patrocinada de cada postagem em /clean/blog/<slug>.md precisamente para que o documento voltado para máquinas permaneça auditável — a razão está na análise dos anúncios de agentes da TIME.

Camada 2: Onde vivem os padrões reais

Legível é uma convenção. Descobrir tem especificações reais, e usá-las não custa nada.

/llms.txt é o índice escrito por humanos: um H1, um bloco de citação resumido e listas delimitadas por H2 de links com descrições de uma linha. Pense nisso como um sitemap escrito para algo que lê prosa. A variante /llms-full.txt que a maioria dos sites também envia — todo o corpus concatenado — é uma convenção da comunidade, não parte da especificação. Envie ambos; eles atendem a diferentes orçamentos de contexto.

/.well-known/api-catalog é o padrão. RFC 9727, publicado em junho de 2025, define-o como um URI bem conhecido que retorna application/linkset+json — uma lista legível por máquinas de cada API e superfície de documento que você publica, cada uma com uma relação de link e tipo de mídia. É a diferença entre um agente adivinhando cinco caminhos bem conhecidos e lendo um documento que os nomeia todos.

O conjunto completo de descoberta neste site é nove arquivos estáticos:

/llms.txt                              text/plain
/llms-full.txt                         text/plain
/.well-known/api-catalog               application/linkset+json   (RFC 9727)
/.well-known/mcp                       application/json
/.well-known/mcp/server-card.json      application/json           (SEP-1649)
/.well-known/agent-skills/index.json   application/json
/.well-known/oauth-protected-resource  application/json           (RFC 9728)
/auth.md                               text/markdown
/.well-known/security.txt              text/plain

Cada um deles é pré-renderizado. Nenhum deles precisa de um servidor.

Um ponto de honestidade vale mais aqui do que um fluxo de autenticação fabricado: /.well-known/oauth-protected-resource neste site declara que /mcp é público e não requer autenticação, e o documento do servidor de autorização não anuncia nenhum endpoint de token porque nenhum existe. Publicar metadados OAuth que descrevem um servidor de autenticação que você não construiu é pior do que não publicar nada — isso envia agentes para um handshake que nunca será concluído.

Camada 3: Por que chamável é a única camada que precisa de um servidor

Um endpoint MCP é onde "legível por agentes" se transforma em "utilizável por agentes". Este site expõe quatro ferramentas sobre JSON-RPC em /mcp:

curl -s -X POST https://