How to Fix 404 Error

How to fix 404 error starts with the cause. Restore the page if it was deleted by mistake, redirect it if the URL moved, correct the link if the URL is wrong, and return 410 if the content is intentionally gone. Then verify the status code, links, sitemap, and crawl path.

A 404 means the server is reachable but the requested URL does not resolve to a live resource. MDN defines 404 Not Found as a response status showing the server cannot find the requested resource at that address, which is different from a connection failure or DNS issue (MDN 404 reference). If you need the basics first, see http 404 error meaning.

How to fix 404 error: choose the right repair#

Most bad fixes happen because teams treat every 404 the same way. The right action depends on why the URL fails, not on the error message alone.

1. Restore the page when content was deleted accidentally but should still exist.
2. 301 redirect the old URL when the page moved permanently to a new address.
3. Fix the internal or external link when the destination URL was mistyped.
4. Repair server rules or permalinks when many valid pages suddenly return 404.
5. Return 410 Gone when content was removed on purpose and has no replacement.

This is also where YepAPI's On-Page Instant API fits. You can check live page responses, titles, canonicals, and other technical signals in code instead of testing broken URLs one by one.

What Error 404 Not Found usually means#

An Error 404 Not Found response usually points to one of six causes:

Google's crawling and indexing documentation explains that Google discovers URLs through links and sitemaps, so dead internal paths and stale sitemap entries create avoidable crawl waste (Google Search Central crawling docs). That is why fixing 404s is both a user-experience task and a technical SEO task.

Diagnose the cause before you change anything#

Start with the specific failing URL, not the whole site. Check the exact URL in a browser, then confirm the HTTP status with a command-line or API request.

A fast manual check looks like this:

1. Open the URL exactly as linked.
2. Confirm whether the homepage works.
3. Check whether a similar URL or updated slug exists.
4. Test the response headers with cURL.
5. Inspect where the bad URL is linked from.
6. Decide whether the page should exist, move, or disappear.

For header testing, cURL's documentation shows how to request only the response headers, which is enough to confirm a 404, 301, or 410 without loading the full page (cURL docs). A simple request is curl -I https://example.com/bad-url.

If one page fails, the problem is usually content, linking, or URL changes. If many pages fail, look at routing, rewrite rules, deploy changes, or CMS permalink settings.

Restore the page if it was deleted by mistake#

If the page should still exist, restoring it is the cleanest fix. This keeps the original URL alive, preserves inbound links, and avoids adding redirects you do not need.

Restore the page when the URL had traffic, backlinks, internal links, or a legitimate place in your site structure. After restoring it, recheck the status code and make sure the page is not blocked by robots directives or canonicals. For a broader technical pass after restoration, YepAPI's On-Page Instant API can validate the live page state at scale.

Use a 301 redirect when the page moved#

If the content now lives at a different URL, add a 301 redirect from the old path to the new one. A permanent redirect is the correct fix when users and crawlers should land on a replacement page.

Use a 301 only when the new page is a close match. Redirecting every broken URL to the homepage is usually a poor user experience and often the wrong technical choice. If you need the redirect basics, see what is 301 redirect and 301 redirect vs 302.

When you need to audit redirect behavior in code, YepAPI's Google SERP API helps you monitor whether important destination pages still appear as expected in search after a migration, while YepAPI's On-Page Instant API lets you test the old and new URLs directly.

Return 410 Gone when content is intentionally removed#

A 410 says the resource is intentionally gone and not expected to return. It is a better response than a 404 when the removal is deliberate and there is no relevant replacement page.

Use 410 for expired campaigns, retired product variants with no successor, or content that should disappear permanently. Do not use 410 for pages that merely moved. The decision is simple: restore, redirect, or 410 based on whether the content should exist now, elsewhere, or nowhere.

Fix the link when the URL is wrong#

Many 404s do not require redirects at all. If the problem is a mistyped slug, a trailing slash mismatch in a fragile setup, a bad relative path, or an outdated hard-coded link, fix the source link.

Prioritize broken internal links first because they hurt both users and crawl paths. Update links in navigation, templates, in-content links, breadcrumbs, XML sitemaps, and structured content modules. If you are doing a broader cleanup, technical seo best practices covers the surrounding checks.

For larger sites, YepAPI's On-Page Content API can help you review page content and on-page elements programmatically, and YepAPI's On-Page Instant API can recheck repaired targets after deployment.

Fix server, rewrite, or routing issues when many pages break#

When valid pages suddenly return 404, the problem is often infrastructure or CMS routing rather than missing content. Common causes include rewrite-rule changes, bad deploys, reverse-proxy path issues, and permalink resets.

Check these in order:

1. Recent deploy or server config changes.
2. .htaccess or rewrite rule edits.
3. CMS permalink settings.
4. Custom routing rules in the application.
5. Caching layers that still serve stale routes.
6. Canonical or internal-link rules pointing to nonexistent paths.

For a single-page diagnostic pass across many URLs, YepAPI's On-Page Instant API is the fastest fit. For full-site discovery and extraction workflows where you need to fetch many pages and inspect outputs in code, YepAPI's Web Scraping API is the scalable option.

WordPress 404 page fixes#

WordPress 404 issues often come from permalink or rewrite problems, not from deleted content. That is why a post can exist in the admin area yet still return a 404 on the front end.

Work through this sequence:

1. Save permalinks again in Settings → Permalinks.
2. Clear page cache, object cache, CDN cache, and browser cache.
3. Disable redirect, security, or SEO plugins one by one if the problem started after a change.
4. Check .htaccess for broken or missing WordPress rewrite rules.
5. Confirm the page slug and parent-child hierarchy did not change.
6. Test with a default theme if template routing may be involved.

WordPress all pages 404 except homepage#

When the homepage works but every inner page 404s, permalink or rewrite rules are the first suspect. In Apache setups, that usually means the .htaccess rules are missing or not being read. In Nginx setups, the route fallback may be wrong.

WordPress page not Found but it exists#

If the page exists in WordPress but still returns 404, check the slug, parent path, publication status, language or multisite path, and plugin conflicts. A page can also appear to exist while a redirect plugin or custom code sends requests to the wrong destination.

How to fix 404 error in Chrome#

Chrome is usually only showing the server's response, so the browser is rarely the root cause. Still, local caching can confuse testing after a fix.

In Chrome, hard refresh the page, open DevTools, and inspect the Network panel to confirm the request URL and status code. Test in an incognito window, then compare with a header check or API request. If Chrome still shows a 404 after the server is fixed, clear cache and verify you are requesting the exact canonical URL.

Find 404s across a site, not just one page#

A single URL fix is easy. The harder problem is finding every broken internal link, outdated sitemap entry, or dead migrated page across hundreds or thousands of URLs.

Use this process:

1. Export failing URLs from server logs or analytics.
2. Crawl your site and collect response codes.
3. Check internal links pointing to 404 pages.
4. Compare current URLs to old sitemap or migration lists.
5. Prioritize by traffic, backlinks, and template reach.
6. Re-crawl after fixes to confirm resolution.

This is where YepAPI's On-Page Instant API becomes practical. You can feed it URLs from your crawler or CMS export, classify which return 404, detect whether a replacement page exists, and automate validation after redirects or restorations. If you need a general endpoint set for technical audits, YepAPI's SEO API groups the on-page, domain, and keyword data you use in the same workflow.

Update internal links, sitemaps, and your custom 404 page#

Fixing the status code is not the end of the job. You also need to remove the pathways that created the 404 in the first place.

Update internal links first. Then remove dead URLs from the XML sitemap, refresh navigation or template links, and improve your custom 404 page so users can recover if they still hit a bad address. If you are editing templates anyway, this is often a good time to review how to add canonical tag in html on pages that were moved or consolidated.

A useful custom 404 page should offer a search box, top categories, and links back to important sections. It should help the user recover, but it should still return an actual 404 status, not a soft-404-looking success page.

How to verify the fix after deployment#

Verification is the gap most guides skip. A repair is only complete when the failing URL now behaves the way you intended.

Run this checklist after every fix:

1. Request the old URL and confirm the expected status code.
2. If redirected, confirm it resolves in one hop to the right destination.
3. Open the source page and test the repaired link.
4. Remove dead URLs from the XML sitemap if applicable.
5. Re-crawl the affected section.
6. Check Search Console for remaining not-found patterns.

Search Console is useful here because it surfaces indexing and crawl feedback for site owners, especially after internal-link and sitemap fixes (Google Search Console documentation). For teams doing this repeatedly, YepAPI's On-Page Instant API is the easiest way to retest large URL sets in code and confirm which ones still fail.

A practical rule set you can hand to your team#

If the page should exist, restore it. If the content moved, 301 redirect it. If the link is wrong, fix the link. If the content is intentionally gone with no replacement, return 410.

That rule set solves most 404 incidents faster than generic troubleshooting lists. It also keeps your technical SEO cleaner because you are matching the response to the real state of the URL.

Fix 404s at scale with YepAPI#

Manual browser checks work for one URL. They break down when you have migrations, CMS issues, or sitewide broken links.

Use YepAPI's On-Page Instant API to test live URLs, classify failures, and verify repairs programmatically. Pair it with YepAPI's On-Page Content API for page-level audits, YepAPI's Web Scraping API for large fetch workflows, and YepAPI's SEO API when you want the broader technical SEO toolkit in one place.

CTA: Pull 404 diagnostics and validation checks via YepAPI's On-Page Instant API — $5 free credit, no card.

FAQ#

What is the cause of a 404 error?#

A 404 error happens when the server is reachable but the requested URL does not match a live resource. Common causes include deleted pages, changed slugs, bad internal links, outdated external links, broken permalink rules, or routing misconfigurations after a deploy. The right fix depends on which of those caused the failure.

Why is the page not found?#

A page is not found because the URL requested by the browser no longer maps to valid content on the server. That can mean the page was removed, moved without a redirect, linked incorrectly, or blocked by broken rewrite logic. Check the exact URL, the linking source, and whether a replacement page exists.

What does the ADP system error 404 mean?#

In most systems, an error 404 still means the requested web resource was not found at the URL being requested. If you see it inside ADP, the meaning is usually the same even though the application context differs. The page, route, or document link may be outdated, mistyped, expired, or unavailable to that path.

How to trigger a 404 error?#

You can trigger a 404 error by requesting a URL that does not exist on a server, such as a fake page slug or an outdated path. Developers often do this intentionally during testing to verify custom 404 pages, logging, and monitoring. Make sure the endpoint truly returns 404 and not a soft error page.