Introdução
Em junho de 2026 a mesma pergunta volta a surgir nas timelines de engenharia e nos canais de SEO: como deve servir o seu conteúdo aos agentes de IA? Markdown simples, porque parece ser o que os modelos gostam? Um endpoint de máquina à parte? Um novo formato de conhecimento? A discussão é barulhenta, é carregada de opiniões, e na sua maioria fala sem se entender.
Aqui fica a posição do profissional à cabeça, porque temos algo em jogo nisto. Já servimos HTML semântico, limpo e renderizado no servidor mais Schema.org a partir de um frontend em Astro sobre a Cloudflare. Este debate confirma essa escolha. Não a ameaça. Quase todos os argumentos do tipo “tem de mudar para Markdown para os agentes” desmoronam-se no momento em que separa três camadas que são constantemente amassadas numa só.
Isto não é comentário das bancadas. No mercado de língua portuguesa, onde muitas equipas chegam à IA depois de anos de SEO clássico, operamos exatamente a infraestrutura de que o debate trata, e já operamos a camada de agentes que o debate aponta repetidamente como o verdadeiro futuro. Portanto, isto é um relato de dentro, não um resumo a partir dos lugares mais baratos.
Conclusões principais num relance
- O argumento confunde três camadas que não são o mesmo problema: Markdown como saída do agente, Markdown como forma de servir páginas, e OKF como camada de conhecimento.
- Markdown como saída do agente é uma decisão de apresentação de máquina para pessoa, e uma das pessoas que mais o impulsionou acabou de o abandonar a favor do HTML.
- Servir Markdown aos bots no mesmo URL onde as pessoas recebem HTML é, na melhor das hipóteses, redundante e, na pior, cloaking. A Google e a Bing disseram-no ambas, sem rodeios.
- O OKF é um formato de conhecimento curado para pipelines de agentes, não um formato de entrega de sites. É uma camada diferente do SEO.
- O único sinal de entrega que tanto a Google como a Bing documentam como realmente consumido é o HTML semântico limpo mais Schema.
- Observe, não se precipite a implementar, os novos formatos de entrega. A verdadeira aposta de futuro é a camada de ação do agente, e essa parte já a construímos.
Três camadas que toda a gente confunde
Quase todo o calor deste debate vem de tratar três perguntas separadas como uma só. Separe-as e as contradições dissolvem-se.
Camada 1: Markdown como saída do agente
Isto trata daquilo que um modelo devolve a uma pessoa, não de como um site é servido. Quando um agente gera um relatório, uma resposta de chat ou um documento, em que formato deve emiti-lo?
Durante muito tempo a resposta por predefinição foi Markdown. É limpo, é barato em tokens, apresenta-se bem numa bolha de chat. Depois Thariq Shihipar, que trabalha no Claude Code na Anthropic, retratou-se publicamente. Depois de construir exemplos lado a lado a comparar a eficácia de HTML e Markdown, a sua conclusão foi que o HTML ganha para a saída do agente, porque o HTML transporta a estrutura, a semântica e a interatividade que uma superfície mais rica orientada a pessoas necessita. O Markdown achata demasiado.
Leia isso com atenção, porque é rotineiramente citado ao contrário. A pessoa mais próxima da saída do agente está a mover-se para o HTML, não a afastar-se dele. E, o que é decisivo, esta camada nada diz sobre como deve servir o seu site de marketing a um rastreador. É comunicação de máquina para pessoa. Quem cite Thariq como razão para converter o seu site para Markdown inverteu o argumento dele.
Camada 2: Markdown-for-Agents como entrega de páginas
Esta é a camada que realmente nos toca, porque corremos na Cloudflare. O Markdown-for-Agents da Cloudflare converte o seu HTML em Markdown em tempo real quando um cliente envia Accept: text/markdown, anuncia uma contagem de tokens através de x-markdown-tokens e reporta cerca de 80 por cento de redução de tokens face ao HTML em bruto. Está em beta nos planos pagos, e clientes como o Claude Code e o OpenCode já enviam o cabeçalho. É governado pelo Content-Signal, que na Cloudflare vem ativado por predefinição, pelo que isto pode estar ativo no seu domínio sem uma decisão deliberada. É precisamente esse detalhe do ativado-por-predefinição que todo o cliente da Cloudflare deveria verificar.
A poupança de tokens é real. A alegação de visibilidade não é. Não há provas documentadas de que servir uma representação em Markdown altere se um sistema de IA o cita. E no momento em que serve aos bots uma representação diferente do mesmo URL daquela que as pessoas recebem, está mesmo ao lado da linha do cloaking.
John Mueller da Google disse-o sem diplomacia nenhuma:
“Converting pages to markdown is such a stupid idea. Did you know LLMs can read images? WHY NOT TURN YOUR WHOLE SITE INTO AN IMAGE?”
É sarcasmo com um ponto lá dentro. Se o modelo já consegue ler o seu HTML, um canal Markdown paralelo não é sinal novo, é uma segunda coisa para manter e manter sincronizada. Fabrice Canel da Bing foi mais seco e, sem dúvida, mais demolidor para quem espere poupar orçamento de rastreio:
“Really want to double crawl load? We’ll crawl anyway to check similarity.”
Por outras palavras, o motor de busca vai buscar o HTML de qualquer forma, para verificar se o seu Markdown corresponde ao que as pessoas veem. Não reduz a carga, acrescenta uma superfície que tem de coincidir com a canónica ou é sinalizado. Dois dos maiores operadores de rastreio do planeta disseram-lhe, em público, que isto não faz o que os seus defensores esperam.
Camada 3: OKF como camada de conhecimento
A 12 de junho de 2026 a Google Cloud publicou o Open Knowledge Format, OKF, com um repositório de referência público. É deliberadamente humilde: ficheiros Markdown com frontmatter YAML, um conceito por ficheiro, apenas o campo type obrigatório, produtor e consumidor mantidos independentes. O enquadramento é “um formato, não uma plataforma”, e deve uma dívida evidente ao gist de wiki para LLM de Andrej Karpathy, a ideia de uma base de conhecimento curada por pessoas e escrita para máquinas.
Eis o que importa e o que os resumos não captam: o OKF não é uma forma de servir o seu site. É uma forma de empacotar conhecimento curado para que um pipeline de agentes o possa consumir. Vive a montante da recuperação, na camada de contexto e fundamentação, não no URL onde um rastreador se cruza com a sua página. Como observou Adam Rogala num comentário no LinkedIn ao anúncio, o OKF faz sentido, mas numa camada diferente do SEO. Confundir “a Google lançou um formato de conhecimento em Markdown” com “a Google quer que sirva o seu site como Markdown” é, de longe, o erro mais comum do ciclo atual, e nem de perto são a mesma coisa.
Existe uma versão sensata de Markdown num stack de publicação, e vale a pena nomeá-la para que ninguém entenda isto como anti-Markdown. Markdown no seu código-fonte, renderizado para HTML no momento do build, é exatamente como este artigo está escrito. É o sítio certo para ele. Enviar Markdown em bruto a um navegador, ou a um rastreador que espera HTML, é a parte que não faz sentido. Como sublinhou Bartosz Łaszczewski na mesma discussão, o consumidor do outro lado está construído em torno do HTML, e enviar Markdown em bruto a um navegador vai contra isso.
Porque é que este debate confirma o nosso stack
Separe as três camadas e a conclusão é quase aborrecida, o que é precisamente o ponto. Aquilo que já funciona continua a funcionar.
Servimos HTML semântico renderizado no servidor. Os cabeçalhos são cabeçalhos, as listas são listas, article, nav e time significam o que dizem, e os dados estruturados são Schema.org a sério em vez de decoração. Essa é a representação que a Google indexa, a representação que a Bing rastreia e a representação que um LLM ingere quando vai buscar a página. É também, não por acaso, a representação que se renderiza depressa para as pessoas. Não há bifurcação para manter sincronizada, nem um segundo canal que possa divergir, nem risco de cloaking.
Tudo aquilo que inquieta o debate obtemo-lo de graça por não o perseguirmos. Quando Mueller diz que a conversão para Markdown é inútil porque o modelo lê o seu HTML, isso é uma descrição da nossa configuração a funcionar como pretendido. Quando Canel diz que a Bing rastreia o HTML na mesma, tudo bem, porque o HTML é o artefacto canónico e não há mais nada a reconciliar. Não tivemos de reagir a nenhuma das declarações. A arquitetura já as tinha respondido.
O único sinal documentado
Se quer uma regra que sobreviva ao próximo anúncio de formato, aqui a tem. HTML semântico, renderizado no servidor e limpo com Schema.org válido é a única abordagem de entrega que tanto a Google como a Bing documentam como algo que de facto consomem. Tudo o resto neste terreno é, ou uma proposta sem consumo medido, ou uma otimização do custo em vez da visibilidade.
A Bing, através do Copilot, lê dados estruturados. A Google lê dados estruturados para as suas próprias superfícies. Os grandes modelos de linguagem ingerem o HTML renderizado. Nenhum dos novos formatos de entrega, llms.txt, Markdown-for-Agents, ai.txt, tem um efeito documentado sobre se é citado. Por isso a postura honesta de engenharia é: mantenha o HTML limpo, mantenha o Schema válido, e trate os novos formatos de entrega como algo a observar em vez de implementar. A mesma disciplina aplica-se a uma montagem headless de WooCommerce sobre Astro: os dados de comércio são marcação semântica real, não um canal lateral só para bots.
A opinião honesta sobre o llms.txt
Publicamos /llms.txt e /llms-full.txt, por isso isto é autocrítica, não uma alfinetada barata a outrem. Os céticos têm um argumento forte. Mueller disse que o formato é essencialmente ignorado, e um estudo independente de registos de servidor não encontrou qualquer pedido de rastreadores de IA por llms.txt em centenas de domínios ao longo de vários meses. Como ficheiro isolado deixado num site na esperança de que algo o leia, faz muito pouco.
O nosso próprio manual de visibilidade perante a IA diz exatamente isso, por escrito: nenhum grande fornecedor de LLM se compromete formalmente a ler estes ficheiros, mas eles aparecem nos nossos registos com frequência suficiente para justificar mantê-los. Sustentamos ambas as ideias ao mesmo tempo. Um llms.txt genérico e órfão é quase peso morto. O mesmo ficheiro como um nó de uma configuração integrada de descoberta de agentes, ligado a uma camada de ação real, é um objeto diferente com um perfil de custo e benefício diferente. O erro está em citar os estudos do “ninguém lê o llms.txt” como se tivessem resolvido a questão para toda a implementação. Resolveram-na para o caso do ficheiro avulso.
A verdadeira aposta de futuro: a camada de ação do agente
Aqui rompemos por completo com a malta do “serve só Markdown”, e aqui está o futuro genuinamente interessante. O próximo passo não é um documento melhor para um agente ler. É deixar o agente agir sem ler documento nenhum.
Essa é a camada de ação do agente: WebMCP, Agent2Agent (A2A) e o Model Context Protocol. Em vez de fazer scraping a uma página de serviços e adivinhar, um agente chama uma função, request_quote, browse_services, search_site, e obtém uma resposta tipada. O WebMCP, uma colaboração entre a Google e a Microsoft, está na pré-visualização para programadores do Chrome desde fevereiro de 2026, e aponta diretamente para este modelo: a página expõe capacidades, o agente invoca-as.
Isto já o construímos. Em public/.well-known/ publicamos um AgentCard A2A, uma server-card MCP conforme à SEP-1649, um descritor ACP e negociação de conteúdo em Markdown através de um sufixo de URL .md e do tratamento de Accept: text/markdown no middleware, com tudo isto anunciado através de cabeçalhos Link e regras robots. A capacidade fetch_markdown no nosso AgentCard aponta para /llms-full.txt, que é precisamente a razão pela qual os ficheiros llms não estão órfãos aqui, estão ligados à camada de ação em vez de ficarem sozinhos.
Repare na assimetria. O Markdown-for-Agents e a negociação de conteúdo, os formatos de entrega, tratamo-los como observar-não-implementar, presentes porque a infraestrutura os oferece, não porque tenhamos medido um benefício. A camada de ação tratamo-la como um investimento de futuro deliberado, porque é a direção para onde o argumento do HTML de Thariq, o WebMCP e toda a vaga de ferramentas para agentes apontam. Ler é o presente. Agir é a aposta.
O que estamos de facto a fazer
Para concretizar a postura, aqui fica a divisão.
- Entrega: HTML semântico limpo mais Schema.org, renderizado no servidor, rápido. É a decisão que sustenta tudo e não vai mudar.
- Markdown-for-Agents e Content-Signal: presentes na Cloudflare, deixados ativados onde são inofensivos, mas verificados, porque a predefinição ativada significa que pode estar ligado sem uma decisão. Sem qualquer alegação de visibilidade associada.
- llms.txt e llms-full.txt: publicados, mas como nós ligados do sistema de descoberta de agentes, não como uma aposta autónoma, e descritos com honestidade no nosso próprio manual.
- OKF: arquivado sob camada de conhecimento. Relevante se e quando alimentarmos conhecimento curado num pipeline de agentes. Não é uma alteração de entrega do site.
- Camada de ação do agente, A2A, MCP, adjacente ao WebMCP: investimento deliberado, já em produção em
/.well-known/, e a parte de todo este debate sobre a qual estamos mais confiantes.
Conclusão
O debate de 2026 sobre “HTML contra Markdown para agentes” parece uma bifurcação no caminho. Não é. Assim que separa a saída do agente da entrega de páginas da camada de conhecimento, os três argumentos deixam de se contradizer e todos apontam na mesma direção. Sirva HTML semântico limpo e Schema válido, porque é o único sinal cujo consumo ambos os grandes rastreadores documentam. Observe os novos formatos de entrega em vez de os perseguir, porque nenhum tem um efeito medido sobre as citações. E ponha a sua energia de futuro na camada de ação do agente, porque é aí que ler se transforma em agir.
Não chegámos aqui a prever o debate. Chegámos aqui a construir sobre o sinal aborrecido e documentado, e a tratar tudo o que é mais recente como algo a medir primeiro. É todo o método. A parte barulhenta da internet discute o formato. A resposta calada e documentada não mudou.
Se quer o panorama de visibilidade mais alargado, o nosso manual de visibilidade perante a IA e os LLM reúne as restantes alavancas por ordem de prioridade.
Última atualização: 15 de junho de 2026.
