How to Fix 404 Errors: A Search Console Decision Guide

A 404 means the server couldn’t find the requested URL. Knowing how to fix 404 errors starts with working out why the URL failed and what it should do now. This guide is for site owners and SEOs. If you’re a visitor: check the address for typos, reload the page, try the site’s search or homepage, and tell the site owner if you reached the page from one of their own links.

Short answer

Confirm the URL really returns a 404, find where the request comes from, then choose one action:

1. Fix the link if one of your own pages or your sitemap points to a wrong URL.
2. Restore the page if it was removed by mistake and still has value.
3. Redirect permanently to a closely equivalent page if the content moved or was merged.
4. Leave it as a 404 or 410 if the page is genuinely gone and has no equivalent.

Then verify the result in Google Search Console. Google’s Search Console Help says 404 errors generally don’t affect your site’s search performance. Its Page indexing report help recommends fixing 404s that affect your own links or sitemap entries, while URLs that genuinely should not exist can generally be left as 404s.

How to read this guide: statements labeled Google documents come from Google’s own documentation. Statements labeled Recommendation are practical advice, not Google requirements.

What a 404 means, and when to leave it alone

A 404 (Not Found) is an HTTP status code the server returns when it finds no resource at the requested URL. It doesn’t say whether the absence is temporary or permanent. People reach a 404 by mistyping a URL, following a broken link, or using an old bookmark or backlink.

Google documents that URLs returning a 4xx status generally aren’t indexed, and already-indexed URLs are removed from Google’s index over time (status-codes documentation). Newly found 404 URLs aren’t processed for indexing, and Google generally crawls them less often over time. A 404 on a page that should be gone is correct behavior, not a defect.

404 vs. 410

The HTTP standard (RFC 9110) says a 410 (Gone) is appropriate when the server knows the removal is likely to be permanent. For Google Search, the practical difference is small: Google treats 410 similarly to 404. Recommendation: use 410 when you want to state clearly that a removal is intentional, but don’t expect it to remove URLs faster than a 404.

Do 404 errors hurt SEO?

• Google documents: its Search Console Help says 404s generally don’t harm your site’s indexing or ranking and that you can safely ignore them if you’re certain the URLs should not exist. It also advises that such URLs return a proper 404 and aren’t blocked in robots.txt. That page uses some older interface wording, so use it for principles, not menu paths.
• Google documents: its crawl budget guide is intended mainly for large or fast-changing sites. Google gives rough examples including sites with around 1 million or more unique pages whose content changes weekly, sites with around 10,000 or more pages that change daily, and sites where a large share of URLs are “Discovered – currently not indexed”. These are estimates, not strict thresholds. The guide explains that a 404 is a strong signal not to crawl that URL again, although Google won’t permanently forget a URL it already knows about. For most smaller sites, Google says keeping the sitemap up to date and checking the Page indexing report regularly is adequate.
• Recommendation: fix 404s that affect people or signals you control: internal links, sitemap entries, and pages with meaningful traffic or external links. A visitor who follows your own link to a dead end is a real problem even when Google isn’t penalizing anything.

Google’s site-move documentation explains that permanent redirects don’t cause a loss in PageRank. The Google documentation reviewed here doesn’t provide a percentage-style “equity” figure, so treat exact numbers you see elsewhere as unsupported unless they have reliable evidence. A redirect still only makes sense when the destination closely matches the old page, and Google determines which URL to show in search results using multiple signals.

Soft 404s: what Google means by the term

Google documents: a soft 404 can occur when a URL shows the user a “not found” message but returns a 200 (success) status code. It can also be an empty or nearly empty page that Google determines has no useful content. Such pages may be excluded from Search, and Search Console reports detected soft 404s in the Page indexing report (crawling-errors documentation).

Google lists several possible causes:

• A missing server-side include file.
• A broken connection to the database.
• An empty internal search results page.
• A missing JavaScript file.

Attribute	Real 404	Soft 404
HTTP status	404 (or 410)	Often 200
Page content	“Not found” message	“Not found” message, empty page, or content Google considers unhelpful
What Google does	Doesn’t index; drops indexed URLs over time	May exclude the URL and flag it in Search Console

Google documents three ways to resolve a soft 404, depending on the page:

1. Content is gone: return a 404 or 410.
2. Content moved or has a clear replacement: return a 301 to it.
3. Page and content still exist: the page may not have loaded properly for Googlebot. Use the URL Inspection tool to inspect the rendered page and reported status. Blocked resources, server errors, and resources that are slow or too large can make a useful page appear empty.

Google’s older 404 help page also discusses cases where deleted pages are redirected to the homepage or answered with a non-404 status. Its current Search Central documentation describes soft 404s in terms of pages that appear to have no content or no useful content despite returning a successful status. Treat both incorrect error handling and irrelevant redirects as problems. Return a real 404 or 410 when there is no replacement, and redirect only to a close equivalent.

Soft 404s in single-page applications

Google documents that preventing soft 404s can be especially difficult in a single-page application, because client-side error handling may report a 200 status. Its JavaScript troubleshooting guide suggests approaches such as redirecting to a URL where the server responds with a 404 status code or adding or changing the robots meta tag to noindex when appropriate. A noindex directive is not a substitute for returning the correct status when content genuinely doesn’t exist.

A practical diagnostic workflow

Work through these steps in order. Each one answers a single question.

Step 1: Confirm the actual status code

What the page looks like and what the server returns can differ. Check the status in your browser’s developer tools (Network tab), with a command-line request, or with Search Console’s URL Inspection tool.

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

Read the response status: 404, 410, 301, 200, or a 5xx code. A “not found” page that returns 200 may be a soft 404, covered above.

Step 2: List the URLs Google reports

In Google Search Console, open the Page indexing report. Under the reasons pages aren’t indexed, look for Not found (404). Also check Soft 404 and Redirect error where they appear in the report.

Google documents several limits on this report:

• The 404 reason covers URLs Google found returning a 404 during its crawling and reporting process; the report isn’t a complete inventory of every URL that may be broken.
• The example URL list can be limited and isn’t guaranteed to show every affected URL.
• Google distinguishes URLs discovered through submitted sitemaps from URLs it found through other means, so check your sitemap separately for dead URLs.
• Google may continue crawling known URLs for a while after they return a 4xx. There’s no way to tell Googlebot to permanently forget a URL, although it generally crawls such URLs less often over time.

Step 3: Find out how Google discovered each URL

Inspect an example URL and check its discovery details, such as sitemaps or referring pages where Search Console provides them. Interface labels can change, so confirm the exact options in your account. For URLs you submitted in a sitemap, Google’s guidance is to check the discovery information and update the sitemap as necessary. Some 404s come from URLs that never existed on your site, such as mistyped links or paths Googlebot extracted from JavaScript. Those typically need no action unless they reveal a broken internal link or another issue you control.

Step 4: Cross-check with a crawl

Recommendation: run a crawler such as Screaming Frog to find broken internal links Google hasn’t reported yet. Filter for 4xx responses and note the source page that links to each broken URL. A backlink tool can show which broken URLs have external links pointing at them, which helps you prioritize. Google’s site-move guidance also suggests the Links report in Search Console, server logs, and analytics for finding important URLs.

Step 5: Classify each URL

Assign every URL to one of the actions in the next section. Don’t apply one fix to the whole list.

Restore, redirect, or remove: the decision table

Situation	Action	Status code	Basis
One of your pages links to a wrong or mistyped URL	Correct the link at its source	n/a (fix the link)	Google: Page indexing report help
Page was deleted by mistake and still has value	Restore it at the same URL	200	Recommendation
Page moved or was renamed	Permanent redirect to the new URL	301 or 308	Google: redirect moved content
Several pages merged into one	Permanent redirect each old URL to the merged page when it is a relevant replacement	301 or 308	Google’s site-move guidance
Page removed, no equivalent exists	Leave it returning 404 or 410	404 or 410	Google: crawling-errors documentation
Common misspelling or alternate spelling of a real URL	Redirect it to the correct page	301	Recommendation
Sitemap lists dead URLs	Remove or update the entries	n/a	Google: 404 help
URL never existed on your site	Usually nothing	404	Google: 404 help
“Not found” page returns 200	Return 404/410, redirect, or fix rendering	See soft 404 fixes	Google: soft 404 guidance

When to restore, redirect, or leave a URL

Restore when the removal was accidental, the content is still accurate and useful, and the URL has internal links, external links, or traffic. Recommendation: restoring at the original URL is simpler than redirecting and avoids a redirect hop.

Redirect when the content moved or has a clear replacement. Google documents: if a page has moved, return a redirect to the new page, and use a permanent redirect when you’re sure it won’t be reverted. Recommendation: a good target answers the same question the old page did. A renamed post goes to the renamed post, and a merged guide goes to the merged guide. A discontinued product may go to its direct successor, or to a parent category only if that helps the visitor find alternatives. If there is no genuinely relevant replacement, let the old URL return a 404 or 410.

Leave the 404 or 410 when the page is genuinely gone. Google documents: if a page was removed and there’s no replacement with similar content, return a 404 or 410. That tells search engines the resource is unavailable and shouldn’t be indexed.

Why not send everything to the homepage?

A blanket redirect of unrelated URLs to the homepage gives visitors something they didn’t ask for and hides which pages are genuinely missing. Google’s 404 guidance advises against redirecting unrelated missing URLs to the homepage or blocking 404s with robots.txt. Its site-move guidance also warns that redirecting many old URLs to one irrelevant destination can confuse users and may be treated as a soft 404. Content genuinely consolidated into one relevant page can redirect to that page. If there’s no close equivalent, let the URL return a real 404 and make that page helpful (see custom 404 page).

How to fix 404 errors by scenario

Broken internal link

1. Find the page that contains the link (crawler source column or Search Console discovery information).
2. Edit the link to point to the correct, live URL.
3. Re-crawl or re-inspect to confirm the target returns 200.

Recommendation: fix the link instead of adding a redirect solely to compensate for it. A redirect can work, but it leaves a link that sends every visitor through an extra request. Google’s site-move guidance recommends updating internal links to the final URLs.

Moved or renamed URL

1. Identify the new URL and confirm it returns 200.
2. Create a permanent server-side redirect from the old URL to the new one (see redirect rules).
3. Update internal links and the sitemap to the new URL.
4. Test the old URL and confirm it reaches the intended destination without unnecessary redirect hops.

Deleted page with no replacement

1. Remove or replace internal links to it.
2. Take it out of the sitemap.
3. Let it return a 404 or 410.
4. Don’t block it in robots.txt merely to hide the 404. Google’s crawl budget guide explains that blocked URLs may remain known to Google and may be crawled if the block is later removed. A robots.txt block is also not a dependable way to keep a URL out of the index: the Page indexing report help explains that blocked URLs can still be indexed in some circumstances.

Soft 404

1. Inspect the URL with URL Inspection and view the tested page.
2. If the content is genuinely gone, make the server return a 404 or 410.
3. If the content moved, add a 301.
4. If the page should be live, fix what made it look empty: blocked or failing resources, a template error, a failing database call, or an empty search or category page.

Set up redirects safely

Google documents:

• Permanent redirects (301, 308) signal that the redirect target should be the canonical URL. Temporary redirects (302, 307) aren’t used as a permanent canonical signal, although other signals can affect which URL Google indexes or displays (redirect documentation).
• Server-side redirects are the most reliably interpreted.
• JavaScript redirects are an option when server-side redirects or meta refresh redirects aren’t possible.
• Google’s crawlers can follow multiple redirect hops, but long chains should be avoided (status-codes documentation). Its site-move guidance recommends redirecting straight to the final destination and keeping chains short if a direct redirect isn’t possible. Its crawl budget guidance explains that long redirect chains can negatively affect crawling.
• After a redirect, Google may keep track of both the old and new URLs. Which URL appears in search results depends on signals such as the redirect type and other canonicalization signals. The old URL may occasionally continue to appear while Google processes the change.

Code	Type	Use when	How Google treats it
301, 308	Permanent	The move won’t be reverted	Strong signal that the target should be canonical
302, 307	Temporary	The original URL will return	Not a permanent canonical signal; other signals may still affect indexing

Redirect rules

• Recommendation: redirect each old URL directly to its final destination, avoiding unnecessary intermediate URLs.
• Recommendation: redirect to the closest equivalent by topic and intent, not to a loosely related page for convenience.
• Recommendation: keep a record of old URL, new URL, date, and reason.
• Google documents: its site-move guidance recommends keeping redirects for as long as possible, generally at least one year. That advice is written for site moves, so use it as a sensible baseline for individual URL moves too.
• Avoid loops. Search Console can report a “Redirect error” for redirect chains that are too long, loops, and invalid or empty redirect destinations.

Apache example

The following examples use Apache’s mod_alias documentation. The plain Redirect directive applies to requests beginning with the old path and can also affect URLs beneath it. RedirectMatch uses a regular expression, and the anchored pattern below limits the rule to the exact path. The 410 rule is an Apache example. Back up .htaccess before editing and test new rules on a staging copy first.

# Exact-match permanent redirect (301)
RedirectMatch 301 "^/old-page/$" "https://www.example.com/new-page/"

# Exact-match removal (410)
RedirectMatch gone "^/discontinued-offer/$"

Nginx example

This example uses an exact match with location =.

location = /old-page/ {
    return 301 https://www.example.com/new-page/;
}

location = /discontinued-offer/ {
    return 410;
}

Reload the server after configuration changes, and check your server’s documentation for your version. Many hosts also offer a redirect tool in their control panel.

Test every redirect

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

You should see a 301 and a Location header pointing to the intended destination. Then request the destination and confirm it returns 200. Google’s site-move guidance recommends URL Inspection for individual URLs and command-line tools or scripts for larger URL lists. To verify the redirect itself, use response headers or browser developer tools rather than relying only on the rendered page.

Fix 404 errors in WordPress

Google’s documentation doesn’t cover every WordPress-specific fix. WordPress’s own documentation covers permalink and .htaccess behavior, while the remaining steps combine common WordPress troubleshooting with third-party guidance. Treat these steps as recommendations and make a backup first. Hosting and security guides overlap with these causes: Sucuri’s guide covers permalinks, .htaccess and plugins, and Hostinger’s guide covers DNS, file permissions, .htaccess and backups. Both vendors sell related services.

Symptom	Likely causes	First checks
One page or post 404s	Slug changed, page unpublished or trashed, redirect missing	Check status, slug and the Trash; add a redirect if the URL changed intentionally
Posts and pages 404 but the homepage works	Stale rewrite rules, damaged .htaccess	Re-save permalinks; check .htaccess
404s after a migration or host change	Rewrite rules not active, wrong server configuration, DNS or file-permission problems	Re-save permalinks; confirm the server’s rewrite support; ask the host
404s after a plugin or theme change	Plugin or theme conflict; permalink rewrite rules that need refreshing	Re-save permalinks; deactivate recent plugins one at a time to isolate the cause
Missing images, scripts, or styles	Moved or deleted media, wrong paths	Check the file path and upload; fix references

Re-save permalinks

1. In the WordPress admin, go to Settings → Permalinks. WordPress’s documentation explains how this screen manages permalink settings and rewrite rules.
2. Click Save Changes without changing the structure. If .htaccess is writable, WordPress may update it automatically.
3. If the file isn’t writable, WordPress may display the rewrite rules for your configuration. Follow the instructions shown in your admin area or ask your host to apply the correct rules.
4. Retest an affected URL.

If .htaccess is missing or damaged (Apache)

1. Download a copy of your current .htaccess from the site root, then rename it (for example .htaccess_old). Files beginning with a dot are hidden on many servers by default, so enable hidden files in your FTP client or file manager.
2. Re-save permalinks as above so WordPress can write a fresh file, or copy the rules it displays if it cannot.
3. Retest, then re-add any custom rules from the backup one at a time.

These steps assume an Apache server that uses .htaccess. If your host runs a different server, ask your host how rewrite rules are managed. Nginx does not use .htaccess.

Other checks

• Caching: purge page, plugin and CDN caches, then retest in a private window.
• Redirect plugins: a redirect manager plugin or your host’s tool is fine. Keep one source of redirect rules where possible so they don’t conflict.
• Automatic slug redirects: WordPress core includes a function that can redirect old post slugs to current permalinks with a 301 when a request would otherwise return a 404. Its reference documents its behavior and limitations, so don’t rely on it for every post type or URL. Test the old URL.
• Unfamiliar changes: an unexpected plugin or modified .htaccess can be a sign of a compromise. A 404 alone isn’t proof of one, but check for unknown plugins and altered files.

When it isn’t really a 404

Several problems look similar from the outside but need different fixes. Check the status code before editing redirects.

What you see	What Google documents	Where to look
5xx server error	Google may slow crawling; if the error persists, affected URLs may eventually be dropped from the index (status codes)	Hosting, server logs, the Crawl Stats report
429 Too Many Requests	Google treats 429 as a server error for crawling purposes	Rate limits, firewall, security plugin
DNS or network error, timeout	Can affect crawling similarly to server errors; persistent unavailability may affect indexing (DNS and network errors)	DNS records, firewall rules, host or CDN
401 or 403	Restricted URLs generally can’t be crawled and indexed normally (Page indexing report)	Login requirements, security rules blocking crawlers
Redirect error	Can result from long chains, loops, or invalid redirect destinations	Redirect rules, plugin conflicts

In its guidance on handling an overwhelming crawl, Google says 503 or 429 responses should be temporary. Returning them for more than about two days can cause affected URLs to be dropped from the index (crawling-errors documentation).

This guide covers 404s and soft 404s. For site-wide crawling and availability problems, see our crawl errors guide.

Build a custom 404 page that behaves correctly

A custom 404 page is primarily for users. Google’s guidance explains that a missing page should return the appropriate 404 status rather than a successful status that can be interpreted as a soft 404.

Recommendation: make the page useful by following these practices:

• State clearly that the page can’t be found, in a friendly tone.
• Keep the site’s look and navigation.
• Link to popular articles or posts and to the homepage.
• Offer a way to report a broken link.

Recommendation: add a search box, and check the response header of a made-up URL on your site to confirm it returns 404.

Verify the fix in Google Search Console

1. Confirm the live behavior. Use URL Inspection and Test live URL for pages that should load or return an error. To check a redirect itself, request the old URL with curl -I or look at its response headers in your browser’s developer tools. The live test doesn’t cover every condition the Page indexing report checks, so a clean test doesn’t guarantee the report will clear immediately.
2. Compare against the last crawl date. If you fixed the problem after Google last crawled the URL, the report may still show the older state.
3. Validate only what you fixed. Validation is optional: Google updates an issue’s count when it recrawls pages, whether or not you request validation. To ask Google to confirm your fixes, address all known instances, then click Validate fix on the issue’s details page for issues you actually changed, such as restored pages and redirected URLs. Don’t click it again until the first attempt finishes. Validation timing varies; Google says it can take days or longer, and some cases take several weeks. URLs you deliberately leave as 404s don’t need validation.
4. Understand what counts as fixed. A URL may be treated as resolved when it no longer shows the issue or is no longer available to Google, depending on the issue and report.
5. Treat the one-month figure as an expectation. Google’s help pages describe the 404 report as covering URLs that returned a 404 during the relevant reporting period. They don’t guarantee that every URL will disappear from the report on an exact date. Google may continue crawling known URLs for a while after they return a 4xx. Submitting a removal request is not a substitute for correcting the status or discovery signals.
6. Speed up large validations (optional). For a large site, you can prioritize important URLs and use sitemap filters where available to focus your review.

Prevention checklist

Before you delete, rename, or move a URL

• Decide the destination: replacement page, merged page, or no equivalent.
• Add the redirect, or plan the 404/410, at the same time as the change.
• Update internal links, navigation, breadcrumbs and canonical tags.
• Update the sitemap.

For migrations and redesigns

• Export a list of current URLs before the change.
• Map each old URL to a new one, or mark it as intentionally removed.
• After launch, crawl the old URL list and check for 404s, chains and loops.
• Read Google’s guidance on moving a site with URL changes.

Ongoing

• Crawl the site on a schedule you can sustain.
• Review the Page indexing report for Not found (404), Soft 404 and Redirect error.
• Keep sitemaps limited to live, indexable URLs.
• Keep slugs stable once a URL is published.

For a broader technical review, use our advanced SEO audit checklist and the crawling resources. If you want a second pair of eyes on a large cleanup, SEORAF also offers an SEO audit service.

Frequently asked questions

For whether 404s hurt SEO, see what a 404 means. For why not to redirect everything to the homepage, see the decision section.

Why does Search Console still show a 404 after I fixed it?

The report may reflect an older crawl. Check the last crawl date, run a live test, and use Validate fix if you want Google to confirm. See the Search Console section.

How long does a removed URL stay in the 404 report?

Google’s reporting period and recrawl schedule mean there is no guaranteed removal date for an individual URL. Google may continue trying a known URL for some time, so treat any approximate timeframe as an expectation rather than a promise.

When should I use a 301 instead of a 302?

Use a 301 (or 308) for a permanent move, and a 302 (or 307) when the move is temporary. Google’s redirect documentation explains that permanent redirects are a strong signal that the target should be canonical, while temporary redirects aren’t a permanent canonical signal. Google uses multiple signals when choosing which URL to show in search results.

How this guide was verified

Last reviewed on October 15, 2026 against the Google Search Central and Search Console Help pages, WordPress.org documentation, and Apache documentation listed in the sources. Third-party WordPress guidance is labeled as such. SEORAF is an independent SEO resource and does not sell rankings. Our editorial policy and affiliate disclosure explain how we work. This guide contains no affiliate links.

Sources

• How HTTP status codes affect Google’s crawlers (Google)
• Troubleshoot Google Search crawling errors (Google)
• 404 (Page Not Found) errors (Google Search Console Help)
• Page indexing report (Google Search Console Help)
• Redirects and Google Search (Google)
• Optimize your crawl budget (Google)
• Debug network and DNS errors (Google)
• How to move a site (Google)
• Fix Search-related JavaScript problems (Google)
• Settings Permalinks screen (WordPress.org)
• wp_old_slug_redirect() (WordPress developer reference)
• Apache module mod_alias (Apache HTTP Server)
• RFC 9110: HTTP Semantics (IETF)
• Error 404: How to Fix and Troubleshoot (Sucuri, third party)
• How to fix Error 404 Not Found (Hostinger, third party)