Your uptime monitor says 100% uptime. Google Search Console reports soft 404 errors. Your customers see an error page.
The status code says 200 OK. The page is broken. Your monitor doesn’t know the difference.
Key takeaway: A 200 OK status code only means your server responded — not that users see the right content. Keyword monitoring checks actual page content, catching soft 404s, error pages, and broken deployments that status code monitoring misses.
This isn’t a hypothetical. It’s happening right now on thousands of websites. Here are the five most common ways a page can return 200 OK while being completely useless.
1. Soft 404s — “Page not found” with a 200 status
A soft 404 happens when your server returns HTTP 200 for a page that doesn’t exist. Instead of a proper 404 response, the user sees “Page not found” — but the status code says everything is fine.
According to Google’s Search Central documentation, soft 404s are one of the most common indexing issues. A Semrush 2024 study of 20,000 websites found that 12% of pages across audited sites returned soft 404 errors.
This is extremely common with:
- Single-page applications (React, Vue, Angular) — the SPA shell always returns 200, even for missing routes
- CMS platforms — WordPress plugins that catch errors and display a “friendly” error page
- E-commerce sites — discontinued products that show a generic “Product unavailable” page
Impact: Google de-indexes pages flagged as soft 404s. Users bounce. Your monitoring stays green.
How to detect: Set a “must contain” keyword rule for expected content. If your product page should contain “Add to cart” but instead shows “not available”, keyword monitoring catches it.
2. Framework error pages that return 200
Many web frameworks catch exceptions and return a custom error page with a 200 status code:
- Laravel shows “Whoops, something went wrong” — returns 200
- Next.js error boundaries render an error component — returns 200
- Django shows a debug page in production if misconfigured — returns 200
Your server is up. The framework caught the error. The status code is 200. The user sees a broken page.
How to detect: Set a “must not contain” rule for common error strings: “something went wrong”, “internal server error”, “unexpected error”.
3. Broken third-party dependencies
The average web page loads resources from 15 different third-party domains (HTTP Archive, 2024 Web Almanac). Any one of them failing can break user experience while your server returns 200.
Your page loads. Your server responds with 200. But:
- The CDN serving your CSS is down — users see unstyled content
- Stripe.js failed to load — the payment form doesn’t render
- Google Fonts is slow — text is invisible for 3 seconds
The HTML is there. The status code is 200. The page doesn’t work.
Remember when AWS S3 went down in 2017 and took out large chunks of the internet? Every affected site’s server was fine. Every uptime monitor reported 100% uptime. The pages were broken.
How to detect: This is where dependency monitoring comes in. upsonar parses your HTML and checks every external resource (CDNs, scripts, fonts, images) alongside the main page check. You can also test your dependencies right now with our free checker.
4. Empty or truncated responses
A deployment goes wrong. Your server returns 200 OK with an empty body. Or it returns the first 10% of the page before the connection drops.
This is more common than you think:
- Misconfigured reverse proxy (nginx returning a default page)
- Memory issues causing truncated responses
- Cache serving stale or empty content
How to detect: A “must contain” rule for any content that should always be on the page (your brand name, a footer link, a navigation element) will catch empty and truncated responses immediately.
5. Content that shouldn’t be there
Sometimes the page is “working” but showing the wrong thing:
- A maintenance page that was supposed to be removed
- A “coming soon” placeholder that accidentally went live
- Debug information leaking to production
- Competitor’s content after a domain migration gone wrong
How to detect: “Must not contain” rules for strings like “maintenance”, “coming soon”, “debug”, or “lorem ipsum”.
Traditional monitoring vs keyword monitoring
All five failures share the same pattern — the status code lies. Here’s how traditional monitoring compares to keyword monitoring:
| Scenario | Status code monitor | Keyword monitor |
|---|---|---|
| Server returns 200 with error page | Reports “up” | Detects “something went wrong” |
| SPA returns 200 for missing route | Reports “up” | Detects missing expected content |
| Product page shows “out of stock” | Reports “up” | Detects “out of stock” keyword |
| CDN down, CSS not loading | Reports “up” | Dependency check catches it |
| Empty response body | Reports “up” | Detects missing required content |
Status code monitoring was designed for a simpler web. In 2026, your page is an assembly of dozens of components, services, and dependencies. A 200 status code tells you the server responded. It tells you nothing about what the user actually sees.
What actually works
Keyword monitoring closes the gap between “server responded” and “page works correctly”:
- Must contain rules verify expected content is present
- Must not contain rules catch error messages and unexpected content
- Dependency monitoring checks every external resource your page loads
- Multi-region verification confirms issues aren’t just local network glitches
upsonar combines all three — uptime, keywords, and dependency monitoring — in a single check. No separate monitors needed. See our keyword monitoring setup guide to get started.
Related: When 200 OK Doesn’t Mean Everything Is OK — our deep dive into why traditional monitoring fails.