Google's AI Overviews arrived in Italy in March 2025 with an immediate and measurable impact on the SERP: blocks of synthesized responses occupying the entire viewport before any traditional organic result. This is not an experimental feature. It's the new reality for millions of informational queries in Italian — and increasingly in English.

The mechanism is now well documented: Google uses its Gemini model to aggregate information from multiple sources, present it as a direct answer, and in some cases cite the pages from which it extracted the content. The click becomes optional. Visibility does not.

The question that matters to any technical SEO is: which signals feed this extraction system? The answer isn't singular, but one element emerges consistently across case studies and official documentation: structured data. Machine-readable markup that no longer serves just to enable rich snippets in the traditional SERP, but to make content interpretable by artificial intelligence systems that don't read between the lines — they follow a precise grammar.

This guide addresses structured data implementation in a technical and operational way. You'll find the most relevant schema types for blogs and business sites, complete and annotated JSON-LD examples, the seven errors that compromise Google's recognition, advanced strategies for intercepting AI Overviews, and an audit method you can apply immediately, with or without paid tools.

This is not a guide for beginners. It's for those who implement schema markup and want to understand why, in 2026, doing it correctly makes the difference between being cited by an AI or being ignored.

What structured data is (and why it's not just about rich results)

HTML for humans, schema markup for machines

HTML describes the visual structure of a page: headings, paragraphs, images, links. A crawler knows that <h1> probably contains the main title, but it doesn't know whether the page is about a recipe, an event or a company profile. Semantic markup adds that layer of interpretation.

Structured data consists of formal annotations that explicitly declare the type of content and its properties. They follow a shared vocabulary defined by Schema.org, a collaborative project launched in 2011 by Google, Microsoft, Yahoo and Yandex. The vocabulary covers over 800 entity types, from Article to MedicalCondition, from Product to Event.

The principle is simple: instead of letting the search engine infer meaning from text, you explicitly declare "this is an article, published on this date, written by this author, belonging to this organization". Ambiguity disappears. The trust of the parsing system increases.

Until 2024, the main incentive to implement structured data was to obtain rich results: star ratings, sitelink search boxes, expandable FAQs in the SERP, recipe carousels. Visual features that increase CTR. Useful, but not critical.

With the advent of AI Overviews, the incentive shifts to a different level. Markup no longer serves just to make the SERP visually richer: it serves to make content extractable by a language model that must synthesize a response. This is a fundamental distinction.

How Google uses schema markup to build AI overviews

Google has not published exhaustive documentation on how Gemini uses structured data to generate AI Overviews. But from analyzing cited pages and tests published by the SEO community in 2025, some constants emerge.

Pages appearing in AI Overviews for informational queries tend to have:

  • Article or BlogPosting schema type with updated datePublished (machine-verifiable content freshness)
  • FAQPage or HowTo that structure the response in already-aggregated form
  • author with Person markup linked to Organization
  • breadcrumbList signaling the content's position in the site architecture

The logical pattern is understandable: a model that must generate a synthetic response will preferentially start from sources that have already organized information in a structured and verifiable way. A page with FAQPage explicitly states: "this is a question, this is the answer." A language model doesn't need to infer that structure from raw text.

Additionally, structured data contributes to E-E-A-T evaluation (Experience, Expertise, Authoritativeness, Trustworthiness). When an article declares an author with sameAs pointing to a verified LinkedIn profile, linked to an organization with url and logo, Google can correlate that digital identity with authority signals from other systems.

JSON-LD vs Microdata vs RDFa: which to choose in 2026

There are three formats for implementing structured data. The choice matters.

FormatWhere it goesSeparation from contentGoogle supportRecommended
JSON-LD<script> in <head> or <body>High: markup doesn't touch the HTMLComplete, preferredYes
MicrodataInline attributes in HTML elementsLow: intertwined with markupCompleteNo (legacy)
RDFaInline attributes, W3C standardLow: intertwined with markupCompleteNo (specific use cases)

Google explicitly recommends JSON-LD in the official developer documentation. The reasons are technical and practical:

  • JSON-LD lives in a <script type="application/ld+json"> tag separate from the DOM: modifying it doesn't require touching the page's HTML
  • It can be injected dynamically by JavaScript (with some caveats, discussed later)
  • It's easier to validate, version and maintain
  • It doesn't risk introducing markup errors in semantic HTML tags

Microdata and RDFa predate JSON-LD becoming the de facto standard. They're still supported, but the technical debt of managing them in complex projects is high. In 2026 there is no valid reason to choose them for a new project.

The most important schema types for blogs and business sites

Article and BlogPosting

Article is the base type for editorial content. BlogPosting is a subtype (more specific, preferable for blog posts). Both belong to the Thing > CreativeWork > Article hierarchy.

The essential properties Google considers for rich results and semantic indexing are:

  • headline: the article title (no more than 110 characters)
  • datePublished: ISO 8601 date (e.g. 2026-03-16)
  • dateModified: date of the last significant modification
  • author: Person or Organization object
  • publisher: Organization object with logo
  • image: absolute URL of a representative image
json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Schema markup 2026: how to optimize structured data for AI overviews",
  "datePublished": "2026-03-16",
  "dateModified": "2026-03-16",
  "description": "Technical guide to JSON-LD structured data: implementation, common errors and strategies for Google's AI Overviews.",
  "image": {
    "@type": "ImageObject",
    "url": "https://www.perseodesign.com/images/schema-markup-ai-overviews-2026.jpg",
    "width": 1200,
    "height": 630
  },
  "author": {
    "@type": "Person",
    "name": "Perseo Design",
    "url": "https://www.perseodesign.com/about/",
    "sameAs": ["https://www.linkedin.com/company/perseodesign/"]
  },
  "publisher": {
    "@type": "Organization",
    "name": "Perseo Design",
    "url": "https://www.perseodesign.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.perseodesign.com/images/logo.png",
      "width": 300,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.perseodesign.com/en/blog/schema-markup-structured-data-ai-overviews-2026/"
  }
}

FAQPage and HowTo (the formats AI prefers for generating responses)

FAQPage is the schema type with the highest implementation-to-impact ratio in the context of AI Overviews. It explicitly declares question-answer pairs — the exact format a language model uses to generate synthetic responses to interrogative queries.

The structure requires each pair to be a Question object with an acceptedAnswer property of type Answer.

json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is structured data and what does it do for SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Structured data consists of machine-readable annotations that explicitly declare the type of content on a page and its properties, following the Schema.org vocabulary. For SEO it serves two distinct purposes: enabling rich results in the traditional SERP (stars, expandable FAQs, carousels) and making content interpretable by AI systems like Google AI Overviews."
      }
    },
    {
      "@type": "Question",
      "name": "Is JSON-LD the best format for structured data?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Google recommends JSON-LD as the preferred format for structured data. Compared to Microdata and RDFa, JSON-LD is separate from the page's HTML, simpler to maintain and validate, and can be injected dynamically. For any new project in 2026 it is the correct choice."
      }
    }
  ]
}

HowTo is equally relevant for procedural content. It structures a series of steps with name, text and optionally image for each. Google uses it to generate responses to "how to do X" queries.

json
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "How to add JSON-LD markup to a WordPress page",
  "description": "Technical procedure for inserting JSON-LD structured data in WordPress without a plugin, directly in the theme template.",
  "totalTime": "PT15M",
  "supply": [
    {
      "@type": "HowToSupply",
      "name": "Access to functions.php or child theme"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Open the functions.php file",
      "text": "Access the theme editor in WordPress (Appearance > Theme Editor) or open the functions.php file via SFTP in the active child theme."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Add the JSON-LD output function",
      "text": "Use the wp_head hook to inject the script tag with the markup. Condition the output on page type with is_single() or is_page() to avoid markup on inappropriate pages."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Validate with the Rich Results Test",
      "text": "Paste the page URL at https://search.google.com/test/rich-results to verify the markup is detected correctly and there are no property errors."
    }
  ]
}

BreadcrumbList signals to Google the document's position in the site's information tree. It has two concrete functions: displaying the navigation path in rich results and reinforcing the site structure for crawling.

json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://www.perseodesign.com/en/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://www.perseodesign.com/en/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema markup and AI Overviews 2026",
      "item": "https://www.perseodesign.com/en/blog/schema-markup-structured-data-ai-overviews-2026/"
    }
  ]
}

Organization and WebSite (domain authority signals)

Organization and WebSite don't generate rich results, but are fundamental as domain identity signals. Google uses them to build the Knowledge Graph related to the entity managing the site.

WebSite with potentialAction of type SearchAction enables the sitelinks search box, but regardless of this feature, the explicit declaration of name, url and sameAs strengthens the correlation between the site and its digital presences.

json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Perseo Design",
  "url": "https://www.perseodesign.com",
  "logo": "https://www.perseodesign.com/images/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "areaServed": "IT",
    "availableLanguage": ["Italian", "English"]
  },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Florence",
    "addressCountry": "IT"
  },
  "sameAs": [
    "https://www.linkedin.com/company/perseodesign/",
    "https://github.com/perseodesign"
  ]
}

This type of schema should be inserted in the <head> of every page on the site, not just the homepage. Repeating Organization on every page is not an error — it's best practice.

How to implement JSON-LD correctly

Where to insert the script tag

The <script type="application/ld+json"> tag can be inserted in the <head> or <body>. Google explicitly states it supports both positions, but the established practice — and the one recommended for code readability — is in the <head>.

Positioning in the <head> ensures the markup is available to the parser before the body renders, which is relevant if the site uses partial server-side rendering. In cases of Single Page Applications (React, Vue, Svelte), the markup must be available in the DOM at the time of Googlebot's crawl, not after hydration. See the JavaScript SEO guide already published on this blog for the technical detail.

A justified exception to <head> positioning: when markup is generated dynamically by PHP or a template engine based on page content, it may be more practical to inject it before the closing </body>. This is not a problem for Google.

Annotated base BlogPosting example

html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  /* The main type: BlogPosting is a subtype of Article, more specific */
  "@type": "BlogPosting",

  /* headline: the exact article title, max 110 characters */
  "headline": "Schema markup 2026: how to optimize structured data for AI overviews",

  /* datePublished: ISO 8601 format with optional timezone */
  "datePublished": "2026-03-16T08:00:00+01:00",

  /* dateModified: update every time content is modified significantly */
  "dateModified": "2026-03-16T08:00:00+01:00",

  /* image: required for Article rich results */
  "image": {
    "@type": "ImageObject",
    "url": "https://www.perseodesign.com/images/schema-markup-2026-og.jpg",
    "width": 1200,
    "height": 630
  },

  /* author: the person or organization that wrote the content */
  "author": {
    "@type": "Person",
    "name": "Perseo Design Team",
    "url": "https://www.perseodesign.com/about/",
    /* sameAs: links the author to verifiable external profiles */
    "sameAs": "https://www.linkedin.com/company/perseodesign/"
  },

  /* publisher: the organization publishing the content */
  "publisher": {
    "@type": "Organization",
    "name": "Perseo Design",
    "url": "https://www.perseodesign.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.perseodesign.com/images/logo-schema.png",
      "width": 300,
      "height": 60
    }
  },

  /* mainEntityOfPage: the canonical page for this content */
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.perseodesign.com/en/blog/schema-markup-structured-data-ai-overviews-2026/"
  },

  /* keywords: optional, but useful for semantic context */
  "keywords": ["schema markup", "structured data", "AI Overviews", "JSON-LD", "technical SEO"],

  /* inLanguage: explicitly declares the language */
  "inLanguage": "en-US"
}
</script>

Note: The /* */ comments are included for illustrative purposes. Standard JSON does not support comments. Remove them in production code.

How to nest schema (Article, Author, Organization)

Nesting allows building a graph of correlated entities that Google can use for semantic enrichment. The Article -> Author (Person) -> Organization pattern is one of the most effective for signaling E-E-A-T.

json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Article title",
  "datePublished": "2026-03-16",
  "author": {
    "@type": "Person",
    "name": "Perseo Design Team",
    "jobTitle": "SEO Specialist",
    "worksFor": {
      "@type": "Organization",
      "name": "Perseo Design",
      "url": "https://www.perseodesign.com",
      "foundingDate": "2012",
      "areaServed": {
        "@type": "City",
        "name": "Florence"
      }
    },
    "sameAs": [
      "https://www.linkedin.com/company/perseodesign/"
    ]
  }
}

Using @id allows referencing the same entity in multiple places in the markup without redefining it. If Organization is defined with "@id": "https://www.perseodesign.com/#organization" in a separate block, subsequent blocks can reference it with just {"@id": "https://www.perseodesign.com/#organization"}.

WordPress: plugins vs manual code

ApproachProsCons
Yoast SEOGuided setup, full coverage of basic typesGenerated schema difficult to customize, JS overhead
RankMathVisual schema builder, advanced type supportLess granular control over the final JSON
Manual code (functions.php)Total control, no plugin overheadRequires maintenance, no UI for content team
Lightweight custom pluginControl + maintainable structureDevelopment time

The choice depends on context. For a site managed by a non-technical content team, Yoast or RankMath cover 90% of cases. For a site with complex architecture or custom schema (events, products, courses), manual code or a custom plugin is preferable to avoid the plugin generating incorrect or incomplete markup.

The 7 most common errors in structured data

1. Content not matching the page

The fundamental principle of Google Search Central is that markup must describe content visible on the page, not information that is absent or different. Adding a FAQPage with questions that don't appear in the text, or a Product with a price that doesn't match what the user sees, is a violation of Google's guidelines.

Google can penalize pages with misleading markup by applying a specific manual action for "misleading structured data". The verification is simple: every markup property must have a verifiable counterpart in the DOM.

2. Missing or conflicting canonical tag

The mainEntityOfPage in the markup points to the canonical URL of the page. If this URL differs from the <link rel="canonical"> tag in the head, a conflict is created that the crawler must resolve. Google generally gives priority to the canonical tag, but the discrepancy creates uncertainty in markup evaluation.

Typical case: an article published on two URLs (with and without trailing slash, or with UTM parameters) where the markup points to one URL and the canonical to another. The right tool to detect this type of conflict is a technical audit that reads both HTTP headers and the rendered DOM.

3. Schema markup on noindex pages

Markup on pages with <meta name="robots" content="noindex"> or HTTP header X-Robots-Tag: noindex is irrelevant: those pages are not indexed and their markup contributes neither to the Knowledge Graph nor can it generate rich results. It's not technically an error, but it's noise in the code.

The most critical case is the opposite: pages that should have schema markup (articles, products, FAQ pages) that are accidentally excluded from the index due to an erroneous noindex. The audit must cross-reference indexing status with markup presence.

4. Missing required properties

The Rich Results Test distinguishes between errors (missing required property) and warnings (missing recommended property). Required properties vary by schema type. For Article: author, datePublished, headline, image, publisher. For FAQPage: mainEntity with at least one Question object. For HowTo: name and at least one step.

Missing a required property doesn't cause a direct penalty, but prevents generating the corresponding rich result. The markup is still read by Google for semantic enrichment, but the main incentive (SERP visibility) disappears.

5. Incorrect nesting or incompatible schema types

A frequent error in sites with manually implemented markup is using incompatible types as property values. For example, using "author": {"@type": "Organization", ...} when Schema.org spec for Article.author accepts both Person and Organization, but many validation tools expect Person for editorial content.

A more serious error is circular nesting or referencing @ids not defined in the document. The Rich Results Test flags these cases as "unknown property" or generates a silent parsing error.

6. Duplicate or conflicting structured data

This happens when a CMS plugin automatically generates an Article and the theme adds a second Article block with different properties for the same page. Google receives two contradictory declarations about the same entities.

It's not precisely defined in the documentation which markup prevails. In practice, Google chooses non-deterministically, which means rich results can appear and disappear without an apparent cause. The audit must verify that for each schema type there is only one block per page.

7. Not updating schema after content changes

dateModified is not just a formality: it signals to Google that the content has been updated. If you update an article without updating dateModified, the markup declares that the content has remained unchanged since the original publication date, which affects freshness evaluation.

Even more critical: if you update a FAQ on the page but don't update the FAQPage markup, AI Overviews may extract the obsolete answer from the structured markup, not the updated one in the text. Schema must faithfully reflect the current state of the content at all times.

How to audit your site's structured data

Google Rich Results Test: how to read it

The Rich Results Test accepts a URL or direct HTML code. It analyzes the rendered markup (after JavaScript execution) and shows:

  • Detected schema types
  • Required properties present and missing
  • Warnings for absent recommended properties
  • A rich result preview (when applicable)

The important detail is "rendered": the test executes JavaScript before analysis, so it's reliable even for sites with dynamically injected markup. It's not a bulk audit tool, but it's the starting point for any single-page markup debugging.

Google Search Console: enhancements section

Search Console aggregates markup data for the entire site in the "Enhancements" section. For each detected schema type it shows:

  • Number of pages with critical errors
  • Number of pages with warnings
  • Number of valid pages
  • Trend over time

This is the fastest way to identify regressions: if a deploy introduces an error in the markup template, the number of pages with errors rises immediately. Search Console can send email notifications for these events.

Bulk audit across the entire site

For sites with dozens or hundreds of URLs, manual page-by-page analysis is not practical. Bulk validation requires a tool that crawls the entire sitemap, analyzes markup on each URL, and aggregates the results.

PerSeo Insights is one of the tools that allows this type of analysis directly from a sitemap. By entering the sitemap.xml URL, the tool analyzes each page and returns for each: the presence of JSON-LD and Microdata, detected schema types, property errors, plus data on Core Web Vitals, meta tags and canonical. Useful for a quick initial mapping of markup status on existing projects, without configuration.

For larger datasets (enterprise sites with thousands of URLs) or analyses requiring greater reporting granularity, Screaming Frog SEO Spider with custom XPath extraction is the market standard. The typical workflow involves extracting the content of the <script type="application/ld+json"> tag from each URL and then parsing it with a Python script or importing it into a spreadsheet for analysis.

Screaming Frog configuration for JSON-LD extraction:

  1. Configuration > Custom > Extraction
  2. Add a column with XPath: //script[@type='application/ld+json']
  3. Extraction type: "Extract Inner HTML"
  4. Crawl the site with JavaScript rendering enabled (requires Screaming Frog + Spider JS)

The result is a CSV column with the raw JSON from each page, analyzable programmatically.

Structured data and AI overviews: advanced strategies

Why FAQPage and HowTo increase the probability of being extracted by AI

Google's AI Overviews respond primarily to queries with informational intent. The model must construct a coherent response by synthesizing multiple sources. Its preferential behavior — documented empirically by researchers like Mordy Oberstein and the SEO experimenter community — is to start from sources that have already formalized the question-answer structure.

FAQPage does exactly this. Each Question object with its acceptedAnswer is a semantically complete pair that the model can cite directly or paraphrase. The markup reduces interpretive ambiguity to a minimum.

HowTo works similarly for procedural queries ("how to", "how to configure", "how to install"). The step structure with name and text for each one is almost identical to the output format AI Overviews use to respond to this type of query.

Structuring responses for semantic extraction

The strategy doesn't stop at markup. The textual content must be coherent with the structure declared in the schema. FAQs must be present in the page text, not just in the markup. The steps of a HowTo must be reproducible on the page as identifiable sections.

Some practical indications that emerge from analyzing pages most frequently cited in AI Overviews:

  • FAQ answers in the markup are concise (50–150 words) and self-contained — they don't require additional context to be understood
  • H2 and H3 headings correspond semantically to the FAQ questions (not necessarily word for word, but topically)
  • The text under each heading answers a single question or describes a single concept, without tangents

This coherence between HTML structure, textual content and structured markup is the strongest signal you can send to a semantic extraction system.

The role of author + organization in E-E-A-T

Google evaluates E-E-A-T at the page, site and author level. Structured data contributes to the "machine-verifiable" component of this evaluation.

Declaring an author with sameAs pointing to externally verifiable profiles (LinkedIn, Google Scholar for academic contexts, profiles on industry platforms) allows Google to correlate the author's identity with authority signals from independent sources. An author with a verifiable editorial history on multiple platforms carries different weight than an author declared only in markup with no external references.

The same applies to Organization. Declaring foundingDate, address, areaServed and sameAs with links to verifiable profiles (Google Business Profile, Wikidata if available, profiles on industry directories) builds an entity representation that goes beyond the single website.

This is not a direct ranking signal, but it's an input for domain trust evaluation that influences which sources Google cites in AI Overviews for queries where authority is relevant.

Schema markup and llms.txt: complementary signals

The llms.txt file (proposal by Jeremy Howard, 2024) is an emerging convention for communicating to language models which site content is available for processing and in what format. It's not a formal standard, and has no official Google support at the time of this guide's publication, but its adoption is growing among technical sites.

The relationship with structured data is one of complementarity, not overlap. Schema markup provides structured semantic metadata to individual pages, readable during crawling. llms.txt provides an overview of the site and its resources, designed for systems that process the site as a corpus.

For sites wanting to maximize readability by AI systems, the combination of complete schema markup and llms.txt is more effective than implementing only one of the two. Schema markup remains the primary tool, with documentation and official support from Google. llms.txt is an additional signal with still-uncertain time horizons.

Audit checklist: 10 points for verifying structured data

Before publishing or after any significant site changes, this checklist helps identify the most common issues in structured markup.

  1. Does every indexed page have at least one relevant schema? Verify that articles, product pages, category pages and the homepage have the appropriate schema type.
  2. Are all required properties present? For Article/BlogPosting: headline, datePublished, author, image, publisher. Validate with the Rich Results Test.
  3. Does dateModified correspond to the actual last modification? Compare the value in the markup with the real date of last content modification.
  4. Is the markup content visible on the page? Every FAQ, every HowTo step, every piece of information in the markup must have a verifiable textual counterpart in the DOM.
  5. Does the URL in mainEntityOfPage match the canonical? Compare "@id" in the markup with the value of the <link rel="canonical"> tag.
  6. Are there no duplicate blocks of the same type? Check that there aren't two Article or two FAQPage blocks for the same page, generated by different plugins or templates.
  7. Do noindex pages have no productive markup? Markup on noindex pages is irrelevant. Removing it reduces noise.
  8. Does author.sameAs point to active and verifiable profiles? Verify that external links in sameAs resolve correctly and point to the right profile.
  9. Is the JSON-LD markup valid JSON? Syntax errors (missing commas, unclosed brackets) silently invalidate the block. Validate with jsonlint.com or equivalent.
  10. Does Search Console report active errors or warnings? Check the Enhancements section for any regressions introduced by recent CMS, theme or plugin updates.

For a large-scale audit covering the entire sitemap, tools like PerSeo Insights (for quick URL-by-URL analysis on medium-sized sites) or Screaming Frog (for enterprise datasets) allow automating points 1, 2, 4, 5 and 6 with a single crawl.

Reference documentation for schema types supported by Google is available at developers.google.com/search/docs/appearance/structured-data. The complete Schema.org vocabulary is at schema.org/docs/full.html.

Structured markup is not an optional component of technical SEO in 2026. With AI Overviews intercepting a growing share of informational queries, the machine-readable legibility of content has become a prerequisite for organic visibility, not a competitive advantage. Sites that invested in correct implementation over the last two years are reaping the results in terms of citations in AI blocks. Those that didn't are facing a longer recovery than expected.