Schema markup and technical access

Does schema markup help me get cited in AI answers?

Not in the way it is usually sold. Google's site-owner documentation for AI features says it directly: "You don't need to create new machine readable files, AI text files, or markup to appear in these features. There's also no special schema.org structured data that you need to add."[^google-no-special-schema]

That is the only operator statement on the subject from a company that runs a major AI answer surface. OpenAI, Anthropic and Perplexity publish crawler documentation and say nothing about structured data as a retrieval input. So the honest position is: one operator says it is not required, and the others have not said anything. Any vendor telling you which schema types raise citation rates is reporting a correlation from their own sample, not a documented mechanism.

Then why implement structured data at all?

Because "not required for AI features" is not "useless", and the real reasons survive the correction.

Rich results in classic Search. Structured data still drives the search features it always drove, and Google's stated eligibility bar for AI features is being indexed and eligible to be shown with a snippet.[^google-snippet-eligibility] Anything that strengthens your ordinary search presence strengthens the pool you are selected from.

Entity disambiguation. Organization markup with a consistent name, URL, logo and sameAs links states unambiguously which company you are. For a brand with a generic name competing against a similarly named entity, that is worth having regardless of AI features, and it costs one block of JSON-LD.

Facts the page asserts about itself. An Article with a real author and a real dateModified, a Product with a real price, a FAQPage whose questions are actually visible on the page. These state, in machine-readable form, the things a source-selecting system cares about: who wrote this, when, and is it current.

Consistency discipline. Google's own fundamentals list includes making sure structured data matches the visible text.[^google-structured-data-match] Maintaining that match forces the discipline of having a real author, a real date and real prices on the page - which is the underlying benefit, with the markup as a by-product.

What none of that supports is the implementation-for-its-own-sake pattern: fifteen schema types on a thin page, FAQPage markup for questions that appear nowhere in the copy, AggregateRating with no real ratings behind it. The last one is not a grey area - emitting a rating you did not collect is fabrication in a format designed to be trusted, and it is the exact failure this guide's editorial rules exist to prevent.

The technical work that does matter

Google's fundamentals list for AI features is short and, unusually for this category, actionable. It asks site owners to ensure crawling is allowed in robots.txt and by any CDN or hosting infrastructure,[^google-crawling-cdn] to make content findable through internal links,[^google-internal-links] and to make sure important content is available in textual form.[^google-textual-form]

Those three sentences cover most real-world invisibility. Expanded:

Fetchability, end to end

Being allowed in robots.txt is necessary and not sufficient. The CDN layer is where blocks actually happen - managed bot rules, rate limits, geographic restrictions, JavaScript challenges. Google names the CDN explicitly, which it would not do if it were rare.

Verify by fetching, not by reading configuration. Request your key pages as each agent and record the status code. A 403 from a bot rule looks identical to a policy decision in a dashboard and nothing like one in your logs.

Rendering

If the answer to the question you want to be cited for only exists after JavaScript executes, you are betting that every fetcher renders. Some do; the guidance to keep important content in textual form exists because not all do.[^google-textual-form] Server-render the substance. Keep interactivity for the parts that are genuinely interactive.

Google's URL Inspection tool shows the HTML Googlebot actually received, which is the fastest way to see the page as a crawler sees it.[^google-inspection-tool] It answers only the Google question, but the class of failure it reveals is platform-independent.

Snippet controls, and their cost

nosnippet, data-nosnippet, max-snippet and noindex are the controls Google names for limiting what is shown from your pages.[^google-snippet-controls] They are the real levers - and they cut both ways, because the eligibility bar for appearing in AI features is being showable with a snippet. Restricting your snippet restricts your AI presence by the same action.

data-nosnippet is the precise instrument: use it on the parts of a page that should never be quoted out of context - a legal disclaimer, a price that varies by contract - while leaving the rest extractable. Most sites either use none of these or apply nosnippet sitewide in a panic. Neither is a decision.

Internal linking

Google lists internal links as a fundamental for AI features.[^google-internal-links] The mechanism is discovery: a page nothing links to is a page that gets crawled late and refreshed rarely. This is the concrete argument for the pillar-and-chapters shape of a guide like this one - each chapter is linked from the pillar and from its siblings, so none of them depends on external discovery.

Crawl budget and politeness

If your site is large, crawl efficiency is a real constraint. Anthropic supports the non-standard Crawl-delay directive for sites that need to slow bots down.[^anthropic-crawl-delay] Use it when a crawler is genuinely costing you capacity - not as a general precaution, since a slower crawl is a staler index.

The failures we see most often

These are ordinary, boring and expensive, and every one of them is invisible in the tools most teams look at.

The bot rule nobody remembers enabling. A managed "block AI scrapers" ruleset in a CDN dashboard, turned on during a scraping scare, never revisited. It blocks the search agents alongside the training ones, because the ruleset was written to a different question than the one the business was asking.

The staging robots.txt that shipped. Disallow: / copied to production during a migration. It usually surfaces weeks later as a mysterious decline, by which time three other changes are in the frame as suspects.

Documentation behind a login. A product's most citable content - the reference docs - gated for no reason anyone can currently articulate. A model cannot cite what it cannot read, and for technical products the docs are the pages that answer the sub-questions best.

The date that is not real. A "last updated" line generated from build time, so every page claims to be updated on every deploy. It is worse than an old date: it trains anything reading your lastmod to ignore it, and it removes your ability to signal a genuine refresh.

Answer text inside a tab or accordion that renders client-side. Common on pricing and FAQ pages, which are exactly the pages you want extracted.

Redirect chains on your most-linked URLs. Every hop is a chance for a fetcher to give up, and the pages with the most inbound links are usually the oldest ones, which are the ones that have moved most.

None of these need a strategy. They need somebody to look, once, with server logs open.

An honest checklist

In priority order, most valuable first, for a site that wants to be cited:

1. Confirm each AI agent can fetch your key pages, at the CDN as well as in

robots.txt, and check the status codes in your logs.

1. Confirm the answer text is present without JavaScript.
2. Confirm your pages are indexed and snippet-eligible - no accidental

nosnippet, no stray noindex.

1. Add a real, visible last-updated date and a named author, and mirror both in

Article structured data.

1. Add Organization markup with consistent identity fields.
2. Add FAQPage markup only where questions and answers are visibly on the page.
3. Link every important page from at least one hub and one sibling.

Items 1 to 3 are where the failures live. Items 4 to 7 are worth doing and are not where your problem is. If a vendor's technical audit spends most of its findings below item 3, it is auditing the easy half.

Structured data as a statement, not a signal

There is a way to think about markup that survives the "not required" finding, and it is worth adopting because it produces better decisions than either enthusiasm or dismissal.

Treat structured data as a machine-readable restatement of things the page already says. Under that rule, every question about whether to add a type answers itself. Does the page have an author? Then say so in the markup. Does it have a price? Say the price. Does it have four visible questions and answers? Mark them up. Does it have a rating? It does not, so there is no markup to write.

The rule also protects you from the failure mode Google names explicitly - markup that does not match the visible text.[^google-structured-data-match] Mismatch is not a small infraction. It is the page telling a machine one thing and a person another, which is the definition of the behaviour every guidelines document exists to prohibit.

And it makes maintenance tractable. Structured data generated from the same source of truth as the page cannot drift; structured data hand-written into a template drifts the first time a price changes. If your markup is not generated from the content, assume it is wrong and check.

What to take from this chapter

Structured data is hygiene with a good return in classic search and a documented non-requirement for Google's AI features. Technical access is the thing that silently removes you from consideration, and it fails at the CDN and the rendering layer far more often than in robots.txt. Spend the effort accordingly - and be suspicious of any AI-visibility programme whose first deliverable is a schema audit, because that is the part the operator told you was not required.