Sitewide Drops Versus Page-Level Drops

A sitewide drop is usually technical and urgent; a page-level drop is usually competitive and not. They look identical in a summary chart, which is why the summary chart is the wrong place to look. Separating them is a single grouping operation on data you already have, and it changes what you do next completely.

How to tell them apart

Group your tracked keywords by URL, then count how many URLs moved.

Many URLs, similar magnitude, same day — sitewide. The shared cause is something that applies to the whole site: a server-level problem, a directive applied at site scope, a redirect or hosting change, a certificate or DNS event, a migration step.

One URL, most or all of its keywords — page-level. Something about that page or that URL specifically.

One keyword on one URL — query-level. Usually competitive, occasionally your own two pages fighting each other.

A cluster of URLs sharing a template or a directory — template-level, which behaves like a small sitewide event and has the same kind of causes at a smaller scope.

The counting matters more than the magnitude. Ten URLs each losing three places is a bigger deal than one URL losing thirty, because the ten have a shared cause and shared causes tend to keep going.

Sitewide: what to check, in order

Sitewide drops earn same-day attention because the plausible causes are the ones that get worse if ignored.

Availability. Is the site returning 200 to a crawler, from outside your network, right now. Not “does it load for me.”
Site-level directives. A noindex or a blanket disallow shipped by accident is the classic. It’s fast to check and catastrophic to miss.
Certificates and protocol. An expired certificate or a broken redirect between protocol variants takes the whole site down for crawlers while looking fine to a logged-in browser with a cached exception.
DNS and hosting changes. Anything that changed where the site resolves.
A migration in flight. Including one you weren’t told about.
Broad volatility affecting everyone. Check this before concluding it was you — what volatility trackers measure.

Note that most of these produce a cliff rather than a slide. A sitewide slide over weeks is more likely an accumulation of page-level problems than one big cause.

Page-level: what to check

Page-level drops are rarely urgent, but they’re where most of the actual work is.

Is it still the same URL. A slug change, a redirect, a canonical pointing elsewhere, a page moved into a new directory. This is the most common answer and the easiest to overlook because the page still exists.

Is it still indexed as the version you think it is.

Did the content change. Including edits nobody logged: a template change that removed a section, a plugin update, an image block that swallowed a heading.

Are you competing with yourself. Two of your own pages targeting one query produces a distinctive pattern — keyword cannibalisation looks like flapping.

Did something better get published. Look at the result page. If three of the four results above you are new, that’s your answer, and it’s a content decision rather than a bug.

Why the distinction changes your reporting

The two cases warrant genuinely different messages.

For a sitewide event: name it, give the scope, give the fix and the expected recovery shape. Recovery from a technical sitewide problem tends to follow recrawling, so it’s uneven and takes longer than the drop did. Say that in advance, so nobody reads day three as a failure.

For a page-level event: name the page, name what changed, and say whether it’s worth fixing. Not every page-level drop is worth work — a page losing positions on queries that were never valuable is a report line, not a project.

For a query-level event on a single keyword: usually nothing. Include it in the monthly, not in an alert.

Building the split into your tracking

This diagnosis is much faster if the tracked set is structured for it: keywords grouped by target URL, and URLs grouped by template or section. Most trackers support tagging, and this is the highest-value use of it.

A tracked set that’s just a flat list of keywords makes you do the grouping by hand every time you’re under pressure, which is exactly when you’ll skip it. The selection logic is covered in choosing which keywords to track.

What to actually do

Tag every tracked keyword with its target URL and section when you add it.
On any drop, count affected URLs first. That single number routes the investigation.
Escalate sitewide same-day; schedule page-level; log query-level.
Check availability and site-level directives from outside your own network.
Set recovery expectations by cause, since a technical fix recovers on a recrawl schedule and a content fix doesn’t recover on any schedule at all.