Traffic Dropped After a Core Update: 7-Day Triage
A 7-day triage worksheet for confirming a core update caused a traffic drop, measuring the size of the drop in Search Console, and running Google's self-assessment before rewriting anything.
If blog traffic dropped and you suspect a core update, do not start rewriting pages on day one. Google's own core-update documentation recommends confirming the update's start and end dates on the Search Status Dashboard, then waiting about a week after rollout completes before comparing a week-after period against a week-before period in Search Console. Rewriting before that window closes means editing against incomplete data.
Use the 7-day triage worksheet below. It sequences confirmation, measurement, and self-assessment so the first edit you make is based on evidence, not day-one panic.
Who is this guide for?
This is for founders and editors who see blog traffic drop and immediately suspect "a core update." Google's core-updates documentation is explicit that a core update is a broad, systemic change and "don't target specific sites or individual web pages." That means the first job is confirming the update actually overlaps your drop in time, not assuming causation because the timing feels close. If the drop shows up as impressions holding steady while clicks fall, Search Console shows impressions but no clicks: what to fix first is the more precise diagnosis to run instead.
Did a core update actually cause my traffic drop?
Check the Search Status Dashboard for the start and end date of any recent core update before concluding anything. Google's documentation directs site owners there specifically to confirm timing. If your traffic drop began before the update's start date, or continued unchanged well past its end date with no other rollout nearby, a core update is a less likely sole explanation, and the worksheet's day 2 step (checking for site-specific causes) becomes more important.
What goes on the 7-day triage worksheet?
Day 1 is the day the Search Status Dashboard marks the rollout complete. Confirm the dates and rule out site-side causes on day 1, make no page edits through day 6, and on day 7 compare the week after completion with the week before the rollout started, then self-assess the biggest drops.
Copy this into a document or spreadsheet and fill in the dates and rows as you go. Do not skip to day 7's action items early.
| Day | Task | What you're confirming | Do not do yet |
|---|---|---|---|
| Day 1 (rollout complete) | Check the Search Status Dashboard for the update's start and end date. | Whether the update's timing actually overlaps your drop. | Do not assume causation from timing alone. |
| Day 1 | Check for non-core causes: a broken deploy, robots.txt change, noindex tag, expired redirect, or lost backlink source. | Whether a site-side change, not Google's algorithm, explains the drop. | Do not skip this because "a core update happened" is the easier story. |
| Day 2–6 | Wait out the full week after the rollout completed, as Google's core-updates documentation recommends. Avoid making page edits during this window. | That the week-after comparison uses a complete week of post-rollout data. | Do not rewrite pages mid-rollout; you cannot yet tell if the edit helped or if the rollout was still moving. |
| Day 7 | In Search Console's Performance report, compare the week after rollout completed against the week before it started. | The real size of the change: clicks, impressions, and position, filtered to the affected pages. | Do not compare arbitrary date ranges that do not bracket the rollout dates. |
| Day 7 | Classify the size of the position change per page: a small shift (for example position 2 to 4) versus a large one (for example position 4 to 29). | Whether this is a minor reshuffle or a significant demotion worth deeper review. | Do not treat every page with any drop as equally urgent. |
| Day 7 | Run Google's self-assessment questions against the pages with the largest drops. | Whether the page still reads as original, expert, people-first content compared to what else now ranks for the query. | Do not rewrite yet; record the assessment first, then decide keep, refresh, or deeper audit. |
| After day 7 | Decide the next action per page: keep, refresh, merge, or route to a deeper content audit. | That the action matches the evidence gathered, not a same-day reaction. | Do not decide to prune a page as a first response; Google's guidance treats pruning as a last resort. |
How do I measure the actual size of the drop, not just the feeling of it?
Open the Performance report in Search Console and use the date filter to set two ranges: one week starting after the core update's rollout completed, and one week ending before it started, per Google's own recommended comparison method. Look at clicks, impressions, CTR, and average position together, not clicks alone, since Google's Performance report documentation defines average position as "the average position of the topmost result from your site" for a query, which can shift even when click volume looks stable at first glance. Use daily granularity to catch the moment of change, then switch to weekly to see the trend without daily noise. To see where the loss sits, export the Pages table in Compare mode and paste it into the Search Console click drop analyzer: it splits each page's click change into lost impressions and lower click-through, marks position drops, and shows whether the loss is one page, one section, or most of the site. A drop concentrated in a few pages with different causes is not the site-wide pattern a core update self-assessment is for.
What does Google's self-assessment actually ask?
Google's helpful-content documentation frames self-assessment as content-and-quality, expertise, and presentation questions rather than a single traffic metric. Representative questions include whether the content provides original information, reporting, research, or analysis; whether it is the sort of page a reader would bookmark or recommend; and whether it was written or reviewed by someone who demonstrably knows the topic. Apply these to the specific pages that dropped the most, not the whole site at once, and record the answers in the worksheet before deciding on a rewrite.
What should you do after day 7?
- Sort affected pages by size of position or click change, largest first.
- For each page in the top group, record the self-assessment answers directly in the worksheet.
- Route pages that fail the self-assessment into a full content decision, using the AI Overviews content audit on this site if the page needs a defend/rewrite/merge/kill call.
- Route pages that pass the self-assessment but still show a real drop into your content maintenance calendar as an earlier-than-scheduled review trigger.
- Recheck recovery timing with the understanding that Google's documentation says recovery can take from a few days to several months, and that if months pass without improvement, a site may need to wait for the next core update to see a change.
For a structured keep, refresh, or merge score across all the pages you flagged on day 7, the content durability scorer turns the worksheet's per-page notes into one comparable decision.
Claim ledger
| Claim | Source | How to use it safely |
|---|---|---|
| Core updates are broad, systemic changes and do not target specific sites or individual pages. | Google Search Central, Google Search's core updates, accessed 2026-09-16. | Use to avoid treating a drop as a targeted penalty before checking other causes. |
| Google recommends checking the Search Status Dashboard for a core update's start and end date, then comparing a week-after period against a week-before period once rollout is complete. | Google Search Central, Google Search's core updates, accessed 2026-09-16. | Use as the basis for the day 1 and day 7 worksheet steps; do not compare arbitrary date ranges. |
| Recovery from a core update can take a few days to several months, and site owners do not need to wait for another named core update to see change. | Google Search Central, Google Search's core updates, accessed 2026-09-16. | Use to set realistic recovery-timeline expectations; do not promise a fixed recovery date. |
| The Performance report's average position field is the average position of the topmost ranking result from the site for a query, and date range or search type can be changed with report filters. | Search Console Help, Performance report (Search results), accessed 2026-09-16. | Use to correctly read the report during the day 7 comparison. |
| Google's self-assessment includes questions about original information, expertise, and whether a reader would bookmark or recommend the content. | Google Search Central, Creating helpful, reliable, people-first content, accessed 2026-09-16. | Use as the literal self-assessment questions for the day 7 review step; do not invent additional scoring criteria. |
FAQ
How do I know if a core update caused my traffic drop?
Check the Search Status Dashboard for the update's confirmed start and end dates, then compare your Search Console data from before the update to after it completed. If your drop's timing lines up with the rollout window and no site-side cause (broken deploy, robots.txt change, lost backlinks) explains it, a core update is a plausible cause, though Google's documentation notes these changes are broad and not targeted at individual sites.
How long should I wait before comparing Search Console data?
Wait until the rollout has completed, per the Search Status Dashboard's end date, then compare one week after completion against one week before the update started. Comparing data mid-rollout can make the change look smaller or larger than it actually is.
Should I rewrite pages immediately after a core update?
No. Confirm timing, measure the size of the change per page, and run Google's self-assessment questions on the pages with the largest drops before rewriting anything. Google's guidance treats pruning or rewriting as steps to take after assessment, not a same-day reaction.
How long does recovery from a core update take?
Google's documentation says recovery timing varies: some changes take effect in a few days, but confirming improvement can take several months. Site owners do not need to wait for the next named core update, since smaller updates happen continuously.
What if my traffic drop does not line up with a core update's dates?
Treat it as a site-specific issue instead. Check for a broken deploy, an unintended noindex or robots.txt change, an expired redirect, or a lost referral or backlink source before assuming an algorithm update is responsible.
Sources
- Google Search Central, Google Search's core updates: https://developers.google.com/search/docs/appearance/core-updates
- Search Console Help, Performance report (Search results): https://support.google.com/webmasters/answer/7576553
- Google Search Status Dashboard: https://status.search.google.com/
- Google Search Central, Creating helpful, reliable, people-first content: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Our own 7-day triage worksheet and claim ledger, last reviewed 2026-09-16.