Geo-Targeted Scraping: Where Sites Place Your Mobile IP

If you collect localized data, such as store prices, delivery availability, map listings or search results for a given metro, the page you receive depends on where the target thinks your request came from. That decision is not made by looking at our modem. It is made by looking your IP address up in a geolocation database. Most of the time the answer is the metro you bought. Sometimes it is the state, or a neighbouring hub city, and every so often one lookup service disagrees with the next. This guide explains why that happens on carrier networks, what we have seen on our own hardware, and how to build location checks into a scraping pipeline so a wrong city never quietly contaminates a dataset.

The target reads a database, not a map pin

An IP address carries no coordinates. When a retailer or search engine localizes a page, it asks a commercial geolocation provider, typically MaxMind GeoIP2, ipinfo, IP2Location, DB-IP or an in-house blend, which city that address belongs to. Those providers assemble their answers from several sources: which entity registered the block, the routes it is announced on, geofeeds that networks publish in the RFC 8805 format, latency measurements from probe points, and signals contributed by apps and users.

So the city in your scraped results is an inference about the network, not a measurement of where the SIM card physically sits. For crawler design that distinction matters, because it means the location is something you verify per run, not a constant you set once in a config file.

Why a mobile address resolves to a metro or a state

Our modems attach to towers in the city you chose, but their traffic does not reach the internet at that tower. Inside the operator's core it is hauled to a regional egress gateway, goes through carrier-grade NAT alongside a crowd of ordinary phone users, and only then emerges with a public address from that gateway's pool. The databases locate the pool, so a carrier address tends to come back as a metro, sometimes only as a state, and once in a while as the hub city the carrier routes that region through.

That also sets a hard limit worth stating plainly for anyone scraping hyperlocal results: no mobile proxy can be honestly sold as placing you in a specific zip code, street or neighbourhood. If a target localizes by postcode, pass the postcode the way a shopper would, through the store selector, a delivery address field or a query parameter, rather than hoping the IP lands there.

One building, two carriers, two cities

Our Boston site is the clearest illustration we have. The Verizon lines in that rack resolve as Boston in the major databases. The AT&T lines on the same shelves, using the same towers, resolve as New York. Nothing is faulty on either side; AT&T simply registers and routes its addresses for that region through a gateway it associates with New York, while Verizon keeps a Boston presence.

For a crawler collecting Boston store inventory, that difference decides whether the dataset is right. The practical lesson is to treat carrier as part of your location setting. If a job needs a Boston reading, tell us before you buy or contact support afterwards, and we will put you on the carrier that reads that way.

Why the reading can drift between runs

Lookup services refresh their databases on their own schedules, and carriers now and then hand a block of addresses to a different market. Because a rotation hands you a new address from the carrier's pool, a run that read as one city yesterday can read as the state today, or the reverse, without anything changing in our rack.

Pipelines that assume a fixed location are the ones that get burned by this. Pipelines that record the location alongside each batch catch it immediately and can re-queue the affected pages.

Signals beyond the address when you scrape with a browser

Plain HTTP clients send little besides the address and headers, but headless and headed browsers expose more. A target can compare the IP's city with the browser timezone, the Accept-Language header, the HTML5 geolocation API, which reports what the device's GPS or Wi-Fi positioning says and has nothing to do with the IP, and WebRTC, which can reveal the machine's own address if left unconfigured.

Picture a Massachusetts mobile address arriving from a browser that insists it is on Berlin time: that is an obvious inconsistency, and some targets will localize from the browser instead of the IP. Set the timezone and locale in your Playwright or Puppeteer launch options to match the proxy's reading, deny or set the geolocation permission deliberately, and disable WebRTC leaks. GoLogin and Undetectable.io can align these values to the proxy automatically if you use them.

Putting a location check into the pipeline

Decide first what precision the job really needs. Plenty of price monitoring only needs a US or state-level reading; local pack rankings and store availability usually need the metro. Then make the check routine:

• Right after purchase, feed the new address to ipinfo.io, browserleaks.com/ip (which shows several databases side by side) and our Tools page checker, then note the majority city
• Store the resolved city with every batch so a shift shows up in your data rather than in a client complaint
• Re-check after rotations and when results start looking like a different market
• Compare against a known localized page, for example a store locator, to confirm what the target itself decided
• When a crawl needs a different answer, move the line to another city yourself in the dashboard at no charge, or ask support for the carrier whose addresses resolve where your crawl has to be.

Frequently asked