Llms.txt é o robots.txt da era dos agents
Crawlers de busca obedeceram a um arquivo na raiz do seu site por trinta anos. Os modelos lendo seu site para clientes agora não têm tal arquivo, o que significa que eles te leem errado, e você nunca descobre.
Apollo Space Research
Apollo Space
Por três décadas, todo crawler web sério fez uma pergunta antes de tocar seu site: o que diz o arquivo na raiz? Ele buscava /robots.txt, lia as regras e as obedecia. Indústrias inteiras foram construídas sobre a suposição de que os crawlers obedeceriam. Aí um tipo diferente de leitor apareceu, um modelo de linguagem respondendo uma pergunta para um dos seus clientes, e ele não tinha arquivo para ler. Então ele leu tudo, decidiu o que sua empresa era por conta própria, e citou qualquer parágrafo que por acaso rankeasse.
Você nunca viu a resposta que ele deu. Você só perdeu o cliente que perguntou.
Crawlers de busca obedeceram a um arquivo na raiz do seu site por trinta anos. Os modelos lendo seu site para clientes agora não têm tal arquivo. Este post é sobre o arquivo que conserta isso, o que ele é, por que a versão ingênua dele falha, e o que ele de fato tem de conter para mudar a resposta que um modelo dá sobre você.
O leitor mudou, e o contrato não
Comece pelo que robots.txt de fato era. Nunca foi sobre segurança, qualquer um podia ignorá-lo. Era um contrato de intenção: um arquivo pequeno e previsível numa localização conhecida que dizia a um leitor automatizado como se comportar no seu site. Onde ele podia ir. Onde não devia. A qual crawler as regras se aplicavam. A web concordou na localização e no formato, e porque todo mundo concordou, o arquivo funcionou.
O contrato segurou porque o leitor era previsível. Um crawler de busca tinha um trabalho: indexar páginas para que um humano pudesse depois encontrá-las e clicar. O humano fazia a leitura. O crawler era só um bibliotecário decidindo o que ia na prateleira.
Esse leitor está sendo substituído. O novo leitor não indexa sua página para que um humano possa encontrá-la. Ele lê sua página para que um humano nunca tenha de fazê-lo. Alguém pergunta a um modelo “quem devo usar para X”, e o modelo responde a partir do que quer que tenha absorvido sobre você, seus preços, seu posicionamento, o post de blog do seu concorrente sobre você, e o cliente age sobre essa resposta sem nunca carregar seu site. O clique pelo qual você otimizou por trinta anos não aconteceu. A leitura aconteceu em algum lugar que você não consegue ver, e o arquivo que costumava governar o leitor não governa nada agora, porque foi escrito para um bibliotecário e o bibliotecário virou um advogado que responde em seu nome.
O gargalo nunca desapareceu. Ele se moveu. Costumava ser o crawler consegue encontrar minha página. Agora é o modelo consegue entender minha empresa bem o suficiente para representá-la corretamente quando eu não estou na sala.
A correção ingênua: só escreva mais conteúdo
Aqui está a primeira coisa para a qual todo mundo apela, porque é o que funcionou da última vez. Se modelos leem seu site e o entendem errado, escreva mais. Publique mais páginas. Enfie mais keywords. Repita sua proposta de valor em mais lugares para que o modelo não possa errá-la. Isto é memória muscular de otimização para mecanismos de busca, e é o músculo errado.
Falha por uma razão específica. Um mecanismo de busca recompensava volume porque mais páginas indexadas significava mais chances de bater com uma query. Um modelo não funciona assim. Um modelo lê suas quarenta páginas, encontra três delas se contradizendo, a página de preços diz uma coisa, o post de blog antigo diz outra, o FAQ uma terceira, e não tem como saber qual é verdadeira agora. Então ele tira a média. Ou pega a mais confiantemente redigida, que costuma ser a mais desatualizada. Ou cita o concorrente que descreveu você mais claramente do que você descreveu a si mesmo.
Mais conteúdo não faz um modelo te entender. Dá a ele mais formas de te contradizer.
A correção ingênua trata o modelo como um crawler que só precisa de mais para mastigar. Mas o modelo não está faminto por conteúdo. Está se afogando em conteúdo não-rankeado, não-datado, não-atribuído sem nenhum sinal sobre o que é canônico. Você não tem um problema de volume. Você tem um problema de autoridade, nada no seu site diz ao leitor em qual fonte confiar quando suas próprias fontes discordam.
O que o arquivo de fato tem de fazer
Então precisamos de um arquivo de novo, mas não pode ser o arquivo antigo com um nome novo. robots.txt respondia aonde você pode ir. O arquivo da era dos agents tem de responder uma pergunta mais difícil: quando você representa minha empresa, o que é verdade, o que é canônico, e o que você deve citar. Esse é o formato do llms.txt, e a ideia por trás dele é simples mesmo que a disciplina não seja.
A ideia-chave é esta. O arquivo é um único mapa em texto plano na raiz do seu site que faz três trabalhos de uma vez. Primeiro, ele nomeia o que sua empresa é, nas suas palavras, datado, autoritativo, para que o modelo tenha uma fonte em que pode confiar acima das páginas espalhadas. Segundo, ele aponta para a versão canônica de toda coisa importante: este é o preço real, esta é a lista de produtos atual, esta é a história de cliente, e estas páginas mais antigas estão superadas. Terceiro, ele diz ao leitor o que citar, a URL que você quer atribuída quando um modelo responde sobre você, para que a citação aponte para algum lugar que você controla em vez de algum lugar que você esqueceu.
Vamos explicar por que cada um dos três é load-bearing.
A auto-descrição importa porque a alternativa é o modelo escrevendo sua descrição por você. Se você não diz claramente “somos uma empresa que faz X para Y”, o modelo infere isso a partir de manchetes e meta tags e do tom de um post de lançamento, e a inferência deriva. Um modelo que tem de chutar o que você é vai chutar, e vai chutar diferente para diferentes clientes fazendo perguntas ligeiramente diferentes.
O ponteiro canônico importa porque resolve o problema da contradição na fonte. Quando sua página de preços e seu post de blog antigo discordam, o arquivo é o critério de desempate: esta URL é canônica, aquela está superada. Agora o modelo não está tirando a média de duas fontes de idade desconhecida. Ele tem um vencedor declarado. A contradição que costumava produzir uma resposta errada e confiante produz a certa, porque você disse ao leitor em qual das suas próprias vozes acreditar.
A diretiva de citação importa porque atribuição é o novo clique. Quando um modelo responde “use esta empresa para X”, a coisa valiosa não é uma visita, é a citação, a fonte nomeada que o cliente pode verificar e à qual o modelo pode retornar. Se você não diz onde apontar, o modelo aponta para onde quer que seu treinamento por acaso tenha ancorado: um site de reviews, uma página de comparação de concorrente, um press release de três anos atrás. O arquivo reivindica a citação de volta.
Canônico é um verbo, não uma tag
Há uma armadilha no ponteiro canônico, e é a mesma armadilha que fez a correção de conteúdo ingênua falhar. As pessoas tratam “canônico” como uma coisa que você declara uma vez e esquece, uma tag que você seta, uma linha que você escreve, pronto. Não é. Canônico é uma coisa que você mantém, porque o ponto inteiro é que ela permaneça verdadeira à medida que todo o resto muda.
Imagine a falha. Suponha que você escreva o arquivo uma vez, num dia bom, e ele está perfeito. Ele nomeia a empresa, aponta para o preço real, lista o produto atual. Aí, ao longo dos próximos meses, o preço muda, um produto é renomeado, uma história é aposentada. Ninguém atualiza o arquivo. Agora o arquivo, a única fonte que você disse a todo modelo para confiar acima de todas as outras, é o documento mais confiantemente errado no seu site. Você não só deixou de ajudar o leitor. Você entregou a ele uma falsificação com a sua assinatura nela.
É por isso que um arquivo estático escrito à mão é necessário e não suficiente. O arquivo tem de ser gerado a partir da verdade, não transcrito dela. O preço canônico deveria vir de onde quer que o preço real viva. A lista de produtos deveria vir da lista de produtos real. A data de “vigência” deveria ser hoje, automaticamente, para que um modelo possa ver quão fresca a alegação é e ponderá-la. Um arquivo editado à mão vai apodrecer do mesmo jeito que o CRM apodrece, no momento em que mantê-lo depende de alguém lembrar.
Uma auto-descrição que ninguém atualiza é pior do que nenhuma. É uma resposta errada na qual o leitor confia mais do que na certa.
A disciplina, então, não é “escreva um llms.txt”. É “faça do arquivo um render do seu estado canônico atual, datado, e re-renderizado sempre que aquele estado muda”. Essa é a diferença entre um arquivo que ajuda um modelo a representar você e um arquivo que silenciosamente envenena toda resposta sobre você por meses.
Quem mantém o arquivo verdadeiro
Note o que isso silenciosamente exige. Para renderizar uma descrição da sua empresa pronta-para-citação, datada e canônica em toda mudança, algo tem de saber o que sua empresa atualmente é, através de preços, produtos, posicionamento, as histórias que você conta, e notar quando qualquer parte disso se move.
Isso não é uma tarefa de conteúdo. É uma tarefa de sistemas. A razão pela qual arquivos llms.txt escritos à mão apodrecem é a mesma razão pela qual CRMs preenchidos à mão apodrecem e páginas de status atualizadas à mão mentem: um fato que vive na memória de alguém de “eu deveria atualizar aquilo” é um fato que já está obsoleto. O arquivo permanece verdadeiro só se a empresa tem um único lugar que segura o que é canônico, um company brain, e o arquivo é uma visão sobre ele, não uma cópia dele.
Isso reenquadra o problema inteiro. A pergunta nunca foi “como escrevo um bom llms.txt”. É “minha empresa tem uma fonte de verdade coerente o suficiente para que um modelo pudesse lê-la e me entender certo”. Se a resposta é não, o arquivo só expõe a incoerência a todo leitor que importa. Se a resposta é sim, o arquivo praticamente se escreve sozinho, e se reescreve, porque é uma projeção de algo já verdadeiro.
A virada: você está sendo lido tendo você publicado ou não
Aqui está a parte que não é sobre um arquivo.
Agora, hoje, um modelo em algum lugar está respondendo uma pergunta sobre sua empresa. Ele está contando a um cliente prospectivo o que você faz, o que você cobra, se você é o fit certo, como você se compara. Ele está fazendo isso a partir do que quer que tenha conseguido encontrar, rankeado de qualquer jeito que rankeia, datado nunca. Você não foi consultado. Você não viu a resposta. E o cliente que a ouviu pode já ter decidido.
Essa é a mudança desconfortável. Por trinta anos, ser lido por uma máquina era um opt-in que você controlava, um crawler que você podia permitir ou bloquear, um resultado que você podia otimizar. Agora você está sendo lido por default, resumido por default, representado por default, e a única pergunta é se o leitor tem algo de você para ler ou tem de inventar. Silêncio não é neutro. Silêncio é o modelo preenchendo a lacuna com a fonte mais confiante que consegue encontrar, que raramente é você.
O arquivo é pequeno. A disciplina por trás dele é a empresa inteira ser legível para um leitor que você nunca vai conhecer, mantida atual por algo que não esquece. Crawlers de busca obedeceram a um arquivo na raiz do seu site por trinta anos; os modelos lendo seu site para clientes agora não têm tal arquivo, e escrevê-lo é a forma mais barata de parar de ser descrito por estranhos.
É parte do que estamos construindo na Apollo Space, um company brain coerente o suficiente para que o arquivo dizendo aos modelos quem você é possa ser um render da verdade, datado e atual, em vez de um snapshot digitado à mão que está errado até sexta. Se você já leu o que um modelo diz sobre sua empresa e fez careta, você já sabe que o problema não é o modelo. É que ninguém lhe entregou a página certa.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaO imposto oculto dos agents em paralelo é um diamante de migrations
Seis agents escrevendo para um schema conflitam no banco de dados, não no código, e a CI morre em "multiple heads".
EngenhariaUm orchestrator que não sobrevive ao próprio crash não é um
Um crash que apaga o raciocínio do orchestrator perde a única coisa que você não consegue reconstruir.
EngenhariaColoque um portão determinístico na frente do seu revisor mais esperto
A pega-defeito mais barata é um script burro que checa se duas branches mergeadas ainda sobem antes de qualquer julgamento.