Der Tag der Umschaltung — und die vier Wochen danach

Der Moment, in dem die neue Website live geht, ist der einzige im ganzen Projekt, der nicht wiederholbar ist. Alles davor kann man ändern. Ab jetzt sehen Kunden, was da ist.

Dieser Artikel geht durch, was vorher vorbereitet gehört, was am Tag selbst passiert und was in den Wochen danach kontrolliert wird.

Wann umgeschaltet wird

Nicht freitags. Nicht vor einem Feiertag. Nicht vor dem Urlaub.

Der Grund ist banal: Wenn etwas nicht funktioniert, braucht es jemanden, der es repariert. Eine Website, die Freitagnachmittag umgeschaltet wird und Samstag ein Problem hat, ist bis Montag kaputt — und zwar mit dem Formular, über das Anfragen kommen.

Der beste Zeitpunkt ist Dienstag oder Mittwoch vormittags. Genug Zeit am selben Tag, genug Puffertage in der Woche.

Und wenn es einen saisonalen Verlauf gibt: nicht in der Hochsaison. Ein Handwerksbetrieb schaltet nicht im April um, ein Steuerberater nicht im Mai.

Was vorher bereitstehen muss

Der Rückweg. Das Wichtigste. Es muss möglich sein, die alte Website innerhalb kurzer Zeit wiederherzustellen.

Praktisch heißt das: eine vollständige, geprüfte Sicherung des alten Stands, und ein klarer Ablauf, wie sie eingespielt wird. Nicht „die liegt irgendwo beim Hoster", sondern eine Datei, von der jemand weiß, wo sie liegt und wie man sie zurückspielt.

Der Rückweg wird fast nie gebraucht. Er ist der Grund, warum man ruhig bleiben kann, wenn etwas nicht stimmt.

Das Zertifikat für die Live-Adresse. Ein Zertifikat, das nur für die Testadresse gilt, erzeugt beim Umschalten eine Warnseite. Das gehört vorher geklärt.

Die DNS-Änderungen, falls der Anbieter wechselt. Wichtig dabei: DNS-Änderungen brauchen Zeit, bis sie überall angekommen sind — teilweise Stunden. In dieser Zeit sehen manche Besucher die alte, andere die neue Seite. Das ist normal und lässt sich abkürzen, indem man die Gültigkeitsdauer der DNS-Einträge einige Tage vorher herabsetzt.

Die Zwischenspeicher- und Auslieferungskonfiguration.

Und die Weiterleitungen, eingerichtet und getestet.

(Eigene Checkliste website-relaunch)

Die Prüfung direkt nach dem Umschalten

Diese Liste wird am selben Tag abgearbeitet, nicht am nächsten:

1. Der Testumgebungs-Blocker ist weg. Der wichtigste Punkt der ganzen Liste. Wenn auf der Testumgebung „Suchmaschinen blockieren" aktiviert war und diese Einstellung mit umgezogen ist, ist die neue Website für Google unsichtbar.

Das ist der teuerste Fehler bei einem Relaunch. Er wird oft erst nach Wochen bemerkt — nämlich dann, wenn der Verkehr einbricht und jemand nach der Ursache sucht.

Prüfen: deinedomain.de/robots.txt aufrufen, und im Quelltext nach noindex suchen.

2. Alle Seiten durchklicken. Desktop und Telefon. Nicht stichprobenartig — vollständig, wenn es weniger als fünfzig sind.

3. Formulare testen. Absenden, Bestätigung prüfen, und im Postfach nachschauen, ob die Mail angekommen ist. Das ist der Punkt, der bei einem Umzug am häufigsten bricht: Der Mailversand hing an einer Konfiguration des alten Servers.

Und zwar jedes Formular, nicht nur das Kontaktformular.

4. Weiterleitungen stichprobenartig testen. Die wichtigsten alten Adressen aufrufen.

5. Verschlüsselung auf allen Seiten, ohne gemischte Inhalte.

6. Die neue Sitemap in der Search Console einreichen.

7. Indexierung der wichtigsten Seiten anfordern.

8. Die Auswertung prüfen: Werden Daten erfasst? Bei einem Neuaufbau geht der Auswertungscode gern verloren.

9. Ladezeit messen und den Wert festhalten. Als Ausgangspunkt für später.

Und ein Punkt, der auf keiner technischen Liste steht: Sag deinen Kunden Bescheid. Ein kurzer Hinweis auf der Startseite oder im Newsletter — „unsere Website ist neu, wenn etwas nicht funktioniert, sagen Sie uns bitte Bescheid" — erzeugt Nachsicht und liefert die besten Fehlermeldungen.

(Eigene Checkliste website-relaunch)

Die ersten zwei Wochen

Jetzt beginnt der Teil, den viele Projekte auslassen — und in dem sich entscheidet, ob der Relaunch ein Erfolg wird.

Täglich: die Search Console prüfen. Neue Fehlerseiten, Abrufprobleme, Indexierungsmeldungen. Jede auftauchende Fehleradresse ist eine vergessene Weiterleitung und wird nachgereicht.

Das ist die produktivste Viertelstunde des ganzen Projekts. Die Fehlermeldungen der ersten Wochen sind die vollständigste Liste dessen, was im Weiterleitungsplan gefehlt hat — vollständiger als jede Vorabprüfung, weil sie auf tatsächlichen Aufrufen beruht.

Besucherzahlen im Vergleich beobachten. Ein Rückgang in den ersten Tagen ist normal — die Indexierung braucht Zeit. Ein anhaltender Rückgang über zwei Wochen ist es nicht.

Formulareingänge prüfen. Kommen tatsächlich Anfragen an? Und zwar im Vergleich zu vorher. Ein Formular kann technisch funktionieren und trotzdem weniger Anfragen bringen, weil es schwerer zu finden ist.

Kundenrückmeldungen sammeln. Die nützlichste Fehlerquelle überhaupt. Kunden benutzen die Website anders als der Erbauer.

Externe Dienste prüfen. Newsletter-System, Buchungssystem, Bewertungsanzeige, Terminvergabe. Alles, was auf die Website zugreift oder von ihr aus angesprochen wird. Diese Verbindungen brechen bei einem Umzug regelmäßig, und niemand merkt es, weil sie nicht auf der Startseite sichtbar sind.

(Eigene Checkliste website-relaunch)

Nach vier Wochen

Der Zeitpunkt für die ehrliche Bilanz. Vier Wochen sind gewählt, weil die Ladezeitdaten aus echten Besuchen etwa 28 Tage brauchen, bis sie aussagekräftig sind.

Positionen vergleichen: alt gegen neu. Hier zahlt sich die Bestandsaufnahme aus — ohne sie ist der Vergleich nicht möglich.

Indexierungsstand prüfen. Sind die neuen Seiten drin? Sind die alten draußen?

Die Ladezeitwerte aus echten Nutzerdaten in der Search Console anschauen.

Den Vorher-Nachher-Vergleich dokumentieren. Ladezeit, Positionen, Besucherzahlen, Anfragen. Das ist die Antwort auf die Frage „hat sich das gelohnt" — und die kommt sicher.

Die Weiterleitungen noch einmal komplett durchgehen. Erfahrungsgemäß fehlt bis dahin noch etwas.

Und das Projekt formell abschließen: Gespräch mit dem Kunden, offene Punkte klären, und die Frage nach der weiteren Betreuung stellen.

(Eigene Checkliste website-relaunch)

Was normal ist und was nicht

Weil die ersten Wochen unruhig sind, hier die Einordnung:

Normal:

• Rückgang der Besucherzahlen in den ersten ein bis zwei Wochen.
• Einzelne Seiten, die kurz aus dem Index verschwinden und wiederkommen.
• Fehlerseiten-Meldungen in der Search Console — das ist der Mechanismus, der funktioniert.
• Schwankende Positionen.

Nicht normal, und dann sofort nachsehen:

• Verkehr, der über zwei Wochen anhaltend deutlich unter dem alten Niveau bleibt.
• Die Startseite ist nicht indexiert.
• Formulareingänge bleiben komplett aus.
• Die Meldung „Durch noindex-Tag ausgeschlossen" bei wichtigen Seiten.
• Eine Meldung im Bereich Sicherheitsprobleme.

Und die Ursache ist in den meisten Fällen eine von dreien: der Testumgebungs-Blocker ist mitgekommen, die Weiterleitungen fehlen, oder der Mailversand funktioniert nicht.

Was zu tun ist

Vorher:

1. Zeitpunkt festlegen — Dienstag oder Mittwoch, nicht vor Feiertagen, nicht in der Hochsaison.
2. Rückweg vorbereiten und die Sicherung prüfen.
3. Zertifikat, DNS, Zwischenspeicher, Auslieferung klären.
4. Weiterleitungen einrichten und testen.

Am Tag selbst:

5. Testumgebungs-Blocker entfernen. Als Erstes.
6. Alles durchklicken, mobil und am Desktop.
7. Jedes Formular bis zum Maileingang testen.
8. Weiterleitungen stichprobenartig prüfen.
9. Sitemap einreichen, Indexierung anfordern.
10. Auswertung und Ladezeit prüfen.
11. Kunden Bescheid sagen.

Danach:

12. Zwei Wochen täglich die Search Console.
13. Fehlende Weiterleitungen nachreichen.
14. Externe Dienste prüfen.
15. Nach vier Wochen die Bilanz ziehen und dokumentieren.

Was ich Kunden dazu sage: Der Tag des Umschaltens ist nicht das Ende des Projekts, sondern der Anfang der wichtigsten vier Wochen. Wer danach nicht hinschaut, erfährt von Problemen erst durch einen Kunden, der anruft — oder gar nicht.

Quellen

• Eigene Checkliste website-relaunch — die Go-live-Absicherung mit der Festlegung des Zeitpunkts (nicht freitags, nicht vor Feiertagen), dem vorbereiteten Rückweg zur schnellen Wiederherstellung der alten Seite, den geplanten DNS-Änderungen bei Anbieterwechsel, dem bereitstehenden Zertifikat für die Live-Adresse sowie vorbereiteter Auslieferungs- und Zwischenspeicherkonfiguration; die Prüfliste direkt nach dem Umschalten mit dem Durchklicken aller Seiten am Desktop und mobil, dem Test der Formulare bis zum Maileingang, der stichprobenartigen Prüfung der Weiterleitungen, dem Einreichen der neuen Sitemap, dem Anfordern der Indexierung wichtiger Seiten, der Prüfung der Auswertung, der Verschlüsselung ohne gemischte Inhalte, dem Entfernen des Testumgebungs-Blockers aus der robots.txt und der Messung und Dokumentation der Ladezeit; die Punkte für die ersten zwei Wochen mit täglicher Kontrolle der Search Console, dem Vergleich der Besucherzahlen, dem Identifizieren von Fehlerseiten und Ergänzen der Weiterleitungen, dem Sammeln von Kundenrückmeldungen, der Prüfung der Formulareingänge und der Prüfung externer Dienste; und die Punkte nach vier Wochen mit Positionsvergleich, Indexierungsstand, Ladezeitwerten aus etwa 28 Tagen Felddaten, dokumentiertem Vorher-Nachher-Vergleich, erneuter Prüfung der Weiterleitungen, Projektabschluss mit dem Kunden und dem Gespräch über die weitere Betreuung.
• Eigene Checkliste projektablauf-relaunch — die Phasenaufteilung des Projekts und die Einordnung der Go-live-Phase.
• Rheinwerk, Website-Konzeption und Relaunch, Kap. 6.3 — die Unterscheidung zwischen einer Umstellung in einem Zug und einer schrittweisen Umstellung sowie deren jeweilige Voraussetzungen.
• Atlas, seo/technical-audit.md — das Audit der noindex-Anweisungen als regelmäßiger Prüfpunkt, besonders nach einem Relaunch.
• Eigene Prüfpraxis — die Empfehlung von Dienstag oder Mittwoch vormittags und die saisonale Rücksicht, das Herabsetzen der DNS-Gültigkeitsdauer einige Tage vor dem Wechsel, der Hinweis, Kunden über den Umbau zu informieren, die Einordnung, was in den ersten Wochen normal ist und was nicht, die drei häufigsten Ursachen bei auffälligen Befunden, und die Beobachtung, dass die Fehlerseiten-Meldungen der ersten Wochen die vollständigste Liste vergessener Weiterleitungen liefern.