Server location is not a definitive ranking signal, in Google's own words. Time to first byte is not a Core Web Vital. Two hosting claims, both qualified.
“Not a definitive signal” is Google’s own phrasing about server location. It appears one sentence after the line hosting salespeople quote, and it is the more useful half.
Hosting decisions get made on two arguments, geography and speed, and the documentation qualifies both. That does not make hosting unimportant. It makes it important for different reasons than the ones on the pricing page.
This page sets out what the documentation says about location and response time, then what hosting genuinely determines.
Server location, in full
The two sentences belong together, and they are usually separated.
The part that gets quoted, verbatim. The server location is often physically near your users and can be a signal about your site’s intended audience.
The part that follows, verbatim. Some websites use distributed content delivery networks or are hosted in a country with better webserver infrastructure, so it is not a definitive signal.
What Google says it uses instead. Country-code top-level domain names. hreflang statements, whether in tags, headers or sitemaps. And other signals including local addresses and phone numbers on the pages, the use of local language and currency, and links from other local sites.
One more line worth knowing. Google states that it does not attempt to vary the crawler source used for a single site in order to find possible variations in a page.
What that rules out. Serving different content based on where the crawler appears to be. It will not see the variations, and building a strategy around that is building on something the documentation says does not happen.
The practical consequence for a B2B firm selling internationally. Your hreflang implementation, your ccTLD choice and the local signals on your pages do more for geographic targeting than which data centre you rent. Those are cheaper to fix, too.
Time to first byte, and why it is not a Core Web Vital
The other hosting argument is speed, and here the documentation is precise in a way that cuts both directions.
The published guide, verbatim. As a rough guide, most sites should strive to have a TTFB of 0.8 seconds or less. Good values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.
The qualification, verbatim. Because TTFB is not a Core Web Vitals metric, it is not absolutely necessary that sites meet the good TTFB threshold, provided that it does not impede their ability to score well on the metrics that matter. Which is why the thresholds are described as a rough guide.
Why it still matters. Time to first byte is the floor under largest contentful paint. Every millisecond the server spends before sending anything is a millisecond the 2.5-second budget has already lost.
And why better hosting often does not fix the metric. On most B2B sites, largest contentful paint is broken by an unoptimised hero image, a webfont blocking the headline, or third-party scripts. A faster server shortens the first step of a chain whose later steps are the problem.
The diagnostic that settles it. Compare your time to first byte against your largest contentful paint. If TTFB is 0.4 seconds and LCP is 4 seconds, hosting is not your issue and buying more of it will not help.
When hosting genuinely is the issue. TTFB above 1.8 seconds, or a TTFB that climbs sharply under traffic, which is the failure mode shared hosting produces and synthetic tests never show.
Hosting owns the first segment of a chain. Knowing the segments tells you whether buying more of it will help.
Segment one: the server. Time to first byte. Everything before a single byte reaches the browser. This is the part hosting owns, and the guide is 0.8 seconds.
Segment two: the blocking resources. Stylesheets, fonts and any script that blocks rendering. On a B2B site this is frequently longer than the server segment, and it is entirely under your control.
Segment three: the largest element itself. Usually a hero image. Whether it is correctly sized, in a modern format, and given priority.
Segment four: layout stability. Not part of the 2.5 seconds, but the same causes. Images without declared dimensions, banners injected late.
The arithmetic that decides your spend. If your budget is 2.5 seconds and the server takes 0.4, moving to a faster host might recover 0.2. If your hero image takes 2 seconds, optimising it recovers ten times more for no monthly cost.
Which is the common case. On most B2B sites the server is not the bottleneck. The bottleneck is a 3 MB header image and a font that blocks the headline.
When the diagnosis reverses. Database-driven pages, heavy plugin stacks, and any site where TTFB varies wildly between visits. There the server genuinely is the problem, and it usually shows as inconsistency rather than as a high average.
Six things, none of which is a ranking factor, all of which cost you money when they fail.
Whether the site is up. The unglamorous one. Availability is the only hosting property whose failure is total, and the only one your customers notice within minutes.
Response time under load. Not response time on a quiet Tuesday. What happens when a campaign, a newsletter and a conference all land in the same hour. This is where shared hosting fails and where synthetic tests never look.
Whether backups restore. Everyone has backups. Far fewer have restored one. A backup you have never tested is a belief, not a safeguard.
Whether a staging environment exists. The difference between testing a change and discovering it in production. This is a hosting decision more often than a budget one.
How quickly a human responds. At 2am on the day your certificate expires, the response time that matters is the support desk’s, not the server’s.
What it costs to leave. Proprietary caching layers, custom build steps and undocumented configurations are exit costs. They do not appear on the pricing page and they arrive on the day you want to move.
Changing hosting is a documented, mild case
Worth stating because it is often treated as risky and the guidance is reassuring.
Its own category. The documentation covers a change in hosting infrastructure, meaning switching hosting providers or moving to a content delivery network, and applies only to migrations that do not affect the user-visible URL.
The steps. Prepare the infrastructure, change the DNS, monitor traffic, decommission the old setup.
Which step is the move. The documentation identifies the DNS change as the actual site move step.
What is absent. Redirects. There is nothing to redirect, because nothing about your addresses changed.
What that means for the risk conversation. A hosting change is not a migration in the sense that a URL change is. The main real risks are configuration drift, a missed redirect rule that existed on the old server, and TLS certificate handling at cutover.
The one thing to check that people forget. That your old server stops answering. Two servers serving the same site during a DNS propagation window is how inconsistent behaviour appears and disappears for two days.
No redirects, because nothing moved. But make sure the old server actually stops answering. Source : Google hosting change guidance (2026)
How to choose, and how to test the claim
Six checks, all of which you can run before signing anything.
Test response time under load, not at rest. Ask the provider for a load test, or run one against a trial instance. Rested response time is the number everyone advertises and nobody experiences.
Ask what a restore takes, in hours. Not whether backups exist. How long a full restore takes, who performs it, and when they last did one.
Confirm the staging environment is included. If it costs extra, budget it. Testing in production is more expensive.
Check TLS certificate handling. Automatic renewal, and what happens if it fails. Expired certificates take sites down completely and predictably.
Ask what leaving involves. If nobody can answer clearly, that is the answer.
And do not buy geography you do not need. If you sell internationally, spend on hreflang and a content delivery network rather than on a data centre in each market. Google says location is not a definitive signal, and names what it uses instead.
Does my server need to be in the country I sell to?
Google says server location can be a signal about your intended audience but qualifies that it is not a definitive signal, because sites use content delivery networks or host where infrastructure is better.
What does Google use instead?
Country code top-level domains, hreflang statements in tags, headers or sitemaps, and other signals including local addresses and phone numbers on the pages, local language and currency, and links from other local sites.
Does Google crawl from different countries to check?
It states that it does not attempt to vary the crawler source used for a single site in order to find possible variations in a page. So geo-varying your content by crawler location is not a strategy.
What is a good time to first byte?
Most sites should strive for 0.8 seconds or less, with poor values above 1.8 seconds. But it is not a Core Web Vital, and the documentation calls those thresholds a rough guide.
So is TTFB not important?
It is the foundation of largest contentful paint, so a slow server makes the metric that does count harder to hit. The documentation just declines to make it a requirement in its own right.
Will better hosting fix my Core Web Vitals?
Partly at best. Hosting affects the first byte. What usually breaks largest contentful paint on a B2B site is an unoptimised hero image, a blocking font, or third-party scripts, none of which a faster server fixes.
Is changing hosting risky for SEO?
It is a documented category of move, but a mild one: the guidance covers only migrations that do not change addresses, identifies the DNS change as the move itself, and involves no redirects at all.
What should I actually pay for?
Response time under load, backups you have tested restoring, a staging environment, and someone who answers when it breaks. None of those is a ranking factor and all of them are why hosting matters.