AI search ranking factors: what evidence can actually support

Key takeaways

• Use product-specific evidence: documentation names particular eligibility, retrieval and presentation details.
• Separate eligibility from selection: a page can qualify to appear without being chosen for a particular answer.
• Grade every claim: label it as documented behavior, bounded research, editorial hypothesis or unsupported shortcut.
• Research has scope: an experiment can support a result in its tested setting without forecasting another engine or industry.
• Test the failure you can see: access logs, citations and repeated answer samples answer different questions.

What are AI search ranking factors?

AI search ranking factors are conditions or signals that may affect which pages, entities or products an answer-oriented search experience retrieves, cites or presents. A careful analysis separates confirmed product rules from research findings and from recommendations that still need testing.

The word “ranking” can hide several stages. A search system may decide whether a page is eligible, retrieve candidate sources, rank those candidates for a query, generate an answer, and choose which links to display. A merchant surface can select products under its own criteria. A browser agent may follow a link because it helps complete a user's task. A factor at one stage should not be assumed to govern all the others.

That distinction matters commercially. If a page is not accessible, improving its title may not address the actual failure. If a page is accessible and cited but a buyer's question is not answered, crawler access is no longer the only issue. The ChatGPT citation playbook covers source-level diagnosis; this guide shows how to evaluate factor claims against the product, task and evidence behind each observation.

What do search products document directly?

Documented rules define only their stated scope

Start with rules a provider has actually published. Google says pages need to be indexed and eligible to appear with a snippet to be considered as supporting links in AI Overviews or AI Mode, and says there are no additional technical requirements for those features. That is a documented eligibility condition. It does not say which eligible source will be chosen for every query, how sources are ordered inside an answer, or that one content layout wins consistently.

OpenAI documents OAI-SearchBot as a crawler used to surface websites in ChatGPT search features. It also distinguishes that search crawler from GPTBot, which may crawl material for potential model training, and from ChatGPT-User, which can serve certain user actions. Use those published roles to set access policy; evaluate answer-source selection with visible evidence from the relevant product surface.

A product can disclose a mechanism without exposing every internal decision. ChatGPT search documentation says queries may be rewritten and sent to search providers, while Google's AI-feature guidance describes query fan-out. Those descriptions explain how a question can lead to several retrieval paths; use them to inspect the visible sources for the task being tested.

Treat eligibility and selection as distinct stages. An indexed, snippet-eligible rule sets a threshold for consideration; relevance, passage support and source-link order require separate evidence. A crawler role identifies a request's purpose, so keep access logs beside, but separate from, citation samples.

When a source says there are no additional technical requirements, use that boundary to scope implementation. A separate technical markup or AI-only file is not required for the named feature; publishers still need to meet ordinary search rules and provide material that addresses the query.

Record the scope in the same sentence as the claim. Prefer “Google says an indexed, snippet-eligible page can be considered for supporting links” to “AI search ranks indexed pages.” Prefer “OpenAI identifies this crawler as part of ChatGPT search” to “ChatGPT reads every site with this bot.” Precise language preserves what is useful in the documentation and prevents a narrow instruction from becoming a cross-platform rule.

What does research support about AI search factors?

Research supports bounded hypotheses

Research can test a proposed content intervention under controlled conditions. The GEO paper introduced the term generative engine optimization and evaluated methods intended to affect visibility in generative-engine responses. The paper reports results from its own research environment and notes that efficacy varies across domains. Apply those findings within the paper's tested scope, then evaluate a site's own content and answer surfaces separately.

Before applying a finding, read the method. What queries were used? Which system answered? How were candidate passages changed? What did the researchers count as visibility? How broad was the corpus? The method may reveal that a technique is worth testing, but the external validity depends on how closely the new setting resembles the original one. If the target product, language, market or task differs, call the transfer an experiment rather than a conclusion.

A good evidence note names the exact outcome and comparison. “Adding a citation improved visibility” is incomplete unless the reader can see the baseline, the intervention, the measured response and the context. A paper that tests multiple techniques can support a more careful claim than a single before-and-after screenshot, but even a strong study leaves open whether a page in another category will behave the same way.

Read the reported outcome as the researchers defined it. A visibility measure may describe whether an engine included or surfaced a source under the tested prompts. It is not automatically a measure of qualified visits, sales, trust or durable recognition. If the intervention changes more than one attribute, the result cannot isolate a single factor without a design that separates those changes. Quote the method alongside the finding rather than compressing it into a universal tip.

Research can still be strategically useful when it does not deliver a prediction. It can suggest a low-risk editorial experiment, reveal a mechanism worth studying or show that a claim is more complicated than a slogan. The responsible conclusion might be “this method deserves a local test,” not “the engine rewards this format.” That distinction protects a research program from becoming a list of tactics detached from the original experiment.

Which ranking factors are plausible but unproven?

Many recommendations are sensible for readers without being verified ranking factors. A descriptive heading helps a person find a section. A concise answer can make a passage easier to understand. A table can clarify a product comparison. A named author can show who is responsible for an explanation. These are defensible editorial choices because they improve the page for people; without product-specific evidence, they should not be described as signals that force a model to cite it.

The same caution applies to structured data, freshness and authority language. Structured data should represent visible page content and can make certain information more explicit to software. That fact does not prove that a particular schema field causes an AI answer to select the page. A current date can help a reader understand recency, but changing a date without a material update is not a credible freshness strategy. “Authority” should refer to an identifiable source, expertise or evidence, not an invented score.

Place plausible recommendations in a test queue. State the mechanism you expect, the page or question it concerns, the observation that could falsify the idea and the time when you will review it. If a change improves the user's ability to evaluate the answer but does not move a visibility metric, it may still be worth keeping. The editorial value and the ranking hypothesis are different reasons, and they deserve different decisions.

Freshness is a useful example of the distinction. Correcting an outdated specification protects readers from acting on stale information. Changing a publication date without a meaningful revision does not establish that an engine favors the page. Similarly, structured data can describe visible product information for software, while the presence of a property does not by itself prove that an answer will cite the page. Say what the implementation clarifies and measure any claimed selection effect separately.

Authority language also needs a concrete referent. An author biography, an editorial policy, a cited standard or an independent review can each provide context a reader evaluates. A vague claim that “authority is a factor” gives a team no falsifiable task. Name the source or relationship, specify the user need it supports and keep qualitative review separate from any numerical score.

How can a team evaluate a claimed factor?

Use an evidence ladder. At the top are documented product rules, which can justify a product-specific statement. Next are controlled research results with explicit scope. Below those are repeatable observations from your own sample. Editorial hypotheses are useful but need an honest label. At the bottom are claims that cannot identify a source, method or falsifying observation. The ladder is a review device, not a score assigned to engines.

Translate a proposed factor into an observable change. If the claim is about crawler access, inspect the response and logs. If it concerns source selection, save the answer and cited URLs. If it concerns brand identity, classify aliases and entity references. If it concerns content structure, evaluate whether the intended answer is actually present and whether a reviewer can verify it. One sample should not be used to infer all stages at once.

For an access test, record the exact URL, user-agent, request time, status code, redirect destination, canonical and main content returned. For a citation test, retain the exact question, product surface, answer, source link and the passage that supports the adjacent claim. Store those records beside the hypothesis so another reviewer can classify the outcome without reconstructing the test from a dashboard.

Where practical, compare similar pages or hold a baseline constant. Do not change the title, body, schema and navigation simultaneously if the goal is to learn which intervention mattered. Exact isolation is not always possible in a live site; record the confounders and avoid causal wording when they cannot be controlled. If the sample changes its prompt or product mode, treat that as a different test.

Check whether the observation can distinguish the proposed mechanism from alternatives. A page may change at the same time as its title, price, availability or external references. The product mode may also have changed, or a different query may have been tested. List those competing explanations before drawing a conclusion. If the available data cannot separate them, report that the result is consistent with the hypothesis rather than proof of it.

A useful test begins with a claim narrow enough to fail. For example, a team might ask whether a particular product page is easier to retrieve after it becomes reachable without a challenge. The relevant evidence includes the response observed before and after, the crawler or product being tested, the exact URL and the answer sample. If the answer changes but the crawler path does not, the result does not support a claim that access caused the change.

For example, imagine a product page is absent from an AI Overview. First capture the query and confirm indexing and snippet eligibility. Next, verify that the page addresses the task and that the answer's visible links are relevant to it. If the page is eligible but does not appear, record a selection observation; if it is blocked or misses the question, fix that defect and retest. Keep the query and surface constant when comparing results.

Keep raw observations next to the interpretation. Save the question, response, linked source, timestamp, product mode and any relevant server log. Review how the coding rule treated partial matches, aliases and missing citations. When independent reviewers disagree, refine the rule before publishing a trend. The evidence ladder is useful only if another person can follow the path from source to conclusion.

Keep a claim register beside the experiment. Include the wording, source URL, quotation or measurement method, product scope, date checked and what would change the conclusion. A compact register prevents a slide from detaching a number or sentence from its limitation. It also makes later maintenance easier when a provider changes documentation or retires an interface.

How should SEO teams prioritize known factors?

Start with the defects that have direct evidence and broad user impact. A page that returns an error to a permitted crawler, hides the answer behind an unusable interaction or names the wrong product is a stronger repair candidate than an unverified tactic. These defects directly obstruct the page's intended function, so fixing them is worthwhile before testing speculative ranking tactics.

Then identify the evidence gap. A product comparison should explain the tradeoffs and conditions instead of asserting that one option is best for everyone. A technical guide should name the actual standard and its scope. A policy answer should distinguish the rule from exceptions. Link the primary source and tell the reader when your interpretation begins. For a broader process, the AI search optimization checklist organizes site checks without treating each as a ranking signal.

The evidence ladder helps decide when to stop optimizing. If a provider has documented an access control, implement it correctly and verify the response. If a study offers a promising method, test it on an appropriate page set and record limits. If an idea has no source and no observable outcome, do not let it displace a known customer problem. Product teams can still choose a sensible editorial practice for its human value, but they should not sell that choice as an engine requirement.

Finally, measure the outcome that matches the change. An access fix calls for an access retest; a new source page calls for answer sampling; an improved product page calls for a task-relevant review. Qomvia's Site monitor reports public readiness separately from AI monitor observations. A diagnostic score can help locate exposed checks, but it should not be sold as an engine's ranking calculation.

When the outcome is mixed, keep the layers separate. A page can become accessible without appearing in a later sample, or appear as a citation while still misstating the offer. The access change may still be correct, and the content defect may need a different owner. A factor review is most useful when it ends with a verified repair or a narrower unresolved question rather than a broad claim that the page has been “optimized.”

Use a claim review before publishing a factor list. For each statement, name its evidence class, the product and task it applies to, the exact source and the limitation. Remove a claim when those details cannot be supplied. This helps practitioners distinguish published product behavior from recommendations that still need a test.

Close the review by documenting what would change the conclusion. If a new official source appears, revise the evidence class; if repeated testing disagrees with the claim, narrow the scope or retire it. A dated correction log helps the team distinguish a research update from an editorial preference and prevents an unsupported factor from returning as established fact.

Sources and further reading

• Google Search Central: AI features and your website
• OpenAI: public bot documentation
• OpenAI: ChatGPT search
• Aggarwal et al.: GEO, Generative Engine Optimization
• How to get cited by ChatGPT

Questions

What are the AI search ranking factors?

There is no public universal list. Providers document some eligibility and crawler behavior, while selection methods are not fully disclosed; research findings need to stay within their tested scope.

How do AI search engines rank sources?

The process varies by product and question. Public sources describe parts such as query rewriting or eligibility; use those details and label unobserved selection behavior as a product-specific unknown.

What makes an AI search engine cite a page?

Relevance, availability to the retrieval path and a useful passage all matter. Compare documented eligibility with the citation evidence in the sampled answer.

Does schema markup help a page rank in AI answers?

Structured data should accurately represent visible content. The sources cited here do not establish that a particular field guarantees citation or a higher AI ranking.

Can a study prove a technique works for every model?

No. A study can support a result under its method, corpus and system. Applying it elsewhere is a new hypothesis that should be tested.

How should I test a proposed AI ranking factor?

Define the change and outcome, preserve a baseline, hold conditions steady where practical and save the underlying answers or logs. Report confounders rather than implying causality without evidence.