How Long Does One Rank Check Actually Take?

The retrieval takes well under a second. Everything you actually wait for is a queue. People assume a rank refresh is slow because fetching a result page is slow. It isn’t. Fetching one page for one keyword is one of the faster things in your whole stack. The hours between pressing refresh and seeing new numbers are scheduling, rationing and retries — not network time.

That distinction matters because it changes what a timestamp on a row means.

The two clocks

A position check runs on a fast clock and a slow one.

The fast clock is the retrieval itself: issue one request for one keyword, one location, one device; get a result page back; parse it. Vendors who sell that retrieval compete on this number and publish it — Serply’s Google search endpoint’s published latency is advertised as an average under 300 ms. That’s one vendor’s figure for its own service rather than a measured market average, but it establishes the order of magnitude: a single fetch is a sub-second operation.

The slow clock is your tracker’s refresh run — every keyword in your set, times every location, times every device, scheduled against a fixed amount of concurrency that is shared with every other account on the platform.

Do the naive arithmetic and the slow clock shouldn’t exist. Two thousand keyword-location-device combinations at a third of a second each is about eleven minutes run one at a time, and seconds if run wide. Refreshes routinely take hours anyway.

Where the hours go

Concurrency is rationed upstream. Your tracker doesn’t own an unlimited pool of retrieval capacity; as covered in where a rank tracker’s data comes from, most of them buy it. What they buy is a share of somebody else’s throughput, and that share is split across their entire customer base.

The set is bigger than the keyword count suggests. A hundred keywords across five cities on two devices is a thousand fetches, not a hundred. Location and device are multipliers, not settings — that’s the whole argument in mobile and desktop are two rank sets.

Failures get re-queued. A fetch that comes back empty, blocked or malformed has to be tried again, usually with a backoff delay. A run isn’t finished when every request has been made; it’s finished when every request has succeeded or been given up on.

Runs are smoothed deliberately. A vendor that fired every customer’s refresh at midnight would need peak capacity it only uses once a day. So accounts get staggered slots, and your slot may be nowhere near the time you think of as your refresh time.

The timestamp is the write time, not the sample time

This is the practical consequence. On most tools, the date attached to a row is when the run was recorded, not when that specific keyword was fetched. Two keywords stamped with the same date can have been sampled hours apart, at different points in a day’s volatility.

Which means intraday comparisons inside your own tool are mostly meaningless, and cross-tool comparisons on “the same day” are comparing two samples that may be most of a day apart — one more entry in the list of reasons two rank trackers report different positions.

If you need to know when a keyword was actually checked, the field you want is a per-keyword fetch time, and plenty of tools don’t expose one. Its absence is worth knowing about before you build a report on hour-level reasoning.

What “refresh now” is really doing

On-demand refresh buttons do one of two things, and they look identical.

Some issue a genuine out-of-band fetch, jumping your keyword to the front of the queue. That costs the vendor a real retrieval, which is why these are almost always capped — a manual-refresh allowance per day is the tell that a real fetch is happening.

Some just re-render the page from data already stored. Nothing is fetched, and the number can’t change. Uncapped, instant “refresh” is usually this one.

Neither is dishonest, but only the first answers the question “has this moved since this morning.”

What to actually do

1. Stop treating a shared date stamp as a shared sample moment. If two keywords moved on the same date, that’s not evidence they moved together.
2. Find out whether your tool records per-keyword fetch times, and if it does, use that field rather than the run date for anything time-sensitive.
3. Check whether your manual refresh is capped. Capped means real; uncapped and instant means you’re re-reading stored data.
4. When a refresh feels slow, ask about queue position rather than assuming the retrieval is the bottleneck. The fetch is not what you’re waiting for, and negotiating over speed is really negotiating over priority.
5. Size your tracked set with the multipliers included. The number that determines your run length is keywords times locations times devices, and most people quote themselves the first number only.