Your rankings dropped. Find the date first
The instinct after a drop is to start rewriting. Nearly every drop we get asked about turns out to have a date attached to it, and the date narrows the cause to one of about six things before you touch a single page.
The message usually turns up on a Monday. Rankings are down, enquiries have gone quiet, and can we look at the site this week. Attached is a screenshot of a graph going the wrong way.
The first thing we ask for isn't the screenshot. It's a date. Not "a few weeks ago", not "since about July". The day the line turned.
That sounds pedantic and it isn't. A ranking drop is one of maybe six things, and most of them announce themselves by when they happened rather than by how they look. Get the date and you've usually eliminated four of the six before anybody has opened a page of copy. Skip the date and you end up doing what most people do, which is rewriting the pages that were already fine.
Getting the date
Search Console, Performance report, compare mode. Set the date range wide, twelve months if you have it, and look at impressions rather than clicks. Clicks are noisy at small volumes and a single good week can hide a slide that started a month earlier.
What you want is the shape. Google's own guide to debugging drops in Search traffic opens with sketches of the graph shapes and what each tends to mean, which is more useful than it sounds. A cliff is a different animal from a slope. A cliff on a Tuesday is usually something you did. A slope over ten days is usually something Google did. A dip that comes back on its own is usually seasonality or a reporting glitch, and Google explicitly lists reporting glitches as a cause, with a shrug emoji in the documentation, which I appreciate more than I probably should.
Write the date down. Then go and check it against the calendar.
Was it an update?
Google publishes the start and end of every named ranking change on the Search Status Dashboard. This is the single most underused free thing in SEO. It takes about forty seconds.
The durations are the part people miss. The May 2026 core update started on 21 May and took eleven days and twenty-one hours to finish rolling out. The March 2026 one ran twelve days. The August 2026 spam update was quicker, under three days. So a "gradual decline over a fortnight" is not evidence that something slowly rotted on your site. It's the exact shape of a core update landing.
If your date sits inside one of those windows, you have your answer, and the answer is uncomfortable but freeing: Google's core updates page describes them as broad reassessments that don't target individual sites, and the debugging guide above says outright that there might not be anything fundamentally wrong with your content. Google's own analogy is a list of your twenty favourite restaurants, rewritten a few years on. Some places move down without having got worse.
Two rules from Google's core updates guidance are worth following exactly. Wait until the rollout has finished, then wait a full week more, before you judge anything. And compare the week after against the week before the update started, not against the middle of the rollout, or you're measuring half a change.
Small drop or big drop
This is the distinction that decides whether you do anything at all.
The debugging guide draws the line between a small move, their example is position 2 to position 4, and a large one, position 4 to position 29. Small moves happen constantly in both directions, and their advice is to leave it alone. They go as far as recommending against radical changes to a page that's already performing well, which is the exact opposite of what a panicked owner does on a Monday afternoon.
A large move is a different message. Something about how that page is assessed has changed materially. That's worth work. But it's worth work on that page and the queries it lost, not a site-wide rewrite.
Pull the query list for the affected page before and after. If twelve queries dropped four places each, that's noise. If two queries fell off a cliff and the rest are untouched, you have a specific problem with a specific intent, and now you know what to read.
The four causes that aren't Google
If the date doesn't line up with anything on the dashboard, it's almost certainly one of these.
You changed something. Rebuilds, redirect changes, a new template, a plugin someone installed, a noindex that shipped with the build. Check the date against your own deploys before you check anything else. If there was a redesign anywhere near it, the redirect map is the first place to look, and we've written about what goes wrong there in detail.
Something broke quietly. Server errors during crawls, a robots.txt edit, pages timing out under load. The Pages report in Search Console will tell you, and it's the reason a technical audit starts with crawl health rather than keywords.
Seasonality. Boring, real, and the easiest to confirm: compare the same month last year rather than last month. Plenty of Australian service businesses have a July that looks like a catastrophe and is just July.
Someone else moved. A competitor published something better, or a big publisher decided your topic was worth covering. Nothing broke on your side at all. This one is genuinely common and there's no fix beyond doing the work.
Worth ruling out first, though: are the pages even indexed? If the drop is total rather than partial, you might be looking at an indexing problem rather than a ranking one, and those two get confused constantly. We've covered how to tell them apart.
What not to do in week one
Don't rewrite pages that dropped four places. Don't add three thousand words to a page because a tool said it was thin. Don't disavow links on a hunch. Don't buy anything from whoever emails you offering to fix it, and they will email you, because drops are visible from outside.
The reason is the comparison problem. If you change six things and the numbers recover, you learned nothing, and you'll do all six again next time out of superstition. Change one thing. Wait. Most recoveries after a core update take until the next one anyway, which is a genuinely awful thing to tell someone but it's the truth of it.
I'll admit the part I find hardest is the waiting. Sitting with a drop for three weeks while you confirm it's finished rolling out feels like negligence, and it isn't, but it feels like it.
This week
Open Search Console, find the day the line turned, and write it in a note somewhere you'll find it again. Then open the Search Status Dashboard and see whether anything with a name overlaps it.
If it does, you have a date, an explanation, and a reason to leave your best pages alone for a month. If it doesn't, check your own deploy history for that week, and the answer is probably sitting in there.
Either way you're now working on the actual problem rather than the first one that came to mind, which is most of the job. If you'd rather hand that part over, a free website audit will tell you what's earning and what's broken before you spend anything on fixing the wrong thing.