Host Check: How to Check Who Hosts a Website (and What to Do With the Answer)

To run a host check, enter the domain into a hosting checker, or look up the domain's IP address with a DNS query and find out which network owns that IP. The owner of that network is usually the hosting provider. One catch: if the site sits behind a CDN such as Cloudflare, every method shows the CDN, not the server behind it.

That answers who hosts a site. If you're checking your own site, the more useful question is whether your host is fast, up and returning the right status codes, because that is what visitors and search engines notice. This guide covers both:

• Want to know who hosts a website? Start with How to Check Who Hosts a Website.

• Got a result and not sure what it means? See How to Read Host Check Results.

• Checking your own host? Jump to Check Your Own Host: Uptime, Response Time and Server Errors.

What Is a Host Check?

A host check, also called a domain hosting check, identifies the infrastructure behind a domain: the server's IP address, the network that IP belongs to, the hosting provider, the data center's region, and often the type of hosting (shared, VPS, cloud, or a CDN in front of it).

People use the term for two different jobs:

A host check is not a WHOIS lookup. WHOIS tells you where a domain is registered, and for generic top-level domains it has been replaced by RDAP since 28 January 2025. A domain can be registered at one company and hosted at a completely different one.

How to Check Who Hosts a Website

The fastest route is an online hosting checker, sometimes called a web host checker or website host checker. The three manual methods below let you check a website's host by hand, show what the checker is doing, and help when its answer looks wrong.

The fast way: a hosting checker

1. Enter the bare domain, such as example.com, without a path or query string.

2. Run the lookup. The checker resolves the domain to an IP address and looks up who owns that IP.

3. Check the ASN and location before you trust the provider name. If the provider is Cloudflare, Fastly, Akamai or Amazon CloudFront, you've found the CDN, not the host. See When the answer is Cloudflare below.

Manual method 1: DNS lookup, then IP and ASN lookup

Every website points to an IP address through its DNS A record (AAAA for IPv6). Find that IP, then find which network it belongs to.

# Which IPv4 address does the domain point to? (macOS / Linux)
dig +short example.com A

# The same on Windows (PowerShell)
Resolve-DnsName example.com -Type A

# Who owns that IP block? Look for OrgName, netname and origin AS.
whois 203.0.113.42

Then run the IP through an IP-to-ASN lookup; Hurricane Electric's BGP Toolkit and ipinfo.io are two free options. The ASN (autonomous system number) identifies the network that routes the IP. The big clouds are easy to spot: AS16509 is Amazon, AS15169 Google, AS8075 Microsoft and AS13335 Cloudflare. Smaller hosts run their own ASN or rent space on someone else's.

Here is what the full sequence looks like. The output is illustrative and uses documentation addresses, not a real site:

$ dig +short example-shop.com A
203.0.113.42

$ whois 203.0.113.42 | grep -iE "orgname|netname|origin"
NetName:   EXAMPLE-HOSTING-NET
OrgName:   Example Hosting Ltd
OriginAS:  AS64500

The IP belongs to Example Hosting's network, so that's almost certainly the host. Field names vary between regional registries, so the lines you get may look different. For a real run on a site behind a CDN, see the vettaly.com example further down.

Manual method 2: WHOIS (RDAP) and nameservers

A domain's registration record shows the registrar, the key dates and the nameservers. It does not show the web host.

Nameservers are a hint, not an answer. ns1.examplehost.com suggests the domain's DNS is managed at that host, and many sites on shared or managed hosting keep DNS and hosting together. But DNS often runs somewhere else entirely, such as Cloudflare, Amazon Route 53 or the registrar.

# Which nameservers does the domain use?
dig +short example.com NS

Don't confuse MX records with hosting, either. They show who handles the domain's email, such as Google Workspace or Microsoft 365, which is usually a different company from the web host.

Manual method 3: read the HTTP response headers

# Fetch only the response headers
curl -sI https://example.com

Headers often name the platform serving the page:

Headers can be removed or rewritten, so treat them as clues, not proof.

When the answer is Cloudflare: CDNs hide the origin

If a site is proxied through a CDN or reverse proxy, its A record points to the CDN's edge servers, so every method above returns the CDN. The signs are an ASN that belongs to a CDN, CDN headers such as cf-ray, and nameservers like *.ns.cloudflare.com.

Here is what you can and can't conclude:

• You've learned something real. The site uses that CDN for caching, security and often DNS.

• The origin host is hidden on purpose, usually to protect it from attacks. Public tools can't reliably reveal it.

• You don't need the origin to report abuse. For sites on its CDN, Cloudflare forwards abuse complaints to both the site operator and the hosting provider.

• For your own site, the origin is listed in your CDN's DNS settings and in your hosting account.

How to Read Host Check Results

Whichever way you check a site's host, the result usually comes back with five fields. Each one tells you something specific, and each has a blind spot:

What each type of hosting looks like

• Shared hosting: the IP sits in a hosting company's own network, a reverse IP lookup shows dozens or hundreds of domains on the same address, and the nameservers are often the host's own (ns1.hostname.com).

• VPS or dedicated server: the IP is in a hosting or cloud provider's network with few or no other domains on it. Reverse DNS is usually a generic hostname from the provider.

• Cloud platforms (AWS, Google Cloud, Azure): the ASN belongs to Amazon, Google or Microsoft, and reverse DNS looks like …amazonaws.com or …bc.googleusercontent.com. This tells you the infrastructure, not who manages the site on it.

• Managed platforms (managed WordPress, Vercel, Netlify): many run on a big cloud, so the ASN shows the cloud. The platform itself shows up in the response headers or the nameservers.

• CDN in front: the ASN belongs to a CDN, and the location changes depending on where you test from.

CDN or origin? A quick test

You're looking at a CDN if any of these is true:

1. The ASN belongs to a known CDN network.

2. The headers include server: cloudflare, cf-ray, x-cache, via or another CDN header.

3. The IP's location changes when you test from different regions. Many CDNs announce the same IP from many cities (anycast).

If none of them apply, you're probably looking at the origin host. This matters for your conclusions: when the result is a CDN, its provider and location say nothing about where the real server is, or how fast it responds when a request misses the cache.

Why Hosting Matters for SEO

Your host doesn't rank your pages, but it decides how fast they're served, whether crawlers can fetch them, and how much Google is willing to crawl. Four effects are worth knowing.

1. Server response time (TTFB)

Time to First Byte is how long a browser waits for the first byte of the response. It includes redirects, the DNS lookup, connection and TLS setup, and the server's own processing time. Google's web.dev team gives 0.8 seconds or less as a rough guide for a good TTFB, measured at the 75th percentile of visits, with anything over 1.8 seconds rated poor.

TTFB isn't a Core Web Vital, but it comes before everything else on the page. A slow server pushes back First Contentful Paint and Largest Contentful Paint, and LCP is a Core Web Vital.

The host sets how fast the response starts; the page decides what happens after. That's why Vettaly's Performance rules look at what you control in the HTML itself, such as HTTPS, HTML size, render-blocking resources and image formats.

2. Server location and distance

The farther the server is from your visitors, the longer each round trip takes, and a new HTTPS connection needs several round trips before the first byte arrives.

Location matters for speed, not for which country you rank in. Google treats server location as only a weak signal of a site's target audience, and relies on country-code domains and hreflang instead.

A CDN closes most of the distance gap for cached pages, images, scripts and stylesheets. It helps much less for anything that still has to reach the origin: uncached HTML, logged-in pages, checkout and API calls.

3. Downtime, 5xx errors and rate limiting

Google sets a crawl capacity limit for every site. According to Google's crawl budget documentation, the limit rises while a site stays healthy and falls when responses slow down, the server returns 5xx errors, or it signals rate limiting with 429.

A short outage rarely leaves a mark. Errors that persist for days can drop URLs from the index; our guide to checking if a website is down covers how Google handles both cases.

Server errors also break your indexing signals. A canonical tag that points at a URL returning errors sends search engines to a dead end, which is why Vettaly's indexation rules check canonical targets and canonical chains. It's also why our crawler is rate-limited per domain: an audit should never add load to a struggling server.

4. Shared hosting and "bad neighbours"

Sharing an IP address with other sites is not a ranking problem in itself. In 2020, Google's John Mueller said he knew of no ranking algorithm that treats shared IPs that way, noting that Blogger and AWS put good and bad sites on the same infrastructure.

The real risk on cheap shared hosting is resources. When a neighbour hogs the CPU or the server is oversold, your response times and error rates suffer. Judge a shared host by its speed and uptime, not by who else is on the IP.

Check Your Own Host: Uptime, Response Time and Server Errors

When you check web hosting for your own site, the question isn't who the host is. It's whether the host is doing its job. Run through this checklist:

• Uptime: the homepage and a few deep pages return 200 from outside your network. If they don't, start with our website-down checklist.

• Response time: TTFB stays under about 0.8 seconds from where your visitors are. Search Console's Crawl stats report shows the average response time and host status as Googlebot sees them.

• HTTPS: the certificate is valid and not close to expiry. Our guide to checking if a website is safe shows how to read it.

• Redirects: http to https and www to non-www (or the reverse) each take one hop, with no chains or loops.

• Status codes: live pages return 200, removed pages 404 or 410, and planned maintenance 503 with a Retry-After header. An error page that returns 200 is a problem too.

One command covers most of it:

# Final status code, time to first byte, total time and number of redirects
curl -sL -o /dev/null -w "status %{http_code}  ttfb %{time_starttransfer}s  total %{time_total}s  redirects %{num_redirects}\n" https://example.com

Verify what your server actually sends

A hosting lookup stops at the IP address. To see what your server returns for a real page, paste the URL into Vettaly's free single-page audit. There's no sign-up: it fetches the page from our servers, records every redirect hop and the final status code, and scores the page across six categories.

Every deducted point traces back to a named rule. Some rules check what the server sends, such as performance.https for a page not served securely and performance.cache.headers for its HTTP caching headers. Others check the page itself, such as performance.render.blocking for scripts and styles that hold up rendering. That's the difference from an IP lookup: you see what to fix, not just where the server is. Vettaly analyses the raw HTML your server returns and doesn't render JavaScript.

Check every page with a full-site crawl

One page can be fine while others fail. A free account crawls up to 30 pages per audit, three audits a month, and Pro covers up to 2,000 pages per crawl. Site-level rules such as links.internal.broken and site.redirect.loop show whether a problem is one URL or a pattern across the site.

The crawler honours robots.txt and Crawl-delay, keeps to five concurrent requests per domain at most, and spaces requests 200–500 ms apart, so it won't strain the host you're testing. Vettaly isn't an uptime monitor, so pair it with one if you want alerts the minute your site goes down.

A Real Host Check: vettaly.com, Start to Finish

We ran the steps in this guide on our own site in October 2026. Here is what each step returned and what it told us.

Step 1: DNS and IP ownership

On 13 October 2026 the domain resolved to two IP addresses, and its nameservers were Cloudflare's:

$ dig +short vettaly.com A
104.21.52.11
172.67.193.234

$ dig +short vettaly.com NS
aldo.ns.cloudflare.com.
vera.ns.cloudflare.com.

ARIN's registration records place 104.21.52.11 in 104.16.0.0/12 and 172.67.193.234 in 172.64.0.0/13. Both blocks are named CLOUDFLARENET and registered to Cloudflare, Inc.

Verdict: the site sits behind Cloudflare, so the origin host is hidden. A hosting checker would report "Cloudflare" and stop there. That's correct, and it's all a public lookup can tell you.

Step 2: response time, broken down

We timed three requests to https://vettaly.com/en with curl from one location, splitting each into phases. The table shows the averages:

Verdict: a time to first byte of about 0.24 seconds is well inside web.dev's 0.8-second guide. From where we tested, the host isn't holding the site back.

The breakdown still shows where the time goes. The network was quick: a round trip to the CDN edge took about 1 ms. Almost all of the 0.24 seconds was spent waiting for the server, which is consistent with the HTML being fetched from the origin on every request rather than served from the edge cache. That ties in with the audit finding in step 3.

One more thing worth knowing: the bare domain redirects to /en, which adds a full extra request for anyone who lands on the root URL.

Step 3: the audit

A full-site Vettaly crawl of 10 pages on 9 October 2026 scored Performance at 88 out of 100. Two rules account for the whole gap:

Neither is a reason to change hosts. The render-blocking finding is one resource in each page's <head>, fixed in the page template. Cache headers are a configuration change on the server or at the CDN.

Verdict: moving to another host would have fixed none of this. The CDN was doing its job, the server answered in about a quarter of a second, and both performance deductions are fixes to the page and the configuration. That's the order to work in: check the host, break down the time, audit the page, and only then decide whether to move.

How to Choose a Hosting Provider (If the Check Shows a Problem)

Before you move, make sure the host is actually the problem. Many "slow host" complaints turn out to be slow pages, and a new host won't fix those. Match your symptom against this table:

What to compare when you do switch

• Response time from your audience's region. Test a site already running on the host, not its marketing page.

• Uptime commitment. Look for a written SLA, what it pays out, and a public status page with an incident history.

• Data center locations. Pick one near your main audience, or plan to pair the host with a CDN.

• Scaling. Find out how you add CPU, memory or workers, and whether that means downtime or a migration.

• Migration support. Free migration, staging sites, backups, and full access to DNS and server logs.

• Support. Who answers during an outage, and how quickly.

When you move, lower your DNS TTL a day or two ahead and keep the old server running until the new IP has propagated. Afterwards, run the host check again to confirm the domain resolves to the new provider, then crawl the site to catch broken redirects and pages that didn't make the trip.

Host Check FAQ

How can I tell who hosts a website?

To check website hosting, enter the domain into a hosting checker, or find its IP address with a DNS lookup (dig +short example.com) and run that IP through an IP or ASN lookup. The organisation that owns the IP block is usually the host, unless it turns out to be a CDN.

Can I find the hosting provider if the site uses Cloudflare?

Usually not. Cloudflare proxies the site's traffic, so lookups return Cloudflare's IP addresses and headers instead of the origin server's. That's by design; if you're reporting abuse, Cloudflare forwards complaints to the hosting provider for you.

How do I find the server location of a website?

Look up the site's IP address in an IP geolocation tool, which shows the country and often the city. Treat the city as approximate, and ignore the location entirely for CDN addresses, which are served from many places at once.

How do I check if a website's host is down or slow?

Test the URL with a checker that connects from several locations and note the status code and response time. 5xx codes and timeouts point to the server; a time to first byte well above 0.8 seconds means the server or the application is slow.

Does web hosting affect SEO rankings?

Indirectly. Hosting affects response time, uptime and how much Google is willing to crawl, and errors that persist for days can push pages out of the index. A shared IP address or the server's location is not a meaningful ranking factor on its own.

How do I find out who is hosting a WordPress site?

Use the same steps as for any site: the IP and ASN lookup, the nameservers and the response headers. Managed WordPress hosts often add their own header or cache identifier, and the nameservers frequently belong to the host. WordPress itself is software, not a host.

What is the difference between a host check and a WHOIS lookup?

A host check finds where a site's server is: its IP address, network, provider and location. A WHOIS or RDAP lookup finds where the domain is registered, along with registration dates and nameservers. The registrar and the host are often different companies.

Can a host check tell me who owns a website?

No. A host check identifies the infrastructure, not the person or company running the site, and most domain registration records hide the owner's details for privacy. For legal or abuse issues, contact the registrar or the host through their abuse channels.