Proxies for Local SEO Geo-Grid Rank Tracking

A geo-grid rank check places a square of evenly spaced pins over a map, usually centred on a business, and records where that business ranks for one keyword at every pin. The output is a heat map: green where you hold a top-three spot, red where you do not appear.

Three settings define every scan:

• Grid size. The number of pins per side. 5x5 gives 25 points, 7x7 gives 49, 9x9 gives 81. Local Falcon's help pages call 9x9 the most popular size and mention grids as large as 21x21, which is 441 points.
• Spacing. The distance between neighbouring pins, typically a quarter mile to a mile for urban businesses and several miles for service-area businesses.
• Depth. How far down the results each pin looks. Local Falcon's reports check up to position 20.

The summary metrics most agencies report come from that same vendor's vocabulary. Per Local Falcon's published definitions, ARP (Average Rank Position) averages only the pins where the business was found within the top 20, ATRP (Average Total Rank Position) averages every pin including misses, and SoLV (Share of Local Voice) is the share of pins where the business sits in the top three.

The key point for infrastructure: one pin is one search. A 9x9 grid for one keyword is 81 separate queries, each of which has to look as if it came from its own coordinates. That multiplier is why local rank tracking burns far more requests than classic keyword tracking, which is covered in datacenter proxies for SEO rank tracking.

Google's own help article on managing your location in Search lists four sources that are "used together to estimate where you are":

Google's article adds a detail that matters directly for grid scans: google.com may reuse the device location from your last visit, stored in a cookie set to expire after 6 hours. A scraper that keeps one cookie jar across a whole grid can carry pin 1's location into pin 40. More on that in the clean-scan section.

Google does not publish which source wins when they disagree. What the table does show is that the IP is the coarsest signal on the list, so a scanner that needs pin-level precision has to supply location some other way. That is how geo-grid products work: they set a location for each pin rather than hunting for an IP that happens to sit there, and a pilot scan (described at the end) is how you confirm your own method is being honoured.

Do the geometry for a typical scan.

Every grid in that table fits inside a single mid-sized city. A city-targeted IP, even a perfectly geolocated one, gives every pin the same answer: somewhere in that city. It cannot tell pin 1 from pin 81, so a grid built from city IPs collapses into one repeated measurement drawn 81 times.

IP geolocation is also less precise than vendor dashboards suggest. Commercial databases disagree with each other at city level, and many IPs resolve to the registered location of the network rather than where the traffic originates. If you want to see how far off a given address is, validating IP geolocation accuracy shows how to cross-check several databases.

City-targeted IPs still have a use: a quick single-point check of "what does someone in Denver see for plumber near me" when you cannot or do not want to set coordinates. For anything shaped like a grid, location has to travel in the request. For the basics of what country, state and city targeting do mean, see what geo-targeting means in proxies.

Taking the pin location off the proxy does not make the proxy irrelevant. It changes what you are buying it for.

1. Country match. Results, language and even which businesses are eligible differ by country. The exit IP should sit in the same country as the grid, and the Google domain and interface language should agree with it. A US grid served from a German exit invites a mixed-signal response.
2. Reputation and challenge rate. Search and Maps pages challenge automated traffic aggressively. The share of pins that return a CAPTCHA or an unusual-traffic page, rather than results, is the metric that decides your proxy bill, because every blocked pin is a hole in the heat map or a retry.
3. No identity carry-over. Each pin must look like a fresh visitor. Rotation per request, no sticky sessions, no cookies from earlier pins, and never an account login.
4. Enough headroom for retries. Plan capacity for a realistic failure rate on first attempt, then measure the real one on your targets.
5. Predictable cost. Rendered map pages are heavy. On a per-GB plan, page weight and retries both add to the bill; on an unmetered plan, neither does.

Notice what is missing from that list: city targeting and huge concurrency. Both are what vendors tend to sell for this use case, and neither is the constraint.

Size from pins, not keywords. The formula is:

monthly pin lookups = locations x keywords x (grid side ^ 2) x scans per month

Three illustrative profiles, with the arithmetic shown so you can swap in your own numbers:

Now convert lookups into infrastructure. Two findings surprise most teams.

Concurrency is small. Assume a rendered map result takes about 6 seconds including a headless browser. The agency's weekly 23,500 pins, run in an 8-hour overnight window, need roughly 49 lookups a minute, which is about 5 concurrent browsers. The retail brand's 22,500 daily pins in a 6-hour window need about 6. Even SparkProxy's smallest plan, 100 threads, is far more parallelism than either needs. Buy for clean exits and retry margin, not thread count.

Credits and bandwidth are large. If you use a scraping API instead of your own browsers, cost follows the per-request price. On the SparkProxy Scraping API, a JavaScript-rendered request costs 5 credits and the country_code geolocation add-on adds 5, so a rendered, country-pinned lookup is 10 credits. The agency's 101,900 lookups become about 1.02 million credits a month, just over the Growth plan's 1,000,000 ($99) and inside Pro's 3,000,000 ($249). If the results you need are available without rendering, the same lookups at 6 credits each come to about 611,000 credits, which fits Growth. The docs state that failed requests are refunded, which keeps retries from compounding the bill.

If you run your own headless browsers through proxies instead, each rendered page pulls scripts, tiles and images. That is exactly where a metered plan gets expensive and an unmetered one does not.

SparkProxy sits in two rows. Its proxy plans are rotating datacenter capacity with unlimited bandwidth: Starter $75/mo for 100 threads, Core $140 for 250, Boost $240 for 500 and Plus $440 for 1000, with random per-request rotation that suits one-pin-one-identity scanning. Country targeting is included. SparkProxy does not sell residential or mobile proxies and does not offer city targeting, so if your process genuinely depends on city-geolocated exits, buy those elsewhere. For scraping jobs, the SparkProxy Scraping API does offer residential exits through its premium_proxy option, which routes a request through a residential pool for 10 credits, or 25 with JavaScript rendering. The SparkProxy Scraping API covers the second row, with 1,000 free credits and no card.

For the wider picture on search result collection, including non-local SERPs, see proxies for SERP scraping at scale.

The grid itself is plain geometry. This function builds a square grid around a centre point, converting metres to degrees with the latitude correction that keeps spacing honest away from the equator:

import math

def geo_grid(lat, lng, side=7, spacing_m=1000):
    """Return (row, col, lat, lng) for a side x side grid centred on lat/lng."""
    half = (side - 1) / 2
    m_per_deg_lat = 111_320
    m_per_deg_lng = 111_320 * math.cos(math.radians(lat))
    pins = []
    for r in range(side):
        for c in range(side):
            dy = (half - r) * spacing_m   # north is up
            dx = (c - half) * spacing_m
            pins.append((r, c,
                         round(lat + dy / m_per_deg_lat, 6),
                         round(lng + dx / m_per_deg_lng, 6)))
    return pins

grid = geo_grid(39.7392, -104.9903, side=7, spacing_m=1000)
print(len(grid), grid[0], grid[24])   # 49 pins; corner pin; centre pin

The flat-earth approximation is accurate enough for grids a few miles wide. For service-area grids spanning tens of miles, switch to a proper geodesic library.

Each pin then becomes one request carrying its coordinates. How you pass them depends on the surface you scan. Rank trackers commonly centre a Maps search viewport on the pin, or encode the location for web search with the undocumented uule parameter. Neither is a published Google interface, both can change without notice, and scanning Google properties is governed by Google's terms, so check them with counsel before running this at commercial scale.

A country-pinned, rendered request through the SparkProxy Scraping API looks like this. The target URL is whatever your scanner builds for the pin:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --data-urlencode "url=$PIN_URL" \
  --data-urlencode "render_js=true" \
  --data-urlencode "country_code=US" \
  --data-urlencode "tag=grid:denver-dental:r3c3"

The tag parameter comes back in the response, which makes it a convenient place to carry the grid name and pin index for matching results to cells.

A heat map is only as good as its worst pin. These are the failure modes that quietly corrupt grids.

Cookie carry-over

Google's 6-hour cached-location cookie means a reused session can report an earlier pin's location. Start every pin with an empty cookie jar and a fresh browser context. On the SparkProxy gateway that means port 11000, which rotates the exit per request, never the sticky port 11002.

Logged-in scanning

A Google account carries saved home and work addresses and search history. Scan logged out, always.

Split scan windows

If half a grid runs at 2am and the rest at 2pm after a timeout, you are comparing two different moments. Run each grid in one contiguous window, and retry failed pins inside that window or mark them missing.

Treating blocks as "not found"

An unusual-traffic page contains no business listings, so a naive parser records the pin as "not in top 20". That drags ATRP down and looks like a ranking loss. Detect challenge pages explicitly and store them as failed, not as misses.

Matching by business name

Chains, franchises and near-duplicate names produce false matches. Match on a stable identifier from the listing, such as the place ID or the listing URL, and keep the raw HTML for each pin so disputed cells can be re-read later.

Pacing

Spread pins over the window with jitter rather than firing a whole grid in one burst. Low concurrency is also your friend here, and as the sizing section showed, you rarely need more than a handful of parallel lookups.

For a single business or a small agency, buy. The single dental practice above needs about 1,750 pin lookups a month, and a per-pin SaaS tool handles that with no scanner code, no parser maintenance when Google changes its markup, and client-ready reports. No proxy plan, SparkProxy's included, is the cheaper route at that size.

Building starts to make sense when three things are true together:

• Volume. Tens of thousands of pins a month or more, where per-pin credits dominate the tooling budget.
• Data ownership. You need raw results per pin in your own warehouse, joined to call tracking, reviews or revenue data.
• Custom scheduling or grids. Irregular shapes that follow a delivery zone, daily scans for a few keywords and monthly for the rest, or competitor-centred grids.

If you build, the cheapest reliable stack is usually a small pool of headless browsers, one fresh context per pin, rotating country-matched datacenter exits on an unmetered plan, and explicit challenge detection with a retry budget. Swap the browsers for a scraping API if running them is the part you want to avoid; web scraping API vs self-managed proxies lays out that trade in cost terms.

Before committing, run a one-grid pilot: a 7x7 scan for two keywords, repeated three times across a week. If the heat maps agree with each other and with a manual spot check at the centre pin, your location handling is right. If they disagree, fix location handling before you buy capacity.