A Gemini SEO prompt set that has to show where every claim came from
Three chained Google Gemini prompts for SEO, built around grounded search results, so every claim in the brief arrives with the source that produced it.
- Works in
- Gemini
- You need
- One query you want to rank for · Grounding with Google Search switched on · A draft, for the third prompt only
- Written for
- gemini prompt for seo
Scored by our own engine
This page, run through the audit we sell. Measured 4 August 2026.
Most prompts labelled “for Gemini” are the same prompt with a different name at the top. The set below is built around grounded search results and a ledger that keeps every claim next to the URL it came from, which is only worth doing on a model where you can see the sources.
Why the model choice matters here
Grounding is the reason. Google documents grounding with Google Search as a tool you enable explicitly on an API request, and grounded responses come back with citation annotations that tie a span of the answer to a source URL. That is a checkable artefact rather than a claim about quality, and the whole set is designed to keep it.
The second reason is reuse. Gems store instructions and files for later chats, which suits a three prompt chain you will run weekly. A prompt you re-paste is a prompt that gets shortened, and the rules people shorten first are the ones stopping the model inventing things.
Everything else we could say about Gemini is behaviour we have noticed rather than anything measured, and it is offered as a tendency: grounded answers tend to lean on whichever pages the search surfaced, which is a strength for freshness and a weakness when the top results are all repeating each other.
What we are not claiming
We have not benchmarked Gemini against any other assistant, so nothing here says it is better at SEO. We publish no comparison, no scores and no capability claims, because a company selling measurement should not sell an impression instead.
Two real limits. Grounding constrains where claims come from and does not make them true, so a well cited page repeating a widely copied error will produce a well cited ledger of that error. And the DATE field will often read “no date shown”, which is a fact about the open web rather than about the model.
The third prompt is the one people skip and the one that pays. Tracing a finished draft back to the ledger catches the sentences that were added during editing, which is where unsourced claims usually enter. If your draft was written elsewhere, run the drafting prompt that refuses to invent evidence first, then trace it. Once the page is live, check it with the content freshness checker, since a page built from dated sources should carry a date of its own.
Run these three in order, in the same conversation, with Google Search
grounding available. Each one takes the output of the last.
===== PROMPT ONE. THE SOURCE LEDGER =====
Search for the query below and build me a ledger of what you found. Do not
write a brief yet and do not summarise the topic from memory.
For every claim you record, give me four fields on one line each:
CLAIM: one sentence, stated plainly.
SOURCE: the URL you took it from.
DATE: the date shown on that page, or "no date shown".
TYPE: primary documentation, vendor, news, forum, or unclear.
Then two separate lists:
UNGROUNDED. Anything you believe about this topic that you could not attach
to a URL from this search. State each one and leave the source blank. Do not
quietly drop these and do not go looking for a citation to justify them.
CONTESTED. Any point where two of your sources disagree, naming both.
Rules:
- Never write a URL you did not retrieve in this session. If you cannot
produce the link, the claim belongs in UNGROUNDED.
- Do not estimate search volume, difficulty, traffic or ranking positions.
You have no access to any of those.
- If the search returns nothing usable, say so and stop. An empty ledger is
an acceptable answer.
The query: [THE QUERY YOU WANT TO RANK FOR]
My business: [ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]
===== PROMPT TWO. THE BRIEF, BUILT ONLY FROM THE LEDGER =====
Turn the ledger into a brief for one page. Every claim in the brief must carry
the ledger line it came from. Nothing enters the brief that was not in the
ledger.
Give me, as headed sections rather than a table:
THE QUESTION the page answers, in the reader's words.
THE SECTIONS, each with its question, the ledger claims it uses, and the
thing the reader gets from it.
WHAT THE LEDGER CANNOT COVER. The parts of this page that need our own
evidence: a real example, our own numbers, a customer story. Say who has
to produce each.
WHAT EVERYONE ELSE ALREADY SAYS, from the ledger, and the one angle none of
those sources take.
Do not include anything from UNGROUNDED. Do not resolve a CONTESTED point by
choosing a side. Present both and mark it for a human.
Who reads this page: [WHO THEY ARE AND WHAT THEY ALREADY KNOW]
===== PROMPT THREE. TRACE THE DRAFT BACK =====
Here is the draft written from that brief. Go through it claim by claim.
For each factual claim in the draft, output one line:
QUOTE the sentence exactly, then TRACED to the ledger line, or UNTRACED.
Every UNTRACED line is something the writer or you added along the way. List
those separately at the end under WHAT NOBODY SOURCED. Do not fix them, do not
soften them and do not go and find a source for them now.
Quote sentences verbatim. If you cannot quote it, you cannot judge it.
My draft: [PASTE THE DRAFT]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[THE QUERY YOU WANT TO RANK FOR]- One query, as a person would type it, not a topic. "How long should a meta description be" gives the search something narrow to retrieve against. "Meta descriptions" returns a ledger of general background you already knew.
[ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]- This decides which of the retrieved claims matter. "We run technical SEO audits for ecommerce teams on Shopify" keeps the ledger on things that change what those teams do. Leave it out and the ledger reads like an encyclopedia entry.
[WHO THEY ARE AND WHAT THEY ALREADY KNOW]- Used only by prompt two, and it decides how much of the ledger survives into the brief. "Developers who have already read the schema.org spec" removes every explanatory section, which is usually half the page.
[PASTE THE DRAFT]- The finished draft, after human editing, pasted into the same conversation so the ledger is still in context. Starting a fresh chat for prompt three breaks the trace, because the model then has nothing to trace against and will agree that everything is sourced.
How to run it
- 01Confirm grounding is actually on
In the Gemini API, Google Search grounding is a tool you enable explicitly on the request, so a call without it answers from the model alone. In the app you cannot pass a parameter, so treat the presence of real links in the answer as your only evidence that a search happened.
- 02Run prompt one and open three of the links
Click three sources at random from the ledger and check the claim is on the page. This takes two minutes and it is the whole quality control step. A ledger you have never spot checked is prose with URLs next to it.
- 03Read the UNGROUNDED list before the ledger
That list is the model telling you which of its beliefs it could not back up in this search. Some of them will be true and well known. Treat them as things to verify yourself, never as claims to lift into the brief.
- 04Run prompt two in the same conversation
Starting a new chat loses the ledger and the brief silently becomes ordinary generated content with citation shaped language in it. Keep one thread from prompt one through to prompt three.
- 05Save the set as a Gem once it works
Gems in the Gemini app store instructions and files you can reuse, so the version you have tuned is the version that runs next time. Re-pasting a long prompt is how the rules quietly get shortened.
- 06Check the dates before you publish
The DATE field exists because grounded results include pages that have not been touched in years. Once the page is live, run it through the content freshness checker so the page carries its own date signals as clearly as its sources carried theirs.
Questions people ask
What is a good Gemini prompt for SEO?
One that uses grounded search as the input rather than the model's own recall, and that makes the sources visible. The instruction that matters is the ledger: every claim recorded with the URL it came from, and anything the model believes but cannot link listed separately as ungrounded.
Does Gemini search the web when I ask it an SEO question?
In the Gemini API, grounding with Google Search is a tool you enable explicitly on the request, so it does not happen unless you ask for it. Google documents this in its [grounding guide](https://ai.google.dev/gemini-api/docs/google-search). In the app you have no such switch, so the practical test is whether the answer comes back with links you can open.
Is Gemini better than ChatGPT for SEO work?
We have not measured that and will not claim it. What is documented is narrower and more useful: grounded responses come back with citation annotations that tie a span of the answer to a source URL, which is what these prompts are built on. Other assistants have search features of their own, so pick on whether you can see and check the sources.
Why does the prompt ask for an ungrounded list?
Because the failure mode of a grounded model is a mixed answer: two sentences from a retrieved page, one from memory, all in the same paragraph and all reading equally confident. Forcing the unsourced beliefs into their own list separates what was retrieved from what was recalled.
Can I reuse this without pasting it every time?
Yes. Gems let you save instructions and files and reuse them in later chats, which is the right home for a long rule set like this one. Google documents what a Gem stores in its [Gems help page](https://support.google.com/gemini/answer/15235603).
Unsubscribe in one click. We never pass your address on.