How to Test Websites by Geolocation

To test a website by geolocation, first determine which location signal it uses. Use Chrome DevTools Sensors to emulate browser-reported coordinates when the site requests the browser’s Geolocation API. Use a proxy, VPN, or cloud testing session in the target region when the site determines location from the source IP. If you do not know which signal the site uses, test both: changing coordinates does not change the request’s source IP, and changing the IP does not automatically change browser coordinates.

This guide covers interactive checks, repeatable testing, automation considerations, result capture, and common failures. The right method depends on what the website reads; none of these methods alone proves how every visitor in a region will experience it.

1. Define what “location” means for your test

Websites can infer or receive location in several ways. Identify the signal before choosing a tool.

Location signal	What to change	What it can verify
Browser Geolocation API	Emulated latitude and longitude, plus permission state	Location prompts, coordinate-based content, and fallback behavior
Source IP	Route the test traffic through an exit point in the target country or region	IP-based redirects, regional availability, and IP-based content or restrictions
User-selected location	Change the site’s own country, language, or store selector	Behavior after an explicit user choice
More than one signal	Test coordinates and IP separately, then together if relevant	Interactions between browser permission, network region, and site settings

Do not treat a browser coordinate override as an IP-location test. A website may use an IP lookup before it asks for browser permission, or it may ignore coordinates entirely. When the implementation is unclear, inspect the application code or network behavior where possible and run separate tests for each signal.

2. Write a small regional test matrix

Choose regions that reflect where the product is available and what could change there. For each region, write down the expected result before you run the test. Include a permission-denied or unavailable case if the site asks the browser for location.

Case	Signal to vary	Example expected result
Default visitor	Neither, or your ordinary connection	Default locale or a location chooser
Browser location allowed	Coordinates	Nearby service, local content, or a location-aware result
Browser location unavailable	Permission or location state	Useful fallback instead of a blank state or endless spinner
Target country	Source IP	Expected redirect, currency, catalog, or access message
Restricted region	Source IP and, if relevant, coordinates	Correct eligibility or restriction message

Record the target region, signal changed, tool and plan, browser and device, expected and actual outcomes, and a screenshot or test log. This makes a failure easier to reproduce and helps distinguish a location issue from a browser, account, or cache issue.

3. Test browser coordinates with Chrome DevTools

Chrome DevTools Sensors can emulate preset cities, custom coordinates, and an unavailable location state. This is a useful starting point for sites that call the browser Geolocation API. It does not route requests through another country. See the Chrome DevTools Sensors documentation.

Open the page in Chrome and open DevTools.
Open the DevTools menu, then More tools and Sensors. In the Sensors panel, find the location controls.
Select a preset location, or choose a custom location and enter latitude and longitude for the test point.
To check fallback handling, select the location-unavailable state.
Reload the page or repeat the action that requests location. If the site asks for permission, grant or deny it according to the test case.
Check the visible result and any relevant console or network errors. Record which coordinate and permission state were active.

For each case, verify the outcome the visitor sees: the location prompt, localized content, a result based on nearby coordinates, a useful fallback, or an understandable error. A successful page load alone does not show that location handling works.

Coordinates are inputs, not proof of physical presence

Emulated coordinates let you exercise code that consumes browser location. They do not change the network route, prove that an IP lookup returns the same place, or reproduce every browser and operating-system permission flow on a real device. Use a real-device or cloud browser session when those details are part of the requirement.

4. Test source-IP location

If the application uses IP geolocation, the request must originate from an exit point in the target region. Use a location-specific proxy, VPN, or cloud testing platform, then confirm the selected region is active for the test session. Provider coverage and access can depend on the product and plan.

Select the country or state required by the test.
Connect the browser or test runner to that location using the provider’s documented setup.
Start a fresh session, then load the site and repeat the user journey.
Check redirects, language, currency, regional products or content, blocked content, and consent or eligibility messages.
Record the provider, selected location, session details, browser, and result so the test can be repeated.

BrowserStack documents IP Geolocation for selected countries and states, with product and plan restrictions. Its documentation reports addresses hosted in 60+ countries and 30+ states; treat that as vendor-reported coverage and check current eligibility before choosing a plan. WonderProxy documents regional proxy and VPN access, automation integrations, and browser overrides as a separate capability. It reports coverage of 280 cities across 103 countries; that is also a vendor-reported figure, not an independent comparison. See BrowserStack IP Geolocation and WonderProxy documentation.

For a quick, non-interactive inspection, Cloudflare Radar URL Scanner documents country-based scanning. Its Security Center location scanning is limited to Enterprise customers according to its documentation. A scanner can help inspect location-dependent presentation, but it is not a substitute for exercising an interactive journey in the browser. See Cloudflare Radar URL Scanner documentation.

5. Verify outcomes, not just the apparent location

For each target, check the outputs that matter to your users and business:

Language, locale formatting, and currency.
Product, service, or content availability.
Redirect destination and whether the visitor can choose another region.
Access restrictions and eligibility messages.
Consent prompts and other region-specific interface elements.
Whether a denied or unavailable browser location leaves a usable fallback.

Some behaviors can come from a saved cookie, account preference, or cached response rather than the location signal under test. Use a fresh browser context or clear the relevant state, and repeat the test when necessary. Do not assume a result reflects the target region until you have verified which signal changed and that the expected journey actually ran.

6. Automate repeatable checks

For automation, keep the location setup explicit in the test configuration. Run coordinate-based cases with a browser context that supports geolocation emulation and the required permission state. Run IP-based cases through a provider endpoint configured for the target region. These are separate controls: setting a browser’s coordinates does not configure a proxy, and configuring a proxy does not grant browser location permission.

Organize tests around a small set of region and outcome pairs, and capture the selected region alongside the result. For cloud testing services, confirm the chosen location is supported by the product and plan in use. If a test is flaky, first check whether the session actually used the intended proxy or coordinate override, whether a redirect or saved preference changed the journey, and whether a timeout prevented the location-dependent request from finishing.

7. Capture evidence for a regional result

A screenshot is useful evidence of what the page displayed, but it does not establish which IP or browser coordinates were used. Save the test configuration or logs with the image. For a quick manual capture, use the browser’s built-in screenshot command or your existing test runner after setting the location. For a URL-only inspection, ScreenshotNeo can capture a page as an image or PDF; it does not itself select a source-IP region or set browser geolocation coordinates. See the ScreenshotNeo website and API documentation.

When comparing regions, keep the viewport, browser state, account state, and capture timing consistent. Otherwise, a layout or session difference may be mistaken for a geolocation difference.

Or skip the browser setup

For a URL-only screenshot, ScreenshotNeo provides a one-call API. This captures the target page; use your own coordinate emulation or regional network setup when the test depends on those signals.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Replace the example URL with the page you need to capture. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots, and 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000. Every feature is on every plan. For available capture options and response details, see the ScreenshotNeo API documentation. Sign up for 1,000 free screenshots a month, with no card required.

Performance, reliability, and cost

DevTools Sensors is a built-in option for interactive coordinate checks and avoids setting up a regional network route. IP-based testing adds provider setup and may have product or plan constraints; check current availability for the region and workflow you need. Cloud browser testing can make regional runs repeatable, though coverage depends on the service and plan. The dossier does not establish comparative endpoint accuracy or latency, so validate the result against the behavior your application expects.

Keep the test matrix focused on regions that your product serves or restricts, and reuse a consistent browser state to make failures easier to compare. For screenshot evidence, ScreenshotNeo bills only clean shots: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its plans are Free for 1,000 shots per month, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free. Confirm current plan details on the product site.

Troubleshooting

Symptom	Likely cause	What to do
The page does not change after entering coordinates	The site does not use browser geolocation, or it only requests location after a user action	Trigger the relevant action; inspect whether the page requests coordinates. Test source-IP behavior separately if appropriate.
The page still shows the original country with DevTools coordinates set	The site uses IP location, a saved preference, or another location source	Check cookies and account preferences, then test with a regional network route if the site relies on IP.
A regional proxy is active but the browser location prompt fails	Network location and browser permission are independent	Set coordinates and permission state separately when testing Geolocation API behavior.
The location-dependent content is stale	A cookie, account setting, redirect, or cached response may preserve the earlier region	Use a fresh session, clear relevant site data, and repeat the journey while recording the selected region.
The unavailable-location case hangs or renders nothing	The application may not handle denied or unavailable coordinates	Verify the fallback state and ensure the user can continue or choose a location manually.
The test uses the wrong country or state	The provider may not support that location in the selected product or plan, or the session may not have applied the selection	Check current provider coverage and plan restrictions, reconnect the session, and verify the selected location in the test record.
A URL scanner result differs from an interactive browser test	The scanner is an inspection vantage point and may not reproduce browser permissions, account state, or interaction	Use an interactive browser session for the full journey and treat scanner output as a limited inspection.

FAQ

Does changing my browser location change my IP address?

No. A browser coordinate override and the network’s source IP are separate signals.

Should I test permission denial?

Yes, if the site requests browser coordinates. Verify that the visitor gets a useful fallback.

Can a screenshot prove the site was tested from a particular country?

No. Keep the location configuration or test log with the screenshot as evidence of how the session was configured.

Which location should I test first?

Start with the regions where your product has different language, currency, availability, redirects, or access rules, then add the denied or unavailable case for browser geolocation.