Where a Rank Tracker's Data Comes From

Somebody has to fetch a result page for every keyword, location and device you track, every time you check. There is no official interface that returns organic positions for arbitrary keywords, and automated querying of Google’s search results is against Google’s terms of service. Every tracker in the market is built on top of that awkward fact, usually by buying the retrieval from a specialist data provider.

Worth knowing not as gossip but because it explains the category’s quirks: the pricing, the location limits, the delays, and the gaps.

What the constraint produces

Cost scales with checks. Retrieval is the marginal cost, and it multiplies: keywords times locations times devices times frequency. This is why every pricing page in the category is built around that product, and why free tiers cut frequency and locations first — free keyword rank checkers: what you’re actually giving up.

Locations are a finite list, not a coordinate space. Fine-grained location support costs more to operate, so most tools expose a curated set. It’s the underlying reason local tracking is priced differently and why grid tracking is a premium feature — a city is not a location.

Checks are queued, not instantaneous. Your daily check happens when your keywords come up in a queue, which is why the time of day isn’t yours to choose on most tools, and why two tools checking “daily” sampled different moments.

Failures happen and are handled invisibly. Retrieval sometimes fails. What the tool does then — retry, skip, report null, or carry yesterday’s value forward — is rarely documented and materially changes your data, which is why a flat stretch in a series deserves suspicion: when a keyword falls out of the top 100.

Depth costs extra. Checking a hundred results costs more than checking twenty, so tools cap depth, and “not found” often means “not in the shallow window we paid for.”

The database alternative

Not every position number comes from a fresh retrieval. Large keyword tools maintain their own crawl of result pages across millions of terms, and can return a position for a keyword from that index without fetching anything.

That’s a legitimate and useful technique with one important property: the number is as old as the crawl. It may be days stale, and it cannot tell you that a shopping block appeared this morning. Both approaches answer real questions; only the fresh retrieval answers “what does this page look like now.”

The tell is response time. Instant answers across many keywords indicate a lookup. A few seconds per keyword indicates a fetch. Neither is dishonest, and neither should be presented to a client as the other.

What this means for how much you trust it

Three practical positions follow.

Treat position data as a sample, not a reading. It’s one retrieval, from one place, at one moment, through infrastructure you can’t inspect. It’s reproducible enough to trend and not precise enough to argue over a single number.

Expect gaps and don’t over-interpret them. A missing day is an infrastructure event. It is not a ranking event, and a tool that hides the difference is doing you no favours.

Consistency is the property to buy. Since you can’t verify accuracy from outside, the useful thing to ask of a tracker is that it behaves the same way every day — which is the argument in why two rank trackers disagree.

The official data you do have

Search Console is a first-party interface, provided deliberately, with no terms problem and no retrieval cost. It reports impressions, clicks and average position for queries that actually generated impressions. Its limits are well known — it lags a couple of days, omits low-volume queries, and can’t tell you about terms you don’t rank for.

Which is exactly the complementary shape: the official data covers what happened, and the tracker covers what you want to observe deliberately. Neither replaces the other, and knowing which one has a terms-of-service question attached is part of knowing what each is for — rank tracker vs. Search Console.

What to actually do

1. Ask your vendor what happens on a failed check. Whether they retry, null, or carry forward is the single most useful thing to know about their data.
2. Find out your configured search depth, so you know what “not found” means.
3. Treat first-party Search Console data as the record for anything that actually happened.
4. Don’t argue over individual position numbers. Argue over trends, which survive all of the above.
5. Be honest about provenance when a client asks where the number came from. “An automated check of the result page from a set location” is accurate and nobody minds hearing it.