Website Not Loading: DNS, SSL and HTTP Checks

First record which URL fails and who is affected

'The website is not loading' is not a single type of error. The domain may fail to resolve, an HTTPS connection may not be established, the server may return an HTTP error, or the application may show an error screen. The checks below identify the affected layer without changing the database, DNS records or application files.

1. Record the full URL, the browser's error text and the time with its time zone. Test the homepage and the affected inner page separately.
2. Open the same URL once in a different browser and, if possible, through another connection you control. Does the issue occur on only one device or in every check?
3. Note the latest change to DNS, domain renewal, certificates, PHP, themes or plugins.
4. Check account status and any maintenance or operation notice you received in the official customer portal.

Do not change several settings at once during diagnosis. After recording the error, work with the owner of the relevant layer to make rollback and verification easier.

Choose the right check based on the result you see

Does DNS point to the correct destination?

Check domain expiry status and nameserver details through the official registration source. Identify which provider manages DNS records. When comparing the IP in the hosting panel with published A/AAAA records, remember that a CDN or reverse proxy may expose an IP different from the origin server's.

If using a terminal, the queries below only read DNS information. Replace example.com with your own domain; these are example commands, not results for your website:

nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=NS example.com

NXDOMAIN indicates that the queried name was not found; SERVFAIL means resolution could not complete and may have various causes, including DNSSEC or authoritative server issues. An answer without an A record does not, by itself, mean the domain does not exist. Assess the expected record type, subdomain and resolver together.

If DNS changed recently, some resolvers may retain the previous answer in cache. The Google Public DNS troubleshooting documentation treats cache, authoritative server and DNSSEC issues separately. Do not change nameservers or disable DNSSEC without understanding the result; work from the record inventory in the DNS guide.

Match the SSL warning to the domain and certificate

First check that the device's date and time are correct. Then record the certificate error shown by the browser: the certificate may have expired, may not cover the domain being opened, or chain validation may have failed. Checking the same URL from another device helps distinguish local clock or network effects.

Check addresses with and without www separately. One subdomain working does not prove certificate coverage for another. A DNS change pointing to the wrong server can also cause a certificate error; verify the destination before reinstalling the certificate.

Do not bypass the warning and enter credentials or disable certificate validation on the command line. Contact the provider with the certificate name, validity, exact error and affected URL. The SSL and HTTPS guide details certificate, redirect and mixed-content checks.

View the HTTP status code in your browser

Open Developer Tools → Network, reload the page once and record the main document request's status. Use Preserve log to follow redirects if needed. Chrome's Network documentation explains this investigation.

These codes are explained in the MDN HTTP status code reference. If you use a CDN, it also matters whether the response comes from the CDN or the origin server. Do not publicly share complete network logs containing credentials.

Match application error logs with the latest change

If DNS and HTTPS work but WordPress shows a database error, blank screen or critical error message, review recent application changes. Look at the incident time in the PHP/application error logs you can access through the panel. If you suspect a resource limit, match measurements from the hosting limits guide to the same interval.

When WordPress needs more detailed error logging, follow the official debugging documentation with your technical team. Do not leave settings enabled that show error details to visitors on live pages; logs may contain file paths and sensitive data.

Deleting the database, randomly changing every plugin or opening file permissions wholesale is not a diagnostic method. Apply a change chosen on evidence with a current backup and, where possible, in a test environment; first record which file or setting will change.

Example report: homepage works, quote page returns 500

The following report is for educational purposes; it is not a live customer incident.

URL: https://example.com/quote
Check time: [date, time, time zone]
Homepage: HTTP 200, expected content visible
Quote page: HTTP 500
DNS and certificate: working for the same domain
Scope: same result from two different connections
Latest change: quote module update
Next record: application error log from the same time

In this case, the first place to investigate is the quote module's error log. Because DNS affects the whole of the same domain, this observation alone does not call for a nameserver change. Whether the update caused the issue cannot be confirmed without reviewing the log.

Open the request with evidence and verify the fix at the same URL

Add the full URL, first and most recent occurrence times, error code, affected connections and latest change to the support request template. Use the customer portal for an existing account. If you cannot access the portal either, report the access issue through the contact channel.

After a fix, check the affected URL and function again, not just the homepage. Repeat comparisons across devices or networks using the same method. Record the result in the request along with the single change made; if temporary debugging settings or permissions were enabled, verify that they have been disabled.