I  Sinal da Semana

A proposta de 2024 sem resposta dos motores

Veja o que a proposta original diz e o que o mercado passou a prometer por cima dela.

O llms.txt nasceu como sugestão pública, não como padrão acordado com quem opera os modelos. Jeremy Howard, cofundador da Answer.AI e figura conhecida por trabalhos anteriores de aprendizado de máquina, publicou a ideia em setembro de 2024, junto com um site que descreve o formato.

A proposta é econômica e faz sentido de engenharia. Um arquivo em markdown, salvo na raiz do domínio, com um título, um parágrafo de resumo e listas de links comentados. O modelo que precisasse entender o site inteiro leria aquele arquivo em vez de rastrear centenas de páginas cheias de menu, rodapé e banner de cookie.

A palavra que sustenta a frase é proposta. Não houve anúncio conjunto com OpenAI, Anthropic, Google ou Perplexity, e nenhuma dessas empresas publicou até hoje documentação afirmando que seus rastreadores buscam o arquivo ou usam o conteúdo dele para montar respostas.

O contraste com o robots.txt explica por que a confusão pegou. O robots.txt também começou como convenção informal, em 1994, mas foi adotado publicamente pelos buscadores em poucos meses e virou documentação oficial de cada um deles. O llms.txt completou quase dois anos sem essa segunda metade da história.

A diferença que decide

Arquivo que o motor confirma ler é infraestrutura. Arquivo que ninguém confirmou ler é aposta barata.

O que existe de concreto são medições independentes de registros de servidor, feitas por times de conteúdo e por consultorias, e todas contam a mesma coisa: o llms.txt é pedido quase sempre por auditores de SEO e raramente por rastreador de motor de resposta.

Ainda assim, a adoção cresceu rápido. Grandes empresas de documentação técnica publicaram o arquivo, plataformas de site passaram a gerar o llms.txt automaticamente e agências incluíram o item em pacote de serviço com preço.

A explicação da adoção não é técnica. O arquivo é barato, cabe numa tarde, aparece num relatório como entrega concluída e não quebra nada se ninguém ler. É a proposta de menor atrito num mercado que ainda não sabe o que fazer com a fila que distribui as respostas.

O risco também não é técnico, é de atenção. A empresa que publica o arquivo e considera o assunto encerrado deixa de mexer no que já se sabe que a máquina lê hoje, que é o HTML entregue pelo servidor em cada página pública do domínio.

II  Case Brasileiro

A software house de Belo Horizonte que mediu o próprio arquivo

Uma software house de Belo Horizonte vende um sistema de gestão para clínicas odontológicas, tem quarenta funcionários e mantém uma base de documentação com cento e vinte artigos de ajuda, escritos ao longo de seis anos pelo time de suporte.

O diretor de produto leu sobre o llms.txt numa comunidade de tecnologia e pediu para o time publicar o arquivo. Havia uma expectativa clara, dita em reunião: aparecer nas respostas quando um dentista perguntasse ao ChatGPT qual sistema usar para agenda e prontuário.

Antes de publicar, o time fez a única coisa sensata para quem quer saber se algo funciona. Escreveu trinta perguntas que um dentista faria, rodou as trinta em três motores e anotou quem era citado em cada resposta. A empresa apareceu duas vezes nas noventa respostas.

O arquivo foi publicado no fim de março, com trinta e dois links comentados. Durante noventa dias, o time monitorou duas coisas ao mesmo tempo: os pedidos ao arquivo nos registros do servidor e a repetição das mesmas trinta perguntas a cada quinze dias.

Os registros do servidor no período fecharam assim.

Pedidos ao llms.txt: 63

Vindos de auditores de SEO: 58

Vindos de rastreador de motor de resposta: 0

As citações nas trinta perguntas subiram de duas para nove no mesmo intervalo, e é justamente aí que o caso deixa de ser óbvio. O ganho não veio do arquivo, veio do que a equipe precisou fazer para conseguir escrevê-lo.

Para listar os trinta e dois links, alguém teve que abrir os cento e vinte artigos de ajuda e decidir quais mereciam entrar. A leitura revelou dezenove artigos com informação desatualizada, sete duplicados que respondiam a mesma dúvida com respostas diferentes e onze sem título que descrevesse a pergunta real do dentista.

A limpeza levou cinco semanas. Os duplicados foram fundidos, os desatualizados foram corrigidos com a versão atual do sistema, e os títulos passaram a repetir a pergunta do usuário em vez do nome interno da funcionalidade.

Nove das novas citações apontavam para artigos de ajuda reescritos nessa limpeza. Nenhuma apontava para o llms.txt, que continuava lá, correto, atualizado e sem um único pedido de rastreador de motor de resposta.

O diretor de produto resumiu o aprendizado numa frase que vale guardar. A empresa foi premiada pelo trabalho de organizar o conteúdo, não pelo arquivo que serviu de desculpa para começar o trabalho.

III  Checklist da Semana

Publique o arquivo sem entregar o resultado a ele

1. Trate o llms.txt como aposta de vinte minutos. Publique, porque o custo é baixo e a chance de virar padrão daqui a um ano não é zero. O erro não está em publicar, está em contar com o arquivo como resposta ao problema.

2. Escreva o índice à mão, nunca deixe a plataforma gerar. Arquivo gerado automaticamente lista todas as páginas do site em ordem de menu. O valor inteiro do exercício está em escolher quais páginas merecem entrar e escrever uma frase honesta sobre cada uma.

3. Use a escolha das páginas como auditoria de conteúdo. Ao decidir os quinze ou trinta links, você vai encontrar página desatualizada, duplicada e sem título claro. Anote cada uma numa lista separada, porque essa lista é o trabalho que traz retorno medido.

4. Corrija o que a leitura revelou antes de comemorar. Funda duplicados, atualize dado velho e troque título interno por pergunta de cliente. É a etapa que a maioria pula, e é a única com efeito comprovado nas citações.

5. Confirme que as páginas listadas existem no HTML entregue. Não adianta apontar no índice para uma página cujo texto só aparece depois que o script roda no navegador. Abra o código-fonte de cada link listado e procure uma frase real dentro dele.

6. Puxe os registros do servidor sessenta dias depois. Filtre pelo endereço do arquivo e separe os pedidos por agente. Se o único movimento vier de ferramenta de auditoria, você tem a sua resposta local, medida no seu domínio, sem depender de opinião de ninguém.

7. Meça citação com pergunta repetida, não com sensação. Escreva trinta perguntas reais do seu cliente antes de qualquer mudança, rode em três motores e guarde o resultado. Repita as mesmas trinta a cada quinze dias, sempre com as mesmas palavras.

8. Revise o arquivo quando o site mudar de verdade. Página nova importante, produto descontinuado, mudança de endereço. Índice desatualizado é pior que índice ausente no dia em que algum motor decidir começar a ler.

A armadilha mais cara aparece na etapa um, quando o arquivo vira item de relatório entregue e o assunto sai da pauta. Publicar leva vinte minutos, e o que realmente decide citação leva semanas de trabalho no conteúdo do próprio domínio.

A segunda armadilha é a agência que cobra por implementação de llms.txt como serviço avulso. O trabalho que justifica preço é a auditoria e a correção dos artigos, não o arquivo de texto que qualquer estagiário publica numa tarde.

A terceira é confundir adoção com validação. Milhares de sites publicaram o arquivo, e nenhum motor confirmou ler nenhum deles, o que são duas afirmações verdadeiras ao mesmo tempo e que dizem coisas diferentes.

O arquivo é uma aposta barata sobre o futuro, e a limpeza de conteúdo que ele provoca é um ganho medido no presente.

"Quais quinze páginas do seu site você colocaria nesse índice hoje?"

Quem propôs o formato llms.txt, e quando?

Como foi a edição de hoje?