A Cached Result Page Is Not a Fresh Check

Somewhere between Google and your dashboard there is a cache, and when it hits, nobody fetched anything. The row still appears. It still carries today’s date. It just describes a result page that was retrieved at some earlier point, and nothing in a standard tracker interface distinguishes that row from one fetched thirty seconds ago.

This isn’t an accusation of bad faith. It’s a structural feature of how the retrieval layer is priced, and it’s worth being able to recognise.

Why the cache is there

Retrieval is metered per request, and cache hits are explicitly outside the meter. Serply’s credit definition on its pricing page states that one credit equals one successful uncached API request, and that cached responses cost nothing. That’s one vendor’s published model rather than a universal standard, but it makes the incentive structure legible: on a per-request billing model, a cache hit is free to whoever is buying, and a fresh fetch is not.

Stack that up. Popular keywords get queried by many customers. A generic commercial term in a common location is very likely being checked by several accounts on the same platform within the same window. Serving one retrieval to all of them is the obvious engineering answer, and it’s also the cheap one.

So the question for any tracker is not whether there’s a cache — there almost certainly is, at some layer — but what its lifetime is, and whether the tool tells you when you got a hit.

What a cache hit looks like in your data

There’s no flag, so you’re reading symptoms.

A flat line on a keyword that shouldn’t be flat. Head terms in competitive verticals move. A commercial keyword sitting on exactly the same integer for eleven straight days, while everything near it in the same set jitters, is worth a second look — see why do Google rankings change every day for why perfect stability is the anomaly, not the baseline.

Identical SERP snapshots. If your tool stores the result page it parsed, compare two consecutive days on a keyword. Genuinely re-fetched pages differ in small ways almost every time — a sitelink, an ad, a snippet rewrite. A byte-for-byte match across days is a stronger signal than a matching position.

Feature blocks that never update. Result-page features churn faster than organic positions. An AI overview or a local pack that hasn’t changed shape in weeks, on a query where the organic ordering has moved, suggests you’re reading a stored page rather than a current one.

Movement that arrives in a batch. Cached data goes stale together. If several keywords sit still for days and then all jump on the same run, that’s more consistent with a cache expiring than with a ranking event affecting exactly those keywords.

This is not the same problem as a gap

Worth separating, because the symptom looks similar. A gap is a check that didn’t happen and got papered over — a flat line in rank history might be a gap covers what carry-forward and interpolation do to a series. A cache hit is a check that did happen, at some earlier moment, and returned real data.

The difference matters for what you can conclude. Carried-forward data is invented; cached data is genuine but misdated. Both corrupt a baseline, but only one of them was ever a real observation, and only one of them can be fixed by asking about a lifetime rather than a failure rate.

What to actually do

1. Ask your vendor two questions in writing: is there a cache in the retrieval path, and what is its lifetime? A specific answer in hours is a good sign. “We always fetch fresh data” on a keyword-count-unlimited plan deserves a follow-up.
2. Sanity-check with a keyword you know to be volatile. If a term that visibly churns in a manual search reads as perfectly stable in your tool for a week, the tool isn’t measuring stability.
3. Don’t report a flat week as stability without checking whether it’s a flat week of observations or a flat week of the same observation.
4. If your tool stores parsed result pages, diff them across days occasionally. It’s the cheapest test available and it needs no vendor cooperation.
5. When you genuinely need a fresh reading — the morning after a fix went live, say — use whatever manual-refresh path is capped and rationed rather than the scheduled run. Rationing is the sign that a real fetch is being spent on you.