How to Find Out Who Hosts a Website, and What 69 Real Sites Showed When I Checked

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

You can usually find out who hosts a website with four free checks: who owns the IP address it resolves to, which nameservers it uses, what its response headers say, and what platform code its page source carries. No single check works on every site. When I ran all four on 69 well-known sites on 19 October 2026, a network such as Cloudflare, Fastly, Akamai or Amazon CloudFront sat in front of 48 of the 68 that resolved, and the plain IP lookup named the real operator on only 12.

This guide shows what each check can and cannot see, with the numbers from that survey, a test on two sites where I already know the answer, and the exact commands to run yourself.

The four clues, and what each one can actually see

Every website answers a few public questions whenever a browser loads it. Each answer leaks a different piece of the hosting picture:

• The IP address owner. Look up the address the domain resolves to, and the registry says which organisation announces that address range. On a host that serves its own customers directly, this names the host. When a proxy or content delivery network (CDN) sits in front, it names the proxy instead.
• The nameservers. These are the servers that answer DNS questions for the domain. Many hosts hand their customers nameservers carrying the host’s own name, which is the clearest tell there is. Many sites instead use a general DNS service, which says nothing about the host.
• The response headers. Before the page itself, the server sends headers. Some name the software, some name the platform, and some are added by a specific host’s caching layer.
• The page source. The HTML often carries the fingerprint of the platform that built it, such as Shopify’s cdn.shopify.com files or WordPress’s /wp-content/ folder. That tells you the software, and for an all-in-one platform like Shopify, the software is the host.

Two lookups that people reach for first do not answer the question. A WHOIS or RDAP record shows the registrar, the company that sold or manages the domain name, not the company that stores the site. ICANN’s own lookup at lookup.icann.org reports registration data, and a domain bought from one company often runs on another. Likewise, the MX records say who handles the domain’s email, which can be a third company entirely. My guide to MX records covers that side.

What 69 real sites gave away

I took 69 domains: online stores built on Shopify, WordPress properties and hosting companies, news and open-source projects, and well-known software-as-a-service tools. For each one I recorded the first IP address from Google’s public DNS service, the owner of that address from ipinfo.io, the nameservers, the headers of a request to the home page, and the platform markers in the page source. One domain, hismile.com, had no address record at its bare name, so 68 resolved. This sample skews toward large, well-resourced sites, so treat the shares as a picture of popular sites, not of the average small-business site.

What the checks showed	Sites
IP owner named the real host or operator (Automattic, Wikimedia, GitHub, Squarespace, Wix and similar)	12
A CDN was in front, but a header or the page source still named the platform	20
IP owner was only a general cloud provider (Amazon or Google)	8
A CDN was in front and none of the four checks named an operator	28
Did not resolve	1

Behind the 48 CDN-fronted sites: 35 resolved to Cloudflare addresses, 5 to Fastly (the New York Times, the BBC and the Guardian among them), 3 to Akamai, and 5 to Amazon CloudFront. Across all 69, 36 answered with a Server: cloudflare header, and 15 used Cloudflare’s nameservers.

The 20 that were still identifiable are worth a look, because they show which clues survive a CDN:

• Shopify’s page source. Sixteen sites carried Shopify’s code: shopify.com and 15 of the stores. Fifteen of those 16 resolved to Cloudflare addresses in the 23.227.38.x block, so without the page-source check a Shopify store and any other Cloudflare site look the same. These 15 make up most of the 20.
• Platform headers. elementor.com sent x-powered-by: Elementor Cloud, wpengine.com sent WP Engine Headless Platform, mailgun.com sent WP Engine, and kinsta.com carried an x-kinsta-cache header. nodejs.org sent an x-vercel-id header while sitting behind Cloudflare. woocommerce.com sent x-powered-by: WordPress VIP, and its IP owner was Automattic, so it was already counted in the first row.
• A headless storefront. huel.com resolved to an Amazon address, answered with Server: Vercel, and carried Shopify code in its page. The store runs on Shopify but the pages are served from Vercel, so the honest answer to “who hosts it” has two parts.

The nameserver check was the weakest on this sample. In 52 of 69 cases the nameservers belonged to a general DNS service such as Cloudflare, Amazon Route 53, GoDaddy’s DNS, NS1, Akamai, Azure or Google, or to a domain-security registrar’s DNS, which says nothing about where the site lives. The ones that did name an operator were hosting companies and platforms describing themselves: hostinger.com, siteground.com, wordpress.com, woocommerce.com and squarespace.com. That is a bias of my sample. A small site on shared hosting is far more likely to use its host’s own nameservers than a large company is.

Why a CDN hides the host, and how much it really hides

A CDN or reverse proxy answers visitors on behalf of the real server. Cloudflare’s documentation says it plainly: for a proxied record, DNS lookups return Cloudflare IP addresses instead of the record’s actual target, and traffic passes through Cloudflare before it reaches the origin server (see Cloudflare’s proxy status page). That is the design working as intended, not a flaw. A site owner can switch the record to DNS only, which makes Cloudflare answer with the real address, but then loses the proxy’s protection.

The practical rule: when the IP owner is Cloudflare, Fastly, Akamai or CloudFront, stop trusting the IP check and move to the other three. When all four come back empty, the host is genuinely not discoverable from outside, and no website hosting checker can do better than the clues above. The free tools, such as Geekflare’s hosting checker and nslookup.io’s, run the same lookups I did and hit the same wall.

A test on two sites where I already know the answer

The fairest test of a method is a site where the truth is known. This site and its sister site repairpicks.com both run on Hostinger, so I ran the same four checks on both on 19 October 2026:

• IP owner: both addresses belong to AS47583, Hostinger International Limited. Correct.
• Nameservers: ns1.dns-parking.com and ns2.dns-parking.com for this site, cosmos.dns-parking.com and nova.dns-parking.com for the other. The domain does not say Hostinger, but the start-of-authority record for dns-parking.com lists dns.hostinger.com as its contact, and Hostinger’s own support documentation says nameservers in the dns-parking.com format mean Hostinger manages the DNS zone. Correct, with one extra lookup.
• Headers: platform: hostinger, panel: hpanel and server: hcdn on both. Correct and explicit. The page also announces x-powered-by: PHP/8.3.35, which is the PHP version, a detail covered in my guide to checking your WordPress PHP version.
• Page source: WordPress markers, which names the software, not the host.

Three of the four checks agree, and the fourth is honest about what it measures. That is the typical result for a site on a shared host that has no third-party CDN in front. It is also why the same checks fail so often on the big sites in the survey: those sites put their own layer in front.

Run the four checks yourself

Everything below uses tools that ship with Windows, macOS or Linux, plus one free web lookup.

1. Find the IP address. On any system, run nslookup example.com. On macOS or Linux, dig +short example.com prints just the addresses. Note the first one.
2. Look up who owns it. Open https://ipinfo.io/ followed by the address. The “org” line gives the ASN and the organisation, for example “AS47583 Hostinger International Limited”. If it says Cloudflare, Fastly, Akamai or Amazon with a CloudFront header, go on to step 3.
3. Check the nameservers. Run nslookup -type=NS example.com or dig +short NS example.com. A name containing a hosting company’s brand is a strong clue. Cloudflare, Route 53 or the registrar’s own DNS is not.
4. Read the headers. On macOS and Linux run curl -sI https://example.com. On Windows use curl.exe -sI https://example.com. Look for server, x-powered-by, platform, via and any header carrying a host or platform name, such as x-kinsta-cache or x-vercel-id.
5. Search the page source. In a browser, open view-source:https://example.com and search for cdn.shopify.com, wixstatic.com, squarespace and /wp-content/. Platform fingerprints often settle a question the network clues leave open.

Read the answers together, not one at a time. In my survey the IP lookup alone named the operator for 12 of the 68 resolving sites. Adding headers and page source raised that to 32, and to 40 if you count the 8 where only Amazon or Google appeared. Hosting companies show the gap well: for siteground.com, the site of SiteGround, the IP lookup said Google, while the nameservers, ns3.siteground.com and ns4.siteground.com, named the company itself. That is why one clue is never enough.

Registrar, web host and email host are three different questions

Before you act on an answer, make sure it is the right one. The company that sold you the domain name may not host the site. The company that hosts the site may not run the email. If you are looking for the right dashboard to log in to, the registrar from an RDAP lookup is where you change nameservers, the web host is where the files and database live, and the MX provider is where mailboxes are managed. A common mistake when moving a site is changing the web records and forgetting the email ones. If you are moving, the files and database are covered in my backup restore guide, and the email records in the MX guide.

If you own the site you are investigating, there is a shorter route than any of this: the host’s name is on your billing emails and in your hosting control panel. The checks above are for the cases where you do not have access, such as a site you inherited, a competitor, or a client whose old login is lost.

What to do when the host stays hidden

If all four checks come back empty, you can still reach someone. Contact the site owner through the site’s contact page, and ask. If you are reporting abuse, most CDNs and registrars publish an abuse contact, and a report to them is the usual route when the host itself is hidden. For a site you are about to take over, ask the previous owner for a hosting export or a login, not a guess from the outside. Guessing is also risky because a wrong answer can send you changing records at the wrong company.

Checked for accuracy on 19 October 2026. The 69-site survey used dns.google for IP and nameserver records, ipinfo.io for the IP owner, one HTTP HEAD request and one page fetch per site from the Netherlands, and my own classification of the results. Content delivery networks can answer differently by location and time, so another run can give slightly different counts.