Why Some Pages Get Mentioned in AI Answers and Others Do Not
Separating the part engines publish from the part they never will. What the documented requirements actually say, and why most pages fail before selection is even on the table.
Mostly because of what the engine could use, not what it preferred. Documented factors are mundane: the page has to be fetchable, its content has to exist in real text, and its markup has to match what a visitor sees. Selection logic on top of that is proprietary, unpublished, and changes.
The instinct when a competitor shows up in an AI answer and you do not is to assume you lost a contest.
Usually you were not in one. Most pages are excluded a stage earlier, at the point where the engine tries to fetch and parse them, and never reach the part where anything is being compared.
That distinction is the whole subject. One stage is documented and yours. The other is proprietary and nobody's.
Stage one: could the engine use the page at all
Every answer engine has to do the same unglamorous thing before it can be clever. Fetch a page, parse it, and turn it into statements it can stand behind.
Four ways that fails, all of them mundane, all of them checkable.
The fetch is refused. AI crawlers are published and named. Perplexity publishes its crawlers, including PerplexityBot, which its documentation says is "not used to crawl content for AI foundation models" (Perplexity docs). Anthropic publishes ClaudeBot, Claude-User, and Claude-SearchBot and how to block each (Anthropic support). If your robots.txt, CDN, or bot protection turns these away, everything downstream is moot.
OpenAI states the consequence in plain language for shopping: "some retailers block automated access to their sites. When this happens, shopping research will either skip those sources or rely on other sites with similar products" (OpenAI). Skip, or use someone else. That is the whole mechanism, published.
The content is not in the HTML. A page whose main content assembles after JavaScript runs can arrive at a retriever as a header, a footer, and a hole. Google's list of practices that matter for AI features includes "making sure that important content is available in textual form" (Google Search Central). A human sees a finished page. The machine received a shell.
The page is not indexed. For Google's surfaces this is explicit: "To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet." A page that is not in the index is not eligible, full stop.
The markup contradicts the page. Google's same list says to make sure "your structured data matches the visible text on the page." Markup that disagrees with the page is not a neutral omission. It is a machine-readable statement that happens to be false, on a surface where nothing checks it against the pixels.
None of those four is a competition. They are doors that were locked.
Stage two: the part nobody outside the labs can see
Say the engine could read you. Now it is deciding.
Google describes the shape of the process without describing the logic. Both AI Overviews and AI Mode "may use a 'query fan-out' technique, issuing multiple related searches across subtopics and data sources, to develop a response." So one question becomes a spray of sub-queries, and pages are gathered against subtopics you never saw and cannot see.
The same page adds a caution that undercuts a lot of confident advice: "AI Mode and AI Overviews may use different models and techniques, so the set of responses and links they show will vary." Two surfaces from one company, same query, different links.
OpenAI publishes the factor list for product results without publishing the weighting: structured metadata from first-party and third-party providers, prior model responses, and OpenAI safety and product policies (OpenAI).
That is genuinely as far as the public record goes. Anyone telling you what the ranking function is has either read something the rest of us have not or is guessing with conviction. We walk through the shape of that process in how AI engines decide what to recommend.
The trait people notice, and what it actually is
Look at pages that get drawn on and a pattern shows up: the answer is near the top, stated plainly, in a sentence you could lift out whole.
It is tempting to call this a ranking factor. It is better understood as a parsing property.
An engine composing an answer needs a clean statement it can attribute. A page that gives it one has handed it a usable unit. A page where the same information is spread across three paragraphs of scene-setting, a testimonial, and a table image has the information and none of the usability. The engine has to reconstruct rather than lift.
Same knowledge on both pages. Only one of them is easy to use, and ease of use is not a favor an engine does you. It is arithmetic about what fits in a context window.
The same logic explains why structured data helps without guaranteeing anything. Schema does not vouch for you. It removes ambiguity about what a page is, what it offers, and what it costs, so a machine states a fact instead of inferring one from styling.
Old way, new way
The old way had one currency: position in a list. You either outranked the other page or you did not, and the reason was competitive.
The new way has two gates. The first is technical and binary, and most pages that "lose" actually failed here. The second is competitive and probabilistic, and it is the only part people talk about.
Working on the second while the first is failing is the most common wasted quarter in this whole field.
Why yesterday's readable page stops being readable
Two forces move without anyone touching a page.
Engines change. Google moved AI Overviews to Gemini 3 as the default model (Google), and the prior default was itself a change from the one before it. Retrieval behavior shifts with those updates.
Your site changes faster. Every page you publish that ships without structure lowers the share of your site that is actually readable. A theme update, a plugin change, or a migration can silently remove markup that took a week to add.
So a page you fixed in spring is not a page that stays fixed. That is the argument for a watch rather than an audit, and it is a claim about maintenance, not about outcomes.
The damaging admission
Nothing in this piece will make an engine mention you. We are not going to pretend the second gate is ours to move, because it is not ours and it is not anyone's.
What we will say is narrower and true: if an engine skipped a page it literally could not fetch or parse, that is a fixable problem with a checkable cause. If it read your page cleanly and chose another source, you were at least in the set it drew from, and the next lever is the content itself, not the markup.
Citedon measures readiness and reports whether four engines named you on the queries we ran. We report that as evidence, never as a promise. And the automated fix layer is WordPress-only, applied through the connected plugin with a preview and a per-fix approval. On Shopify, Wix, Webflow, or headless, you get the diagnosis and apply it yourself.
Where to start
Take the page you would most want an engine to draw from. Ask the narrow version of the question: reading only this URL, could a machine pull out a clean, attributable answer, or would it hit layout first.
Run a free scan on that page to see how ChatGPT, Perplexity, Gemini, and Claude read it today, and which of the four doors is closed.