Fix 404 Pages That Redirect to the Homepage: A Five-Step Checklist

If deleted URLs automatically send visitors to your homepage, first find the rule responsible, then classify each old URL. A page with a relevant replacement needs a deliberate redirect; a page that is genuinely gone needs an honest not-found response. Changing the design of the error page alone does not change its HTTP status.

This checklist is for fixing an existing implementation. For the broader explanation, see how homepage redirects, error responses and replacement pages differ. Keep a record of the original behavior before changing anything, especially if the same rule also handles valid migrations.

1. Capture the Response Before Following the Redirect

Start with a deleted URL you recognize and a deliberately nonexistent URL on your own site. Also include a valid page as a control. Open each in a fresh browser session and inspect its document request in the Network panel with the request log preserved. Record the first response, every redirect and the final destination.

A command-line request helps separate the HTTP response from what the browser displays. These commands use a reserved example domain; replace it with the site you are authorized to inspect:

# First response to a GET request, without following redirects
curl -sS -D - -o /dev/null 'https://example.com/deleted-product/'

# Follow the chain and display each set of response headers
curl -sS -L --max-redirs 10 -D - -o /dev/null 'https://example.com/deleted-product/'

The command's redirect limit is a testing setting, not a statement about how many redirects Google accepts. Prefer a direct route to the appropriate destination rather than adding intermediate hops.

A soft 404 is an interpretation of a page's response and content, not a separate HTTP status code. Do not identify it solely from the final homepage URL or assume that every 404 is an error that needs a redirect.

2. Find the Broad Rule Without Removing Valid Mappings

Check the layers that can answer a request: CDN redirect rules, web-server configuration, CMS redirect plugins, theme code and application routing. A common problem is a catch-all rule that sends every unmatched path to the homepage. Another is an error handler that fetches the homepage internally and returns it with a 200 response.

In WordPress, look for options named “redirect all 404s,” “fallback destination” or similar. Export the plugin's redirect list before changing those settings. In an application, distinguish valid client-side routes from genuinely missing resources; a single-page application's routing fallback must not turn every arbitrary URL into an apparently valid content page.

1. Save the current rule and its position in the rule order.
2. List specific redirects that still serve a legitimate move.
3. Disable or narrow the catch-all rule in a test environment.
4. Confirm that the specific mappings still work and an unknown path now receives the intended error response.
5. Publish the scoped change and repeat the same requests through the public hostname.

When the origin and public hostname disagree, check edge caching and overlapping rules. Clearing one browser's cache does not prove that the CDN or application cache has been updated. Retest both a previously requested URL and a fresh nonexistent path.

3. Assign a Destination Based on the Missing Page's Purpose

Create a mapping sheet before bulk changes. Record the old URL, what it used to provide, whether it is still needed, the proposed treatment, the destination if any, and the person who approved it. A destination should meet the visitor's original need; sharing a few words or belonging to the same broad industry is insufficient.

A category page may sometimes be a useful replacement, but it is not automatically suitable for every discontinued product. A buyer looking for an old model's wiring diagram may still need an archived support page. Sending that person to a general catalog would not preserve the original task.

For example, imagine that /products/pump-a/ was only renamed to /industrial-pumps/pump-a/. That is a straightforward mapping. If Pump A was retired, Pump B has different connections and the old installation manual is still needed, first decide how to preserve support information instead of treating Pump B as an interchangeable destination. This is a planning example, not a client result.

4. Repair the Links That Still Point to the Old URLs

A redirect helps requests that arrive at an old address. It does not replace maintenance of the links you control. Update navigation, category pages, article links and other active references to point directly to the correct destination.

Use Screaming Frog or an equivalent crawler to find links to missing pages and redirect chains. Review the linking page as well as the target: sometimes the source sentence refers to a discontinued offer and needs an editorial update, not just a new URL.

• Remove permanently missing URLs from active sitemaps; list the current canonical pages instead.
• Update canonical and language-alternate references that still name replaced URLs.
• Check image, video and download URLs separately. A missing manual should not return the homepage's HTML.
• Keep a useful 404 page with a clear message and relevant navigation. Include site search only if it actually works.
• Review important external references to old pages and request an update where practical.

Do not use robots.txt as a substitute for the intended missing-page response. A crawler that is blocked from fetching the URL cannot inspect the status you changed.

5. Verify the Change and Keep a Rollback Record

Repeat the same test set after release: a real removed page, a random unknown path, a moved page, a valid page, a missing asset and any temporary-maintenance route. Check both the first response and the final rendered page. Test mobile navigation on the error page so visitors have a usable next step.

Use a small acceptance table rather than marking the work complete because the homepage still opens:

For an owned site, Search Console can provide additional URL inspection and indexing information. Its reports can lag behind a deployed change, so keep the deployment time and response evidence rather than repeatedly changing a correct implementation to make an old report disappear.

Retain the previous configuration, the approved mapping sheet and the test results together. If a legitimate route breaks, restore the relevant rule or mapping and rerun the control cases. The finished result is specific: useful old content reaches its proper successor, genuinely missing resources return an honest status, and visitors are offered a sensible next step.