Simulate Google AI Overviews With LLM Prompts to Test Pages
Asking one model whether it would cite your page is a null test. Run a blind, repeated bake-off against real rivals and score what actually moves.
You cannot query Google's AI Overview system directly, so every citeability test is a proxy. The only question worth arguing about is whether the proxy is honest. Most attempts to simulate Google AI Overviews are not: paste one page into a chat window, ask the model whether it would cite it, and it says yes. It says yes to almost anything. Here is the harness to use instead, and the scoring that turns its output into an editorial decision.
Why Google AI Overviews reward citation, not ranking
Classic ranking is a sort. An AI Overview is a selection. The answer gets assembled from retrieved passages and links attach to the ones it leaned on, so a page at position eight can be cited while position two is ignored. Ranking gets you into the retrieval pool. It does not get you into the answer.
Pew Research Center tracked real browsing behaviour in March 2025 and found users clicked a result link on 8% of visits where an AI summary appeared, against 15% of visits without one. The click you won by outranking someone is now won by being the passage the summary is built from. The traffic that survives is still worth defending, as clicks still matter despite AI Overviews argues.
Which citeability signals you can test, and which you cannot
Google's guidance for AI features is short on levers and long on principles: original, clearly sourced, people-first content, plus the technical basics that let a page be crawled and understood (Google Search Central, AI features and your website). Split that into two piles before building anything.
- Testable offline: whether a passage answers the query without the rest of the page, whether your distinctive claim survives extraction, and whether scope and date are stated.
- Not testable offline: retrieval, domain-level trust, links, engagement, and everything Google knows about your site that a pasted text file does not carry.
The blind bake-off: a fair way to simulate Google AI Overviews
Here is the failure mode in every "would you cite this?" workflow. It tests your page alone, with your brand attached. An AI Overview never sees one page. It sees competing passages and picks among them. Grading a solo contestant tells you nothing about the contest.
So make it a contest. Call it the blind bake-off. It has what the solo prompt lacks: rivals, anonymity, a control.
- Pull the current top results for your target query. Five is enough. Copy each main body text into a text file.
- Add your draft as the sixth passage, then strip every brand name, byline, URL and self-reference from all six. Leave "at Ahrefs we found" in place and you are grading reputation, not text.
- Number them 1 to 6 and reshuffle the order every run. Position bias in long contexts is real; skip the shuffle and you measure it instead of your writing.
- Ask for an answer of roughly eighty words using only the numbered passages, citing the numbers behind each sentence.
- Run it ten times. Then swap your passage for the control, the version before your edit, and run ten more.
Two numbers no solo prompt gives you: how often your passage gets picked on text alone, and how much of that traces to your edit.
Prompt recipes you can paste today
Recipe 1 - the bake-off run
Using ONLY the numbered passages below, answer the question in 80 words or fewer. After each sentence, cite in square brackets the passage numbers it came from. If passages disagree, follow the best-supported one and say which. Do not use outside knowledge. Question: [query]. Passages: [1-6].
Temperature matters more than model choice. Run the set at temperature 0 for a reproducible baseline, then repeat at 0.7 to see which passages survive sampling noise. A passage that only wins deterministically is fragile.
Recipe 2 - the extraction probe
From the passage below, list every factual claim a search engine could quote verbatim as an answer. For each, give the exact sentence and rate how self-contained it is: standalone, needs one sentence of context, or needs the whole section.
This is the one solo prompt worth keeping, because it grades structure rather than quality. Anything rated "needs the whole section" will not be quoted, however good it is.
Recipe 3 - the attribution stress test
Answer the question using the passages. Then, for every sentence in your answer, name the passage it came from and quote the words that support it. If no passage supports a sentence, mark it UNSUPPORTED.
Unsupported sentences are what the model would rather invent than take from your corpus. Each one is a claim nobody in the top results has written down, which makes that list a content plan.
Scoring the output: cite share, carry rate, drift band
Model output is prose. Editorial decisions need numbers, so reduce every run to three.
- Cite share. The fraction of runs where your passage number appears. Cited in six of ten runs is 0.6.
- Carry rate. Of the distinctive claims only your page makes, how many reach the summary. Seed three or four deliberately, then count them out.
- Drift band. Rerun the unchanged corpus ten more times. The spread between highest and lowest cite share is your noise floor.
The drift band is the step every simulation writeup skips, and the one that stops you shipping superstition. If your control scores 0.5, your variant 0.6, and the untouched corpus wanders between 0.4 and 0.7 on its own, you have measured nothing. Ship only when the gap clears the band. At temperature 0 the band is usually narrow; at 0.7 it rarely is.
Fixes that follow from a losing run
A low cite share is a diagnosis, not a verdict. The output names the passage that beat you and quotes the sentence it took, so the fix list is short and ordered.
- Lead the section with the answer. Bury the claim three paragraphs down and a retriever chunking the page cuts it away from the question it answers.
- One claim per paragraph. Extraction probes rate bundled paragraphs as "needs the whole section" every time.
- Own a number nobody else has, and date it. Dated figures get quoted verbatim; adjectives get summarised away.
- Put the definition beside the term, not in a glossary four screens down.
- State scope out loud: who it applies to, when it was measured, what it excludes. Models reuse hedges they are given.
- Then do the unglamorous technical work. Structured data will not make weak text citeable, but an uncrawlable page never enters the pool (Google Search Central, intro to structured data).
Wiring re-simulation into your publishing pipeline
One-off tests are a party trick. The value arrives when the harness becomes a gate. Keep each corpus as a text file beside the draft, one per target query, and run the bake-off as a pre-publish check on anything new.
Re-run the same corpus quarterly on revenue pages. Rivals edit their passages too, so a cite share won in March is not one you hold in September. Prioritise by money, not curiosity: test where a lost citation costs a booking.
Building the query list stalls most teams, and it needs no subscription. A prompt-driven brainstorm gets you there, following the workflow in building a free keyword research workflow. Log date, model version, query, cite share and carry rate, so you know whether your page changed or the model did.
Limits of the proxy and what to watch next
Be blunt about what this is. You are running a different model, on a corpus you assembled by hand, with no retrieval step and no ranking signals. It cannot tell you whether Google will surface the page, only whether your text wins a fair fight on words alone, which is the only part you control.
Three failure modes. Models are agreeable, so any prompt carrying your brand name inflates the score, which is why anonymising is not optional. Long contexts favour whatever sits at the top, so neither is the shuffle. And every finding is stamped to one model version, so re-baseline when your provider ships a new one.
Watchlist for the rest of 2026: Google's AI features guidance, where citation behaviour changes surface first, and your own referral data, the only ground truth you own. Pair this page-level harness with the brand-level sweep in a practical AI visibility brand test and the reporting layer in metrics for generative engine optimization.
How VarynForge fits in
A bake-off is only as good as the queries you point it at, and hand-picking those is where most teams stall. VarynForge reads your site first, maps the niche, and hands your agent a ranked set of opportunities labelled against what you already cover, so the runs you spend go to queries with something left to win. Start a free project and see the ranked list.
Key Takeaways
A solo "would you cite this?" prompt is a null test, because the model agrees with almost anything you hand it. Make the simulation competitive, blind and repeated and it starts producing decisions instead of reassurance. Anonymise your draft against five real rivals, reshuffle every run, score cite share and carry rate, then measure both against a drift band from the unchanged corpus. Ship only when the gap clears that band, and treat every result as a proxy stamped with a model version and a date.
Further Reading
- Google Search Central: AI features and your website
- Google Search Central: Creating helpful, reliable, people-first content
- Pew Research Center: Google users are less likely to click when an AI summary appears
- Anthropic: Prompt engineering overview
Sources
Frequently asked questions
Can simulating AI Overviews with an LLM reliably predict what Google will cite?
No, and any workflow that claims otherwise is selling you something. You are running a different model on a corpus you assembled yourself, with no retrieval step, no index and none of the site-level signals Google carries into the decision. What the simulation does measure is narrower and still useful: given a set of competing passages judged on text alone, how often does yours get picked, and does your distinctive claim survive into the summary. That is the part of the problem your editing controls. Treat the result as a relative signal between two versions of your own page, never as an absolute forecast of Google behaviour. The moment you start reporting a simulated cite share as an expected citation rate, you have crossed from testing into fortune telling.
Which LLM settings work best for simulating Google-style AI Overviews?
Run the same corpus twice, at two temperatures. Temperature 0 gives you a reproducible baseline where repeated runs mostly agree, which is what you want when comparing a variant against a control. Then repeat the set at around 0.7 to see which passages keep winning when sampling gets noisy. A passage that only wins deterministically is fragile and will lose the moment anything shifts. Keep the context window comfortably larger than your six passages so nothing is silently truncated, cap the answer length at roughly eighty words so the model is forced to choose rather than include everything, and pin the exact model version in your log. Model choice matters far less than holding every other variable steady across runs. When your provider ships a new version, re-baseline the control before you trust any new comparison.
Should I feed the model full page HTML, rendered text, or a short excerpt?
Use rendered main-body text, stripped of navigation, footers, cookie banners and markup. Raw HTML wastes context on boilerplate and lets the model grade your template instead of your writing. A short excerpt is worse in the opposite direction: it hides the structural problems you are trying to find, because you have already done the extraction work the retriever would have to do. The point of the test is to see whether your claim survives being chunked out of its surroundings, and that only shows up when the model sees the section as a reader would. Match the treatment across all six passages. If you paste clean text for your own page and messy HTML for a competitor, you have handicapped them and your score means nothing.
How do I score likelihood to be cited from a model's output?
Reduce every run to three numbers. Cite share is the fraction of runs in which your passage number appears in the answer, so six citations across ten runs gives you 0.6. Carry rate is the share of your deliberately seeded distinctive claims that reach the summary, which tells you whether the model is quoting you or merely agreeing with you. The drift band is the spread of cite share you get from rerunning the unchanged corpus, and it is your noise floor. Compare a variant against a control, and only act when the gap between them clears the drift band. Without the band you will read random sampling variation as evidence and rewrite pages for no reason. Log all three per run alongside the date, model and model version so a later change is attributable to something.
What quick on-page changes most increase a page's chance of being cited?
Lead each section with the answer rather than the wind-up, so a retriever chunking the page cannot separate your claim from the question it answers. Keep one claim per paragraph, because bundled paragraphs consistently score as needing their whole section for context and never get quoted. Own a specific figure nobody else in your set publishes and date it, since dated numbers get lifted verbatim while adjectives get summarised away. Put definitions immediately beside the term instead of in a glossary further down. State scope explicitly, meaning who the claim applies to, when it was measured and what it excludes, because models reuse the hedges they are handed. Finally, confirm the page is crawlable and marked up. Structured data will not make weak text citeable, but a page search engines cannot fetch never enters the candidate pool at all.
How often should I re-run simulations after publishing or editing a page?
Run the bake-off once as a pre-publish gate on anything new, then quarterly on the pages that carry revenue. Quarterly is not arbitrary. Your competitors are editing their passages too, so the corpus you tested against in March is not the corpus you face in September, and a cite share you won earlier can decay without you touching a word. Re-run immediately in two other cases: after any substantial edit to the page itself, and after your model provider ships a new version, because a version change invalidates your baseline. Do not test everything. Pick the pages where losing a citation costs a booking or a signup, and leave the rest alone. A gate that runs on twelve important pages and actually gets read beats one that runs on four hundred and gets ignored.
Are there risks to optimizing specifically for AI Overviews?
Yes, three worth naming. The first is overfitting to a proxy: you can tune a page until it wins your local bake-off and learn nothing about the system that actually decides, especially if you skip the drift band and chase noise. The second is decay, because tactics tied to current model behaviour expire when the model changes, so anything you cannot justify on plain editorial grounds is temporary. The third is degradation of the page itself. Chopping prose into extractable fragments can win a simulated citation while making the page worse for the human who lands on it, and that trade rarely pays. The safe filter is simple: only ship changes you would defend to a reader who never sees an AI summary. Clearer leads, dated numbers and stated scope pass that filter. Keyword-shaped fragments do not.
