Possible soft 404 (empty or error page returning 200)
soft_404Short answer
The server says 200 OK, but the page is nearly empty and its title says "not found" or similar. Google classifies this as a soft 404 and does not index it. If the content is really gone, return 404 or 410; if the page is empty by mistake, restore the content.
Why it matters
Google treats a soft 404 the same as a real one for indexing — the URL is dropped — but with a worse side effect: crawlers keep re-fetching it because the status code says the page exists, and your "not found" handling cannot be verified in Search Console as a 404. A listing page that returns 200 with "no results" is the classic case.
How Glimana detects it
The rule fires when a 200 page has fewer than 30 words and a title matching "not found", "404", "page does not exist" (and the equivalents in the site's language). The evidence shows the title.
How to fix it
- Find the affected pages in Glimana. Open Issues › Possible soft 404 (empty or error page returning 200). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Make the application return a 404 (or 410 for permanently removed content) with the error template. For empty listings, either return 404 when a category has no items, or give the page real content (an explanation and links) so it is not empty.
WordPress returns 404 correctly for unknown URLs. Soft 404s come from plugins that render "not found" inside a normal page template (search results, custom post type archives with no posts). Add
status_header(404)in the template when the query has no results, or exclude empty archives from indexing.Empty collections return 200 with "No products found". Either unpublish empty collections or add a noindex to them while empty.
Return the correct status in the controller; do not render the error view with 200.
-
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the URL returns 404/410 or has substantive content. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the URL returns 404/410 or has substantive content.