How do I show different prices, language or phone numbers depending on where a visitor is?

This page may contain affiliate links from which Blur Studio earns commissions.

This is a case where the right answer genuinely depends on how dynamic your need is, and getting that wrong in either direction costs you: over-engineering a simple redirect, or under-building something that actually needs real logic. Working out which one you actually have is worth doing before writing a single line of code.

Check if a plain redirect rule is enough first

If your actual need is "send UAE visitors to the Dubai page, UK visitors to the UK page," that's a redirect with a country condition, no code involved at all:

# In netlify.toml
[[redirects]]
  from = "/pricing"
  to = "/pricing/uae"
  status = 302
  conditions = {Country = ["AE"]}

Netlify, the hosting platform the file above assumes your site is built and published on, runs a redirect engine that supports conditions by country, language, user role and cookie value directly in the rule, processed before the page even loads for the visitor. For a straightforward "send this country here" need, this is genuinely the entire solution, and it's worth confirming this covers your case before reaching for anything more involved.

When you actually need Edge Functions

A redirect sends the visitor to a different page. It can't change the content of one page based on where the visitor is, show the same pricing page but with AED instead of GBP, or swap a UK phone number for a UAE one on an otherwise identical layout. That's a genuinely different, more dynamic kind of problem, and it's what Netlify Edge Functions are built for.

An Edge Function runs at the network location nearest the visitor, before the page fully loads, and can inspect where the request is coming from (via Netlify's own geolocation context) to modify the response: rewrite a price, swap text, insert a different phone number, all on the same URL rather than redirecting to a separate page.

The real technical limits, so you don't design around the wrong assumptions

Netlify's own documentation sets specific, fairly tight limits for Edge Functions, worth knowing before you plan anything complex:

• 20MB code size after compression, for the whole set of edge functions on a site.
• 512MB memory shared across the deployed edge functions.
• 50 milliseconds of CPU execution time per request. This is genuinely tight, and it rules out any heavy processing; an edge function needs to do something fast and simple, like swapping a price or a phone number, not running a complex calculation.
• Not compatible with split testing, custom headers (including basic auth), or prerendering. If your site uses any of those features on the same paths, the edge function won't run as expected there.

That last point matters in practice more than it sounds: if you're already running an A/B test on your pricing page and then try to add an edge function for country-based pricing on the same page, the two features conflict, and you'll need to choose one or restructure how you're running the test.

A realistic example

Say you sell a service at a price shown as a round number in USD, but want Dubai-based visitors to see it in AED and UK visitors in GBP, converted at rates you control rather than letting a browser's locale guess do it inconsistently. An edge function can detect the visitor's country from Netlify's geolocation context, pick the right currency and rate from a small lookup table in your code, and rewrite that one number on the page, all within the tight CPU budget, since a currency lookup and a string replacement is exactly the kind of fast, simple operation edge functions are built for.

A worked example: a consulting firm with two offices and one website

A consulting firm with offices in London and Dubai wanted their "contact us" phone number to automatically show the local office's number depending on where the visitor was browsing from, while keeping everything else on the page identical. This wasn't a redirect case, since redirecting to two entirely separate page copies just to swap one phone number would mean maintaining two nearly identical pages and remembering to update both every time anything else on the page changed.

An edge function solved this cleanly and stayed well within the tight CPU budget: it checks the visitor's country from Netlify's geolocation context, picks the right phone number from a two-entry lookup, and swaps it into the page before it loads. The entire operation is a lookup and a string replacement, nowhere close to the 50-millisecond limit, and the firm now maintains one page instead of two, with the location-specific detail handled automatically rather than manually kept in sync across duplicate pages.

Common mistakes with geo-targeting

• Building an edge function for something a redirect already solves. If you genuinely just need different visitors landing on different pages, a redirect condition does that with zero code and zero ongoing maintenance.
• Trying to run heavy logic inside the 50-millisecond budget. Anything beyond a quick lookup and swap risks timing out. Keep edge function logic deliberately minimal.
• Not testing from an actual location, or a VPN set to one. Geo-targeting bugs are easy to miss testing from your own usual location; verify the behavior from (or simulating) each target country before considering it done.

What I'd actually tell you

Most requests I hear that sound like "I need geo-targeting" turn out to be the simple redirect case once we talk through it: send this market here, that market there. Don't build an edge function for that; it's solving a harder problem than you actually have. Reach for edge functions specifically when the content needs to change on the same page based on location, not when a different page per market would do the job just as well with far less to maintain.

When to skip this entirely

If you're already running an ecommerce platform like Shopify, its built-in Markets feature handles multi-currency and multi-region pricing natively, often better than a custom edge function would, since it's purpose-built for exactly that. Don't build custom geo-logic on top of a platform that already solves the problem natively, since you'd be maintaining a parallel system doing something the platform you're already paying for already does reliably.

How I'd approach this

I'd start by confirming which of these two problems you actually have, since they have very different right answers. If it's "send this market to a different page," that's a five-minute redirect rule, not a project. If it's genuine same-page personalization by location, Netlify Edge Functions are the right tool and I build this kind of thing regularly, kept well within the tight CPU budget by doing the lookup and swap quickly rather than anything heavier.