Traffic Collapsed Overnight: A Diagnostic Protocol in Order of Probability

The message always arrives the same way, usually on a Monday: traffic has collapsed, something must have happened, what do we do. The instinct is to assume an algorithm update, because that is the explanation that requires no one to have made a mistake. It is also, in our experience, one of the least likely causes.

This article is the diagnostic protocol we work through, in order of probability, using the Semalt platform to separate the possibilities quickly. It is designed so that the first thirty minutes eliminate most of the candidates.

Step zero: is the drop real?

Before investigating anything, confirm that traffic actually fell. A meaningful number of emergencies turn out to be measurement problems, and thirty seconds of checking prevents days of wasted investigation.

1. Check whether the tracking code is still present

   Deployments remove analytics tags routinely. If sessions dropped to near zero abruptly across every page and source at once, this is almost always the cause.

2. Compare against a second source

   If search impressions are stable while analytics shows a collapse, your traffic is fine and your measurement is not. If both fell, the drop is real.

3. Check whether it is seasonal

   Compare to the same period last year, not to last month. In several industries, a forty per cent August fall is the calendar rather than a problem.

4. Check whether it is one country or device

   A drop confined to a single segment usually points at something specific — a redirect, a regional change, a broken mobile template — rather than a general loss of standing.

Working parameters from the protocol described below.

Step one: technical causes, by probability

Overwhelmingly the most common category, and the fastest to check.

The first row is worth checking before anything else every single time, because it takes ninety seconds and it is catastrophic when true. A staging noindex that reached production explains more sudden collapses than every algorithm update combined.

Step two: content and structural causes

If nothing technical explains it, look at what changed on the site itself. Pages deleted during a cleanup, a section moved without redirects, a template that dropped a chunk of copy, internal links removed in a redesign, a large batch of thin pages published that changed how the site is understood overall.

We cover this in detail in Internal Links: The Free Lever Almost Every Site Leaves Unused.

This category is diagnosed by comparing crawls across time. If a crawl from two months ago exists, the diff usually answers the question in minutes. If it does not, this is the moment you understand why we keep saying to store them.

Step three: external causes

Only now, once the first two categories are eliminated, is it reasonable to look outward.

Other external explanations exist and are often overlooked. A competitor may have launched something substantial. Demand for the topic may have genuinely fallen — check whether impressions dropped across everyone or only for you. A results page may have gained a feature that absorbed the clicks, which shows as stable positions with falling traffic. And on rare occasions a manual action applies, which is the one case that announces itself in Search Console rather than requiring detective work.

There is a full walkthrough in Structured Data in Practice.

What not to do in the first week

The damage in these situations is frequently self-inflicted, and it happens in the first days when pressure is highest and information is lowest.

Do not rewrite large amounts of content immediately. If the drop is a fluctuation, you will have changed the pages that were working, and when things recover you will not know what recovered them.

Do not disavow links in a panic. Aggressive disavowing on a hunch has caused more harm in our experience than the links being disavowed.

Do not deploy five fixes at once. If any of them works, you will not know which. Change one thing, record the date, and wait.

And do not promise a recovery date. You do not know one, the honest answer is a range with conditions, and a specific date given under pressure becomes the thing you are measured against.

Working the recovery

Once the cause is identified, the response depends on which category it fell into.

Technical faults recover quickly and predictably — often within days of the fix being crawled, since nothing was actually wrong with the pages themselves. This is why the technical category is worth exhausting first: it is both the most likely and the most fixable.

Content and structural causes take longer, typically weeks, because the pages have to be reassessed. Restore what was removed where possible; where it is not, rebuild the equivalent.

Algorithm-related declines are the slowest and the least amenable to a single fix. The productive response is to identify which segment was affected and what the pages that gained have that yours do not, then improve accordingly, accepting that recovery may come with a subsequent update rather than immediately.

See also: Images and Video.

Handling the conversation while you investigate

The technical work is only half of it. The other half is what you say to the client or the board in the first hours, when you do not yet know the answer and someone senior wants one.

Three things make that conversation survivable. Say what you know, what you have ruled out, and when you will next report — in that order. "We have confirmed the drop is real, ruled out tracking and indexability, and are checking deployment history; I will update you at four" is a complete answer even though it contains no diagnosis. It demonstrates a process, which is what the person is actually asking for.

Resist the pressure to name a cause early. The instinct under pressure is to offer the most plausible explanation available, which is usually "an algorithm update" — and once said out loud it becomes the working assumption for everyone, making it socially awkward to later report that a developer shipped a noindex. Provisional explanations are much harder to withdraw than to withhold.

Set expectations about timeline honestly and early. Some causes are found in thirty minutes; some take a week to be confident about. Saying "if it is technical I will know today, if it is not it will take longer" is accurate and prevents the hourly check-ins that make the work slower.

And when you find it, report the cause plainly even when it is embarrassing for someone. A drop caused by a deployment is a process problem worth fixing; a drop attributed vaguely to the algorithm teaches nobody anything and guarantees a repeat.

Making the next one cheaper

Most of what makes a traffic drop expensive is not the drop; it is the absence of information about the state before it. Three habits fix that entirely.

Keep scheduled crawls so that technical changes appear as a diff rather than requiring reconstruction. Track a stable keyword set so that "we lost rankings" is measurable rather than an impression. And keep a simple deployment log — even a shared note with dates — so the question "what changed" has an answer that does not depend on memory.

None of that prevents drops. All of it turns a week of investigation into an afternoon, which is usually the difference between a manageable incident and a crisis.

The protocol, in one paragraph

Confirm the drop is real. Check noindex, robots.txt and status codes. Ask specifically what was deployed. Compare crawls to find structural changes. Look at the shape of the curve to distinguish a fault from an update. Check whether competitors moved. Change one thing at a time, record everything, and do not promise a date.

That sequence resolves the large majority of cases within a day, and the ones it does not resolve are at least correctly classified, which is where any real recovery has to start.

If you are in this situation now and have no historical crawl to compare against, run one immediately — it becomes the baseline for everything that follows. Open the dashboard, crawl the site, and start with indexability.