Prontidão para Busca de IA

Três movimentos. Eles não são sobre qualidade de conteúdo, que é governada pelo non-commodity-content. Eles são sobre se o site pode ser encontrado, cotado e transacionado por uma máquina agindo em nome de um cliente.

Um site pode passar em todas as regras de conteúdo e ainda ser invisível para um agente, porque nunca publicou um número e nunca expôs um endpoint de reserva que uma máquina possa ler.

Movimento 1: publique a faixa de preço

A regra. Todo site comercial publica quanto custa seu serviço. Não um catálogo de preços. Uma faixa com os dois extremos e o que move o número entre eles.

As pessoas perguntam à IA quanto as coisas custam, constantemente. Uma IA sem nada para citar as envia para um concorrente que publicou algo. "Ligue para saber o preço" é um beco sem saída para uma máquina e, cada vez mais, para uma pessoa.

O que publicar, no mínimo:

o valor mínimo e o valor máximo, como números reais
o que o move: as duas ou três variáveis que decidem onde na faixa o trabalho se encaixa
a data em que a faixa foi medida, ao lado dos números
toda taxa fixa, na íntegra: entrega, configuração, depósito, limpeza, mínimos, penalidades
um link para a fonte ativa para um orçamento exato

A objeção e a resposta. Operadores resistem porque os preços mudam e temem ser responsabilizados por um valor desatualizado. Essa objeção é sobre um preço fixo único apresentado como o preço. Não é um argumento contra uma faixa. Uma faixa datada com seus impulsionadores nomeados é mais precisa do que silêncio, e é a única coisa que o operador pode afirmar de forma única.

A regra que resolve isso. Nunca publique uma taxa simples. Publique:

As diárias variam de R$ 106 a R$ 175 em toda a frota, medidas em 18 de setembro de 2026. Qual trailer e quais datas decidem onde você se encaixa. Verifique suas datas para a taxa exata.

Não:

Trailers a partir de R$ 106/noite.

Nunca digite um preço duas vezes. Leia-o da fonte que a empresa já mantém, no momento da compilação: o feed da plataforma de reservas, o PDV, a tabela de taxas publicada. Um preço digitado em uma página é um preço que vai discordar do checkout em um mês. Quando o número é extraído da própria página do operador, os dois nunca podem divergir.

Onde uma taxa realmente não pode ser publicada (é cotada por trabalho, ou definida por um terceiro), a página ainda deve ao leitor tudo o que é adjacente e fixo: a tabela de taxas, os mínimos, o depósito, a penalidade por alterar uma reserva. Então diga claramente que a taxa em si é definida no momento do orçamento e aponte para onde. Uma página que diz "não publicamos X, aqui está o porquê, aqui está onde obtê-lo, e aqui está tudo o que não muda" vence uma página que não diz nada.

Verificação pré-publicação para qualquer página de preços:

Ambos os extremos da faixa são números reais, não "a partir de"
Os impulsionadores que movem o preço estão nomeados
A data de medição está ao lado dos números
Todas as taxas fixas estão publicadas na íntegra
Os números são lidos de uma fonte no momento da compilação, não digitados
Os dados estruturados carregam os mesmos números que o texto (veja Movimento 2)
Onde algo não pode ser precificado, a página diz isso e aponta para o orçamento

Movimento 2: agendamento pronto para agente

A regra. Se o agente de um cliente não puder ver como transacionar com o calendário, o negócio está invisível para ele. A reserva por agente é uma realidade: um assistente reservará uma mesa, uma chamada de serviço, um aluguel. Ele busca primeiro os dados estruturados e depois o DOM.

Três camadas, todas obrigatórias.

1. A oferta, em dados estruturados. Cada item reservável carrega uma Offer com um preço real ou uma faixa priceSpecification, uma moeda, um estado de disponibilidade e um priceValidUntil correspondendo à data de medição. Um priceRange no negócio não é suficiente; a máquina quer a oferta no item que está sendo solicitado a reservar.

"offers": {
  "@type": "Offer",
  "priceCurrency": "BRL",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceCurrency": "BRL",
    "minPrice": 600,
    "maxPrice": 1000,
    "unitCode": "DAY",
    "referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
  },
  "availability": "https://schema.org/InStock",
  "priceValidUntil": "2026-12-31",
  "url": "https://exemplo.com/reservar"
}

2. A ação. A entidade carrega um potentialAction nomeando o endpoint de reserva, o alvo HTTP e as entradas que ele requer. Esta é a parte que quase ninguém publica e a parte que um agente realmente precisa.

"potentialAction": {
  "@type": "ReserveAction",
  "name": "Reservar este trailer",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://exemplo.com/reservar?aluguel_id={aluguel_id}&de={checkin}&ate={checkout}",
    "actionPlatform": [
      "https://schema.org/DesktopWebPlatform",
      "https://schema.org/MobileWebPlatform"
    ],
    "httpMethod": "GET"
  },
  "result": { "@type": "Reservation", "name": "Reserva de aluguel de trailer" },
  "object": { "@type": "Product", "name": "Jayco Jay Flight 2023" }
}

Escolha o tipo de ação que corresponde ao verbo: ReserveAction para uma reserva, ScheduleAction para um agendamento, OrderAction para uma compra, RsvpAction para um evento.

3. As restrições, declaradas como dados, não como prosa. Um agente que reserva uma estadia que o negócio não pode honrar perdeu o tempo de todos. Publique as regras que fariam uma reserva falhar:

duração mínima e máxima
prazo de antecedência e limite (availabilityStarts, advanceBookingRequirement)
elegibilidade (idade mínima, carteira de motorista, depósito)
área de serviço (areaServed), e quanto custa para alcançar cada parte dela
janelas de abertura ou entrega, onde a hora de chegada é restringida por outra pessoa

Coloque cada um desses no schema onde existir uma propriedade, e em frases simples na página onde não existir. Ambos, sempre: o agente lê um, a pessoa lê o outro, e eles devem concordar.

Renderização legível por agente. Conteúdo crítico renderizado no servidor, HTML semântico, cabeçalhos reais, texto alternativo, tabelas como <table>. Um agente lê o DOM e a árvore de acessibilidade. Conteúdo que aparece apenas após uma busca no lado do cliente é conteúdo que o agente não viu.

Não finja capacidade. Publique um ReserveAction apenas contra um endpoint que realmente aceite uma reserva. Uma ação apontando para um formulário de contato é uma mentira sobre a qual um agente agirá, e o cliente descobre no pior momento. Onde a reserva é genuinamente por telefone, publique o número de telefone no schema e nenhuma ação de reserva.

As camadas de protocolo e qual construir

Existem três camadas. Elas não são alternativas, elas se empilham, e a ordem importa porque as inferiores são lidas hoje e as superiores, em sua maioria, ainda não são.

Camada 1: dados estruturados (construa isso primeiro, sempre). Offer mais potentialAction, como acima. Isso é o que os assistentes atuais realmente consomem quando respondem a uma pergunta sobre um negócio e quando seguem um link para agir. Custa uma página de JSON-LD e funciona imediatamente.

Camada 2: um feed legível por máquina. Uma URL JSON estável contendo o catálogo: o que está para alugar ou para venda, o preço de cada um, as restrições, a URL de reserva e a data em que foi medido. Nenhum compromisso de protocolo, nenhum endpoint para defender, legível por qualquer agente, rastreador ou site irmão. Barato e a coisa que torna a camada 3 um trabalho de uma manhã mais tarde.

Camada 3: A2A (Agent2Agent). O protocolo aberto para delegação de tarefas entre agentes: um cartão de agente numa URL bem conhecida descrevendo a identidade, habilidades e autenticação do agente, e um endpoint falando JSON-RPC sobre HTTPS que aceita tarefas e retorna resultados. É a resposta certa quando um assistente do cliente deve ser capaz de fazer perguntas e obter respostas, em vez de ler uma página.

Seja honesto sobre onde está. Em final de 2026, não há registro que assistentes de consumo rastreiem rotineiramente para cartões de agente, então publicar um é uma aposta na chegada da descoberta, não uma fonte de reservas neste trimestre. Construa quando o negócio tiver algo que um agente genuinamente precise perguntar que um feed estático não possa responder, tipicamente disponibilidade em tempo real.

A regra da honestidade se aplica mais fortemente aqui. Um cartão de agente declara habilidades, e outro agente as invocara. Declare apenas o que o endpoint realmente faz. A maioria dos pequenos operadores não consegue completar uma reserva agente-a-agente, porque pagamento, seguro e o contrato de aluguel estão dentro de uma plataforma de terceiros. Isso é ok, e o cartão deve dizer isso:

{
  "name": "Assistente de reservas Exemplo Locações",
  "description": "Responde perguntas sobre disponibilidade e preço para uma frota. Não pode receber pagamento.",
  "skills": [
    { "id": "verificar-disponibilidade", "description": "Quais unidades estão livres entre duas datas" },
    { "id": "cotar-estadia", "description": "Total para uma unidade e datas, incluindo entrega por cidade" }
  ],
  "capabilities": { "streaming": false, "pushNotifications": false }
}

Um cartão reivindicando uma habilidade reservar-estadia que termina em um redirecionamento é a mesma falha que um ReserveAction apontando para um formulário de contato, com uma máquina do outro lado em vez de uma pessoa.

Pagamentos. Os trilhos de pagamento por agente (AP2 como uma extensão A2A e as especificações concorrentes de comércio agêntico) estão evoluindo rápido e não são suportados pela maioria das plataformas de reserva. Não projete um checkout em torno deles. Passe para o checkout da própria plataforma e diga isso no cartão.

Verificação pré-publicação para qualquer página reservável:

Offer com preço ou faixa de preço, moeda, disponibilidade, priceValidUntil
potentialAction com um EntryPoint real que um agente possa chamar
Os parâmetros do modelo de URL da ação são os que o sistema de reservas realmente aceita
Mínimos, prazos de antecedência, elegibilidade e área de serviço publicados como dados e como prosa
Cada número no schema corresponde ao número no texto
A página renderiza seus fatos de reserva no lado do servidor
Nenhuma ação é publicada para uma capacidade que não existe

Movimento 3: conteúdo a partir de perguntas reais

A regra. As perguntas que os clientes realmente fazem são o conteúdo. Cada telefonema, cada e-mail, cada pergunta "antes de reservar" é uma página ou uma seção, respondida publicamente, nas próprias palavras do cliente.

A própria orientação do Google diz que conteúdo de conselho genérico ("7 dicas para o verão") não vence. O que vence é hiperespecífico e real. A pergunta que um cliente fez esta manhã é ambos, por construção, porque um concorrente escrevendo a partir de fontes públicas não sabe que ela foi feita.

O hábito operacional:

Capture a pergunta na íntegra. As palavras do cliente, não jargão do setor. "Vocês podem deixar na minha casa enquanto consertam o telhado" é a consulta. "Logística de posicionamento residencial" não é. Esta é a mesma regra de escrever o substantivo do pesquisador.
Responda onde o leitor a tem. Na página onde a pergunta surge, não em um post de blog que ninguém alcança.
Responda com uma fonte. Uma resposta sem fonte é uma opinião; é a taxa fixa, a regra publicada, o número medido que a torna digna de citação.
Diga quando a resposta não é sua para dar. Onde a resposta pertence a um terceiro, um conselho, uma seguradora, um parque, diga isso e nomeie a quem perguntar. Essa frase é um ativo.
Mantenha uma lista do que só o operador sabe. Cada projeto mantém um arquivo de perguntas em aberto. Essas respostas são o conteúdo que ninguém pode copiar, e o arquivo é a pauta da entrevista.

Blocos de FAQ são para leitores, com marcação FAQPage porque declara claramente o que a página responde. Eles não são a alavanca que ganha citações. A especificidade em primeira mão é.

Como os três se encaixam

Um leitor chega de uma resposta de IA que citou a faixa. A página confirma o número, nomeia o que o move e responde à pergunta que eles realmente tinham. Seu agente então a reserva, porque a oferta e a ação foram publicadas como dados.

Qualquer um faltando quebra a corrente. Um site com ótimo conteúdo e nenhum preço publicado não é cotado. Um site com preço e nenhuma ação não pode ser transacionado. Um site com ambos e conteúdo genérico não vale a pena ser citado em primeiro lugar.

Fontes

Palestra principal de Danny Sullivan, Google Search Central Live Toronto, abril de 2026, sobre conteúdo não-commodity.
Guia de Otimização para IA, Google Search Central, sobre legibilidade por agente e expansão de consultas.
schema.org Offer, UnitPriceSpecification, ReserveAction, EntryPoint.
Protocolo A2A (Agent2Agent), Linux Foundation, para o cartão de agente e interface de tarefas JSON-RPC.

prontidão-para-busca-de-ia

O que é prontidão-para-busca-de-ia?

Perguntar na sua IA favorita

Documentação