The first 48 hours of an organic traffic drop

Most organic traffic drops are investigated in the wrong order. Someone opens Search Console, sees a declining line, and the conversation immediately becomes a debate about algorithm updates. Two weeks later the team is implementing content changes for a problem that turns out to be a redirect.

Here is the order that actually narrows it down, and roughly what fits in the first two days.

Hour 0–2: Establish whether the drop is real

Before anything else: is traffic down, or is reported traffic down?

These are entirely different problems and they look identical in a chart.

• Compare Search Console clicks against GA4 sessions against CRM records over the same window. Search Console is measured before your site loads; GA4 is measured after. If GSC is flat and GA4 fell, the change is in your measurement, not in your traffic.
• Check whether a consent banner, a tag change or a container release happened near the date. A consent implementation that drops rather than models data can cut reported traffic overnight with no change in reality.
• Check whether the CRM still shows the same lead volume. If leads held and sessions fell, you are looking at a tracking problem.

We have watched teams spend a quarter recovering traffic that never left.

Hour 2–6: Find the exact date

Not the month. The day.

Pull Search Console at day-level granularity and export it, because the interface will not let you segment it the way you need. Then find the date separately for:

• each major template or site section
• brand versus non-brand queries
• each significant market

Different dates for different sections is itself a finding. A single site-wide date suggests one event — a release, a robots change, a migration. A staggered pattern across sections suggests recrawling, which suggests something structural that Google is discovering gradually.

If every section dropped on the same day and the day was a Tuesday, look at your deploy log before you look at anything else.

Hour 6–12: Indexation before position

This is the branch point that determines everything after it.

Ask: did the affected URLs leave the index, or are they still indexed and ranking lower?

• Left the index → technical. Canonicals, robots, noindex, status codes, rendering. Fast to find, usually fast to fix, and recovery is measurable within weeks of recrawl.
• Still indexed, ranking lower → content, authority, competition, or a quality update interacting with an existing weakness. Slower to diagnose, much slower to recover.

Read the coverage report by category, not the summary count. The category name frequently states the cause outright — "Alternate page with proper canonical tag", "Excluded by noindex tag", "Duplicate without user-selected canonical". We have seen a site where Search Console had been naming the exact cause for three months while the team debated content quality.

Hour 12–24: Diff the technical state

If the answer was "left the index", crawl now and compare against whatever you have from before the date — an old crawl export, the Wayback Machine, a staging copy, your git history.

Check specifically:

• canonical tags on the affected template
• robots.txt and meta robots
• status codes and redirect chains on the affected URLs
• the rendered DOM versus the raw HTML response
• internal links pointing at the affected URLs
• the sitemap contents for that section

The single most common finding in this bucket is a correct fix applied one level too broadly. Someone fixed variant duplicates and caught base products. Someone blocked a staging path and matched a production one. Someone added a canonical to a template that more pages use than they realised.

Hour 24–36: Compare page and query cohorts

Now separate the affected URLs into a cohort and analyse only that cohort. Site totals hide everything.

For the affected cohort against an unaffected control cohort:

• impressions change versus clicks change (a click drop with flat impressions is a result-layout or title change, not an indexing problem)
• average position change
• which specific queries lost impressions
• whether those queries still exist at all — sometimes demand genuinely fell

Impressions falling before clicks usually means the pages stopped being shown. Clicks falling with impressions steady usually means they are still shown and being chosen less — a different problem with different fixes.

Hour 36–48: Only now consider external causes

By this point you have either found a cause or eliminated the whole technical and measurement space. That is when known search updates, competitor movement and seasonality become the reasonable explanation rather than the default one.

And even here, look at the pattern rather than the timing alone. Updates rarely affect a strong site evenly. Which page types were hit, and which were not, is usually pointing at a real weakness that is worth fixing whatever caused the timing.

What not to do in the first 48 hours

• Do not ship fixes yet. Every change you make now makes attribution harder later. Diagnose first, then fix in ordered, attributable groups.
• Do not "improve content" as a first response. It is the slowest possible feedback loop and it is almost never the cause of a sudden drop.
• Do not disavow anything. Reflexive link disavowal remains one of the more reliable ways to make a bad situation worse.
• Do not conclude "algorithm update" because the date is near one. Google ships changes almost continuously; proximity is not evidence.

The one-page version

1. Is it real, or is it reporting?
2. What is the exact date, per template and per query class?
3. Did the pages leave the index, or drop in position?
4. What changed technically around that date?
5. What do the affected URLs have in common that the unaffected ones do not?
6. Only then: what happened externally?

If your current answer to question 2 is "sometime in the spring", that is where to spend today.