The four variables, and the ones that don't exist
"Does hosting affect SEO" is usually a vague worry answered with a vague yes. Narrowed down, it's four measurable things — each with a free test and a threshold you can check this afternoon.
- Not a thing: your hosting brand. No ranking bonus comes with a premium logo on the invoice.
- Not a thing: a dedicated IP as a ranking factor. Useful for email. Irrelevant to search.
- Not a thing: "SEO hosting" selling C-class IP diversity for link networks — a product built for a tactic Google has penalised for a decade.
| Variable | How it reaches rankings | Free test | Bad number |
|---|---|---|---|
| Server response time (TTFB) | Directly feeds LCP, and a slow server makes Googlebot crawl less | PageSpeed Insights, Search Console crawl stats, DevTools Network tab | Over 600ms flagged; over 1s is costing you |
| Uptime | Sustained 5xx errors get URLs dropped from the index | Any free uptime monitor on a five-minute check | Below 99.9%, or any outage over a few hours |
| Shared IP neighbours | Resource contention and server-level compromises, not reputation | Reverse-IP lookup, plus Search Console Security Issues | Malware on the box, or CPU throttling in your host panel |
| Server location | Network latency to your audience. A weak geotargeting hint at best | Test TTFB from a location matching your customers | Over 200ms of pure round-trip before anything renders |
Server response time: the one that actually costs you
Time to first byte is how long the server takes to start sending the page after the browser asks. It's the variable cheap hosting fails first.
It matters more than it sounds because TTFB is *inside* Largest Contentful Paint, not next to it. The LCP clock starts at navigation. If your server takes 1.2 seconds to answer, you've spent half the 2.5-second "good" budget before a byte of HTML arrives, and image compression can't buy it back. That's the link between your hosting bill and your Core Web Vitals.
Three ways to measure it, all free
- PageSpeed Insights. Look for the "Reduce initial server response time" audit — Google fails it above 600ms. One lab test from one location, so treat it as a smoke alarm rather than a measurement.
- Search Console → Settings → Crawl stats. The "Average response time" figure is Googlebot's own measurement across every URL it fetched, over months. The most representative number you'll ever get about your host, and almost nobody looks at it. The Host status panel in the same report flags connectivity failures.
- Chrome DevTools → Network tab. Click the document request, open Timing, read "Waiting for server response". Append a query string so you're testing the server, not a cache.
What the numbers mean
- Under 200ms — genuinely fast. Usually real caching and a nearby server.
- 200–500ms — fine. Leave it and go fix something else.
- 500–800ms — you're eating LCP budget and Google's audit is about to fail you.
- Over 1s, consistently — now your biggest technical problem, ahead of anything in the content plan. Google reduces crawl rate for slow or erroring servers, so it compounds: slow server, less crawling, slower discovery of everything you publish.
Uptime: what Google actually does when your site is down
Google handles short outages far more gracefully than most people fear. A brief run of 5xx responses gets retried, and Googlebot temporarily slows its crawl rate rather than punishing you. Rankings don't evaporate because your host had a bad twenty minutes.
Sustained downtime is different. Days of server errors will eventually see URLs dropped from the index, and they come back slower than they left. For planned maintenance, return a 503 with a Retry-After header — that tells Google this is temporary. The common mistake is a holding page returning a 200, which tells Google your page is now a holding page.
Set a free uptime monitor on a five-minute check and forget it. The arithmetic: 99.9% uptime is about 43 minutes down a month, which is fine. 99% is about seven hours, which is not.
Server location versus a CDN
Two questions get tangled here: latency and geotargeting.
Latency is physics. A user in Chennai hitting a server in Virginia pays for the round trip — typically 200ms or more — several times over before the first byte arrives. If your customers are Indian, a server in India or Singapore removes it.
Geotargeting is mostly not about the server. Google works out who a page is for from your ccTLD, hreflang, language and content. Server location is a weak hint at best. A .in domain hosted in Frankfurt isn't confused about which country it serves; it's just slow.
A CDN sits between the two. It genuinely fixes images, CSS and JavaScript from a nearby edge. It does not fix a slow dynamic response unless you turn on full-page caching at the edge, which most people never do — which is why sites add a CDN, see no TTFB change, and conclude CDNs don't work.
Rule of thumb: Indian audience, host in India or Singapore. Mixed or overseas, host near your largest market and put a CDN with full-page caching in front.
What a ₹99-a-month plan cuts to hit that price
Budget hosting isn't a scam. It's a set of engineering trade-offs, perfectly sensible for one kind of site and quietly ruinous for another. Here's what gets traded.
- Density. Hundreds of accounts on one machine. Every resource you use is one somebody else isn't.
- Hard limits. CPU, memory and concurrent-process caps. Hit them and requests don't fail with a clear error — they queue. That queue is your TTFB.
- Slower storage. Older SATA disks rather than NVMe, which shows up immediately on database-heavy WordPress queries.
- No server-level caching. No object cache, no full-page cache before PHP starts. A plugin cache helps, but it's doing in PHP what a proper stack does earlier.
- "Unlimited" bandwidth with a fair-use clause that throttles you exactly when a page takes off.
When to move host, and how to move without losing rankings
Move when Search Console's average response time sits above roughly 800ms and your host can't explain why, when neighbours are visibly costing you resources, or when you're serving Indian traffic from a distant continent for no reason. Don't move because a review site scored someone higher.
A host move is not a migration. Your URLs, protocol and structure shouldn't change at all — which makes it far lower-risk than a genuine site migration. Follow this order and the risk is close to zero.
- Baseline first. Current TTFB, Search Console average response time, Core Web Vitals field data, rankings for your tracked queries. Without this you'll never know if the move helped.
- Copy, don't cut. Stand the site up on the new host and test via a hosts-file entry or a hostname behind HTTP auth — never a public staging URL that can get indexed.
- Drop DNS TTL to 300 seconds a day or two before the switch, so cutover takes minutes rather than hours.
- Keep the old server serving for at least 72 hours after you flip DNS. Propagation is uneven and some visitors still land on the old box.
- Check status codes on your top 100 URLs right after cutover, plus the SSL certificate and — critically — that
robots.txtis the production file. - Watch crawl stats for two weeks. If average response time hasn't improved, you moved for nothing, and it's worth saying so out loud.