A Google ranking monitor is usually configured the same way: pick a threshold, alert when a position moves more than that, ship it. The default threshold in most tools is somewhere around three positions, because three sounds like a meaningful move.
In our own data it is not. Across 106 queries with at least 30 impressions over 90 days, the median query has a position standard deviation of 7.45. On a typical query, a three position change is not a signal. It is the everyday behaviour of the number.
The monitor is not broken. It is uncalibrated. This is what the calibration looks like when it is done from your own history rather than from a default.
What a monitor assumes, and which assumptions fail
Four assumptions sit behind every alerting rule, and only one of them holds.
Positions are stable enough that a threshold works. Fails. The spread differs per query by an order of magnitude, which we measured below.
A move of the same size means the same thing at every position. Fails. The distance between position 3 and position 6 is not equivalent to the distance between position 41 and position 44, in clicks or in meaning.
Every query deserves the same threshold. Fails. A branded query and a competitive head term have nothing in common statistically.
More frequent checks produce better information. Fails past a point. Checking daily gives seven times as many readings as weekly and, on most query sets, seven times as much noise around the same signal.
The rest of this article replaces each of those with a measurement.
What our own queries actually do
Method: our Search Console property, 90 days ending September 12, 2026, dimensions query and date, 8,020 rows, filtered to the 106 queries with at least 30 impressions over the window. For each query we calculated the standard deviation of its daily average position, and the share of days it stayed within three positions of its own median.
Measure | Value |
|---|---|
Queries in the sample | 106 |
Median standard deviation of daily position | 7.45 positions |
Queries with a standard deviation under 2 positions | 12 of 106 (11%) |
Queries with a standard deviation of 10 or more | 40 of 106 (38%) |
Median share of days within 3 positions of the query's own median | 59% |
Four queries from the same sample show how differently the same site behaves, query by query.
Query | Median position | Standard deviation | Days within 3 of median |
|---|---|---|---|
amazon echo keywords | 14.1 | 1.29 | 100% |
on page seo audit | 92.2 | 4.99 | 63% |
perplexity seo checker | 31.9 | 12.87 | 22% |
geo | 70.4 | 9.83 | 30% |
The practical reading: only about one query in ten is stable enough for a fixed three position rule to mean anything. Roughly four in ten move so much that a threshold below ten positions would fire constantly.
Most queries move far more than the default alert threshold assumes.
Calibration rule 1: build bands per query, not per site
A site-wide threshold is an average of behaviours that do not resemble each other. The fix is to compute the band for each query from its own history, which takes one Search Console pull and a few lines of arithmetic.
For each query, use its own distribution rather than a global number:
- Normal: within one standard deviation of the query's own median.
- Watch: between one and two standard deviations, or the query leaves its own middle 80% band.
- Investigate: beyond two standard deviations, confirmed on a second consecutive run.
On the sample above, that changes the alert volume dramatically. A query with a standard deviation of 1.29 needs a move of roughly three positions to reach the watch band. A query with a standard deviation of 12.87 needs a move of about thirteen, and it will produce almost no alerts at all until something real happens.
This is the same logic the alert band design guide uses for scheduled monitoring, applied per query instead of per account. If you only change one thing after reading this, change the threshold from a constant to a per-query value.
Calibration rule 2: require a minimum impression floor
A position is an average, and an average over three impressions is not a measurement. Below roughly 30 impressions over the window, the number moves on its own because the underlying sample is tiny.
Two consequences follow, and both are easy to implement.
Do not alert on low-impression queries at all. Monitor them, but treat the position as context rather than a signal. The exception is a query that suddenly gains volume, because that is an impressions event and worth knowing about on its own.
Pair every position with its impressions. A five position drop with stable impressions means something different from a five position drop that arrives with a 60% loss of impressions. The second is closer to an indexing or eligibility problem, and the first is closer to competition. A monitor that reports only position throws that distinction away, which is the failure mode this triage order exists to catch.
Calibration rule 3: split device and location before you alert
A blended position is a weighted average of device and location specific results. When the mix changes, the average moves without anything happening to your pages. We measured up to 11 positions of difference on the same query between mobile and desktop, so this is not a rounding error; it is the same order of magnitude as the noise you are trying to detect.
The implementation is unglamorous and cheap: pull positions per device, store both, and alert on the device where the movement happened. If you track one blended number, write the device mix into the output so that a mix shift is visible rather than inferred. Our device split walkthrough covers the query shape.
Five columns turn an alert into an investigation with a starting point.
What to monitor instead of position alone
Position is one column. Four others decide whether a move is worth a person's attention.
Impressions. The demand side. Movement here changes the meaning of every position number.
SERP feature state. Whether an AI Overview, video block, or local pack is present on that query. Feature changes move positions without any change to your page.
Click curve position. Where you sit relative to the features, not just where you sit in the list. Position 1 below an AI Overview is not position 1. If you want to track feature state properly, the AI Overview tracker build covers the field to store.
Change log entries. Your own deploys, template changes, and content edits, on the same timeline. Most real drops we have investigated had a commit behind them.
Store all five per query per day and an alert becomes an investigation with a starting point, rather than a number that looks alarming and a person who has to reconstruct the week from memory.
Cadence maths before you commit
Monitoring cost scales with keywords multiplied by checks, so decide the cadence from the query count rather than from ambition.
- 30 money queries checked daily is 900 requests per month. This is affordable on almost any plan and is where most teams should start.
- 200 queries checked daily is 6,000 requests per month, and on a volatile set it generates a large share of its alerts from noise.
- The same 200 queries checked weekly is roughly 1,400 requests per month and catches most real movement, because real movement persists for more than a week.
If you need both, split by stakes rather than by preference: daily for the short list tied to revenue, weekly for everything else. If you build the pull yourself, the two-source tracker covers the request pattern and the comparison rule.
The checklist before you trust any monitor
Five questions, and a monitor that fails any of them will cost more attention than it saves.
- Does it store raw results, or only the computed position? If you cannot later ask what else was on the page, you cannot explain an alert.
- Are location and device fixed per query and recorded? If not, your history mixes conditions.
- Is the threshold per query, or a single account-wide number? A single number is a default, not a calibration.
- Does it distinguish an incident from a drop? Google publishes a status dashboard with an incident history, and checking it first is cheaper than any investigation.
- Does it tell you what changed, or only that something changed? The second kind of alert is a to-do item; the first is a decision.
Auspia view: a ranking monitor is only as good as its calibration. The default three position threshold is not wrong because tools are lazy; it is wrong because it is a population average applied to individual queries. Measure your own queries, set bands from their own distributions, and the alerts you keep will be the ones you act on.
FAQ
What is a normal position change for a Google ranking monitor to ignore? There is no universal number, and that is the point. In our sample, the median query swung 7.45 positions across 90 days, while one in ten queries stayed within a two position spread. The right threshold is the one derived from each query's own history, usually one standard deviation.
How often should a ranking monitor check positions? Weekly for a normal set, daily for a short list tied to revenue. Daily checks on a large set multiply cost and mostly capture noise, since real ranking movements persist for longer than a day.
Why does my monitor show daily movement that Search Console does not? They are different measurements. A monitor takes one snapshot of a live result page at a point in time and location. Search Console averages impressions over a date range and a device mix. Neither is wrong, and comparing them directly is how teams end up chasing drops that only exist in one of them.
Should I monitor every keyword I rank for? No. Monitor the queries with enough impressions to be measurable, which in our data was 106 out of thousands. Everything below the impression floor is better tracked as a group, for example by counting how many queries rank at all, rather than as individual alerts.
Do I need a paid tool to calibrate a monitor? No. One Search Console export with query and date dimensions is enough to compute per-query medians and standard deviations, which is all the calibration needs. Paid tools add convenience and cross-vendor data, not the statistics.
Author: Miles Carter, Ranking Data Analyst Across 8,000 Tracked Queries at Auspia. Miles writes about ranking measurement, alert calibration, and how to tell a change in the data from a change in the search results.
