404 Errors, 410s & Redirects: When to Fix, Redirect, or Let a URL Stay Gone

A 404 error is not automatically an SEO problem.

Sometimes a missing URL is a mistake: an important page was deleted, a migration mapped the URL incorrectly, or an internal link still points to an old address. In those situations, the site needs to be fixed.

Other times, the page is genuinely gone and there is no replacement. In that case, returning a 404 or 410 can be exactly the right technical response.

The real SEO task is not eliminating every 404. It is determining why the URL is missing and choosing the response that best matches what happened to the resource.

What is a 404 error?

A 404 is an HTTP status code indicating that the server could not find the requested resource at that URL.

For example, someone may request:

https://example.com/old-product/

and the server may respond:

HTTP/1.1 404 Not Found

That response does not, by itself, mean something is wrong with the website.

The important question is whether the URL is supposed to exist.

Do 404 errors hurt SEO?

A legitimate 404 does not create a sitewide ranking penalty.

Websites naturally accumulate URLs that no longer exist, URLs people type incorrectly and URLs crawlers discover from old or external references.

The presence of those responses is not the problem.

Problems arise when important content accidentally returns 404, when your own site continues linking users to dead URLs, or when a missing URL should have been redirected to a clear replacement.

That distinction matters:

A correct 404 is normal. An incorrect 404 is a defect.

Why is this URL returning 404?

Before implementing a redirect, determine what actually happened.

When should a 404 become a 301 redirect?

Use a permanent redirect when the old URL has a genuine new destination.

Good examples include:

• a page permanently moved to a new URL;
• two articles were consolidated into one definitive resource;
• a discontinued product has a genuine successor;
• a site migration changed the URL structure;
• or an old domain moved permanently to a new one.

The destination should satisfy substantially the same need as the original page.

For large redirect implementations, see our enterprise 301 redirect guide.

Do not redirect simply to eliminate a 404

A redirect should communicate a real relationship between the old and new URLs.

Suppose an old guide about canonical tags disappears.

This is usually poor handling:

/old-canonical-guide/
→
/

The homepage does not replace a canonical-tag guide.

If a new canonical guide exists, redirect there.

If no equivalent resource exists, a 404 or 410 may be more accurate.

A similar page is not always a replacement

Topical similarity is not enough.

If someone requests a specific product, article or service, sending that person to a loosely related page can create a worse experience than clearly saying the old resource no longer exists.

Before redirecting, ask:

Would someone looking for the old resource reasonably consider this destination its replacement?

If the answer is no, do not force the redirect.

What is the difference between 404 and 410?

Both status codes communicate that the requested resource is unavailable.

A 404 Not Found means the server cannot find the resource at that URL.

A 410 Gone more explicitly communicates that the resource was intentionally removed.

For Google Search, both are appropriate when content has been removed and there is no similar replacement that should inherit the URL relationship.

You do not need to convert every intentional deletion into 410. A properly configured 404 is also a valid response.

Restore valuable pages that disappeared accidentally

Not every 404 needs a redirect.

Sometimes the correct response is to put the page back.

This can happen when:

• a CMS migration fails to import a page;
• a product database drops a valid record;
• someone unpublishes a page accidentally;
• routing changes break a previously working URL;
• or a deployment removes a template unexpectedly.

If the resource still belongs at the same URL, restoration is usually cleaner than creating a new URL and redirecting unnecessarily.

Broken internal links are a separate problem

Your site may contain a legitimate 404 and still have an issue because another page links to it.

For example:

/services/
→ /old-service/
→ 404

If the old service has no replacement, the 404 can remain correct.

The broken internal link from /services/ should still be removed or updated.

Do not confuse:

“This URL should not exist anymore”

with:

“Our website should continue linking users to it.”

Audit internal links to missing URLs

A crawl can help identify pages that link to 404 or 410 destinations.

Prioritize links appearing in:

• main navigation;
• footer navigation;
• breadcrumbs;
• high-traffic pages;
• commercial landing pages;
• product/category modules;
• and frequently used editorial content.

The fix may be to update the source link rather than changing the missing URL's HTTP response.

What if external websites still link to the 404?

An inbound link to a missing URL deserves investigation because users may still be following it.

Possible solutions include:

• restoring the original resource;
• redirecting to a genuine updated replacement;
• asking the publisher to update the link;
• or allowing the URL to remain gone when no appropriate destination exists.

Do not redirect an irrelevant page merely to preserve a backlink.

The destination still needs to make sense for the user who follows the original reference.

What is a soft 404?

A soft 404 occurs when a URL behaves like a missing or unusable page without returning an appropriate missing-page status.

A common example is:

HTTP/1.1 200 OK

Product Not Found

The server says the request succeeded, while the page tells the visitor that the requested content does not exist.

Google may identify this mismatch as a soft 404.

Common causes of soft 404s

Soft 404s can occur when:

• a missing-page template returns 200;
• a page is almost empty;
• important content fails to render;
• an internal search result has no results but returns an indexable success page;
• a product template displays “not found” while returning 200;
• or a JavaScript application does not set an appropriate error response.

The correct fix depends on whether the page should actually exist.

If the page should exist, fix the page—not the status report

A useful page can sometimes be classified as a soft 404 when Google receives little usable content because of:

• failed JavaScript;
• blocked resources;
• template errors;
• database failures;
• or incomplete rendering.

If the page is legitimate, restore the missing content and verify what search crawlers actually receive.

Do not intentionally turn a valuable page into a real 404 simply because Search Console reported a soft 404.

JavaScript sites need explicit missing-page handling

Single-page applications can make error handling more complicated.

A browser-side router may display a “not found” component while the web server responds with 200 OK.

Test nonexistent URLs at the HTTP level.

Where possible, configure the application and server so missing resources communicate an appropriate status code.

If technical constraints make that difficult, additional index-control handling may be necessary, but a visually correct error message alone is not sufficient technical QA.

Create a useful custom 404 page

A custom 404 page can make an unavoidable dead end much less frustrating.

Useful elements can include:

• a clear message that the page could not be found;
• normal site branding and navigation;
• a link to the homepage;
• links to major sections;
• a site search option where useful;
• and a way to contact support or report a broken link.

The page should help the visitor recover without pretending the requested resource still exists.

A custom 404 page must still return HTTP 404

This is one of the most common mistakes.

A beautifully designed missing-page template that responds:

HTTP/1.1 200 OK

does not become technically correct because it looks good.

The server should still communicate that the requested URL was not found.

Do not use 404 for a temporary outage

A missing resource and an unavailable service are not the same condition.

If a valid page cannot be served temporarily because of maintenance or infrastructure trouble, use the response that accurately describes the server condition rather than pretending the page does not exist.

For example, a temporary service outage may call for a 503 Service Unavailable response.

Do not use 404 as a generic error code for every technical failure.

How should ecommerce sites handle unavailable products?

Ecommerce creates several distinct cases.

Temporarily out of stock

If the product is expected to return, keeping the page live is often more useful than deleting the URL.

Clearly communicate availability and provide appropriate alternatives or notification options.

Permanently discontinued with a true successor

If a new model directly replaces the old one, a permanent redirect may make sense.

Permanently discontinued but still useful

Some product pages retain value for:

• manuals;
• specifications;
• support;
• compatibility;
• replacement parts;
• or historical research.

In those situations, keeping the page available can serve users better than deleting it.

Permanently removed with no useful replacement

If the page has no continuing value and no meaningful replacement, a 404 or 410 can be correct.

Do not automatically redirect discontinued products to a category

A category page can sometimes be a useful replacement.

It is not automatically one.

If the old product represented a very specific need and the category contains hundreds of unrelated products, silently dropping the visitor into that category may not preserve the original intent.

Use judgment rather than a sitewide “deleted product → parent category” rule.

Expired articles and events can still deserve a live page

A page does not need to disappear because its date passed.

An old event page may still contain:

• videos;
• speaker information;
• research;
• presentations;
• transcripts;
• or historically useful context.

An older article can remain useful when its information is still accurate or has been appropriately updated.

Delete pages because they no longer serve a purpose—not merely because they are old.

What should happen to typo URLs?

People and crawlers request URLs that were never legitimate pages.

For example:

/enterpirse-seo-services/

does not require a permanent redirect simply because the correctly spelled page exists.

If the typo appeared in your own marketing, earned links or significant traffic, fixing it with a redirect can make sense.

If it is a random one-off request, a normal 404 is fine.

Bot-generated URLs do not all require fixes

Server logs often contain requests for:

• files that never existed;
• old CMS endpoints;
• malicious probe URLs;
• random parameters;
• mistyped paths;
• and automated scanner requests.

Do not create redirects for every URL merely because a bot requested it.

First determine whether the URL was ever part of the actual website or represents a legitimate user journey.

Use Search Console to investigate—not to chase a zero-404 score

Google Search Console can help identify URLs Google encountered that are not being indexed because they return errors or appear to be soft 404s.

Use that information to ask:

• Should this URL exist?
• How did Google discover it?
• Does it have a replacement?
• Does our own site still link to it?
• Is the HTTP response correct?

The goal is not to make the 404 count reach zero.

Use crawls to find broken internal pathways

A crawler is particularly useful for finding links on your own website that lead to missing destinations.

That can reveal:

• outdated editorial links;
• navigation problems;
• broken image/file references;
• old product links;
• migration leftovers;
• and URLs still embedded in templates.

Fix the source of the broken path rather than automatically creating a redirect for every destination.

Use server logs to prioritize repeated requests

Log data can show whether an old missing URL continues receiving substantial crawler or user traffic.

This is useful for prioritization.

A retired page receiving thousands of legitimate requests deserves investigation.

A malformed URL requested once by an automated scanner generally does not.

Request volume can tell you where to look first, but it does not determine whether a redirect is relevant.

Remove intentionally missing URLs from XML sitemaps

Your active XML sitemap should represent current preferred URLs you want search engines to discover.

If a page has been permanently retired and now returns 404 or 410, remove it from the current sitemap.

Do not redirect the page merely because sitemap maintenance was overlooked.

Fix internal references to removed pages

After intentionally retiring a page, check whether current site components still reference it.

That can include:

• navigation;
• breadcrumbs;
• related-content modules;
• article links;
• product recommendations;
• and category templates.

A correct 404 should not become a permanent destination in the site's active user journey.

301 and 302 redirects solve different conditions

A 301 communicates a permanent move.

A 302 communicates a temporary one.

The distinction should be based on what is actually happening to the resource—not an old “link juice” formula.

When a page permanently moves and the destination should replace it, use an appropriate permanent redirect.

When the original URL is expected to resume its role, a temporary redirect may be appropriate.

404 errors and canonical tags are not interchangeable

A canonical tag does not repair a missing URL.

Canonicals are used when accessible duplicate or substantially similar URLs exist and one should be treated as preferred.

If a URL is gone, decide whether it should:

• redirect;
• return 404;
• return 410;
• or be restored.

Our canonical tags guide covers the separate canonicalization decision.

How to prioritize 404 cleanup

Not every missing URL deserves the same amount of work.

A practical workflow for handling a missing URL

1. Confirm the response. Check whether the URL actually returns 404, 410, 200, a redirect or another response.
2. Determine whether the page should exist. If it was removed accidentally, restore it.
3. Look for a genuine replacement. If the resource permanently moved or was consolidated, redirect appropriately.
4. Allow legitimate removals to stay gone. Use 404 or 410 when there is no meaningful replacement.
5. Check internal links. Remove or update links from current pages to retired URLs.
6. Review inbound links and traffic. Prioritize important old URLs without forcing irrelevant redirects.
7. Check for soft 404 behavior. Confirm the status code matches what the page actually displays.
8. Remove retired URLs from active sitemaps. Keep the sitemap focused on current canonical URLs.
9. Monitor recurring requests. Use Search Console, crawls and logs to identify important patterns.

404 errors and AI search

There is no special AI-specific 404 status or documented universal “404 penalty” for generative recommendations.

A broken URL can obviously prevent a crawler or retrieval system from accessing a resource at that address, so accurate URL management remains part of healthy web infrastructure.

The correct approach is still to fix the underlying web problem: restore valuable resources, maintain valid redirects where content moved, and return honest missing-page responses when content is gone.

If AI visibility matters to the business, measure brand mentions, citations and prompt-level visibility separately rather than assuming every technical 404 directly changes recommendation performance.

A healthy website can contain legitimate 404s

The objective of technical SEO is not to build a website where the server never says “not found.”

The objective is to make the response accurate.

If someone requests a page that exists, serve it.

If it moved, send them to its real replacement.

If the URL broke because of your own internal linking, fix that path.

If the resource is permanently gone and nothing replaces it, say so with the correct status.

That is cleaner for users, easier to maintain and more technically honest than building a web of redirects whose only purpose is hiding every 404 from an audit report.

Frequently Asked Questions

Do 404 errors hurt SEO?

Legitimate 404 responses do not create a sitewide ranking penalty. Problems arise when important pages accidentally return 404, users encounter broken internal links, or an old URL should have been redirected to a genuine replacement.

Should every 404 be redirected?

No. Redirect a URL when the content moved or there is a clear replacement. If the resource is permanently gone and no meaningful replacement exists, a 404 or 410 can be the correct response.

What is the difference between a 404 and a 410?

A 404 means the requested resource was not found. A 410 more explicitly means the resource has been intentionally removed. Google accepts both when content is permanently unavailable and there is no similar replacement.

What is a soft 404?

A soft 404 occurs when a page behaves like a missing or unusable page without returning an appropriate missing-page response. A common example is a “Product Not Found” page that returns HTTP 200. Google may classify that URL as a soft 404.

Should a custom 404 page return 200?

No. A custom 404 page can include branding, navigation, search and helpful links, but the missing URL should still return an appropriate 404 response.

Should a discontinued product redirect to the category page?

Only when the category is a genuinely useful replacement for someone requesting that product. A true successor product may be a better destination. If the old page still provides useful support or specification information, keeping it live can also make sense. If there is no replacement or continuing value, 404 or 410 may be appropriate.

Should I redirect typo URLs?

Usually not. Random mistyped URLs can simply return 404. A redirect may be worthwhile when a particular typo was previously published, has meaningful backlinks or receives substantial legitimate traffic.

What should I do with internal links pointing to 404 pages?

Update or remove the internal link. If the missing page has a genuine replacement, point the link directly to that current URL rather than relying on a redirect whenever possible.

Should 404 URLs stay in my XML sitemap?

No. The active XML sitemap should generally contain current canonical URLs intended for discovery and indexing. Pages that have been intentionally removed should be removed from the active sitemap.

Do 404 errors directly reduce AI visibility?

There is no documented universal AI-specific 404 penalty. Broken URLs can make a resource unavailable at that address, but technical URL management and AI visibility measurement should be treated as separate issues.