Why a 200 OK Doesn't Mean Your Website Is Healthy

I used to think that checking whether a website worked was fairly straightforward: send a request, get a successful response, and move on.

The more I work on web tooling, the less useful that definition feels.

An HTTP 200 OK response answers one narrow question: did the server successfully handle this particular HTTP request? It does not tell you whether the website is secure, accessible, fast, searchable, or even useful to a visitor.

That distinction is part of what interests me about building Zenith, a project focused on monitoring and improving websites. A meaningful website check needs to look beyond a green status indicator.

Here are five layers I would examine, and how I'd begin testing them.

1. Availability isn't the same as usability

Try:

curl -I https://example.com

The response can tell you about status codes and headers. It cannot tell you whether a sign-in button works, whether a critical API fails after the page loads, or whether a JavaScript error prevents users from completing an action.

In fact, curl -I makes a HEAD request. Some servers handle HEAD differently from GET, so it's useful as a quick inspection tool, not as complete proof of normal page behaviour.

For a more realistic picture, check more than one endpoint and include an actual browser journey. For example:

• Can the homepage load?
• Can a visitor navigate to an important page?
• Can a non-destructive form validation flow complete?
• Does the browser report failed requests or JavaScript errors?

An uptime check is a starting point, not a quality score.

2. HTTPS is necessary, but it doesn't finish the security job

A padlock indicates that a connection is protected by TLS under the browser's trust rules. That's important. It isn't a certificate of application security.

Look at response headers:

curl -sSI https://example.com

Things worth reviewing include:

• Strict-Transport-Security: helps instruct browsers to use HTTPS for future connections.
• Content-Security-Policy: can reduce the impact of certain injection attacks when configured carefully.
• X-Content-Type-Options: with nosniff, can prevent some MIME-type confusion.
• Cookie attributes: Secure, HttpOnly, and SameSite matter for session handling.

Presence isn't enough. For example, a CSP that broadly permits unsafe inline scripts may provide less protection than its name suggests. And missing a header does not automatically mean a site is exploitable: context matters.

Also, please don't run intrusive security scans against sites you don't own or have permission to assess. Public response-header inspection and authorised testing are different things from attempting exploitation.

3. Accessibility can't be reduced to one automated score

Automated accessibility testing is excellent at catching certain problems: missing accessible names, insufficient contrast in some contexts, structural errors, and more.

But a passing automated test doesn't mean someone can actually use the interface with a keyboard or screen reader.

A simple manual starting point:

1. Put down the mouse.
2. Use Tab and Shift+Tab to move between controls.
3. Check whether the focus indicator is visible.
4. Try the main interaction using the keyboard alone.
5. Verify that errors are understandable and connected to the appropriate inputs.

An interface can look polished and still exclude people. I think that should be considered a functional bug, not just a design issue.

4. Performance depends on the user, not just the server

A fast server response isn't necessarily a fast experience.

There are differences between receiving the initial HTML, displaying meaningful content, and making the page responsive to interaction. Large images, render-blocking resources, third-party scripts, and heavy client-side work can change what visitors experience.

For an initial lab measurement, use Lighthouse in Chrome DevTools. For real-user context, look at Core Web Vitals such as Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.

I would always record the device, network conditions, URL, time, and measurement method. Otherwise it becomes too easy to compare two numbers that aren't really comparable.

5. Being online doesn't mean being discoverable

A search engine has to find, crawl, render where necessary, and understand a page before ranking becomes relevant.

Some straightforward checks:

curl -I https://example.com/robots.txt
curl -I https://example.com/sitemap.xml

Those paths are useful places to look, not universal guarantees. A site may use different sitemap locations, and a successful response does not prove correct content.

I would also review canonical URLs, titles, meta descriptions, redirect behaviour, indexing directives, and whether important content can be accessed without relying on fragile client-side behaviour.

The part I find most useful: evidence before scores

One tempting approach is to merge all these checks into a single score out of 100.

Scores can be helpful for prioritisation, but they can also hide important details. A critical security configuration problem should not disappear because the site has excellent SEO or performance metrics.

For every finding, I think a useful report should answer four questions:

1. What was observed? Include the exact URL, response, test or reproducible behaviour.
2. Why might it matter? Explain the consequence without overstating it.
3. What should change? Give a concrete, proportionate next step.
4. How do we verify the fix? Repeat the same test, and add a stronger check if needed.

That last point matters most to me. Identifying problems is easy to celebrate. Demonstrating that a change actually solved one is more useful.

I'm still learning how to make these kinds of checks reliable and understandable. Building website tools keeps revealing the difference between what a system appears to be doing and what we can actually verify.

A 200 OK response is good news.

It just isn't the whole story.

I'm Marceli Pawliński. I build and experiment with software, cybersecurity, AI and website infrastructure. My main project is Zenith.