Website Not Loading? Read DNS, Status Codes and Redirects

The site loads for a colleague and not for you. A customer says your checkout is down while your own dashboard looks fine. Email stopped arriving after a DNS change. Troubleshooting by guesswork wastes hours, because a web request passes through several separate layers and each one fails in its own way. This guide walks the layers in order and shows which free tool answers each question, so you can find the broken link in minutes.

The path a request takes

When someone opens a web address, four things happen in sequence.

1. DNS turns the domain name into an IP address.
2. A connection is opened to that address, and for HTTPS the certificate is checked.
3. The server answers with an HTTP status code and headers.
4. Redirects, if any, send the browser to another URL, and the process repeats.

A failure at one layer looks different from a failure at another, which is why the order matters. Start at the top and stop at the first thing that looks wrong.

Step 1: does the name resolve?

Open the DNS Lookup, enter the domain and choose a record type. The tool offers A, AAAA, CNAME, MX, NS, TXT, SOA, SRV and CAA.

• A and AAAA hold the IPv4 and IPv6 addresses of the site. If the A record still shows your old host after a migration, visitors are still being sent there.
• CNAME makes one name an alias for another. A www record often points to the bare domain or to a hosting provider.
• MX lists the mail servers. Email that stops after a DNS change usually has a missing or mistyped MX record.
• NS shows the authoritative name servers, TXT holds SPF, DKIM and verification strings, and CAA limits which authorities may issue certificates.

Each answer includes a TTL in seconds: how long resolvers may keep a cached copy. The lookup is made by Google Public DNS from your browser, so a recent change may still show the old value until the TTL runs out, and your own provider's resolver may differ again. A message that no records were found means the resolver returned nothing, so check for a typo, a missing record or a lapsed domain.

Step 2: is the server answering?

If the name resolves, ask the server. The Server Status Checker requests the URL from our server and reports the status code, response time, server header and SSL certificate state. Because the request comes from outside your network, it ignores your browser cache, VPN and office proxy. Response time is labeled fast under 500 ms, acceptable up to 1.5 seconds and slow beyond that.

Read the status code by its first digit.

• 2xx means success.
• 3xx means redirect, which is step 3.
• 4xx means the request was refused or wrong: 404 not found, 403 forbidden, 410 gone.
• 5xx means the server failed: 500 internal error, 502 bad gateway (a proxy received an invalid reply), 503 unavailable (overload or maintenance) and 504 gateway timeout.

If there is no status at all, the error message names the layer: the domain could not be found (DNS), the connection was refused or reset, the server did not respond in time, or the certificate is expired, self-signed, issued for a different name or missing an intermediate certificate. A certificate that expires within 30 days is flagged as expiring soon.

Step 3: where does the URL really go?

Redirects are invisible to visitors and expensive when chained. The Redirect Checker lists every hop with its status code and destination, follows up to 10 hops and stops at loops. A typical bad chain is the http address sending visitors to https, then to the www version, then to a home page path: three hops where one would do.

• Aim for a single redirect from any old URL to its final address.
• 301 and 308 are permanent redirects that search engines treat as a move. 302, 303 and 307 are temporary, so using them for a permanent move keeps the old URL in play.
• Redirecting HTTP to HTTPS is good practice.
• Only HTTP redirects are followed. Redirects done by JavaScript or a meta refresh tag inside the page are not.

To write the server rules that fix a chain, the htaccess Generator builds redirect rules for Apache.

Step 4: is the domain itself healthy?

Sometimes the site is fine and the domain is the problem. The Whois Lookup reads the registry's official RDAP record through our server and shows the registrar, the registration date, the expiry date with days remaining, the name servers, DNSSEC status and the registry status codes explained in plain English. An expired domain produces "site down" symptoms, and name servers that differ from your DNS provider explain why records you edited never take effect. Owner names and contact details are normally redacted by the registry.

Step 5: what does the internet see of you?

Sometimes the problem is your own address: a firewall allow-list, a VPN that is not on, or a service that blocks a region. What is My IP shows the public address your connection presents, with an approximate city, country, network provider and time zone taken from ipinfo.io. To learn where an address from a log or an email header sits, enter it into IP Location. Treat locations as approximate, since they reflect provider records rather than a street address.

Quick triage

• The name does not resolve: DNS Lookup, then Whois Lookup for expiry and name servers.
• The name resolves but nothing answers: Server Status Checker.
• Wrong page or endless loading: Redirect Checker.
• Works for others but not for you: check your IP, VPN and local DNS cache.