First confirm it was a core update by matching your drop date against Google’s Search Status Dashboard and checking whether the decline is sitewide or page-level. Google’s position is that a drop doesn’t mean anything is broken. Recovery, when it comes, usually arrives with a later update after genuine content improvement.
The first hour after a big ranking drop is when most of the damage gets done. Not by the update — by the reaction. Pages get deleted, content gets rewritten in a panic, links get disavowed wholesale, and three months later nobody can tell which change made things worse because everything changed at once.
So slow down. This piece covers how to confirm what actually happened, how to tell a core update apart from a manual action or a technical fault, what Google’s published guidance really means in practice, and what recovery honestly looks like — including the uncomfortable part where some sites don’t get back what they lost.
How do you confirm it was actually a core update?
Three checks: match your drop date against Google’s published list of ranking updates, look at whether the decline is sitewide or limited to specific pages, and open the Manual Actions report in Search Console. If the dates line up, the drop is broad, and there’s no manual action, a core update is the likely explanation.
Google maintains a Search Status Dashboard that lists ranking updates with their start and completion dates, and announces broad core updates as they roll out. That’s the authoritative source. Third-party volatility trackers are useful as corroboration, but they measure a sample of keywords and can flag turbulence that has nothing to do with an announced update.
Timing nuance matters here. Core updates roll out over days or weeks rather than landing all at once, so rankings can move repeatedly during the rollout and settle somewhere different from where they were mid-way through. Judging your position on day three of a two-week rollout will mislead you. Wait for the completion date before drawing conclusions.
The sitewide-versus-page-level distinction is the most diagnostic single signal. Core updates typically reassess how a site’s content is valued broadly, so drops tend to appear across many pages and topics at once. A decline confined to one page or one template, on a date that matches no announced update, points somewhere else entirely.
What’s the difference between a core update, a manual action and a technical fault?
They produce different symptom patterns, and telling them apart takes about ten minutes. A manual action is a human decision recorded in Search Console. A technical fault has a discoverable mechanical cause. A core update has neither — just a broad change in how your content is valued.
| Signal | Core update | Manual action | Technical problem |
|---|---|---|---|
| Search Console notification | None | Yes, in the Manual Actions report | Usually errors in Indexing or Page Experience reports |
| Timing | Matches an announced rollout window | Any date; often follows a pattern of guideline violations | Often matches a deployment or migration |
| Scope | Broad, across many pages and topics | Can be sitewide or limited to affected URLs | Often confined to one template, section or URL pattern |
| Indexing status | Pages remain indexed | Pages may be removed or heavily demoted | Pages may drop out of the index entirely |
| How the drop looks | Gradual over the rollout period | Abrupt and severe | Abrupt, and impressions often fall to near zero |
| Reconsideration request available | No | Yes, once the issue is fixed | Not applicable |
| Typical resolution path | Improve content, wait for a later update | Fix the violation, then request reconsideration | Fix the fault; recovery is often quick |
Work through that table before touching anything. The technical column is the one worth ruling out first, because technical faults are the most fixable and the most commonly misattributed. A botched migration that drops canonical tags will look catastrophic and feel algorithmic, and it’s neither.
Why does Google say there’s nothing to fix, and what does that mean in practice?
Google’s guidance on core updates is that a drop doesn’t necessarily indicate anything is wrong with your pages — the update changed how content is assessed relative to everything else. In practice that means there’s no error to correct, but it doesn’t mean there’s nothing to do.
The distinction is between a fault and a comparison. A manual action says you broke a rule. A core update says other content is now being judged more favourably than yours for the same queries. Nothing on your site became technically wrong; the bar moved, or the competition improved, or the system got better at recognising what searchers wanted all along.
Google’s practical advice is to focus on the self-assessment questions in its guidance on creating helpful, reliable, people-first content — questions about whether content demonstrates first-hand expertise, whether it leaves readers feeling they’ve learned enough, whether it exists primarily to attract search traffic. Those questions are vague enough to be frustrating and specific enough to be useful if you answer them honestly about your worst twenty pages.
Here’s the reframing that helps most. Stop asking “what did I do wrong” and start asking “why would a reader prefer the pages that now outrank me”. Open those pages. Read them properly. The answer is usually visible within ten minutes, and it’s usually about specificity, first-hand knowledge or genuine usefulness rather than anything technical.
Wait for the rollout to complete
Rankings move repeatedly during a core update rollout, sometimes recovering partially before settling. Any change you make mid-rollout gets evaluated against a moving baseline, and you’ll never know whether your fix helped or the update simply finished. Wait for the confirmed completion date, then give it another week.
What should you check before changing anything?
Run a full diagnostic before you touch content. The goal is to establish what actually dropped, for which queries, and whether the pattern points at a topic, a template or a page type. Skipping this step is how sites end up rewriting the wrong things.
- Check the Manual Actions report in Search Console first — this rules in or out the one cause with a defined fix
- Match the drop date against Google’s Search Status Dashboard, noting rollout start and completion
- Compare a four-week window before and after, filtered to organic search only
- Export the queries and pages that lost the most impressions, sorted by loss not by percentage
- Look for a pattern — one topic cluster, one template, one content type, or genuinely everything
- Confirm the dropped pages are still indexed rather than removed
- Check whether anything shipped to the site in the same fortnight — deployments, plugin updates, template changes
- Open the results that now outrank you for five lost queries and read them fully
- Note whether the SERP layout itself changed — new features can cut clicks without any ranking change
- Write down one hypothesis before making any change, so you can test it
That last item is the discipline that separates recovery from flailing. One hypothesis, one set of changes, then a wait. If you change six things simultaneously and rankings return, you’ve learned nothing transferable and you’ll be in the same position next update.
What should you not do after a core update drop?
Three reactions cause more harm than the update did: deleting content in bulk, mass disavowing links, and rewriting the entire site at once. All three feel decisive. All three destroy your ability to diagnose anything.
Panic-deleting content. The advice to prune low-performing pages gets misapplied constantly after updates. Pages with low traffic aren’t necessarily harmful, and removing them can cost you internal link structure, topical coverage and the occasional page that converts quietly. If a page is genuinely thin and serves no reader, improve it or merge it — deletion should be the last option, not the first.
Mass disavowing. Google has repeatedly said the disavow tool is unnecessary for the vast majority of sites, and core updates are not link penalties. Uploading a large disavow file after an algorithmic drop is a common reflex and a genuinely risky one, because you can remove links that were helping you. Unless you have a manual action citing unnatural links, or you know you bought a large volume of low-quality links, leave it alone. We covered the risk calculus around paid links in our piece on whether buying links is actually dangerous.
Rewriting everything at once. Beyond the diagnostic problem, wholesale rewrites often replace pages that were fine with pages that are merely different. Start with the twenty pages that lost the most impressions, improve those properly, and see what happens before touching the rest.
There’s a fourth reaction worth naming: buying links to fix an algorithmic drop. It doesn’t work, because a core update didn’t devalue your links — it reassessed your content. Adding referring domains to a page Google now considers a weaker answer is spending money on the wrong axis. If you do want to check whether your existing profile is a liability, our guide to assessing which links are worth keeping is a better starting point than a disavow file.
What does realistic recovery look like?
Recovery from a core update generally requires a subsequent core update to reassess the site, which means the timeline is measured in months and set by Google’s release schedule rather than yours. Google has said sites may need to wait for a later update, and that improvements made now are evaluated then.
That’s a hard thing to sit with. You make genuine improvements, and nothing happens for weeks or months, because the system that demoted you hasn’t run again. This is why the discipline of a single hypothesis matters so much — the feedback loop is slow enough that unstructured experimentation gives you nothing.
Partial recovery is more common than full recovery. Sites that improve substantially often regain a meaningful share of what they lost rather than all of it, particularly where the update reflected a lasting change in what the results reward. And some sites don’t recover, especially where the business model depended on ranking content that Google has decided serves searchers less well than alternatives. That’s not a comfortable thing for an SEO company to write, but pretending otherwise sells false hope.
The sites we’d expect to do best are the ones that treat the drop as information rather than an injury. If a core update told you that your comparison pages are thinner than the ones now outranking them, that was true before the update too. You just weren’t being charged for it. If you want an outside read on which pages are genuinely weak, a structured assessment of where your content stands against what now ranks will get you there faster than staring at your own pages.
Key takeaways
- Confirm the cause first: match dates against Google’s Search Status Dashboard, check scope, and check the Manual Actions report.
- Core updates, manual actions and technical faults produce distinct symptom patterns — rule out technical faults first.
- Google’s position that nothing is broken means there’s no fault to correct, not that there’s nothing to improve.
- Wait for the rollout to complete before changing anything, then form one hypothesis and test it.
- Avoid bulk deletions, mass disavows and site-wide rewrites — all three destroy your ability to diagnose.
- Buying links doesn’t fix an algorithmic content reassessment; it spends money on the wrong axis.
- Recovery usually needs a later core update, is often partial, and occasionally doesn’t come at all.
How long after a core update do rankings settle?
Google publishes start and completion dates for each rollout, and completion typically arrives days to a few weeks after the start. Give it another week beyond the published completion date before treating your positions as final — residual movement is common.
Does adding backlinks help after a core update?
Not for the drop itself. A core update reassessed how your content is valued, so authority isn’t the constraint that changed. Links remain useful for pages competing on a genuine authority gap — that’s a separate problem that happens to share a calendar with this one.
Should I disavow links after an algorithmic drop?
Almost certainly not. Google has said the disavow tool isn’t needed for most sites, and it’s aimed at manual actions for unnatural links rather than core updates. Disavowing broadly can remove links that were helping, which makes a bad quarter worse.