Site-Migrations-Checkliste (PDF)

Eine druckbare Freigabe-Checkliste für die Site-Migration: Phasen vor dem Launch, am Launch-Tag und danach mit Ankreuzfeldern und Unterschriftszeilen der Verantwortlichen, damit nichts unverifiziert live geht.

Nutzen Sie diese Checkliste als druckbares Freigabeblatt für eine Site-Migration – die Seite, die jeder Verantwortliche vor und nach dem Go-Live ankreuzt und unterschreibt. Jede Variante ist eine Phase, von Planung und Backups über den Launch-Tag bis zum Monitoring nach dem Launch und endet mit einer formellen Freigabe. Drucken Sie sie, gehen Sie sie Phase für Phase durch und rücken Sie nicht vor, bis der Verantwortliche die Phase freigegeben hat. Das hält eine Migration verbindlich, statt sich auf Erinnerung und gute Absichten zu verlassen.

6 einsatzbereite Varianten

Phase 1: Planen & Sichern

Legen Sie den Plan fest und erstellen Sie vollständige Backups, bevor jemand auch nur eine URL ändert.

Ziel: sicherstellen, dass die Migration umkehrbar und vollständig geplant ist, bevor die Arbeit beginnt.

Vor dem Start ankreuzen

☐ Vollständiges Backup der aktuellen Site (Dateien und Datenbank) erstellt und Wiederherstellung getestet
☐ Vollständiger Crawl der alten Site exportiert und gespeichert
☐ URL-Mapping (alt zu neu) für jede Seite entworfen
☐ Analytics- und Search-Console-Ausgangswert erfasst: [Traffic- / Ranking-Snapshot]
☐ Rollback-Plan geschrieben und mit dem Dev-Verantwortlichen abgestimmt
☐ Launch-Fenster für verkehrsarme Stunden geplant: [Datum / Uhrzeit]

Freigabe Phase 1
Verantwortlich: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

Phase 2: Staging-QA

Verifizieren Sie die neue Site auf Staging, damit Probleme erkannt werden, bevor sie öffentlich werden.

Ziel: bestätigen, dass die neue Site korrekt und crawlbar ist, solange sie noch privat ist.

Auf Staging ankreuzen

☐ Redirects auf Staging getestet und liefern die erwarteten Codes
☐ Titel, Meta-Descriptions und Überschriften auf Schlüsselseiten vorhanden
☐ Canonical-Tags zeigen auf die neuen URLs
☐ Interne Links auf neue URLs aktualisiert, keine Links auf die alte Domain
☐ robots.txt erlaubt beim Launch das Crawlen (Staging-noindex beim Go-Live entfernt)
☐ XML-Sitemap mit neuen URLs erzeugt und validiert
☐ Mobile Darstellung und Seitengeschwindigkeit auf Schlüssel-Templates geprüft

Freigabe Phase 2
Verantwortlich: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

Phase 3: Launch-Tag

Die Go-Live-Sequenz, der Reihe nach angekreuzt, sobald jeder Schritt abgeschlossen ist.

Ziel: die Umstellung sauber ausführen und das Wesentliche in dem Moment bestätigen, in dem die Site live ist.

Während des Launches ankreuzen

☐ Staging-noindex / Passwortschutz entfernt
☐ Redirects in die Produktion ausgerollt
☐ robots.txt live und erlaubt das Crawlen der neuen Site
☐ Neue Sitemap in der Search Console eingereicht
☐ Analytics und Tag-Tracking bestätigt, dass sie auf der neuen Site auslösen
☐ Eine Stichprobe hochprioritärer alter URLs manuell auf Redirect bestätigt
☐ SSL-Zertifikat über die gesamte neue Domain gültig

Freigabe Phase 3
Gestartet von: [Name] Live-Zeitpunkt: [Uhrzeit] Unterschrift: [Unterschrift]

Phase 4: Erste 48 Stunden

Fangen Sie die Fehler ab, die erst auftauchen, wenn echter Traffic auf die Live-Site trifft.

Ziel: Launch-Tag-Pannen finden und beheben, bevor sie Rankings kosten.

Innerhalb von 2 Tagen ankreuzen

☐ Vollständiger Crawl der Live-Site durchgeführt; 404er und kaputte Redirects protokolliert
☐ Redirect-Ketten und -Schleifen geprüft und beseitigt
☐ Search Console auf Crawl-Fehler und Coverage-Warnungen geprüft
☐ Serverfehlerrate und Ladezeiten überwacht: [Status]
☐ Hochprioritäre Seiten als indexierbar und mit 200 bestätigt
☐ Beim Umzug verlorener Content wiederhergestellt oder markiert: [Notizen]

Freigabe Phase 4
Verantwortlich: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

Phase 5: Wochen 1–4 Monitoring

Beobachten Sie, wie sich Rankings, Indexierung und Traffic einpendeln, damit echte Einbrüche früh angegangen werden.

Ziel: bestätigen, dass die Migration gehalten hat, und auf alles reagieren, was abgerutscht ist.

Im ersten Monat ankreuzen

☐ Indexierung der neuen URLs schreitet in der Search Console voran
☐ Rankings für Prioritäts-Keywords mit dem Ausgangswert vor dem Launch verglichen
☐ Organischer Traffic gegen denselben Zeitraum des letzten Zyklus verfolgt: [Trend]
☐ Alle Seiten, die Rankings verloren haben, untersucht und behoben
☐ Backlinks, die auf alte URLs zeigen, lösen weiterhin über Redirects auf
☐ Alte Sitemap entfernt, sobald die neuen URLs indexiert sind

Freigabe Phase 5
Verantwortlich: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

Phase 6: Finale Freigabe

Schließen Sie das Projekt ab, sobald die Migration als stabil und verbindlich verifiziert ist.

Ziel: die Migration formell abschließen, mit jedem Phasenverantwortlichen in der Pflicht.

Vor dem Abschluss bestätigen

☐ Alle früheren Phasen freigegeben
☐ Keine offenen 404er oder kaputten Redirects auf Prioritätsseiten
☐ Traffic und Rankings in einer akzeptablen Bandbreite zum Ausgangswert oder erholen sich planmäßig
☐ Offene Punkte mit Verantwortlichen und Fälligkeitsdaten protokolliert: [Liste]
☐ Bericht nach der Migration mit den Stakeholdern geteilt

Projekt-Freigabe

SEO-Verantwortlich: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

Dev-Verantwortlich: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

Freigebender: [Name] Datum: [Datum] Unterschrift: [Unterschrift]

So verwendest du diese Vorlage

Drucken Sie die Checkliste und weisen Sie jeder Phase einen namentlichen Verantwortlichen zu, bevor die Arbeit beginnt.
Schließen Sie Phase 1 ab: erstellen und testen Sie ein vollständiges Backup, erfassen Sie Ausgangswerte und stimmen Sie einen Rollback-Plan ab.
Bearbeiten Sie Phase 2 vollständig auf Staging, damit Redirects, Metadaten und Crawlbarkeit privat verifiziert werden.
Führen Sie die Launch-Sequenz von Phase 3 der Reihe nach aus und bestätigen Sie Redirects und Tracking im Moment des Go-Live.
Crawlen Sie die Live-Site innerhalb von 48 Stunden auf 404er und Redirect-Probleme und beheben Sie sie schnell.
Überwachen Sie Indexierung, Rankings und Traffic über die Wochen 1 bis 4 und untersuchen Sie alles, was abrutscht.
Verlangen Sie, dass der Phasenverantwortliche jede Phase unterschreibt, bevor die Migration zur nächsten übergeht.
Erledigen Sie die finale Freigabe erst, wenn die Prioritätsseiten sauber sind und die Stakeholder den Bericht haben.

Profi-Tipps

Behandeln Sie jede Unterschriftszeile als echtes Gate, nicht als Formalität: eine unsignierte Phase bedeutet, die Arbeit ist nicht verifiziert, und unverifizierte Arbeit ist der Punkt, an dem Migrationen Traffic verlieren.
Erstellen und testen Sie die Wiederherstellung Ihres Backups, bevor Sie irgendetwas anfassen; ein Rollback-Plan, den Sie nie getestet haben, ist eine Hoffnung, kein Plan.
Planen Sie den Launch für wirklich verkehrsarme Stunden, damit die unvermeidlichen Fixes der ersten Stunde die wenigsten Nutzer betreffen.
Überwachen Sie einen ganzen Monat lang; Rankings und Indexierung pendeln sich allmählich ein, und die schlimmsten Einbrüche tauchen oft ein bis zwei Wochen nach dem Launch auf, nicht an Tag eins.

Haeufige Fragen

Warum ein druckbares PDF statt einer Tabelle?

Ein Freigabeblatt geht um Verbindlichkeit, nicht um Daten. Es zu drucken und jeden Verantwortlichen ankreuzen und unterschreiben zu lassen erzwingt an jedem Gate einen bewussten Halt. Es passt gut zu einer URL-Mapping-Tabelle, die das zeilenweise Detail übernimmt, während dieses Blatt bestätigt, dass jede Phase tatsächlich erledigt und verantwortet wurde.

Wie lange vor dem Launch sollte Phase 1 beginnen?

Beginnen Sie Planung und Backups deutlich vor dem Launch-Fenster, bei einer großen Site idealerweise Wochen im Voraus. Plan und Mapping zu überstürzen ist der Ursprung des meisten vermeidbaren Migrationsschadens. Je früher Crawl, Mapping und Rollback-Plan existieren, desto weniger Druck landet am Launch-Tag.

Was ist die wichtigste Phase?

Ehrlich gesagt fangen die Staging-QA in Phase 2 und der 48-Stunden-Crawl in Phase 4 das meiste ab. Redirects vor dem Launch zu testen und direkt danach neu zu crawlen deckt die größten Quellen von Traffic-Verlust ab. Dennoch ist das Auslassen des Backups in Phase 1 der eine Fehler, den Sie wirklich nicht rückgängig machen können.

Sollte ich nach der Migration einen Traffic-Einbruch erwarten?

Ein kurzer Rückgang, während Suchmaschinen neu crawlen und neu indexieren, ist selbst bei einer sauberen Migration üblich. Entscheidend ist, dass sich der Trend innerhalb von Wochen erholt. Ein Einbruch, der immer tiefer wird, deutet meist auf kaputte Redirects, verlorenen Content oder Indexierungsprobleme hin, die die Monitoring-Phase abfangen soll.

Wer sollte jede Phase unterschreiben?

Die Person, die tatsächlich für diese Arbeit verantwortlich ist: meist ein Entwickler für Launch und Redirects und ein SEO-Verantwortlicher für QA und Monitoring. Ein finaler Freigebender unterschreibt das gesamte Projekt. Echte Namen in jeder Zeile machen klar, wer was verifiziert hat, falls später etwas überprüft werden muss.

Kann ich das für eine kleinere Änderung wie ein Redesign wiederverwenden?

Ja, wobei Sie Phasen überspringen können, die nicht zutreffen. Ein Redesign, das die URLs unverändert lässt, braucht weniger Redirect-Arbeit, profitiert aber weiterhin von Staging-QA, einem Backup und Monitoring nach dem Launch. Kürzen Sie das Blatt auf die Phasen, die zum Umfang Ihrer konkreten Änderung passen.