Rank tracking is priced per successful query, not per gigabyte. The formula, the volume math for 10,000 keywords, and when to buy a SERP API instead.
· 13 min read · Pricing and economics
Every article about proxies for SEO rank tracking ranks the vendors. None of them price the job. That is a strange omission, because rank tracking is one of the few proxy workloads where the volume is known in advance — keywords times locations times frequency — and where the cost per useful result, not the cost per gigabyte, decides which pool you should be buying.
This is the cost model. Formula first, then the three constraints that make rank tracking different from generic scraping, then the arithmetic for a real tracking program.
Three constraints, each with its own failure mode.
Location fidelity. A rank tracker's output is only meaningful if the SERP came from where you said it came from. Google's own documentation is explicit that IP address is the primary location signal: "the most important factor is your IP address," with GPS, Wi-Fi and cell tower data refining it on mobile devices (Google Search Help). Get the exit location wrong and you have not collected a bad ranking. You have collected a ranking for a market you were not asked about, and it will look exactly like a real one.
A consistent device and user-agent profile. Mobile and desktop SERPs are different result sets. So are the same SERPs with different declared viewports. If your tracker reports one number per keyword but your fleet drifts between profiles, your week-on-week deltas measure your own configuration noise.
No personalization carry-over. Every request has to look like a first visit. Google caches the location it last used for you in a cookie set to expire after six hours, per the same help page. Carry that cookie or that IP across queries and query two inherits query one's context.
That third constraint is the one that quietly sets the whole architecture, because it rules out the session model most scraping guides recommend.
Mechanism, not folklore.
A retail site sees a datacenter IP and mostly cares whether the request pattern looks like a bot. A search engine sees a datacenter IP and already knows something a retail site does not: almost no human searches from an AWS range. Search infrastructure has decades of query-log context on which address space issues consumer searches and which does not, and the SERP is also one of the most heavily automated targets on the internet, so the cost of a false positive against datacenter space is low for them and high for you.
Three practical consequences:
Do not accept a percentage here from anyone, including this page. No detection-rate figure comparing datacenter and residential exits on SERP pages is published by any auditable source, and the figures that circulate on social media arrive with no methodology attached. The mechanism above is real and the direction is not in doubt. The magnitude is a measurement, and the only measurement that binds your budget is the one your own keyword set produces — which the next section shows you how to take.
Here is the arithmetic the vendor listicles skip.
cost per successful query = (price per GB x GB per query) / success rate
Bandwidth is not what you are buying. Successful, correctly located SERPs are what you are buying, and a blocked query costs you the request, the interstitial's bytes and a retry.
Now use it to settle the tier question without needing a single measured success rate. Datacenter runs at $0.99/GB and residential at $1.99/GB (rates as of 2026-08-06, per-GB rates). Assume the page weight is roughly the same either way, because it is the same SERP. Residential is the cheaper purchase when:
1.99 / rate_residential < 0.99 / rate_datacenter
Which reduces to:
rate_residential / rate_datacenter > 2.01
Residential wins as soon as it succeeds slightly more than twice as often as datacenter on your target. That is the whole tier decision, in one ratio, and you can settle it in an afternoon by running 500 queries through each pool and counting. You never need anyone's published success rate — including any this site might quote — because the only number that matters is the one your own keyword set produces.
The same ratio governs the step up to mobile at $3.99/GB: mobile has to succeed about twice as often as residential to be worth it. On most SERP work it will not, which is why the honest recommendation is to test residential against datacenter and stop there.
Measure the success rate yourself, and define "success" strictly. A 200 response containing an interstitial is a failure. A SERP from the wrong city is a failure. Count only queries that produced parseable results from the requested location.
Requesting an exit in Chicago gets you an address that geolocation databases place in Chicago. It does not guarantee a Chicago SERP. Four things can intervene.
Verify rather than assume. Before a tracking run, sample the exits you are about to use and confirm what the target itself reports — most SERPs render a visible location string somewhere on the page or in a settings panel. Compare that string to the city you requested, on a sample of 30 exits per location, and record the agreement rate as a quality metric alongside your rankings. The full procedure, including what to do when the databases disagree, is under verifying the location you asked for.
City-level work has a second cost. Country selection and ASN exclusion are included in the base rate, but state, city, ZIP and ASN filters are advanced target filters and are billed at twice the standard rate — see country, city and ASN targeting. For a program tracking three cities per keyword, that doubles the per-GB line on every request, and it belongs in the model before you commit to a location count.
Rank tracking is the clearest case in proxy work where a held session actively harms the result.
Sticky sessions exist to preserve state across requests. Rank tracking exists to collect a result with no state at all. Every query after the first from a held address carries the previous query's cookies, the previous query's cached location and the previous query's volume against that address. All three degrade the data before they degrade the success rate.
So: a rotating port, a fresh exit per query, and a fresh cookie jar per query. The gateway selects the mode by port rather than by a request flag, so this is a configuration decision made once — see rotating and sticky session ports, and rotate per query for what each session model does to how a target reads you.
One exception. If a location's verification step requires a two-request sequence — set the location, then query — hold the exit across exactly those two requests and release it. That is a two-request sticky window, not a session.
Concurrency matters here too, because a rank tracking run is a burst: 900,000 queries do not spread themselves evenly across a month unless you make them. Size the pool against your concurrent connection limits before you schedule the job, not after it fails at 02:00.
Take a program tracking 10,000 keywords across 3 locations, daily.
10,000 x 3 x 30 = 900,000 queries per month
The second input requires your own measurement, because SERP page weight varies
by query type, device profile and how many rich elements the result set
carries, and no auditable published figure exists for it. Take it directly: sum
encodedDataLength over a cold browser load, or read size_download for a
document-only fetch, across 100 representative queries from your own keyword
set. An afternoon of work, and it is the input the whole model turns on.
Rather than assert a number, here is the sensitivity table. Find your measured page weight in the header row and read down. Gigabytes are decimal, 1 GB = 1,000,000 KB.
| Monthly queries | 100 KB/query | 250 KB/query | 500 KB/query | 1,000 KB/query |
|---|---|---|---|---|
| 300,000 (10K keywords, 1 location) | 30 GB | 75 GB | 150 GB | 300 GB |
| 900,000 (10K keywords, 3 locations) | 90 GB | 225 GB | 450 GB | 900 GB |
| 1,800,000 (10K keywords, 3 locations, 2 devices) | 180 GB | 450 GB | 900 GB | 1,800 GB |
Then divide by your measured success rate, because failed attempts are metered:
billable GB = table value / success rate
At 900,000 queries, 100 KB per query and a success rate of 0.8, that is 90 / 0.8 = 112.5 GB per month. At residential rates that is roughly $224. Double it if you are using city-level filters. What exactly lands inside those gigabytes is in what each query costs. The point of the model is not the answer; it is that you can compute the answer before you buy, and that the two inputs you are missing are both measurable in a day.
Screaming Frog. Proxy settings live under File > Settings > Proxy on
Windows and Linux, and under Screaming Frog SEO Spider > Settings > Proxy on
macOS. Tick "Use Proxy Server", enter host, port, username and password, and
restart — the setting does not take effect until you do. The SEO Spider accepts
a single proxy server and does not rotate between several, so point it at a
rotating gateway port and let the gateway do the rotation. See the
Screaming Frog SEO Spider FAQ
for the current path.
A custom tracker. One rotating endpoint, one fresh cookie jar per query, one location per worker pool. Keep the location assignment sticky to the worker, not to the exit: worker A always requests Chicago exits and always writes Chicago rows, so a mislabeled row is traceable to one pool rather than to the whole run.
Scrapy. Set the proxy per request in a downloader middleware, disable the
cookies middleware entirely for SERP requests, and cap
CONCURRENT_REQUESTS_PER_DOMAIN deliberately — the default will not be the
number your thread limit allows.
Whichever you use, log four fields per query: requested location, exit address, location the target reported, and outcome. Those four columns are what let you compute the success rate the cost model needs, and the geo agreement rate the data quality depends on.
Raw proxies are the wrong purchase for a lot of rank tracking programs, and saying so is the only thing that makes the rest of this article worth reading.
Buy a SERP API when:
Buy raw proxies when:
Cost them against each other with the same formula. A SERP API's price per result is directly comparable to your cost per successful query. If the API is cheaper and you do not need control of the request, the proxies are the wrong line item.
Not automatically. Run 500 queries from your actual keyword set through both a datacenter and a residential pool and count strict successes. Divide the two published per-GB rates to get your threshold: at current rates residential has to succeed about 2.01 times as often as datacenter to be the cheaper purchase. Many programs find it does on general web search and does not on less-defended surfaces, so test per target rather than per vendor claim.
Rotating, with a fresh exit and a fresh cookie jar per query. Rank tracking needs every request to look like a first visit, and a held session carries forward cookies, cached location and accumulated request volume from the previous query. Sticky sessions exist to preserve state; rank tracking exists to collect results with no state at all.
Multiply keywords by locations by frequency to get monthly queries, multiply by your measured page weight per query, then divide by your success rate because failures are metered too. Ten thousand keywords across three locations daily is 900,000 queries per month. At 100 KB per query and 80% success that is about 113 GB. Measure the page weight; it varies more than anything else in the model.
Compare what you requested against what the target reports. Most SERPs render a visible location string on the page or in a settings panel. Sample 30 exits per location before a run, record the agreement rate, and treat it as a data quality metric alongside your rankings. Geolocation database agreement is not evidence; only the target's own reported location is.
Yes. Country selection and ASN exclusion are included in the base rate. State, city, ZIP and ASN filters are advanced target filters billed at twice the standard per-GB rate. A program tracking three cities per keyword should model the doubled rate on every request from the outset, because it changes the tier comparison and can make a smaller location set the better purchase.
Two measurements: page weight per query, and strict success rate per pool. Two multiplications. The answer tells you which tier, how many locations you can afford and whether you should be buying proxies at all.
Start routing once the model says proxies win, and check the per-GB rates for the pool your test chose.