Pular para o conteúdo
Voltar

llms.txt v2 chegou: o que mudou e o que você deve atualizar

Publicado:  at  10:00 AM

llms.txt v2 chegou: o que mudou e o que você deve atualizar

Em 10 de agosto de 2026, Jeremy Howard publicou a v2 da proposta llms.txt, a primeira revisão desde o lançamento do formato em setembro de 2024. Dois anos de adoção produziram uma lista clara do que estava faltando, do que era ambíguo ou do que simplesmente não era usado da forma que a especificação supunha.

Comecemos pela parte tranquilizadora: seu arquivo llms.txt atual continua válido. O formato do arquivo não mudou. O que mudou é tudo ao redor dele, principalmente a resposta a uma pergunta que milhares de adotantes repetiam.

O problema que a v2 resolve

A v1 mandava publicar um llms.txt cheio de links e servir versões limpas em Markdown das suas páginas em page.html.md. Mas nunca conectou as duas pontas.

Nas palavras de Howard, o arquivo “apontava os agentes para as páginas, mas nada na especificação dizia a eles onde as versões em Markdown realmente estavam”.

Ou seja, um agente que chegava em https://exemplo.com/docs/auth não tinha como responder de forma confiável a duas perguntas básicas:

  1. Existe uma versão em Markdown desta página? Onde?
  2. Existe um llms.txt cobrindo esta página? Onde?

Restava adivinhar: tentar acrescentar .md, tentar /llms.txt na raiz, torcer para dar certo. A v2 substitui adivinhação por declaração.

Esta é a mudança principal. A v2 recomenda duas link relations padrão do HTML:

Você pode entregá-las como elementos <link> no seu <head>:

<link rel="alternate" type="text/markdown" href="/docs/page.html.md" />
<link rel="describedby" href="/docs/llms.txt" />

Ou, melhor para a maioria dos times, como cabeçalho de resposta HTTP Link::

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Por que a versão em cabeçalho importa: você pode adicioná-la na configuração do seu servidor web ou CDN sem tocar em um único template. Ela também funciona para recursos não-HTML, incluindo os próprios arquivos Markdown. Se você usa Cloudflare, Netlify, Vercel ou nginx, isso é uma mudança de configuração, não uma migração.

E não são convenções inventadas: alternate e describedby são link relations já registradas na IANA. A v2 optou por reaproveitar o encanamento da web em vez de inventar um novo.

Mudança 2: dois padrões de URL para Markdown agora são aceitos

A v1 especificava uma única convenção: acrescentar .md à URL completa, de modo que /docs/tutorial.html virava /docs/tutorial.html.md.

Na prática, muitas ferramentas de publicação fizeram a outra coisa óbvia e substituíram a extensão: /docs/tutorial.md. A v2 aceita as duas.

PadrãoOriginalVersão em Markdown
Acrescentar .md/docs/tutorial.html/docs/tutorial.html.md
Substituir a extensão/docs/tutorial.html/docs/tutorial.md
URL sem extensão/docs/tutorial//docs/tutorial/index.html.md ou /docs/tutorial/index.md

A nota da própria especificação sobre isso: a prática “divergiu da v1 de formas que valem ser abençoadas”. É um jeito saudável de conduzir um padrão. Nenhum dos dois padrões é preferido, então use o que sua stack produz naturalmente e depois declare-o com rel="alternate".

Mudança 3: a cobertura por subcaminho agora está definida com precisão

Um arquivo llms.txt cobre as URLs abaixo do seu próprio caminho, e quando vários arquivos se aplicam, os agentes devem usar o mais específico. Então /docs/llms.txt cobre tudo em /docs/ e tem precedência sobre o /llms.txt da raiz para essas páginas.

Isso é mais do que um esclarecimento. É a razão de o llms.txt ficar em um caminho em vez de /.well-known/ (RFC 8615). URIs bem conhecidas só existem na raiz da origem, e muita gente controla apenas um subdiretório: um site de projeto no GitHub Pages, uma pasta de docs em um host compartilhado, a seção de um time dentro de um domínio corporativo. Na v2, quem consegue publicar um arquivo em um caminho consegue publicar um llms.txt para ele.

Se você mantém docs, blog e site de marketing sob um mesmo domínio, agora pode dar a cada um seu próprio arquivo com escopo definido, sabendo qual deles prevalece.

Mudança 4: llms_txt2ctx saiu, e a mecânica da seção “Optional” também

A v1 trazia uma ferramenta de linha de comando, llms_txt2ctx, que expandia um llms.txt em um grande bloco de contexto, com a seção ## Optional carregando um significado mecânico (pule-a quando o contexto ficar apertado).

A v2 remove ambos da especificação. Não porque expandir contexto seja ruim, mas porque não é assim que os agentes se comportam. Agentes reais visualizam ou pesquisam o llms.txt e depois seguem apenas os links de que precisam. O arquivo permanece pequeno o suficiente para caber no contexto; o detalhe vive atrás dos links e é buscado sob demanda.

A seção ## Optional continua existindo, mas agora puramente por convenção: links secundários que um agente pode pular quando quer um contexto mais curto. Sem semântica de ferramenta atrelada.

Mudança 5: o enquadramento alcançou a realidade

A seção de contexto de 2024 era uma previsão: a de que agentes leriam sites rotineiramente. A v2 a reescreve como descrição, porque hoje isso é só mais uma terça-feira.

A especificação agora cita as evidências: milhares de sites publicam o arquivo, plataformas de documentação o geram automaticamente, o Lighthouse do Chrome audita sua presença como parte das verificações de navegação agêntica, e os próprios laboratórios de IA publicam os seus, OpenAI, Anthropic e a equipe do Gemini do Google servem llms.txt para suas documentações de desenvolvedor.

O que o formato ainda exige (sem mudanças)

Vale repetir, porque é a parte que as pessoas erram e nada disso se moveu na v2:

Cada lista de arquivos é uma lista Markdown em que todo item tem um link obrigatório e, opcionalmente, um : seguido de notas:

# Título

> Descrição opcional vai aqui

Detalhes opcionais vão aqui

## Nome da seção

- [Título do link](https://link_url): Detalhes opcionais do link

## Optional

- [Título do link](https://link_url)

Seu checklist da v2

  1. Mantenha seu arquivo atual. Ele continua em conformidade com a especificação. Não reescreva.
  2. Sirva versões em Markdown das suas páginas importantes, usando qualquer um dos dois padrões de URL.
  3. Adicione as duas link relations, de preferência como cabeçalho HTTP Link: no CDN ou no servidor, para não precisar editar templates.
  4. Delimite seus arquivos por caminho se um domínio hospeda várias áreas distintas.
  5. Aponte seus links para Markdown, não para HTML. Os links dentro do llms.txt devem levar a conteúdo amigável para LLMs. Isso já valia na v1 e é o erro mais comum.
  6. Valide antes de publicar, para que o arquivo que você sobe realmente seja interpretável.

Uma coisa que a v2 não mudou

O llms.txt continua sendo uma proposta, não um padrão web ratificado, e continua não sendo um fator de classificação do Google. O Google disse claramente que não usa o arquivo. A v2 torna o formato mais útil para os agentes que de fato o leem, um conjunto real e crescente, mas não transforma o arquivo em uma alavanca de SEO.

Se alguém te vender a v2 como upgrade de ranqueamento, leia primeiro O llms.txt é um fator de classificação do Google?.

Conclusão

A v2 é uma revisão pequena e sensata que corrige a única lacuna estrutural da v1: agentes conseguiam ler seu arquivo, mas não conseguiam encontrá-lo, nem encontrar o Markdown para o qual ele apontava. Duas link relations fecham essa lacuna, e uma delas é uma linha de configuração no CDN.

Pronto para atualizar? Gere um arquivo em conformidade com a especificação usando nosso gerador de llms.txt e depois confira o formato com o validador de llms.txt. Se ainda estiver decidindo se o arquivo vale a pena para o seu site, comece por Quando o llms.txt faz sentido.



Próximo Artigo
O llms.txt é um fator de classificação do Google? Não. Aqui está para que serve