How to Fix Soft 404 Errors in Google Search Console

A soft 404 means Google considers a page missing or error-like even though the response does not correctly communicate that state. A common example is a “Page not found” screen served with 200 OK, the status normally used for a successful request.

Start with the affected URL's purpose. Should it display useful content, forward to a replacement, or remain unavailable? The right fix follows that decision. Adding paragraphs or redirecting everything to your homepage can leave the underlying problem unresolved.

This guide walks through one URL first, then shows how to apply the same checks to a shared template or group of pages.

What is a soft 404 error?

Soft 404 is Google's classification, rather than an HTTP status code you configure on your server. Search Console reports it when the content appears to represent a missing page without the expected missing-page response. Google's Page indexing help^[1]Source 1Page indexing helpView source ↗ recommends checking the rendered page and returning a genuine 404 for content that is truly absent.

A real 404 can have a helpful design, navigation links and a search box. What makes it a real 404 is the response code for the requested address, not whether the screen looks friendly.

Response and content	What the evidence tells you	Appropriate next check
200 with the intended content	The request succeeded and delivered the page	Inspect its indexing state separately
200 with a missing-page message	Response and content disagree	Correct the missing-page response
200 with an empty template	Main content is unavailable in this view	Investigate rendering or data delivery
404 or 410 for intentionally removed content	The response communicates absence	Check stale links and sitemap entries
Redirect to a relevant replacement	The URL forwards to other content	Trace the path and inspect the destination

In a local demonstration for this guide, we served the same missing-page HTML once with 200 and once with 404. Its visible message did not change. The response did. A third route returned 200 with the intended guide content. This demonstrates HTTP behavior, not how Google classified the test pages.

Google's HTTP status guidance^[2]Source 2HTTP status guidanceView source ↗ explains that a successful response allows processing but does not guarantee indexing. Check content and status together.

Find soft 404 pages and compare the evidence

Open Indexing > Pages in Search Console, select Soft 404, and choose an example URL. Start with a page that matters to visitors or belongs to a recognizable pattern, such as product pages, category pages or recently changed routes.

Copy the exact address, including its parameters and final slash. Compare the reported crawl information with the time of any recent repair. An older report can describe a response that has already changed.

Use the URL Inspection tool to compare Google's recorded information with a current live test. When available, open View tested page and inspect the screenshot and HTML. Look for the actual main content, not just the site logo and footer.

Evidence collection workflow

1. Record the exact URL and its intended purpose.
2. Check its current response status and any redirect path.
3. Inspect the rendered screenshot and main content.
4. Compare the result with a working page of the same type.
5. Record what differs before choosing a repair.

Check the HTTP response and rendered content

In Chrome's Network panel, reload the page and inspect the main document request. Record its status. If the address redirects, follow the requests to the final page instead of assuming the final address bar explains the whole path.

Then ask whether the expected content is actually present. A product title without its specifications, an empty article container or a category with a failed data request can all make a nominally successful page unhelpful.

A normal browser session may have login cookies, cached data or permissions that a crawler does not. Compare a signed-out view where relevant. Our guide to viewing a site as Googlebot explains the limits of different inspection methods.

Avoid diagnosing the whole site from one random URL. If several examples share a template, inspect a few affected pages and a working control page. A repeated failure points toward a shared cause; a single deleted record may need only a page-level correction.

Choose the right fix for each affected URL

Decide what the URL should provide before changing its status, content or indexing directives.

Intended future	Site-side action	Evidence to verify
The page should exist	Restore useful main content and a successful response	Intended text or product details render correctly
The content moved	Permanently redirect to a genuinely relevant replacement	Direct path to the correct destination
The page is gone without a replacement	Return a real 404 or 410	Requested address communicates missing content
A useful utility page should stay out of search	Use an appropriate noindex directive	Google can crawl and read the directive

If an article was deleted accidentally, restore it or repair the route that should load it. Do not apply noindex to a valuable page simply because Search Console currently lists an error.

For moved content, match the old need to the new destination. A replacement model's detailed page may be relevant to a discontinued product; a generic homepage often is not. Check the redirect path and destination after implementation.

For genuinely absent content, a custom error page can help visitors find alternatives while retaining a 404 response. A link to the homepage offers a choice. An automatic redirect removes that choice and can conceal the fact that the requested resource is gone.

Use noindex for a deliberate search-exclusion decision. It does not restore missing content or repair a server response. Google's robots meta documentation^[3]Source 3Robots meta documentationView source ↗ also makes clear that Google must be able to access a page to read its indexing directive.

Keep useful out-of-stock pages useful

An unavailable item is not always a nonexistent page. A temporarily out-of-stock product can still provide specifications, compatibility details, support information and an accurate availability message.

Assess what the page offers someone following its URL. Keep a useful product page accurate rather than removing honest availability language just to avoid an error phrase. If a template mistakenly replaces all product details with “item not found,” fix that behavior.

There is no universal paragraph count that turns a missing page into a useful one. Add information because it serves the page's purpose, and repair loading failures when the information already exists but is not delivered.

Repair JavaScript and template failures

An existing page can appear empty when its main content depends on a failed script, blocked resource or unsuccessful API request. Inspect those failures before rewriting the article or deleting the product.

Compare the initial HTML with the rendered result. If the initial response contains only a shell, identify what supplies the main content and whether that process completes in the tested environment. Check resource access, console errors and the data response used to populate the page.

For example, a product API might return an error while the page template continues to show 200 OK and an empty product panel. Fixing the template's failure handling is more useful than adding generic text below the panel.

Check shared error components too. An unavailable-content message left visible across valid pages can contradict their main content. Correct the component or its condition. Do not treat every occurrence of “not found” in source code as proof of the cause.

Handle missing routes in a single-page app

Client-side routing can serve the same successful HTML shell for both valid and nonexistent addresses. Handle those states explicitly.

Google's JavaScript SEO guidance^[4]Source 4JavaScript SEO guidanceView source ↗ describes two options for client-rendered error pages when meaningful server statuses are impractical: navigate to a URL that returns a real 404, or add a noindex directive to the error page.

Keep this error handling separate from a valid page waiting for data. A temporary API failure should not silently turn every affected product into permanently removed content. Test the successful route, an absent record and a failed data request as separate cases.

Clean internal links and sitemaps

After choosing the correct page state, update the paths on your site that still advertise an obsolete URL. Check menus, related-content blocks, product listings and links inside older articles.

Replace links to moved pages with the intended final address. Remove obsolete sitemap entries for deleted pages. For valid restored pages, keep a sensible internal link route so visitors and crawlers can reach them.

Google's sitemap guidance^[5]Source 5Sitemap guidanceView source ↗ recommends listing the URLs you want represented in search results. Updating a sitemap supports discovery; it does not erase Google's memory of an old address or override the response that address returns.

If endless empty filter combinations create the same issue, review how those URLs are generated and exposed. A template-level decision is usually more manageable than treating each newly generated address as an unrelated incident.

Verify a soft 404 fix against the intended outcome

Retest the response and rendered content first. A correct repair can produce a valid page, a relevant redirect or a genuine missing response. Each requires different evidence.

Verification workflow

1. Repeat the original check on the same URL.
2. Confirm that its response matches its intended purpose.
3. Inspect another URL affected by the same change.
4. Check a valid control page for accidental damage.
5. Use Search Console validation where applicable and monitor fresh crawl evidence.

For a restored page, you can follow Google's recrawl request process^[6]Source 6Recrawl request processView source ↗. A request does not guarantee indexing or an immediate report update.

A deleted page moving from “Soft 404” to an ordinary not-found state can be the correct result. You do not need to recreate it to make every exclusion disappear.

Choose one important affected URL, record what it should provide, and check what the server and rendered page actually deliver. Repair the mismatch, then repeat the same check so the improvement is observable.

Sources

1. Google Search Console Help. Page indexing help.

2. Google Search Central. HTTP status guidance.

3. Google Search Central. Robots meta documentation.

4. Google Search Central. JavaScript SEO guidance.

5. Google Search Central. Sitemap guidance.

6. Google Search Central. Recrawl request process.