Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

HTTP errors

What does 404 Not Found mean, and how do you fix it?

A 404 means the server has nothing at that address. Why it happens, when it is the correct answer, and how to stop broken links costing you visitors.

404 Not Found means the server has nothing at the requested address. On your own site it usually comes from a moved page without a redirect, a typo in a link, or a deleted file. Fix the links that point there, redirect moved pages with a 301, and let genuinely removed pages return 404.

Published · Last updated

By Michal Měřínský. Audit methodology.

What 404 Not Found means

404 is the status a server sends when it has nothing at the address you asked for. The server is working and reachable. It simply has no page, file or route matching that path. The HTTP specification also allows a server to answer 404 when a resource exists but the server does not want to reveal it, which is why some private pages answer 404 rather than 403.

Two neighbors are worth knowing:

  • 410 Gone - the page existed and was removed on purpose, and nothing will replace it. Search engines treat it almost exactly like 404.
  • Soft 404 - a page that says not found but sends status 200. Visitors see an error, crawlers see a normal page, and that mismatch is the real bug.

If you are a visitor

A 404 on someone else's site means the link you followed is out of date or mistyped. Check the address for a typo, try removing everything after the last slash, or use the site's search. If you came from a search result, the page has probably moved and the result is stale.

Why your own site returns 404, most likely first

  • A page was renamed or moved and nobody added a redirect from the old address.
  • A link in your navigation, footer or content has a typo or points to a draft path.
  • A file was deleted or never deployed, such as an image, PDF or script referenced from a page.
  • Case sensitivity. /About and /about are different paths on most servers, and links copied by hand often mix them.
  • A single-page app without a fallback. Client-side routes work when you click through the app but return 404 on a direct visit or refresh, because the server has no file at that path.
  • Trailing slash rules that disagree between your links and your server.

How to fix it

Start by finding which 404s actually matter. A 404 for a URL nobody links to is harmless. A 404 linked from your own menu or from another site is losing visitors every day.

Check the exact status a URL returns:

curl -sI https://example.com/old-page

Then fix by case:

  • Moved content: add a 301 redirect from the old URL to the closest equivalent page, not to the homepage.
  • Broken internal links: correct the link at its source. A redirect that patches your own typo is a permanent hop you did not need.
  • Single-page apps: configure the host to serve your index file for unknown paths, and let the app render a real not-found view for routes it does not know.
  • Removed content with no equivalent: leave it as 404 or 410. That is the honest answer.

Never redirect every 404 to the homepage. Google treats that as a soft 404 anyway, and visitors land on a page that does not answer what they clicked.

When a 404 is the right answer

Most 404s on a healthy site are correct: old campaign pages, deleted products with no successor, mistyped addresses, bots probing for files you never had. What matters is that the response is an honest 404 status, and that the error page helps a person recover, with navigation, search and a link home.

Google treats every 4xx response except 429 as a page that is not there. An indexed URL that starts returning 404 is removed from the index. That is fine for content you meant to remove and costly for content that simply moved, because the signals that page had built up are lost unless a redirect carries them.

404s do not harm the rest of your site. Google has said for years that a site with many 404s is not penalised for them. The cost is narrower and real: every broken link wastes a visitor and a crawl.

What a scan can and cannot tell you

WebAuditOS reports eligible crawled 4xx and 5xx responses and broken internal targets, excluding 401, 403, 429 and recognized bot challenges. A separate fixed-path probe checks soft 404 behavior; the helpfulness check warns when the first crawled 404 has fewer than three same-host links. Together those cover the 404s you created yourself.

It cannot see links pointing at you from other sites, or old URLs that only exist in someone's bookmarks. The place to find those is the Page indexing report in Google Search Console and your server's access log, filtered by status 404.

A crawl only follows links it can reach. A page that returns 404 and is linked from nowhere on your site will not appear in any crawl-based report, ours included.

Short answers

Is a 404 bad for SEO? Only for pages that should exist. Fix moved pages with redirects and leave genuinely removed pages as 404.

404 or 410 for a deleted page? Either works. 410 says the removal was deliberate.

Should a custom 404 page return 200? No. It should look friendly and still send status 404.

Why does my app work locally but 404 on refresh in production? The host is missing a fallback to your index file for client-side routes.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.