O SEO também morreu? Não: tornou-se a API dos agentes

Durante anos acusou-se o SEO de escrever para robôs.

A ironia é que agora os robôs falam connosco, leem páginas, consultam ferramentas, combinam dados e conseguem executar ações. Já não se limitam a ordenar ligações. Começam a mediar entre uma pessoa e praticamente qualquer capacidade digital.

Uma pessoa pode dizer:

Revê os meus movimentos do último trimestre, deteta despesas anómalas e mostra-me num gráfico o que devo analisar primeiro.

O agente não precisa apenas de encontrar uma página que explique o que é um movimento bancário. Precisa de descobrir que sistema pode consultar, que contas está autorizado a ler, como solicitar um intervalo temporal, que estrutura devolverá cada transação, que moeda utiliza e que parte da informação deve transformar numa explicação, tabela ou gráfico.

É aí que surge uma nova fronteira do SEO.

Não porque as páginas tenham deixado de importar. Pelo contrário: o conteúdo visível continua a ser o lugar onde uma empresa explica o que sabe, o que oferece, que limites tem e por que razão merece confiança. Mas uma explicação já não chega quando o utilizador espera que o agente faça alguma coisa.

A capacidade precisa de duas representações:

1. Uma representação visual e conversacional para que uma pessoa consiga compreendê-la, avaliá-la e controlá-la.
2. Uma representação estruturada, tipada e invocável para que um agente consiga selecioná-la e utilizá-la de forma fiável.

A segunda representação assemelha-se ao SEO dos dados levado até à sua consequência operacional: uma API, uma ferramenta ou um servidor MCP que não descreve apenas o que existe, mas também o que pode ser feito.

A frase é deliberadamente provocadora. Os dados estruturados não são uma API e uma API não é SEO. O salto conceptual está noutro ponto: ambos reduzem a ambiguidade para que um sistema automático consiga descobrir significado, escolher uma opção e agir sem ter de adivinhar.

Em resumo

O SEO não morreu com os agentes. Dividiu-se em duas camadas complementares.

A primeira é o SEO que já conhecemos: conteúdo útil, texto acessível, arquitetura clara, títulos descritivos, ligações, autoridade, dados estruturados e acesso para crawlers. A sua função é ajudar a encontrar e compreender uma fonte.

A segunda é uma camada emergente que proponho chamar SEO operacional: contratos de ferramentas, APIs, schemas, permissões, resultados estruturados e erros acionáveis que permitem a um agente descobrir uma capacidade, selecioná-la, invocá-la e verificar o resultado.

Uma página responde:

O que é isto, para quem serve e por que razão devo confiar?

Uma ferramenta responde:

O que posso fazer, com que parâmetros, sob que permissões e o que vou devolver?

E uma interface gerada responde:

Como pode uma pessoa compreender, explorar, corrigir ou aprovar o que acabou de acontecer?

O futuro não opõe conteúdo, API e interface. Obriga-os a partilhar a mesma verdade.

O SEO sempre foi uma interface entre duas formas de leitura

O SEO costuma ser reduzido a rankings, palavras-chave ou tráfego. Essa redução esconde a sua função mais útil: traduzir uma página para que seja compreensível, ao mesmo tempo, por pessoas e sistemas automáticos.

Uma pessoa interpreta hierarquia visual, tom, exemplos, reputação e contexto. Um crawler precisa de ligações acessíveis, texto disponível, HTML semântico, títulos descritivos, relações entre URLs e sinais que consiga processar de forma consistente.

A Google define o SEO como o conjunto de práticas que ajudam os motores de pesquisa a descobrir e compreender conteúdo. Também insiste que essa otimização cria valor quando se aplica a conteúdo produzido principalmente para pessoas, e não quando o conteúdo existe para manipular o sistema.

Esse equilíbrio é importante porque antecipa o problema atual.

Quando acrescentamos dados estruturados a uma página, não criamos uma segunda realidade secreta para o robô. Acrescentamos pistas explícitas sobre a realidade que a pessoa também consegue ver. A Google exige que o markup represente o conteúdo principal, seja relevante e não descreva informação oculta ou enganadora.

A regra pode ser generalizada:

A representação para máquinas deve ser uma expressão mais precisa da mesma capacidade prometida às pessoas.

Na web clássica, essa representação ajuda a classificar e apresentar informação. Num sistema agêntico, também pode tornar-se o contrato que habilita uma ação.

A mudança não é o agente ler a web: é poder continuar depois de a ler

Um motor de pesquisa tradicional encontra uma página e entrega o passo seguinte à pessoa. A pessoa abre o resultado, interpreta a interface e executa a ação.

Um agente pode encadear mais partes do processo:

1. Compreender a intenção expressa em linguagem natural.
2. Procurar fontes ou ferramentas relevantes.
3. Comparar informação e restrições.
4. Escolher uma capacidade.
5. Preparar parâmetros.
6. Solicitar autorização quando necessário.
7. Executar uma consulta ou ação.
8. Transformar o resultado numa explicação ou interface.
9. Pedir confirmação antes de uma alteração sensível.
10. Manter evidência do que foi realizado.

Visitar a página deixa de ser sempre o objetivo final. Pode tornar-se uma etapa de descoberta, confiança ou documentação dentro de uma tarefa maior.

Isto não elimina a web. Altera o destino de parte do seu tráfego: de cliques para páginas para delegações em capacidades.

A interface deixa de ser apenas o lugar onde executamos o trabalho e passa a ser o lugar onde definimos, supervisionamos e verificamos uma delegação. O SEO vive uma transformação paralela: deixa de otimizar apenas a entrada numa página e começa a participar na legibilidade daquilo que o agente pode fazer a seguir.

O modelo de dupla representação

Uma capacidade digital madura vai precisar de duas representações coordenadas.

1. Representação visual e conversacional

É a forma como uma pessoa compreende a capacidade e o seu resultado.

Pode assumir muitas superfícies:

• Uma página editorial que explica um serviço.
• Uma conversa que resume uma análise.
• Uma tabela que conserva precisão.
• Um gráfico que revela uma tendência.
• Um mapa que permite explorar relações espaciais.
• Um formulário para editar várias opções ao mesmo tempo.
• Um diff que mostra o que mudou.
• Um painel de aprovação que separa leitura de escrita.

Esta representação não é um invólucro decorativo. Organiza o significado, reduz a carga cognitiva e permite verificar aquilo que o agente interpreta ou executa.

A conversa é excelente para expressar intenção, pedir uma síntese e refinar o objetivo. É pior para comparar vinte valores, detetar uma anomalia em centenas de linhas ou rever os detalhes de uma ação irreversível. Por isso, a interface agêntica não será apenas voz ou chat. Será uma combinação dinâmica de linguagem, controlos e visualizações.

2. Representação estruturada e invocável

É a forma como um agente descobre e utiliza a capacidade sem depender de uma interpretação visual frágil.

Inclui, consoante o sistema:

• Um nome estável e orientado para uma ação.
• Uma descrição que explica quando deve ser utilizada.
• Um schema de entrada com tipos, limites e valores permitidos.
• Um schema de saída que conserva estrutura e significado.
• Identificadores estáveis para continuar o fluxo.
• Autorização e âmbito de acesso.
• Declaração de efeitos sobre dados ou sistemas externos.
• Erros acionáveis que permitam corrigir parâmetros.
• Versionamento, disponibilidade e limites operacionais.
• Metadados para distinguir leitura, escrita e ações destrutivas.

A OpenAI recomenda tratar nomes, descrições e documentação de parâmetros como product copy: são os textos que ajudam o ChatGPT ou o Codex a decidir se uma ferramenta corresponde à intenção do utilizador. O MCP formaliza essa superfície através de name, description, inputSchema, outputSchema e structuredContent.

Esta camada não tenta fazer com que o agente “veja melhor” um botão. Tenta evitar que precise de procurar o botão.

Dados estruturados não são o mesmo que uma API

Convém parar aqui porque a metáfora pode induzir em erro.

Os dados estruturados de uma página são sobretudo descritivos. Indicam que tipo de entidade aparece, quem é o seu autor, quando foi publicada, que propriedades contém ou como se relaciona com outros elementos.

Uma API ou ferramenta é operacional. Define uma interação possível com um serviço: o que recebe, o que devolve, que permissões verifica, que estado pode alterar e que erros pode produzir.

Camada	Pergunta principal	Resultado esperado
Conteúdo visível	O que significa e por que é importante?	Compreensão humana, confiança e contexto.
Dados estruturados	Que entidade ou informação descreve esta página?	Classificação e pistas explícitas para sistemas.
API ou ferramenta	Que capacidade pode ser executada e sob que contrato?	Consulta ou ação repetível.
Interface de resultado	Como se compreende, explora ou aprova o resultado?	Evidência visual e controlo humano.

Por isso, “a representação estruturada é o SEO dos dados transformado em API” funciona como tese editorial, não como definição técnica.

A analogia correta é esta:

O SEO reduz a ambiguidade ao descobrir e compreender conteúdo. Um contrato de ferramenta reduz a ambiguidade ao selecionar e invocar uma capacidade.

O salto é de semântica descritiva para semântica operacional.

Da palavra-chave à intenção executável

O SEO moderno passa há anos por um afastamento da repetição literal de palavras-chave. Uma página útil deve resolver uma intenção, demonstrar conhecimento e oferecer uma resposta satisfatória.

As ferramentas para agentes levam essa lógica a um nível mais rigoroso.

Uma descrição como “Obtém dados financeiros” é demasiado ampla. Não explica:

• Se consulta saldos ou movimentos.
• Se trabalha com uma conta ou com todas.
• Que período aceita.
• Se devolve montantes líquidos ou brutos.
• Que moedas consegue combinar.
• Se os dados são em tempo real.
• Se apenas lê ou também modifica.
• Em que casos não deve ser utilizada.

Uma descrição orientada à intenção seria mais parecida com:

Utilize esta ferramenta quando o utilizador quiser analisar despesas já registadas numa ou mais contas autorizadas. Não a utilize para iniciar transferências, alterar categorias ou estimar movimentos futuros.

O equivalente técnico pode incluir um contrato como este:

{
  "name": "finance.get_spending_summary",
  "description": "Analisa despesas registadas em contas autorizadas dentro de um período. Apenas leitura; não inicia pagamentos nem altera transações.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "account_ids": {
        "type": "array",
        "items": { "type": "string" }
      },
      "date_from": { "type": "string", "format": "date" },
      "date_to": { "type": "string", "format": "date" },
      "currency": { "type": "string" }
    },
    "required": ["account_ids", "date_from", "date_to"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "totals_by_category": { "type": "array" },
      "anomalies": { "type": "array" },
      "source_period": { "type": "object" }
    },
    "required": ["totals_by_category", "anomalies", "source_period"]
  }
}

O exemplo não representa uma API bancária real. Mostra o tipo de precisão semântica de que um agente precisa para não confundir análise com ação.

A descrição atrai a intenção correta. O schema evita parâmetros improvisados. A autorização limita as contas. A saída estruturada permite continuar. A UI transforma o resultado em algo que uma pessoa consegue rever.

O catálogo de ferramentas é uma nova página de resultados

Um agente ligado pode ter dezenas ou centenas de ferramentas disponíveis. Perante um pedido, tem de decidir qual utilizar, quais descartar e se precisa de combinar várias.

Esse problema assemelha-se a uma pesquisa em miniatura.

A OpenAI propõe avaliar metadados com um conjunto de prompts diretos, indiretos e negativos. Depois recomenda medir precisão e recall:

• Precisão: quando uma ferramenta foi ativada, era realmente a correta?
• Recall: quando a ferramenta era necessária, o agente encontrou-a e utilizou-a?

Estas métricas pertencem tanto à recuperação de informação como ao design de produto.

A comparação com SEO ajuda a perceber o paralelismo, desde que não se confundam as camadas:

SEO documental	Descoberta de ferramentas
title e H1 descrevem a página	name e title identificam a ação
Meta description resume relevância	description explica quando invocar
Cabeçalhos desenvolvem o tema	Parâmetros documentam âmbito e limites
Ligações internas conectam conteúdo	Relações e sequências conectam ferramentas
Schema.org fornece pistas explícitas	JSON Schema define entradas e saídas
URL canónico estabiliza a referência	ID e versão estabilizam o contrato
Robots e sitemap controlam descoberta	Registo, permissões e disponibilidade controlam exposição
Search Console revela desempenho	Evals e analítica revelam seleção e falhas

Não estamos perante “SEO para enganar o modelo”. Estamos perante arquitetura de informação para que o modelo não tenha de adivinhar.

Descobrir, compreender, invocar e verificar

O percurso completo de uma capacidade agêntica pode resumir-se em quatro verbos.

Descobrir

O agente precisa de localizar uma fonte ou ferramenta candidata.

Na web, isto continua a depender de rastreio, indexação, ligações, sitemaps, texto acessível e permissões do crawler. A Google afirma que as práticas de SEO existentes continuam a aplicar-se a AI Overviews e AI Mode, e que não é necessário um ficheiro especial nem um schema exclusivo para aparecer nessas experiências.

A OpenAI distingue o OAI-SearchBot, utilizado para mostrar sites nas funcionalidades de pesquisa do ChatGPT, do GPTBot, relacionado com treino. Isto confirma que a acessibilidade para sistemas de pesquisa continua a ser uma decisão técnica concreta, não uma abstração.

Compreender

Encontrar um URL não chega. O agente tem de identificar o que a fonte afirma, com que evidência, em que data e sob que contexto.

Aqui importam o conteúdo original, a autoria, definições claras, tabelas, semântica HTML, datas, referências e coerência entre texto visível e dados estruturados.

O conteúdo de qualidade não é um resíduo anterior à era agêntica. É a base com que o agente constrói uma resposta, compara fontes ou decide se uma capacidade é adequada.

Invocar

Quando existe uma ação repetível, o agente precisa de um contrato mais rigoroso do que uma página.

A OpenAPI define uma descrição normalizada para que pessoas e sistemas descubram e compreendam capacidades HTTP. O MCP expõe ferramentas com schemas de entrada e saída. Os resultados estruturados permitem encadear passos sem voltar a extrair informação de prosa ou píxeis.

A invocação acrescenta dimensões que o SEO clássico não precisava de resolver diretamente:

• Identidade.
• Autorização.
• Âmbito.
• Efeitos laterais.
• Idempotência.
• Limites de utilização.
• Erros e recuperação.
• Confirmação humana.

Verificar

O agente pode ter chamado a ferramenta correta e ainda assim produzir uma conclusão errada.

Um JSON válido não garante que os seus valores sejam verdadeiros. A OpenAI alerta que Structured Outputs pode respeitar um schema e ainda conter erros nos valores. Um schema garante forma; a evidência, a validação e a revisão sustentam o significado.

Por isso, a última camada volta a ser humana: mostrar fontes, período, filtros, pressupostos, anomalias, alterações e ações à espera de aprovação.

Aquilo que os agentes nos vão mostrar também é UX e também é SEO

O agente não precisa apenas de ler melhor. Também precisa de decidir como devolver aquilo que encontrou.

Uma resposta falada pode ser suficiente para:

Este mês gastou mais 18% em software do que a sua média dos últimos seis meses.

Mas uma pessoa pode precisar de verificar:

• Que subscrições compõem esse aumento.
• Que meses foram comparados.
• Se o montante inclui impostos.
• Que conta originou cada cobrança.
• Que categorias foram inferidas.
• Que movimentos ficaram por classificar.
• Que ação o sistema recomenda e porquê.

É aí que aparece a interface gerada ou selecionada pelo agente.

As MCP Apps permitem que ferramentas forneçam gráficos, formulários e dashboards dentro de uma conversa. A OpenAI recomenda acrescentar UI quando as pessoas precisam de inspecionar, comparar, editar, confirmar ou navegar informação estruturada. Também propõe separar as ferramentas que recuperam ou processam dados das que renderizam a apresentação final.

Essa separação é fundamental.

A ferramenta de dados deve devolver uma representação precisa e reutilizável. O agente pode analisá-la, combiná-la ou filtrá-la. Só depois escolhe uma vista adequada: gráfico, tabela, mapa, formulário, diff ou cartão de confirmação.

A UI deixa de ser necessariamente um ecrã fixo pelo qual todas as pessoas entram. Torna-se uma vista contextual de evidência, construída para a pergunta concreta.

O conteúdo, os dados e a interface continuam relacionados:

• O conteúdo explica a capacidade antes de ser utilizada.
• O schema permite executá-la sem ambiguidade.
• Os dados estruturados conservam precisão ao longo do fluxo.
• A interface permite compreender e controlar o resultado.
• A conversa liga tudo à intenção original.

Um exemplo: “revê as minhas contas e mostra-me o que preciso de ver”

Imaginemos que uma pessoa diz essa frase ao computador.

Um sistema bem desenhado não deveria começar por abrir separadores ao acaso e ler números do ecrã como única estratégia. Poderia seguir um fluxo como este:

1. Identificar que o pedido é de análise, não de transferência.
2. Mostrar que fontes financeiras estão ligadas e pedir o âmbito se existirem várias.
3. Invocar uma ferramenta apenas de leitura para recuperar contas autorizadas.
4. Consultar movimentos com datas, moedas e identificadores estáveis.
5. Normalizar categorias sem alterar o registo original.
6. Calcular tendências e assinalar anomalias com critérios explícitos.
7. Conservar o período e as fontes dentro do resultado estruturado.
8. Escolher uma representação visual adequada.
9. Resumir por voz as duas ou três conclusões principais.
10. Permitir abrir cada categoria ou movimento a partir do gráfico.
11. Separar qualquer ação posterior — por exemplo, cancelar uma subscrição — numa ferramenta de escrita com confirmação própria.

A pessoa recebe uma experiência simples: uma conversa e um gráfico.

Por baixo existe uma arquitetura complexa: ferramentas focadas, permissões, schemas, fontes, cálculos, estados e rastreabilidade.

O bom design não consiste em esconder completamente essa complexidade. Consiste em mostrar a parte necessária no momento certo.

A mesma fonte de verdade deve alimentar a página, a ferramenta e a interface

O maior risco deste modelo é criar três versões incompatíveis do negócio:

1. A promessa comercial na página.
2. O contrato técnico na ferramenta.
3. O comportamento real do sistema.

Proponho chamar-lhe triângulo de paridade semântica.

Vértice	O que deve expressar	Falha típica
Promessa visível	O que resolve, para quem, com que limites e evidência.	O marketing promete tempo real, mas os dados são atualizados uma vez por dia.
Contrato estruturado	Entradas, saídas, permissões, efeitos, erros e âmbito.	A descrição diz “apenas leitura”, mas o endpoint pode alterar estado.
Comportamento real	A operação e o resultado que o sistema executa.	O output omite moeda, fuso horário ou fonte e produz uma visualização enganadora.

A coerência não deve ser mantida através da cópia manual de texto entre CMS, documentação e código. Sempre que possível, convém derivar as representações de uma fonte de verdade partilhada:

• Catálogo canónico de capacidades.
• Tipos de dados versionados.
• IDs estáveis.
• Políticas de autorização centralizadas.
• Exemplos de utilização verificáveis.
• Definições de negócio partilhadas.
• Testes de contrato.
• Evals de seleção de ferramentas.
• Verificações de paridade entre conteúdo e comportamento.

O SEO, o design e a engenharia deixam de ser fases separadas. Participam na mesma arquitetura semântica.

O que é o SEO operacional

SEO operacional não é uma norma existente. É um quadro para nomear uma responsabilidade que está a surgir.

Defino-o assim:

O SEO operacional é o design de conteúdo, metadados, schemas e contratos para que uma capacidade digital possa ser descoberta, compreendida, selecionada, invocada e verificada por agentes sem perder clareza, confiança nem controlo humano.

Não substitui o SEO técnico nem editorial. Prolonga-os quando uma página representa uma capacidade executável.

Uma empresa não precisa de transformar cada artigo numa ferramenta. Uma opinião, uma investigação ou uma história podem continuar a ser conteúdo. A camada operacional faz sentido quando existe um resultado repetível e autorizável:

• Consultar disponibilidade.
• Calcular uma tarifa.
• Recuperar uma encomenda.
• Analisar movimentos.
• Criar uma reserva.
• Preparar um orçamento.
• Atualizar um registo.
• Gerar um relatório.
• Abrir uma incidência.
• Agendar uma reunião.

A pergunta prática é:

Depois de compreender esta página, existe uma capacidade concreta que o utilizador vai querer delegar?

Se a resposta for sim, provavelmente convém desenhar a sua representação invocável.

A matriz de maturidade: página, contrato e ação

Podemos classificar uma capacidade segundo as representações disponíveis.

Representação humana	Contrato invocável	Estado da capacidade
Sim	Não	Compreensível, mas a pessoa ainda tem de executar manualmente.
Não	Sim	Operável por integração, mas opaca e difícil de avaliar ou governar.
Não	Não	Capacidade invisível ou dependente de conhecimento interno.
Sim	Sim	Capacidade delegável: pode ser compreendida, invocada e verificada.

A última categoria não é automaticamente boa. Também precisa de autorização, segurança, observabilidade e recuperação. Um agente não deve conseguir agir apenas porque encontrou um endpoint.

Como explico em Controlar agentes IA como Codex no ambiente de trabalho, as instruções e anotações não substituem os controlos técnicos. As permissões devem ser aplicadas no servidor, as ações sensíveis devem ser separadas e a pessoa deve manter capacidade de revisão e revogação.

Como muda o trabalho de SEO, UX/UI e desenvolvimento

O SEO deixa de terminar na página

O profissional de SEO continuará a trabalhar com intenção, arquitetura, conteúdo, semântica, indexação, ligações, autoridade e medição.

Mas, para produtos agênticos, também terá de colaborar em:

• Taxonomias de capacidades.
• Nomes e descrições de ferramentas.
• Diferenciação entre operações semelhantes.
• Exemplos positivos e negativos de ativação.
• Coerência entre promessa, schema e resultado.
• Descoberta em catálogos de ferramentas.
• Evals de precisão e recall.
• Versionamento semântico de capacidades.

É uma evolução natural. Escrever uma descrição de ferramenta não é muito diferente de escrever um título e uma meta description: ambos condensam significado para ajudar um sistema a escolher. A diferença é que uma má escolha de ferramenta pode alterar dados, enviar uma mensagem ou gastar dinheiro.

UX/UI desenha a evidência e o controlo

O designer já não trabalha apenas na interface anterior à ação. Também desenha o que acontece depois de delegar:

• Como se expressa o âmbito.
• Como se mostram as fontes.
• Como se comparam resultados.
• Que visualização corresponde a cada tipo de dado.
• Quando basta uma resposta textual.
• Quando é necessário um formulário ou dashboard.
• Como se apresenta uma confirmação.
• Como se interrompe ou reverte uma tarefa.
• Como se distingue uma inferência de um dado observado.

A interface pode ser efémera e gerada para um pedido específico, mas os seus princípios não podem ser improvisados de cada vez.

O desenvolvimento transforma funções internas em contratos de produto

Não convém expor cada endpoint interno como ferramenta. A OpenAI recomenda começar pelo objetivo do utilizador e agrupar operações coerentes, separando leituras de escritas e ações com diferentes níveis de risco.

O trabalho inclui:

• Modelar inputs e outputs explícitos.
• Devolver IDs estáveis.
• Evitar blocos de texto quando o resultado precisa de ser reutilizado.
• Desenhar erros que permitam corrigir e tentar novamente.
• Aplicar autorização real.
• Declarar e testar efeitos laterais.
• Manter compatibilidade e versionamento.
• Separar processamento de dados e renderização.

Em Um LLM prevê tokens; um agente executa tarefas, explico que o valor do agente não surge apenas no modelo, mas no sistema que o rodeia. O contrato de ferramentas é uma dessas camadas decisivas.

Como medir este novo SEO

O ranking, por si só, não descreve a visibilidade agêntica.

Convém medir três níveis.

1. Descoberta documental

• Páginas rastreáveis e indexadas.
• Cobertura do sitemap.
• Impressões e cliques.
• Tráfego proveniente de motores de pesquisa e assistentes.
• Consultas em que a fonte aparece.
• Atualidade e acessibilidade do conteúdo.
• Coerência do markup estruturado.

2. Seleção e invocação

• Precisão da seleção da ferramenta.
• Recall perante prompts relevantes.
• Ativações falsas em prompts negativos.
• Validade dos argumentos.
• Percentagem de chamadas bem-sucedidas.
• Novas tentativas causadas por erros de schema ou de negócio.
• Tempo até concluir a tarefa.
• Utilização correta de leitura em relação a escrita.
• Custo de execução.

3. Compreensão e controlo humano

• Tempo necessário para verificar o resultado.
• Capacidade de localizar a fonte de um dado.
• Erros de confirmação.
• Ações revertidas.
• Correções solicitadas.
• Compreensão de limites e permissões.
• Satisfação com a representação visual.
• Incidentes ou ações indesejadas.

A unidade de sucesso deixa de ser apenas uma visita. Pode ser uma tarefa concluída de forma correta, compreensível e reversível.

O que não convém fazer

Criar conteúdo “para agentes” que não ajuda pessoas

A Google mantém uma posição clara: as práticas de SEO são úteis quando se aplicam a conteúdo útil e centrado nas pessoas. A chegada dos agentes não justifica produzir páginas vazias, definições repetidas ou texto concebido apenas para aparecer numa resposta generativa.

Tratar llms.txt como uma solução mágica

Alguns sites publicam índices legíveis por modelos e estes podem ser práticos como documentação. Mas a Google afirma que não é necessário criar novos ficheiros “AI text” nem markup especial para as suas funcionalidades de IA. Um ficheiro auxiliar não substitui conteúdo acessível, ligações, arquitetura, permissões de crawler nem uma API bem desenhada.

Copiar a API interna sem pensar no objetivo

Uma ferramenta com vinte modos e parâmetros ambíguos obriga o modelo a adivinhar. As capacidades devem ser desenhadas a partir do resultado que a pessoa espera, não da conveniência do backend existente.

Devolver apenas prosa quando o dado será reutilizado

Um parágrafo pode ser agradável de ler, mas perde IDs, tipos, unidades e relações. A resposta estruturada deve conservar a precisão; a conversa pode sintetizá-la depois.

Mostrar um gráfico sem expor a sua proveniência

Uma visualização convincente pode ocultar filtros, períodos ou dados excluídos. A UI deve permitir rastrear o resultado até às suas fontes e pressupostos.

Confiar no schema como garantia de verdade

O schema valida a forma, não necessariamente o significado. Continuam a ser necessários validação de negócio, evidência, testes e revisão proporcional ao risco.

Permitir que a descrição substitua a autorização

Dizer que uma ferramenta é apenas de leitura não a torna tecnicamente apenas de leitura. As restrições devem ser impostas através de permissões, endpoints e políticas reais.

Uma arquitetura prática para capacidades legíveis por agentes

Uma organização pode começar com sete camadas.

1. Página canónica: explica a capacidade, o público, os limites, exemplos, fontes e evidência.
2. SEO técnico: assegura texto acessível, semântica, ligações, canonical, sitemap, desempenho e políticas de crawling.
3. Dados estruturados: descrevem entidades e conteúdo visível sem inventar uma realidade paralela.
4. Catálogo de capacidades: mantém nomes, descrições, responsáveis, estado e versão.
5. Contrato invocável: expõe ferramentas ou APIs com schemas, autorização, efeitos e erros.
6. Resultado estruturado: conserva IDs, unidades, fontes e campos reutilizáveis.
7. Renderização de evidência: transforma o resultado em conversa, tabela, gráfico, formulário ou painel de aprovação conforme a tarefa.

A estas camadas é preciso acrescentar observabilidade, segurança e governo. Cada chamada deve conseguir responder quem solicitou a ação, que ferramenta foi utilizada, com que argumentos, que dados devolveu e que parte foi inferida pelo modelo.

A web não desaparece: torna-se documentação viva de capacidades

A previsão de que os agentes vão eliminar os sites confunde navegação com significado.

Talvez visitemos menos páginas para executar tarefas rotineiras. Mas as organizações continuarão a precisar de lugares canónicos onde explicar:

• O que oferecem.
• Como funciona.
• Que dados utilizam.
• Que limites aplicam.
• Que evidência sustenta as suas afirmações.
• Quem é responsável.
• O que muda entre versões.
• Como se revoga o acesso.
• O que o agente pode fazer em nome do utilizador.

A página torna-se ainda mais importante como fonte pública de verdade, mesmo quando o agente é quem a consulta primeiro.

A diferença é que o conteúdo já não deve viver isolado do produto. A definição visível, o schema e o comportamento precisam de evoluir em conjunto.

A conclusão incómoda: o SEO aproxima-se do design de produto

O SEO nasceu como disciplina de descoberta. Com os agentes, parte dessa descoberta conduz diretamente a uma ação.

Isso obriga a ampliar a pergunta.

Já não basta perguntar:

Um motor de pesquisa consegue encontrar e compreender esta página?

Também teremos de perguntar:

Um agente consegue descobrir esta capacidade, distingui-la de outras, invocá-la com os parâmetros corretos e devolver um resultado que uma pessoa consiga verificar?

Nesse ponto, o SEO toca arquitetura de informação, design de APIs, documentação, UX, segurança e analítica de produto.

Não porque todos esses trabalhos se transformem em SEO, mas porque todos participam na mesma batalha: fazer com que uma intenção humana chegue à capacidade correta com a menor ambiguidade possível.

A web para pessoas e a interface para agentes não são dois mundos separados.

Uma explica.

A outra executa.

E ambas devem dizer a verdade.

Perguntas frequentes

O SEO vai desaparecer quando os agentes responderem e agirem por nós?

Não. Os agentes continuam a precisar de descobrir fontes, interpretar conteúdo, avaliar autoridade e recuperar informação fiável. A esse SEO documental junta-se uma nova camada operacional: descrever capacidades através de ferramentas, APIs e schemas que possam ser selecionados e invocados sem adivinhação.

Os dados estruturados de uma página são o mesmo que uma API?

Não. Os dados estruturados descrevem o significado de uma página ou entidade. Uma API ou ferramenta expõe uma capacidade executável, com entradas, saídas, autorização, erros e possíveis efeitos sobre o estado. A relação entre ambas é uma analogia semântica, não uma equivalência técnica.

O que significa SEO operacional para agentes?

É um quadro proposto neste artigo para desenhar conteúdo, metadados e contratos de ferramentas de modo que uma capacidade possa ser descoberta, selecionada, invocada e verificada por um agente, mantendo uma representação clara e útil para as pessoas.

Uma empresa precisa de transformar todo o seu site numa API?

Não. O conteúdo editorial, institucional ou explicativo pode continuar a ser apenas documental. Faz sentido expor uma camada invocável quando existe uma capacidade repetível e autorizável, como consultar disponibilidade, calcular uma proposta, recuperar movimentos, criar uma reserva ou atualizar um registo.

As interfaces visuais continuam a ser necessárias se o agente consegue falar?

Sim. A conversa serve para expressar intenção e receber uma síntese. As interfaces visuais continuam a ser superiores para comparar, explorar dados densos, editar opções, rever evidência, confirmar ações e conservar um registo persistente.

Como se mede a visibilidade de uma capacidade para agentes?

Além da indexação, impressões e tráfego, é preciso medir seleção de ferramentas, precisão e recall da ativação, validade dos argumentos, sucesso da tarefa, novas tentativas, tempo de verificação humana, erros de confirmação e capacidade de recuperação.