Status Code Integrity Audit

Modern frameworks serve 200 for almost everything, so a deleted product, an empty filter result and a failed third-party call all look like healthy pages to a crawler. Google then has to guess, via soft 404 detection, which is slow and unreliable. The reflex fix of adding noindex is wrong for most of these states, because it keeps the URL in the crawl queue indefinitely instead of removing it.

The skill file

---
name: status-code-integrity-audit
description: Use when removed, empty or failed pages return 200 OK, when soft 404s appear in Search Console, or before removing a batch of URLs from a site.
---

# Status Code Integrity Audit

Modern frameworks serve 200 for almost everything, so a deleted product, an empty filter result and a failed third-party call all look like healthy pages to a crawler. Google then has to guess, via soft 404 detection, which is slow and unreliable. The reflex fix of adding noindex is wrong for most of these states, because it keeps the URL in the crawl queue indefinitely instead of removing it.

## What you need first

- A crawl export with status codes, plus the Search Console soft 404 list
- A list of every state the application can produce with no useful content, taken from the code or from the developers rather than from a crawl
- Command line access to request URLs and read raw response headers
- The ability to change status codes in the application and to see what the CDN does to them

## Method

1. Enumerate the failure states from the code base with the developers: deleted item, empty search or filter result, expired listing, permanently out of stock, login gated, failed API dependency. A crawl only finds the states that are already linked, which is the minority of them.
2. Request one URL per state from the command line and record the header status, not what the page body says. A page reading "not found" while sending 200 is the most common finding in this audit and it is invisible in a browser.
3. Assign the correct code per state: 404 where the thing is gone and has no equivalent, 410 where you are certain and want faster removal, 301 where a genuine one-to-one replacement exists, 200 with real content where the page still serves a purpose, and 503 with Retry-After for planned downtime.
4. Check what happens under load and during dependency failures. A server that answers 200 with an error page hides an outage from monitoring and from Google, while a correct 503 gets crawling backed off and resumed without index loss.
5. Reconcile the list against the soft 404 report. Every entry there is Google stating that it disagrees with your 200, and it is the cheapest confirmation you will get that a state is misclassified.
6. Verify at the header level after deploying, because an edge worker, a cache rule or a custom error page can rewrite a status the application set correctly, and the application logs will show the correct one.
7. Watch crawl stats for two weeks. A large batch of new 404s or 410s produces an alarming graph that is expected and self-correcting; a rise in 5xx in the same window is not, and needs stopping.

## What this produces

A state-by-state response code map with the current and correct code for each, and a verified header-level check confirming what production actually sends.

## Where this goes wrong

- Redirecting every removed page to the homepage, which Google treats as a soft 404 anyway while destroying the signal that the page is gone
- Serving 200 with a noindex on an empty state, so the URL stays in the crawl queue forever and never leaves
- Testing in a browser, where a client-side router or service worker can render a 404 page that was delivered with a 200 header
- Answering 404 during a maintenance window instead of 503, which drops working pages out of the index for the sake of an hour

---

From the QuQi skill library - https://www.quqi.io/skills/status-code-integrity-audit

What you need first

• A crawl export with status codes, plus the Search Console soft 404 list
• A list of every state the application can produce with no useful content, taken from the code or from the developers rather than from a crawl
• Command line access to request URLs and read raw response headers
• The ability to change status codes in the application and to see what the CDN does to them

Method

1. 01 Enumerate the failure states from the code base with the developers: deleted item, empty search or filter result, expired listing, permanently out of stock, login gated, failed API dependency. A crawl only finds the states that are already linked, which is the minority of them.
2. 02 Request one URL per state from the command line and record the header status, not what the page body says. A page reading "not found" while sending 200 is the most common finding in this audit and it is invisible in a browser.
3. 03 Assign the correct code per state: 404 where the thing is gone and has no equivalent, 410 where you are certain and want faster removal, 301 where a genuine one-to-one replacement exists, 200 with real content where the page still serves a purpose, and 503 with Retry-After for planned downtime.
4. 04 Check what happens under load and during dependency failures. A server that answers 200 with an error page hides an outage from monitoring and from Google, while a correct 503 gets crawling backed off and resumed without index loss.
5. 05 Reconcile the list against the soft 404 report. Every entry there is Google stating that it disagrees with your 200, and it is the cheapest confirmation you will get that a state is misclassified.
6. 06 Verify at the header level after deploying, because an edge worker, a cache rule or a custom error page can rewrite a status the application set correctly, and the application logs will show the correct one.
7. 07 Watch crawl stats for two weeks. A large batch of new 404s or 410s produces an alarming graph that is expected and self-correcting; a rise in 5xx in the same window is not, and needs stopping.

What this produces

A state-by-state response code map with the current and correct code for each, and a verified header-level check confirming what production actually sends.

Where this goes wrong

• Redirecting every removed page to the homepage, which Google treats as a soft 404 anyway while destroying the signal that the page is gone
• Serving 200 with a noindex on an empty state, so the URL stays in the crawl queue forever and never leaves
• Testing in a browser, where a client-side router or service worker can render a 404 page that was delivered with a 200 header
• Answering 404 during a maintenance window instead of 503, which drops working pages out of the index for the sake of an hour

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Technical SEO