Custom 404 pages and soft 404s: serve the error page with the error status

What it is

Google's troubleshooting documentation defines a soft 404 as a URL that returns a page telling the user the page does not exist while also returning a 200 status, and lists causes such as a missing include file, a broken database connection, an empty search result page or a missing JavaScript file; such pages are excluded from Search. The same documentation recommends returning 404 or 410 for content that is gone, and describes a good custom 404 page as one that says clearly the page cannot be found, keeps the site's look and navigation, links to popular pages and the home page, and offers a way to report a broken link. Its status-code documentation adds that content from 4xx responses is not used and that a previously used URL now returning 4xx is dropped over time, with crawling frequency decreasing.

On the server, nginx's error_page defines the URI shown for given errors through an internal redirect, with the method changed to GET for non-GET requests. The same directive can change the status with =response; the documentation's own example, error_page 404 =200 /empty.gif;, shows how a 404 becomes a 200. Single-page applications that serve index.html for every path have the same effect by design.

Why it matters

A soft 404 wastes crawl requests, keeps dead URLs in indexes, hides broken links from monitoring (everything is 200), and confuses tools that treat status codes as truth. A hard 404 with a bare server page loses the visitor instead.

How to apply

• Configure the error page (error_page 404 /404.html;) without =200, and confirm with curl -I https://example.com/no-such-page that the status line says 404 and the body is your page.
• For single-page applications, return 404 from the server for paths the router does not know, or have the application render an error state and, where the framework supports it, set the status on the server-rendered response.
• Make the page self-contained: inline critical styles or reference fingerprinted assets by absolute path, because the failing URL may sit in a deep directory.
• Log 404s with referrer and review them; the frequent ones deserve a redirect, the rest a fix at the linking page.
• Use 410 for deliberate removals if you want to state permanence; the linked open question discusses how clients treat it.

Pitfalls

Redirecting all unknown URLs to the home page (a soft 404 with a 302). Error pages that load resources by relative path and break in subdirectories. Error pages that themselves return 404 for their assets, or 500 because a template needs data that a not-found request lacks.

Single-page applications without a server route table

Most single-page applications cannot return 404 from the server for unknown routes, because the server does not hold the route table and parameterised routes need a data lookup. Google's JavaScript SEO documentation gives two alternatives its crawler honours: redirect from JavaScript to a URL the server answers with 404 (for example /not-found), or add <meta name="robots" content="noindex"> to the document from JavaScript when the application determines that the page does not exist. Both keep the page out of the index; neither gives monitoring a status code, so prefer prerendering or server-side rendering of the not-found state with a real 404 where the framework supports it, and use the JavaScript methods for the rest.