Website Status

Site availability check: how to read the result

The checker sends a request from our server to the URL you enter and waits up to 15 seconds for an answer. If you leave out the scheme, https:// is used. The request uses the HEAD method, so the server returns headers only, without the page body: the check is fast and puts no load on the site. Redirects are followed (up to ten) and the final address is shown.

The report contains:

• "Site is Up" or "Site is Down". Up means the server answered with a status from 200 to 499 and no network error. That includes 404 and 403: the server is alive, but that particular URL returns an error. Always look at the code itself.
• HTTP status of the final response after all redirects.
• Response time for the whole request from our side: DNS, connection, TLS handshake and redirects.
• TTFB, time to first byte of the last response — how long the server spent producing it.
• SSL — whether a certificate was received. It is validated, so an expired certificate or one issued for another name causes a connection error and the site is marked down.
• Redirect count, final URL, the Server header and a redirect chain table (status, from, to).

Is it down for everyone or just me?

Our request comes from a data center, not from your device, which is what makes the result useful:

One honest limitation: the check runs from a single location. A site that is geo-blocked, or unreachable only through certain ISPs or countries, may look fine from our data center. To check website availability worldwide you need probes in several regions; a quick substitute is testing through a VPN exit in the country you care about, or over mobile data.

If the site is down only for you

1. Try your phone on mobile data with Wi-Fi off.
2. Flush the DNS cache: Windows ipconfig /flushdns; macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
3. Compare DNS answers with nslookup example.com 8.8.8.8. If a public resolver returns a different IP than yours, switch to 1.1.1.1 or 8.8.8.8.
4. Disable VPN, proxy and browser extensions; try a private window.

Status codes at a glance

To inspect each hop with its own headers, use the HTTP status checker.

Down with no status code

• Could not resolve host — the domain doesn't resolve: registration expired, nameservers or the A record removed. Check expiry in WHOIS lookup.
• Connection refused — the machine is up but nothing listens on 443 or 80: web server stopped or port firewalled. Test it with the port checker.
• Timed out — no answer within 15 seconds: overload, DDoS, network trouble at the host.
• SSL certificate problem — expired certificate, missing intermediate, or name mismatch. The SSL checker shows the details.

What to do if your own site is down

On a VPS with nginx and PHP-FPM, start here:

systemctl status nginx php8.3-fpm
tail -n 50 /var/log/nginx/error.log
df -h          # disk full?
free -m        # out of memory?

A 502 with nginx running almost always means PHP-FPM died or is saturated. A full disk breaks the database, sessions and logs at once.

On WordPress, a white screen or 500 right after a plugin update is usually cleared by renaming that plugin's folder over FTP (wp-content/plugins/name → name-off); define('WP_DEBUG', true); plus define('WP_DEBUG_LOG', true); in wp-config.php will log the actual error. On shared hosting or site builders, first check whether the account was suspended for billing and whether the platform has posted an incident.

How downtime affects Google rankings

A short outage of minutes or a few hours won't sink your rankings. When Googlebot gets a 5xx or a timeout, it slows down crawling and comes back later. If the server keeps returning 5xx for days, Google starts dropping those URLs from the index, and recovery can take weeks. Two rules follow:

• For planned maintenance return 503 with a Retry-After header — not a "we'll be back" page with status 200, and not 404. A 503 tells crawlers the outage is temporary, so your pages aren't replaced in the index by the placeholder.
• Don't answer crawlers with 403 or 404 when the server is overloaded. Google reads 4xx as "this page doesn't exist", not "the server is busy".

location / {
    return 503;
}
add_header Retry-After 3600 always;

Also watch the redirect chain in the report. A typical result for a bare domain is two hops: http://example.com → https://example.com/ → https://www.example.com/. The site works, but every visit pays for an extra round trip. Send every variant to the canonical URL in a single 301.

Response time benchmarks

Google treats a TTFB under 0.8 seconds as good. A consistently higher TTFB points at the server: no page cache, slow database, undersized plan. Low TTFB but high total time means the time goes to redirects, DNS or connection setup — check the chain in the report. Run the response time test for repeated measurements.

This is a one-off site availability check, not a website uptime monitor: it doesn't watch the site around the clock or send alerts. If outages are intermittent, run the check while the problem is happening and keep the status code and error text — that's exactly what your host's support will ask for.