A domain resolving successfully does not prove that the website server or application is healthy. Check DNS resolution, the HTTP response, SSL and hosting separately.
The domain and website are different layers
A domain can resolve correctly while the server behind it is offline, misconfigured or returning an application error. Separating the layers prevents unnecessary DNS changes.
1. Confirm the domain resolves
Check the A/AAAA/CNAME records and authoritative nameservers. If the domain resolves to the expected infrastructure, do not immediately replace the DNS records.
2. Check the HTTP response
A timeout, 404, 500, 502 and SSL error each point toward different areas. The browser message is useful evidence. Server logs can provide much more detail.
3. Check hosting and server health
Confirm the hosting account is active and the expected server or application is running. A hosting suspension, resource limit, expired service or failed deployment can take the site offline without changing DNS.
4. Check SSL separately
If the server responds but HTTPS fails, inspect the certificate and the hostname it covers. Do not assume that a certificate problem means the domain is broken.
5. Check the application
If the server returns a 500 or the page loads partially, the issue may be application code, database connectivity, a plugin, a deployment or another dependency. Preserve logs before changing files.
The safest first response
Write down what is currently working, what is failing and what changed immediately before the outage. Then investigate the failing layer instead of changing several layers at once.