Audit der Statuscode-Integrität

Moderne Frameworks liefern für fast alles einen 200 aus, sodass ein gelöschtes Produkt, ein leeres Filterergebnis und ein fehlgeschlagener Drittanbieter-Aufruf für einen Crawler alle wie gesunde Seiten aussehen. Google muss dann raten, über die Soft-404-Erkennung, die langsam und unzuverlässig ist. Der Reflex, einfach ein noindex zu setzen, ist für die meisten dieser Zustände falsch, weil die URL damit unbegrenzt in der Crawl-Warteschlange bleibt, statt zu verschwinden.

Die Skill-Datei

---
name: status-code-integrity-audit
description: Verwenden Sie dies, wenn entfernte, leere oder fehlgeschlagene Seiten 200 OK zurückgeben, wenn in der Search Console Soft 404s auftauchen, oder bevor Sie eine grössere Menge URLs von einer Website entfernen.
---

# Audit der Statuscode-Integrität

Moderne Frameworks liefern für fast alles einen 200 aus, sodass ein gelöschtes Produkt, ein leeres Filterergebnis und ein fehlgeschlagener Drittanbieter-Aufruf für einen Crawler alle wie gesunde Seiten aussehen. Google muss dann raten, über die Soft-404-Erkennung, die langsam und unzuverlässig ist. Der Reflex, einfach ein noindex zu setzen, ist für die meisten dieser Zustände falsch, weil die URL damit unbegrenzt in der Crawl-Warteschlange bleibt, statt zu verschwinden.

## Was Sie vorher brauchen

- Ein Crawl-Export mit Statuscodes sowie die Soft-404-Liste aus der Search Console
- Eine Liste aller Zustände, in denen die Anwendung keinen brauchbaren Inhalt erzeugt, entnommen aus dem Code oder von den Entwicklern statt aus einem Crawl
- Zugang zur Kommandozeile, um URLs abzurufen und rohe Response-Header zu lesen
- Die Möglichkeit, Statuscodes in der Anwendung zu ändern und zu sehen, was das CDN damit macht

## Methode

1. Erfassen Sie die Fehlerzustände gemeinsam mit den Entwicklern aus der Codebasis: gelöschtes Objekt, leeres Such- oder Filterergebnis, abgelaufenes Angebot, dauerhaft nicht mehr lieferbar, hinter Login, fehlgeschlagene API-Abhängigkeit. Ein Crawl findet nur die bereits verlinkten Zustände, und das ist die Minderheit.
2. Rufen Sie je Zustand eine URL von der Kommandozeile ab und notieren Sie den Status im Header, nicht das, was der Seitentext sagt. Eine Seite, die "nicht gefunden" anzeigt und dabei 200 sendet, ist der häufigste Befund dieses Audits, und im Browser ist er unsichtbar.
3. Weisen Sie je Zustand den richtigen Code zu: 404, wo die Sache weg ist und es keine Entsprechung gibt; 410, wo Sie sicher sind und eine schnellere Entfernung wollen; 301, wo es einen echten Eins-zu-eins-Ersatz gibt; 200 mit echtem Inhalt, wo die Seite weiterhin einen Zweck erfüllt; und 503 mit Retry-After bei geplanter Nichtverfügbarkeit.
4. Prüfen Sie, was unter Last und beim Ausfall von Abhängigkeiten passiert. Ein Server, der eine Fehlerseite mit 200 beantwortet, verbirgt eine Störung vor dem Monitoring und vor Google, während ein korrekter 503 das Crawling drosselt und danach ohne Indexverlust wieder aufnimmt.
5. Gleichen Sie die Liste mit dem Soft-404-Bericht ab. Jeder Eintrag dort ist Googles Aussage, dass es Ihrem 200 widerspricht, und die günstigste Bestätigung, die Sie für einen falsch eingestuften Zustand bekommen.
6. Prüfen Sie nach dem Deployment auf Header-Ebene nach, denn ein Edge-Worker, eine Cache-Regel oder eine eigene Fehlerseite kann einen Status überschreiben, den die Anwendung korrekt gesetzt hat, und die Anwendungslogs zeigen weiterhin den korrekten.
7. Beobachten Sie die Crawl-Statistiken zwei Wochen lang. Eine grosse Menge neuer 404er oder 410er erzeugt eine alarmierende Kurve, die erwartbar ist und sich von selbst wieder legt; ein Anstieg der 5xx im selben Zeitfenster tut das nicht und muss gestoppt werden.

## Was dabei herauskommt

Eine Zuordnung von Antwortcodes je Zustand mit dem aktuellen und dem korrekten Code sowie eine auf Header-Ebene verifizierte Prüfung dessen, was die Produktion tatsächlich sendet.

## Wo es schiefgeht

- Jede entfernte Seite auf die Startseite weiterleiten, was Google ohnehin als Soft 404 wertet und zugleich das Signal zerstört, dass die Seite weg ist
- 200 mit einem noindex für einen leeren Zustand ausliefern, sodass die URL für immer in der Crawl-Warteschlange bleibt und sie nie verlässt
- Im Browser testen, wo ein clientseitiger Router oder ein Service Worker eine 404-Seite rendern kann, die mit einem 200-Header ausgeliefert wurde
- Während eines Wartungsfensters mit 404 statt 503 antworten, was funktionierende Seiten wegen einer Stunde aus dem Index wirft

---

Aus der QuQi-Skill-Bibliothek - https://www.quqi.io/de/skills/status-code-integrity-audit

Was Sie vorher brauchen

• Ein Crawl-Export mit Statuscodes sowie die Soft-404-Liste aus der Search Console
• Eine Liste aller Zustände, in denen die Anwendung keinen brauchbaren Inhalt erzeugt, entnommen aus dem Code oder von den Entwicklern statt aus einem Crawl
• Zugang zur Kommandozeile, um URLs abzurufen und rohe Response-Header zu lesen
• Die Möglichkeit, Statuscodes in der Anwendung zu ändern und zu sehen, was das CDN damit macht

Methode

1. 01 Erfassen Sie die Fehlerzustände gemeinsam mit den Entwicklern aus der Codebasis: gelöschtes Objekt, leeres Such- oder Filterergebnis, abgelaufenes Angebot, dauerhaft nicht mehr lieferbar, hinter Login, fehlgeschlagene API-Abhängigkeit. Ein Crawl findet nur die bereits verlinkten Zustände, und das ist die Minderheit.
2. 02 Rufen Sie je Zustand eine URL von der Kommandozeile ab und notieren Sie den Status im Header, nicht das, was der Seitentext sagt. Eine Seite, die "nicht gefunden" anzeigt und dabei 200 sendet, ist der häufigste Befund dieses Audits, und im Browser ist er unsichtbar.
3. 03 Weisen Sie je Zustand den richtigen Code zu: 404, wo die Sache weg ist und es keine Entsprechung gibt; 410, wo Sie sicher sind und eine schnellere Entfernung wollen; 301, wo es einen echten Eins-zu-eins-Ersatz gibt; 200 mit echtem Inhalt, wo die Seite weiterhin einen Zweck erfüllt; und 503 mit Retry-After bei geplanter Nichtverfügbarkeit.
4. 04 Prüfen Sie, was unter Last und beim Ausfall von Abhängigkeiten passiert. Ein Server, der eine Fehlerseite mit 200 beantwortet, verbirgt eine Störung vor dem Monitoring und vor Google, während ein korrekter 503 das Crawling drosselt und danach ohne Indexverlust wieder aufnimmt.
5. 05 Gleichen Sie die Liste mit dem Soft-404-Bericht ab. Jeder Eintrag dort ist Googles Aussage, dass es Ihrem 200 widerspricht, und die günstigste Bestätigung, die Sie für einen falsch eingestuften Zustand bekommen.
6. 06 Prüfen Sie nach dem Deployment auf Header-Ebene nach, denn ein Edge-Worker, eine Cache-Regel oder eine eigene Fehlerseite kann einen Status überschreiben, den die Anwendung korrekt gesetzt hat, und die Anwendungslogs zeigen weiterhin den korrekten.
7. 07 Beobachten Sie die Crawl-Statistiken zwei Wochen lang. Eine grosse Menge neuer 404er oder 410er erzeugt eine alarmierende Kurve, die erwartbar ist und sich von selbst wieder legt; ein Anstieg der 5xx im selben Zeitfenster tut das nicht und muss gestoppt werden.

Was dabei herauskommt

Eine Zuordnung von Antwortcodes je Zustand mit dem aktuellen und dem korrekten Code sowie eine auf Header-Ebene verifizierte Prüfung dessen, was die Produktion tatsächlich sendet.

Wo es schiefgeht

• Jede entfernte Seite auf die Startseite weiterleiten, was Google ohnehin als Soft 404 wertet und zugleich das Signal zerstört, dass die Seite weg ist
• 200 mit einem noindex für einen leeren Zustand ausliefern, sodass die URL für immer in der Crawl-Warteschlange bleibt und sie nie verlässt
• Im Browser testen, wo ein clientseitiger Router oder ein Service Worker eine 404-Seite rendern kann, die mit einem 200-Header ausgeliefert wurde
• Während eines Wartungsfensters mit 404 statt 503 antworten, was funktionierende Seiten wegen einer Stunde aus dem Index wirft

Diese Skill in Ihrer eigenen KI nutzen

Die Datei ist einfaches Markdown, mit Name und Auslöser im Frontmatter. Wo ein Assistent Skills selbst laden kann, liest er genau dieses Frontmatter, um zu entscheiden, dass diese hier passt.

Mehr in Technisches SEO