Google core updates: how to tell if you were hit and how to respond

Several times a year Google announces a core update: a broad change to its ranking systems that rolls out over a couple of weeks. Some sites gain, some lose, most barely move. For the sites that lose, the first days are usually spent in a mild panic, rewriting titles, deleting pages and adding author bios, often before anyone has confirmed that the update caused the drop at all.

This guide is a calmer process: confirm, locate, compare, then act. It assumes you have Search Console access and at least a few months of history.

What core updates are, and what they are not

Google describes core updates as changes to how it assesses content overall, not as penalties aimed at specific sites or techniques. A page that drops after a core update has not necessarily done anything wrong; other pages may have been judged more relevant or more helpful for the same queries. Google's public guidance after each update points to the same set of questions about content quality, expertise and helpfulness rather than to technical fixes.

That framing matters for your response. Core update losses are rarely fixed by a technical change, and almost never fixed quickly. They are different from:

• Spam updates, which target specific spam policies such as link schemes, scaled low-value content or site reputation abuse.
• Manual actions, which are applied by people and appear in Search Console with a description of the issue; see manual actions and security issues.
• Technical faults on your side that happen to coincide with an update.

Step 1: confirm the cause

Before attributing anything to an update, rule out the boring explanations. They are common, and they are fixable.

Possible cause	How to check
Tracking problem	Do Search Console clicks show the same drop as analytics? If only analytics dropped, look at the tag, consent banner or a site change.
Seasonality	Compare year over year for the same weeks. A dip every November is not an update.
Technical fault	Check the Page indexing report, robots.txt, noindex on templates, server errors and recent deploys. A scheduled technical check makes this quick; a sudden drop in the checker score on the same day points away from the update.
Lost rich results or SERP changes	Did impressions hold but CTR fall? A new AI Overview, video carousel or shopping block can take clicks without any ranking change.
Timing	Did the change start inside the announced rollout window? Google lists dates on its Search Status Dashboard.

If the drop started days before the rollout, or affects only one template, it is very unlikely to be the update. The traffic drop diagnosis guide goes through these checks in more detail.

Step 2: wait for the rollout to finish

Core updates take one to two weeks, sometimes longer, to roll out. Rankings move around during that time and some early losses reverse. Making large changes mid-rollout means you will never know which change, if any, helped. Use the time to gather data instead. Once the update is announced as complete, wait a few more days for Search Console data to settle, since the newest days are often revised.

Step 3: find exactly what lost

Compare a period of equal length before and after the update, avoiding the rollout days themselves. In Search Console's Performance report, export by page and by query, and calculate the change in clicks for each row. Then group.

• By section or template: did the whole blog drop while product pages held? Did one category lose everything?
• By query type: informational queries ("how to…", "what is…") and commercial queries ("best…", "buy…") often move differently.
• By position band: pages that fell from 2 to 4 are a different problem from pages that fell from 5 to 25.

Usually a small share of pages accounts for most of the lost clicks. Make a list of the top 20 to 50 losers by absolute click change. That list is where the work happens. The regex filters guide helps with grouping queries in the interface.

Step 4: compare honestly with what now ranks

For each important losing query, search it (in a clean browser, logged out, in the target country) and look at what ranks above you now. Ask the uncomfortable questions:

• Does the top result answer the question faster or more completely?
• Is it written by someone with visible first-hand experience: original photos, test results, specific details your page lacks?
• Does it match the intent better? If the top results are now comparison tables and your page is a long essay, or vice versa, intent may have shifted. See search intent.
• Is your page mostly a rewrite of what everyone else says?
• Does the page put ads, pop-ups or affiliate blocks before the answer?

Write the answers down per page. Patterns appear quickly: thin product round-ups with no testing, outdated guides, articles written by nobody in particular, sections built to target keywords rather than readers.

Step 5: decide per page

Finding	Action
Page is outdated or incomplete compared with winners	Rewrite with new information, real examples and a clearer answer; see refreshing old content
Several weak pages target the same topic	Merge into one strong page and redirect the others
Page has no unique value and little traffic	Improve substantially or remove; see pruning thin content
Intent changed	Restructure the page for the new intent or accept that a different page type now wins
Page is good and only slipped one or two positions	Leave it alone; small moves are normal

Site-level patterns deserve site-level responses. If a large share of the site is content produced quickly to cover keywords, fixing ten pages will not change the overall assessment. That is a strategy conversation, not an SEO ticket.

Things that rarely help

• Adding an author box to every page without changing the content. Showing who wrote something is good practice, but it does not make a thin page useful. The E-E-A-T guide explains what actually demonstrates experience.
• Changing publish dates without meaningful updates.
• Mass-deleting pages that still earn clicks.
• Disavowing links in response to a core update. Core updates are not link penalties.
• Rewriting everything with an AI tool for "freshness". Faster production of similar content is the opposite of what the update rewards.

Gains deserve the same analysis

When a section gains after an update, run the same comparison in reverse. Which pages rose, for which queries, and what do they have in common? Often the winners are pages someone wrote with real care: a buying guide based on hands-on testing, a support article that answers the question in the first paragraph, a category page with genuinely useful filtering advice. Those pages are the template for fixing the losers. They also tell you what to protect: a redesign that strips the detail from a page that just gained is an expensive way to undo the update.

Explaining it to the people who pay

Owners and clients mostly want three answers: what happened, is it our fault, and when will it come back. Be honest about the third. Say that core update recoveries are slow and not guaranteed, show the per-section numbers rather than a single total, and present the page-level plan with a date to review progress. A dated, specific plan calms a room far more than reassurance does, and it stops well-meaning colleagues from making ten uncoordinated changes in the same week.

Keep a log for next time

Record every update date in your reporting, alongside your own site changes: deploys, content batches, migrations, redesigns. When the next update arrives you can see at a glance whether sections you improved recovered and whether the same sections lost again. Agencies should share this log with clients; it turns "we lost traffic" into a dated, explained event. Monitoring tools that store daily average position per query, as DeskSEO does once Search Console is connected, make the before-and-after comparison a few clicks instead of an afternoon of exports.