A website that “does not open” can be failing at several different layers. The domain may be expired, DNS may point to the wrong server, the host may be offline, the web server may be misconfigured, the application may be failing, or the TLS certificate may be invalid. The browser message provides the first useful clue.
Record the exact symptom and affected URL
Test the full URL, including whether it uses the www hostname. Record the browser error, HTTP status code if available, and whether the site fails on several networks. A local office DNS or proxy problem can affect one location while the public website remains healthy.
Different messages point to different layers: a name-resolution error suggests DNS, a timeout suggests routing or server availability, a certificate warning suggests TLS, and a 500-series response suggests the web server or application.
Domain registration and DNS checks
Confirm that the domain registration is active and that the authoritative nameservers are correct. Then compare public A, AAAA and CNAME records with the intended hosting configuration.
Recent changes may still be cached, but “propagation” should not be used as a catch-all explanation. Check the record returned by several independent resolvers and confirm its TTL. Also check whether an obsolete IPv6 record sends some visitors to the wrong server.
Hosting, firewall and web-server checks
If DNS points to the expected address, verify that the server is reachable and the web service is running. Check disk space, memory pressure, recent restarts, firewall rules, cloud security groups and provider status.
For Nginx or Apache, review configuration tests and error logs before restarting repeatedly. Confirm that the requested hostname matches the intended virtual host and that redirects do not create a loop between HTTP, HTTPS, www and non-www versions.
TLS and SSL certificate problems
An expired certificate, missing intermediate certificate, hostname mismatch or incorrect server block can create a privacy warning even when the website application is running.
Confirm the certificate dates, covered hostnames and complete chain. If a CDN or reverse proxy is used, check both the public edge certificate and the connection between the proxy and origin server. Renewing one certificate does not fix a different certificate presented by another endpoint.
Application and database errors
A working web server may still return a blank page or 500 error because of application code, a failed database connection, missing environment variables, file permissions or an incompatible update.
Review recent deployments and logs. If the failure began immediately after a change, prefer a controlled rollback over several untracked fixes. Take a backup before database or file changes.
A safe response process for website outages
- Record the exact URL, error, time and affected networks.
- Confirm domain registration and public DNS.
- Check hosting availability, resource usage and web-server status.
- Inspect the certificate and redirect chain.
- Review application and database logs.
- Document the cause and preventive follow-up.
Avoid changing DNS, server configuration and application code at the same time. One controlled change at a time makes rollback possible and preserves the evidence needed to find the real cause.
Need help with this issue?
Email a short description, your location, and any screenshots or error messages. We will help identify the most sensible next step.