A bulk rank checker promises one thing: many keywords, one report. What the report contains depends almost entirely on a setting most people never change, which is how deep the check goes.
We ran the same 50 keywords twice, back to back, on September 12, 2026, against the same search engine, location, and device. The only difference was depth.
At depth 10, the check found our domain on 1 of the 50 keywords. At depth 100, it found our domain on 22 of them.
Same keywords. Same hour. Same API. The difference is not accuracy, because both runs were accurate. It is field of view, and it changes the headline number by a factor of 22.
What we ran
Fifty keywords drawn from our own Search Console query list, filtered to Latin-script queries so the United States, English result set would match. Both runs used live Google organic requests at desktop resolution, eight concurrent workers, and a 300 second timeout per request.
Setting | Run A | Run B |
|---|---|---|
Keywords | 50 | 50 |
Depth requested | 10 | 100 |
Location and language | United States, English | United States, English |
Device | Desktop | Desktop |
Concurrency | 8 | 8 |
We recorded per-request latency, billed cost, organic result count, and whether our domain appeared.
Result 1: the same keywords, two different answers
Measure | Depth 10 | Depth 100 |
|---|---|---|
Keywords checked | 50 | 50 |
Requests that returned a usable result | 50 | 43 |
Requests that failed | 0 | 7 |
Keywords where our domain appeared | 1 | 22 |
Within the top 3 | 1 | 1 |
Within the top 20 | 1 | 1 |
Within the top 100 | 1 | 20 |
The keyword set did not change between the runs. Only the depth setting did.
Read that carefully, because the shape of it is the whole lesson. At depth 10, our visibility on this keyword set looked like 2 percent. At depth 100 it looked like 44 percent. Neither number is wrong, and only one of them is useful.
The top-of-page picture barely moved. One keyword sat inside the top 10 in both runs. Everything the deeper check added was between position 20 and position 100, which is exactly the range that a default bulk checker hides. If your plan is built on a rank checker set to the first page, your baseline is not a measurement of your visibility. It is a measurement of your visibility within the first page, and on this keyword set those differ by 21 keywords.
A small extra detail: two of the 22 keywords found in the deep run sat beyond absolute position 100. The API returns a little past the requested depth, so a "top 100" report can contain positions above 100. Filter them if the label matters to you.
Result 2: cost scales with depth, roughly seven to one
Measure | Depth 10 | Depth 100 |
|---|---|---|
Total billed cost | $0.1000 | $0.6230 |
Cost per keyword | $0.0020 | $0.0125 |
Organic results returned per keyword | about 12 | about 97 |
The depth 100 run cost 6.2 times the depth 10 run for the same 50 keywords, and the difference bought the 21 additional keywords where our domain showed up.
That ratio is the honest answer to the most common bulk-checker question, which is whether it is worth paying for more results. It is worth paying for if you rank past the first page. If your keywords sit in the top 10, the deeper run mostly returns rows you will never read.
There is a middle setting, and it is usually the right one. Depth 20 costs $0.0035 per keyword in our earlier pricing, which is 75 percent more than depth 10 and still a 75 percent discount against depth 100. For a site in the position 20 to 50 band, depth 20 captures most of the useful movement at a fraction of the cost.
The billed cost was also lower than the per-keyword price predicted, because the seven failed requests were not charged. That is the failure rate showing up in the invoice, which brings us to it shortly.
Result 3: the report also hides whether an AI Overview was there
Depth is not the only thing a position-only report leaves out.
We recorded SERP element types on every request in both runs. On the depth 10 run, 48 of the 50 queries returned an AI Overview. On the depth 100 run, 42 of the 43 successful requests did.
Run | Queries with an AI Overview | Queries checked |
|---|---|---|
Depth 10 | 48 | 50 |
Depth 100 | 42 | 43 successful |
That number will look wrong to anyone who read our earlier snapshot, which found AI Overviews on 4 of 40 SEO-topic queries. Both are correct, and the difference is the query set rather than the method.
The 40-query set was an SEO-topic list: ranking tools, audits, algorithm updates, and 15 queries naming a tool or API. This 50-query set came from our own Search Console query list, which is dominated by long-tail utility and comparison phrasing. The queries a site actually gets impressions for are a different shape from the queries an SEO team writes down, and AI Overview presence follows the shape.
The practical point for bulk checking is narrower and more annoying. A bulk rank checker returns positions. It does not return the element that now sits above position 1, and on the query set we actually own, that element was present on 96 percent of them.
Result 4: the time is latency divided by concurrency
A bulk check is not instant, and the reason is request latency rather than any processing you control.
Measure | Depth 10 | Depth 100 |
|---|---|---|
Wall clock at 8 workers | 62.0 seconds | 135.9 seconds |
Fastest request | 2.6 seconds | 8.1 seconds |
Median request | 8.3 seconds | 19.2 seconds |
Slowest request | 22.0 seconds | 40.3 seconds |
Sum of all request times | 451 seconds | 998 seconds |
Two things fall out of this.
Median latency more than doubled with depth, from 8.3 to 19.2 seconds. A deeper search is genuinely slower to assemble, which is why a bulk checker with a short client timeout fails on deep runs and not on shallow ones.
The wall clock is set by concurrency, not by the API's speed. Run the 50 keywords one at a time and the depth 10 check takes about 7.5 minutes; at eight workers it takes one. If your bulk checker has no concurrency control, that is the single setting worth asking about, because it is worth a factor of eight in elapsed time at no cost difference.
Result 5: the deeper run failed 14 percent of the time
Seven of the 50 depth 100 requests failed. None of the depth 10 requests did.
Run | Failures | Failure rate |
|---|---|---|
Depth 10 | 0 of 50 | 0 percent |
Depth 100 | 7 of 50 | 14 percent |
Because the failed requests were not billed, the depth 100 run also cost less than the $0.70 the per-keyword price predicted, which is why the effective cost per keyword came in at $0.0125 rather than $0.014.
This is the part of bulk checking that reports rarely show. A tool that retries silently will paper over it. A tool that does not will quietly under-report your rankings, and the failures cluster on the slowest requests, which are the deep ones you paid extra for.
The error message was identical on all seven: the task completed with partial results, some pages could not be retrieved after several retry attempts, and the pages that were not returned were not charged. That is the right behaviour from a provider, and it is also why a bulk check under-reports instead of crashing. A failed page is not a keyword where you do not rank. It is an unknown, and a report that renders it as a blank cell has quietly converted an unknown into a negative.
If you build your own loop, log failures as a first-class outcome rather than dropping them, and retry the failures once before reporting.
Deeper requests take longer, and the failures cluster at the slow end of the distribution.
What this means for the number on your dashboard
The same 50 keywords produced two defensible visibility figures, 2 percent and 44 percent, separated only by a depth setting. That is a larger swing than most ranking changes you will spend a quarter trying to explain.
Three rules follow.
Set depth from where you rank, not from what the tool defaults to. Pull your own position distribution first. If most of your keywords sit between 20 and 60, depth 10 will report almost nothing and you will conclude you have a visibility problem you do not have.
Report the depth alongside the number. A ranking report without a depth setting is not reproducible. Same for location, language, and device.
Treat "not found" as data, not as an error. Twenty-eight of the 50 keywords returned no result for our domain at depth 100, and that is the honest answer. A checker that hides those rows is shortening your keyword list in the least useful direction.
Check whether the report includes SERP features at all. On this keyword set an AI Overview was present on 96 percent of queries. A position-only export cannot show you that, and no depth setting will add it.
If the goal is a number you can defend over time, the depth question sits underneath the reporting question. Our notes on how far down Google actually serves results cover where the ceiling is, running both a first-party and a live source covers the setup that keeps you honest about it, and what Search Console can tell you that a live check cannot covers the half of the picture this run never touched.
Limits
Two limits worth stating.
Fifty keywords from one property is a small sample, and the 2 percent versus 44 percent split is specific to a site whose keywords sit deep. A property ranking in the top 10 for most of its list would see almost no difference between the two runs, and would be overpaying for depth.
Latency depends on the provider, the location, and the moment. The absolute seconds here will not transfer, but the ratio between the two depths should hold roughly, because the difference is real work rather than network variance.
FAQ
What depth should a bulk rank checker use? Set it from your own position distribution. Depth 10 is enough if you rank in the top 10. Depth 20 covers most of the practical range at $0.0035 per keyword. Depth 100 costs $0.014 and is only worth it when you genuinely track positions past 50.
How long does it take to check 50 keywords? About one minute at eight concurrent workers for a shallow check, and about 2.3 minutes for a deep one. Run serially, the same checks take 7.5 and 16.6 minutes, so concurrency is worth a factor of eight in elapsed time.
Why did the deeper check fail more often? Deeper requests take longer to assemble, with a median of 19.2 seconds against 8.3 for the shallow run, so they are more likely to hit a client or provider timeout. Log and retry failures rather than dropping them.
Is a bulk rank checker accurate if it says my keyword is not found? Usually yes. In our run, 28 of 50 keywords genuinely had no result for our domain within 100 positions. Check the depth setting before you treat a missing row as a data problem.
Does checking more keywords cost more than checking deeper? Depth moves the bill more per keyword, but keywords multiply the total. Going from 50 to 500 keywords at depth 10 costs ten times as much and takes ten times as long, while depth 100 costs 7 times as much per keyword. Price the depth you need, then buy the keyword count you can review.
Auspia view: before changing a single page, check your bulk checker's depth setting. It is the cheapest explanation for a surprising visibility number, and in our test it accounted for a factor of 22 between two runs made minutes apart. Set depth from your position distribution, log failures, and keep the setting in the report so next quarter's number is comparable.
Author: Bennett Hayes, Applied GEO Analyst Across 400+ Implementation Reviews at Auspia. Bennett writes about practical search execution, measurement, and the details that change a report.
