Why Is My Organic Traffic Dropping?

Answer one question before anything else

Did impressions fall, or only clicks? Everything downstream depends on this, and it takes thirty seconds in Search Console's Performance report with both metrics enabled.

• Impressions fell too: Google is showing your pages less often. That is a ranking or indexation problem, and it is the more serious case.
• Impressions held, clicks fell: your positions did not change. The result page changed around you, or your snippet stopped earning the click.

Those two need completely different responses, and skipping this check is how teams spend a month rewriting content to fix what was a title problem.

The four shapes a drop takes

The shape narrows the cause faster than any amount of keyword-level detail:

The drops that are not drops

Before diagnosing, rule out the four ways a drop can be a measurement artefact:

• The data is incomplete. Search Console lags two to three days, so the most recent days always look like a decline.
• Seasonality. Compare year over year, not month over month, on anything with a seasonal shape.
• A property or filter change. A different date range, country filter or search type produces a drop that exists only in the comparison.
• You are reading GA4, not Search Console. A consent banner or tag change moves GA4 sessions without touching a single ranking, which is one of the reasons the two never agree anyway.

The diagnosis order that saves a week

1. Manual Actions. Ten seconds, and it changes everything if present.
2. Indexation. Did the number of indexed pages fall? The Page indexing report names Google's reason.
3. Impressions versus clicks. The split from the top of this page.
4. Which pages, specifically. Sort by clicks lost. If the losses cluster in one section, you have a template problem, not a site problem.
5. Your deploy history against the drop date. Correlation here is usually the answer.
6. Only then, algorithm updates. By this point you know whether the pattern fits one.

Compare the last 28 days against the previous 28 for my site. List the 15 pages that lost the most clicks. For each, show impressions change, click change, average position change and CTR change. Group them by URL path so I can see whether the losses concentrate in one section. Flag any page where impressions held but CTR fell more than 20%.

Narrowing it to a section

The single most useful move after the impressions check, and the one most people skip: group the losses by URL path. A drop that looks site-wide in a total often turns out to be one template.

Export the pages that lost the most clicks and sort them by directory. Three patterns appear, and each names a different cause:

• Losses concentrated in one path. A template or deploy problem. Crawl that template and compare it against a page that did not drop.
• Losses spread evenly across paths. Something site-wide: an algorithm shift, a competitor gaining broadly, or a technical change affecting every page.
• Losses on your oldest content only. Ordinary decay, which is a content-refresh problem rather than an incident.

This one sort turns an unbounded investigation into a specific one, and it takes about five minutes.

What not to do while diagnosing

• Do not change several things at once. A panic response that rewrites titles, adds content and adjusts internal links leaves you unable to attribute any recovery, which means you learn nothing for next time.
• Do not disavow links reflexively. Google generally ignores low-quality links rather than penalising them, and a careless disavow removes signals you wanted.
• Do not republish everything with a new date. Changing dates without changing content is a pattern rather than a fix, and it removes your ability to tell which pages genuinely were updated.
• Do not act on a week of data. Search Console lags two to three days and its recent edge is provisional, so the last week always looks worse than it is.

Making the next one easier to diagnose

Every drop is easier to diagnose if three things were already in place, and all three take an afternoon to set up:

• A change log with dates. Deploys, template changes, content updates, consent banner changes. This is the single most useful artefact during an incident and nobody has it when they need it.
• A history pipeline. Search Console keeps 16 months, so the year-over-year comparison you will want in two years has to be captured starting now.
• Scheduled crawling. Regressions arrive with deploys, and a quarterly manual crawl can miss one by three months.

None of the three helps during the drop you are currently investigating, which is exactly why they get skipped every time. The best moment to set them up is the week after an incident, while the cost of not having them is still fresh enough to justify an afternoon.

When it really is an update

Sometimes it genuinely is. The signs that fit: the drop starts within a known rollout window, it affects whole content types rather than scattered pages, competitors in your space report the same thing, and nothing in your own change log lines up.

If that is the pattern, the response is not a quick fix. Core updates reassess quality broadly, so the recovery work is the same work you would do anyway: improve the pages that lost most, and consolidate what was never worth keeping.

Then wait for the next assessment, which is the genuinely hard part. Our guide to a site that never ranked covers the adjacent case, where nothing is dropping because nothing arrived.