Google core update recovery is mostly a sequencing problem, not a knowledge problem. You already know the things that might be wrong: thin pages, duplicate topics, slow templates, content that reads like nobody wrote it. What you do not have is a week-shaped plan that tells you what to look at on Monday, what to decide by Thursday, and when to stop touching the site and let the data settle. So here is one, written for a two-person team with a company blog, not for an agency with six analysts.

One warning before Day 1. Plenty of traffic drops that look like core update damage turn out to have another cause entirely.

Day 1: confirm the drop is a core update, not noise

Start with the dates, not the site. Google publishes confirmed rollout start and finish dates on its core updates page in Search Central, and a rollout usually runs for a couple of weeks rather than landing overnight. Write the start date down. Everything else today is measured against it.

In Search Console, compare the 28 days before the rollout began with the 28 days after it finished, and align the comparison weekday to weekday. A B2B blog that takes most of its clicks Monday to Thursday will show a fake collapse if your two windows contain a different number of working days. Rolling averages smooth the exact edge you are trying to find, so use the date-range comparison instead.

Then read impressions and clicks separately, because they tell different stories:

• Impressions down, clicks down: you lost visibility. Positions moved. That is the pattern a core update produces.

• Impressions flat, clicks down, average position flat: you lost the click, not the ranking. AI Overviews, a bigger People Also Ask block or a new shopping module can take the click without taking your position.

• Both down sharply on one single day: suspect yourself first. A tag manager change, a property filter, a migration, a noindex shipped with a theme update.

Rule out the impostors before you blame the algorithm: seasonality (compare the same window last year), analytics tracking changes, a site move, indexing errors, and consent banner changes that cut GA4 data while Search Console stays flat. If Search Console and GA4 disagree, Search Console is the one that reflects what Google saw.

Finish Day 1 with one sentence you can defend in a meeting. Something like: "Organic clicks to the blog fell 38% between 12 September and 9 October, concentrated in the guides directory, with impressions down a similar amount and average position down 4.1 places."If you cannot write that sentence, you do not have a diagnosis yet and no amount of rewriting will give you one.

Day 2: find the exact pages and query clusters that lost

Export the Pages and Queries reports for both periods, put them side by side in a spreadsheet, and sort by absolute click loss. Not percentage change. Percentage sorting is the single most common reason teams spend a week fixing the wrong pages: it floats a post that fell from nine clicks to two straight to the top, while the one guide that quietly dropped four thousand clicks sits halfway down the sheet looking like a modest decline. The recovery almost always hinges on that page.

Now group the losers by topic rather than by URL. Core updates move clusters. When you plot the damage by theme you usually find one subject area where the whole set slipped together and other areas untouched, which changes the job completely: it is not "rewrite ten posts", it is "we have not earned the right to cover this subject and our competitors have".

Two more columns before you leave the spreadsheet. First, whether each losing URL is an informational blog post or a money page, because a service page losing commercial queries is a different problem from a how-to guide losing long-tail impressions. Second, whether the page has inbound links or attached conversions. That column exists to stop someone proposing a delete on Friday for a page that is quietly earning three referring domains and two enquiries a month.

Day 3: rule out technical causes before you rewrite a paragraph

Content fixes are slow and expensive. Technical fixes are fast and cheap. Check the cheap ones first.

• Index coverage: filter the Pages report for Excluded and look for "Crawled, currently not indexed"clustering in one directory. That pattern points at quality assessment, not a bug.

• Canonicals and noindex: staging builds leave noindex tags behind more often than anyone admits. Check a losing template in the URL Inspection tool, live test, not the cached result.

• robots.txt: particularly on a directory added since the last audit.

• Core Web Vitals and mobile rendering on the losing template specifically, not the site average. Your homepage can pass while the blog post template fails because of a related-posts script.

• Plugin and theme release dates: if a template update changed your H1s, titles or schema in the same fortnight as the rollout, you have a confounder and you need to separate the two before you draw conclusions.

The one people miss is duplicate structured data. If an SEO plugin such as Yoast is already emitting Article markup and a theme or a third-party script adds a second copy, you can get validation errors and lose rich results while the content itself is untouched. Worth knowing too: since August 2023 Google has limited FAQ rich results to well-known authoritative government and health sites, so an FAQ block disappearing from your SERP listing may have nothing to do with the core update at all. Run two or three losing URLs through the Rich Results Test and read what is actually in the page source.

Day 4: grade the losing content on first-hand value, not word count

Pick five losing pages. Open the live top 10 for each one's main query and read them properly. The question is not "are they longer than us". It is: what do these pages know that ours does not? Usually the answer is embarrassingly concrete. They name the standard. They give a price range. They explain the step where the process goes wrong and why.

Thin AI output gives itself away in predictable ways, and those are the pages core updates tend to take first. No named examples. Hedged generalities that would be true of any business in the sector. Every sentence running to roughly the same length. A conclusion that restates the introduction in slightly different words. The counter is not a different model or a heavier polish pass: it is first-hand specificity and deliberate rhythm variation. Our own checklist of what Google's guidance actually asks publishers to demonstrate is the standard we grade against, and it is a content test, not a detection test.

Grade every candidate on two separate axes: how useful it is for search, and whether it has any content integrity, by which we mean whether it says anything only someone with real experience could say. Let integrity win ties. A page that is technically well optimised, correctly structured, keyword-aligned and still says nothing a human had to be there to learn is precisely the page a core update demotes. We grade every draft twice for the same reason, before anyone sees it.

Day 5: decide improve, merge or remove

Run the cannibalisation check first, because it is a common hidden cause of a soft, puzzling decline. In the Queries report, filter by a head query and look at which pages Search Console attributes it to. Two or more URLs swapping in and out for the same query means Google cannot work out which page you intend to rank, and a core update is exactly the moment it stops guessing in your favour.

Take the realistic case: a six-page cluster on one service topic, three of which rank interchangeably for the same query. The fix is a merge, not a cull. Build one strong page from the best of all three, 301 the two weaker URLs into it, update the internal links that pointed at them, and track that query for the next eight weeks. A redirect keeps the link equity. A delete throws it away.

Then sort the rest into three piles:

1. Improve: the page has a real audience and a real gap. This is a proper content refresh with new substance, not a tidy-up.

2. Merge: near-duplicates, combined and redirected.

3. Remove: genuinely redundant, no links, no conversions, no query it serves better than another page. Prune these, and only these.

On timing, be honest with whoever is asking. Fixing an indexing bug can show up in weeks. A site-wide quality problem is reassessed broadly, and Google's own guidance is clear that there is no single fix and that improvements may not be reflected until a later update rolls out. Plan for months, be pleased if it is faster.

Day 6 and 7: rebuild the plan so the recovery compounds

Day 6 is planning the next quarter against real UK search volumes and difficulty, with a content gap analysis against five to ten crawled competitors, so the new work targets the cluster you just lost rather than scattering across the site. Check every proposed title against what you already publish. Creating fresh cannibalisation forty-eight hours after fixing it is a genuinely common outcome, and a decent content marketing platform should flag the overlap before a brief is written, not after a draft is live.

Pace matters more than volume here. Teams that dump twenty posts in a fortnight to show Google they are active produce exactly the spiky, low-quality publishing pattern they are trying to escape. Ramp gradually, two a week rather than twenty in one, and keep it steady for a quarter.

Day 7 is measurement discipline. Write a dated changelog: what changed, which URLs, which day. Set reviews at 4, 8 and 12 weeks after the last change, and make no further sweeping changes in between, because if you keep editing you will never know which edit worked. That clean record is also what lets you read the next core update properly instead of guessing again.

The recovery mistakes that cost UK small business blogs the most

• Mass-updating publish dates with no substantive change. Google has said repeatedly that changing dates without changing content does not make a page fresh. All you do is destroy your own record of when real work happened.

• Panic-deleting the archive. Out go the internal links, the referring domains and the topical signals that told Google what your site is about.

• Replacing thin output with more thin output in a different voice. Same generic page, new adjectives. The problem was never the tone.

• Chasing one quick win. If eleven pages in a cluster fell together, fixing the best one tells you nothing. The pattern is the story.

Done properly, google core update recovery is a week of diagnosis followed by a quarter of patient, specific publishing. If you want a second pair of eyes on which cluster actually lost, our free content marketing snapshot is a reasonable place to start.

Frequently Asked Questions

How long does Google core update recovery usually take?

It depends entirely on the cause. A technical fault, such as a noindex left on a template, can be reflected within weeks of recrawling. A broad content quality problem is slower, and Google's guidance states that improvements may not be reflected until a subsequent core update runs, which can be several months later.

Can you recover from a core update before the next one rolls out?

Sometimes, yes. Individual pages do move between core updates as Google recrawls and reassesses them, particularly where the fix was technical or where you have genuinely rebuilt a page. Site-wide reassessment is the part that tends to wait for a later update, so treat a partial mid-cycle improvement as a good sign rather than the finished job.

Should I delete low-traffic blog posts after a core update drop?

Only where a page is genuinely redundant, has no inbound links and drives no conversions. Low traffic on its own is not a reason to delete. Merging near-duplicates into one stronger page with a 301 redirect keeps the value and solves the cannibalisation at the same time, which deleting does not.

How do I tell a core update drop from seasonality or a tracking problem?

Match the drop to the confirmed rollout dates, compare the same weeks in the previous year for seasonality, and cross-check Search Console against your analytics. A single-day vertical fall usually means a tracking or tagging change, while an algorithmic drop accumulates over the rollout period and shows in impressions and average position, not just clicks.

Does updating publish dates help a site recover?

No. Changing the date without changing the content does not make a page more useful, and Google has been consistent on that point. Update the date when you have actually added something: new figures, a new section, a corrected process. Then the date is information rather than decoration.