SEO-Checkliste für die Website-Migration

Eine Website-Migration ist eine kontrollierte Änderung der Plattform, Domain, des Protokolls, der Informationsarchitektur, der URL-Struktur oder des Rendering-Systems einer Website. Sie ist erst dann abgeschlossen, wenn Benutzer, Crawler und Analytics-Systeme über stabile Routen auf die gewünschten Inhalte zugreifen können und das Team nachweisen kann, dass wertvolle Sichtbarkeit erhalten geblieben ist.

Checkliste: Website-Migration SEO. Zeitrahmen: für eine mittelgroße Website 6–12 Wochen vor dem Launch beginnen; die letzten 5 Arbeitstage für einen Änderungsstopp reservieren, den Launch-Tag für betreute Validierung und mindestens 4 Wochen für aktive Überwachung. Verantwortlich: ein Migrationsleiter, der für die gesamte Veröffentlichung verantwortlich ist, unterstützt von benannten Verantwortlichen für Entwicklung, SEO, Analytics, Content und Infrastruktur.

Warum diese Checkliste existiert und warum sie hier läuft

Diese Release-Steuerungsebene im SEO-Prozess verwendet Crawl- und Index-Daten aus dem technischen Baseline-Audit , Keep-/Merge-/Remove-Entscheidungen aus der Content-Inventur und dem Audit sowie die Zielhierarchie aus der thematischen Karte und Informationsarchitektur . Diese Ergebnisse müssen vorliegen, bevor Weiterleitungen oder Staging bewertet werden können.

Führen Sie sie aus, nachdem die Zielstruktur genehmigt wurde, aber bevor die Produktionsrouten eingefroren sind. Wenn sie zu früh ausgeführt wird, ordnet das Team Weiterleitungen Zielen zu, die sich möglicherweise noch ändern. Wenn sie zu spät ausgeführt wird, sind Routing, Vorlagen, Analytics oder Launch-Kommunikation möglicherweise bereits zu teuer, um sie sicher zu korrigieren.

Die Weiterleitungszuordnung ist das Artefakt mit dem höchsten Risiko, da sie alte Routen mit neuen verbindet. Jede wertvolle alte URL sollte eins-zu-eins auf das nächstgelegene Ziel weitergeleitet werden, das ihren Zweck erhält. Verwenden Sie niemals die Startseite als Sammelbecken: Sie frustriert Besucher und verschleiert fehlende Ziele.

Ein- und Ausgaben

Die Ausgaben sind der Vertrag mit der Launch-Operation. Eine Tabelle ohne Verantwortliche, Belege oder Akzeptanzkriterien ist keine Übergabe.

Die Checkliste

Jeder Punkt nennt was, warum, wie, Werkzeug und eine beobachtbare Erledigt-Bedingung. Ersetzen Sie einen Schwellenwert nur durch eine strengere Regel oder eine dokumentierte, auf der Baseline basierende Regel.

Phase 1: Pre-Migration-Inventur

1. Erstellen Sie das vereinigte URL-Inventar. Was: kombinieren Sie jede auffindbare alte URL aus Crawls, XML-Sitemaps, Analytics, Search Console, Backlink-Exporten, CMS-Datensätzen, bezahlten Kampagnen und Server-Logs. Warum: keine einzelne Quelle enthält jede wertvolle oder angefragte URL; eine in der Navigation nicht vorhandene Seite kann dennoch Links, Traffic oder vertragliche Bedeutung haben. Wie: normalisieren Sie Protokoll, Host, Groß-/Kleinschreibung, abschließenden Schrägstrich, Parameter und codierte Zeichen, während Sie den rohen Quellwert beibehalten. Deduplizieren Sie erst, nachdem dokumentiert wurde, wo jede URL gefunden wurde. Werkzeug: Crawler, CMS-Export, Analytics, Search Console, Backlink-Daten und Logs. Erledigt wenn: jede Quelle datiert ist, jede Zeile eine normalisierte URL und eine Auffindungsquelle hat, Duplikate aufgelöst sind und die Quellsummen mit dem endgültigen Inventar übereinstimmen.

2. Klassifizieren Sie die Disposition jeder URL. Was: kennzeichnen Sie jede URL als beibehalten, verschieben, zusammenführen, entfernen oder untersuchen. Warum: Weiterleitungen können erst korrekt zugeordnet werden, wenn die Content-Entscheidung explizit ist. Wie: kombinieren Sie Traffic, Conversions, Backlinks, Indexzustand, Inhaltsqualität, Geschäftsbedarf und Intent; dokumentieren Sie den Beleg und den genehmigenden Verantwortlichen. Werkzeug: Inventar-Arbeitsmappe und Content-Audit. Erledigt wenn: 100% der im Scope befindlichen URLs eine Disposition, einen Verantwortlichen, ein Ziel oder einen Entfernungsgrund haben und zum Zeitpunkt des Einfrierens keine ungelöste „Untersuchen“-Zeile mehr vorhanden ist.

3. Erfassen Sie die unterzeichnete Baseline. Was: bewahren Sie vor dem Launch die organischen Sitzungen, Klicks, Impressionen, Conversions, Umsätze, indexierten URLs, Crawl-Fehler, Antwortcodes, Verfügbarkeit und Performance für Prioritätsvorlagen und -verzeichnisse auf. Warum: ohne einen datierten Vergleichspunkt sehen normale Schwankungen und Migrationsschäden gleich aus. Wie: exportieren Sie mindestens 28 vergleichbare Tage, kommentieren Sie Kampagnen und Saisonalität und identifizieren Sie Prioritäts-URLs, die eine tägliche Überprüfung erfordern. Werkzeug: Analytics, Search Console, Crawler, Ranking-Daten und Monitoring. Erledigt wenn: die Baseline schreibgeschützt, reproduzierbar, segmentiert, mit Zeitstempel versehen und von den SEO- und Analytics-Verantwortlichen genehmigt ist.

Phase 2: Weiterleitungszuordnung

4. Ordnen Sie Quellen wo immer möglich eins-zu-eins zu. Was: weisen Sie jede verschobene oder zusammengeführte alte URL der nächstgelegenen neuen URL mit derselben Hauptintention zu. Warum: ein präzises Ziel bewahrt die Kontinuität für den Besucher und gibt Crawlern ein kohärentes Ersatzsignal. Wie: vergleichen Sie Thema, Produkt, Geografie, Sprache und Aufgabe; ordnen Sie Zusammenführungen der überlebenden Seite zu und dokumentieren Sie bewusste Entfernungen. Ordnen Sie niemals nicht zugeordnete URLs der Startseite zu. Werkzeug: Arbeitsmappe für die Weiterleitungszuordnung, Inventar und Ziel-Crawl. Erledigt wenn: jede sich ändernde Quelle genau ein genehmigtes Ergebnis hat, jedes Ziel relevant und im Scope ist und Startseiten-Sammelzuordnungen gleich Null sind.

5. Validieren Sie die Weiterleitungsmechanik vor dem Launch. Was: testen Sie Statuscodes, Ziele, Query-Verhalten, Groß-/Kleinschreibungsvarianten, Protokoll, Subdomains, abschließende Schrägstriche, Dateien und Kampagnen-URLs. Warum: eine korrekt aussehende Tabelle kann dennoch Schleifen, Ketten, Platzhalter, die gültige Seiten verschlucken, oder Ziele, die Fehler zurückgeben, produzieren. Wie: generieren Sie die Staging- oder Proxy-Regeln, fordern Sie jede Quelle an, folgen Sie den Sprüngen und vergleichen Sie die endgültige URL mit der genehmigten Zuordnung. Werkzeug: automatisierter HTTP-Test, Crawler und Server-Konfigurationsprüfung. Erledigt wenn: 100% der zugeordneten Quellen das genehmigte 200-Ziel in einem permanenten Weiterleitungssprung erreichen; Schleifen, Ketten, temporäre Weiterleitungen und Fehlerziele gleich Null sind.

6. Gleichen Sie Kanonikalien, Links und Sitemaps mit den Weiterleitungen ab. Was: stellen Sie sicher, dass die kanonische URL , interne Links, Hreflang-Referenzen, strukturierte Daten, Feeds und XML-Sitemaps direkt auf die endgültigen URLs verweisen. Warum: das Weiterleiten alter URLs, während sie weiterhin veröffentlicht werden, erzeugt widersprüchliche Migrationssignale und verschwendet Crawler-Anfragen. Wie: crawlen Sie jede Referenzquelle und vergleichen Sie normalisierte Ziele mit der Weiterleitungszuordnung. Werkzeug: Crawler, gerendertes HTML, Sitemap-Parser und Konfigurations-Diff. Erledigt wenn: Endseiten sich selbst kanonisch referenzieren, sofern keine genehmigte Ausnahme etwas anderes vorsieht, interne Verweise auf weitergeleitete URLs gleich Null sind und neue Sitemaps nur kanonische 200-URLs enthalten.

Phase 3: Staging-Validierung

7. Testen Sie das Staging, ohne es öffentlich indexierbar zu machen. Was: crawlen Sie die vollständige Staging-Veröffentlichung, während Sie Suchmaschinen daran hindern, die Umgebung zu indexieren. Warum: das Team benötigt Crawler-Ebene-Nachweise, ohne eine doppelte Website in den Suchergebnissen zuzulassen. Wie: verwenden Sie Zugriffskontrolle für externe Crawler, führen Sie dann einen authentifizierten internen Crawl mit JavaScript-Rendering durch, wo die Produktionsseite davon abhängt. Behandeln Sie eine Staging-Sperre als temporäre Release-Konfiguration, nicht als etwas, das blind in die Produktion übernommen werden sollte. Werkzeug: authentifizierter Crawler, Browser und Antwortkopfzeilen-Inspektion. Erledigt wenn: das erwartete Staging-Inventar vom Testteam crawlbar ist, eine nicht autorisierte öffentliche Indexierung blockiert ist und die Produktions-Launch-Checkliste explizit die Entfernung von Staging-spezifischen Kontrollen vorsieht.

8. Überprüfen Sie Vorlagen und Prioritäts-Benutzerreisen. Was: testen Sie repräsentative Seiten aus jeder Vorlage sowie Navigation, Suche, Formulare, Anmeldung, Checkout, Lokalisierung, Paginierung, Filter und Fehlerseiten. Warum: ein Bestehen der Startseite deckt keinen kanonischen Fehler auf Produktseiten oder einen defekten Consent-Status auf, der Analytics unterdrückt. Wie: erstellen Sie eine Geräte-und-Vorlagen-Matrix, testen Sie saubere und zurückkehrende Sitzungen und dokumentieren Sie Screenshots oder Antwortnachweise für jedes Ergebnis. Werkzeug: Browser, Barrierefreiheitsprüfer, Validator für strukturierte Daten, Analytics-Debugger und Transaktionstests. Erledigt wenn: jede im Scope befindliche Vorlage und jede primäre Benutzerreise auf den vereinbarten Browsern und Geräten besteht, mit null kritischen offenen Fehlern.

9. Vergleichen Sie das Staging mit den genehmigten Verträgen. Was: vergleichen Sie Titel, Beschreibungen, Überschriften, Kanonikalien, Robots-Direktiven, strukturierte Daten, interne Links, Antwortcodes, Inhalte und Analytics-Tags mit der alten Website und der Ziel-Spezifikation. Warum: Plattform-Migrationen verlieren oft Metadaten oder ändern das Rendering, selbst wenn der sichtbare Text intakt erscheint. Wie: crawlen Sie die alte Produktion und das Staging mit identischen Einstellungen, segmentieren Sie Unterschiede nach Vorlage und genehmigen Sie nur beabsichtigte Änderungen. Werkzeug: Crawl-Diff-Bericht und Quellinspektion. Erledigt wenn: jeder wesentliche Unterschied entweder korrigiert oder als genehmigte Änderung mit Verantwortlichem und Grund aufgeführt ist; unbeabsichtigte noindex-, kanonische, inhaltliche und Tracking-Änderungen gleich Null sind.

10. Frieren Sie den Release-Kandidaten ein. Was: frieren Sie das URL-Inventar, die Weiterleitungszuordnung, die Routendefinitionen, die kanonischen und Robots-Regeln, die Sitemap-Generierung, die Analytics- und Consent-Einrichtung, den DNS/CDN-Plan und nicht zusammenhängende Produktionsbereitstellungen ein. Warum: ein Testergebnis gilt nur für die getestete Version. Wie: kennzeichnen Sie die Release-Artefakte, beschränken Sie Änderungen auf den Incidents-Pfad und verlangen Sie eine erneute Prüfung von allem, das von einer Notfallbearbeitung betroffen ist. Werkzeug: Bereitstellungssystem, Änderungsprotokoll und Genehmigungsnachweis. Erledigt wenn: ein unveränderlicher Kandidat benannt ist, der Zugriff eingeschränkt ist, alle Ausnahmen einen Verantwortlichen haben und jede Änderung nach dem Einfrieren ein Testergebnis trägt.

Phase 4: Launch-Tag

11. Führen Sie ein einziges verantwortetes Runbook aus. Was: setzen Sie Routing, Anwendung, DNS/CDN, Analytics, Sitemaps und Monitore in der genehmigten Reihenfolge ein. Warum: parallele, nicht sequenzierte Änderungen erschweren die Fehlerisolierung und machen ein Rollback unsicher. Wie: ein Migrationsleiter ruft jeden Schritt auf, der zugewiesene Operator dokumentiert den Abschluss, und die Validierer testen den Nachweis vor dem nächsten abhängigen Schritt. Werkzeug: Runbook, Bereitstellungs-Logs, DNS-Prüfungen und gemeinsamer Incident-Kanal. Erledigt wenn: jede Zeile eine tatsächliche Uhrzeit, einen Operator, ein Ergebnis und einen Nachweis-Link hat und keine Abhängigkeit allein aufgrund mündlicher Zusicherung als abgeschlossen markiert ist.

12. Führen Sie den Launch-Smoke-Test durch. Was: testen Sie die Startseite, die Robots-Datei, Sitemaps, mindestens eine URL pro Vorlage, jede Prioritäts-Benutzerreise, den Analytics-Empfang und eine stratifizierte Stichprobe von Weiterleitungsquellen. Warum: die schnellste sichere Reaktion erfolgt durch die Erkennung eines breiten Fehlers, bevor Caches und Crawler ihn verbreiten. Wie: testen Sie von außerhalb des Produktionsnetzwerks, verwenden Sie Desktop und Mobil, überprüfen Sie sowohl servergeliefertes HTML als auch gerenderte Ausgabe und vergleichen Sie mit den eingefrorenen Erwartungen. Werkzeug: Crawler, Browser, HTTP-Client, Analytics-Echtzeitansicht und Transaktionsmonitor. Erledigt wenn: kritische Seiten den beabsichtigten Status und Inhalt zurückgeben, Prioritäts-Weiterleitungen ihre exakten Ziele erreichen, Analytics-Ereignisse mit korrekten URLs eintreffen und alle Launch-blockierenden Prüfungen bestanden sind.

13. Übermitteln und überprüfen Sie Auffindungssignale. Was: veröffentlichen Sie die endgültigen Sitemaps, bestätigen Sie das Robots- und kanonische Verhalten und beantragen Sie die Inspektion für eine kleine Menge von Prioritäts-URLs. Warum: saubere Auffindungssignale helfen Crawlern, die Zielmenge zu erreichen, ohne dass die Einreichung als Garantie für die Indexierung behandelt wird. Wie: reichen Sie jede Produktions-Sitemap einmal ein, inspizieren Sie repräsentative neue URLs und dokumentieren Sie den von Google gemeldeten kanonischen und Index-Status. Werkzeug: Sitemaps und Indexierung und URL-Inspektion . Erledigt wenn: Sitemaps erreichbar sind und das eingefrorene kanonische Inventar enthalten, repräsentative Inspektionen keine Produktionssperre oder falsche Kanonikale zeigen und jede Warnung einen Verantwortlichen hat.

Phase 5: Post-Launch-Überwachung

14. Beobachten Sie die ersten 72 Stunden als Incident-Fenster. Was: überwachen Sie Verfügbarkeit, 5xx, 4xx, Weiterleitungsfehler, Latenz, Crawl-Volumen, Analytics-Empfang, Conversions, Sitemap-Verarbeitung und Prioritäts-Benutzerreisen kontinuierlich oder im kürzesten praktischen Intervall. Warum: Infrastruktur- und Routing-Fehler treten schnell zutage, während die Suchperformance länger braucht und nicht als einziger Launch-Alarm verwendet werden sollte. Wie: vergleichen Sie mit der unterzeichneten Baseline, segmentieren Sie nach Vorlage und Verzeichnis und leiten Sie Alarme an einen Bereitschaftsverantwortlichen weiter. Werkzeug: Logs, Analytics, Crawler, Uptime-Monitore und Incident-Dashboard. Erledigt wenn: das Dashboard keinen ungeklärten Launch-kritischen Alarm hat, jeder Vorfall einen Verantwortlichen und Zeitstempel hat und die 24-, 48- und 72-Stunden-Überprüfungen unterzeichnet sind.

15. Setzen Sie die Such- und Index-Überwachung nach der Stabilisierung fort. Was: verfolgen Sie Klicks auf Seitenebene, Impressionen, Indexzustand, ausgewählte Kanonikalien, Crawl-Fehler, Verzeichnis-Performance und Conversion-Ergebnisse für mindestens vier Wochen. Warum: Crawling, kanonische Auswahl und Index-Ersetzung hinken der Infrastruktur-Validierung hinterher. Wie: vergleichen Sie gleichartige Zeitfenster, trennen Sie verschobene URLs von unveränderten Kontrollen und untersuchen Sie Cluster, anstatt auf den Tagesgesamtbetrag zu reagieren. Werkzeug: Google Search Pages , Verzeichnisansicht , URL-Inspektion, Analytics und Logs. Erledigt wenn: Prioritätsziele auffindbar und indexierbar sind, alte URLs konsistent zu genehmigten Zielen aufgelöst werden, ungeklärte Verluste Tickets haben und die Verantwortung in den normalen Berichtsrhythmus übergeht.

Tools in AmICited

AmICited bietet Launch-Nachweise und Überwachungsoberflächen; die genehmigte Weiterleitungszuordnung und die Bereitstellungs-Logs bleiben die operative Quelle der Wahrheit.

Entscheidungsregeln

Dies sind Release-Leitplanken, keine universellen Suchmaschinen-Schwellenwerte. Vereinbaren Sie sie vor dem Launch und verschärfen Sie sie dort, wo das Risiko es erfordert.

Ein Rollback stellt einen bekannten, guten Dienstzustand wieder her; es kehrt keine normale Suchschwankung um. Die Launch-Autorität wendet die vereinbarten Regeln an und dokumentiert die Nachweise.

Liefergegenstand

Übergeben Sie ein versioniertes Migrations-Kontrollpaket, das für Engineering und SEO zugänglich ist. Verwenden Sie eine Arbeitsmappe oder Datenbank für zeilenweise Aufzeichnungen, ein Runbook für Launch-Aktionen und ein Dashboard für Live-Kennzahlen.

Es muss enthalten: das eingefrorene Inventar und die Quellenabstimmung; die genehmigte Weiterleitungszuordnung mit Verantwortlichen und Tests; abgeglichene alte, Staging- und neue Crawls; Metadaten-, Kanonikale-, Robots-, Sitemap-, Hreflang-, Strukturierte-Daten-, Link- und Analytics-Diffs; die unterzeichnete Baseline und Prioritätskohorten; das Launch-Runbook und das Wiederherstellungsverfahren; numerische Rollback-Regeln und Entscheidungsverantwortlichen; sowie die 24-, 48- und 72-Stunden-Nachweise mit vierwöchiger Überwachungsverantwortung.

Der Migrationsleiter muss in der Lage sein, das genaue Release zu identifizieren, jeden kritischen Test nachzuweisen, jede Routing-Entscheidung zu rekonstruieren und jede Ausnahme zuzuordnen. Andernfalls ist das Paket unvollständig.

Was schiefgeht

Die Weiterleitungszuordnung verwendet nur die aktuelle Sitemap. Verwaiste Seiten, Kampagnen-URLs, Backlinks und zuvor indexierte Routen verschwinden, sodass jede Tabellenzeile besteht, während echte Anfragen fehlschlagen.

Die Startseite wird zum Standardziel. Benutzer landen auf einer irrelevanten Seite, Crawler-Signale werden mehrdeutig und fehlende Inhalte werden als Implementierungsfortschritt getarnt.

Weiterleitungen funktionieren, aber Referenzen bleiben alt. Navigation, Hreflang, Kanonikalien, strukturierte Daten und Sitemaps senden Crawler weiterhin durch unnötige Sprünge und widersprüchliche Ziele.

Staging-Schutz erreicht die Produktion. Eine kopierte noindex-, Authentifizierungsregel, Robots-Sperre oder CDN-Richtlinie zerstört die Indexierbarkeit . Verlangen Sie einen expliziten Entfernungsschritt und einen externen Test.

Das Team validiert nur die Startseite. Eine gemeinsame Vorlage kann Tausende von Seiten falsch konfigurieren, während die Startseite besteht. Prüfen Sie jede Vorlage stichprobenartig und crawlen Sie Regeln im großen Maßstab.

Nicht zusammenhängende Releases werden zusammen ausgeliefert. Wenn Plattform-, Analytics-, Consent-, Navigations-, Checkout- und CDN-Änderungen ein Zeitfenster teilen, werden Fehler schwer zu isolieren oder rückgängig zu machen.

Die Suche wird zu früh oder zu allgemein beurteilt. Gesamtzahlen der Website verbergen defekte Verzeichnisse, und ein volatiler Tag führt zu unnötigen Korrekturen. Vergleichen Sie verschobene Kohorten, unveränderte Kontrollen, Verzeichnisse und abgeglichene Zeitfenster.

Das Rollback wird während der Störung debattiert. Ein guter Plan benennt Schwellenwerte, Entscheidungsträger, Wiederherstellungszeit, Befehle, Datenkonsequenzen und Validierungssequenz vor dem Launch.

Nächste Phase

Sobald die ersten 72 Stunden stabil sind, ist der nächste Schritt die kontinuierliche Aktualisierung und Iteration . Dieser benötigt die unterzeichnete Baseline, die endgültige URL-Zuordnung, Launch-Anmerkungen, Verzeichniskohorten, bekannte Ausnahmen, die Incident-Historie und benannte Verantwortliche aus dieser Checkliste. Ohne diese Eingaben kann ein späterer Traffic-Verlust nicht zuverlässig in Migrationsschaden, normale Nachfrageänderung, Content-Verfall oder Messfehler getrennt werden.

Behalten Sie die Weiterleitungszuordnung und die Migrations-Anmerkungen dauerhaft. Verschieben Sie nicht kritische Erkenntnisse mit einem Schweregrad, einer Hypothese, einem Verantwortlichen, einem Fälligkeitsdatum und einer Verifizierungsmethode in den normalen Berichtsrhythmus.

Häufig gestellte Fragen

Wann sollte das SEO-Team in eine Website-Migration einbezogen werden?

Bevor Routen, Vorlagen und Plattformbeschränkungen festgelegt sind. Das SEO-Team benötigt ausreichend Zeit, um aktuelle URLs zu inventarisieren, wertvolle Ziele zu erhalten, die neue Informationsarchitektur zu beeinflussen, das Weiterleitungsverhalten zu definieren und messbare Launch- und Rollback-Regeln zu vereinbaren.

Sollten alte URLs auf die Startseite weiterleiten, wenn es keinen direkten Ersatz gibt?

Nein. Leiten Sie eine alte URL auf die nächstgelegene Seite weiter, die dieselbe Benutzerintention erfüllt. Wenn kein relevantes Ziel existiert und der Inhalt nicht erhalten werden soll, geben Sie einen ehrlichen 404 oder 410 zurück, anstatt Benutzer und Crawler auf eine nicht zusammenhängende Startseite zu schicken.

Wie lange sollten Migrations-Weiterleitungen bestehen bleiben?

Behalten Sie permanente Weiterleitungen so lange bei, wie alte URLs noch Besuche, Links, Lesezeichen oder Crawler-Anfragen erhalten können. Behandeln Sie sie als dauerhafte Routing-Infrastruktur, nicht als Launch-Gerüst, das nach einigen Wochen entfernt werden soll.

Was sollte vor dem Migrations-Launch eingefroren werden?

Frieren Sie das genehmigte URL-Inventar, die Weiterleitungszuordnung, die kanonischen und Robots-Regeln, die Sitemap-Generierung, die Analytics- und Consent-Konfiguration, DNS- und CDN-Änderungen sowie nicht zusammenhängende Produktionsveröffentlichungen ein. Notfallkorrekturen folgen dem benannten Change-Control-Pfad.

Wann sollte eine Migration zurückgesetzt (Rollback) werden?

Verwenden Sie Kriterien, die vor dem Launch vereinbart wurden. Führen Sie ein Rollback bei Fehlern wie längerer Nichtverfügbarkeit, weit verbreiteten 5xx-Antworten, unterbrochenen primären Benutzerreisen, fehlendem Analytics oder Routing-Fehlern durch, die einen wesentlichen Anteil der Prioritäts-URLs betreffen und nicht sicher innerhalb des vereinbarten Wiederherstellungszeitfensters korrigiert werden können.