Mobile proxies for SERP and rank tracking
Search results are assembled per request from country, device class, and whatever the engine infers about the client. A rank measured from a cloud IP in another country is not a noisy version of the real ranking — it is a different question being answered. If you report mobile rankings for a local market, the measurement has to come from a mobile IP in that market.
The problem: you are measuring a SERP nobody sees
Two distortions compound. First, geography: search engines localise results heavily, so a query run from the wrong country returns a ranking no user in your target market experiences. Second, device class: the mobile index and the desktop index genuinely differ, and since most commercial search traffic is mobile, a desktop-shaped measurement misstates the rankings that actually drive your revenue. On top of both, sustained automated querying from datacentre ranges attracts interstitials and captchas, which turns a rank tracker into a captcha-solving budget.
You will recognise this if
- Reported ranks that do not match what clients see on their phones.
- Captcha and "unusual traffic" interstitials that grow as your keyword set grows.
- Local-pack and map results missing entirely from your captures.
- Rankings that shift when you change hosting provider — a sure sign you are measuring your infrastructure, not the index.
- Desktop and mobile ranks reported as identical, which is almost never true.
Working code
Every block below runs as written once PROXY_URL holds a real connection string. Copy yours from the dashboard after your first top-up.
Set the connection URL
bashexport PROXY_URL="http://USERNAME-mbl-gb-sid-serp01-rot-auto10:[email protected]:7000"
# Country token = the market you report rankings for.
# Vary -sid- across workers so queries spread over many devices.Python — a paced rank check on the mobile index
pythonimport os, time, random, urllib.parse
import requests
PROXY = os.environ["PROXY_URL"]
MOBILE_UA = (
"Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"
)
def serp(query: str, gl: str = "gb", hl: str = "en") -> str:
params = urllib.parse.urlencode({"q": query, "gl": gl, "hl": hl, "num": 20})
r = requests.get(
f"https://www.google.com/search?{params}",
headers={"User-Agent": MOBILE_UA, "Accept-Language": f"{hl},en;q=0.8"},
proxies={"http": PROXY, "https": PROXY},
timeout=45,
)
# An interstitial is not a ranking. Fail loudly instead of parsing it.
if r.status_code == 429 or "/sorry/" in r.url:
raise RuntimeError("rate limited — slow down and let the IP rotate")
r.raise_for_status()
return r.text
for kw in ["mobile proxy", "4g proxy uk", "rotating proxy api"]:
html = serp(kw)
print(f"{len(html):>7} bytes {kw}")
time.sleep(random.uniform(8, 20)) # realistic human cadenceThe pacing is not decoration. A rank tracker that queries faster than a person can type is the one that gets throttled.
Spread a keyword set across sessions
pythonimport os, re
def proxy_for_worker(worker_id: int) -> str:
"""Give each worker its own device by rewriting the -sid- token."""
base = os.environ["PROXY_URL"]
return re.sub(r"-sid-[a-z0-9_]+", f"-sid-serp{worker_id:02d}", base)
# 4 workers, 4 devices, each pacing itself independently.
for w in range(4):
print(proxy_for_worker(w))Distinct sids mean distinct devices, so four slow workers beat one fast one.
Which rotation mode to use
-rot-auto10Rank tracking wants many independent queries and keeps no state between them, which is exactly what timed rotation is for. auto10 hands you a fresh carrier IP roughly every ten minutes so a long keyword run is spread across many exits rather than concentrated on one. The rotation is not a licence to go fast, though: pair it with genuine pacing of several seconds between queries and split the keyword set across several -sid- values so the load is shared across devices instead of stacked on one.
When to choose something else
| Mode | Use it when |
|---|---|
| auto30 | Daily or weekly tracking of a modest keyword set, where a slower churn is more than enough. |
| sticky | Rarely useful here. Only if you are deliberately measuring how results evolve for one persistent client. |
| hard | Not recommended for SERP work — pinning one device concentrates all your query volume on a single IP. |
Expected bandwidth use
SERP tracking is one of the cheapest workloads on the pool, provided you fetch the results HTML rather than rendering the page. Rank data lives in the markup.
| Workload | Per unit | Per GB |
|---|---|---|
| Search results page, HTML only | 250–450 KB | ~2,300–4,200 queries |
| Results page with local pack / rich results | 400–700 KB | ~1,500–2,600 queries |
| Full browser render of a SERP | 2–4 MB | ~260–520 queries |
| Cached-result revalidation (conditional GET) | ~1 KB | effectively free |
A thousand keywords tracked daily on HTML-only fetches is roughly 8–13 GB a month — worth modelling before you commit, because it is usually cheaper than a per-query rank-tracking API at that volume. Track daily rather than hourly unless you genuinely act on intraday movement; most ranking decisions are made on weekly trends, and the extra frequency is bandwidth you spend for noise.
| Bandwidth | Price | Per GB | Save |
|---|---|---|---|
| 1 GB | $7 | $7 | — |
| 5 GB | $35 | $7 | — |
| 10 GB | $68 | $6.80 | 3% |
| 25 GB | $150 | $6 | 14% |
| 50 GB | $283 | $5.66 | 19% |
| 100 GB | $500 | $5 | 29% |
Relevant countries
Change country by editing one token in the proxy username — no redeploy, no second account. Pool depth varies by country and by whether you use the mobile (mbl) or residential (peer) pool; live availability is shown on each country page and in your dashboard.
Legitimate use only
ProxyMobile is sold for measurement, quality assurance and research on systems you own or are authorised to test. Buying bandwidth does not grant permission to access a third party's systems. You remain responsible for complying with each target's terms of service, robots directives and rate limits, and with the data-protection law that applies to you.
For this use case
- Track rankings for properties you own or that a client has engaged you to report on.
- Honour each search engine's terms of service and rate expectations — several publish an API for exactly this purpose, and it is often the right tool.
- Pace your queries to a human cadence. Volume that degrades a service for its users is not something bandwidth entitles you to.
- Do not collect or store personal data that appears incidentally in results.
Never, on any plan
- No credential stuffing, account takeover, or any attempt to authenticate as someone else.
- No circumventing an access control, paywall or security measure you have not been authorised to test.
- No collection of personal data you have no lawful basis to process.
- No load that a reasonable operator would experience as a denial of service — throttle, back off on 429s, and honour Retry-After.
Accounts used for fraud, intrusion or bulk abuse are terminated without refund, and we cooperate with valid legal process. Full terms are in our acceptable use policy.
SERP tracking FAQ
Why do mobile proxies matter for rank tracking specifically?
Because the mobile index differs from the desktop one, and most commercial search traffic is mobile. Measuring from a desktop-shaped datacentre connection reports a ranking that does not correspond to where your revenue actually comes from.
Will this stop captchas entirely?
No, and you should be sceptical of anyone who says otherwise. Carrier IPs materially reduce interstitial rates compared with datacentre ranges, but querying faster than a human plausibly would will still get throttled. Pacing matters at least as much as the IP.
How much bandwidth does a thousand keywords cost?
Tracked once daily on HTML-only fetches, roughly 8–13 GB per month. Rendering each SERP in a browser instead multiplies that by about eight, which is almost never worth it since the ranking data is in the markup.
Which rotation mode should I use?
auto10, split across several -sid- values so the query load spreads over multiple devices. Sticky and hard concentrate everything on one IP, which is the opposite of what a large keyword set needs.
Can I track local-pack and map results?
Results that depend on locality are exactly the ones that need an in-country exit, so this is where a carrier IP in the target market helps most. Expect somewhat heavier pages when rich results are present.
Related guides
Try it against your own targets
Bandwidth estimates on this page are honest ranges, not promises — the only number that matters is what your targets cost you. Your first top-up is credited with an extra $2, which is enough to meter a real run before you size a budget.
