Como implementar LLMs.txt para agentes: guia completo para WordPress, Wix, Webflow e personalizado

O Google tacou fogo no parquinho na hora em que postou uma atualização recente do Lighthouse – especificamente colocando o LLM.txt como um padrão para operação de agentes. E quem me conhece sabe que eu desdenhei do LLM.txt desde, basicamente, o seu lançamento. O que eu não previ era como ele seria adaptado pela plataforma.

Para você desenrolar esse fio de Ariadne, além de explicar o que é e como usar eu vou te dar um cadinho de contexto para você entender como o LLM.txt evoluiu de uma proposta para uma medida extraoficial e o que a história nos ensina sobre como esses processos vão avançar daqui para a frente.

Origem do LLM.txt

O LLMs.txt foi proposto por Jeremy Howard — cofundador da fast.ai e figurão na comunidade de machine learning prática — em setembro de 2024.

A ideia nasceu de uma observação simples: os sites da web são construídos para humanos, cheios de navegação, CSS, scripts e elementos visuais que não têm nenhuma utilidade para um modelo de linguagem que precisa extrair informação de forma eficiente. Howard propôs uma convenção análoga ao robots.txt: um arquivo em /llms.txt que apresentasse o conteúdo essencial do site em Markdown limpo, fácil de consumir por LLMs.

A proposta original estava focada em facilitar o consumo de conteúdo por modelos durante inferência — ou seja, quando alguém usa um LLM com acesso à web e ele precisa entender rapidamente o que um site oferece. Não era sobre treinamento de modelos.

A ferramenta foi integrada aos poucos nas principais plataformas do mercado:

O que aconteceu depois é que o conceito foi sendo ressignificado e expandido conforme o ecossistema evoluiu. Com a ascensão dos agentes de IA em 2025 e 2026, o arquivo ganhou uma segunda camada de utilidade: além de descrever o conteúdo, ele passou a ser usado para declarar pontos de entrada para ação — formulários, APIs, MCPs — o que é exatamente o uso que o Wix, o Google Lighthouse e os kits de desenvolvimento de agentes estão validando agora.

Em uma linha do tempo ficaria mais ou menos assim:

• Set/2024 — Jeremy Howard publica a proposta em llmstxt.org;
• Final de 2024/2025 — Adoção orgânica por sites de documentação técnica e ferramentas de IA;
• (é nessa meiuca que os GEO bros atacam)
• 2025/2026 — O foco migra de “conteúdo legível por LLMs” para “infraestrutura operacional para agentes”;
• Mai/2026 — Google IO confirma como ponto de auditoria no Lighthouse; Wix ativa globalmente com suporte a MCP.

O LLMs.txt não é para treinar modelos — é para agentes

Antes de qualquer instrução técnica, é preciso entender o ponto mais importante e mais frequentemente mal interpretado sobre o LLMs.txt: ele não é um arquivo de dados para treinar modelos de linguagem. Ele não orienta ou aumenta as chances do seu conteúdo ranquear em IAs, o que já cansou de ser provado e corroborado em experimentos da comunidade.

Ele é um arquivo de instrução para agentes de IA que operam em tempo real, tomando ações em nome de usuários.

A distinção importa porque muda completamente o que você deve colocar no arquivo e como você deve estruturá-lo. Um LLMs.txt pensado para treinamento seria um arquivo descritivo, cheio de contexto e conteúdo. Um LLMs.txt pensado para ranquear é só firula de quem quer vender GEO. Um LLMs.txt pensado para agentes é um arquivo operacional: ele declara o que o site oferece, como ele está organizado, quais são os pontos de entrada relevantes para ação e, quando disponível, como um agente pode interagir com o site via MCP ou API.

O Google IO confirmou recentemente o LLMs.txt como ponto de auditoria no Lighthouse Agentic Browsing Report. A documentação do Lighthouse é direta: sem o arquivo, agentes podem gastar mais tempo rastreando o site para entender sua estrutura e conteúdo principal. Com ele, o agente tem um ponto de entrada leve — em média 9,8 KB, cerca de 275 vezes menor que uma página web comum — que concentra as informações operacionais essenciais.

Quando uma convenção técnica deixa de ser curiosidade e vira infraestrutura

Tecnologias de infraestrutura raramente nascem como consenso. Em geral, elas começam como propostas simples, quase modestas, criadas para resolver uma dor específica de um grupo pequeno de desenvolvedores, pesquisadores ou operadores técnicos. O robots.txt, por exemplo, não nasceu como uma lei universal da web, mas como uma convenção voluntária para orientar crawlers sobre o que poderiam ou não acessar. O sitemap também seguiu um caminho parecido: primeiro apareceu como uma forma prática de ajudar buscadores a encontrar URLs com mais eficiência; depois foi incorporado por ferramentas, CMSs, plugins de SEO e plataformas de auditoria até se tornar parte do vocabulário básico de qualquer implementação técnica minimamente séria.

O mesmo tipo de trajetória pode ser observado em tecnologias como Schema.org, Open Graph e até AMP, cada uma com destinos diferentes. Todas começaram como camadas auxiliares: um vocabulário semântico para estruturar entidades, uma marcação para controlar previews sociais, um formato para acelerar páginas móveis. O momentum não veio apenas da elegância da ideia, mas da combinação entre adoção por ferramentas, validação por plataformas dominantes e incorporação em rotinas de auditoria. Quando uma tecnologia passa a aparecer em plugins, checklists, relatórios automatizados, documentações oficiais e painéis de diagnóstico, ela deixa de depender apenas da convicção dos early adopters. Ela vira parte do repertório esperado.

É nesse ponto que o LLMs.txt parece estar entrando agora. A proposta inicial podia ser vista como experimental, redundante ou até ingênua quando pensada apenas como “um Markdown para LLMs lerem melhor um site”. Mas, quando Wix, Shopify, plugins de SEO, kits de agentes e o próprio Lighthouse passam a tratá-lo como ponto de descoberta, auditoria ou integração, a pergunta deixa de ser “isso ranqueia em IA?” e passa a ser “meu site está preparado para ser compreendido e operado por agentes?”. Esse é o momento em que uma convenção técnica muda de estatuto: ela não precisa mais provar que é revolucionária; basta passar a ser esperada.

O que um bom LLMs.txt para agentes contém

Vamos lá: como vocês acabaram de ver, estamos na fase experimental. Convenções, normas e muito mais ainda será discutido com o passar do tempo. Algumas coisas que são basilares no modelo proposto por Howard são, porém, conhecidos, e compreendem as seguintes seções:

• Descrição geral do site e seu propósito principal;
• Lista das seções ou áreas de conteúdo mais relevantes, com URLs;
• Pontos de entrada para ação: formulários, APIs públicas, MCPs disponíveis;
• Instruções de uso para agentes, se houver restrições ou preferências;
• Informações de contato ou suporte, quando relevante para tarefas agênticas.

Um LLMs.txt bem estruturado para agentes pode se parecer com o seguinte exemplo:

# Título (exemplo: Dentista de Primeira)
> Descrição opcional do site (exemplo: site do Dentista de Primeiro localizado na avenida 124 catimbó)
Detalhes opcionais (exemplo: ganhador do prêmio sorriso beleza)
## Section name (exemplo: agendamento)
- [Link title](https://link_url): Optional link details (exemplo: [Contato] (/contato): Link de agendamento de consultas)
## Optional (exemplo: especializações)
- [Link title](https://link_url) (exemplo: [Especializações do Dentista de Primeira](/especializacoes))

Estrutura básica do arquivo

O arquivo deve ser salvo como llms.txt na raiz do domínio — acessível em seusite.com.br/llms.txt — e deve seguir a sintaxe Markdown, com cabeçalhos em H1 para o nome do site, H2 para seções principais e listas simples para os itens de cada seção.

Implementação no WordPress

O WordPress não gera o LLMs.txt automaticamente, mas a implementação pode ser feita de três formas diferentes, dependendo do nível técnico e do controle desejado.

A forma mais simples é criar o arquivo manualmente via FTP ou gerenciador de arquivos da hospedagem. Acesse a raiz do seu domínio — geralmente a pasta public_html — e crie um arquivo chamado llms.txt com o conteúdo estruturado. Essa abordagem funciona bem, mas exige atualização manual sempre que a estrutura do site mudar.

A segunda opção é usar um plugin de criação de arquivos virtuais. Plugins como Yoast SEO ou Rank Math já gerenciam arquivos como robots.txt e sitemaps via interface administrativa. Atualmente, alguns deles começaram a oferecer suporte experimental ao LLMs.txt ou permitem adicionar arquivos de texto na raiz via configuração. Verifique a versão mais recente do plugin que você usa para checar essa disponibilidade.

A terceira opção, mais robusta, é gerar o LLMs.txt dinamicamente via functions.php ou via um plugin personalizado. Esse método permite que o conteúdo do arquivo seja gerado com base no conteúdo atual do site — taxonomias, páginas principais, endpoints de API registrados — garantindo que o arquivo esteja sempre atualizado.

Uma alternativa mais avançada é gerar o LLMs.txt dinamicamente via código, usando o functions.php do tema ou, preferencialmente, um plugin personalizado. Essa abordagem exige conhecimento técnico de WordPress, porque envolve criar uma regra de rewrite para interceptar a URL /llms.txt, gerar uma resposta em texto puro e montar o conteúdo do arquivo a partir das informações atuais do site, como páginas principais, categorias, tipos de post, produtos, APIs ou endpoints de MCP.

A vantagem desse método é que o arquivo pode se manter atualizado automaticamente conforme o site muda. Em vez de editar manualmente o llms.txt sempre que uma nova seção, página ou endpoint for criado, o próprio WordPress pode gerar a lista com base na estrutura real do site. Por outro lado, essa implementação deve ser feita com cuidado para não causar conflito com plugins de cache, plugins de SEO, regras de redirecionamento ou arquivos estáticos já existentes na raiz do domínio.

Para sites WordPress com WooCommerce, essa geração dinâmica pode incluir pontos úteis para agentes de compra, como a página da loja, categorias de produto, busca interna, página de carrinho, checkout e, quando existirem, APIs públicas ou MCPs de comércio eletrônico. Nesse caso, o LLMs.txt deixa de ser apenas uma lista de URLs importantes e passa a funcionar como um mapa operacional para agentes entenderem onde consultar produtos, iniciar fluxos de compra ou localizar informações comerciais relevantes.

Implementação no Wix

Se o seu site está no Wix com um plano premium e domínio personalizado, você não precisa fazer nada. O Wix ativou a geração automática do LLMs.txt para todos os sites que se enquadram nesse perfil, em escala global.

Mais do que isso: o LLMs.txt gerado pelo Wix já está configurado com pontos de entrada para o MCP integrado à plataforma, o que significa que agentes compatíveis podem interagir com o site de forma estruturada sem precisar rastrear cada página individualmente.

Para verificar se o seu site já possui o arquivo, acesse seusite.com/llms.txt diretamente no navegador. Se o arquivo existir, você verá o conteúdo estruturado. Se quiser personalizar as informações apresentadas, consulte a central de ajuda do Wix para ver as opções de configuração disponíveis no painel administrativo.

Implementação no Webflow

O Webflow permite adicionar arquivos na raiz do projeto via a aba de configurações de hospedagem, na seção de arquivos estáticos. Você pode fazer o upload de um arquivo llms.txt diretamente pelo painel.

A limitação dessa abordagem é que o arquivo será estático — ou seja, não se atualiza automaticamente quando você adicionar novas páginas ou seções ao site. Por isso, é recomendável estabelecer um processo de revisão periódica do arquivo, idealmente toda vez que a estrutura de navegação do site mudar significativamente.

Para projetos Webflow que utilizam o CMS, vale mapear as coleções principais no LLMs.txt — por exemplo, as coleções de Blog, Projetos e Clientes — com seus respectivos slugs de listagem, para que agentes possam identificar rapidamente onde encontrar cada tipo de conteúdo.

Implementação em sites customizados

Para sites desenvolvidos com frameworks próprios — Next.js, Nuxt, Laravel, Django ou qualquer outro stack — a implementação do LLMs.txt é direta: crie uma rota que retorne o arquivo de texto na URL /llms.txt.

Em Next.js, por exemplo, você pode criar um arquivo em /public/llms.txt para servir o conteúdo estático, ou criar uma API route em /pages/api/llms.txt.js para servir o conteúdo gerado dinamicamente.

A vantagem da implementação customizada é a possibilidade de gerar o arquivo com base em dados reais do sistema — incluindo as rotas de API disponíveis, os endpoints de MCP registrados e os recursos mais acessados — com total controle sobre a frequência de atualização.

Configurando pontos de acesso agênticos

Este é o passo que diferencia um LLMs.txt vendido por tech bro de um LLMs.txt realmente preparado para o ecossistema agêntico. Pontos de acesso agênticos são as entradas que permitem a um agente interagir com o seu site de uma forma estruturada.

Se o seu site expõe uma API REST pública, liste os endpoints mais relevantes para tarefas agênticas — busca, consulta de conteúdo, envio de formulários autenticados. Inclua o link para a documentação da API, se ela for pública.

Se o seu site implementa um MCP — seja via Wix, via um plugin WordPress compatível, ou via implementação própria —, declare o endpoint do MCP no LLMs.txt. Isso permite que agentes compatíveis descubram e utilizem as ferramentas disponíveis sem precisar adivinhar a estrutura da interface.

Se o seu site não expõe API nem MCP, os pontos de acesso mais relevantes a declarar são os formulários principais — contato, cadastro, pesquisa — com as URLs exatas onde eles se encontram.

Na prática, um LLMs.txt preparado para agentes não precisa apenas listar as páginas principais do site. Ele pode funcionar como um mapa operacional, indicando quais URLs servem para leitura, quais permitem busca, quais conduzem a ações e quais endpoints estruturados estão disponíveis para agentes compatíveis. No exemplo abaixo ficaria mais ou menos assim em linguagem natural:

# Exemplo Site
Site institucional e comercial da Exemplo Site, empresa especializada em serviços de consultoria, conteúdo técnico e venda de produtos digitais.
## Conteúdo principal
- Página inicial: https://www.exemplosite.com.br/
- Blog: https://www.exemplosite.com.br/blog/
- Serviços: https://www.exemplosite.com.br/servicos/
- Produtos digitais: https://www.exemplosite.com.br/produtos/
- Central de ajuda: https://www.exemplosite.com.br/ajuda/
## Pontos de acesso para agentes
Esta seção lista os pontos de entrada que agentes de IA podem usar para consultar informações, executar tarefas ou orientar usuários dentro do site.
### Busca interna
Agentes podem usar a busca interna do site para localizar conteúdos, produtos ou páginas específicas.
- Interface de busca: https://www.exemplosite.com.br/?s=
- Endpoint de busca pública: https://www.exemplosite.com.br/wp-json/wp/v2/search
### Conteúdo via API
Agentes podem consultar conteúdos públicos publicados no site por meio da API REST do WordPress.
- Posts do blog: https://www.exemplosite.com.br/wp-json/wp/v2/posts
- Páginas institucionais: https://www.exemplosite.com.br/wp-json/wp/v2/pages
- Categorias: https://www.exemplosite.com.br/wp-json/wp/v2/categories
### Produtos
Agentes podem orientar usuários para páginas de catálogo, categorias de produto e fluxo de compra.
- Catálogo de produtos: https://www.exemplosite.com.br/loja/
- Categorias de produto: https://www.exemplosite.com.br/categoria-produto/
- Carrinho: https://www.exemplosite.com.br/carrinho/
- Checkout: https://www.exemplosite.com.br/finalizar-compra/
### Formulários
Agentes podem direcionar usuários para os formulários públicos abaixo. O envio automatizado só deve ocorrer quando o usuário solicitar explicitamente a ação.
- Formulário de contato: https://www.exemplosite.com.br/contato/
- Solicitação de orçamento: https://www.exemplosite.com.br/orcamento/
- Cadastro de newsletter: https://www.exemplosite.com.br/newsletter/
### MCP
Este site expõe ferramentas estruturadas para agentes compatíveis com MCP.
- Endpoint MCP: https://www.exemplosite.com.br/mcp/
- Documentação do MCP: https://www.exemplosite.com.br/docs/mcp/
- Ferramentas disponíveis:
  - Buscar conteúdos publicados no site
  - Consultar produtos e categorias
  - Enviar solicitação de orçamento autenticada
  - Verificar disponibilidade de serviços
## Instruções para agentes
- Agentes podem consultar livremente páginas públicas, posts, categorias e produtos.
- Agentes não devem enviar formulários sem confirmação explícita do usuário.
- Ações que envolvam dados pessoais, orçamento, compra ou cadastro exigem consentimento do usuário.
- Endpoints autenticados exigem chave de API.
- Para dúvidas sobre uso automatizado, consulte: https://www.exemplosite.com.br/politica-para-agentes/
## Contato técnico
- Suporte: https://www.exemplosite.com.br/suporte/
- E-mail técnico: suporte@exemplosite.com.br

A diferença é sutil, mas importante. Um LLMs.txt comum diz ao agente “estas são as páginas importantes do meu site”. Um LLMs.txt agêntico diz algo mais completo: “estas são as áreas importantes, estes são os pontos de consulta, estes são os fluxos de ação e estas são as regras para interagir com eles”. É essa camada operacional que torna o arquivo relevante no contexto de agentes, MCPs e navegação automatizada.

WebMCP e LLMs.txt: mapa e ferramenta não são a mesma coisa

A chegada do WebMCP ajuda a esclarecer um ponto importante: o LLMs.txt não precisa fazer tudo sozinho. Ele não é, por si só, a ferramenta que permite a um agente preencher um formulário, acionar uma busca, selecionar uma data ou executar uma compra. O papel dele é mais parecido com o de um mapa de entrada. Ele informa ao agente quais áreas do site existem, quais URLs são relevantes, onde estão os pontos de ação e, quando aplicável, onde ferramentas estruturadas podem ser encontradas.

O WebMCP entra em outra camada. Enquanto o LLMs.txt aponta para o formulário de orçamento, para o checkout, para a busca interna ou para a área de suporte, o WebMCP descreve como um agente pode interagir com esses elementos de maneira estruturada. Em vez de o agente tentar “adivinhar” como preencher uma interface visual feita para humanos, a página pode declarar ferramentas, entradas, saídas, ações permitidas e regras de confirmação. É a diferença entre dizer “o formulário está aqui” e dizer “este formulário aceita nome, e-mail, telefone, tipo de serviço e só pode ser enviado depois de confirmação explícita do usuário”.

Essa distinção é essencial para não transformar o LLMs.txt em mais uma promessa inflada de GEO. O arquivo não precisa carregar toda a lógica operacional do site. Ele deve indicar os caminhos relevantes para agentes. A execução, porém, acontece nos pontos de ação: formulários, APIs, checkouts, buscas internas, MCPs e interfaces anotadas. Em outras palavras, o LLMs.txt organiza a descoberta; o WebMCP estrutura a interação.

Na prática, a relação entre os dois pode ser pensada assim: o LLMs.txt diz ao agente “estas são as áreas do site que importam e estes são os pontos onde você pode agir”; o WebMCP diz “quando estiver nesta página, estas são as ações disponíveis, estes são os campos esperados e estas são as regras para executar a tarefa com segurança”. Por isso, o avanço do WebMCP não torna o LLMs.txt obsoleto. Pelo contrário: ele reforça o papel do arquivo como camada inicial de orientação em uma web que começa a ser navegada não apenas por pessoas e crawlers, mas também por agentes capazes de executar tarefas.

Boas práticas de manutenção

O LLMs.txt não é um arquivo que se cria uma vez e esquece. À medida que o site cresce e muda, o arquivo deve refletir essas mudanças. Algumas práticas que ajudam a manter o arquivo útil ao longo do tempo:

1. Revise o arquivo sempre que uma nova seção principal for adicionada ao site.
2. Verifique se os URLs listados ainda respondem corretamente — links quebrados em um LLMs.txt prejudicam diretamente a capacidade do agente de navegar pelo site.
3. Atualize a lista de ferramentas e APIs disponíveis sempre que novos endpoints forem publicados ou descontinuados.

Com o Lighthouse do Google agora auditando o LLMs.txt como parte do relatório de navegação agêntica, manter o arquivo atualizado passa a ter implicações mensuráveis na avaliação técnica do site — não apenas uma questão de boas práticas.

Dúvidas comuns sobre llms.txt