Website-Relaunch Checkliste: fünf Phasen zum Go-Live

Vier Wochen vorher

In dieser Phase geht es ausschließlich um Bestandsaufnahme. Alles, was hier nicht erfasst wird, kann später nicht geprüft werden, weil die Vergleichsgrundlage fehlt. Der häufigste Fehler ist, mit dem Gestalten anzufangen, bevor man weiß, was die alte Website eigentlich leistet.

• Vollständigen Crawl der alten Website ziehen und die Adressliste sichern
• Search-Console-Daten der letzten sechzehn Monate exportieren: welche Seite bringt welche Besucher
• Titles und Descriptions aller Seiten exportieren
• Externe Verweise erfassen, damit klar ist, welche alten Adressen von außen verlinkt sind
• Serverlogs sichten, wenn die Website groß ist, um Adressen zu finden, die kein Crawl entdeckt
• Liste der Formulare, Zahlarten und Schnittstellen anlegen, die später zu testen sind

Aus den ersten beiden Punkten entsteht die Entscheidung, welche Inhalte mitkommen. Das ist der Moment, in dem gelöscht werden darf, aber nur mit Blick auf die Zahlen: Ein Fachbeitrag von 2019, der monatlich Besucher bringt, wird nicht nach Gefühl aussortiert. Wie die vier Quellen zusammen die vollständige Adressliste ergeben, steht unter SEO beim Relaunch.

Während des Aufbaus

Hier entsteht das Mapping, und zwar parallel zum Bau, nicht danach. Wer das Mapping erst anlegt, wenn die neue Struktur fertig ist, hat die Entscheidungen über Zusammenlegungen schon getroffen, ohne ihre Folgen zu kennen.

• URL-Mapping führen: jede alte Adresse mit ihrem neuen Ziel, Zeile für Zeile
• Testumgebung gegen Suchmaschinen sperren, und die Art der Sperre schriftlich festhalten
• Titles und Descriptions bewusst übernehmen oder verbessern, nie automatisch erzeugen lassen
• Interne Verlinkung der alten Seite nachbilden, nicht nur die Navigation
• Weiterleitungen in einer Datei sammeln, die beim Livegang eingespielt wird
• Bilder mit sprechenden Dateinamen und Alternativtexten anlegen

Der zweite Punkt klingt nach Formalie und ist der wichtigste der ganzen Liste. Notieren Sie wörtlich, wie die Testumgebung gesperrt ist: per Meta-Angabe, per robots.txt, per Passwortschutz oder auf mehreren Wegen gleichzeitig. Am Go-Live-Tag muss jemand genau diese Notiz abarbeiten, und mehrfach gesperrte Umgebungen sind der Grund, warum eine der Sperren überlebt.

Am Tag vor dem Livegang

Diese Phase dient der Umkehrbarkeit. Alles hier Aufgeführte hat nur einen Zweck: dass ein Problem morgen keine Katastrophe wird.

• Vollständiges Backup der alten Website samt Datenbank, abgelegt außerhalb des Servers
• DNS-TTL auf 300 Sekunden senken, falls die Domain oder der Server wechselt
• Weiterleitungsdatei fachlich gegenlesen, Stichprobe von zwanzig Zeilen manuell prüfen
• Alle Formulare in der Testumgebung absenden und die Zustellung im Postfach bestätigen
• Analytics und Conversion-Ziele im neuen System vorbereiten
• Zuständigkeiten für den nächsten Tag festlegen: wer schaltet, wer prüft, wer entscheidet

Der Punkt mit den Formularen wird regelmäßig übersprungen, weil das Formular ja sichtbar ist und eine Bestätigungsmeldung zeigt. Sichtbar heißt nicht zugestellt. Es genügt eine falsche Absenderadresse, damit der Server die Nachricht verwirft und der Besucher trotzdem „Vielen Dank" liest. Solche Fälle bleiben monatelang unentdeckt, weil sich niemand beschwert, der keine Antwort bekommt.

Die ersten sechzig Minuten

Nach dem Umschalten zählt Reihenfolge. Diese Liste steht in der Ordnung, in der geprüft werden sollte, weil die oberen Punkte die größten Schäden verhindern.

• Sperre der Testumgebung entfernt? Quelltext auf noindex prüfen, robots.txt live aufrufen
• Zwanzig alte Adressen im Browser aufrufen und schauen, wo man landet
• Startseite, drei wichtigste Unterseiten und eine tiefe Detailseite auf Statuscode 200 prüfen
• Ein Formular auf der Livesite absenden und die Zustellung bestätigen
• Bei Shops: Testkauf über jede aktive Zahlart, inklusive Eintrag in der Warenwirtschaft
• Neue Sitemap einreichen und die alte ersetzen
• Darstellung auf einem echten Handy prüfen, nicht nur im verkleinerten Browserfenster

Der zweite Punkt braucht keine Werkzeuge und findet die meisten Fehler. Nehmen Sie die zwanzig Adressen, die laut Search Console am meisten Besucher gebracht haben, und rufen Sie sie auf. Landen Sie auf der inhaltlich passenden neuen Seite, ist das Mapping im Kern in Ordnung. Landen Sie auf der Startseite, ist es das nicht, und dann ist jetzt der Moment, das zu korrigieren, und nicht in vier Wochen.

Woche eins bis acht

Diese Phase fehlt in fast jedem Angebot, und in ihr werden die Fehler der vorherigen Phasen überhaupt erst sichtbar. Technische Probleme zeigen sich in den ersten zwei Wochen, die Auswirkungen auf Rankings erst ab Woche drei.

• Search Console wöchentlich: 404-Meldungen, Indexierungsstatus, Crawl-Statistik
• Sichtbarkeit und Besucherzahlen gegen die Werte vor dem Relaunch vergleichen
• Weiterleitungsketten auflösen, wo eine Adresse über mehrere Stationen läuft
• Seiten prüfen, die vorher Besucher brachten und jetzt keine mehr bekommen
• Ladezeit unter Realbedingungen messen, nachdem echte Besucher auf der Seite sind
• DNS-TTL wieder auf den normalen Wert setzen

Eine kurze Delle in dieser Zeit ist normal und kein Zeichen für einen Fehler. Wichtig ist die Richtung: Wenn die Werte ab Woche drei steigen, läuft es. Wenn sie flach auf niedrigem Niveau bleiben, fehlt etwas, und dann lohnt der Blick zurück auf Phase eins, weil dort die Vergleichsdaten liegen.

Der Rückweg-Plan

Fast jede Checkliste im Netz endet mit dem Go-Live. Was fehlt, ist die Antwort auf die Frage, was passiert, wenn es schiefgeht. Drei Festlegungen genügen, und sie kosten zusammen eine halbe Stunde Vorbereitung.

Erstens ein Backup, das nicht auf demselben Server liegt wie die Website. Ein Backup im gleichen Verzeichnis hilft nicht, wenn das Verzeichnis das Problem ist. Zweitens eine gesenkte DNS-TTL, damit ein Zurückschalten in Minuten greift und nicht in Stunden. Drittens, und das ist der eigentliche Punkt: eine schriftliche Grenze, bei welchem Fehler zurückgeschaltet wird und wer das entscheidet.

Ohne diese Grenze passiert im Zwischenfall immer dasselbe. Es wird eine Stunde diskutiert, ob man es nicht schnell reparieren kann, dann wird repariert, dann funktioniert es halb, und am Ende war die Website einen Tag lang in einem Zustand, in dem sie nicht hätte sein dürfen. Ein Satz vorher hätte das verhindert: „Wenn der Checkout nach dreißig Minuten nicht läuft, schalten wir zurück, und das entscheidet Frau X."