AI SEO Has No Secret Markup — Audit the Claim, Not the Page

The most important AI SEO deliverable is a falsifiable claim

The fastest way to waste a search budget in 2026 is to approve work because it sounds optimized for an AI model. Google’s own AI-features documentation says there are no additional technical requirements for appearing in AI Overviews or AI Mode, no special schema.org markup, and no need to create AI text files. That does not make technical SEO irrelevant. It makes unsupported “AI optimization” claims unusually easy to test.

This is the distinction many audits miss. A page can be hard to crawl, poorly linked, slow, or impossible for a search engine to interpret. Fixing those problems is ordinary, valuable SEO. But an agency promising that a proprietary heading pattern, an llms.txt file, or artificial “mentions” will unlock Google’s generative results is selling a mechanism it has not demonstrated.

My recommendation is blunt: treat AI SEO as an evidence and systems problem, not a markup category. Require every proposed tactic to identify the search mechanism it changes, the Google documentation that supports the mechanism, and the measurement that could prove the tactic did not work.

Start with Google’s three-layer eligibility model

Google’s Search Essentials describes three layers that determine whether web content is eligible to appear: technical requirements, spam policies, and key best practices. AI search does not replace that model. Google’s AI-features documentation says a page must be indexed and eligible to appear with a snippet in ordinary Search before it can be a supporting link in AI Overviews or AI Mode.

That creates a useful audit sequence:

1. Can Google access and index the page? Check robots directives, status codes, canonicalization, rendering, and internal links.
2. Is the page allowed to compete? Check spam-policy exposure, scaled-content patterns, misleading structured data, and other manual or algorithmic risks.
3. Would a person find it useful? Check first-hand evidence, accuracy, clarity, page experience, and whether the page contributes something beyond a rewritten competitor summary.

Only after those questions are answered should a team discuss how a page might be retrieved for a complex query. The order matters. A beautifully formatted page that is blocked from crawling is not “AI-ready”; it is unavailable. A crawlable page that merely paraphrases ten existing articles is not made distinctive by adding an AI-oriented label.

Google also warns that meeting the requirements does not guarantee crawling, indexing, or serving. Eligibility is a prerequisite, not a ranking promise. A credible audit must preserve that uncertainty instead of turning eligibility language into a forecast.

Query fan-out changes the research brief, not the HTML recipe

Google describes AI Overviews and AI Mode as experiences that may issue multiple related searches across subtopics and data sources. Its generative-AI guide calls this query fan-out and explains that the resulting systems use the Search index to retrieve relevant pages before generating a response.

The practical implication is often misstated. Fan-out means a page may be relevant to a supporting sub-question even when it does not rank for the user’s exact wording. It does not imply that an SEO team should create one thin page for every imagined sub-query.

Google’s guide explicitly says that producing pages primarily to manipulate rankings or generative responses can violate the scaled-content-abuse policy. It also says Google’s systems can understand related meanings without requiring every keyword variation. The right response to fan-out is therefore better coverage of the underlying decision, not a larger URL count.

Consider a retailer publishing a guide to choosing a commercial barcode scanner. A weak AI-search plan creates separate pages for “best barcode scanner,” “barcode scanner for warehouse,” “barcode scanner inventory,” and dozens of near-duplicates. A stronger plan produces one decision guide with first-hand workflow evidence, a comparison table, compatibility constraints, maintenance costs, and links to product or implementation details. The second plan gives a retrieval system more useful passages without forcing the reader or crawler through a keyword maze.

A research brief should ask:

Question	Evidence to require	Bad substitute
What decision does the visitor need to make?	Interviews, support logs, sales objections, product constraints	A list of keyword variants
What facts would change that decision?	Tests, original measurements, named experts, documented experience	A longer introduction
What related questions must the page answer?	A task map with intentional sections and links	One URL per autocomplete phrase
What should remain separate?	Different audiences, products, locations, or transactions	Canonicalized duplicates with different titles

This is content architecture, not a new form of markup. The HTML still needs to expose the content clearly, but the competitive work is deciding what is worth saying and proving.

Structured data is a contract, not a citation slot

Structured data remains useful, but for a narrower reason than many AI SEO sales decks suggest. Google’s structured-data documentation says markup provides explicit clues about the meaning of a page and can make a page eligible for rich results. It also says the markup must describe visible content; adding inaccurate or invisible information can make a result ineligible.

That makes structured data a contract between the rendered page and the search engine. It can clarify that a visible page is an article, product, organization, event, or another supported type. It cannot turn an unsupported claim into evidence or force a generative response to cite the page.

Use this implementation pattern for a product page, with values generated from the same source of truth as the visible UI:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Visible product name",
  "description": "The same claim shown to shoppers",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "199.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

The important engineering control is not the snippet itself. It is the invariant: if the price, availability, or description changes in the storefront, the markup changes with it. Google recommends validating structured data during development and monitoring rich-result reports after deployment. A team that adds markup without a drift check has created a second content system that can contradict the first.

The same rule applies to article authorship, review ratings, business details, and product claims. Fewer complete and accurate properties are better than a maximal object filled with stale or invented values. “AI-readable” is not a license to create a machine-facing version of the page that users cannot see.

The real AI-content audit has two ledgers

Google’s AI-features documentation says AI Overviews and AI Mode traffic appears in Search Console’s overall Web search type. Google’s newer generative-AI guide also recommends monitoring visibility in the available generative-AI performance report. That reporting detail should change how teams evaluate vendors.

Do not accept a single “AI visibility score” that combines ranking, inclusion, citations, mentions, and clicks without showing the underlying events. Keep at least two ledgers:

• Eligibility ledger: crawl status, index status, canonical URL, preview controls, structured-data validity, and Search Console issues.
• Outcome ledger: organic impressions, organic clicks, AI-feature impressions where available, landing-page sessions, qualified conversions, and revenue.

A third operational table is useful for experiments:

change_id, url_or_property, hypothesis, control_state,
implemented_at, recrawl_observed_at, baseline_window,
organic_clicks, ai_impressions, qualified_conversions, decision

This prevents a common category error. If a vendor installs a new script and AI impressions rise, that is a correlation, not proof that the script caused the change. Search systems, query demand, competitors, feature rollouts, and content updates can move at the same time. If the proposed mechanism is not observable, the claim should remain a hypothesis.

Google’s generative-AI optimization guide also supplies a useful negative test: it says there is no requirement to create new machine-readable files or special schema for AI features. Therefore a vendor’s case for a new file should identify a non-Google consumer, a measurable product requirement, or an operational benefit. “Google needs it for AI” is not enough.

Preferred Sources are a product surface, not an optimization hack

There is one Google feature that does introduce a meaningful audience-development action: Preferred Sources. Google’s Preferred Sources documentation says publishers can help readers select a domain as a preferred source, and that selected sites may receive a preferred badge in Top Stories, AI Overviews, and AI Mode. It offers a standard JavaScript button, a custom integration, and a deeplink.

This is not secret schema and it is not a replacement for ranking. It is a user-choice workflow. The distinction matters because the correct work is product design: make the choice understandable, place it near a moment of trust, and measure whether returning users or qualified sessions change. A vendor promising that adding the button will make every page a preferred citation is confusing eligibility and user action with guaranteed distribution.

The implementation is intentionally small:

<script async src="https://news.google.com/swg/js/v1/publisher.js"></script>
<div google-add-preferred-source-btn></div>

Before shipping it, confirm that the site is eligible, the domain scope is correct, consent and localization requirements are acceptable, and the button does not interrupt the primary task. Google says the feature is domain- or subdomain-level; a /blog subdirectory is not itself a selectable preferred source. That is a product and information-architecture constraint worth checking before a campaign begins.

The broader lesson is valuable: when Google exposes a real control, its documentation describes the user action, eligibility boundary, and implementation. When a proposed tactic has none of those, ask what evidence supports it.

A procurement test for AI SEO vendors

Use this five-question test before approving an AI SEO project:

1. What documented mechanism changes? The answer should name crawling, indexing, rendering, content quality, structured-data eligibility, user preference, or measurement—not “the model understands us better.”
2. What does the tactic not change? A serious proposal states its limits. Structured data may support a rich result; it does not guarantee a citation.
3. What page-level or property-level scope is affected? Require exact URLs, domains, templates, and inheritance behavior.
4. What would falsify the claim? Define a baseline, propagation window, comparison cohort, and stopping rule before implementation.
5. Which source was actually read? Prefer Google documentation, Search Console exports, product logs, original tests, or clearly documented first-hand evidence over screenshots of a proprietary score.

Reject proposals that fail the third or fourth question. Unscoped changes are impossible to attribute, and unfalsifiable claims are not strategy.

This approach is compatible with the measurement discipline described in AI search visibility is a recognition problem, where citation and brand recognition are kept separate. It also complements SEO visibility needs an asset-level measurement stack: the unit of analysis should be a page, asset, query class, or user action—not an opaque sitewide score.

Build for useful retrieval, then measure the business result

Google’s documentation does not promise a shortcut into AI search. It points back to a demanding but familiar system: make pages accessible, follow policies, publish distinctive information, represent visible facts accurately, and measure what users actually do.

The winning operating model is therefore simple. Audit technical eligibility first. Invest in original evidence rather than query-shaped duplicates. Treat structured data as synchronized metadata. Instrument organic and generative outcomes separately. Use genuine user-choice features as product experiences, not ranking charms.

If a tactic cannot explain which layer it changes—or cannot survive a controlled measurement plan—it belongs in the “interesting theory” column, not the roadmap. AI search has changed how information is retrieved. It has not suspended the burden of proof.