Rank Alerts That Don't Cry Wolf

Alert on things that can’t happen by accident. A threshold of “moved three or more places” fires on ordinary daily wander, which means it fires most days on most keywords, which means it gets muted — and a muted alert is worse than no alert, because now you believe you have coverage.

Good rank alerting is mostly about which shape of event you’re detecting, not about picking a better number.

Why places-moved is the wrong trigger

Three places is not a fixed amount of anything. Near the top of the first page it’s a substantial change in click share; in the forties it’s the ambient shuffle. One threshold applied across a whole tracked set therefore over-fires at depth and under-fires where it matters — the ordinal problem in position is an ordinal, not a quantity, in its most expensive form.

Percentage-based thresholds are worse. A percentage of an ordinal isn’t a quantity at all, and the same relative threshold means something completely different at position 2 and position 60.

Four triggers that work

Band crossings. Define bands — top three, top ten, top twenty, beyond — and alert when a keyword leaves one. Movement inside a band is ignored entirely. This matches how position actually relates to outcomes, and it silences the deep-page shuffle for free.

Breadth. Alert when the number of affected keywords crosses a threshold, not when any single one moves. “More than twenty percent of tracked keywords moved down today” is a strong signal and a rare one; a single keyword moving is neither. This is the alert that catches sitewide events, which are the only ones worth waking up for — sitewide drops versus page-level drops.

Persistence. Require the condition to hold for two or three consecutive checks. Most single-check drops revert, so a persistence requirement removes the majority of false positives at the cost of a day’s delay — which is almost always the right trade, since almost nothing here is fixable within a day anyway.

Disappearance. A keyword falling out of the tracked depth entirely is a qualitatively different event from moving down, and it’s usually technical. Alert on it separately and treat it seriously — when a keyword falls out of the top 100.

Per-keyword thresholds beat global ones

A single global threshold assumes every keyword has the same normal range, and they don’t. Some sit within a place or two for months; others swing ten places weekly because the query itself is unsettled.

If your tool supports per-keyword or per-group thresholds, set them from each keyword’s own observed range: alert when it moves outside where it’s been living. If it only supports one global threshold, split the tracked set into a stable group and a volatile group and apply different settings to each. Either way you need the observed range first — baselines before you read a position.

Suppress what you already know about

Alerts should be silent during events you caused. A migration, a deploy that changes URLs, a deliberate deindexing — all of these will fire everything, and the noise buries anything unexpected happening at the same time.

Two mechanisms:

• A maintenance window on the alerting itself, with an end date so it doesn’t become permanent.
• A separate watchlist for whatever you’re actively changing, with its own tighter settings, while the main set stays quiet.

Also suppress during broad volatility. If everything is moving for everybody, per-keyword alerts are describing the weather — what volatility trackers measure.

An alert needs a defined action

The test for whether an alert should exist: name what you will do when it fires. If the answer is “look at it”, it isn’t an alert, it’s a report, and it belongs in the weekly.

Alerts worth having have concrete responses. Breadth alert: check availability and site-level directives. Disappearance alert: check the URL’s index state. Top-three exit on a commercial term: look at the result page and see who arrived.

Anything without a named response should be deleted, not tuned. Most alerting problems are solved by having fewer alerts.

What to actually do

1. Replace places-moved thresholds with band crossings.
2. Add one breadth alert across the whole tracked set — this is the one that catches real emergencies.
3. Require two consecutive checks before firing anything.
4. Alert separately on disappearance, with a different, higher urgency.
5. Write the response next to each alert. No named response, no alert.
6. Suppress during your own migrations, with an end date on the suppression.