Website Troubleshooting Checklist: How to Diagnose DNS, SSL, Hosting, and WordPress Errors

Overview

A website request normally passes through several layers: your browser and network, the domain’s DNS records, the web server or hosting account, the SSL certificate, and the application itself. WordPress adds another layer through its database, themes, plugins, and configuration files. A failure at any point can produce a similar symptom, such as a blank page or a message that the site is unavailable.

Start by identifying the scope of the problem:

• Only one device or browser is affected: suspect cache, cookies, browser extensions, local DNS cache, or a network issue.
• Several devices show the same problem: check DNS, hosting, SSL, and the website application.
• Only one page is broken: investigate that URL, its redirects, content, or a WordPress route.
• The whole site is unavailable: begin with DNS and hosting, then check SSL and server or application logs.
• The site works but displays the wrong content: check DNS records, caching, redirects, and whether you are testing the correct domain or environment.

Keep a short incident note with the time the problem started, the exact URL, the error message, recent changes, and the tests you have completed. This prevents repeated work and makes a hosting or developer support request much easier to resolve.

Checklist by scenario

Scenario 1: The domain does not resolve

Messages such as “server IP address could not be found,” “DNS_PROBE_FINISHED_NXDOMAIN,” or a domain that redirects to an unexpected provider usually point to DNS or domain configuration.

1. Confirm that the domain name is spelled correctly and that you are testing the intended version, such as www.example.com or example.com.
2. Check the domain registrar to confirm that the domain is active and using the intended nameservers.
3. Review the DNS zone for the required records. An apex domain commonly uses an A record or an equivalent setup, while a subdomain such as www may use a CNAME. Use the values supplied by your hosting provider rather than guessing.
4. Look for conflicting, duplicate, or outdated records. A stale record can send visitors to an old server.
5. Allow time for DNS changes to appear across different networks. During this period, compare results from more than one connection instead of repeatedly editing the records.

For a fuller walkthrough, use the DNS settings guide. Do not change nameservers and individual DNS records at the same time unless you understand which system is authoritative.

Scenario 2: DNS works, but the website is not loading

If the domain resolves to an IP address but the browser reports a timeout, connection refusal, or a server error, investigate hosting and the web server.

1. Check the hosting control panel for service notices, account status, resource alerts, or an expired hosting plan.
2. Verify that the domain is attached to the correct hosting account and that the document root points to the intended site files.
3. Confirm that the server is listening for both the root domain and the www hostname if both are meant to work.
4. Test a simple static file, if you have access to the site directory. A static file loading while WordPress fails suggests an application or PHP issue rather than a DNS problem.
5. Review server or hosting logs for timeouts, permission errors, exhausted resources, or configuration failures.

If the site is intermittently unavailable, record the times and test from another network. An uptime monitoring setup can help distinguish a local problem from a recurring server issue; see the website uptime monitoring guide.

Scenario 3: The browser reports an SSL or security warning

An SSL error means the encrypted connection cannot be validated for the address being visited. Check the following:

• Confirm that the certificate covers the exact hostname, including whether visitors use www.
• Check whether the certificate is active and installed on the server that DNS currently points to.
• Verify that the server is presenting the complete certificate chain when the hosting platform requires it.
• Check the server date and time if the warning concerns certificate validity.
• Review redirects so that HTTP and HTTPS do not create a loop.
• In WordPress, confirm that the site URL and home URL use the intended protocol and hostname.

Do not tell visitors to bypass a certificate warning as a permanent fix. Correct the certificate, hostname, server configuration, or redirect that caused it.

Scenario 4: WordPress shows a blank page, error, or broken layout

First determine whether the problem began after an update, installation, migration, theme change, or configuration edit. Then:

1. Use a backup or staging copy before making major changes. A practical backup routine should include both website files and the database; the website backup guide explains the basic process.
2. Temporarily disable recently changed plugins, if you can access the dashboard. If the dashboard is unavailable, use the hosting file manager or another approved method to rename the relevant plugin directory.
3. Switch to a standard theme temporarily to test whether the active theme is responsible.
4. Check PHP and application logs for the first error rather than focusing only on the final browser message.
5. Verify database credentials and database availability if WordPress reports a database connection failure. Use the dedicated database connection troubleshooting guide for that scenario.
6. Clear relevant caches only after recording the change. This includes a WordPress cache, hosting cache, CDN cache, and browser cache when applicable.

After recovery, update one component at a time and test the homepage, an internal page, a form, login, and the administration area.

Scenario 5: The site loads, but a form, image, or link fails

Limit the test to the failing feature. Check the browser developer console, the request URL, file permissions, redirect rules, and mixed HTTP/HTTPS content. For contact forms, confirm that submission reaches the application and that delivery is configured separately from the on-page success message. The contact form troubleshooting guide covers the most common checks.

What to double-check

Before concluding that a fix worked, test the complete path rather than one page in one browser.

• Test the root domain and the preferred hostname, with and without www if relevant.
• Test both HTTP and HTTPS and confirm that the non-preferred version redirects only once to the preferred version.
• Check an internal page, an image, a form, and a WordPress login or admin page.
• Use a private browser window and a second network to reduce the effect of cached results.
• Confirm that DNS changes were made in the authoritative DNS provider, not in an unused hosting panel.
• Review recent changes to domains, nameservers, SSL, hosting, plugins, themes, redirects, and firewall rules.
• Check that a security or maintenance setting has not blocked crawlers, visitors, or your own IP address.

If search visibility is part of the issue, verify that redirects, the XML sitemap, and robots.txt still reflect the intended site. See the redirect guide, XML sitemap guide, and robots.txt guide. If a link above is unavailable, use the linked topic title as a checklist rather than making unrelated configuration changes.

Common mistakes

• Changing several layers at once: Editing DNS, SSL, WordPress, and plugins together removes the evidence needed to identify the cause.
• Assuming propagation is the only explanation: A delayed DNS result is possible, but an incorrect record, inactive domain, or wrong nameserver may need correction.
• Clearing every cache first: Cache clearing can hide useful clues. Record the original error and clear one layer at a time.
• Editing files without a backup: Keep a restorable copy before changing configuration files, database values, themes, or plugins.
• Ignoring the exact hostname: A certificate or DNS record may work for one hostname but not another.
• Testing only from an administrator session: A logged-in WordPress user may see a different cached or permission-controlled version than a visitor.
• Repeating a failed fix: Keep a change log with the time, action, result, and next hypothesis.

When to revisit

Use this checklist whenever a domain, hosting account, SSL certificate, DNS provider, WordPress core version, plugin, theme, redirect, or caching layer changes. Revisit it before a planned launch, migration, seasonal campaign, or major content release, when a previously stable site becomes slow or unavailable, and after restoring a backup.

For routine maintenance, create a short recurring review:

1. Confirm that backups complete and that at least one restore test is documented.
2. Check the domain, hosting, SSL, and DNS contact details and renewal settings.
3. Test the homepage, key internal pages, forms, redirects, and login.
4. Review uptime alerts, server errors, WordPress updates, and unusual traffic or security notices.
5. Record the current DNS provider, hosting account, preferred hostname, SSL setup, and recovery contacts in a secure location.

When the checklist does not identify the fault, stop making random changes. Save the exact error, timestamps, affected URLs, DNS results, recent change history, and relevant logs, then provide that information to your hosting or technical support team. A structured handoff is usually safer and faster than continuing to edit production settings without a clear hypothesis.