Relaunch und Umzug überwachen: DNS, SSL, Redirects

Warum gehen Relaunch und Umzug so oft schief?

Bei einem Relaunch ändert sich vieles gleichzeitig: Server, Software, URL-Struktur, Zertifikate, Weiterleitungen und häufig der DNS-Eintrag. Jede dieser Änderungen kann für sich funktionieren und im Zusammenspiel scheitern. Die Fehler sind selten spektakulär, aber teuer: Die Website läuft, aber für Suchmaschinen steht noch noindex im Code, ein Teil der alten URLs führt ins Leere, das Zertifikat deckt www nicht ab, oder E-Mails an die Domain gehen verloren, weil der MX-Eintrag nicht mit umgezogen ist.

Ziel dieses Artikels ist ein Ablauf mit konkreten Prüfungen vor, während und nach dem Umzug. Er unterscheidet sich von einer reinen Verfügbarkeitsüberwachung: Der Zeitraum rund um die Umstellung ist ein Ausnahmezustand, in dem Sie bewusst mehr, genauer und zusätzlich manuell prüfen. Zur Einordnung der Prüfarten siehe Monitortypen.

Was ist vor dem Umzug zu tun?

Eine Woche vorher

• TTL senken. Prüfen Sie die aktuelle TTL: dig +noall +answer example.com A zeigt in der zweiten Spalte die verbleibende TTL in Sekunden beim befragten Resolver, dig @ns1.ihr-dns-anbieter.de example.com A die tatsächlich eingestellte. Senken Sie sie auf 300 Sekunden, und zwar mindestens so lange vor dem Umzug, wie die alte TTL dauerte. Bei einer alten TTL von 86.400 Sekunden (24 Stunden) also mehr als einen Tag vorher.
• Ausgangslage dokumentieren. Führen Sie den Sofort-Report aus und speichern Sie Antwortzeit, Header, Weiterleitungen und DNS-Einträge als Referenz. Legen Sie Monitore an: HTTP für Startseite und zwei bis drei wichtige Unterseiten, SSL und DNS.
• Alle DNS-Einträge inventarisieren. Exportieren Sie die Zone vollständig: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, Verifizierungen), CAA, SRV. Wer das nicht tut, vergisst Einträge, die niemand mehr im Kopf hat.
• Weiterleitungsliste erstellen. Eine Tabelle alter URL → neue URL, aus Sitemap, Server-Logs und Analyse.

Am Vortag

• Neuen Server testen, ohne DNS zu ändern: curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/ ruft die Domain gezielt auf der neuen IP-Adresse ab, mit korrektem Zertifikat und Hostnamen. Alternativ tragen Sie die neue IP lokal in die hosts-Datei ein.
• Zertifikat auf dem neuen Server ausstellen oder importieren und mit openssl s_client -connect 203.0.113.10:443 -servername www.example.com prüfen, ob Kette, Hostname und Ablaufdatum stimmen. Bei Let's Encrypt prüfen Sie, dass die Validierung (HTTP-01 oder DNS-01) auf dem neuen Server überhaupt funktionieren wird.
• Datenbank und Dateien abgleichen; letzter Sync unmittelbar vor der Umstellung, damit zwischenzeitlich geschriebene Daten (Bestellungen, Kommentare) nicht fehlen.

Wie läuft der Umzugstag ab?

Ein Wartungsfenster unterdrückt Alarme und nimmt die Zeit aus der Verfügbarkeitsberechnung. Das schützt vor Fehlalarmen, bedeutet aber auch: Echte Probleme innerhalb des Fensters werden nicht gemeldet. Halten Sie das Fenster deshalb kurz und prüfen Sie aktiv. Hintergrund: Wartungsfenster planen.

Der DNS-Monitor fragt aus Sicht des Messstandorts. Hat er die neue Adresse gesehen, heißt das nicht, dass alle Nutzer sie sehen. Andere Resolver halten den alten Wert, bis die alte TTL abläuft, höchstens also so lange, wie sie vorher dauerte. Deshalb laufen alter und neuer Server nach dem Umzug noch eine Weile parallel; schalten Sie den alten nicht sofort ab. Einzelheiten zu Auflösung und Fehlerbildern: DNS-Fehler erkennen und beheben.

Wie prüft man Weiterleitungen und Redirect-Ketten?

Bei jedem Relaunch gibt es mindestens drei Weiterleitungsebenen: Protokoll (http → https), Hostname (example.com → www.example.com oder umgekehrt) und Pfade (alte → neue URLs). Werden sie hintereinander geschaltet, entstehen Ketten:

http://example.com/alt/  →  301  https://example.com/alt/
                         →  301  https://www.example.com/alt/
                         →  301  https://www.example.com/neu/

Drei Stationen für einen Aufruf, jede kostet eine Round-Trip-Zeit, und Suchmaschinen folgen nur einer begrenzten Zahl von Weiterleitungen. Besser ist eine direkte Weiterleitung auf das Ziel. In nginx sieht eine saubere Lösung für die Hostname-Variante so aus:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate … (Zertifikat muss auch example.com abdecken)
    return 301 https://www.example.com$request_uri;
}

Prüfen Sie Ketten mit curl -sIL -o /dev/null -w "%{url_effective} %{num_redirects} %{http_code}\n" http://example.com/alt/: Die Ausgabe nennt die Ziel-URL, die Zahl der Weiterleitungen und den Endstatus. Ein HTTP-Monitor mit eingeschaltetem Folgen von Weiterleitungen bewertet den Code am Ende der Kette; mehr als fünf Stationen oder eine Schleife zählen als Fehler. Warum und wie man Ketten vermeidet, erklärt Weiterleitungen und Redirect-Ketten. Für die Suchmaschinen-Sicht ist die Dokumentation zu Website-Umzügen in der Google Search Central die maßgebliche Quelle.

Wie erkennt man vergessene Staging-Reste?

Ein häufiges Szenario: Die Website wurde auf einer Staging-Domain entwickelt, mit noindex-Meta-Tag oder Disallow: / in der robots.txt. Beim Umzug werden beide Elemente mitkopiert. Die Website ist erreichbar, der HTTP-Monitor ist grün, und Suchmaschinen schließen die Seite still aus, mitunter wochenlang unbemerkt.

• Keyword-Monitor „darf nicht enthalten sein“ auf die Startseite mit dem Suchbegriff noindex: Der Meta-Tag steht im <head>, also innerhalb der ersten 256 KB, die gelesen werden. Achtung: Dasselbe Wort kann in legitimen Texten vorkommen; wählen Sie bei Bedarf die genaue Form content="noindex.
• Keyword-Monitor auf /robots.txt mit Suchbegriff Disallow: / als „darf nicht enthalten sein“: Bedenken Sie, dass Disallow: /admin/ den Begriff ebenfalls enthält; hier passt ein genauerer Text wie eine Zeilenfolge, die nur bei Komplettsperre vorkommt. Manueller Check ist hier oft einfacher.
• Staging-Text wie „Testumgebung“ oder der Staging-Hostname: auch als „darf nicht enthalten sein“.
• HTTP-Header: X-Robots-Tag: noindex lässt sich per curl -sI https://www.example.com/ | grep -i robots prüfen. Ein Monitor liest den Body, nicht beliebige Antwort-Header, deshalb gehört dieser Check in Ihre manuelle Liste.

Der Sofort-Report prüft zusätzlich robots.txt, Sitemap und llms.txt und listet Auffälligkeiten als Maßnahmen. Nutzen Sie ihn unmittelbar nach der Umstellung und eine Woche später erneut.

Was ist mit E-Mail und Zusatzdiensten?

Die Website ist nur ein Teil der Domain. Beim DNS-Wechsel an einen neuen Anbieter oder Server müssen auch diese Einträge stimmen:

• MX: Mailserver der Domain. Fehlt er, gehen eingehende E-Mails verloren, ohne dass eine Fehlerseite erscheint.
• SPF, DKIM, DMARC (TXT): Absender-Authentifizierung. Fehlen sie, landen Ihre Mails eher im Spam oder werden abgelehnt, siehe SPF, DKIM und DMARC erklärt.
• CAA: Wenn gesetzt, muss sie die Zertifizierungsstelle des neuen Zertifikats erlauben, sonst scheitert die Ausstellung.
• Subdomains: Shop, Mail, Support, Statusseite; jede kann einen eigenen Eintrag haben.

Legen Sie DNS-Monitore für die kritischen Typen an, am wichtigsten sind A und MX, mit dem erwarteten Wert. Der DNS-Monitor von UPTIMESHIELD unterstützt A, AAAA, CNAME, MX, NS und TXT. Für DKIM und DMARC nutzen Sie einen TXT-Monitor mit dem erwarteten Text oder den Sofort-Report, der DNS inklusive SPF, DMARC, CAA und DNSSEC einmalig auswertet.

Was ist nach dem Umzug zu beobachten?

Die kritische Phase endet nicht mit dem letzten grünen Haken. Planen Sie zwei bis drei Tage Nachbeobachtung ein:

• Antwortzeit: Vergleichen Sie Median und p95 mit den Werten vor dem Umzug. Ein dauerhaft höherer p95 deutet auf zu schwache Hardware, fehlenden Cache oder noch nicht aufgewärmte Caches hin. Einordnung: Antwortzeit interpretieren.
• Fehlerquote: Sporadische Fehler nach der Umstellung können vom alten Server kommen, der noch von einem Teil der Nutzer erreicht wird.
• TTL wieder erhöhen, sobald alles stabil ist (zum Beispiel auf 3.600 Sekunden), um DNS-Last zu sparen.
• Zertifikats-Erneuerung testen: Der erste automatische Erneuerungslauf auf dem neuen Server ist ein typischer Stolperstein. Der SSL-Monitor warnt 30, 14, 7, 3 und 1 Tag vor Ablauf.
• Cronjobs und Backups: Beim Umzug werden Crontabs oft vergessen. Legen Sie Heartbeat-Monitore an, siehe Cronjobs mit Heartbeat überwachen.
• Alten Server erst nach einigen Tagen und mit Datensicherung abschalten.

Welche Fehler treten beim Relaunch besonders häufig auf?

• TTL zu spät gesenkt. Die Umstellung dauert Stunden statt Minuten. Gegenmaßnahme: Sie vor dem Umzug mindestens um die alte TTL-Dauer senken.
• Zertifikat deckt nicht alle Namen ab. Fehler wie „Hostname stimmt nicht überein“ tauchen nur bei www oder nur ohne www auf. Gegenmaßnahme: Beide Varianten mit SSL-Monitor oder openssl prüfen.
• Redirect-Ketten und Schleifen. Entstehen, wenn Server- und Anwendungsregeln gegeneinander arbeiten (zum Beispiel erzwingt das CMS www, der Server entfernt es). Gegenmaßnahme: Regeln an genau einer Stelle pflegen.
• noindex/Disallow aus dem Staging. Gegenmaßnahme: Keyword-Monitore „darf nicht enthalten sein“, manueller Header-Check.
• Mixed Content und harte alte URLs. Bilder oder Skripte werden noch von der alten Domain geladen; das fällt in HTTP-Monitoren nicht auf. Gegenmaßnahme: Browser-Konsole prüfen, Datenbank-Suchen-Ersetzen.
• E-Mail-Einträge vergessen. Gegenmaßnahme: Zone vorher exportieren und nachher vergleichen.
• Wartungsfenster zu lang. Echte Fehler bleiben ungemeldet. Gegenmaßnahme: knapp planen, aktiv prüfen.

Checkliste für Relaunch und Umzug

1. TTL aller betroffenen Einträge auf 300 s senken, rechtzeitig.
2. DNS-Zone exportieren; Weiterleitungsliste erstellen.
3. Neuen Server mit curl --resolve testen.
4. Zertifikat inklusive www prüfen.
5. Monitore anlegen: HTTP, Keyword, SSL, DNS, Heartbeat.
6. Wartungsfenster setzen, DNS umstellen, Monitore beobachten.
7. Weiterleitungen, noindex, robots.txt, Sitemap prüfen.
8. E-Mail-Funktion testen (Senden und Empfangen).
9. Nachbeobachtung 2 bis 3 Tage, dann TTL erhöhen, alten Server abschalten.

Grenzen und Einordnung

Die Monitore sehen die Website aus Sicht des Messstandorts und seines Resolvers. Ohne zusätzlich eingerichtete Standorte (Pro bis 3, Max bis 6) kann ein Problem, das nur eine Region oder einen Resolver betrifft, unentdeckt bleiben. UPTIMESHIELD prüft nicht, ob Weiterleitungen inhaltlich passen, ob Rankings erhalten bleiben oder ob die Inhalte vollständig migriert wurden. Ein Keyword-Monitor sieht das ausgelieferte HTML, nicht das Rendering im Browser. Rankingverluste nach Relaunches haben viele Ursachen, die kein Monitoring abdeckt; hier helfen Search-Console-Daten und eine inhaltliche Prüfung. Auch die Beurteilung, ob Daten (zum Beispiel personenbezogene) rechtmäßig umgezogen wurden, gehört in die Hand von Fachleuten.

Wie setzt man das mit UPTIMESHIELD um?

Legen Sie nach der Registrierung die Monitore der Checkliste an, setzen Sie ein Wartungsfenster (im Konto verfügbar) für einen oder alle Monitore und richten Sie einen Alarmkanal ein. Der Sofort-Report liefert Vorher-Nachher-Werte; die wiederkehrenden Website-Checks im Dashboard zeigen den Notenverlauf und markieren, was neu auftrat und was behoben wurde, hilfreich in den Tagen nach dem Umzug. Die Verfügbarkeit des Umzugsfensters wird nicht gewertet, die Daten im Prüfprotokoll bleiben nachvollziehbar. Die Prüfintervalle und Standorte hängen vom Tarif ab, siehe Preise und Messmethodik.