Check any website or URL for DNS, connectivity, HTTP, SSL, redirects, latency, security headers, compression, and other common configuration issues — all in one pass. Run Website Health Check to try it against any domain or URL.
What Does Website Health Check Do?
NetSH Website Health Check runs a series of network and web diagnostics against the URL you provide. Instead of simply telling you whether a server responded, it examines the different layers involved in reaching and serving a website and highlights issues that may need attention.
You can enter either a bare domain, such as example.com, or a full URL, such as https://example.com/some-page. When a full URL is supplied, NetSH checks that exact URL — not just the domain it belongs to.
Checks Performed
- Domain / Target — the domain or exact URL being checked.
- IP Address — the public IP address returned by DNS.
- Location — the approximate location associated with the resolved public IP.
- Organization — the organization associated with the resolved IP.
- Ping — ICMP reachability, where supported. A failed ping does not necessarily mean a website is down, since ICMP is commonly blocked — see below.
- Latency — response timing and, where available, individual connection phases (DNS, TCP, TLS).
- HTTP Response — the HTTP response and status code returned by the requested URL.
- Redirects — the redirect chain, with problematic patterns (such as a drop from HTTPS to HTTP) flagged.
- SSL Certificate — the HTTPS certificate's validity and expiry.
- Security Headers — presence of common HTTP security headers.
- HTTP Protocol — support for modern protocols such as HTTP/2, where available.
- Compression — whether the response uses compression such as gzip or Brotli.
- Ports — whether common web ports, 80 and 443, are open.
URL vs. Domain Behavior
When a full URL is entered — for example, https://example.com/products/widget — NetSH distinguishes between checks that operate on that exact URL and checks that operate on the underlying domain:
- URL-level checks use the exact URL supplied: HTTP status, redirects, response timing, compression, HTTP protocol, and other response-related checks.
- Domain/infrastructure checks use the underlying hostname: DNS, IP address, location, organization, SSL certificate, and ports.
This distinction is a core part of how NetSH works, and it is reported accurately rather than collapsed into a single, less precise result.
Why a Failed Ping Doesn't Mean a Website Is Down
Ping uses ICMP, while websites normally use HTTP or HTTPS. Many servers, CDNs, firewalls, and cloud providers intentionally block ICMP while continuing to serve web traffic normally. A failed ping therefore does not automatically mean the website is down — the HTTP Response check is a more direct signal of whether the site itself is reachable.
Why the IP Might Belong to Cloudflare or a CDN
Websites behind Cloudflare or another CDN may resolve to the CDN's public edge IP rather than the origin server's IP. NetSH reports the public infrastructure it can actually reach — the IP, location, and organization shown may therefore belong to Cloudflare, a CDN, or another reverse proxy rather than the website's origin server. NetSH does not attempt to discover or bypass the origin server behind a CDN.
How NetSH Identifies Itself
Website Health Check performs server-side HTTP requests to the URL you provide. NetSH identifies these requests using the following User-Agent:
NetSH/1.0 (+https://netsh.io/website-health)This allows website owners and network administrators to identify NetSH requests in server, CDN, firewall, and WAF logs. NetSH does not impersonate a web browser, Googlebot, or another third-party crawler — the checker identifies itself transparently as NetSH.
Why Might NetSH Receive a 403?
Some websites use WAFs, bot protection, access policies, rate limiting, IP reputation systems, or application rules that may block automated requests. A 403 response means the request was denied; it does not by itself prove that a specific WAF rule caused the block. NetSH cannot determine the exact internal reason for every 403 from the public HTTP response alone.
What NetSH Does Not Do
- Does not require login to the target website.
- Does not attempt to bypass authentication.
- Does not execute arbitrary JavaScript in the target website.
- Does not attempt to discover private origin infrastructure.
- Does not bypass WAF or bot protection.
- Does not impersonate Googlebot.
- Does not impersonate a web browser.
- Performs diagnostics only against the publicly supplied target.
Frequently Asked Questions
Can I check a specific page instead of just a domain?
Yes. Enter the complete URL and NetSH checks that URL.
Can NetSH tell me whether a website is down?
It can determine whether the requested URL is reachable from NetSH's infrastructure and explain the network/HTTP result, but one failed check does not prove global unavailability.
Why does ping fail while HTTP works?
Because ICMP is often blocked while HTTP/HTTPS remains available.
Why does the IP belong to Cloudflare?
Because the site may be behind Cloudflare's proxy/CDN.
Does NetSH check the origin server?
No. It checks publicly reachable infrastructure and does not attempt to bypass CDNs or reverse proxies.
Why did a website return 403?
A WAF, bot protection, access policy, rate limit, IP reputation system, or application rule may have denied the request. NetSH cannot always identify the exact rule.
Related tools: DNS Lookup, Ping, SSL Certificate Checker, HTTP Headers Checker, and Port Checker each run one of these checks on its own, with more detail on that specific layer.
Run the Website Health Check now against any domain or URL.