Tell a real ranking movement from noise, before anyone blames an algorithm update
A prompt that walks five gates in order and stops at the first one your data cannot pass, and is forbidden from naming a Google update as the cause.
- Works in
- ChatGPT, Claude, Gemini
- You need
- Search Console export for the period you think changed · The same export for at least four earlier periods · Your own change log with dates
- Written for
- seo algorithm updates
Scored by our own engine
This page, run through the audit we sell. Measured 4 August 2026.
The first thing to establish after a ranking movement is whether there was a movement. Most are inside normal variation, and a model asked why traffic fell will answer regardless, because answering is what it does. The prompt below walks five gates in order, stops at the first one your data cannot pass, and is forbidden from naming a Google update at any point.
What Google actually publishes
Enough to date an update and not enough to diagnose your site. That gap is where most algorithm analysis goes wrong.
Google says it makes significant, broad changes to its search algorithms and systems several times a year, and publishes a ranking updates history with start and end dates for each one. That is a calendar. It tells you that something happened across the web in a window, and nothing whatsoever about whether it happened to you.
The same guidance is unusually direct about what a drop means. It compares search results to a list of top restaurants: a place that moves down the list is not suddenly bad, other places have moved above it. It also recommends waiting at least a full week after a core update completes before analysing your site in Search Console.
Why the gates stop at the first failure
Because every question after an unanswered one is speculation dressed as analysis. A model that continues past a gap fills it, fluently.
The most common stopping point is Q1, and it is the most useful result on the page: the change is inside the variation your own data shows every month. Nothing happened. That answer saves a fortnight and it is the one no report ever leads with, because it reads as a failure to find something.
The second most common is Q5, where the date lines up with something you shipped. This is why the change log gets written before you open the data. Written afterwards, the release that does not feel related never makes the list.
What you can never conclude from this
That a named update affected you. Your data contains no such information, and no amount of correlation with a published date supplies it.
What you can conclude is narrower and worth more: something moved or it did not, it was concentrated or it was broad, eligibility changed or only presentation did, and it started on a date you can point at. Take that date to the dashboard afterwards, never before.
Before any of it, rule out the cause that produces the same shape and has nothing to do with algorithms: run the affected URL through the indexability checker. Then work through the rest of the analysis prompts, starting with diagnosing a single page.
You are a search analyst. I think my rankings moved. Before anyone decides
why, work out whether anything actually happened.
Hard constraint, above every other instruction: do not name a Google
update. Nothing in my data can confirm that a named update affected my
site, and naming one ends the investigation instead of running it. If I
have named one in my inputs, ignore the name and treat it purely as a date.
You also cannot see my competitors, my backlinks, a live results page, or
anything Google has not shown me. Never assert or estimate any of them.
Answer five questions in order, one block each, in exactly this shape:
Q1. the question, restated
ANSWER: YES or NO or CANNOT TELL
BECAUSE: the specific rows or figures from my data that decide it
Stop at the first NO or CANNOT TELL. Write STOP HERE, then name the one
thing I would have to get before the next question could be answered and
where I would get it. Do not answer any later question and do not
speculate about what its answer might have been.
The five questions, in this order and no other:
Q1. Is the change larger than the ordinary period to period variation in
this same data across the earlier periods I gave you?
Q2. Is it concentrated in particular queries or URLs, rather than spread
evenly across everything?
Q3. Did impressions move, or did only clicks and average position move?
Q4. Does the change start on one identifiable date, rather than sloping
across several weeks?
Q5. Does anything in my own change log fall on or before that date?
If and only if you reach the end of Q5, write one final block and nothing
after it:
WHAT THIS IS STILL NOT EVIDENCE OF:
one item per line
That list always includes everything that would require data I did not
give you.
Rules you must follow:
1. Every BECAUSE line quotes figures from what I pasted. A BECAUSE line
with no number in it is not an answer, it is an opinion.
2. Do not turn a small absolute change into a large percentage to make it
look significant. Give both numbers every time.
3. Seasonality is a real explanation and you have no seasonal baseline
unless I gave you the same period a year earlier. If I did not, say so
inside Q1 rather than assuming there is no seasonality.
4. If the earlier periods are too few to establish normal variation, Q1 is
CANNOT TELL. Two periods is not a baseline.
5. Do not recommend any fix. This prompt establishes whether something
happened. Deciding what to do about it is a different job.
My site and market: [ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]
The period I think changed: [START AND END DATES]
Search Console for that period: [PASTE QUERIES OR PAGES WITH CLICKS, IMPRESSIONS, CTR AND POSITION]
Earlier periods, at least four of them: [PASTE THE SAME EXPORT FOR EACH, LABELLED WITH ITS DATES]
My change log: [WHAT YOU CHANGED AND WHEN, OR WRITE "nothing"]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[ONE SENTENCE ON WHAT YOU SELL AND TO WHOM]- Your business and market in a line. Mostly it tells the model whether a seasonal pattern is plausible at all. "We sell exam revision guides to UK sixth formers" makes an August drop unremarkable, and without that sentence the same drop looks like an event.
[START AND END DATES]- The window you think changed, as dates rather than as "last month". Keep it to a period you can compare like for like against the earlier ones. Comparing four weeks against a calendar month is the most common way a change gets manufactured out of nothing.
[PASTE QUERIES OR PAGES WITH CLICKS, IMPRESSIONS, CTR AND POSITION]- The Search Console export for the suspect period, all four columns. Queries or pages, but be consistent across every period you paste. This is the only evidence in the whole exercise, which is why rule 1 will not let a finding exist without a figure from it.
[PASTE THE SAME EXPORT FOR EACH, LABELLED WITH ITS DATES]- Four or more earlier periods of the same length, in the same shape. These are the entire point. Without a baseline there is no such thing as an unusual number, and Q1 will correctly refuse to answer, which is a more useful result than a confident diagnosis of a normal week.
[WHAT YOU CHANGED AND WHEN, OR WRITE "nothing"]- Your own deployments, template changes, redirects, migrations and content edits, with dates. Write it before you look at the data rather than after. Half the movements people attribute to an update fall on the day something shipped, and nobody remembers until Q5 asks.
How to run it
- 01Write the change log before you open the data
List what you shipped and when, from your own deploy history and CMS, before you have seen a single number. Doing it afterwards is how a release quietly gets left out because it did not feel related at the time.
- 02Export five periods of the same length
In Search Console, export the suspect period and at least four earlier ones of identical length, with clicks, impressions, CTR and position. Same shape, same columns, same length. Four earlier periods is the minimum that makes the word "normal" mean anything.
- 03Run the prompt and stop where it stops
Read down to the first STOP HERE and go no further. The block that stopped it is the finding. A run that halts at Q1 has told you the change is inside your normal variation, which is the most common and most useful answer here.
- 04Rule out the boring causes before the interesting one
If it clears Q4 with a single date, check indexability, redirects and anything that shipped that day before considering anything algorithmic. A page that quietly acquired a noindex produces exactly the shape people attribute to an update.
- 05Only then check the published update dates
Google publishes a ranking updates history with start and end dates on its Search Status Dashboard. Compare that against your date afterwards, not before. Reading the dashboard first gives you a hypothesis you will then find evidence for.
- 06Wait before you act on any of it
Google recommends waiting at least a full week after a core update completes before analysing your site in Search Console. That advice generalises: acting inside a moving window means measuring your fix against numbers that were still settling.
Questions people ask
How do I know if an algorithm update hit my site?
Strictly, you do not. You can establish that a change exceeds your normal variation, that it is concentrated rather than spread, and that it starts on a date. Matching that date against a published update is a correlation across a window where thousands of sites also changed. Treat it as context, never as a diagnosis.
How often does Google update its ranking systems?
Google says it makes significant, broad changes to its search algorithms and systems several times a year, and it publishes a ranking updates history with start and end dates on its Search Status Dashboard. Smaller changes happen continuously and are not announced, which is one reason a small movement is rarely attributable to anything nameable.
Does a drop after a core update mean my page is bad?
Not necessarily, and Google says so directly. Its guidance compares it to a list of top restaurants: a place moving down is not suddenly bad, other places have moved above it. That distinction matters because the two situations have completely different responses, and only one of them involves rewriting anything.
Why is the prompt forbidden from naming an update?
Because naming one ends the investigation. Once an update is on the page, every subsequent finding gets read as evidence for it, and the questions that would have found a redirect chain or a shipped template change never get asked. The name is available to you afterwards, from the dashboard, once your own data has said what it can.
How long should I wait before reacting?
Google recommends at least a full week after a core update completes before analysing in Search Console, and notes that improvements can take months for its systems to confirm. Both point the same way: the window you are looking at is still moving, and a fix measured against a moving baseline cannot be evaluated.
Unsubscribe in one click. We never pass your address on.