That question is narrower than it looks. A 200 tells you the server says the request succeeded. It doesn't tell you whether the page your visitors got is the page you meant to serve.

What 200 actually promises

RFC 9110, the current HTTP spec, defines 200 like this: "The 200 (OK) status code indicates that the request has succeeded." For a GET, the body is "a representation of the target resource" (RFC 9110, section 15.3.1).

Notice who decides that. The server. If your app catches an exception and renders a friendly "Something went wrong" template, it can send that with a 200. If a reverse proxy or hosting panel falls back to a default page, that can be a 200 too. HTTP has no idea the content is wrong.

Google runs into the same problem at a much bigger scale. Its crawler docs say that when a 2xx page's content "suggests an error", such as "an empty page or an error message", Search Console reports it as a soft 404 (Google Search Central, HTTP status codes). In other words, even Google doesn't trust 200 by itself. It looks at the content.

Ways a site breaks while returning 200

These are common patterns, not a complete list:

• The app catches its own error. A framework error boundary or a generic error template renders with status 200 instead of 500.
• A dependency is down, the shell isn't. The layout loads, but the product list, the cart or the login form is empty because the database or an API call failed.
• A deploy shipped the wrong thing. A placeholder page, a "coming soon" template, a default server welcome page, or the staging build.
• Something in front of the app answers instead of it. A hosting parking page, a maintenance page, or a cached copy that is badly out of date.
• A redirect lands somewhere you didn't expect. The monitor follows the redirect, gets a 200 at the end, and reports success, even though the final URL is a login wall or a different domain.

In every one of these, a status-only check stays green while real people see a broken page.

The cheap fix: check for something that should be there

The simplest upgrade is a keyword check (also called a content check or content match). Along with the status code, the monitor downloads the response body and looks for a string that only appears when the page is actually working. If the string is missing, the check fails, even with a 200.

You don't need a headless browser for this. A plain HTTP GET and a substring search cover a lot of ground.

Picking a good keyword

This is where most of the value is, and also where most false alerts come from.

Good choices:

• Text that is rendered from your data, not hard-coded in the layout. For a shop, a category name that comes from the database is better than the logo text. If the database is down, it disappears.
• A stable marker you control, for example a hidden data-health="ok" attribute or a short comment your template writes only when the page rendered fully.
• On an API, a field from a real response, like "status":"ok" on a health endpoint that actually checks its dependencies.

Bad choices:

• Your brand name. It's in the header, the footer, the title and probably the error page too.
• Marketing copy that changes every campaign. You'll get alerts every time someone edits a headline.
• Anything that only appears after JavaScript runs, if the monitor doesn't execute JavaScript (most HTTP monitors don't).

A quick test: open your own error page, maintenance page and an empty-database state if you can reproduce it. Your keyword should be missing from all of them and present on the working page.

An inverse check helps too

Some monitors also let you alert when a string does appear, such as "Error establishing a database connection" or "maintenance". That's useful when you know the exact failure text. It's a complement to the positive keyword, not a replacement, because you can't list every way a page can fail.

Limits worth knowing

Keyword checks are not a full browser test.

• Single-page apps. If the server sends an empty <div id="root"></div> and everything renders client-side, there's nothing useful in the HTML to match. Monitor an API endpoint the app depends on instead, or use a browser-based synthetic check for the critical flow.
• Body size. Some monitors only read the first part of a large response. Put your marker early in the HTML when you can.
• Personalized or A/B-tested pages. Pick a string that appears in every variant, or check a simpler URL.
• It checks one page, not a journey. Checkout can be broken while the product page looks fine. For flows that make money, a scripted check is worth the extra setup.

A practical setup

For a typical small site or client site, this covers most real outages without much noise:

1. Monitor the homepage and one page that depends on your database or main API.
2. Set the expected status range explicitly (for example 200-299, or 200-399 if redirects are fine).
3. Add a keyword that only shows up when the page rendered from real data.
4. Require more than one failed check, ideally from more than one location, before alerting. That filters out a single network hiccup.
5. Send alerts somewhere you'll actually see them quickly.

Disclosure, and where I'm coming from

I work on PingoGo, a small uptime monitor. It does the things above: per-site expected status codes, an optional required keyword, and confirmation from a second region before marking a site down, with alerts going to Telegram. There's a free plan for two sites if you want to try a keyword check on your own site.

If you'd rather use something else, the advice still holds. Whatever tool you use, check whether it supports content matching, and turn it on for at least one page that depends on your backend.

If you want to see what your page returns right now, without signing up, there's a free HTTP status checker.

I wrote this with help from an AI assistant and reviewed and edited it myself.