SEO QA Checklist: First 24 Hours After a Google Update

Every time a Google core update rolls out, the same pattern repeats. SEOs scramble to check rank tracking tools, post panicked questions in communities, and refresh Search Console hoping something changes. Most of this activity produces noise, not signal.

The problem is not the update. The problem is not having a structured way to separate actual impact from normal ranking fluctuation.

This is the QA checklist I run in the first 24 hours after a core update lands. It tells me what actually changed, what needs fixing, and what I can ignore.

Key takeaways

• Structured response beats panic: the instinct to investigate everything usually leads to fixing nothing — a checklist gives you a way to separate actual impact from normal ranking fluctuation.
• Pull baseline data first: export 28-day GSC performance data, a coverage report snapshot, and average position for top 20 pages before looking at what changed.
• Not every update affects every site: run the checklist whenever tracking shows unusual movement, not automatically after every announced update.
• The checklist covers three layers: quality signal review (content depth, E-E-A-T, engagement), technical signal review (indexation, crawl errors, canonicals), and content audit against current top results.
• Recovery verification is part of the checklist: confirm affected URLs reappear in GSC coverage, canonical chains resolve cleanly, and no new errors introduced by fixes.

Does this checklist apply to every update?

Short answer: run it whenever you see unexpected ranking changes or traffic drops after any Google update.

Not every update affects every site. But if your tracking shows unusual movement, the instinct to immediately investigate everything usually leads to fixing nothing. This checklist gives you a structured way to respond instead of reacting to every chart wobble.

Step 1: Pull baseline data before looking at the update impact

This sounds backwards. Most people jump straight to checking what changed. You cannot know what changed unless you know what was normal before.

Before doing anything else, export three datasets:

1. Search Console performance data for the 28 days before the update. Set the date range explicitly. You need the baseline.
2. Coverage report snapshot. Every URL in the indexed state.
3. Average position and impressions for your top 20 pages by traffic.

Write down the date the update started. Google usually announces core updates on their channels. If you are reading this after the fact, use the commonly accepted date from SEO publications.

Why this matters

Rank fluctuation is normal. Every dataset has variance. If you see a position drop on day one, you need to know if that URL was stable before the update or if it was already moving. The 28-day window gives you that context.

Step 2: Check Search Console for indexation changes first

Most SEOs jump to rankings. I check indexation first because a ranking change caused by an indexation defect is fixable. A ranking change caused by an algorithm shift is a longer-term problem.

In Search Console, go to Coverage. Look for:

• Any increase in Excluded URLs — pages that were indexed but are now dropped
• Any spike in Not indexed status for URLs that were previously indexed
• Changes in the Sitemap section — URLs suddenly removed from sitemap recognition

Specifically watch for the Discovered - currently not indexed status. This means Google found the URL but chose not to index it. That decision can change after an update. See the discovered currently not indexed fix guide for the specific steps to take when pages are stuck in this state.

If you see indexation drops, compare the affected URLs against your canonical structure. Are the dropped pages high-value landing pages or thin content pages that should not have been indexed in the first place?

Step 3: Identify which page types lost position

Rankings do not change uniformly across a site. Core updates tend to affect specific page types differently.

In Search Console, segment your pages by:

• Content type — blog posts, product pages, category pages, homepage
• Topic cluster — pages covering YMYL topics vs informational content
• Traffic volume — high-traffic pages vs long-tail pages

Filter your performance report by these segments and check if the position changes are concentrated in one segment.

This is where most SEOs stop. They see an aggregate position drop and panic. The aggregate tells you nothing. The segment tells you what happened.

For example: a site with thin product descriptions might see category pages drop while blog posts stay stable. That is a signal pointing to a content quality issue, not a technical issue.

Step 4: Check for manual actions before assuming an algorithmic cause

In Search Console, go to Security and Manual Actions. If Google has issued a manual action against your site, algorithmic changes will compound the penalty.

A manual action does not go away after an update. It needs to be fixed and resubmitted for review.

If you have no manual actions, rule this out and proceed knowing the issue is algorithmic.

Step 5: Compare your SERP positions against actual competitors

Tracking tools show you your position for your tracked keywords. They do not always show you who you are losing to.

For every keyword that dropped, check the SERP manually. Look at:

• Who is now ranking above you
• Whether AI Overviews have appeared or expanded for that query
• Whether the SERP feature mix has changed — more featured snippets, more image results, more video content

I have seen sites drop because a competitor published better content. I have also seen sites drop because Google added an AI Overview that pushed organic results below the fold.

These are different problems requiring different fixes. The SERP check tells you which one you are facing.

Step 6: Verify Core Web Vitals did not become a ranking factor mid-update

Google’s page experience signals are confirmed ranking factors. After any core update, it is worth checking whether your Core Web Vitals scores changed for any pages.

In Search Console, check the Core Web Vitals report. Look for pages that moved from Poor to Needs improvement or vice versa.

If a page that dropped in rankings also shows a Core Web Vitals degradation, the Vitals issue may be compounding the algorithmic change. Fixing it will not recover the algorithmic drop, but it removes a suppressive factor.

Step 7: Run a quick content quality scan on affected pages

Core updates often penalize pages with specific quality issues. On affected pages, check for:

• Thin content — pages with fewer than 300 words that were probably should not rank
• Outdated information — articles on topics where the landscape has changed but the content has not
• Missing E-E-A-T signals — no author, no sources, no clear expertise demonstration
• Advertising-to-content ratio — pages with excessive advertising above the fold

If your dropped pages are thin content pages, the update may be doing exactly what it is supposed to do. Trying to recover those rankings with technical fixes is the wrong approach.

Step 8: Check for negative SEO signals

After a core update is a common time for competitors to test negative SEO tactics. In your Links report, check for:

• Sudden spikes in low-quality referring domains
• Links from link farms or PBN networks you have not participated in
• Anchors that are exact-match commercial keywords on unnatural-looking link profiles

Negative SEO is largely ineffective against sites with strong natural link profiles. But if your site is newer or has a weaker backlink profile, a sudden link attack can amplify a core update’s effects.

Disavow obviously toxic links if you see a spike. This will not recover algorithmic rankings but removes a compounding factor.

Step 9: Document what you found before making changes

Write down:

1. What dropped — specific URLs, keywords, page types
2. What did not change — URLs and keywords that were stable
3. What the SERP shows — competitors, AI Overviews, SERP features
4. What the data suggests — quality issue, indexation issue, competition issue, or negative SEO

This documentation serves two purposes. First, it lets you track whether changes you make actually move the needle. Second, it gives you evidence when you need to explain to clients or stakeholders what happened and what you are doing about it.

Step 10: Prioritize fixes, then wait

After the checklist, you will have a clear picture of what needs attention.

If the issue is indexation — fix the coverage problems first. The SEO Analyzer can help you audit indexation coverage across your important URL paths.

If the issue is content quality — do not make changes immediately. Core updates play out over days to weeks. Making hasty content changes during an active update can make things worse. Wait for the update to fully roll out, then address quality issues.

If the issue is competition — the answer is usually better content, not more technical fixes. There is no shortcut here.

If the issue is Core Web Vitals — these are worth fixing regardless of the update. Poor Vitals suppress rankings even when the core algorithm has not changed.

The 48-hour rule

After any core update, do not make site-wide changes in the first 48 hours. Google’s core updates roll out gradually. The full impact is rarely visible immediately.

Run this checklist at the 24-hour mark to establish your baseline understanding. Run it again at the 72-hour mark when more of the update signal has stabilized.

Most ranking changes you see in the first 24 hours will look worse than they are because the update is still propagating.

What SEOKit24 adds

The checklist above turns an overwhelming event into a structured investigation. Once you know what broke, the actual fix work begins.

Use the SEO Analyzer to verify indexation coverage across your most important URL paths. If the issue points to content quality, the Meta Tag Analyzer can help identify pages that may need better title and description signals to compete.

Summary: Core updates cause panic because most SEOs react without a checklist. The first 24 hours should be spent gathering data, not making changes. Check indexation, segment your ranking changes by page type, verify the SERP landscape, and document what you find. Then prioritize fixes based on what the data actually shows.

Frequently asked questions

How do I know if a ranking drop is from a core update or something I did wrong?

Core updates typically affect entire site sections or page types uniformly, not individual URLs in isolation. If you see drops concentrated on blog posts or product pages across multiple queries, it is likely an algorithmic shift. Drops on specific URLs after you made changes point to something you changed. Check your site logs and change history first.

Should I make changes during the 48-hour window after an update?

No. Core updates roll out gradually over 48-72 hours. Changes made during the active rollout period may be based on incomplete data and can compound problems. Gather your baseline data, run the checklist, but hold off on content or technical changes until the rollout is complete.

My site dropped but I cannot find a technical or content issue. What now?

This is the most common outcome after a core update. The site was not “broken” — it was outperformed by competitors who improved their content or user experience. The fix is not a technical audit; it is a content audit. Compare your dropped pages against what now ranks above them.

Is it worth disavowing links after a core update?

Only if you see a clear spike in toxic links coinciding with the update. Disavowing links has no positive effect on algorithmic rankings — it only removes a potential negative factor. If your link profile looks normal, disavowing is unlikely to help.

When should I expect to see recovery after fixing issues?

Core update recovery typically takes one to three months after making changes. Google needs to reprocess affected pages, evaluate the improvements, and update rankings accordingly. Checking rank tracking daily after a fix creates false anxiety — monthly check-ins give a clearer picture.