SEO-Rollback-Plan: Technischer Ablauf und QA

Was hier wirklich geprüft wird

Definieren Sie getrennte Rollback-Punkte für App-Release, DB-Migration, CDN/Edge, Redirects, DNS, Feature Flags, Templates und Cache. Nur Code zurückzusetzen ist oft unvollständig.

Sollverhalten und Entscheidungsgrenze

Sollzustand: Definieren Sie getrennte Rollback-Punkte für App-Release, DB-Migration, CDN/Edge, Redirects, DNS, Feature Flags, Templates und Cache. Nur Code zurückzusetzen ist oft unvollständig. Fuer jede URL-/Host-Klasse wird vorab ein erwarteter Status, ein erwartetes Ziel und der Owner festgelegt. PASS bedeutet, dass gemessener HTTP-/DNS-/DOM-Zustand dieser Definition entspricht und keine unerklärte Zwischenstufe entsteht.

Diagnose: welche Messdaten erfassen

Erfassen Sie die Prüfung als Tabelle, damit Release- und SEO-Teams denselben Zustand sehen:

url,expected_status,actual_status,expected_target,actual_target,canonical,robots,owner
https://old.example/a,301,301,https://new.example/a,https://new.example/a,https://new.example/a,index,platform

Zusätzlich gehören bei Host-/Infrastruktur-Änderungen DNS-Antwort, TLS/SNI, CDN-Cache-Status und Zeitstempel in die Messdaten. Ein Screenshot allein reicht nicht, weil er weder Statuscode noch Redirect-Kette belegt.

Technische Umsetzung

Definieren Sie getrennte Rollback-Punkte für App-Release, DB-Migration, CDN/Edge, Redirects, DNS, Feature Flags, Templates und Cache. Nur Code zurückzusetzen ist oft unvollständig.

curl -I https://old.example/path
curl -IL https://old.example/path
curl -I https://new.example/path

Erfassen Sie mindestens eine repräsentative URL pro Template/Pfadklasse und speichern Sie den erwarteten sowie gemessenen HTTP-Status. Bei DNS/CDN-Themen zusätzlich Resolver-Ergebnis, Zertifikat/SNI, Host-Header-Routing und Cache-Status dokumentieren. Bei Redirects immer den ersten Hop und das tatsächlich ausgelieferte Ziel getrennt testen.

Typische Ursachen

Typische Ursachen sind unvollständige URL-Inventare, parallel geänderte CMS-/Design-/Domain-Schichten, nicht getestete Edge-Regeln, alte absolute URLs in Templates, unterschiedliche Production-/Staging-Konfiguration und fehlende Rollback-Grenzen. Bei einem Fehler zuerst klären, ob er in DNS/TLS, Webserver/CDN, Application-Routing, CMS/Template oder Page-Level-Metadaten entsteht.

Sonderfälle und Fehlalarme

Nicht jeder Unterschied ist ein Fehler: bewusste 404/410-Ziele können korrekt sein, ein temporärer 302 kann bei Tests richtig sein, und DNS-Antworten können während TTL-Propagation differieren. Definieren Sie pro URL-Klasse das erwartete Verhalten, bevor Sie Abweichungen automatisch „reparieren“. Bei Login/API/non-GET-Endpunkten Redirect-Semantik separat prüfen.

Verifikation nach dem Fix

| Check | PASS | FAIL | | --- | --- | --- | | Output | erwartete Regel ist im tatsächlich ausgelieferten HTML/HTTP/DOM sichtbar | Backend zeigt korrekt, tatsächlich ausgelieferte Ausgabe aber nicht | | Scope | repräsentative URLs aller betroffenen Templates getestet | nur eine Beispiel-URL getestet | | Source | systemische Ursache/Owner dokumentiert | manuelle Einzel-Edits ohne Root Cause | | Regression | angrenzende Canonical/Robots/Accessibility/Link-Regeln bleiben korrekt | Fix erzeugt neuen Fehler in derselben Component | | Evidence | Vorher/Nachher-Werte und Testzeitpunkt gespeichert | nur visueller Eindruck oder Screenshot |

Verantwortung und Übergabe

Content/SEO-Owner: definiert den erwarteten Seitenzweck und ob die Abweichung wirklich behoben werden muss.
Developer/Platform: behebt die systemische Template-, Routing-, Header- oder Component-Ursache.
QA: testet repräsentative Edge States und führt einen Re-Crawl/Re-Request nach Deployment aus.
Release Owner: dokumentiert Zeitpunkt, Scope und Rollback-Punkt, damit Monitoring-Signale später eindeutig zugeordnet werden können.

Abnahmekriterien

PASS, wenn der tatsächlich ausgelieferte technische Zustand auf repräsentativen URLs konsistent nachweisbar ist, die systemische Ursache behoben wurde, erlaubte Ausnahmen dokumentiert sind und Re-Crawl/Re-Request keine neue Regression bei Canonical, Robots, Accessibility, internen/externen Links oder Rendering zeigt.

Operatives Beispiel: Fehler → Fix → Nachweis

Fehlerbild: Der Audit meldet „SEO-Rollback-Plan: Technischer Ablauf und QA“ auf mehreren URLs.
Root Cause: Die systemische Ausgabe entsteht in einem Template, Component, CMS-Fallback oder Infrastruktur-Layer.
Fix: Ändern Sie diese systemische Quelle statt einzelner Seiten und halten Sie die Änderung so klein wie möglich.
Nachweis: Speichern Sie mindestens eine vorher/nachher URL pro Template, tatsächlich ausgelieferten HTTP/HTML/DOM-Output und das Re-Crawl-Ergebnis. Wenn ein Sonderfall bewusst anders bleibt, dokumentieren Sie ihn explizit, damit das Audit ihn nicht später wieder als unbehandelten Fehler interpretiert.

Für produktive Systeme sollte der Fix außerdem eine Regression-Prüfung enthalten: gleiche Locale, Mobile/Desktop falls relevant, leere Datenzustände und eine Seite, die bereits korrekt war. So wird sichtbar, ob der Fix nur den gemeldeten Fall löst oder den Generator insgesamt stabilisiert.

1. Betroffene URL-/Template-Klasse definieren und Expected Behavior schriftlich festlegen.
2. Raw HTTP/HTML erfassen; bei clientseitigen Änderungen zusätzlich den gerenderten DOM prüfen.
3. Redirect-/Status-Matrix gegen die tatsächlich ausgelieferte Ziel-URL prüfen; keinen Test nur mit Follow-Redirects beginnen.
4. Den Fehler auf die systemische Schicht zurückführen: DNS/CDN, Routing, Template, Component, CMS-Feld oder Editor-Inhalt.
5. Den kleinsten systemischen Fix umsetzen und vorher einen Rollback-Punkt sichern.
6. Positive Fälle, leere/fehlende Daten und mindestens einen Edge Case testen.
7. Alle betroffenen Templates/URLs erneut crawlen bzw. requesten und Vorher/Nachher-Messdaten speichern.
8. PASS: erwartetes Verhalten ist konsistent nachweisbar, keine angrenzende SEO-/Accessibility-Regel regressiert und der Fix benötigt keine manuellen Einzel-Workarounds.