Structured data in the age of AI Overviews: how to prepare your site's schema

Structured data gains an extra layer of relevance in the age of generative search: it's the same input that helps Google understand a page's content, whether for traditional rich results or, in this article's reading, for features like AI Overviews. See how MarTech teams in Brazil can adapt schema and measure the before and after.

Publishers in Brazil are living with a silent shift in the discovery funnel: part of the searches that used to generate a click now end in an AI-generated answer, like AI Overviews. In this scenario, appearing as a cited source within the answer has become as concrete a goal as ranking in the first blue position. And the input that helps Google understand (and reuse) a page's content remains the same one behind rich results: structured data.

A Google Search Central's documentation on structured data is the honest starting point for this conversation, even though it doesn't mention AI Overviews specifically. What it makes explicit is the mechanism: Google uses the structured data it finds on the web to understand page content and gather information about people, books and businesses described in the markup. In this article's reading, it's this machine understanding that, by extension, would also feed generative search features, even though the official documentation doesn't address this point.

What structured data does under the hood

Structured data is a standardized format for describing and classifying a page's content. In a recipe, for example, the markup states what the ingredients are, the prep time, the temperature and the calories, instead of leaving the search engine to guess this from the running text. Google treats the Search Central documentation as the definitive reference for what it supports, even though the vocabulary comes from schema.org. Not everything that exists in schema.org is used by Google, but that's the foundation.

The documentation's central technical message: mark up only what's visible to the user. In Google's own words, you should not "create blank or empty pages just to hold structured data," nor add markup about information that doesn't appear on the page, even if it's true. Schema is not a place to hide data, and this rule applies equally to the generative era: the model needs to find a match between the markup and the actual content.

JSON-LD, and why it won

Google accepts three formats, all equally valid when well implemented:

The official recommendation is to use JSON-LD whenever the site's structure allows it, because the markup stays isolated from the text and Google can read it even when it's dynamically injected by JavaScript or by CMS widgets. For those working with WordPress, Wix or Shopify who don't edit the HTML directly, the way forward is the structured data plugin or the platform's search settings page.

A recipe JSON-LD block, like the example from the documentation itself, gives a sense of what "describing the page" means in practice:

<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>

Each property labels an element (author, date, rating, ingredients), and it's this granularity that lets the search engine answer by ingredient, calories or prep time. The way I read it: the more content is described in clean entities, the easier it is for a generative system to extract a fact and attribute it to its source.

Complete and correct beats exhaustive

There's a common trap for content teams: filling the markup with recommended properties to "maximize" eligibility. The documentation warns against this. All required properties of a type must be included to be eligible for enhanced display, and more recommended properties help, however, in Google's own words, it's more important to "provide fewer recommended properties, but complete and accurate ones, than to try to fill in every possible one with incomplete, malformed or inaccurate data."

In practice, for a Brazilian MarTech team, this means prioritizing the right type (Article, Product, FAQPage, Recipe, Organization) with the key fields filled in and truthful, rather than spreading half-baked schema across the entire site. It's also worth using properties like sameAs to connect the brand to its official profiles, something Google says it can leverage more broadly and reserve for future search features.

How to validate and monitor

The recommended quality workflow has two distinct moments:

• During development: the Rich Results Test validates the markup and, in some cases, shows a preview of the feature in search.
• After deployment: the rich results status reports in Search Console and the URL Inspection tool confirm that Google actually found the markup, which catches breakages caused by templates or server issues after publication.

Skipping the post-deploy step is where many implementations die: the schema passes the test in a controlled environment and breaks in production because of a poorly rendered template.

Measuring the before and after, Google's way

The point that matters most to whoever is responsible for traffic: the documentation itself proposes a before/after testing method instead of blind faith. The suggested roadmap:

1. Choose pages on the site that don't yet use structured data and that already have several months of history in Search Console. Prefer stable pages, without seasonality, and popular enough to generate meaningful data.
2. Add the markup and confirm, via URL Inspection, that Google found it.
3. Track performance for a few months in the Performance report, filtering by URL to compare the same page against itself.

The documentation is upfront about the noise: a page's views vary for many reasons, so isolating the effect requires a long window and well-chosen pages. As a reference for order of magnitude, the case studies cited by Google show relevant gains in CTR and engagement: Rotten Tomatoes measured 25% higher CTR on pages with structured data, Food Network reported 35% more visits, and Nestlé saw 82% higher CTR on pages appearing as a rich result. These are numbers from the source, from specific sites and contexts, not a promise that transfers to any project.

What remains open for the generative scenario

An important caveat, one of engineering, not marketing: Google Search Central's documentation never mentions AI Overviews nor addresses generative search at any point, it speaks of content understanding by Google Search in general terms. The extension to the generative scenario made in this article is the author's reading, not a promise from Google: structured data improves machine understanding of content, and it's reasonable to assume that this understanding serves as raw material for both rich results and AI features, but this isn't officially documented. Preparing schema is a condition that may help, not a button that switches on citation.

For the Brazilian team, the practical approach I'd follow: standardize Article/Organization/FAQPage in JSON-LD, ensure full correspondence with the visible content, validate in the Rich Results Test, confirm the reading in URL Inspection, and run the before/after Performance test for two to three months before declaring victory. Without measurement, there's no way to separate the schema's effect from normal traffic fluctuation, and it's precisely this discipline of measuring that separates SEO as engineering from SEO as guesswork.