Website Checker Methodology

This page explains exactly how Website Checker evaluates a URL, what we can and cannot measure, and why your browser experience may differ from our result.

1. Input validation and safety filters

Before any request is made, we normalize and validate the submitted URL. We block unsupported schemes, local/private IP targets, and unsafe redirect outcomes. This prevents misuse and keeps checks focused on public web endpoints.

2. DNS checks

We query DNS records and resolve domain-to-IP mappings. If a domain does not resolve publicly, we mark that explicitly so users can separate DNS issues from web server issues.

3. HTTP(S) request behavior

We perform an HTTP(S) request with redirect following and timing capture. The response includes status code, redirect count, final URL, content type, and basic page metadata when retrievable.

4. SSL/TLS handling

We attempt strict SSL verification first. If a strict SSL handshake fails, we may run a relaxed follow-up check to determine whether the host is reachable but misconfigured. In those cases we flag SSL concerns separately rather than silently treating the site as healthy.

5. Rate limits and anti-bot pages

Some websites block automated requests (for example, WAF challenges or Cloudflare protection). When we detect these patterns, we label the result as limited so users do not confuse bot blocking with a complete outage.

Known limitations

• Results are from our server location, not every global region.
• Checks are on-demand snapshots, not continuous monitoring.
• A 200 response does not guarantee every page path is healthy.
• User-side issues (ISP blocks, browser cache, extensions) can differ from server-side checks.

How to use results responsibly

Treat a checker result as one technical data point. For critical incidents, combine it with server logs, synthetic monitoring from multiple regions, and your hosting provider diagnostics.