Core update: what a broad Google update actually is

Several times a year Google readjusts the systems that decide the order of results. These adjustments are announced, get a name with a month and a year, and hit every kind of site and query at once. The practical consequence is uncomfortable: a page can drop without anyone at Google ever having looked at that page.

Three things that business conversations almost always blur belong apart. A manual action is a human decision about a specific site, it is reported in Search Console, and it allows a reconsideration request. A spam update improves the automated systems that detect prohibited practices. A core update does neither: it reorders, and that is all.

Google explains the effect with a domestic comparison. If someone rewrites their list of twenty favourite restaurants today, the ones that slip are not suddenly bad; there are simply new candidates and new criteria. Losing positions after a core update does not prove that the page breaks any rule.

Nor does every core update cover the whole of Search. On 5 February 2026 Google released a core update aimed at Discover, carrying the same label and the same general guidance, but limited to that surface.

The rollout is not instant. Google publishes the start and end date on its Search status dashboard, and in between results move more than usual because the different systems update at different moments. When an update touches several systems at once, the process stretches out: announcing the March 2024 update, Google warned that the rollout could take up to a month.

While the rollout is still open, any reading of the data is provisional. The official recommendation is to wait at least a full week after it closes and then compare that week against a week before it started. Comparing against the rollout period itself produces numbers that change on their own.

Then comes measuring the real size of the movement per page and per query, not across the site total. A slip from position 2 to position 4 does not justify touching anything, and Google explicitly advises against changing content that already performs well. A slip from position 4 to position 29 does call for a deeper assessment. It also helps to separate web, images, video and news, because a collapse concentrated on a single surface points to a different cause.

And here comes the part the industry tends to rewrite. To the question “what do I do to recover?” the official answer is not a list of fixes: Google states that there are no specific actions you can take to recover from a core update and that a negative impact may not mean anything is wrong with your pages. What it offers instead is a self-assessment questionnaire covering the whole site, plus the caveat that improvements can take months and that no change guarantees a visible effect.

The decision hanging on this concept is whether to react at all, and with what budget. A drop that coincides with a core update looks a great deal like a drop caused by a technical fault, by a template change, or by a competitor who just published something better. Confusing them costs money: you rewrite what was fine and leave untouched what was broken.

The second decision concerns deadlines and promises. Content changes can take months to show up, and the search engine itself guarantees no visible effect for any modification. A plan promising the old position by next month is promising something Google does not promise.

The third concerns internal governance. If every ranking movement is attributed to the most recently announced update, nobody reviews the boring causes: a half finished migration, a forgotten noindex, a campaign that ended, a seasonal fall in demand. Dating the episode and cross checking it against the official calendar turns an argument about opinions into a check.

• Record the start and end date of every announced update in the analytics calendar, so it can later be cross checked against your own data.
• Wait for the rollout to finish and let another week pass before drawing conclusions or presenting figures to a client.
• Compare the week after against a week before the start, and do it per page and per query, not only across the site total.
• Rule out technical and business causes first: crawling, indexing, template changes, seasonality, campaigns that ended.
• Apply the self-assessment questionnaire to the whole site and also ask someone outside the project to answer it, because your own eye on your own content is lenient.
• Work on the worst affected pages with substantial improvements in usefulness, and treat deletion as a last resort.

• Calling a drop after a core update a penalty, which sends people looking for a culprit and a reconsideration form that does not exist here.
• Measuring during the rollout and deciding on numbers that are still moving.
• Applying quick fixes picked up second hand, such as removing a page element because someone declared it harmful.
• Deleting whole sections by reflex. If deletion is the natural reaction, the useful question is why those sections were published.
• Attributing every fluctuation to the most recently announced update and never checking crawling, indexing or demand.