llms.txt e Páginas de Manifesto de Agentes: Um Índice de Site Mantido Voltado para Máquinas

Uma página llms.txt e manifesto de agente é um índice voltado para máquinas que informa aos sistemas de IA o que um site representa, quais páginas públicas são autoritativas e — quando o negócio suporta ações de agente — quais capacidades e políticas verificadas se aplicam. É um mapa para fontes mantidas, não um substituto para essas fontes e não uma promessa de que qualquer rastreador específico a utilizará.

Seu contrato é identidade → escopo → destinos autoritativos → capacidades opcionais → restrições → atualização. O arquivo é bem-sucedido quando uma máquina pode recuperá-lo, interpretá-lo sem adivinhação, seguir URLs canônicas ativas e chegar a fatos que ainda correspondem à realidade de produção.

Perguntas que responde

A pergunta principal é: “Quais partes deste site um sistema de IA deve usar para entender a organização, seu conteúdo e suas ações suportadas?” As perguntas de suporte incluem:

• Qual é o nome canônico, domínio, propósito e público do site?
• Quais páginas de produto, serviço, documentação, preços, política e suporte são autoritativas?
• Quais páginas devem ser preferidas em relação a arquivos, páginas de campanha, parâmetros ou versões regionais duplicadas?
• O site expõe uma capacidade de agente real ou apenas informações legíveis por humanos?
• Onde estão documentadas autenticação, limites de taxa, tratamento de dados, termos comerciais e suporte?
• Quais afirmações são orientações descritivas em vez de regras de controle de acesso?
• Quem é o proprietário do arquivo, qual evento aciona uma atualização e como a deriva é detectada?

Quando usar este tipo de postagem

Use este tipo quando o site tiver conteúdo público e durável suficiente para se beneficiar de um índice curado voltado para máquinas e alguém puder assumir sua manutenção. A razão para publicá-lo é reduzir ambiguidade para sistemas de recuperação, não criar mais uma URL por si só.

Não confunda orientação com controle. O robots.txt expressa preferências de acesso do crawler; um sitemap XML ajuda crawlers a descobrir URLs; autenticação e autorização decidem se uma ação pode ocorrer. O llms.txt fornece contexto curado. Uma frase no llms.txt não pode conceder acesso, revogar acesso, proteger um segredo ou sobrepor os termos de uma página de destino.

Melhor para estes tipos de negócio

1. SaaS . O ajuste mais forte porque uma empresa de software geralmente tem fontes distintas de produto, funcionalidade, preços, integração, API, segurança, status e documentação. O índice pode resolver qual página possui cada fato, enquanto um manifesto de capacidade separado pode descrever apenas ações que o produto realmente suporta.
2. E-commerce . Forte quando produtos, envio, devoluções, disponibilidade e políticas de atendimento ao cliente são públicos e canônicos. Mantenha dados voláteis de itens em feeds ou APIs; use o índice para apontar para essas fontes mantidas em vez de copiar um catálogo em Markdown.
3. Marketplaces . Valioso quando as políticas de comprador, vendedor, provedor e plataforma diferem. Rotule cada público e jurisdição para que um agente não aplique regras de vendedor a um comprador ou infira estoque da plataforma a partir de um único anúncio.
4. Serviços B2B . Útil para esclarecer capacidades, setores, limites de serviço, evidências, materiais de aquisição e rotas de contato. Não converta um escopo negociado ou promessa específica de cliente em uma afirmação universal voltada para máquinas.
5. Agências . Útil quando a empresa mantém muitas páginas de serviço, metodologia, estudo de caso e expertise. Portais de cliente, credenciais, relatórios privados e manuais internos ficam de fora do arquivo público.
6. Indústrias e manufatura . Útil para direcionar sistemas a famílias de produtos, especificações, certificações, manuais, distribuidores e documentos de segurança. O índice nunca deve parafrasear instruções críticas de segurança quando o documento controlado é a autoridade.

Pequenos sites de brochura com cinco páginas estáveis podem ganhar pouco com mais um artefato mantido. Sites sem um proprietário de conteúdo claro devem corrigir canonicalização, navegação e qualidade de fonte antes de publicar um arquivo que imediatamente ficará desatualizado.

Intenção de busca

A intenção de busca é o resultado esperado de uma consulta. Este tipo tem dois públicos com intenções diferentes. Uma máquina busca um caminho raiz previsível e espera Markdown conciso, cabeçalhos estáveis, links canônicos e sem ruído decorativo. Um buscador humano geralmente quer orientação de implementação: “exemplo llms.txt”, “o que colocar no llms.txt” ou “formato de manifesto de agente”. A página explicativa pública pode responder a essas perguntas, enquanto o /llms.txt implantado permanece otimizado para recuperação por máquina.

O arquivo em si não é uma página de palavra-chave. Não adicione definições genéricas, termos de categoria repetidos ou centenas de links de blog para fazê-lo “ranquear”. Cada linha extra consome atenção e cria outra obrigação de manutenção. Prefira dez links deliberados com descrições claras a um despejo de dez mil URLs.

Como as convenções e o suporte do consumidor podem mudar, declare em que sua implementação se baseia e evite afirmar adoção universal. Uma busca bem-sucedida prova apenas que o arquivo está acessível e analisável; não prova que um produto de IA específico o utiliza para ranqueamento, recuperação, treinamento ou citação.

Estrutura da página

As faixas de palavras são restrições de edição, não metas. O arquivo implantado deve permanecer conciso o suficiente para ser auditado linha por linha. A nota de implementação voltada para humanos pode ser mais longa, mas não deve ser copiada para o arquivo de máquina.

Um arquivo curado típico tem aproximadamente 200–700 palavras. Comprimento não é um sinal de qualidade: o tamanho certo é o menor índice que estabelece identidade e direciona um consumidor a fontes mantidas sem esconder distinções importantes.

Elementos obrigatórios

O índice deve ser chato no melhor sentido: previsível, explícito e fácil de diferenciar. Coloque interpretação crítica antes de links opcionais para que uma leitura parcial não produza uma conclusão falsa.

Frontmatter

Siga a especificação de frontmatter . Nesta especificação de tipo de postagem, use entity = "post-type-llms-txt-page" e schemaType = "Article". Em uma página de implementação voltada para humanos de uma organização específica, use uma identidade estável como acme-ai-access-index, não uma frase de campanha ou data.

Use Article porque a página web explica a implementação. A marcação schema descreve conteúdo visível; ela não transforma o arquivo de texto bruto em um protocolo de agente reconhecido. Não marque a página como SoftwareApplication, Dataset ou HowTo a menos que seu conteúdo visível e modelo satisfaçam os requisitos relevantes de forma independente.

O arquivo bruto /llms.txt normalmente não tem frontmatter porque o frontmatter não deve vazar para a saída publicada. Armazene seus metadados operacionais no CMS, configuração do gerador ou registro do repositório: domínio canônico, escopo de localidade, proprietário, coleção de origem, modo de geração, última data de verificação, próxima regra de revisão, resultado do validador e destino de alerta. Se existirem arquivos localizados, documente a regra de seleção e mantenha uma resposta raiz canônica inequívoca.

Exemplo completo

Este arquivo fictício demonstra um índice conciso para uma plataforma SaaS. Suas URLs, produto e capacidade são exemplos; o padrão é a especificação.

# Northstar Analytics

> Northstar Analytics é uma plataforma de relatórios para equipes de operações. Este índice aponta para as páginas públicas que definem o produto, planos, documentação, políticas e capacidade de agente suportada.

As permissões de acesso são controladas pelo robots.txt, autenticação e pelas políticas vinculadas abaixo. Este arquivo não concede acesso ou permissão para reutilizar conteúdo.

## Produto

- [Visão geral do produto](https://www.northstar.example/product): Escopo atual do produto e fluxos de trabalho de relatórios suportados.
- [Planos e preços](https://www.northstar.example/pricing): Planos públicos atuais, funcionalidades incluídas e termos de faturamento.
- [Integrações](https://www.northstar.example/integrations): Fontes de dados e sistemas de destino suportados.

## Documentação

- [Página inicial da documentação](https://docs.northstar.example/): Documentação atual para usuários e administradores.
- [Referência da API](https://docs.northstar.example/api/): Endpoints públicos, esquemas, autenticação, erros e limites de taxa.
- [Notas de versão](https://docs.northstar.example/releases/): Alterações datadas no produto e no comportamento da API.

## Confiança e suporte

- [Segurança](https://www.northstar.example/security): Programa de segurança e documentos de garantia atuais.
- [Política de privacidade](https://www.northstar.example/privacy): Processamento de dados, retenção e direitos do usuário.
- [Suporte](https://www.northstar.example/support): Rotas de contato suportadas e link de status do serviço.

## Capacidade de agente

- [Ação de exportação de relatório](https://docs.northstar.example/agents/export-report): Contrato de ação autenticada, entradas aceitas, formato de saída, limites de taxa e tratamento de erros. A disponibilidade depende do plano e função do usuário.

## Opcional

- [Biblioteca de pesquisas](https://www.northstar.example/research): Relatórios de referência originais com métodos e datas de publicação.

Verificado em 2026-08-27 pela equipe de Operações de Documentação. Gerado a partir do registro canônico de recursos públicos; valide após alterações em produto, plano, política, API ou URL.

O exemplo declara apenas uma capacidade porque existe um contrato de ação real e documentado. Se o produto não tiver uma ação de agente suportada, omita essa seção. Nunca infira uma capacidade transacional a partir da presença de uma caixa de busca, formulário ou endpoint não documentado.

Para um manifesto de agente armazenado separadamente do /llms.txt, mantenha a mesma disciplina. Especifique um formato versionado, identificador canônico, endpoint de produção, método de autenticação, operações permitidas, esquema de entrada e saída, limites de taxa, limites de consentimento, estados de erro e URLs de política. Valide-o contra o sistema ativo. Uma declaração sintaticamente válida que anuncia uma ação desabilitada ainda está errada.

Galeria de design

O arquivo bruto tem pouco design visual por intenção. As variantes da galeria devem testar arquitetura da informação, ordem de leitura, legibilidade em dispositivos móveis da página de implementação humana e evidências operacionais — não decoração.

Lista de verificação de qualidade

Publique apenas quando cada afirmação aplicável for verdadeira:

• O arquivo é resolvido na URL raiz pretendida sem autenticação, loops de redirecionamento, muros de consentimento ou um shell de aplicação renderizado.
• A resposta é texto simples ou Markdown legível, usa UTF-8 e não depende de JavaScript para revelar seu conteúdo.
• O H1 fornece o nome canônico da organização ou site, e a descrição declara propósito, público e escopo sem slogans.
• Cada URL vinculada é canônica, pública, indexável por política, acessível e de propriedade da organização ou claramente rotulada como externa.
• As descrições dos links dizem qual autoridade o destino possui; elas não repetem texto de âncora genérico como “saiba mais”.
• Fontes primárias de produto, preços, documentação, política e suporte concordam com o índice.
• Páginas de arquivo, resultados de busca, parâmetros de rastreamento, localidades duplicadas, páginas de campanha e páginas de tag de baixo valor são excluídas.
• Alegações de capacidade correspondem a um contrato ativo, suportado e autenticado e incluem as restrições relevantes.
• Nenhum segredo, token, endpoint privado, dado pessoal, documento de cliente, item de roteiro não publicado ou detalhe de implementação sensível à segurança aparece.
• A linguagem de acesso, permissão, licenciamento e política aponta para fontes controladoras e não é contradita pelo índice.
• O arquivo não alega ranqueamento garantido, citação, exclusão de treinamento ou suporte universal do consumidor.
• O escopo de localidade e regional é explícito sempre que preços, políticas, disponibilidade ou documentação diferem.
• O proprietário, registro de origem, processo de geração e método de validação são registrados fora ou no final do arquivo.
• Verificações de link quebrado, redirecionamento inesperado, status de resposta, hash de conteúdo e seções obrigatórias são executadas após implantações relevantes.
• A data de verificação muda apenas depois que destinos, descrições, capacidades e políticas são verificados substancialmente.

Erros comuns

Tratar o arquivo como um sitemap. Um inventário completo de URLs destrói a priorização e é difícil de revisar. Mantenha sitemaps XML para descoberta; selecione o llms.txt em torno de fontes autoritativas e grupos significativos.

Tratá-lo como controle de acesso. Uma solicitação em Markdown não é uma camada de aplicação. Expresse regras de rastreamento no robots.txt, proteja recursos privados com autenticação e coloque requisitos vinculantes na política relevante e nos controles do sistema.

Copiar o conteúdo de destino para dentro do índice. Preços, especificações de produto e políticas repetidos divergem. Resuma apenas o suficiente para identificar a autoridade e, em seguida, link para a fonte mantida.

Publicar capacidades especulativas. Um formulário ou rota de API não documentado não torna um site pronto para agente. Declare apenas ações suportadas em produção com autenticação, esquemas, restrições, erros e um proprietário.

Incluir tudo “por precaução”. Mais links criam mais ambiguidade e mais pontos de falha. Conteúdo opcional deve ganhar inclusão ao responder a uma necessidade provável de recuperação que as seções principais não cobrem.

Expor material privado. Arquivos públicos legíveis por máquina são públicos. Nunca liste hosts de staging, APIs internas, credenciais, exportações de clientes, documentos não publicados ou detalhes de segurança que não foram intencionalmente aprovados para publicação.

Gerar sem governança. A automação pode reproduzir dados-fonte ruins em velocidade. Um gerador precisa de um registro de origem aprovado, regras de exclusão, ordenação determinística, validação, responsabilidade de revisão e alertas de implantação.

Editar manualmente um arquivo gerado. A próxima geração sobrescreve a correção. Corrija o registro de origem ou o gerador, regenere e registre a alteração material.

Afirmar resultados não suportados. “Isso garante citações de IA” transforma uma convenção de implementação incerta em uma promessa enganosa. Relate evidências de acessibilidade e recuperação separadamente dos resultados de visibilidade e citação.

Atualizar a data sem verificar a realidade. Um novo carimbo de data/hora não pode reparar uma URL de documentação quebrada, um plano renomeado ou uma ação desabilitada. Verificação significa comparar cada declaração importante com sua fonte de produção.

Links internos

Link a página de implementação humana para tipos de postagem de SEO quando um autor precisar distinguir o índice de máquina de um diretório, página de documentação ou política. Link de cada afirmação operacional para sua fonte controladora: escopo do produto para a página do produto, preços atuais para preços, comportamento para documentação, permissões para controles de acesso e obrigações para política.

O arquivo bruto deve usar URLs canônicas absolutas porque pode ser recuperado fora da navegação normal do site. Prefira um destino autoritativo por fato. Se duas páginas se sobrepõem, resolva a propriedade antes de listar ambas; o índice deve expor a hierarquia de fontes, não memorializar desacordo interno.

Use nomes de seção curtos e estáveis como Product, Documentation, Policies e Agent capabilities. Mantenha variantes de localidade em grupos claramente rotulados apenas quando diferirem materialmente. Não link cada post de blog; selecione pesquisas ou guias duráveis apenas quando ajudarem um sistema a entender o assunto e as evidências do site.

Links de entrada também importam operacionalmente. Documentação, portais de desenvolvedor e orientações de acessibilidade para IA devem direcionar mantenedores ao registro de implementação, enquanto o registro aponta para o arquivo ativo e o validador. Isso cria um caminho de revisão para humanos sem poluir o índice de máquina.

Como medir resultados

Meça o arquivo como infraestrutura primeiro e como insumo de visibilidade em segundo lugar. Um aumento de citação não pode ser atribuído ao llms.txt apenas porque ambos ocorreram após a publicação.

Monitore quatro camadas:

• Disponibilidade: status de resposta da URL raiz, comportamento de redirecionamento, tipo de conteúdo, codificação, latência, independência de renderização e tempo de atividade.
• Integridade: sucesso de análise, seções obrigatórias, URLs duplicadas, links quebrados, alvos de redirecionamento, incompatibilidade canônica, domínios não autorizados, segredos expostos e alterações de hash de conteúdo.
• Atualização: dias desde a verificação substantiva, mudanças de destino desde a verificação, cobertura do registro de origem, confirmação do proprietário e tempo para reparar deriva.
• Resultados: buscas no log do servidor por agentes identificáveis onde legal e tecnicamente apropriado, visitas a destinos indexados, citações de IA de páginas canônicas preferidas e precisão de respostas para perguntas monitoradas de marca ou produto.

Estabeleça uma linha de base antes da implantação: quais URLs são citadas, quais fatos são declarados incorretamente, se o arquivo raiz existe e quais crawlers o solicitam. Anote a publicação e cada atualização material. Compare janelas de observação longas o suficiente para evitar ler uma única busca ou citação como tendência e mantenha a distinção entre correlação e causalidade.

Teste os modos de falha diretamente. Renomeie uma cópia de teste de uma URL listada e confirme que o validador detecta a quebra. Altere um mapeamento canônico e confirme que o gerador atualiza o índice. Desabilite uma capacidade em um ambiente de teste controlado e confirme que a verificação do manifesto falha. Esses testes provam o sistema de manutenção, não a adoção externa.

Use como medimos resultados para separar disponibilidade técnica, representação em máquina, descoberta, citação, engajamento e resultados de negócio. No AmICited, revise o arquivo ativo em Acessibilidade de Agente e use o relatório Cockpit para observar URLs citadas e visibilidade de IA junto com anotações de implantação. A afirmação de sucesso crível é “o arquivo é válido, atual e direciona sistemas para as fontes pretendidas”; qualquer mudança de visibilidade downstream requer evidências separadas.

FAQ

Perguntas frequentes