Server Location & CDNs: Does It Still Matter Where You Host?

The short answer: server location no longer decides your rankings, but it still shapes them — through speed. Google dropped server IP as a geotargeting signal years ago in favour of ccTLDs, hreflang and Search Console settings, and a CDN can serve your static assets from a node near any visitor on earth. What a CDN cannot do is move your database. Every dynamic, personalised or uncached request still travels to your origin server and back, and that round trip is governed by distance. Whether hosting geography matters for your site depends entirely on how much of your traffic is dynamic and where your users actually are.

What Google actually says about server location

For international targeting, Google's position is settled: server location is not used to determine a site's target country. Geotargeting runs on ccTLDs, hreflang annotations and Search Console country settings, as documented in Google's own guidance on managing multi-regional sites. A Malaysian business hosting in Singapore or Frankfurt loses nothing in targeting terms.

But targeting and performance are different questions. Core Web Vitals are measured from real users' devices, and Time to First Byte sits underneath every one of them — a slow first byte delays LCP no matter how optimised the rest of the page is. TTFB is dominated by network latency to the responding server plus server processing time. When the responding server is your origin, distance is baked into the number. Light in fibre covers roughly 200km per millisecond; a Kuala Lumpur user hitting a US-East origin pays 200–250ms in round-trip time before the server even begins to think.

So the accurate statement is: location does not matter to Google's targeting systems, and matters a great deal to the field data Google collects from your users. The ranking effect is real but indirect — and unlike most ranking factors, this one also shows up directly in your conversion rate.

What a CDN actually fixes — and the requests it cannot touch

A CDN answers cacheable requests from the edge node nearest the visitor: images, CSS, JavaScript, fonts, and — if you configure it — full HTML pages. For a content site where most pages are identical for every visitor, aggressive full-page caching at the edge can make origin location nearly irrelevant; the origin is consulted only on cache misses and purges.

The requests a CDN cannot answer are the ones tied to state: logged-in views, carts, checkouts, on-site search, form submissions, API calls, personalised recommendations, inventory checks. These are cache-bypassing by nature, and each one makes the full journey to origin. An ecommerce store might serve 85% of raw requests from the edge yet still route its most revenue-critical interactions — add to cart, checkout — through the slowest path in the stack. The audit question is not “what share of requests are cached” but “what share of revenue-bearing requests are not.”

This is also why two sites with the same CDN can have wildly different real-user numbers. The CDN flattens the cacheable layer for both; the dynamic layer still reflects raw geography. Before assuming your CDN has solved distance, segment your RUM data by request type and origin round trips per session.

Reading your own data: the afternoon TTFB audit

You do not need to theorise about whether origin location hurts you — your field data answers it. Pull real-user TTFB segmented by country from CrUX or your RUM tool, and compare markets served near your origin against markets far from it. A healthy target is TTFB under 800ms at the 75th percentile per web.dev guidance; if your far markets sit 400–600ms above your near markets, distance is the dominant term and no amount of asset optimisation will close it.

Then separate the two components. Synthetic tests from multiple regions against a cached asset measure pure network distance; tests against an uncacheable endpoint (a search URL with a random parameter works) measure distance plus server processing. If the uncacheable test is slow even from nearby regions, your problem is server processing — underpowered hosting, slow database queries — and moving geography will not fix it. Our data-backed breakdown of how hosting affects SEO through TTFB shows how often “location problems” turn out to be processing problems wearing a disguise.

Only when nearby regions are fast and distant regions are slow do you have a genuine geography decision to make — and the fix menu, in ascending order of cost, is: full-page edge caching, edge rendering, origin relocation, multi-origin.

Choosing origin location for single-market and multi-market sites

For a single-market site the rule is unchanged from the pre-CDN era: host in or immediately adjacent to your market. A Malaysian audience is well served from Kuala Lumpur or Singapore; an Australian audience from Sydney; a UK audience from London. The cost difference between a local and a distant data centre is usually trivial, and the latency win applies to your slowest, most valuable requests. This remains the cheapest performance improvement most small sites can buy, and it compounds with everything else in our guide to choosing reliable hosting.

Multi-market sites face a genuine trade-off, and the data-driven answer is to host at your traffic centre of gravity: weight each candidate region by sessions and revenue, and place origin where the weighted latency across all markets is lowest. A site earning 60% of revenue from Southeast Asia and 40% from Europe usually lands origin in Singapore with aggressive edge caching covering Europe — not the reverse, and not a compromise location that is mediocre for everyone.

Resist multi-origin until the numbers force it. Running synchronised origins in two regions doubles infrastructure complexity, introduces replication lag as a new failure mode, and is justified only when a distant market is both large and dynamic-heavy. Most sites that think they need multi-origin actually need better edge caching.

Edge rendering: the middle path that keeps getting wider

Between “cache static assets” and “move the origin” sits a rapidly maturing middle layer: rendering pages at the edge. Full-page HTML caching with smart invalidation suits content pages that change on publish, not per visitor. Stale-while-revalidate lets the edge serve a cached copy instantly while refreshing in the background, hiding origin latency from almost every request. Edge functions can assemble mostly-static pages near the user and fetch only the truly dynamic fragments from origin.

The practical effect for SEO is that a well-configured edge layer gives crawler and user alike a fast first byte regardless of origin geography — for every page that tolerates caching. The pages that do not tolerate it are, again, the stateful ones, which is why edge rendering narrows the geography question rather than eliminating it: it removes content pages from the equation and leaves transactional flows as the residual case for origin proximity.

One caution from crawl-side data: aggressive edge caching with sloppy invalidation can serve crawlers stale content for days after a publish or price change. Pair any full-page caching strategy with purge-on-publish hooks, and verify with fetch-as-Google style checks after deploys.

The decision in numbers: a worked example

Consider a store selling into Malaysia and Singapore from a US-West origin behind a CDN. Field data: 75th-percentile TTFB of 1,450ms for uncached requests, 240ms for cached. Sessions average six origin round trips (search, cart, checkout steps). Moving origin to Singapore cuts the uncached figure to roughly 420ms — a saving of about one second per dynamic request, six seconds of cumulative wait per transacting session.

Priced against conversion benchmarks — where every additional second of delay measurably suppresses conversion — the relocation typically pays for itself within a quarter for any store doing meaningful volume, before counting the Core Web Vitals improvement in field data. This is the same class of infrastructure-first win that preceded the content work in our ecommerce engagements: fix the physics, then let the content compound on top of it.

Run your own version of this arithmetic with your own numbers before deciding. The point of the exercise is not that everyone should relocate — most sites should not — but that the decision is computable from data you already have, and gut feel is the wrong tool for it.

So: does it still matter where you host?

It matters exactly as much as your dynamic traffic says it does. A brochure site behind full-page edge caching can host anywhere with a clear conscience. A content site with light interactivity should still prefer its market region but will not suffer badly for straying. A store, marketplace, SaaS app or member site — anything where the money moves through uncacheable requests — should treat origin proximity to its primary market as a first-class infrastructure decision, because no CDN tier will cache a checkout.

The reframe we push clients toward: stop asking whether location is a ranking factor and start asking what your users' slowest requests cost you. Rankings follow field data; field data follows physics plus processing; and both of those are measurable this afternoon. If the audit shows your far-market TTFB within a couple hundred milliseconds of your near-market TTFB, your setup is fine — spend the effort elsewhere. If it shows a half-second geography tax on every transaction, you have found one of the rare SEO problems that is fixed with a migration ticket rather than a content calendar.

And if you are about to act on that finding, plan the move properly — a host migration done carelessly can cost more rankings in a week than location ever did. Our step-by-step migration checklist covers the monitoring, DNS and redirect discipline that makes the move invisible to Google.

Frequently asked questions