What the status code does and does not say
The HTTP status code (RFC 9110) tells a client how the request went at the protocol level: 2xx succeeded, 3xx redirects, 4xx the request was wrong, 5xx the server failed. It says nothing about whether the response is the page you meant to serve.
Google makes the same point from the search side: if a page with a 2xx status looks like an error page or is empty, Search Console reports a soft 404. The server said “fine” and the content said “nothing here”.
Failures a 200 hides
- A custom error page with status 200. The framework catches the exception and renders a friendly “Something went wrong” page without setting a 500.
- A maintenance page. A plugin or a host serves “We’ll be back soon” with status 200 (it should be 503).
- A blank page. A PHP fatal error with display turned off returns an empty body. Some stacks still send 200.
- A CDN serving a stale or wrong page. The origin is down and the CDN keeps serving the cached copy. For visitors that is acceptable for a while; for the shop’s stock levels it is not.
- A parked or default host page. After a DNS or hosting change the domain shows “Welcome to nginx” or a hosting company’s placeholder, with 200.
- A login wall or consent wall. A redirect to a login page that returns 200 for an anonymous request.
- A broken checkout or form. The home page loads and the add-to-cart call fails. A page-level check cannot see it.
- Missing assets. The HTML loads, the CSS or JavaScript returns 404, and the page is unusable.
- Wrong content after a deploy. Staging text, an old version, placeholder copy.
- Hacked content. Injected links or spam added to a page that still returns 200.
The opposite problem: error codes that are fine
Not every non-200 is an outage. A 404 on a deleted page is correct. A 401 on a members area is correct. A 301 on an old URL is correct. Decide per URL what “good” means: the status you expect and, where it matters, the content that must be there.
Better checks, in order of effort
1. Check the status you expect
Not only “2xx”: specify 200 for a page, 301 for a redirect you rely on, 404 for a URL that must not exist.
2. Check for expected text
Require a phrase that is on the page when it is healthy and absent when it is not: the footer line, a product name, a heading. Choose a phrase that is stable and unlikely to appear on an error page. This catches blank pages, default host pages, maintenance pages and many error templates.
3. Check for text that must not appear
Alert if the page contains “Fatal error”, “Database connection”, “Index of /” or the hosting company’s placeholder text.
4. Check more than the home page
The home page is the most cached and least representative. Add one URL per template: a product, a post, a search results page, the contact page, the cart. For each, an expected status and expected text.
5. Check the dependencies the page needs
Fetch a stylesheet and a script from the page and check their status. A page whose assets are 404 is down for visitors.
6. Check the journeys that earn money
A scripted browser test that adds an item to the cart or submits the contact form catches what no single request can. These need more upkeep, because every redesign can break them. Choose one or two journeys per client and keep them boring.
7. Check the redirects and the final URL
A request that follows redirects to the wrong host or to a login page is a failure even if the last response is 200. Record the final URL.
8. Check what search engines see
Status 200 with noindex, a robots.txt block or a canonical to another host is “up” for visitors and “gone” for search. See Noindex after a deploy.
Slow is also down
A page that responds in 25 seconds returns 200 and loses the visitor. Set a timeout that matches the visitor’s patience, a few seconds for a page, and treat a timeout as a failure. Record timings so the monthly report can show trends.
How to set expectations with clients
Tell the client what is checked: “we check that the page loads, shows the expected content and that these three pages respond”. Do not say “we monitor your website”, which promises more than any single check delivers. When the cart breaks and the monitor was green, the difference between those sentences is the conversation you will have.
How Beamfar helps
Beamfar checks the page from each enabled region and records the status code, the timings, the DNS answer and the final URL after redirects, and it can require expected text. A site with no valid measurement is shown as “data unavailable”, never as up. It does not run scripted browser journeys, so a broken checkout needs a different test; it does add SEO signals (noindex, robots.txt blocking, canonical moved) that a status code never shows.
Questions
What is a soft 404?
A page that returns a 2xx status but looks like an error page or is empty. Google reports these in Search Console as soft 404 errors.
Should I check for text on a page?
Yes, for the pages that matter. A stable phrase that is present when the page is healthy catches blank pages, maintenance pages, default host pages and many error templates that still return 200.
What status should a maintenance page return?
503 Service Unavailable, so that monitors, browsers and search engines know the outage is temporary. A maintenance page that returns 200 looks like a healthy page to simple checks.
Can a monitor tell me that my checkout works?
Not from one request. A scripted journey that adds an item and proceeds through checkout can, at the price of more maintenance, so choose one or two high-value journeys per client.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- Google Search Central, How HTTP status codes affect Google Search (developers.google.com)
- RFC 9110, HTTP Semantics (status codes) (www.rfc-editor.org)