Welche Änderungen ein Gate brauchen
Gate-pflichtig sind vor allem neue URL-Klassen und URL-generierende Funktionen, Änderungen an Indexierungs-, Canonical- oder Crawl-Logik, neue oder stark veränderte Templates, systemweite Navigation, Migrationen, größere Konsolidierungen und Decommissioning. Normale Änderungen innerhalb freigegebener Leitplanken brauchen kein manuelles SEO-Gate.
Das Gate nach Risiko skalieren
Nicht jeder Change braucht dieselbe Prüfung. Eine lokale Textkorrektur innerhalb eines freigegebenen Templates kann durch bestehende Tests und den normalen Content-Workflow laufen. Eine neue Facettenlogik kann dagegen sehr viele URLs erzeugen und braucht vorab Scope, URL-Class-Entscheidung, technische Tests und einen Verifikationsplan.
| Change-Typ | Beispiel | Passende Kontrolle |
|---|---|---|
| innerhalb freigegebener Leitplanken | redaktionelle Änderung ohne Template- oder Directive-Eingriff | automatisierte Standardchecks, kein manuelles SEO-Gate |
| strukturell begrenzt | Änderung an einem bekannten Seitentyp | gezielter Preflight und benannter Owner |
| systemweit | neue URL-Klasse, Navigation, Migration oder Canonical-Logik | vollständiger Gate-Prozess mit Evidence, Freigabe und Rollback |
Die Einstufung sollte vor dem Release bekannt sein. Sie darf nicht erst dann erfunden werden, wenn ein Team unter Zeitdruck eine Ausnahme benötigt.
Der Preflight
Was technisch geprüft wird
Die konkrete Auswahl hängt vom Change ab. Typische Invarianten sind erreichbare Ziel-URLs, erwartete Statuscodes, keine blockierenden Robots-Regeln, korrekte selbst- oder fremdreferenzierende Canonicals, crawlbare interne Links, konsistente Hreflang-Cluster, sichtbarer Hauptinhalt nach Rendering, valide zum Inhalt passende strukturierte Daten und aktualisierte Sitemaps.
Performance- und Analytics-Prüfungen gehören dazu, wenn der Release diese Systeme berührt. Sie dürfen nicht als pauschale Gate-Pflicht jeden redaktionellen Change verlangsamen.
Block, Pass oder Ausnahme
Ein Block braucht eine vorher definierte Regel. SEO besitzt kein persönliches Universalveto. Wenn eine Änderung aber gegen verbindliche Search-Governance-Regeln verstößt oder die Voraussetzungen für geplante Indexierbarkeit fehlen, muss die Freigabe innerhalb dieses Bereichs verweigert werden können.
Eine Ausnahme dokumentiert Owner, Begründung, Scope, Risiko, Genehmigung, Status und Review. Temporäre Ausnahmen erhalten Zielzustand und Rückführungsbedingung. Dauerhafte Ausnahmen werden ausdrücklich so entschieden und regelmäßig überprüft.
Rollback und Verifikation
Vor dem Deployment muss geklärt sein, welche technische Änderung zurückgenommen werden kann und welches Signal einen Rollback auslöst. Nach dem Release werden zuerst direkt beobachtbare Invarianten geprüft. Crawl-, Index- und Performance-Signale folgen in einem Zeitraum, der zu deren tatsächlicher Verzögerung passt.
Ein grüner Preflight beweist keine spätere Rankingwirkung. Er bestätigt, dass der vereinbarte technische Zustand ausgeliefert wurde.
Evidence nach dem Release
Direkte Evidence kann aus HTTP-Antworten, gerendertem HTML, Canonicals, Robots-Angaben, Links, strukturierten Daten und Sitemap-Einträgen bestehen. Zeitverzögerte Evidence umfasst Bot-Requests, Indexierungsberichte und Performance-Daten. Beide Ebenen müssen zum ursprünglichen Scope zurückgeführt werden, damit ein globaler Mittelwert keinen lokalen Fehler verdeckt.