Soft 404: what it means and what to fix

Fixing a 404: repair the link that leads to it

A URL that returns 404 doesn't need to go away. What needs fixing is whatever sends visitors there: a link on your own site, in a page, a menu or a footer. Whoever clicks it expects a page and gets an error, because of a link you control.

In the sample report on a B2B business website, the footer logo links to /old-home, a URL that returns 404, on every page analyzed. The report lists it among the template defects: one link to fix, once, for every page that carries it.

The rest is decided URL by URL. A page that moved gets a single-hop 301 redirect to its new URL. A deleted page with no replacement keeps its 404. So does a URL that never existed, born of a typo or a bad link on another site: 404 is the right answer, and a helpful error page does the rest.

Soft 404: an error on screen, a success in the code

Every server response starts with a status code, and the HTTP standard (RFC 9110) defines what each one means. The text on the page is for the visitor. The code is for programs, such as search engines, browsers and link checkers, and many of them read nothing else. A soft 404 is a page that tells the visitor something went wrong while its code says everything worked.

Google doesn't stop at the code. When a page returns 200 but its content looks like an error, or the page is empty, Google may classify it as a soft 404 and report it in Search Console; its documentation on crawling errors calls this a bad user experience. Real errors are simpler: Google treats every 4xx error the same way, except 429. The URL drops out of the index and gets crawled less and less often, so for Google, 404 and 410 are equivalent.

Other programs stop at the code. On a site with soft 404s, a link to a deleted page returns 200, exactly like a working link, and any link check that reads status codes counts it as working. The site's dead links become invisible, and nobody knows they need fixing.

How a site ends up returning 200 for a missing page

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

The false success can come from a setting, from the way the site is built, or from content too thin for Google to tell it apart from an error:

• A custom error page served with a 200 code. The server or the CMS shows the intended page without the status code that should go with it.
• Every unknown URL redirected to the home page. A visitor who followed an old link lands on the home page with no way of knowing the page they wanted is gone, and the code they get at the end is a success. Google's documentation on site moves warns that redirecting many old URLs to one irrelevant destination, such as the home page, might be treated as a soft 404.
• An app rendered in the browser that returns the same document for every URL and lets the script display "page not found." Several AI website builders produce sites built this way; the guide to SEO for sites rendered with JavaScript covers how Google handles them and the two fixes it suggests.
• A page that exists but has nothing to show, such as a category with no products. Google may classify it as a soft 404 based on its content alone.

On a site made with an AI builder, soft 404s are one of the things to check; the others are covered in the guide to reviewing an AI-generated website.

A helpful error page, sent with a 404

None of this requires you to touch the server yourself. These are decisions to hand to your developer, your agency or your hosting provider, in this order:

1. Require the error page to be served with a 404 code. Same page, same design: only the code changes.
2. Have any rule that sends unknown URLs to the home page removed. Only pages that really moved keep a permanent redirect, one per URL, to their equivalent.
3. Have the links on your site that lead to a 404 fixed, starting with those in the template, such as the menu and the footer: one fix then covers every page.
4. Make the error page useful: it says plainly that the URL doesn't exist, keeps the site's header and navigation, and offers a way forward, such as the home page, search or the main sections. A visitor who followed an old link can then head for what they wanted instead of leaving.
5. For an empty category, decide whether it should exist. If it will have nothing to show for the foreseeable future, it returns 404; if it stays up, it needs content that doesn't read like an error.
6. After a redesign, a hosting move or a CMS change, have someone recheck what the site returns for an unknown URL. The setting lives on the server, and it doesn't always follow the site.

Files follow the same rule. A deleted image, script or stylesheet also returns a 404, and the page that requests it displays incomplete: the guide to images and files that no longer load covers them.

An error page served with a 200 code is fixed once, in the server or CMS settings, and a rule that sends every unknown URL to the home page comes out just as easily. It becomes a project on an app rendered in the browser, when the server doesn't know which URLs exist. The server then has to learn it, through server-side rendering or pre-rendering, or the site has to apply one of the two fixes Google describes. That changes how the site is built, and it needs planning.

A made-up URL, requested the way a visitor would

During the audit, a made-up URL that cannot exist on any site is requested from the server in a browser. Redirects are followed: what counts is the code received at the end.

• A 404 or 410 code: the response is correct, whatever page is displayed.
• A success code at the end, whether it comes with an error page, the home page or a blank page: that is a soft 404, counted as a defect under the user experience and reliability pillar, because visitors are the first to be affected.
• An access denial or an anti-bot challenge page: the server has not said what it returns for an unknown URL. The point is reported as not verifiable, never counted as compliant.

This test also tells you how to read the rest of the report. On a site with soft 404s, the audit's own dead-link count, which reads status codes, also counts a link to a deleted page as working: dead links can slip past it.

The test shows what the server returns for an unknown URL, not which URLs your visitors actually request. The audit runs into some of them while crawling the site: internal links that lead to an error are recorded on the pages in the sample, and a category page that announces it is empty is recorded with the sentence it displays.

The two published samples show the opposite case. The B2B business website and the online store both return a real 404. That is what made it possible to catch the footer link to /old-home on the first. On the second, it is what gives the result its weight: no broken internal link among all the links followed, and an error page, "Page non disponible" (page not available), served with the right code.