Your service page opens, the address is correct and customers can still contact you. Yet Search Console lists it as a Soft 404, and it is missing from Google.
Before deleting the page or commissioning replacement copy, check what Google actually received. The problem may be an empty template, a failed content request or a page that only loads properly in your usual browser.
For a business relying on service enquiries, the priority is to restore the useful page and its customer journey. Clearing a report is only part of that job.
What does a soft 404 mean?
A normal 404 is an HTTP response saying that a page cannot be found. A soft 404 is Google’s assessment that the content looks like an error or empty page, even though the server may return 200, meaning success. Google’s current HTTP status documentation explains that a successful response does not guarantee indexing.
That distinction matters: a browser opening the address successfully does not prove the main content arrived. A header, navigation and footer can load while the actual service information is missing.
Start with pages that should bring enquiries
Open the Soft 404 issue in Search Console’s Page indexing report. Separate genuine service pages from addresses that should no longer exist.
Prioritise pages you still promote, link from your navigation or expect prospective customers to find. If several affected addresses use the same service template, investigate that shared template before rewriting each page.
For each important example, record:
- The exact URL, including any trailing slash or parameters.
- What the page should contain and which service it supports.
- The crawl date shown in URL Inspection.
- Whether the problem began around a release, migration or content change.
- Whether a comparable page using the same template works.
Keep one unaffected page as a comparison. A difference between two otherwise similar pages can give your developer a much clearer starting point than a list of missing search results.
Compare Google’s saved version with a fresh test
Inspect an affected URL. Google’s URL Inspection guidance distinguishes the saved indexing information from the live test: the first reflects Google’s previous processing, while the second fetches the page now.
Note the previous crawl date, then run Test live URL. Open View tested page and examine the screenshot, HTML and available resource information. Where the saved report offers a crawled page view, compare that too.
Look for the service description, meaningful images and the route to an enquiry. Is the main area blank? Has a loading message replaced the content? Does a prominent error appear where the service details should be?
Repeat the visit in a signed-out browser. Avoid relying entirely on a browser where you are logged into WordPress or have already visited the page repeatedly. Record any difference rather than assuming one successful visit settles the issue.
If the main content is missing, repair its delivery
Google’s soft 404 troubleshooting guidance specifically covers otherwise valid pages that load incorrectly, lack critical resources or show prominent errors during rendering. Blocked resources, server failures and slow or oversized resources can be involved.
Ask your developer to trace the missing section back to its source. Useful questions include:
- Is the service content actually published and attached to the correct template?
- Does the initial page contain the content, or must another request retrieve it?
- Does that request work for a visitor without a login or existing session?
- Is a required script or content endpoint failing?
- Did a template condition accidentally exclude these service pages?
These are investigation prompts, not proof of a particular cause. For example, a blank service area after a redesign could reflect a missing content field; it does not automatically mean Google cannot run the site’s JavaScript.
Check the failing request, not every browser warning
Google’s JavaScript troubleshooting guide recommends examining loaded resources, console output and rendered content. Ask for the specific failed resource or exception that explains the missing service information.
A warning from an unrelated widget is a weak basis for a repair. A failed request that supplies the entire service description is much stronger evidence. Have the developer demonstrate the connection between the fault and the missing content before agreeing a wider rebuild.
Consider how essential content reaches the page
Google can run JavaScript. Its JavaScript SEO documentation explains that some sites initially send an application shell and need rendering before their main content appears. Google also recommends considering server-side rendering or pre-rendering.
For a straightforward service page, ask whether essential information can arrive in the initial HTML. This is a design decision to assess against your existing build. You do not need to replace a functioning website framework simply because a page has been flagged.
If the page renders properly, review what it actually offers
Once you have confirmed that the content arrives, read the page as a prospective customer. A title, a stock photograph and a contact button leave plenty of practical questions unanswered.
Use an editorial review to identify what would make the page useful:
- What work does this service include?
- Who is it suitable for, and what falls outside its scope?
- What does a customer need to provide to get started?
- What happens after an enquiry?
- Which genuine examples or supporting details can the business verify?
Add information because it helps someone choose the service. Do not stretch the copy to an arbitrary word count or invent project results. If location matters to delivery, explain the actual coverage or arrangements. Repeating Essex town names does little to answer those questions.
This review improves the page’s usefulness; it is not a guaranteed way to change Google’s classification. If the page already contains substantial, relevant information, preserve the evidence and continue investigating delivery differences.
If the page really has gone, use the appropriate response
Some Soft 404 entries will be obsolete addresses. Google’s 404 guidance says that a deleted page without an equivalent replacement should return 404 or 410. Where content has moved, redirect visitors to its replacement.
Do not send every missing service URL to the homepage just to reduce errors. Choose a redirect only where the destination serves the original visitor’s need. Otherwise, provide a helpful not-found page with sensible navigation and the correct response code.
Keep this decision separate from repairing a live service page. Changing a wanted page to a real 404 would remove its content from consideration, rather than restore its search visibility.
Verify the repair beyond a green result
Retest the affected pages and the working comparison page. Confirm the intended response, visible service content and usable enquiry route. Check a direct visit as well as navigation from another page.
A successful live inspection is useful evidence of access, but it does not guarantee indexing. Google’s URL Inspection documentation makes that limitation explicit. Check the later saved indexing information after Google has processed the repaired page.
When the underlying issue is fixed across the affected group, use Validate fix in the report. Google’s Page indexing report documentation explains that validation checks known affected URLs and that an issue can also be considered resolved when a page becomes unavailable. A cleared issue therefore does not, by itself, prove that an important service page has returned to the index.
Ask for a handover containing the cause, affected template or URLs, repair made and before-and-after evidence. Include a follow-up check of the wanted page’s indexing status. That gives you something concrete to assess if the problem returns.
Get the page working for customers and search
If an important service page has been classified as a soft 404, BuzzBoost can help connect the technical SEO investigation with the development work needed to repair it. Tell us which page is affected and what customers should be able to find there.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
