AI Search Ranking Factors: Diagnose the page, not the algorithm

The phrase sounds precise, but it often hides three different questions. The first is eligibility: can the system access and consider the page? The second is relevance: does the page answer the question the person actually asked? The third is selection: among all relevant pages, which source does a particular answer system choose for this query, user, location, time, and product surface?

Publishers can inspect and improve the first two directly. They can also make the page more trustworthy and useful, which may improve its chances of selection. They cannot see or control every internal ranking or retrieval decision. A platform can change its model, search index, source mix, or answer layout without publishing a factor-by-factor scorecard.

I therefore avoid writing claims such as “this heading is a confirmed ranking factor” unless an official source actually says that. A more honest statement is that descriptive headings make the topic easier for people and systems to understand. That is a useful design decision, but it is not a promise of placement.

This distinction prevents two costly mistakes. First, it stops us spending weeks on proxies that do not improve the reader's experience. Second, it stops us publishing confident advice that becomes false when a platform changes. Durable work improves the page's usefulness even when the next model behaves differently.

The most basic factor is whether the relevant system can reach and understand the page. Google's official generative AI guidance says the same SEO best practices remain relevant because AI features are rooted in core Search ranking and quality systems. Ordinary technical hygiene is therefore part of an AI-search strategy, not an outdated separate discipline.

I check the preferred URL, response status, redirect chain, canonical, robots rules, page-level noindex, sitemap entry, internal links, and rendered text. I also check whether the main answer is available without a fragile interaction. A page can use JavaScript and still work well, but important text and links should not disappear when a crawler or reader arrives with a delayed script.

This gate is easy to underappreciate because a local browser may display the page perfectly. Search systems evaluate the delivered document, not the editor's intention. If the canonical points to another URL, the sitemap omits the page, or a staging directive survives production, content quality is not the immediate issue.

A page can mention every important term and still fail the query. Searchers do not arrive with keywords alone; they arrive with a job. “AI search ranking factors” may be an exploratory query from a publisher building an editorial brief, a technical marketer diagnosing a page, or a founder deciding whether to invest in AI-search content. The page needs to state which reader it serves and what decision it helps them make.

I write the job as a verb: diagnose, compare, choose, fix, calculate, learn, or implement. Then I check whether the page's title, opening, examples, and next action support that verb. If the page starts with a broad definition but the reader needs a repair sequence, the first section is misaligned even if the target phrase is present.

Query fit also controls whether a related question belongs on the same URL. A short explanation of schema can sit inside a ranking-factor guide. A full schema implementation tutorial probably deserves a separate page. Splitting by reader job keeps pages useful and prevents a content plan from turning every subquestion into a thin doorway.

Sources matter most where the claim is current, specific, or consequential. Product behavior, pricing, model availability, policies, statistics, technical limits, and legal guidance all need a source trail that a reader can inspect. A long list of links at the bottom does not tell the reader which source supports which sentence.

I use a simple claim register. For each important statement, I record the claim, source, source date, scope, and limitation. Then I place the link close enough to the statement that the relationship is obvious. If a source supports only a narrower claim, I narrow the wording. This creates better content than using a confident sentence and a vaguely related reference.

Evidence does not mean every sentence needs a citation. Common explanations and editorial recommendations can stand on their own. The discipline is to distinguish “Google's documentation says…” from “I recommend…” and from “This is an inference from the available reporting.” That language tells the reader what kind of confidence to apply.

Information gain is the useful difference between this page and the average result. It does not require secret data. It can be a first-hand test, an original table, a calculator, a local market example, a better warning, a decision tree, a workflow, or a synthesis that saves the reader time.

For example, “write helpful content” is a common instruction. A page adds information gain when it shows how to identify the actual user job, how to score a claim register, how to choose between one page and two, and how to measure a change without claiming causation. The reader can act on that sequence. A generic article cannot.

Information gain is also where our 2,500-word content floor should be used carefully. The floor protects substantive pages from being shipped as thin summaries, but it is not a ranking factor and it is not a license to repeat the same advice. Add length only when the topic has enough decisions, examples, evidence, and constraints to support it.

AI answer systems often need to extract a portion of a page while preserving its meaning. Clear structure helps. I use headings that name the question, answer-first paragraphs, tables with explanatory text, numbered workflows, and explicit caveats. A section should still make sense when read without the paragraph immediately before it.

The goal is not to make every paragraph a 50-word snippet. That creates a choppy reading experience. The goal is to make the page's reasoning visible: claim, context, evidence, limitation, action. A well-designed long section can contain several concise paragraphs and one concrete example without sounding like a collection of search snippets.

Tables deserve care. A table is useful when it compresses a decision, such as which evidence to check, what a symptom suggests, and what to do next. A table that merely repeats “easy, fast, powerful” across several products adds little. I explain how to read a table and include the trade-off that prevents a false universal winner.

AI topics decay quickly. A platform can rename a feature, change a plan, retire a crawler, alter a reporting view, or update a policy. A page with a recent-looking date but stale claims is worse than a page that clearly narrows its scope. I list the facts that need future review and give the editor a reason to revisit them.

A meaningful update changes the substance: verify a source, replace an old example, correct a recommendation, add a new limitation, remove a retired product, or improve the workflow. Changing “2025” to “2026” without doing that is not freshness. It is a label.

For current claims, I prefer exact dates where they matter. “Pricing checked August 16, 2026” is more useful than “updated recently.” If the claim is likely to change again, link to the first-party page and avoid copying a number that will be difficult to maintain.

Authority is often reduced to a domain metric, but readers experience it through consistency and depth. A focused cluster should make it easy to move from the broad topic to a platform-specific guide, a comparison, a workflow, and a practical tool. Each page should have a reason to exist and a useful relationship with the others.

For this topic, a sensible path may connect the ranking-factors diagnostic to our AI Overviews optimization guide, the broader AI search visibility guide, the ChatGPT citation guide, and platform-specific pages that follow. Those destinations solve distinct jobs. They are not copies with different headlines.

Internal links do not manufacture expertise. They make the site's existing expertise legible. I use descriptive anchors, link near the point where the next question arises, and remove links that merely increase density. A hub should help a person choose the next page, not ask them to open a random list.

An answer system may satisfy a simple definition without sending a click. That is not automatically a failure. The page's job is to help the reader do something more valuable than receive the first sentence. A working tool, a current comparison, a source table, a decision framework, a downloadable template, or a tested implementation plan can justify the visit.

Do not hide the answer to force engagement. That damages trust and makes the page less useful to every surface. Give the direct answer, then make the deeper work available. A reader who needs only the definition can leave satisfied; a reader who needs to implement the decision has a reason to stay.

This is also where commercial pages should be honest. A tool recommendation should explain who it fits, what it costs or limits, what it replaces, and when not to use it. An affiliate link is not information gain. The useful comparison around it is.

Teams waste time when they treat every visible correlation as a ranking factor. I use three buckets. A signal is a page property that directly improves access, understanding, verification, or usefulness. A proxy is an indirect metric that may correlate with quality but does not explain causation. An anti-signal is a tactic that creates the appearance of optimization while making the page worse.

This framework keeps our content plan grounded. When a proposed change arrives, ask whether it improves a real signal or merely imitates a page visible today. That question is especially important for AI search, where the answer surface and source mix can change quickly.

Bing Webmaster Tools' AI Performance report can show pages cited in supported Microsoft Copilot, Bing AI summaries, and partner experiences, along with grounding queries and citation trends. That is valuable evidence about where Bing's supported AI surfaces are using your content. It is not a universal AI ranking report.

Bing explicitly says the report shows citation activity, not rankings, authority, importance, or the causal effect of a particular update. I would use it to find patterns: which pages are cited, which grouped phrases are associated with them, and which topic gaps deserve an editorial review. I would not say that a citation count proves the page outranks another page or that one rewrite caused a trend.

OpenAI's publisher guidance says public websites can appear in ChatGPT Search and that publishers who want content included in summaries and snippets should avoid blocking OAI-SearchBot. That is an access and eligibility consideration, not a promise of citation. Check robots policy, then focus on making the page useful enough to deserve retrieval.

I use a scorecard to prioritize work, not to pretend that a platform exposes a hidden 100-point algorithm. Score each dimension from zero to two: zero means the page fails or the evidence is missing, one means it is partly adequate, and two means it is strong and verified. The score helps decide what to fix first.

A low score is not a reason to publish a new page. It is a reason to decide whether the URL deserves repair, consolidation, or retirement. A page with strong demand and weak evidence may deserve a rewrite. A page with no distinct user job may be better merged into a hub. This prevents the content calendar from rewarding URL creation instead of useful answers.

When we change a page, I want a record another editor can understand. Choose one URL and one primary job. Capture the baseline. Change a small set of related elements: opening answer, evidence, original example, internal links, and technical access if needed. Do not change the title, URL, body, schema, and navigation in five unrelated ways without recording them.

At the review point, compare impressions, clicks, query variants, index status, internal progression, tool use, qualified outbound actions, and any available citation observations. Treat the result as directional. Search demand and model behavior can change at the same time as the page. The experiment still helps because it creates a more honest record than a post hoc claim that one tactic worked.

A brief should not tell an editor to mention the keyword a fixed number of times, copy the headings from a competitor, add a mandatory FAQ count, or hit a word count by repeating generic advice. Those instructions produce pages that look complete in a spreadsheet and feel empty to a reader.

• Secret-factor claims: “Use this exact phrase to get cited.”
• Guaranteed outcomes: “This schema will put you in AI Overviews.”
• Mass fan-out: “Create one page for every related query.”
• Authority theatre: unsupported superlatives, fake first-hand testing, or unnamed experts.
• Length as a goal: paragraphs whose only purpose is crossing a word threshold.
• Unlabeled inference: treating a citation observation as proof of ranking or causality.

Replace those instructions with an editorial question: what will this page help a specific person do, what evidence will we show, and what will we maintain when the subject changes? That brief is harder to automate and much more likely to create a page worth keeping.