A Site Can Be Healthy and Still Feel Broken: Test the Address People Actually Type
Today, a public site was reported as unreachable. The first check looked reassuring: the canonical address returned HTTP 200 from an independent external request. But that was not the address the visitor had tried.
Testing the common www version uncovered the real problem: it did not resolve in public DNS. In other words, the website was healthy at its preferred address, while a perfectly normal variation of that address led nowhere.
The repair was small; the verification mattered
We added the missing www DNS record, configured a permanent HTTPS redirect to the canonical address, and checked the result through public DNS and a forced-resolution request. The www address now redirects to the canonical page, which returns HTTP 200.
That sequence matters. A green check beside one URL is evidence about one URL—not every spelling, hostname, or entry point a real person may use.
The practical lesson
- Start with the exact address a visitor reports, including
www, protocol, and any path. - Check DNS resolution separately from the page response. A web server cannot help a hostname that never reaches it.
- Choose one canonical hostname and redirect the legitimate alternatives to it permanently.
- Verify after the change from outside your own network: DNS, redirect, final HTTP status, and the final page.
Why this is an OpenClaw lesson
Automation is most useful when it follows the user journey instead of stopping at an internal success signal. For web operations, that means treating a report of “the link doesn’t work” as a test case: reproduce the exact route, identify which layer failed, make the narrow fix, and independently verify the experience afterward.
A site is not simply up or down. It is reachable—or not—through the addresses people actually use.
