August 2024 Core Update: What to Check Before Changing Anything

The August 2024 core update is still rolling out. So change nothing on your sites. Seriously, nothing. Confirm the rollout status first, then rule out technical causes, and only after that sit down to compare periods in Search Console. Google announced the update on August 15, 2024, and it has only just started, which means any ranking movement you see today is provisional. Running several content sites? Then a calm checklist will do far more for you than panic edits made on announcement day.

What Google has said about the August 2024 core update

Officially, this one continues Google’s work on search quality. In its announcement of the August core update, the company says the aim is to show more content that people find genuinely useful and less content that feels made just to perform well on Search. And alongside the launch it refreshed its help page about core updates, adding more in-depth guidance for sites that see changes.

A Google core update is broad by design. It does not target specific sites or individual pages. The documentation uses a comparison I rather like: revising a list of favorite restaurants after a few years. New places appear, some move up, and the ones that slip are not necessarily bad. Others simply earned a spot above them.

Why should you wait before editing anything?

Because rankings can keep moving for the whole rollout. A snapshot taken today is a shaky basis for any decision. Google’s own guidance on assessing core updates tells you to confirm on the Search Status Dashboard that the rollout has finished and then wait at least a full week before analyzing anything.

There is a second problem with mid-rollout edits. Rewrite pages while positions are still shifting and you can no longer tell which movement came from the update and which from your own work. You have muddied your own data. So put the waiting time to use:

• note the start date and watch the dashboard for the end date,
• freeze non-essential changes to templates, structure and content,
• keep a log of everything that does get deployed, with dates.

Rule out technical causes of a core update traffic drop first

A drop that lands during a core update is not automatically caused by it. Open your change log. Did anything on your side happen on the same days? A technical fault looks identical in a traffic chart, and that is exactly the trap. The usual suspects:

• a server or IP migration,
• outages and error responses,
• proxy or DNS changes,
• a domain change,
• a robots.txt rule or noindex tag that slipped into production,
• a template or CMS deploy.

Each of these has its own diagnosis. We have covered ranking drops after migrations separately, along with the limits of a reverse proxy as a fix for visibility problems. And if a rebrand landed in the same window, compare what was done against a checklist for planning a domain change.

Be honest with yourself about what this step can achieve, though. Infrastructure fixes solve infrastructure problems. That’s it. New IP addresses or a proxy do not recover a site from a core update, because the update concerns how content is assessed, not where it is served from.

How to compare periods in Search Console performance reports

The comparison only makes sense between a settled week after the rollout and a week before it began. Going by the core updates documentation, the sequence is:

1. Record the start and end date of the rollout from the Search Status Dashboard.
2. Wait a full week after completion.
3. In the Search Console performance report, compare that week with a week before the rollout started.
4. Review top pages and top queries separately to pinpoint what changed.

Site totals hide the detail. A flat overall line can easily mask one section falling while another rises. For a portfolio, run the same comparison per property, otherwise one site’s decline gets read as a pattern across all of them. Oh, and keep seasonality and your own deploys in mind too: August traffic differs from early summer for many topics, algorithm change or no algorithm change.

Small drop or large drop: what each one calls for

The size of the move decides the response. Google’s core updates help page gives its own examples: slipping from position 2 to 4 is a small drop, while falling from 4 to 29 is a large one.

A small drop? No drastic action needed, and Google explicitly recommends avoiding changes to content that already performs well. A large, sustained decline across the site is a different story. That one warrants a deeper assessment of the site as a whole, not just of individual pages. Make the call per site and per page group. Treat the entire portfolio as one case and you end up rewriting pages that were never affected in the first place.

What core update recovery realistically involves

No shortcuts here. Core update recovery comes from content that is helpful, reliable and written for people first, not from quick technical tricks. Google points affected owners to its self-assessment questions, and for someone running content sites they boil down to a fairly practical review:

• Does each page actually solve the query it targets?
• Which pages are thin, or duplicated across the portfolio?
• What was written only to rank?

The good news: improvements do not necessarily have to wait for the next major update to show results. Google says it makes continual changes to its search algorithms, including smaller core updates that go unannounced, and those are another opportunity for improved content to rise.

So, wondering what to do after a core update announcement? For the August 2024 core update the order is simple: wait for the rollout to end, rule out technical causes, compare periods, and only then decide what, if anything, deserves a rewrite.

FAQ