Google announces core updates and they roll out over one to two weeks. During that fortnight every drop looks like the update, including the ones caused by your own deploy on the Tuesday, a competitor's new page, or a public holiday. The method for separating them is the same one used for proving a fix worked, run in reverse: compare what changed against what did not.
The most common finding, having done this honestly, is that the update did not single you out and something else moved. That is worth knowing before rewriting the site.
The steps
- Note the update's rollout window, not its announcement dateGoogle publishes the start and completion dates. Effects appear anywhere inside that window. A drop on the announcement date exactly is more likely coincidence than the update, which takes days to reach a given site.
- Check for your own changes in the windowDeploys, redirects, a CMS upgrade, a template change. A crawl before and after shows whether titles, canonicals or indexability moved on the same dates. Half of 'the update hit us' is a regression that shipped the same week.
- Segment by page type, not site-wideCompare impressions for blog pages, product pages, and the home page separately, week over week. Core updates typically move one kind of page. A site-wide uniform drop is more often tracking, indexing or a manual action.
- Compare against pages you did not touchIf you changed anything in the window, split pages into changed and unchanged, matched by traffic band. If both fell equally, it was not your change. If only the changed pages fell, it was. That is a control set, built after the fact, which is weaker than one frozen in advance but far better than none.
- Wait a full week after rollout completes before concludingPositions oscillate during rollout and settle after. A four-week window from the completion date is the earliest point at which a before-and-after comparison is mostly signal.
If it really was the update
There is no fix to ship. Core updates re-weigh what Google already knew about the site, and the documented advice is to improve the pages that lost ground rather than change anything technical. That is real work, and it is measurable the same way: choose the pages, improve them, freeze a comparison, wait. A page that recovers at the next update while its comparison pages do not is evidence; a site-wide recovery is the next update giving everyone their traffic back.
What the update did not do is anything to a missing meta description or a redirect chain. Those were costing the same before and after, and fixing them is still worth it — just not as a response.
Questions people ask
Impressions fell but clicks did not. What happened?
You lost impressions on queries that were not sending clicks anyway — usually very long-tail or loosely related ones. This is common after core updates and is often not a loss of anything you wanted. Check click-through rate per page: if it rose, the impressions that left were the ones that never converted.
Can a tool tell me automatically?
It can do the segmentation and the changed-versus-unchanged comparison, which is most of the work. Rankelle's ledger keeps a control set for every landed fix, so on the week of an update it already has a matched set of untouched pages to compare against and can say whether a verdict was contaminated by it. What no tool can do is know Google's intent; the comparison is the evidence, and it is all anyone has.
Try it on your own site, free
The whole audit of every website you add, no card and no expiry. Pay only when you want the proof.