Skip to content
LightningBytes
Back to Blog

Geo-Targeted SERP Testing

Designing tests that isolate geography: the same query from different city addresses, a fixed device profile, and a clean record of what each market returned.

by LightningBytes Team
  • geo-targeting
  • serp-tracking
  • seo

To find out whether a result differs by location, change location and nothing else. That sounds simple, and three confounders break it in practice: personalisation, locale and currency.

This is a test design guide rather than a tracking overview. The broader measurement case is in SERP Tracking at Scale.

The design

One variable. Geography. Hold the query, the device, the language, the time window and the session state fixed, and vary only the address.

Multiple markets at one time. Run the sweep across markets within the same window, because results move over time and a market checked today is not comparable to one checked tomorrow.

One address per market per run. Not rotating within a market, so the vantage point is a single point rather than a cloud.

Logged out. No account, no history, no personalisation from prior sessions.

The output is a matrix: query by market by position band, with the layout recorded for each cell.

The three confounders

Personalisation. Prior searches on the same address influence results. A freshly assigned address has no history, which is cleaner than one that has been used for unrelated queries. Keep an address for a market reserved for these tests rather than sharing it with other collection.

Locale. The Accept-Language header and the location parameter both affect the returned page. An address in Poland with an English language header may receive the English version of a localised result set, which is neither market's true view.

Currency and units. Retail and travel results display prices in the local currency. A result compared across markets must have its currency recorded, because comparing a numeric value without it is meaningless.

One more, less obvious: time zone. Some results, particularly for news and events, are time-dependent. Recording the UTC timestamp and the market's local time keeps the comparison honest.

Holding device constant

Device is a structural variable, not a cosmetic one.

  • Viewport and emulation. Set an explicit viewport rather than relying on a tool's default, and record it.
  • User agent. Fix one per device class, and do not randomise it between checks. Changing it mid-comparison introduces a second variable.
  • Touch and hover behaviour, where the tool emulates them, should be consistent across the sweep.
  • Mobile versus desktop as separate runs, never mixed in one matrix.

Where a real mobile network is needed rather than emulation, that is a different test with mobile addresses, and the case is covered in Mobile Proxies for Ad Verification.

Recording results cleanly

The record needs more than a position. For each cell, capture:

FieldWhy
Query and marketThe test's identity
Exit address and its cityThe vantage point, verified not assumed
Timestamp in UTC and localTime-dependent results
Device profile and viewportThe fixed variable
Language header and location parameterLocale context
Organic results with positionsThe measurement
Result modules presentLayout changes position meaning
Ad count and positionsVisibility context
Currency, where prices appearComparability across markets

Two fields are routinely omitted and are the ones that invalidate a later review: the exit address and the module layout. Without the first, the vantage point is unknown. Without the second, a position change cannot be attributed to a ranking change rather than to a panel appearing above it.

Interpreting the output

Four patterns emerge from a well-controlled matrix, and each means something different.

Uniform results across markets. The query is not location-sensitive. Useful to know, because it means the market dimension can be dropped from ongoing tracking and the cost falls accordingly.

Graduated differences. Results change progressively with geography, which usually indicates proximity ranking, typical of services and local businesses.

Binary differences. Some markets show a result and others do not at all, which usually indicates availability, licensing or a local entity.

Layout differences with stable organic order. The organic ranking is the same, but modules differ, so the perceived visibility differs even though the rank does not.

The fourth is the one most often misread as a ranking change. Recording modules is what prevents that.

Sampling within a market

Even with everything controlled, a single check per market is one sample. Engines serve variations, particularly in mid-page positions.

Practical settings:

  • Two or three checks per market in the same run, recording all positions.
  • Report a band, not a precise rank, when the variation is wide.
  • Repeat the sweep weekly, and compare sweeps rather than checks.

A test that runs once and produces a number is a snapshot. A test that runs consistently produces a trend, and the trend is what justifies a decision.

Infrastructure

For a multi-market sweep, the setup is one stable residential address per market, held for the duration of the run, with the language header matched. Verify each address before the run starts, because an address that has drifted out of the intended country silently makes every cell in that market's column wrong. The Proxy Checker and IP Lookup confirm the exit address and its location.

Datacenter addresses are unsuitable for this specific design, because the test's premise is that the vantage point is a real location. The reasoning is in Proxies for SEO Monitoring.

For the solution context, see Geo-Targeting and SERP Tracking.

Start working with cleaner IPs

Clean, pre-filtered residential and mobile proxies, sign up and send your first request in minutes.

We use cookies for authentication and security. With your consent we also enable optional marketing & analytics cookies. See our privacy policy.