Llms.txt foi o primeiro passo. Aqui está a arquitetura que vem a seguir
A conversa sobre llms.txt é real e vale a pena continuar. Abordei isso em um artigo anterior, e o instinto central por trás da proposta está correto: os sistemas de IA precisam de acesso limpo, estruturado e confiável às informações da sua marca, e a arquitetura atual do seu site não foi construída com isso em mente. Onde quero ir mais longe é na própria arquitetura. llms.txt é, em sua essência, um índice que aponta para arquivos Markdown. Este é um ponto de partida, não um destino, e as evidências sugerem que o destino precisa de ser consideravelmente mais sofisticado.
Antes de entrarmos na arquitetura, quero deixar algo claro: não estou argumentando que toda marca deva correr para construir tudo descrito neste artigo até o próximo trimestre. O cenário de padrões ainda está em formação. Nenhuma grande plataforma de IA se comprometeu formalmente a consumir llms.txt, e uma auditoria de logs CDN em 1.000 domínios do Adobe Experience Manager descobriu que os bots específicos do LLM estavam essencialmente ausentes das solicitações de llms.txt, enquanto o próprio rastreador do Google era responsável pela grande maioria das buscas de arquivos. O que defendo é que a questão em si, especificamente como os sistemas de IA obtêm acesso estruturado e autorizado às informações da marca, merece uma reflexão arquitetónica séria neste momento, porque as equipas que a refletirem antecipadamente definirão os padrões que se tornarão padrões. Esse não é um argumento exagerado. É assim que esta indústria tem funcionado sempre que surge um novo paradigma de recuperação.
Onde Llms.txt fica fora do caminho
O valor honesto da proposta é a legibilidade: ela oferece aos agentes de IA um caminho limpo e silencioso para o seu conteúdo mais importante, compactando-o em Markdown e organizando-o em um único diretório. Para documentação do desenvolvedor, referências de API e conteúdo técnico onde a prosa e o código já estão relativamente estruturados, isso tem uma utilidade real. Para marcas empresariais com conjuntos de produtos complexos, conteúdo de relacionamento intenso e fatos que mudam continuamente, a história é diferente.
O problema estrutural é que llms.txt não possui modelo de relacionamento. Diz a um sistema de IA “aqui está uma lista de coisas que publicamos”, mas não pode expressar que o Produto A pertence à Família de Produtos B, que o Recurso X foi descontinuado na Versão 3.2 e substituído pelo Recurso Y, ou que a Pessoa Z é o porta-voz autorizado do Tópico Q. É uma lista simples, sem gráfico. Quando um agente de IA está fazendo uma consulta de comparação, ponderando múltiplas fontes entre si e tentando resolver contradições, uma lista simples sem metadados de proveniência é exatamente o tipo de entrada que produz resultados que parecem confiáveis, mas imprecisos. Sua marca paga o custo de reputação dessa alucinação.
Há também uma questão de encargos de manutenção que a proposta não aborda completamente. Uma das objeções práticas mais fortes ao llms.txt é a manutenção contínua que ele exige: cada mudança estratégica, atualização de preços, novo estudo de caso ou atualização de produto requer a atualização do site ativo e do arquivo. Para uma pequena ferramenta de desenvolvedor, isso é gerenciável. Para uma empresa com centenas de páginas de produtos e uma equipe de conteúdo distribuído, é um passivo operacional. A melhor abordagem é uma arquitetura que se baseia programaticamente em fontes de dados confiáveis, em vez de criar uma segunda camada de conteúdo para manutenção manual.
A pilha de conteúdo legível por máquina
Pense no que estou propondo não como uma alternativa ao llms.txt, mas como o que vem depois dele, assim como os sitemaps XML e os dados estruturados vieram depois do robots.txt. Existem quatro camadas distintas e você não precisa construir todas elas de uma vez.
A camada um consiste em fichas técnicas estruturadas usando JSON-LD. Quando um agente de IA avalia uma marca para uma comparação de fornecedores, ele lê o esquema de Organização, Serviço e Revisão e, em 2026, isso significa lê-lo com muito mais precisão do que o Google fez em 2019. Esta é a base. Páginas com dados estruturados válidos têm 2,3 vezes mais probabilidade de aparecer nas visões gerais de IA do Google em comparação com páginas equivalentes sem marcação, e a pesquisa Princeton GEO descobriu que conteúdo com sinais estruturais claros teve visibilidade até 40% maior em respostas geradas por IA. JSON-LD não é novo, mas a diferença agora é que você deve tratá-lo não como uma peça de rich snippet, mas como uma camada de fatos voltada para a máquina, e isso significa ser muito mais preciso sobre atributos de produtos, estados de preços, disponibilidade de recursos e relacionamentos organizacionais do que a maioria das implementações atualmente.
A camada dois é o mapeamento de relacionamento entre entidades. É aqui que você expressa o gráfico, não apenas os nós. Seus produtos estão relacionados às suas categorias, suas categorias são mapeadas para as soluções do seu setor, suas soluções se conectam aos casos de uso que você oferece suporte e tudo isso está vinculado à fonte confiável. Isso pode ser implementado como uma extensão gráfica JSON-LD leve ou como um endpoint dedicado em um CMS headless, mas a questão é que um sistema de IA consumidor deve ser capaz de atravessar sua arquitetura de conteúdo da mesma forma que um analista humano revisaria um catálogo de produtos bem organizado, com contexto de relacionamento preservado em cada etapa.
A camada três são endpoints de API de conteúdo, acesso programático e versionado às suas perguntas frequentes, documentação, estudos de caso e especificações de produtos. É aqui que a arquitetura vai além da marcação passiva e passa para a infraestrutura ativa. Um endpoint em /api/brand/faqs?topic=pricing&format=json que retorna respostas estruturadas, com carimbo de data e hora e atribuídas é um sinal categoricamente diferente para um agente de IA do que um arquivo Markdown que pode ou não refletir o preço atual. O Model Context Protocol, introduzido pela Anthropic no final de 2024 e posteriormente adotado pela OpenAI, Google DeepMind e Linux Foundation, fornece exatamente esse tipo de estrutura padronizada para integração de sistemas de IA com fontes de dados externas. Você não precisa implementar o MCP hoje, mas a trajetória de onde a troca de dados entre IA e marca está caminhando é claramente em direção a interfaces estruturadas, autenticadas e em tempo real, e sua arquitetura deve ser construída nessa direção. Venho dizendo isso há anos – que estamos migrando para sistemas conectados para a troca e compreensão em tempo real dos dados de uma empresa. É isso que acaba com o rastreamento e o custo para as plataformas associado a ele.
A camada quatro são metadados de verificação e proveniência, carimbos de data/hora, autoria, histórico de atualização e cadeias de origem anexadas a cada fato que você expõe. Esta é a camada que transforma seu conteúdo de “algo que a IA lê em algum lugar” em “algo que a IA pode verificar e citar com confiança”. Quando um sistema RAG está decidindo qual dos vários fatos conflitantes surgirá em uma resposta, os metadados de proveniência são o desempate. Um fato com um carimbo de data/hora de atualização claro, um autor atribuído e uma cadeia de origem rastreável sempre superará uma declaração sem data e não atribuída, porque o sistema de recuperação é treinado para preferi-lo.
Como isso se parece na prática
Considere uma empresa SaaS de médio porte, uma plataforma de gerenciamento de projetos que fatura cerca de US$ 50 milhões em ARR e vende tanto para pequenas e médias empresas quanto para contas corporativas. Eles têm três níveis de produtos, um mercado de integração com 150 conectores e um ciclo de vendas onde as comparações competitivas acontecem em pesquisas assistidas por IA antes que um representante de vendas humano entre em cena.
No momento, o site deles é excelente para compradores humanos, mas opaco para agentes de IA. Sua página de preços é JavaScript renderizada dinamicamente. Sua tabela de comparação de recursos fica em um PDF que a IA não consegue analisar de maneira confiável. Seus estudos de caso são HTML longos, sem atribuição estruturada. Quando um agente de IA os avalia em relação a um concorrente para uma comparação de compras, ele está trabalhando com tudo o que pode inferir do texto rastreado, o que significa que provavelmente está errado no preço, provavelmente errado na disponibilidade de recursos empresariais e quase certamente incapaz de revelar a integração específica que o cliente potencial precisa.
Uma arquitetura de conteúdo legível por máquina muda isso. Na camada de ficha técnica, eles publicam esquemas JSON-LD de organização e produto que descrevem com precisão cada nível de preços, seu conjunto de recursos e seu caso de uso alvo, atualizados programaticamente a partir da mesma fonte de verdade que orienta sua página de preços. Na camada de relacionamento entre entidades, eles definem como suas integrações são agrupadas em categorias de solução, para que um agente de IA possa responder com precisão a uma pergunta composta de capacidade sem ter que analisar 150 páginas de integração separadas. Na camada da API de conteúdo, eles expõem um endpoint de comparação estruturado e versionado, algo que um engenheiro de vendas atualmente produz manualmente mediante solicitação. Na camada de proveniência, cada fato carrega um carimbo de data/hora, um proprietário de dados e um número de versão.
Quando um agente de IA agora processa uma consulta de comparação de produtos, o sistema de recuperação encontra fatos atuais estruturados, atribuídos, em vez de texto inferido. A IA não alucina seus preços. Ele representa corretamente seus recursos empresariais. Ele revela as integrações corretas porque o gráfico da entidade as conectou às categorias de solução corretas. O vice-presidente de marketing que lê um relatório de perdas competitivas seis meses depois não considera “a IA citou preços incorretos” como a causa raiz.
Esta é a infraestrutura por trás dos pacotes de origem verificados
No artigo anterior sobre Verified Source Packs, descrevi como as marcas podem se posicionar como fontes preferidas em pesquisas assistidas por IA. A API de conteúdo legível por máquina é a arquitetura técnica que torna os VSPs viáveis em escala. Um VSP sem esta infraestrutura é uma declaração de posicionamento. Um VSP com ele é uma camada de fatos validada por máquina que os sistemas de IA podem citar com confiança. O VSP é a saída visível para o seu público; a API de conteúdo é o encanamento que torna a saída confiável. Dados estruturados limpos também melhoram diretamente o seu higiene do índice vetoriala disciplina que apresentei em um artigo anterior, porque um sistema RAG que constrói representações a partir de conteúdo bem estruturado, mapeado em relacionamentos e com registro de data e hora produz incorporações mais nítidas do que um que trabalha a partir de prosa indiferenciada.
Construir vs. Espere: a questão do tempo real
A objecção legítima é que as normas não estão estabelecidas, e isso é verdade. O MCP tem um verdadeiro impulso, com 97 milhões de downloads mensais de SDK até 2026 e adoção da OpenAI, Google e Microsoft, mas os padrões de API de conteúdo empresarial ainda estão surgindo. JSON-LD está maduro, mas o mapeamento de relacionamento de entidade no nível de marca ainda não tem especificação formal.
A história, no entanto, sugere que a objecção vai no sentido contrário. As marcas que implementaram os dados estruturados do Schema.org em 2012, quando o Google acabava de lançá-los, e ninguém tinha certeza de quão amplamente eles seriam usados, moldaram a forma como o Google consumiu dados estruturados na década seguinte. Não esperaram por uma garantia; eles construíram de acordo com o princípio e deixaram o formato padrão em torno de seu caso de uso. O mecanismo específico importa menos do que o princípio subjacente: o conteúdo deve ser estruturado para a compreensão da máquina, ao mesmo tempo que permanece valioso para os humanos. Isso será verdade independentemente de qual protocolo vencer.
A implementação mínima viável, que você pode lançar neste trimestre sem apostar a arquitetura em um padrão que pode mudar, consiste em três coisas. Primeirouma auditoria JSON-LD e atualização de suas principais páginas comerciais, esquemas de Organização, Produto, Serviço e FAQPage, devidamente interligados usando o padrão de gráfico @id, para que sua camada de fatos seja precisa e legível por máquina hoje. Segundoum único endpoint de conteúdo estruturado para suas informações comparadas com mais frequência, que, para a maioria das marcas, são preços e recursos principais, gerados programaticamente a partir de seu CMS para que permaneçam atualizados sem manutenção manual. Terceirometadados de proveniência sobre todos os fatos de interesse público: um carimbo de data/hora, um autor ou equipe atribuído e uma referência de versão.
Isso não é um llms.txt. Não é uma cópia Markdown do seu site. É uma infraestrutura durável que serve tanto os atuais sistemas de recuperação de IA como qualquer padrão que seja formalizado a seguir, porque é construída com base no princípio de que as máquinas precisam de fatos limpos, atribuídos e mapeados em relacionamentos. As marcas perguntando “devemos construir isso?” já estão atrás daqueles que perguntam “como podemos dimensionar isso”. Comece com o mínimo. Envie algo neste trimestre que você possa medir. A arquitetura lhe dirá para onde ir em seguida.
Duane Forrester tem quase 30 anos de experiência em marketing digital e SEO, incluindo uma década na Microsoft administrando SEO para MSN, construindo Bing Webmaster Tools e lançando Schema.org. Seu novo livro sobre como permanecer confiável e relevante na era da IA (The Machine Layer) já está disponível na Amazon.
Mais recursos:
Esta postagem foi publicada originalmente em Decodificações Duane Forrester.
Imagem em destaque: mim.girl/Shutterstock; Paulo Bobita/Search Engine Journal
