Mobile Proxy SEO Rank Tracking
Google retired the num=100 parameter in September 2025, so the same ranking report now costs ten times the requests. This guide covers what that changed, how to reproduce a searcher’s location and device properly, and how to keep a position series unbroken.
- num=100 is gone — since September 2025 Google returns ten results a page, so the same top-100 report costs ten requests instead of one.
- There is no single ranking — only about 11 per cent of keywords hold the same position on mobile and desktop, so device is an axis, not a detail.
- Location beats the uule parameter — uule hints the coordinates, but the exit IP still shapes the page you get back.
- Consistency is the whole product — a position series with gaps cannot tell you when anything moved.
Measure the SERP your phone-using customers actually get.
Exit IP and uule pointing at the same place.
SEO Rank Tracking Challenges
Rank tracking looks like a solved problem until you try to do it accurately, at which point two awkward facts surface. The first is that there is no such thing as the ranking for a keyword — Google assembles a results page per searcher, using location and device as primary inputs. The second is that collecting those pages became roughly ten times more expensive in September 2025.
That month Google disabled the num=100 search parameter. Until then a single request could return up to a hundred results, which is how rank trackers captured an entire competitive landscape cheaply. Now Google returns ten results per page. Nothing about ranking itself changed, but the cost of measuring it multiplied: the same top-100 report that once took one request now takes ten paginated ones.
The knock-on effect confused a lot of people. After the change, analyses found around 87.7 per cent of sites recorded fewer total impressions in Search Console and 77.6 per cent recorded fewer unique keywords. That was not a collapse in visibility. Bulk hundred-result requests had been registering an impression for every listing on the page, quietly inflating deep-position counts for years. Removing them corrected the measurement — which is also why average position often improved at the same moment.
| What changed | Before September 2025 | Now |
|---|---|---|
| Results per request | Up to 100 with the num parameter | 10, paginated |
| Requests for a top-100 report | One | Ten |
| Search Console impressions | Inflated by bulk collection at deep positions | Lower and closer to human reality |
| Practical tracking depth | Top 100 by default, at no extra cost | A budget decision, page by page |
The device split is the other half of the problem, and it is larger than most reporting admits: only about 11 per cent of keywords hold the same position on mobile and desktop. The page is not merely reordered, it is assembled differently. On mobile an AI Overview typically occupies the space above everything else and the local pack sits immediately beneath it, pushing classic organic results a long way down. If your customers search on phones, a desktop-only report describes a page they never see.
Decide what you are measuring before you decide how deep to go. Tracking the top ten across many locations and both devices tells you more about your business than tracking the top hundred from one vantage point, and after the num change it also costs less.
Mobile Proxy for SERP Scraping
Search results are among the most heavily defended pages on the web, and the defence is aimed squarely at automated collection. What triggers it is rarely one dramatic mistake. It is request rate from a single address, a browser fingerprint that does not match the address it arrives from, unhandled consent interstitials, and predictable parameter patterns arriving in lockstep.
Carrier IPs help for a structural reason rather than a cosmetic one. Mobile networks put thousands of genuine subscribers behind the same carrier-grade NAT gateway, so a single exit address carries a large amount of ordinary human traffic that is nothing to do with you. Blocking it outright is expensive for the target, which buys your requests more tolerance than an address representing one machine ever gets.
There is also a consistency argument specific to this job. Measuring mobile rankings means presenting as a mobile client, and a mobile user agent arriving from a hosting range is a contradiction the receiving end can see immediately. A mobile user agent arriving from a mobile carrier is simply a phone.
# Page one, then paginate in tens with start= https://www.google.com/search?q=mobile+proxy&gl=fr&hl=fr https://www.google.com/search?q=mobile+proxy&gl=fr&hl=fr&start=10 https://www.google.com/search?q=mobile+proxy&gl=fr&hl=fr&start=20 # gl sets the country edition, hl the interface language. # Neither one places the searcher anywhere -- that is what uule and # the exit IP are for.
Two practical notes. Handle the consent interstitial before parsing anything, because in several regions the results page you receive first is not a results page at all. And keep the session identity stable for the duration of a single measurement: paginating through ten pages from ten different addresses produces ten unrelated snapshots rather than one coherent ranking.
If requests start failing rather than returning results, read the response before changing the proxy — what each block actually means separates a rate problem from a fingerprint problem, and they have opposite fixes.
Geo-Specific Rank Data
Location is where most rank tracking quietly goes wrong, because the three mechanisms that look interchangeable are not. Getting a genuinely local result means understanding which one does what.
| Signal | What it controls | What it does not do |
|---|---|---|
| gl | Which country edition of the results you get | Place the searcher anywhere. It is a country setting, not a location |
| hl | Interface language, and indirectly some result selection | Affect geography at all |
| uule | Encodes coordinates so the search is treated as coming from that point | Override everything. The exit address still shapes the page you receive |
| Exit IP | Default location, consent handling, which interstitials appear | Reach street-level precision on its own — fixed-line geolocation is city-level at best |
The workable combination is to make the signals agree rather than compete. Encode the coordinates you care about in uule, set gl and hl to the market, and send the request from an exit IP inside that same market. When those three point at one place, Google has nothing to reconcile. When they disagree — coordinates in Lyon, an address in Frankfurt — you are measuring how Google resolves a contradiction, which is not a metric anyone asked for.
This is also where mobile earns its cost. A phone reports location with far more precision than fixed-line geolocation infers it, and a carrier address in the target market carries network signals consistent with a subscriber who is genuinely there. For local pack tracking, where the difference between two suburbs changes the result set entirely, that consistency is the difference between a number you can act on and one you cannot.
Scaling Rank Tracking with Proxies
Scale in rank tracking is arithmetic, and doing the arithmetic before buying anything saves a great deal of money. Multiply keywords by locations by devices by pages of depth, and you have the request count for a single run.
requests_per_run = keywords x locations x devices x pages_of_depth # 500 keywords, 4 cities, mobile and desktop, top 30 (3 pages): # 500 x 4 x 2 x 3 = 12,000 requests per run # # Same job tracking the top 100 instead (10 pages): # 500 x 4 x 2 x 10 = 40,000 requests per run
Spread that count across the window you can tolerate, and the pool only needs to be large enough to keep each address at a believable rate. This is the point most teams get backwards: cadence matters more than pool size. A modest pool used patiently outlasts a large one fired all at once, because defences respond to request rate per address rather than to how many addresses exist.
- Cut depth before cutting coverage — Losing a location or a device removes an answer entirely. Losing pages four to ten removes positions almost nobody clicks.
- Keep one identity per measurement — Paginate a keyword through a single session so the ten pages describe one ranking. Rotate between keywords, not within them.
- Back off on the signal, not the schedule — When challenges appear, slow down and let the address recover. Retrying immediately from a fresh address teaches the target that the pattern continues regardless.
- Stagger the run — Every tracker firing at midnight makes an obvious pattern. Spreading a run across hours costs nothing and looks like traffic.
- Track collection health as a metric — Challenge rate and empty-result rate per address warn you days before a series develops a hole. A gap in a position series is not recoverable afterwards.
For the code side of this — sessions, retries and backoff that honours Retry-After rather than hammering a 429 — the Python scraping guide covers the patterns, and scraping best practices covers running them at volume without burning the pool.
Track Rankings From the Market That Matters
Live PXM2 locations — pick the country you need SERP data from, and collect it from a real carrier IP inside it:
France
India
Singapore
Frequently Asked Questions
What changed when Google removed num=100?
Until September 2025 a single request with that parameter returned up to a hundred results, which is how rank trackers captured a full competitive landscape cheaply. Google disabled it, leaving ten results per page. Nothing about ranking changed, but the cost of measuring it did: the same depth now takes ten paginated requests. Anyone tracking deep positions across many keywords saw their request volume multiply overnight.
Why did my Search Console impressions fall at the same time?
Because a large share of them had never been human. Analyses after the change found around 87.7 per cent of sites recorded fewer total impressions and 77.6 per cent recorded fewer unique keywords. Bulk hundred-result requests had been registering impressions for every listing on the page, inflating deep-position counts for years. The drop is a correction to the measurement, not a loss of visibility — average position often improved for the same reason.
Is the uule parameter enough, or do I need a proxy in that location?
On its own it is not enough. Encoding a location into uule tells Google to treat the search as coming from those coordinates, and it works well for the local pack and clearly local intent. The exit IP still influences the page — country defaults, language, consent handling and the interstitials you get served. Pairing a uule value with an exit IP in the same market removes the conflict between the two signals rather than asking Google to resolve it.
Do mobile rankings really differ enough to track separately?
Yes. Only about 11 per cent of keywords hold the same position across mobile and desktop, and the page is assembled differently: on mobile an AI Overview typically occupies the space above everything else and the local pack sits immediately below, pushing classic organic results well down. If your customers are on phones, a desktop-only report is describing a page they never see.
How many proxies does rank tracking need?
Work it out from the job rather than guessing. Multiply keywords by locations by devices, then by the pages of depth you need, and you have the request count per run. Spread that across the window you can tolerate, and the pool only has to be large enough to keep each address at a believable rate. Most teams find cadence, not pool size, is what actually stops the CAPTCHAs — a modest pool used patiently outlasts a large one used all at once.
Related Mobile Proxy Guides
Rank tracking is a measurement job with a scraping engine underneath it, so both halves are worth reading.
Business use cases
Scraping and setup guides
Track Rankings From the Right Place
Dedicated 4G/5G modems with unlimited bandwidth and unlimited rotations — carrier IPs in the markets you need SERP data from, with no per-request pricing.
Get a Mobile Proxy