llms.txt é um arquivo markdown publicado na raiz de um site para orientar modelos de linguagem sobre o que o site faz e quais páginas são relevantes para consulta. Proposto por Jeremy Howard (fast.ai) em setembro de 2024, o padrão foi adotado por empresas como Cloudflare, Stripe e Perplexity como sinal de que a comunicação direta com agentes de AI passou a ser infraestrutura — não opcional. No AEO Framework™ da EPIC, ele faz parte do Layer 0 (Discovery), a camada que determina se um agente sequer encontra o seu site.
Última atualização: 19 Mai 2026
llms.txt é um arquivo de texto em markdown, publicado na raiz de um domínio (em /llms.txt), que diz a modelos de linguagem o que um site faz, quais seções existem e quais URLs são prioritárias para leitura.
Pense nisso assim: robots.txt diz ao rastreador do Google onde ele pode ou não ir. llms.txt diz ao modelo de AI o que ele deveria ler primeiro — e por quê. São propósitos completamente diferentes.
O arquivo tem formato simples e intencionalmente legível por humanos e por máquinas. A spec oficial, mantida em llmstxt.org, define a estrutura mínima: um cabeçalho H1 com o nome do site, um blockquote com descrição resumida, e seções H2 com listas de links anotados — URLs que o modelo deve consultar para entender aquele produto, serviço ou documentação.
Não é um padrão de consórcio. Não passou por comitê de standards. É uma proposta pragmática que resolveu um problema real, foi adotada por grandes players e ganhou tração orgânica em menos de um ano.
A resposta curta: porque o tráfego de agentes de AI para sites corporativos não é mais hipotético. É mensurável, crescente e fundamentalmente diferente do tráfego humano.
Um usuário humano chega ao seu site via Google, lê dois ou três parágrafos, e decide se vai mais fundo. Um agente de AI chega via API ou via crawl autônomo, precisa entender em segundos o que esse site faz, quem serve e quais ações estão disponíveis, e então decide se vai citar, recomendar ou executar uma transação a partir dali.
O problema é que a maioria dos sites não foi construída para esse visitante. A homepage tem hero sections com animações CSS, formulários em iframe e textos genéricos de "soluções inovadoras para o seu negócio". Para um humano, isso é familiar. Para um modelo de linguagem tentando entender o que a empresa faz em menos de 500 tokens, é ruído.
llms.txt resolve o problema de forma cirúrgica: em vez de forçar o agente a inferir o contexto do site a partir de HTML cheio de nav, footer e scripts, você publica um documento limpo que responde às perguntas que o modelo vai fazer de qualquer jeito.
Por isso Cloudflare adotou. Por isso Stripe adotou. Não por altruísmo tecnológico — mas porque eles entendem que quando um desenvolvedor pede ao ChatGPT "como integrar pagamentos via Stripe", a qualidade da resposta depende do que o modelo tem disponível sobre Stripe. llms.txt é a forma de controlar essa narrativa.
O diretório público em directory.llmstxt.cloud lista centenas de sites que já publicaram o arquivo. Entre os adotantes mais relevantes para um público B2B tech:
A EPIC também publica o seu: epic.digital/llms.txt. O arquivo descreve o que a EPIC faz, quais recursos existem para agentes de AI consumirem (incluindo o AEO Framework™ e o Commerce Layer™), e disponibiliza links para endpoints estruturados. Serve como exemplo real de L0 implementado — e é o arquivo que o nosso próprio CLI v2.2 usa como referência de calibração ao auditar Discovery.
Uma nota importante sobre Anthropic: o arquivo em anthropic.com/llms.txt é frequentemente citado como referência inicial de adoção, mas o acesso direto pode variar por configuração de servidor. O que importa é o padrão, não a URL específica de cada empresa — e o padrão está documentado em llmstxt.org.
A spec é deliberadamente minimalista. Isso não é descuido — é uma decisão de design. O arquivo tem que ser legível por humanos sem ferramenta, parseável por modelos sem treinamento específico, e processável por scripts sem biblioteca adicional.
A estrutura recomendada:
# Nome do Site ou Produto
> Descrição em uma ou duas frases. O que é, para quem serve, qual o problema que resolve.
## Seção Principal (ex: Documentação)
- [Nome da página](https://exemplo.com/pagina): descrição curta do que tem ali.
- [Outra página](https://exemplo.com/outra): o que o modelo vai encontrar nessa URL.
## Seção Secundária (ex: Sobre)
- [Quem somos](https://exemplo.com/sobre): contexto institucional.
## Optional
- [Recurso adicional](https://exemplo.com/recurso): informação útil mas não prioritária.
O bloco ## Optional é uma instrução explícita para modelos com contexto limitado: se você não tiver espaço para processar tudo, pode pular esta seção. É um mecanismo de priorização embutido no próprio formato.
O llms.txt da EPIC, por exemplo, declara quem somos, o que o AEO Framework™ faz, lista as páginas principais disponíveis em markdown (a spec recomenda que páginas disponibilizem versão .md via URL), aponta para o agent-card.json e para o sitemap-aeo.json — os outros dois componentes do L0 no nosso framework.
O resultado é que quando um agente chega em epic.digital/llms.txt, ele sabe em menos de 300 tokens: o que a EPIC faz, quais recursos técnicos estão disponíveis para consumo estruturado, e onde ir para cada caso de uso. Sem precisar rastrear o site inteiro.
A confusão é compreensível. São dois arquivos de texto na raiz do domínio com nomes similares. Mas os propósitos são opostos em direção e diferentes em mecanismo.
robots.txt é uma instrução de controle de acesso para rastreadores. Ele diz ao Googlebot, ao ClaudeBot, ao GPTBot: "você pode ir aqui, não pode ir ali." É permissão. É bloqueio. Opera antes do conteúdo ser lido.
llms.txt é um documento de contexto para modelos. Ele não controla acesso — ele orienta compreensão. Não diz "não vá aqui". Diz "se você está aqui, isso é o que você precisa saber primeiro."
Um modelo de linguagem pode ignorar completamente o robots.txt (e alguns agentes fazem isso). Um modelo que lê llms.txt está fazendo isso porque quer entender o site — não porque foi obrigado. É uma interação diferente em natureza.
Na prática: você precisa dos dois. robots.txt para gerenciar quais rastreadores têm permissão de acessar quais partes do seu site (incluindo quais agentes de AI você quer ou não quer). llms.txt para garantir que, quando um modelo chegar, ele entenda o site rapidamente e com precisão.
No AEO Framework™, robots.txt e llms.txt são dois dos 11 checks do Layer 0 (Discovery). Ter um sem o outro é passar em metade do diagnóstico.
Criar é simples. O que dá trabalho é decidir o que dizer — não o formato.
Antes de abrir o editor de texto, responda estas quatro perguntas:
## Optional.Com as respostas em mão, o arquivo leva menos de 30 minutos para ser redigido. A implantação depende da sua infraestrutura: em servidores com acesso ao diretório raiz, é publicar um arquivo estático. Em plataformas como HubSpot, Vercel ou Netlify, você cria o arquivo como um recurso específico e configura o path.
Uma ressalva prática: llms.txt não é um documento que você publica uma vez e esquece. Quando você lança um novo produto, abre um novo endpoint, publica um pillar de conteúdo relevante, ou muda o posicionamento — o arquivo precisa ser atualizado. Tratá-lo como documentação viva, não como configuração estática, é o que separa uma implementação funcional de uma implementação que fica desatualizada em seis meses.
O CLI proprietário da EPIC (@epic-digital/aeo, não distribuído publicamente) inclui o comando aeo generate, que analisa um domínio e gera um rascunho de llms.txt com base nas páginas existentes — parte do workflow de onboarding AEO para clientes. É um ponto de partida, não um substituto para a decisão editorial sobre o que incluir.
llms.txt resolve o problema de discovery — garante que um agente chegue ao seu site com contexto suficiente para entender o que você faz. É Layer 0 no AEO Framework™. É o começo.
O que a maioria das empresas não pergunta é: e depois que o agente entendeu o que você faz, o que ele pode fazer?
É essa a diferença entre um site que é citável por AI e um site que é acionável por AI.
No AEO Framework™, o Layer 4 é o Commerce Layer™ — a camada de infraestrutura machine-to-machine que permite que agentes executem transações reais: solicitar uma cotação, iniciar uma avaliação técnica, acessar dados de produto via endpoint JSON, completar uma sequência de vendas sem intervenção humana em nenhum passo do processo.
llms.txt diz ao agente "a EPIC faz arquitetura de receita e tem um diagnóstico AEO disponível". O Commerce Layer™ é o que permite que esse agente inicie o diagnóstico — com os dados certos, no formato certo, sem precisar preencher um formulário em HTML.
Para organizações B2B com ciclos de venda longos, múltiplos stakeholders e decisões de compra que envolvem pesquisa técnica prévia, essa camada não é diferencial de futuro. É o que determina se o seu site vai ser acionável no próximo ciclo de agentes autônomos de procurement e avaliação de fornecedores — que já estão em uso em empresas de tecnologia, infraestrutura e SaaS no exterior.
O caminho vai de llms.txt (Layer 0) até o Commerce Layer™ (Layer 4) passando por structured data, semantic HTML e narrative blocks. O pillar AEO Framework™ documenta o sistema completo — cada camada, cada check, cada decisão de implementação.
aeo audit <url>) executa esses checks e retorna um score com diagnóstico detalhado. Alternativamente, você pode testar manualmente abrindo seudominio.com/llms.txt e verificando se o arquivo carrega em plain text com a estrutura markdown correta.O seu site está preparado para ser encontrado por agentes de AI?
O AEO Framework™ da EPIC audita os 76 checks distribuídos em 7 camadas — de llms.txt no Layer 0 até analytics de agentes no Layer 6. O diagnóstico inicial é gratuito e o resultado chega em 1 dia útil.
Solicitar audit AEO gratuito | Ler o AEO Framework™ completo