What to check when traffic suddenly drops

A traffic graph falling off a cliff is alarming, and the instinct is to assume the worst explanation immediately — a penalty, a competitor overtaking you, an algorithm update targeting your entire site specifically. Most of the time the real answer is more mundane and considerably easier to fix. Working through causes in order of how common and how checkable they are, rather than jumping to the most dramatic explanation, gets you to the actual answer faster.

First: confirm the drop is real

Before investigating anything, check the number in a second data source. Compare Google Analytics against Search Console's own click and impression data for the same date range. A drop that shows in one but not the other often points at a tracking or measurement problem rather than an actual traffic loss — a tracking code accidentally removed during a site update, a caching plugin serving a stale page that no longer includes it, or a consent tool blocking analytics scripts more aggressively than intended.

Second: check for a technical fault

Technical faults are the most common real cause of a sudden drop, and they are also the fastest to both find and fix once identified.

• A noindex tag or robots.txt block applied accidentally, often during a site update, a theme change, or a migration where a staging setting was never switched off. See how to check Google can crawl your site for how to confirm this directly.
• A broken redirect or a wave of new 404 errors, which Search Console's Coverage report will usually surface within a few days of the underlying cause.
• An expired SSL certificate, which can trigger browser warnings that suppress both visits and, over time, indexing.
• A slow or failing server, which can cause crawl errors serious enough that Google temporarily reduces how much of the site it fetches.
• DNS pointing at the wrong place, following a recent domain or hosting change that has not fully settled — see how long DNS propagation takes if this coincides with a recent change.

These causes share a useful trait: they are entirely within your control to find and fix, and fixing them tends to produce a real, visible recovery once Google recrawls the affected pages.

Third: check for a specific, identifiable change on your own site

If nothing above explains it, look at what actually changed around the date the drop began. A redesign, a plugin update, a new theme, a content migration, or even a change to internal linking can all shift how a site is crawled and evaluated, sometimes with a delay between the change and its visible effect. Comparing the exact date of the drop against your own change log or deployment history is more reliable than guessing from memory.

Fourth: consider a genuine algorithm update

Google runs core updates periodically, and it does publicly confirm when a broad update is rolling out, though it deliberately does not detail exactly what changed or which sites are affected. If your drop's timing lines up with a publicly confirmed update, and nothing technical or content-related on your own site explains it, this becomes the more likely explanation. Even then, the response is rarely a single fix — it is usually a broader, honest look at whether the affected pages are genuinely the best available answer to the queries they targeted, which takes time rather than a quick correction.

Fifth: rule out a manual action

Search Console's Manual Actions report, sitting quietly in the Security & Manual Actions section, will state directly if Google has taken manual action against the site for a specific, named violation. This is a completely different situation from an algorithmic ranking change — it requires a specific fix for the stated reason and, in some cases, a reconsideration request afterwards. It is also relatively rare, which is precisely why it is worth checking directly rather than assuming.

Working the list in order

Keep a simple record of significant site changes as you make them — a plugin update, a redesign, a migration date — even a short note is enough. That single habit turns "when did this start" from a guessing exercise into a quick lookup the next time a graph does something unexpected.

The value of checking these in sequence — confirm the drop, then technical faults, then your own recent changes, then a broader algorithm question, then manual actions — is that it moves from the most common and most fixable causes toward the least common and hardest to influence. Most traffic drops resolve at one of the first two steps. Very few genuinely require the last two, and treating every drop as an algorithm penalty from the outset usually means missing a simple technical fault that was sitting there the whole time.