The 200 OK that means “page not found”
August 1, 2026
Every page your site serves comes with a status code — a number the browser and Google see but your visitors never do. Two hundred means “here is the page you asked for.” Four hundred and four means “that doesn’t exist.” When those two disagree with what’s actually on the screen, you get a specific and costly class of bug: the site looks correct to every human who checks it, and is wrong to every machine that reads it.
The soft 404
On one of my sites, a request for a page that didn’t exist rendered a tidy “not found” screen — right layout, right wording, right everything. It also returned a 200. As far as search engines were concerned, that was a real page with real content, worth indexing, worth ranking, and worth showing to somebody.
Multiply that by every mistyped URL, every stale link, and every deleted product, and you build a search presence full of pages that say nothing. Google has a name for it and treats it as a quality signal against you.
Fixing it surfaced a second problem immediately. Moving the not-found check to the right place fixed the status code but served a different error screen — one that offered logged-out visitors a button to “go to dashboard,” which they could not use. Both now render the same not-found component. The status and the screen have to be corrected together, or you just move the wrongness.
Six more that passed every check
While building two marketing sites I kept a list of bugs that got through type checking, linting, a successful build, and a 200 response. All of them were visible to a person looking at the page. None were visible to any automated gate.
- A contact form rendered with every label empty and a blank submit button, because part of the page tried to read a value that only exists in the browser. No error — just silence where the words should be.
- A font-size setting that was silently ignored because of a syntax subtlety, so text rendered at the wrong size everywhere it was used.
- A decorative graphic that rendered 1,122 pixels wide on a 390-pixel phone, because a missing width fell back to the image’s built-in size.
- A screen-reader-only table cell that gave the entire page a horizontal scrollbar on mobile.
- Images loaded from an outside service that built perfectly and then returned a server error the moment someone actually loaded the page, because the host wasn’t on the approved list.
- Random values generated while rendering, which made the version the server sent disagree with the version the browser built — a mismatch that breaks interactivity in ways that look like nothing at all.
Why the gates miss all of this
Type checking asks whether the code is internally consistent. Linting asks whether it follows house style. A build asks whether it can be assembled. A 200 check asks whether the server responded. Not one of them asks whether the resulting page is correct, and it is entirely possible — routine, even — to pass all four and ship something visibly broken.
The gate that catches these is unglamorous: load the page in a real browser, at a phone width, and read the console. That is where the empty labels, the oversized graphic, the horizontal scrollbar, and the image errors all announced themselves immediately.
What to check on your own site this week
- Visit a URL on your site that definitely doesn’t exist. Does it return a 404, or does it return 200 with a pretty error page?
- Open your homepage on a phone and scroll sideways. If it moves, something is wider than the screen.
- Open the browser console on your two most important pages and look for red.
- Search Google for your domain and look for indexed pages that shouldn’t be there.
The takeaway
Automated checks confirm your site was assembled, not that it’s correct. Verify the status code separately from the screen, and open the real page in a real browser before you call it done.
Capabilities this touches