Dados estruturados na era do AI Overviews: como preparar o schema do seu site

O structured data ganha uma camada extra de relevância na era da busca generativa: é o mesmo insumo que ajuda o Google a entender o conteúdo de uma página, seja para rich results tradicionais, seja, na leitura deste texto, para recursos como o AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → Overviews. Veja como times de MarTech↳Marketing digital4 conteúdosSEO por Elas 2025: Impulsionando e promovendo mulheres no Marketing DigitalMarketing Tech · fev 2025Por que ter um site ainda é relevante em 2025?Marketing Tech · fev 2025SoulCode Academy abre inscrições para cursos gratuitos de Martech e Java Full StackDev (Back & Front) · abr 2022Ver tudo em Marketing Tech → no Brasil podem adaptar o schema e medir o antes e o depois.

Quem publica conteúdo no Brasil convive com uma mudança silenciosa no funil de descoberta: parte das buscas que antes gerava clique agora termina numa resposta gerada por IA, como o AI Overviews. Nesse cenário, aparecer como fonte citada dentro da resposta virou um objetivo tão concreto quanto ranquear na primeira posição azul. E o insumo que ajuda o Google a entender (e a reaproveitar) o conteúdo de uma página continua sendo o mesmo dos rich results: dados estruturados.

A documentação do Google Search Central sobre structured data é o ponto de partida honesto para essa conversa, ainda que ela não mencione o AI Overviews especificamente. O que ela deixa explícito é o mecanismo: o Google usa os dados estruturados que encontra na web para entender o conteúdo da página e reunir informação sobre pessoas, livros e empresas descritos na marcação. Na leitura deste texto, é esse entendimento de máquina que, por extensão, também alimentaria recursos de busca generativa, ainda que a documentação oficial não trate desse ponto.

O que structured data faz por baixo

Dados estruturados são um formato padronizado para descrever e classificar o conteúdo de uma página. Numa receita, por exemplo, a marcação diz o que são os ingredientes, o tempo de preparo, a temperatura e as calorias, em vez de deixar o buscador adivinhar isso do texto corrido. O Google trata a documentação do Search Central como a referência definitiva do que ele suporta, ainda que o vocabulário venha do schema.org. Nem tudo que existe no schema.org é usado pelo Google, mas a base é essa.

O recado técnico central da documentação: marque só o que está visível ao usuário. Nas palavras do próprio Google, não se deve "criar páginas em branco ou vazias apenas para conter dados estruturados" nem adicionar marcação sobre informação que não aparece na página, mesmo que ela seja verdadeira. Schema não é lugar para esconder dado, e essa regra vale igualmente para a era generativa: o modelo precisa achar correspondência entre a marcação e o conteúdo real.

JSON-LD, e por quê ele venceu

O Google aceita três formatos, todos igualmente válidos quando bem implementados:

A recomendação oficial é usar JSON-LD sempre que a estrutura do site permitir, porque a marcação fica isolada do texto e o Google consegue lê-la mesmo quando ela é injetada dinamicamente por JavaScript ou por widgets do CMS. Para quem trabalha com WordPress, Wix ou Shopify e não edita o HTML direto, o caminho é o plugin de dados estruturados ou a página de configurações de busca da plataforma.

Um bloco JSON-LD de receita, como o exemplo da própria documentação, dá a dimensão do que "descrever a página" significa na prática:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Recipe",
  "name": "Non-Alcoholic Piña Colada",
  "author": { "@type": "Person", "name": "Mary Stone" },
  "datePublished": "2024-03-10",
  "recipeYield": "4 servings",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 5,
    "ratingCount": 18
  },
  "recipeIngredient": [
    "400ml of pineapple juice",
    "100ml cream of coconut",
    "ice"
  ]
}
</script>

Cada propriedade rotula um elemento (autor, data, avaliação, ingredientes), e é essa granularidade que permite ao buscador responder por ingrediente, calorias ou tempo de preparo. A leitura que faço: quanto mais o conteúdo estiver descrito em entidades limpas, mais fácil é para um sistema generativo extrair um fato e atribuí-lo à sua fonte.

Completo e correto vence exaustivo

Há uma armadilha comum em times de conteúdo: encher a marcação de propriedades recomendadas para "maximizar" a elegibilidade. A documentação avisa o contrário. É preciso incluir todas as propriedades obrigatórias de um tipo para ser elegível a exibição aprimorada, e mais propriedades recomendadas ajudam, porém, nas palavras do Google, é mais importante "fornecer menos propriedades recomendadas, porém completas e precisas, do que tentar preencher todas as possíveis com dados incompletos, mal formados ou imprecisos".

Na prática, para um time de MarTech brasileiro, isso significa priorizar o tipo certo (Article, Product, FAQPage, Recipe, Organization) com os campos-chave preenchidos e verdadeiros, em vez de espalhar schema meia-boca por todo o site. Vale também usar propriedades como sameAs para conectar a marca a seus perfis oficiais, algo que o Google diz poder aproveitar de forma mais geral e reservar para recursos futuros de busca.

Como validar e monitorar

O fluxo de qualidade recomendado tem dois momentos distintos:

• Durante o desenvolvimento: o Rich Results Test valida a marcação e, em alguns casos, mostra uma prévia do recurso na busca.
• Depois do deploy: os relatórios de status de rich results no Search Console e a ferramenta de Inspeção de URL confirmam que o Google realmente encontrou a marcação, o que pega quebras causadas por template ou por problemas de servidor após a publicação.

Ignorar a etapa pós-deploy é onde muita implementação morre: o schema passa no teste em ambiente controlado e quebra em produção por causa de um template mal renderizado.

Medir o antes e o depois, do jeito do Google

O ponto que mais interessa a quem responde por tráfego: a própria documentação propõe um método de teste antes/depois em vez de fé cega. O roteiro sugerido:

1. Escolha páginas do site que ainda não usam dados estruturados e que já tenham vários meses de histórico no Search Console. Prefira páginas estáveis, sem sazonalidade e populares o bastante para gerar dado significativo.
2. Adicione a marcação e confirme, pela Inspeção de URL, que o Google a encontrou.
3. Acompanhe o desempenho por alguns meses no relatório de Performance, filtrando por URL para comparar a mesma página consigo mesma.

A documentação é sincera sobre o ruído: visualizações de uma página variam por vários motivos, então isolar o efeito exige janela longa e páginas bem escolhidas. Como referência de ordem de grandeza, os estudos de caso citados pelo Google mostram ganhos relevantes de CTR e engajamento, o Rotten Tomatoes mediu 25% de CTR maior em páginas com structured data, o Food Network relatou 35% mais visitas e a Nestlé, 82% de CTR maior em páginas que aparecem como rich result. São números da fonte, de sites e contextos específicos, não uma promessa transferível para qualquer projeto.

O que fica em aberto para o cenário generativo

Uma ressalva importante de engenharia, não de marketing: a documentação do Google Search Central não menciona o AI Overviews nem trata de busca generativa em nenhum momento, ela fala em entendimento de conteúdo pelo Google Search de forma geral. A extensão para o cenário generativo feita neste texto é uma leitura do autor, não uma promessa do Google: dados estruturados melhoram a compreensão de máquina do conteúdo, e é razoável supor que essa compreensão sirva de matéria-prima tanto para rich results quanto para recursos de IA, mas isso não está documentado oficialmente. Preparar o schema é condição que pode ajudar, não botão que liga a citação.

Para o time brasileiro, o encaminhamento prático que eu seguiria: padronizar Article/Organization/FAQPage em JSON-LD, garantir correspondência total com o conteúdo visível, validar no Rich Results Test, confirmar a leitura na Inspeção de URL e rodar o teste antes/depois de Performance por dois a três meses antes de declarar vitória. Sem medição, não há como separar o efeito do schema de flutuação normal de tráfego, e é justamente essa disciplina de medir que diferencia SEO como engenharia de SEO como palpite.

Fonte: Documentação do Google Search Central sobre Structured Data e AI Features