Skip to main content

What actually changes AI recommendations

The levers people sell you are a mix of documented behaviour, reasonable hypothesis, and folklore. This hub grades each one by the evidence behind it, sets honest expectations about timing, and shows how you would prove any of it worked.

Check technical readiness · Set a baseline before you change anything

Nobody can guarantee an AI recommendation, and nobody can control a model's output — including RankRift. Everything below is graded by evidence, and the unproven items are labelled as unproven.

In short

This hub covers the legitimate work that plausibly changes whether assistants name and recommend a brand: being unambiguously identifiable as a specific kind of company, being present in the sources assistants draw from, publishing comparison and product pages that are quotable and retrievable, earning genuine reviews and third-party coverage, and clearing the technical preconditions. Each lever is labelled documented, plausible but unproven, or unsupported, so you can spend effort in proportion to evidence. It also covers the two clocks that govern timing, how to prove any change actually moved a metric, and the tactics that are liabilities rather than levers.

Who this is for

  • In-house SEO and growth leads who have a baseline and now need a work plan they can defend in a roadmap review
  • Agency strategists who have to tell a client which requested tactic is worth billing hours against
  • Content and PR leads deciding where earned coverage is likely to matter for AI answers
  • Founders being pitched an AI-visibility retainer who want to sanity-check the promised levers
  • Anyone who has been told to do something because a competitor did it

When to use this

  • After you have a measured baseline, so you can attribute anything at all
  • When you are prioritising a quarter of work and need an evidence-weighted ordering
  • When a vendor or colleague proposes a tactic and you want to know which grade it falls into
  • When leadership asks when this will show results and you need an honest answer
  • Before you agree to anything involving seeded discussions, incentivised reviews, or planted text

How we grade a lever

Almost every claim in this category is presented with the same confidence, whether it rests on a provider's own documentation or on one practitioner's anecdote. That is the core problem, so this hub labels every lever with one of three grades and says what would change the grade.

Documented means a provider states the behaviour in its own documentation, and the statement is linked and dated. Plausible but unproven means the mechanism is consistent with how retrieval and generation work and with observable output, but no provider confirms it and no reproducible study establishes it. Unsupported means it circulates widely with no evidence behind it, or the available evidence points the other way.

Grades can move when provider documentation changes or a reproducible external run supports or contradicts a hypothesis. Record the dated evidence and change rather than silently editing the grade.

  • Documented — a provider says so, linked and dated
  • Plausible but unproven — consistent with observed behaviour, not confirmed by anyone who can confirm it
  • Unsupported — widely repeated, no evidence, or evidence against
  • How we decide what counts as evidence

A lever being unproven does not make it worthless. It makes it something you fund cautiously and measure carefully, not something you promise a board.

Lever 1: entity clarity — be unmistakably one specific thing

If an assistant is unsure what category you belong to, whether two spellings of your name are the same company, or what you actually sell, you will be omitted from category answers or described as the wrong kind of business. Entity clarity is making your name, category, offering, location and relationships consistent across your own site and the third-party sources that describe you.

Grade: plausible but unproven as a direct driver of recommendation, with a documented component — structured data and consistent naming are documented inputs to search and knowledge systems that assistants draw on. It is also the cheapest lever, the least risky, and the one that fixes visible factual errors about your company regardless of what it does to a score.

How you would prove it worked: record how assistants describe your company before you start, using a fixed set of identity prompts. After the corrections propagate, re-run the same prompts and compare descriptions, not just mentions. A change in how you are characterised is a cleaner signal than a change in how often you appear.

Lever 2: be present in the sources assistants actually cite

When an assistant retrieves before answering, it reads documents. Which documents depends on the question and the category, and it is measurable: run your prompt set, collect every cited URL, and look at which domains and page types keep appearing. In some categories that is review platforms and trade press; in others it is documentation, forums, or a handful of independent comparison pages.

Grade: documented that cited sources influence the answers that cite them, since the retrieval step is described by providers. Plausible but unproven that placement on a particular publication changes your recommendation rate by any predictable amount. Treat source mapping as a targeting exercise, not a guaranteed pipeline.

The bright line here is absolute. Mapping the sources that get cited and pitching them honestly is earned media. Seeding communities under false identities, buying placement in a supposedly editorial list, or planting text intended to steer an assistant is manipulation, and it is covered on this site only as a risk to detect and avoid.

How you would prove it worked: track citation share for your own properties and mention rate for the prompts served by the source you targeted, before and after the coverage lands, with the same prompt set and enough runs to see past the noise.

Lever 3: comparison and product pages that survive extraction

Assistants lift passages. A comparison page that is one long argument for why you win offers nothing liftable that an assistant can present as balanced, and a product page written in positioning language may contain no extractable fact about what the product does, who it is for, or what it costs to run.

Grade: plausible but unproven as a recommendation driver, and documented as a retrieval precondition — a page that cannot be fetched, rendered, or parsed cannot be quoted at all. The structural half of this work sits in the readiness pillar, and it is the half you can verify directly rather than infer.

In practice that means self-contained sections that answer one question each, terms defined on first use, stable comparison tables with consistent columns, explicit statements of who a product is not for, and specifics rather than adjectives. Writing that an assistant can quote without distorting it tends to be writing a sceptical buyer can use too.

How you would prove it worked: watch citation share for the specific pages you rewrote, and read the passages assistants quote. Getting cited for the right sentence is a measurable improvement even before mention rate moves.

Lever 4: genuine reviews and third-party coverage

Independent descriptions of your product exist in places assistants read, and they carry weight your own marketing copy does not. Asking satisfied customers to review you, responding publicly and honestly to criticism, and making it easy for analysts and journalists to get the facts right are all legitimate and useful regardless of AI.

Grade: plausible but unproven as a lever on AI recommendations specifically, because nobody outside the providers can see how much a given review corpus contributes. Firmly unsupported, and legally risky, is anything involving incentivised, fabricated, or filtered reviews — advertising regulators and the platforms themselves treat that as fraud, and the detection and consequence picture is covered on the risk pillar. That paragraph is general information, not legal advice; get qualified counsel before acting on review or endorsement rules.

How you would prove it worked: pair a review-volume timeline with your framing and sentiment measurements over the same window, and expect a weak, slow, confounded signal rather than a step change.

Lever 5: structural and technical readiness

This is the only layer fully under your control, and the only one where you can verify the outcome directly rather than infer it from generated text. If a retriever cannot fetch your page, render it, or find a coherent passage inside it, none of the other levers can operate.

Grade: documented as a precondition. Crawler access, rendering, and parseable structure determine eligibility, and eligibility is checkable in your own server logs and with your own fetch tests. What remains unproven is the size of the effect on recommendation once you are past the threshold.

How you would prove it worked: log evidence that the relevant crawlers and agents fetched the pages, and a rendering test showing the content is present in what a retriever receives. That is proof of eligibility, which is a real result even when the visibility metric has not moved.

Two clocks, and why nobody can give you a date

Timing questions have two answers because two mechanisms are running. When an assistant retrieves live, a change to your site can reach an answer as soon as the relevant index or fetch path picks it up — that clock is comparatively fast and partly observable in your logs. When an answer comes from training recall, your change reaches it only if and when a model is retrained on data that includes it, and that clock is controlled entirely by the provider and is not published.

So the honest answer to when will we see movement is: it depends which clock the answers for your prompts are running on, and you can find out by measuring rather than guessing. Anyone who quotes you a specific number of weeks is quoting a number they cannot support.

What you can do is instrument the lag. Timestamp the change, keep the prompt set fixed, re-run on a regular cadence, and record when and where any shift appears. Over a few cycles you will have your own empirical answer for your own category, which is worth more than any generic figure.

We do not publish expected timelines, because we have no reproducible basis for one and neither does anyone else.

What not to do, and how to sequence what you should

The unsupported grade covers a lot of ground: files and tags added on faith with no observed effect, keyword-stuffed pages restyled as answers, and the general habit of chasing whatever a conference talk mentioned last month while the entity and structure work stays undone.

Beyond unsupported sits actively harmful. Astroturfed discussions, incentivised or fabricated reviews, doorway and parasite pages, and text planted to manipulate an assistant are covered here only defensively — what they are, how they get detected, and what they cost when they fail. This site does not publish instructions for any of them, and treats them as brand-safety exposure rather than tactics. If a proposed tactic cannot be described to your own customers without embarrassment, that is usually the whole analysis.

For the work that is worth doing, order matters more than intensity. Baseline first, because without one you cannot attribute anything. Then readiness, because it is verifiable and gates everything else. Then entity clarity, because it is cheap and fixes real errors. Then structure and source work, which are slower and need the measurement in place to be judged at all. Change one substantial thing at a time where you can — parallel changes make the eventual movement uninterpretable, and an uninterpretable win is one you cannot repeat.

Frequently asked questions

Which lever should we start with?

Start with the two you can verify: technical readiness and entity clarity. Readiness is checkable in your own logs and fetch tests, so you get proof of eligibility rather than an inference. Entity clarity is cheap and fixes factual errors about your company that are worth correcting whatever a score does. Source work and content restructuring come next, because they cost more and need a working measurement in place before you can judge whether they did anything.

Can you tell us how much any of this will move our numbers?

No, and we will not estimate one. Effect sizes in this category depend on your prompt set, your competitors, the assistants your buyers use, and provider changes nobody outside those companies can predict. Publishing a percentage would mean inventing it. What we can give you is the grading, so you know which work rests on documented behaviour and which rests on a hypothesis, and the measurement method to find out what happened in your own category.

Nobody can guarantee that outcome, because nobody outside the provider controls the output. What an agency can legitimately do is improve retrievability, fix entity confusion, earn coverage in sources that get cited, and measure the result honestly. Ask them which grade each proposed tactic falls into, what evidence supports it, and exactly how they would prove it worked. Vague answers to those three questions tell you what you need to know.

We changed a lot of pages and nothing moved. What went wrong?

Possibly nothing. Check three things before concluding failure. First, whether the answers for your prompts are coming from live retrieval or training recall, because the second clock is slow and outside your control. Second, whether your sample is large enough to detect a change of the size you were hoping for. Third, whether the pages you changed are actually being fetched and rendered — log evidence answers that directly.

Should we write pages targeted at how an assistant phrases things?

Write pages that answer the questions your buyers actually ask, structured so a single passage can be lifted without distortion. That is the overlap between what an assistant can quote and what a reader can use. Writing designed only for extraction, with no reader in mind, tends to age badly and reads as filler to the humans who do arrive. Grade this as plausible but unproven and fund it as content work you would want anyway.

How do we prove our work caused a change rather than a model update?

Usually you cannot prove causation, and you should not claim it. What you can do is timestamp changes, keep the prompt set and cadence fixed, watch competitors in the same runs, and note observable provider changes as confounders in your report. If competitors moved with you, suspect the model. If only you moved, and the timing lines up, you have a defensible association — say association, not cause.

Is adding a file or a tag to our site worth the afternoon?

Grade it before you spend the time. Some proposals are documented by a provider, some are plausible mechanisms with nobody confirming them, and some circulate purely because they are easy to do. Easy and unproven is not automatically bad, but it should never displace the entity and structure work. The failure pattern to avoid is a team that ships three speculative quick fixes while its product pages remain unrenderable.

What if an assistant says something false about us while we are doing this work?

Treat it as an incident, not a visibility problem. Document what was said, with the assistant, date and prompt recorded. Identify the likely upstream source, since assistants usually reflect something published rather than inventing from nothing, and correct that source. Then re-measure with the same identity prompts. The risk pillar covers the sequence in detail; anything touching defamation or legal remedies is general information only and needs qualified counsel.

Record a baseline before you change anything

Every lever on this page is judged by whether a metric moved, which means the measurement has to exist first. Start with a baseline and the readiness checks, then work down the graded list.

Use the manual snapshot as a baseline · Check technical readiness · Learn to measure it properly