How to recover from a Google core update

I’ve had three sites hit by core updates since 2021, two of them mine and one I was consulting on. The pattern is always the same: traffic drops 20-60% inside a week, the client or the founder panics, and someone suggests rewriting everything on the site overnight. That’s the wrong move almost every time.

This is for anyone running a content site, affiliate blog, or SaaS marketing site that just watched organic traffic fall off a cliff and suspects (or has confirmed) it lines up with a Google core update. The outcome here isn’t a guarantee of recovery, nobody can promise that, but a structured process to confirm what actually happened, fix the real problems, and avoid wasting three months chasing the wrong signal.

Recovery timelines vary a lot. Some sites bounce back within the next core update cycle (roughly every 3-4 months). Others take a year or more, and some never fully recover because the drop wasn’t really about the update, it was about content that never should have ranked that well in the first place. Set expectations accordingly before you start.

what you need

Google Search Console access with full ownership verification on the property
GA4 (or your analytics platform of choice) with at least 6 months of historical data
Google’s Search Central updates page bookmarked, so you can cross-reference rollout dates
A crawler: Screaming Frog SEO Spider (free up to 500 URLs, £259/year for the paid license) or Sitebulb
A spreadsheet for a changelog (Google Sheets is fine, this matters more than people think)
Wayback Machine access to pull historical versions of pages you’re editing
Optional but useful: Ahrefs or SEMrush (both start around $99-129/month) for competitor keyword comparison
Budget or time for content rewrites, freelance SEO writers typically run $0.05-0.15/word for competent work
2-6 months of patience, this is not a one-week fix

step by step

1. Confirm it was actually a core update

Before you touch a single page, rule out a manual action or a technical problem. Open Search Console, go to Security & Manual Actions, and confirm it’s empty. Then check the date your traffic dropped against Google’s confirmed core update rollout dates and their official blog, where major updates get announced directly.

Expected output: a traffic drop date that lines up within a few days of a confirmed rollout start or end date, and a clean manual actions report.

If it breaks: if the drop doesn’t line up with any confirmed update, check the Search Status Dashboard for indexing outages first, then look at your own deploy history, a broken robots.txt or an accidental noindex tag pushed the same week causes the exact same symptom.

2. Quantify the damage precisely

Pull Search Console Performance data comparing the 28 days before and after the drop. Segment by page and by query, not just the aggregate number. You want to know whether this hit specific page types (thin listicles, aggregator pages) or was site-wide.

Expected output: a spreadsheet ranking your top 50 pages by traffic loss, with clicks, impressions, and average position for each.

If it breaks: if GA4 and Search Console tell wildly different stories, trust Search Console for ranking behavior, GA4 is measuring sessions and can be thrown off by consent mode, bot filtering, or tagging changes that have nothing to do with rankings.

3. Audit content against what Google actually rewards

Read through your worst-hit pages with a critical eye, not an SEO checklist. Ask: does this page demonstrate first-hand experience, or does it read like it was assembled from other people’s summaries? Google’s own ranking systems guide is explicit that content lacking genuine expertise or experience is a target, not an incidental casualty.

Expected output: a short list, usually 10-30% of your hit pages, that are genuinely thin, generic, or AI-boilerplate with no original input.

If it breaks: if every page passes your own eye test but traffic still dropped, the issue is likely site-wide trust or a niche-level reassessment rather than individual page quality, look at your backlink profile and author credentials next instead of rewriting content that’s already fine.

4. Check technical health in parallel

Run a full crawl. In list mode from the command line this is fast for large sites:

screamingfrogseospider --crawl-list urls.txt --headless --save-crawl --output-folder ./crawl-audit

Cross-reference indexed URL counts before and after the drop using site:yourdomain.com searches, and diff two exported URL lists if you have them:

comm -13 <(sort before_urls.txt) <(sort after_urls.txt) > newly_indexed.txt
comm -23 <(sort before_urls.txt) <(sort after_urls.txt) > deindexed.txt

Expected output: confirmation that your important pages are still indexed and Core Web Vitals (checked in Search Console’s report) haven’t regressed.

If it breaks: if you find mass deindexation that isn’t explained by the core update, that’s a separate technical incident, fix it first, it will confound every other measurement you try to take.

5. Benchmark against who’s now winning

For your 10-15 highest-value lost keywords, look at who ranks in your old spots now. Check word count, format, whether they cite sources, whether there’s a named author with visible credentials. Ahrefs’ Content Gap tool or a manual SERP read both work.

Expected output: a clear pattern, usually more depth, more original data or examples, or clearer author expertise signals than your page has.

If it breaks: if the pages that beat you look objectively worse by every measure you can name, the loss may be about domain-level trust rather than that specific page, which changes your fix from “rewrite this page” to “fix the site.”

6. Prioritize and ship fixes

Don’t rewrite everything. Rank your problem pages by traffic potential and fix severity, then work top-down. Merge near-duplicate thin pages instead of trying to save each one. Add genuine expertise signals: author bios with real credentials, first-hand data, original photos, cited sources.

Expected output: a prioritized backlog with 5-10 pages shipped per week, not fifty pages rewritten in a weekend.

If it breaks: if you don’t have the writing or subject-matter capacity to do this well, it’s better to fix fewer pages properly than many pages superficially, a rushed rewrite that’s still generic won’t move anything.

7. Log every change with a date

Keep a changelog: page URL, what changed, date shipped. This is the step almost everyone skips, and it’s the reason most people can’t tell you what actually worked six months later.

Expected output: a running spreadsheet you can cross-reference against the next core update announcement.

If it breaks: if you’re mid-recovery and can’t remember what you changed when, stop new edits for a week and reconstruct the timeline from your CMS revision history or git log before continuing.

8. Wait for the next signal, don’t force it

Google has said repeatedly that core update effects are evaluated over the full rollout and pages can shift for weeks after a rollout completes. Re-check Search Console weekly, but don’t judge success or failure until at least one full update cycle has passed since your fixes shipped.

Expected output: a gradual recovery curve, if it’s working, position and clicks trend back up over weeks, not overnight.

If it breaks: if there’s zero movement after two full core update cycles and your content genuinely improved, it may be worth an editorial second opinion, sometimes the issue is a site-wide trust or backlink problem that content fixes alone won’t solve.

common pitfalls

Panic-rewriting the whole site at once. You lose the ability to tell which change worked, and you burn budget on pages that weren’t actually the problem.
Blaming the update for something else. A manual action, a bad deploy, or a robots.txt mistake produces an identical-looking graph. Rule these out first, every time.
Keyword-stuffing “expertise” signals instead of adding real ones. Slapping “10 years of experience” in an author bio without any actual credentials or original work fools nobody, least of all the systems Google uses to evaluate content quality.
Declaring victory on one good week. Search traffic is noisy. Wait for a sustained multi-week trend before calling anything a recovery.
Not keeping a changelog. Without dates, you can’t correlate your fixes with the next update’s outcome, which means you learn nothing for next time.

scaling this

At 10 sites, this process is manual and that’s fine, you can read every hit page yourself and make judgment calls. At 100 sites, manual review breaks down, you need a templated scoring rubric (word count, citation count, author byline present, last-updated date) applied consistently so you can triage by scale rather than judgment. This is also where a content-detection tool like Originality.ai (roughly $0.01 per 100 words scanned) earns its keep for flagging pages that read as unedited AI output.

At 1000+ sites or pages, you’re no longer doing page-level triage at all, you’re doing portfolio-level pattern matching: which site clusters got hit, which content templates correlate with losses, and pushing fixes through templates rather than individual edits. At this scale you need someone dedicated to the audit function full-time, and you should expect false positives in any automated scoring system, spot-check a sample before trusting the aggregate numbers.

where to go next

If you haven’t already mapped what Google actually means by expertise and trust signals, read e-e-a-t explained: what Google actually rewards before you start rewriting anything. For rebuilding lost rankings with new content rather than just patching old pages, see how to build a topical authority content plan. And if your audit turns up a thin backlink profile as a contributing factor, how to earn backlinks without buying them covers the legitimate paths. For more tutorials like this one, browse the full archive.

If part of your content audit involves checking pages for AI-generated boilerplate at scale, the detection tool roundups on aitoolgazette.com are worth a look, that’s not a space I track closely myself.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-07-17.