Server 404 checker

When a browser or crawler requests a URL that doesn't exist, the server should respond with HTTP status 404 Not Found (or 410 Gone if the page was intentionally removed). That single number tells every downstream system — browsers, bookmarking tools, Google's crawler — that the URL has no content. A "soft 404" is when the server instead returns 200 OK along with a "Page not found" HTML page, or redirects to the homepage. The user experience looks the same, but machines can't tell the difference between a real page and a missing one. Google has a dedicated Soft 404 report in Search Console because this is one of the most common and most harmful indexing bugs.

What this tool checks

• Requests a random non-existent URL — we generate a probe path like /seorado-probe-404-{random} that cannot coincide with a real page
• Reads the HTTP status code — without following redirects, so we see the server's actual response, not where a redirect sends us
• Classifies the response — 404/410 is correct; 200 is a soft 404 (bad); 3xx is a redirect anti-pattern (attention); 401/403 means the site is auth-gated and the check is inconclusive; 5xx means the server crashes on unknown paths

Why soft 404s hurt SEO

• Wasted crawl budget — Googlebot keeps revisiting URLs that return 200, believing they host content. Large sites with thousands of soft 404s (common in SPAs) can starve real pages of crawl attention
• Index bloat — some soft 404s end up in the index as thin, duplicate, or low-quality pages. This drags down the perceived site-wide content quality
• Slow deindexing of real removals — when you legitimately delete a page, a soft 404 means Google doesn't learn that it's gone. The URL lingers in the index for weeks or months
• Search Console Soft 404 report — flags every detected instance sitewide. Pages listed here are actively hurting your indexing health; manual fixing is the canonical action
• Redirect-to-homepage anti-pattern — a 301 from every unknown URL to / is treated by Google as "equivalent to soft 404" per their own documentation, because the redirect target returns 200 and the crawler concludes the URL has real content

Good vs bad examples

Good — Nginx with a proper 404 page:

error_page 404 =404 /404.html;
location = /404.html {
  internal;
}

The =404 part is the critical override — without it, Nginx serves /404.html with status 200, creating a soft 404.

Good — Apache:

ErrorDocument 404 /404.html

Good — Express (Node.js):

app.use((req, res) => {
  res.status(404).render('404');
});

Bad — the most common Express mistake (forgets the status):

app.use((req, res) => {
  res.send('Page not found');  // ← sends 200 OK
});

Bad — SPA catch-all that serves the app shell for every path:

location / {
  try_files $uri /index.html;  // ← every unknown URL → 200 with app shell
}

Bad — redirecting every unknown path to the homepage:

location / {
  try_files $uri @fallback;
}
location @fallback {
  return 301 /;  // ← Google treats this as soft 404
}

Common mistakes

• SPA catch-all routes serving index.html with 200 — React/Vue/Angular apps where the server falls through to the app shell for unknown paths. The client-side router then shows a "404" component, but the HTTP status never becomes 404. Fix: use a framework-level 404 handler (Next.js not-found.tsx, Nuxt error.vue, React Router status={404} on the server render, or a small Node middleware that checks the resolved route and sets the status before responding)
• Missing =404 in Nginx error_page — without the status override, Nginx serves the custom 404 page but with status 200. Always write error_page 404 =404 /404.html
• Redirecting to the homepage for "SEO" — sometimes done deliberately to "keep users on the site". Google explicitly documents this as equivalent to soft 404. Return 404 honestly
• Returning 200 for moved pages — if a page actually moved, use 301 Moved Permanently to the new location. 301 is fine, 200-on-the-wrong-URL is not
• Custom CMS plugins that override status codes — WordPress, Drupal, and similar platforms sometimes have plugins that serve a "friendly error page" with status 200 instead of 404. Check the response headers, not the page content