How to Read Search Console During a Google Core Update

Don’t touch a page during the first days of a core update. The graph will move, you’ll want to explain it, and almost every explanation you come up with in week one is a guess.

Google’s Search Status Dashboard lists the November 2026 core update as starting on 10 November and still rolling out when I pulled my data. Google’s own guidance is to wait at least a full week after a core update finishes before analyzing, and to compare against the period before it started. I follow that, and here is the exact routine.

Step 1: freeze a baseline before you look at the update

Open the Performance report in Search Console and set the date range to the 14 days before the update’s start date. Export clicks, impressions, CTR and average position by day. That file is your baseline, and you save it before you read a single post-update number.

Here is mine, from Search Console for my own site:

A 228-to-393 spread with no update running is the number that matters. If you don’t know your own spread, you can’t tell a core update from a Tuesday.

Step 2: write down what else changed

Core updates get blamed for things they didn’t do. Before you compare anything, list what changed on your side in the same window: a site migration, a template change, a batch of new pages, a robots or noindex edit, a redirect rule. If the list is not empty, the update is not the only suspect.

Also check whether one page is distorting the sitewide line. On 28 October my total impressions jumped from 24,498 to 131,686 in a day because a single page was shown far more often. I walked through that case in what I check when impressions spike and CTR falls. A sitewide average during a core update has the same weakness.

Step 3: wait for the rollout to end, then one more week

Core updates roll out over a couple of weeks and rankings move around while they do. Comparing mid-rollout means comparing a moving target to a fixed baseline. Set a calendar reminder for one week after the dashboard marks the update complete, and do nothing until then.

Waiting is not passive. Use the time to fix things that were broken regardless: pages returning errors, titles that were cut off, thin duplicates. Those changes would be right in any month, and they won’t muddy the comparison as long as you log them with a date.

Step 4: compare equal windows and split four ways

When the reminder fires, compare the 14 days after completion against your frozen 14-day baseline. Equal lengths, same days of the week. Then split the difference:

1. By page. Export the Pages tab for both windows. Sort by change in clicks. In most drops I’ve looked at, five or ten pages account for the bulk of it.
2. By query. For each of those pages, look at which queries lost clicks and whether the loss is position or CTR. A position drop from 4 to 9 is a ranking change. A flat position with falling CTR is a snippet or SERP-feature problem, covered in why your best-ranking pages get zero clicks.
3. By country. A core update can hit one market harder than another, especially on multilingual sites.
4. By device. A mobile-only loss points at the page experience, not at relevance.

If the change is inside your normal spread from Step 1, there is no update effect to explain. Stop there and keep publishing.

Step 5: only now decide what to change

Match the type of loss to the type of fix:

• Lost positions on a few pages: compare them to the pages now ranking above you. Do they answer the query faster, with more specific detail, from first-hand experience? Rewrite yours to do that. Don’t pad it.
• Lost positions everywhere: that’s a site-level quality read, and it’s slow to move. Prune or merge pages that don’t earn their place, and improve the ones that do. Expect recovery to take months, not days. Google has said improvements can take effect over time and that a later core update may be needed for bigger recoveries.
• Gained positions: write down which pages and why. That’s your template for what Google currently rewards on your site.

For pages that slipped to page two rather than collapsing, the routine in how to fix pages stuck on page two applies. For a loss that shows up in GA4 as well, how to diagnose traffic drops with Google Analytics covers the other half.

The prompt I paste into Claude or ChatGPT

Export the Pages tab for your baseline window and your post-update window as two CSVs, then paste both:

Here are two Google Search Console exports by page. File A is the 14 days
before a Google core update began. File B is the 14 days after the rollout
finished. Same length, same days of the week.

1. List the 15 pages with the largest change in clicks, up or down, with
   the change in absolute clicks and in percent.
2. Tell me what share of the total click change those 15 pages explain.
3. Flag any page where clicks changed but impressions did not, since that
   points to CTR rather than ranking.
Show the arithmetic. If a number isn't in the data, say so instead of
estimating. Do not suggest content changes yet.

Check one row by hand before trusting the rest. These models will round confidently and sometimes misstate the share.

If you’d rather not export CSVs for every client, I built SiteWide to pull Search Console and GA4 into Claude for exactly this comparison. Either way, the discipline is the same: baseline first, patience second, changes last. If you want an assistant for the prompt step, I use Claude.

My numbers come from my own Search Console property for 15 October to 11 November 2026: 7,472 clicks and 1,108,401 impressions across the 28 days. It’s too early for me to say whether the update helped or hurt this site, and I’ll only know once the rollout is done and the waiting week has passed.