HTTP 404 Not Found Error: How to Fix and Manage Redirects

The 404 error means that the server was found, but it could not locate the requested resource. This can be correct, such as in a mistyped URL, or indicate a defect, such as an internal link pointing to a removed page. The solution depends on the destination that should have existed.

Direct Response: How to Fix a 404 Error

Confirm the URL and HTTP status, find out where the access came from, and choose one of these actions: restore the page, fix the link, redirect to an equivalent substitute, or keep 404/410 if the content has disappeared without a substitute. Do not redirect every error to the homepage.

Step 1: Confirm the Actual Status

A page with a "not found" message may respond with 200, creating a soft 404. Check with:

curl -I https://exemplo.com/pagina

The beginning should show HTTP/2 404 when the page truly does not exist. Also test variations with a trailing slash, uppercase letters, parameters, and the www domain. In JavaScript applications, confirm both visual navigation and the server's initial response.

Step 2: Locate the Source

Use the Search Console page report, server logs, and a link crawler. For each occurrence, record the broken URL, source page, accesses, external links, and possible substitutes. Internal links are a priority because they are under your control.

Step 3: Restore or Redirect

If the page has been moved, point directly to the most equivalent destination. Avoid chains like old → intermediate → new. In Nginx:

location = /old-guide {
  return 308 /new-guide;
}

In Next.js, keep the redirect mapping versioned. After deployment, test the old URL and confirm the Location header, status, and final page.

If there is no substitute, a legitimate 404 is better than sending the user to an irrelevant page. For an intentional and permanent removal, 410 Gone explicitly communicates this condition.

Step 4: Create a Useful 404 Page

The page should explain what happened, preserve navigation, allow users to go back, and offer search or main paths. It should not pretend that the content exists nor use the canonical of the homepage. The most important thing is to maintain the correct HTTP response.

Step 5: Clean Sitemap and Links

Remove 404 URLs from the XML sitemap. Update menus, articles, canonicals, hreflang, and structured data. A redirected URL should also not continue to be the published canonical version in the sitemap.

Diagnosis in Applications and APIs

In an API, differentiate "endpoint does not exist" from "record does not exist." Return a stable structure without exposing internal details:

{
  "error": "not_found",
  "message": "Resource not found",
  "requestId": "req_123"
}

Log the method, normalized route, and request identifier. If the protected route should not reveal the existence of a resource, the application may deliberately respond with 404 instead of 403.

Checklist After Correction

• the old URL returns the planned status;
• the redirect reaches the destination in one jump;
• the destination responds with 200 and has its own canonical;
• sitemap does not contain removed URLs;
• no internal link points to the error;
• the 404 page works on mobile and maintains navigation.

See also the differences between error 401, error 500, and error 502.

Frequently Asked Questions

Do many 404s harm SEO?

Non-existent URLs are normal. The problem is wasting the experience, keeping broken internal links, or signaling wrong pages in the sitemap.

Should I redirect all 404s to the homepage?

No. This confuses users and search engines and can be interpreted as a soft 404.

Primary Sources

• MDN: status 404 Not Found
• Google Search Central: 404 errors
• RFC 9110: HTTP Semantics