Um cliente me ligou em outubro passado, em pânico. Seu site de e-commerce estava recebendo uma tonelada de tráfego que sua análise mostrava como visitas "diretas", mas as conversões tinham caído. Depois de cavar nos logs do servidor por cerca de uma hora, percebi que uma parte significativa daquele tráfego não era humana em absoluto. Eram agentes de IA, especificamente assistentes de compra e ferramentas de comparação com LLM, rastreando suas páginas de produtos e saindo porque não conseguiam analisar o conteúdo adequadamente. Os dados estruturados eram uma bagunça. Os preços estavam enterrados em JavaScript. Os nomes dos produtos viviam em tags <h3> estilizadas para parecer <h2>s. Os agentes chegavam, encontravam ruído e saíam.
É aqui que estamos agora. Agentes de IA não estão chegando. Eles já estão aqui, já lendo seus sites, já tomando decisões com base no que conseguem ou não extrair. E a maioria dos mais de 12 mil sites que construí ou toquei ao longo dos anos na Seahawk Media não foi construída com isso em mente. Nem foram os seus, provavelmente.
O Que "Legível por Agentes" Realmente Significa
Deixe-me ser direto sobre algo. Legível por agentes não significa "amigável para IA" no sentido vago de marketing. Significa que uma máquina pode chegar a uma URL, analisar o conteúdo sem executar três camadas de JavaScript, extrair o que está procurando e agir com base nisso. É só isso.
Humanos são indulgentes. Nós varremos. Nós inferimos. Vemos um número grande em uma página de precificação e sabemos que é o preço mesmo que esteja envolvido em uma <div class="fancy-number">. Um agente de IA seguindo um fluxo de trabalho estruturado? Nem tanto. Ele precisa de sinais, hierarquia e previsibilidade.
Os agentes fazendo esse trabalho agora incluem coisas como a ferramenta de navegação do OpenAI, o modo online do Perplexity, e dezenas de agentes customizados sendo construídos com frameworks como LangChain e AutoGen. Todos compartilham uma necessidade comum: HTML limpo, parseável, semanticamente significativo com dados estruturados de suporte.
O Problema Real: Arquitetura JavaScript-First
Esse é o que vejo com mais frequência. Agências e freelancers constroem sites em React ou Next.js (ou Vue, ou Svelte, tudo bem), fazem renderização do lado do cliente, e consideram o trabalho feito. O site fica bonito. O Google consegue rastreá-lo, mais ou menos, porque o Googlebot tem um renderizador headless Chrome embutido agora.
Mas a maioria dos agentes de IA não está rodando headless Chrome. Estão buscando HTML bruto via HTTP. Se seu conteúdo existe apenas depois que o JavaScript é executado, esses agentes recebem uma página em branco ou um spinner de carregamento serializado como texto.
Lá em 2022 Seahawk tinha um cliente de fintech que havia construído toda a seção de taxas e comparação de produtos em uma SPA React. Sem SSR, sem fallback estático. Rodamos um simples curl contra sua URL e recebemos literalmente 14 linhas de HTML: um <div id="root"> e algumas tags de script. É isso que um agente vê. Quatorze linhas.
A solução não é necessariamente abandonar seu framework JS. É renderização do lado do servidor (SSR) ou geração de site estático (SSG). Next.js com getServerSideProps ou getStaticProps. Nuxt para Vue. SvelteKit. Até mesmo apenas pré-renderizar páginas-chave com algo como Prerender.io se você estiver preso em um setup legado. O conteúdo precisa estar no payload HTML inicial.
HTML Semântico Não É Mais Opcional
Eu sei. Você ouve "use HTML semântico" desde 2009. Mas não estou dizendo isso por razões de SEO agora. Estou dizendo porque agentes usam tags semânticas para entender que tipo de coisa eles estão vendo.
<article>, <nav>, <main>, <aside>, <header>, <footer>, esses não são decorativos. São sinais. Um agente tentando extrair o conteúdo principal de uma página vai procurar por <main> primeiro. Se você construiu seu layout com <div>s aninhados e nada mais, o agente tem que adivinhar. Agentes que adivinham mal retornam respostas erradas aos usuários.
Aqui está o que faço auditoria em cada site agora:
- Existe exatamente um elemento <main> por página?
- Os títulos seguem uma hierarquia lógica (<h1> para <h2> para <h3>) sem pular níveis?
- Os menus de navegação estão em elementos <nav>?
- O conteúdo suplementar (barras laterais, posts relacionados) está em <aside>?
- Listas de itens são realmente <ul> ou <ol>, não uma sequência de <div class="item">?
Parecem coisas básicas. Mas eu diria que 60% dos sites WordPress que reviso falham em pelo menos três delas. A da hierarquia de títulos é quase universal — designers estilizam <h3>s para parecer grande e <h2>s para parecer pequeno e ninguém corrige o markup por baixo.
Schema Markup: Faça o Trabalho de Verdade Aqui
É aqui que a maioria dos guias fica genérica. Vou tentar não fazer isso.
Dados estruturados do Schema.org dizem aos agentes não apenas o que está na página, mas qual tipo de coisa é. Um produto. Uma receita. Um negócio local. Uma FAQ. Um evento. E passa esses dados em um formato que os agentes conseguem consumir sem fazer parsing de texto.
Os tipos que mais importam agora, na minha experiência:
- Produto (com ofertas, preço, disponibilidade, os três sempre)
- LocalBusiness (com openingHoursSpecification e coordenadas geográficas, não apenas uma string de endereço)
- Article (com datePublished, dateModified e author como tipo Person, não uma string simples)
- FAQPage (mais sobre isso abaixo)
- BreadcrumbList (subestimado, fornece aos agentes um mapa da hierarquia do seu site)
- HowTo (se você publica tutoriais ou documentação de processos)
Para sites WordPress uso Yoast SEO ou Rank Math para o básico, depois estendo manualmente com schema customizado em um bloco <script type="application/ld+json"> para qualquer coisa que eles não cobrem. JSON-LD é o formato a usar. Não RDFa, não microdata. JSON-LD. Mantém a marcação limpa e os agentes conseguem extrair sem tocar na sua camada de apresentação.
Um erro que cometi em 2021: coloquei schema nas páginas de produto de um cliente, mas deixei o campo price vazio porque os preços eram "consulte para orçamento." O validador de schema passou. Mas agentes estavam extraindo um preço em branco e retornando para usuários como "preço: desconhecido," o que destruiu a confiança. A solução foi ou incluir uma faixa de preço realista com minPrice / maxPrice, ou remover o bloco offers completamente. Dados parciais podem ser piores que nenhum dado.
Estrutura de Conteúdo: Escreva para Extração Escaneável
Aqui está a coisa sobre como agentes leem prosa. Eles não leem do jeito que você lê. Estão procurando respostas para perguntas, fatos que podem ser extraídos, e relacionamentos claros entre as afirmações.
Isso significa que sua estrutura de conteúdo deve colocar a resposta em primeiro lugar. Se alguém (ou algo) pergunta "quanto tempo leva a entrega?", sua página deve ter um heading que diga algo como "Prazos de Entrega" e a primeira frase abaixo dele deve informar o número real. Não um parágrafo de contexto sobre suas operações de armazém. O número primeiro, depois o contexto.
Comecei a estruturar conteúdo assim em sites de clientes, quase como uma pirâmide invertida para cada subseção:
- Declare o fato ou a resposta diretamente na primeira frase sob o heading
- Adicione uma ou duas frases de contexto de suporte
- Vincule a um recurso mais aprofundado se o tópico justificar
Pronto. Sem parágrafos de aquecimento. Sem "ótima pergunta, vamos explorar este tópico juntos". Agentes pulam esse ruído e às vezes identificam incorretamente onde a resposta real começa.
Em um site de viagens que reconstruímos na primavera passada, reestruturamos 80 artigos dessa forma em cerca de seis semanas. As citações do Perplexity para essas páginas aumentaram notavelmente. Mais importante, as respostas para as quais essas citações apontavam eram realmente precisas, porque o fato relevante era encontrável.
Robots.txt, llms.txt, e Controle de Acesso
Este é mais novo. Há uma convenção crescente, ainda não um padrão, para um arquivo chamado llms.txt colocado na raiz do seu domínio. A ideia, proposta por Jeremy Howard, é fornecer aos LLMs um mapa de texto simples do conteúdo mais importante do seu site e qualquer preferência de acesso. Pense nela como um robots.txt mas escrito em inglês simples para agentes de modelo de linguagem em vez de bots de rastreamento.
Você deve implementar? Honestamente, sim. Leva 20 minutos para escrever um. Sinaliza que seu site é consciente de agentes, e conforme mais agentes são treinados para procurá-lo, se tornará um sinal significativo.
Sobre robots.txt especificamente: seja deliberado. Alguns proprietários de sites estão reflexivamente bloqueando todos os crawlers de IA agora. Essa é sua decisão, mas bloquear indiscriminadamente significa que seu conteúdo também não aparecerá em respostas geradas por IA, que é um canal de distribuição que você está abandonando. Pense nisso da mesma forma que pensou sobre bloquear o Googlebot em 2005. Provavelmente não é uma boa ideia.
Linkagem Interna e Arquitetura de Rastreamento
Um agente seguindo um workflow não pousa apenas em uma página. Ele segue links. A qualidade da sua estrutura de linkagem interna determina quanto do seu site um agente consegue realmente percorrer e entender.
Linkagem interna fraca significa que agentes indexam uma ou duas páginas do seu site e param. Eles não conseguem ter a visão completa do que você oferece.
Linkagem interna boa significa:
- Toda página importante é alcançável em até três cliques a partir da homepage
- O texto âncora é descritivo, não "clique aqui" ou "leia mais"
- Conteúdo relacionado é vinculado contextualmente no corpo, não apenas em um widget sidebar
- Páginas órfãs não existem (ou se existem, você sabe disso e escolheu deixá-las assim)
Faço crawls com Screaming Frog nos sites de clientes antes de qualquer trabalho de legibilidade por agentes. O relatório de páginas órfãs sozinho geralmente revela conteúdo que clientes acham que foi publicado e é encontrável, mas não é. Um cliente tinha 34 páginas órfãs, incluindo seus principais estudos de caso. Ninguém estava vinculando a elas. Nem agentes, nem humanos.
FAQ
Preciso reestruturar meu site inteiro para ser legível por agentes?
Não. Comece pelas suas páginas com mais tráfego e pelas páginas críticas para conversão. Geralmente é sua homepage, páginas principais de serviços ou produtos, e qualquer conteúdo que está ranqueando atualmente e gerando leads. Acerte essas primeiro. Uma auditoria completa do site é útil eventualmente, mas não é por onde você começa.
Marcação de schema realmente ajuda nas respostas de agentes de IA?
Pelo que observei em sites de clientes, sim. Agentes que extraem dados estruturados retornam respostas mais precisas e atribuem fontes com mais confiabilidade quando schema está presente. Dito isso, não é uma solução mágica. O conteúdo subjacente ainda precisa ser preciso e bem estruturado. Schema ajuda agentes a encontrar e confiar nos dados; não corrige dados ruins.
E quanto a sites com conteúdo pago?
Use a propriedade de schema isAccessibleForFree no seu tipo Article, e o padrão hasPart / isPartOf para marcar quais seções são pagas. Isso diz aos agentes o que eles podem usar. A documentação do Google sobre dados estruturados de conteúdo pago cobre isso claramente, e a mesma lógica se aplica a agentes fora do Google.
llms.txt é amplamente suportado já?
Não universalmente. Mas custa quase nada para implementar, e a adoção antecipada de convenções como essa tende a compensar. Adicionei a sites de clientes Seahawk desde o início de 2024. É um sinal pequeno agora. Vai importar mais em 12 meses.
Como testo se um agente consegue ler meu site?
Comece com curl -A "Mozilla/5.0" [sua URL] em um terminal e veja o que volta. Se seu conteúdo principal não estiver nesse resultado, você tem um problema de renderização. Depois execute suas páginas pelo Rich Results Test do Google para validação de schema. E verifique o audit de acessibilidade Chrome Lighthouse, porque legibilidade para agentes e acessibilidade se sobrepõem muito mais do que a maioria das pessoas percebe.
---
A web foi construída para humanos e depois adaptada para mecanismos de busca. Agora precisa de outra adaptação, dessa vez para agentes que não navegam do jeito que nenhum humano faz. Isso não é uma crise. É só a próxima rodada de trabalho. E honestamente, a maioria disso é boa prática que torna os sites melhores para humanos também. Marcação mais limpa, conteúdo mais claro, menos espalhamento de JavaScript. Você provavelmente deveria ter feito isso mesmo assim.