An HTTP 404 status means the server could not find a resource at the requested URL. It does not necessarily mean the entire website is down. A single missing page, a mistyped path, a deleted file, or an application route that no longer exists can all produce a 404 response.

The right fix depends on whether the page should exist, whether its URL changed, and whether the request is reaching the correct application.

Confirm the Actual Response

Start by checking the exact URL and the HTTP status code. A page that visually says “not found” may return 200, while a custom error page may return 404 correctly. Search engines and monitoring tools rely on the HTTP response, not only the wording shown in the browser.

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

Review the status, server headers, and any redirect chain. If the response redirects several times before ending at a 404, inspect each hop rather than focusing only on the final page.

Common Causes

• The visitor entered an incorrect URL.
• A page was deleted or renamed without a replacement redirect.
• A link points to an outdated slug or path.
• WordPress rewrite rules or permalink configuration are incorrect.
• A deployment omitted a file or route.
• The request reached the wrong document root or virtual host.

Check Whether the Page Should Exist

If the page was removed accidentally, restore it from a backup or recreate it at the intended URL. If the content moved, map the old URL to the closest relevant replacement. If the content was intentionally retired and has no useful substitute, returning a genuine 404 or 410 may be more appropriate than redirecting every visitor to the homepage.

A redirect should preserve intent. Sending an old product URL to an unrelated page can confuse visitors and may not solve the underlying navigation problem.

WordPress-Specific Checks

For WordPress, confirm the post or page is published and that its slug is correct. Review Settings > Permalinks and save the settings to refresh rewrite rules when appropriate. If the issue affects many routes after a migration, inspect web-server rewrite configuration and confirm that requests reach the WordPress front controller.

Also check whether a security, caching, or redirect plugin is intercepting the request. Test in staging or disable components carefully, especially on a production site.

Distinguish a Missing File From a Missing Route

A static file request may fail because the file is absent, has the wrong case, or is outside the configured document root. On case-sensitive filesystems, Logo.png and logo.png are different names. A dynamic route may instead depend on application routing, rewrite rules, or database content.

Use Redirects Selectively

A 301 redirect is generally used when a URL has permanently moved. Use a temporary redirect when the move is temporary. Avoid chains and loops, and test query-string behavior if parameters matter. Keep a redirect map during migrations so important old URLs lead to their corresponding new pages.

Monitor After the Fix

Check server logs and Search Console or other crawl reports for repeated 404s. Prioritize URLs linked from your own navigation, receiving external links, or getting meaningful traffic. A few requests for random nonexistent paths are normal on public websites and do not require creating pages for every request.

Check Internal Links and Sitemaps

Once the response is corrected, update navigation, related-post links, and XML sitemaps so they point to the current URL. A redirect can preserve access to an old address, but internal links should generally lead directly to the destination. Recheck the page from a logged-out browser and confirm that the server returns the intended status.

Final Thoughts

A 404 is a useful signal, not automatically a hosting failure. Verify the status, determine whether the resource should exist, and fix the underlying link, route, file, or migration mapping. Use redirects only when there is a relevant destination, and monitor important URLs after the change.