How to Check If a Website Is Down: A Practical Step-by-Step Guide

The quickest first check is to open an incognito or private browsing window and navigate to the URL. Using a private window prevents your browser's cache from returning a stored version of the page that may not reflect the current server state. If the site loads correctly in a private window, the issue may be local browser cache or a cached error state rather than a real server problem.

Look for more than just whether the page loads. Note the URL in the address bar after the page loads — if the browser redirected to a different URL, this may be intentional or may indicate a configuration issue. Look at the padlock icon in the address bar — a warning symbol or an unlocked padlock indicates HTTPS is not working correctly. Note how long the page takes to load — a blank screen for several seconds before content appears is a response time issue even if the page eventually loads.

If the page does not load at all, note the error message: 'ERR_NAME_NOT_RESOLVED' indicates a DNS issue. 'ERR_CONNECTION_REFUSED' indicates the server is not accepting connections. 'ERR_CONNECTION_TIMED_OUT' indicates the server is not responding. Each of these points to a different underlying problem.

If a site does not load from your browser, confirm that the problem is not specific to your local network. Try loading the site on a phone using mobile data (not WiFi), or ask someone on a different network to check. If the site loads on a different network but not yours, the problem is a local network or DNS issue rather than a server problem.

This step is particularly important for agencies checking client sites remotely. Your office network, VPN, or ISP may have DNS caching, content filtering, or routing behavior that differs from what a typical visitor experiences. A site that loads fine from your office may be inaccessible from a visitor's home network, or vice versa.

An external website health check — a check run from a server outside your local network — gives you the most objective view of what a typical visitor experiences. This is different from your browser test, which uses your local network conditions.

If the site loads but shows a browser warning about an insecure connection, the most likely cause is an expired or invalid SSL certificate. In Chrome, click the padlock icon (or warning icon) in the address bar, then click 'Certificate' to see the certificate details including the expiry date. In Firefox, click the lock icon, then 'Connection Secure,' then 'More Information.'

An expired certificate causes a full-screen browser warning rather than a padlock warning — in this case, you may not reach the page at all. If you see 'Your connection is not private' or 'Warning: Potential Security Risk,' the SSL certificate is the likely cause.

A certificate warning does not always mean the certificate has expired. It can also mean the certificate was issued for a different hostname, the certificate chain is incomplete, or the certificate authority is not trusted. The certificate details panel in the browser will give you the specific issue.

Your browser test tells you whether the site loaded from your computer. An external website health check tells you what a visitor actually experiences, tested from outside your local environment. It also surfaces signals your browser does not display: the exact SSL certificate expiry date, server response time in milliseconds, specific security headers in the response, HTTP status codes, and domain risk notes.

An external check is particularly useful when: the site seems to work from your browser but visitors are reporting problems, you want to verify SSL certificate details without manually inspecting the certificate, you want to check the site's response time from outside your network, or you want a complete picture of site health rather than just whether it loads.

MonitorMojo runs this kind of combined external health check. Enter the domain, run the check, and see reachability, SSL status and expiry, response time, security headers, and domain risk signals in one result — giving you more information than a manual browser check in less time.

If the external check confirms the site is down or degraded, check for the common causes in order of frequency. First, check whether the SSL certificate has expired — this is the most common cause of unexpected HTTPS failures. Second, check the hosting provider's status page for any active incidents that might explain unavailability. Third, verify that DNS is resolving correctly — nslookup or a DNS lookup tool will show whether the domain resolves to the expected IP address.

If none of these explain the problem, check for recent changes to the site: plugin updates, hosting migrations, content changes, or configuration modifications that might have introduced the issue. Changes made within the 24 hours before the failure are a natural starting point for investigation.

If you manage the site, check the server error logs for any recent error entries that might indicate what caused the failure. If you do not have server access, contact the hosting provider's support team with the specific symptoms — the HTTP status code, the error message, and when the issue started.

After resolving the issue, run a final health check to confirm the site is fully functional: reachable, returning a 200 status code, with HTTPS active and the SSL certificate valid, and with response time back within normal range. This confirms the resolution is complete rather than partially fixed.

Document the timeline: when the issue was first detected, what investigation found, what was done to resolve it, and when the site was fully restored. This documentation is useful for client communication and for identifying patterns if similar issues occur again.

If the issue was something preventable — an SSL certificate that had been approaching expiry, a plugin update that introduced a conflict — note the preventive action that would have avoided it and add that to your monitoring workflow for future checks.