O Google Chrome está marcando suas páginas como “não seguras”?
Sua captação de lead está em perigo. Evite páginas não seguras em sua presença digital e, assim, gere mais confiança e credibilidade em suas estratégias.
Um site agent-actionable é um site que expõe suas ações de negócio de forma declarada e executável por software: cada ação tem nome, parâmetros de entrada, pré-condição, resposta estruturada e registro de execução. Ele não é apenas lido por uma IA. Ele é operado por ela.
Nas camadas anteriores do GEO Técnico, o verbo sempre foi passivo: ser acessado, ser renderizado, ser entendido, ser citado.
Agora o verbo muda. Sai “o que a IA entende do meu site” e entra “o que ela consegue executar no meu site”.
Essa é a camada 5. E ela não é a continuação natural das outras.
O que é um site agent-actionable, na prática
Considere uma cena que já está acontecendo.
Alguém pede ao assistente: veja se esse programa abre turma no próximo semestre, confira o valor e me traga uma lista de opções.
O assistente não liga para o seu hero. Não liga para a paleta de cor. Ele abre a página e tenta executar.
O que ele encontra, na maioria dos casos, é uma jornada desenhada para humano: mouse, teclado, paciência e dois minutinhos livres.
Faço aqui um paralelo com o mobile first. Durante anos todo mundo projetou desktop first. Quando chegou a hora de virar a chave, o processo travou, porque a cabeça do time continuava na tela grande.
É a mesma coisa agora. A vida toda desenhamos interface para humano. Só que o humano passou a delegar.
A intenção continua humana. A execução, não.
Onde o agente trava no seu site hoje
Antes de falar de arquitetura, vale mapear os impedimentos concretos. Eles se repetem com uma regularidade quase constrangedora.
Banner de consentimento modal que bloqueia a página até alguém clicar. Para o visitante é um clique sem leitura. Para um agente que não executa JavaScript, é uma parede.
O botão que não é um botão: uma div com evento de clique, sem role, sem semântica. Parece botão na tela e não existe como ação para quem lê o HTML.
Formulário em várias etapas com estado em sessão, token de validade curta e validação só no cliente. O envio depende de uma sequência de interface que o agente não reproduz sem simular um navegador inteiro.
Preço, disponibilidade e condição dentro de PDF ou atrás de login, fora de qualquer resposta estruturada.
Confirmação genérica: o envio acontece, a tela diz “obrigado” e o comprovante vai para o e-mail. O agente não sabe se terminou, então tenta de novo. E de novo.
Sobre o último item eu tenho uma controvérsia honesta: particularmente, prefiro entregar material por e-mail, porque é assim que se qualifica o lead. Mas é preciso admitir que, do ponto de vista do agente, isso é um buraco de confirmação.
O risco mora nos dois extremos
Quase ninguém discute o outro lado. O problema não é só o agente que não consegue agir. É o agente que consegue agir demais.
Formulário público sem limite de taxa vira registro duplicado no CRM, chamado duplicado na fila de suporte e sujeira na base. Quem cuida das operações sente isso primeiro, na forma de trabalho que não existe.
O extremo oposto é igualmente ruim. O WAF (Web Application Firewall, a camada que fica antes da aplicação) bloqueia por heurística e derruba o agente legítimo que estava ali representando um cliente real.
Ninguém fica sabendo. A ação some e o humano por trás dela também.
O resultado é o atrito de sempre: marketing vê o formulário convertendo menos e abre chamado, a TI vê requisição suspeita e aperta a regra.
E não existe log que responda a pergunta mais simples de todas: quem pediu o quê, e o que o sistema fez com isso?
Troca o setor, a mecânica é a mesma
Em logística, “onde está meu pedido?” é a pergunta mais repetida do suporte. A página de rastreio costuma ser um widget de terceiro dentro de um iframe, com o número do pedido vivendo em estado de JavaScript. A consulta existe como tela, não como ação.
Em saúde, o agendamento aparece num calendário desenhado em canvas. O horário está visível para o olho e inexistente para qualquer leitura programática.
Em fintech, a segunda via e o limite de operação ficam atrás de três cliques, um seletor customizado e um CAPTCHA, sem nenhuma distinção entre abuso e automação feita pelo próprio titular.
O teste que vem antes de qualquer ferramenta
Faça o seguinte antes de abrir editor de código.
Monte um formulário interno listando as páginas principais e peça para o time escrever, em uma frase por ação: o que entra, o que sai e o que acontece depois.
Se ninguém do seu próprio time consegue preencher essa lista sem abrir a página ou o código-fonte, você acha mesmo que um agente vai descobrir isso sozinho, gastando tempo e token?
A causa é estrutural, não é falta de plugin
No seu site, a ação não existe como objeto. Ela existe como efeito colateral da interface.
A ação nasce do formulário, que nasce do template, que nasce do construtor. O endpoint real do processo de negócio é um render acoplado a cookie e sessão, com boa parte da lógica rodando no cliente.
Isso produz quatro consequências.
Não existe inventário nem contrato
Contrato aqui é concreto: nome da ação, parâmetros tipados, pré-condição, efeito, formato de resposta e reversibilidade.
Nada disso está declarado no seu HTML. O humano deduz pelo layout, e é por isso que UX importa tanto: ele vê um campo chamado CPF e já sabe o formato.
O agente não deduz com segurança. E quando erra, erra executando.
Essa é a diferença de natureza entre a camada 4 e a camada 5. Erro de leitura gera citação ruim. Erro de execução gera registro ruim no banco.
A regra de negócio mora dentro da interface
A validação está no front. O cálculo de elegibilidade está num hook do formulário. O “só aceita se a turma tiver vaga” está numa condicional de template.
Quando alguém propõe expor isso numa API, a TI reage. E a reação é tecnicamente correta: criar um segundo caminho duplica a regra, e regra duplicada diverge.
É o medo legítimo que trava o projeto na reunião.
Identidade é binária
Hoje só existem dois estados: humano ou bloqueado. Não existe a figura do não humano autorizado, com escopo limitado e limite de taxa próprio.
Os padrões de autenticação de agente ainda estão se formando. Enquanto isso, a decisão é tomada por heurística de user agent, justamente o campo mais fácil de forjar do protocolo.
Ou seja: você bloqueia quem se identifica e deixa passar quem mente.
Não existe observabilidade de ação
Você mede page view, taxa de conversão e Core Web Vitals. Não mede ação, origem, taxa de erro por ação nem latência de execução.
O que não é medido não entra em SLA, não entra em relatório e não entra em reunião de diretoria.
E tem uma causa que não é técnica e atrasa mais que todas: governança. Pode o site criar um registro em nome de terceiro? Isso é decisão de negócio com implicação jurídica, e costuma chegar como chamado técnico sem dono na fila de desenvolvimento.
Por isso a camada 5 não começa no editor de código. Começa numa lista. Não é interface. É contrato.
A arquitetura em seis planos
Os planos são sequenciais de propósito. Pular um dos primeiros é o que transforma a camada de agente em risco.
Inventário de ações. Uma planilha, antes de qualquer código. Cada linha é uma ação que o site expõe hoje (consultar disponibilidade, solicitar proposta, emitir segunda via, abrir chamado) com colunas de entrada, saída, pré-condição, sistema de destino e dono da regra. Esse documento costuma revelar a mesma ação duplicada em três plugins diferentes.
Classificação por risco. Três baldes: leitura (não muda estado), escrita reversível (cria registro que alguém apaga sem consequência) e escrita irreversível ou transacional (dinheiro, contrato, dado sensível, comunicação disparada para fora).
Contrato declarado. No WordPress, um namespace próprio e versionado na REST API, nunca o endpoint cru do plugin de terceiro, cujo roadmap você não controla. Cada ação com parâmetro tipado, obrigatoriedade explícita, resposta estruturada e erro legível em texto: “CPF inválido” resolve, um 400 solto não resolve.
Superfície dupla sobre a mesma regra. A regra vai para uma camada de serviço única. O formulário do site passa a ser cliente dela, e a ação exposta ao agente é outro cliente da mesma camada. Duas superfícies, uma regra. É a resposta ao medo da TI.
Identidade, escopo e limite. Leitura pode ser aberta com limite de taxa por origem. Escrita exige credencial com escopo (esta chave cria lead, não consulta base). O WAF passa a decidir sobre identidade declarada e verificável, o que permite liberar um agente específico sem afrouxar a proteção para o resto.
Confirmação, reversão e log. Toda ação devolve identificador, estado atual e, quando couber, caminho de reversão. O que é irreversível vai para fila de revisão humana com prazo acordado. Cada execução gera registro: quem chamou, com qual escopo, o que mudou, quando.
A regra que aplicamos é simples: começa expondo leitura, avança para escrita reversível, e escrita irreversível só com humano no circuito.
Quase todo o valor inicial está no primeiro balde, e o primeiro balde é de risco quase zero. Comece por ele.
Em cima do log vem a medição: volume por ação, taxa de erro por ação, latência e origem. É isso que coloca a camada de agente dentro do SLA em vez de deixá-la como experimento solto na empresa.
Três perguntas para saber se você está pronto
Você consegue listar todas as ações do seu site em uma única página?
A regra de negócio de cada ação vive fora do template?
Você consegue distinguir no log uma requisição de agente autorizado de uma tentativa de abuso?
Se a resposta for não nas três, o primeiro entregável não é código. É o inventário.
Perguntas frequentes sobre site agent-actionable
Qual a diferença entre um site lido pela IA e um site agent-actionable
Um site lido pela IA é acessível, renderizável e compreensível para crawlers de IA, o que sustenta citação em resposta generativa. Um site agent-actionable vai além: ele permite que um agente execute operações de negócio, como consultar disponibilidade ou abrir uma solicitação, com contrato declarado e resposta determinística.
Preciso de um plugin específico para expor ações a agentes
Não. O caminho é arquitetural: camada de serviço com a regra de negócio, endpoints próprios e versionados, identidade com escopo e log de execução. Os protocolos de ferramenta que vêm surgindo no mercado apontam exatamente para esse formato (capacidade declarada, parâmetro tipado, resposta determinística), então um site bem estruturado já chega preparado para eles.
Expor ações para agentes aumenta o risco de segurança
Expor sem classificação de risco, sem escopo e sem limite de taxa aumenta, sim. Com os seis planos na ordem, o efeito costuma ser o inverso: você sai da heurística de user agent, que bloqueia quem se identifica e libera quem mente, para autorização por identidade verificável e registro auditável de cada execução.
Conclusão
A camada 5 muda o verbo: de ser lido para ser operado.
Hoje a ação do seu site é efeito colateral da interface. Por isso ela não tem nome, não tem contrato e não tem log.
Inventariamos. Classificamos. Declaramos. Autorizamos. Medimos. Esse é o ciclo.
E digo com honestidade: montar a camada de agente não compra demanda. Nenhum agente é obrigado a usar o seu site. O que essa arquitetura faz é remover o impedimento técnico e manter o controle quando a demanda chegar, e ela chega pelo canal que você menos controla, que é o assistente que o seu cliente já usa.
Antes do passo a passo de implementação, vale medir o terreno. Nosso diagnóstico de GEO Técnico dá uma nota de 0 a 100 para o seu site e detalha o que precisa ser corrigido para que a IA consiga acessar, ler e interpretar suas páginas. É o chão sobre o qual a camada de agente se apoia.
E me conta: você consegue escrever hoje, em uma frase por ação, o que o seu site faz?
