Troubleshooting areaReviewed 2026-08-13By HostWithShery technical editorial

Website Health

Diagnose why a website, domain or business email setup is not working by connecting DNS, HTTPS, redirects, hosting and mail evidence.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

Complete Website Health Check

This page is preconfigured with the Complete Website Health Check that best matches this problem.

No accountPublic evidence only
Live public check

Enter the domain only. We will test root + www, DNS, HTTPS, redirects, mail and crawler access.

No account · Public configuration only
On this page
Browse this section

Choose the focused diagnostic

Every important page in this area is linked here with a normal crawlable link, so you can choose by task instead of searching through a long generic list.

Symptom-first guides

Website stopped working after DNS changeA DNS change can send visitors to the wrong server, remove a required record or expose a broken IPv6 endpoint.Open →Website not working after changing nameserversChanging nameservers replaces the authoritative DNS zone. Any website record that was not copied to the new provider stops being published.Open →Website works for me but not othersDifferent DNS caches, IPv4/IPv6 paths or regional routing can make the same domain behave differently for different visitors.Open →Website works on Wi-Fi but not mobile dataMobile and Wi-Fi networks can use different DNS resolvers and IP versions, exposing propagation or IPv6 problems.Open →Domain points to old websiteThe active A/AAAA/CNAME still leads to an old host or one network has cached the previous answer.Open →Domain points to parking pageDNS resolves, but the destination server is serving a registrar, host or default parking response instead of the intended site.Open →Website works without www but not with wwwThe www hostname usually has a missing/wrong DNS record, is not attached to the hosting platform, or is not covered by the certificate.Open →Website works with www but not without itThe apex/root record is missing, points elsewhere or is not attached to the site/certificate.Open →New website not showing after migrationA hosting migration can be complete while public DNS still points to the previous server.Open →DNS changed but old website still appearsA cached DNS answer or forgotten record—often AAAA—can continue sending some visitors to the old server.Open →Subdomain not workingThe subdomain needs its own A/AAAA/CNAME or platform mapping; the root domain working does not make every subdomain resolve automatically.Open →Website shows server IP instead of domainThe server or application is generating redirects/canonical URLs with the IP, or the virtual host is not configured for the requested domain.Open →

Website Health: what this section covers

Website Health is the cross-layer starting point for a failure that has not yet been isolated. It compares whether the domain resolves, whether both HTTP and HTTPS respond, whether root and www agree, whether the certificate is usable, whether mail DNS still exists and whether crawler-facing directives accidentally block the site.

Signals that matter for website troubleshooting

The pages here interpret business-email DNS and mail authentication evidence through the following search tasks and configuration concepts. They are included because they help separate causes, not to repeat a keyword a fixed number of times.

  • Website healthVerify website health from the public Internet and compare it with the value the responsible provider says should be live.
  • Website diagnosticsVerify website diagnostics from the public Internet and compare it with the value the responsible provider says should be live.
  • Website troubleshootingVerify website troubleshooting from the public Internet and compare it with the value the responsible provider says should be live.

Which Website Health check to start with

Use the combined check when several symptoms appeared together after a migration, nameserver change or provider move. If the scan isolates one failing layer, switch to the focused DNS, SSL, HTTP or email tool so the repair can be verified without repeatedly running unrelated tests.

Diagnosis first, raw evidence second

The interface surfaces the highest-impact explanation and its confidence before raw protocol output. For website troubleshooting, that means a visitor can see what probably failed and what to change while an advanced user can still inspect the DNS, certificate, header, resolver or provider evidence behind the conclusion.

What a repaired website troubleshooting problem should look like

A healthy outcome is not a score. It is a set of compatible public signals: the intended website endpoints answer, HTTPS works on the hostnames visitors use, mail still routes to the intended provider and no higher-severity finding explains the reported failure.

Validate the business-email DNS and mail authentication change

The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure. Re-run the same focused tool that exposed the problem so a dashboard status, cache or unrelated healthy signal is not mistaken for proof of the repair.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.