On 3 August we ran a check that takes about ten minutes, on five websites we own. We asked each one for a page that definitely does not exist — /nonexistent-xyz123 — and we asked as Googlebot rather than as a browser.
Four of the five answered 200 OK and served the homepage.
That is not a small cosmetic problem. It is a website telling a search engine that every mistyped address, every dead link from an old business card, and every URL a scraper ever invented is a real page worth indexing.
What the check actually returned
The results, verbatim from that morning:
- cosmoswebtech.com.au — 200, titled “Cosmos Web Tech | Web Design & SEO Sydney”
- eawesome.com.au — 200, titled “Awesome Apps | Mobile App Development”
- insights.cloudgeeks.com.au — 200, titled “AI & Cloud Insights for Australian S…”
- ashganda.com — 200, titled “Ash Ganda - Technology Leadership & AI”
- g-t-s.com.au — 404, correct
Four sites, every one of them returning the homepage under a made-up address, complete with the homepage’s title, its canonical tag and its og:url.
Why a 200 is worse than a 404 here
There is a reasonable instinct that says a broken link showing something is better than a broken link showing an error. For a human visitor, sometimes. For a search engine, no.
A 404 is a clear statement: this address holds nothing, do not index it, stop asking.
A 200 with the homepage is a different statement entirely: this address holds a real page, and the page happens to be identical to our homepage. Google’s own term for this is a soft 404 — a page that behaves like a success but means “not found”.
Two things follow. Google may index duplicate copies of your homepage under arbitrary URLs, which dilutes the one page you actually want ranking. And your crawl budget, which is finite and much smaller for a small business site than most owners assume, gets spent re-fetching addresses that were never real.
If you have ever looked at Search Console and found pages indexed that you do not recognise, this is one of the ways it happens.
The cause was absence, not configuration
Our sites run on Cloudflare Pages. Pages does the right thing by default: for a route it cannot match, it serves dist/404.html with a genuine 404 status.
It does that only if the file exists.
None of those four sites had a 404 page in their source. So Pages fell back to index.html and returned it with a 200. Nobody had configured this. Nobody had made a wrong choice. The behaviour came from a file that was never created, on four separate websites, for as long as those websites had existed.
That is the uncomfortable part. There was no error in any log, no warning in any dashboard, and no broken page a visitor would complain about. The homepage loaded. It just loaded at the wrong address, forever.
The wrong turn, which is the useful bit
One site was correct. g-t-s.com.au returned a proper 404.
That site was also the only one of the five with a functions/_middleware.js file. The inference writes itself: the middleware must be handling unmatched routes, so port the middleware to the other four and the problem is solved.
We read the file before porting it. The middleware does domain aliasing and nothing else. It has no involvement in routing unmatched paths at all.
GTS was correct for an entirely unrelated reason: it happened to have a 404.astro page, added at some point for its own sake. The middleware was a coincidence sitting next to the real cause.
Had we ported the middleware, we would have made four repositories more complicated, verified nothing, and still had four sites answering 200 for every dead URL — while believing the matter was closed. Reading the file that supposedly worked, instead of copying it, turned a risky change across four codebases into one small page each.
Correlation in a small sample is extremely convincing. Five sites, one difference, one correct result. It was still wrong.
What we actually built
A real 404 page on each site. About a hundred lines, mostly layout and a short list of useful links so a visitor who lands there has somewhere to go.
One detail worth copying: every link on those 404 pages was written in the site’s trailing-slash form and checked against the actual build output before it shipped. A 404 page full of its own broken links is an easy thing to produce and an embarrassing thing to discover later.
Check your own site in ten minutes
You do not need tooling for this.
Type a nonsense address on your own domain. Something like yoursite.com.au/kjhgfd-not-a-page. If you see your homepage, you have a soft 404. If you see a page that says it cannot find what you asked for, you are probably fine — but confirm the status code, because a “not found” message can still be served with a 200.
Check the status, not the words. In Chrome, open DevTools, go to the Network tab, reload, and look at the status of the first request. It should say 404. Any free HTTP header checker will tell you the same thing.
Look at Search Console. Under Pages, the “Soft 404” reason is reported explicitly. If it is there, Google has already noticed.
Check every site you own, not the one you suspect. We assumed this was a one-site problem and found it on four. The only reason we caught the fourth is that we tested all five.
The general rule
A status code is a promise your website makes to a machine that will never see your design. Most website problems that survive for years are like this one: invisible to visitors, invisible in logs, and perfectly legible to a crawler that has been quietly acting on the wrong information the whole time.
If you would like a second pair of eyes on the technical side of your site, that is the kind of thing we do as part of SEO work in Castle Hill and across the Hills District and Blacktown. It is rarely the content that is holding a site back. It is usually something like this.
Ashish Ganda is the founder of Cosmos Web Tech, which builds and maintains websites for small businesses across Western Sydney and the Hills District.
