Hosting and SEO: how to choose a fast server

The hosting and SEO relationship is badly explained: no provider will lift your rankings on its own, but a slow server or one returning 5xx errors can throttle Google's crawling and wreck your Core Web Vitals.

Here you will see what hosting really decides, what Google's crawlers support, how to measure it with tools you already have, and a 12-point checklist to buy or migrate without surprises.

What hosting and SEO actually decide in the results (and what they do not)

What does not matter: the provider, the brand and the plan type are not ranking factors. Google does nothing special for sites hosted on its own cloud, and shared hosting is not penalised by itself.

What does matter are four measurable vectors:

Availability: 5xx, 429 and timeouts. A server that is down during a crawl window is traffic that never gets discovered.
Response time: TTFB drags down LCP, and with it every Core Web Vital.
Ability to serve bytes: if the server is struggling, Google crawls less.
Caching and protocols: how the HTML Google downloads is delivered (ETag, compression, HTTP/2).

Server location does not geotarget you

Moving your server to another country to rank there is a myth: the physical location is not used for geotargeting. For that you use a country-code domain or the country setting in Search Console (see the multilingual website guide).

What does show up is latency, which feeds page experience and is fixed with a CDN in front. When Google detects a hosting change it slows crawling as a precaution and recovers afterwards: a temporary brake, not a penalty.

Uptime: 5xx, 429 and why Google crawls you less

5xx and 429 errors slow crawling down, because Google reads them as your infrastructure struggling. Already-indexed URLs are kept at first, but they end up being dropped if the error persists; once the server answers 2xx again, crawl frequency climbs gradually. With a 500 error, the drop is proportional to the number of affected URLs.

The Crawl Stats report in Search Console summarises the last 90 days of availability through host status, though it only exists on root-level properties. Returning 500 or 503 to slow Google down is an emergency measure: it affects the whole hostname and should not last more than a day or two.

Over 30 days, 99.9% uptime equals about 43 minutes down per month, 99.95% about 22 minutes and 99.99% about 4. With those figures, external monitoring with alerts stops being a luxury.

Response time: the two numbers worth memorising

Two numbers to memorise: 600 ms, the threshold in Lighthouse's server response time audit, and 0.8 seconds, the TTFB guidance from web.dev for most sites, measured at the 75th percentile (above 1.8 s it is considered poor).

This is pure SEO: TTFB is the foundation of LCP (official threshold 2.5 s) and with a slow server no image optimisation will save you, because the bottleneck is at the origin. The full breakdown is in the TTFB guide.

Which server resources to check before you buy

CPU and workers: plans with strict limits run out of processes at peak times and start answering 503.
RAM and object cache: without memory, every visit hits the database.
Disk: NVMe or SSD with enough IOPS; a saturated disk shows up in the TTFB of dynamic pages.
Database: if it shares the server it competes for the same resources; splitting it out is one of the most profitable upgrades.
Scaling: pick the plan that handles twice your peak, not the one that handles your average.

Caching: the cheapest lever to bring TTFB down

Three layers, from highest to lowest impact: full-page caching at the origin (the visitor gets pre-generated HTML and the application does not run), an object cache for repeated queries, and OPcache, which stops the code being recompiled on every request. The first one is the difference between 40 ms and 600 ms of TTFB.

A little-known official detail: Google only supports HTTP caching through ETag with If-None-Match and Last-Modified with If-Modified-Since, and it recommends ETag because it carries no date formatting issues. A correct 304 saves bandwidth on every re-crawl, and matching Cache-Control: max-age to how often a page really changes helps decide when to come back.

Protocols and compression: what Googlebot really supports

Google's crawlers support HTTP/1.1 and HTTP/2 and use HTTP/1.1 by default. Crawling over HTTP/2 saves your server CPU and RAM, but brings no ranking advantage; if something breaks you can return 421 to ask not to be crawled over that version. HTTP/3 is great for real users, but it is not on the list of protocols the crawlers support. On compression they accept gzip, deflate and Brotli, so serving HTML uncompressed is giving away response time.

You can check it from the terminal, with nothing to install:

curl -sI https://your-domain.com | head -20 shows the protocol version, the content-encoding and the etag.
curl -sI --http2 https://your-domain.com confirms HTTP/2 is negotiated.
If there is no content-encoding, your server is not compressing the HTML.

The 2 MB limit: why your HTML should weigh far less

Googlebot downloads only the first 2 MB of each HTML URL, and that cut includes the HTTP headers. For PDFs the limit is 64 MB and the default for other crawlers is 15 MB. Whatever falls below the cut is not fetched, not rendered and not indexed.

Hence the golden rule: put what matters at the top. Title, metas, canonical and structured data belong in the head, not pushed down by hundreds of kilobytes of inline CSS or base64 images. Moving that weight to external files helps twice over, because every resource has its own byte budget.

How to tell whether your hosting is slowing you down (no paid tools)

Search Console: in Crawl Stats, look at average response time, host status and the responses table. If response time climbs while requests fall, the problem is infrastructure.
Server logs: separate Googlebot requests by status and duration and verify the IPs with reverse DNS, as explained in the log analysis guide.
PageSpeed Insights: if the diagnosis points at server response time while the other opportunities look fine, the bottleneck is hosting.
Typical symptoms: high TTFB only on dynamic pages points to a slow database; spikes at the same time every day point to backups eating disk; intermittent 502 and 503 at peaks point to the plan's worker limit.
Decision threshold: if TTFB is still above 0.8 s at the 75th percentile with page caching on, the plan has become too small. Upgrade before changing providers.

A fast, error-free server is, in the end, the cheapest way to make better use of your crawl budget.

Checklist: 12 points before you buy or migrate

Publishable historical uptime and a written service level agreement.
TTFB measurable from your target region before you pay.
HTTP/2 and TLS 1.3 enabled; HTTP/3 as a bonus for users.
Brotli or gzip compression at server level.
The ability to enable full-page caching at the origin.
OPcache and an object cache included in the plan.
Explicit resources: CPU, RAM, IOPS and workers.
Vertical scaling: add CPU or RAM without migrating servers.
Log access with enough retention.
Automatic backups and a tested restore.
External uptime and latency monitoring with alerts.
Migration plan: dedicated IP, low DNS TTL on the day of the switch and no changes to URLs or redirects in the same move.

Conclusion: boring hosting, healthy SEO

Three ideas to take away. The provider is not a ranking factor, but availability, TTFB and the ability to serve bytes do have consequences, because Google reduces crawling when the server struggles. Caching is the cheapest improvement.

The next step costs nothing: check average response time and host status in Search Console today. If TTFB is above 0.8 seconds at the 75th percentile, enable page caching before changing providers.