Diagnosing Soft 404s on Service Pages

Service pages diagnosed as Soft 404 in Google Search Console

Google Search Console flags Soft 404 under Indexing reports, in the Pages or Page coverage views.

On service sites, the URLs it lists often include deleted service pages that still load, pages with very little content, pages that show placeholder copy like “nothing found,” and category or filter style pages that end up empty.

The work starts with a simple fork: should this URL exist as a real landing page for users, or should it be treated as removed. Confirm that intent for each flagged URL before you change anything, because the correct fix depends on that choice.

Once you know whether the page should live or die, you can understand why Google called a “200 OK” page an error.

Why Google labels a “200 OK” page as a Soft 404

A Soft 404 happens when your server says a page exists by returning a 200 OK status code, but Google reads the page and decides it looks missing or useless. Google does not need a “404 Not Found” server response to reach that conclusion.

It uses page signals that often appear on broken service pages, such as “not found,” “service unavailable,” “no product available,” or other messages that tell a visitor there is nothing to do.

Thin pages also trigger it, like a service page built from a template with a headline and a few generic lines that match many other pages on the site. Another trigger is intent mismatch: the page loads, but it does not answer what a searcher expects from that service query, so Google treats the URL like a dead end.

Those signals usually come from specific technical setups, so the next step is to trace the mechanism that produced them.

Mechanisms that create Soft 404s on service pages (status codes, redirects, rendering)

Many Soft 404s come from status code mistakes. A common one is a custom “not found” page that returns 200 OK instead of 404 or 410, so every missing service URL looks like a normal page to the crawler.

Another pattern is an error page that sits behind a redirect. For example, an old service URL returns a temporary redirect, then sends Google to a page that looks like an error while returning 200 OK.

That chain gives Google mixed signals, so it may keep the old URL around while also indexing an error like page, then label the result as Soft 404.

Rendering failures can create the same symptoms even when the service content exists. If the page depends on client-side code and that code fails, Google may see a blank page or an “application error” message in the rendered result.

I have seen this happen when a page loads fine in a browser, yet Google’s render pass hits a JavaScript error and never prints the main content into the page. Another cause appears after deployments on JavaScript heavy sites.

Google often crawls in two steps: it fetches the HTML first, then returns later to render it. If a later render tries to load older script files that no longer exist, those missing files break the page and Google may classify the URL as a Soft 404.

These mechanisms matter because they decide how urgent the issue is for crawling and service-page visibility.

Implications for service-page SEO and site crawling

Soft 404 service pages usually do not stay indexed, so they stop showing for the searches you want them to win. They also waste crawl budget because Google keeps checking low value or broken URLs instead of spending time on your real service pages.

When users land on these pages from links or bookmarks, they hit thin content or error-like messaging, which hurts trust and increases exits. If the site produces many of these URLs, the overall site can look cluttered with low value pages, which makes prioritizing fixes important.

That prioritization starts with a clear action choice for each URL.

Choose 404/410, 301, or content restoration; then validate and monitor

Start by deciding what the service URL represents today. If the service page is deleted, out of scope, or you never want it indexed again, return the correct error status.

Use 404 when the page does not exist, and use 410 when it is gone for good and you want a stronger removal signal. Do not keep a “service not available” template on a 200 OK page, because that keeps the Soft 404 pattern alive.

If the service page has a close replacement, use a 301 redirect to the best match, like the updated service page or a parent service category that covers the same intent. Only do this when the destination helps a user who wanted the old service.

Avoid mass redirecting old service URLs to the homepage, since Google often treats that as a Soft 404 signal and users find it confusing.

If the page should exist as a real landing page, restore it as one. Add unique content that matches the service intent, and remove phrases that mimic error copy such as “not found” or “no results” when the page is meant to rank.

Confirm that Google can render the main content without client-side failures by checking the rendered HTML in URL Inspection. If your site relies on JavaScript bundles that change on deployment, reduce version-skew risk by keeping old critical assets available long enough for Google’s later render pass, or by using platform features that prevent broken chunk requests after releases.

After you ship changes, inspect a few affected URLs in Search Console and request validation. Google can take days to weeks to recheck, and some sites see longer delays depending on crawl rate.

Run a site crawl with a tool, like ScreamingFrog, that reports status codes, and confirm that removed pages return 404 or 410, redirects resolve in one step, and live service pages return 200 with meaningful content. Keep a regular audit cadence of once per month so new thin service pages, empty filters, and broken templates do not recreate the same Soft 404 pattern.