A visitor clicks a URL and sees a page that effectively says “nothing here.” The server, however, responds with HTTP 200 as if everything is fine. That mismatch is the essence of a soft 404. It is not just a label from an SEO tool; it is a sign that the response code and the page’s real meaning disagree.
WordPress sites can create these accidentally through empty templates, deleted products that retain a shell page, broken search routes, badly handled filters or custom code that prints a “not found” message without setting the correct status. Google’s crawl-error troubleshooting guidance discusses soft 404s as a signal mismatch between the response and the content.
Why a successful status can be misleading
Status codes are machine-readable explanations of what happened. A browser can show “This item no longer exists,” but if the server still sends 200, crawlers, caches and integrations receive conflicting information. Our guide to choosing between 301, 302, 404 and 410 explains the role of each response.
Where soft 404s tend to appear in WordPress
- Deleted posts replaced with a generic theme message but still returning 200.
- Empty taxonomy archives with headings and no entries.
- Out-of-range pagination such as
/page/999/. - Search or filter URLs with no results but indexable templates.
- Custom post routes that fail lookup without calling the proper 404 handling.
- Thin “product unavailable” pages that have no meaningful alternative or context.
A redirect is not the default answer
A redirect is correct only when there is a genuine replacement. Redirecting every removed URL to the homepage hides the missing-resource condition and can create another quality problem. If a resource is gone with no equivalent, a real 404 or 410 can be clearer. If a new URL replaces it, use a relevant redirect.
Test templates, not just single URLs
Find the pattern behind the issue. If one empty tag archive returns 200, hundreds may do the same. Check representative URLs across post types, archives, pagination, parameters and search. A technical SEO audit should verify response codes alongside canonical, robots and sitemap behavior.
What a correct 404 experience looks like
A 404 page can still be useful to humans. It can offer navigation, search, popular resources and a path back into the site. The important technical detail is that the server response remains 404. Helpful design and correct status are not mutually exclusive.
Repair by pattern, then verify examples
- Export soft-404 examples from Search Console or crawl the site for suspicious 200 responses.
- Inspect the rendered content and HTTP status.
- Group URLs by template or generation rule.
- Choose replacement redirect, genuine 404/410, or useful indexable content.
- Fix the underlying template or routing logic.
- Remove obsolete URLs from sitemaps and internal links.
- Re-crawl and monitor the pattern rather than requesting validation URL by URL.
If Google has already indexed an unhelpful version, use the same diagnosis principles described in what to do when Google indexes the wrong page: correct the site signals first, then allow recrawling to update the search result.
Distinguish soft 404s from intentionally sparse pages
Not every short page is a soft 404. A contact page, login page or concise reference page can be legitimate even with little text. Classification depends on whether the URL represents a real resource and whether the content fulfills its purpose. Use the search engine report as a diagnostic signal, then inspect the page rather than assuming word count is the problem.
Watch application-generated edge cases
Custom filters and APIs can produce unexpected “empty success” states. For example, a valid route may return a 200 template even when the requested object ID does not exist. Add automated tests for nonexistent IDs, out-of-range pagination and deleted records so future releases preserve correct status codes.
Verification after the fix
- Request the URL without being logged in.
- Confirm the status code with a header tool or crawler.
- Check that the sitemap no longer lists obsolete URLs.
- Confirm internal links no longer point at removed pages.
- Review Search Console after recrawling rather than expecting immediate disappearance.
Use logs and crawl data to find the pattern
Soft 404 problems are easier to fix when you know how the URLs are being produced. Server logs can show whether bots repeatedly request invalid IDs, malformed parameters or old URL patterns. A crawler can then test those patterns at scale and record both status code and page title/content.
Do not rely on the visible 404 template alone. Some custom themes correctly display a “page not found” design while still returning 200 because the template was loaded without setting the query to a 404 state. Conversely, a real 404 can display a very polished page. Always check the header.
When 410 communicates the situation more clearly
A 410 can explicitly state that a resource is gone, but it is not a magic SEO accelerator. Use it where your application deliberately distinguishes permanently removed resources. For normal missing URLs, a correct 404 is entirely appropriate. Consistency and accurate semantics matter more than trying to force faster removal.
Make the status code tell the truth
HTTP status codes should describe reality. If the resource is gone, return an appropriate missing response; if there is a true replacement, redirect to it; if the page is intentionally useful, make the content justify the successful status. Correct semantics reduce ambiguity for crawlers, monitoring tools and people trying to diagnose the site months later.