Warum Relaunches an der Infrastruktur scheitern
Ein Relaunch scheitert selten am Code — meistens an der Betriebsplanung. Das Muster ist seit Jahren gleich: Das Design ist freigegeben, das Template sitzt, die Inhalte sind eingepflegt. Und kurz vor dem Go-Live tauchen die Fragen auf, die eigentlich am Anfang hätten stehen müssen. Wie lange laufen die DNS-Änderungen wirklich aus? Was passiert mit offenen Sessions? Wer zieht das letzte Datenbank-Backup, und wo liegt der Rollback-Stand?
Genau dort entstehen die Nachtschichten. Nicht, weil das Projekt technisch unlösbar wäre. Sondern weil Hosting, Deployment und Umschaltplan zu spät gedacht wurden. Wer einen Relaunch sauber vorbereitet, plant nicht nur Seiten und URLs, sondern auch Infrastruktur, Zustände und Rückwege. Das klingt trocken. Spart aber am Ende bares Geld.
Der praktische Fehler liegt fast immer im falschen Fokus. Das sichtbare Ergebnis bekommt Aufmerksamkeit, die unsichtbare Betriebsseite nicht. Dabei ist gerade sie entscheidend, wenn der neue Auftritt ohne Downtime, ohne Suchmaschinenchaos und ohne hektisches Zurückrollen live gehen soll.
Der erste Schritt ist nicht das Deployment, sondern der Zeitplan
Ein Relaunch braucht einen echten Ablaufplan. Nicht als hübsches Dokument für den Kunden, sondern als Arbeitsgrundlage für alle Beteiligten. In der Praxis gehören dort mindestens diese Punkte hinein:
• Wann werden DNS-Werte gesenkt, damit die spätere Umschaltung schneller greift?
• Welche TTLs sind auf A-, AAAA-, CNAME- und MX-Einträgen tatsächlich gesetzt?
• Wann wird die Staging-Instanz eingefroren, damit kein Content mehr auseinanderläuft?
• Wer prüft die finale Datenbank, und wer entscheidet über den Go/No-Go-Punkt?
• Welcher Rollback ist in 10 Minuten möglich, welcher erst in 60?
Gerade die TTLs werden gern unterschätzt. Wer sie am Vortag noch auf 24 Stunden stehen lässt, darf sich nicht wundern, wenn die Umschaltung im Netz verteilt weiterlebt. Das ist kein Theorieproblem, sondern ein klassischer Agenturfehler. Der neue Server ist bereit, der alte bleibt trotzdem noch Stunden sichtbar.
In Technisches SEO: Crawling, Indexierung, Canonicals, Sitemaps und Core Web Vitals richtig steuern wird die Suchmaschinen-Seite dieses Themas ausführlicher betrachtet. Hier geht es um die Betriebsseite davor: Erst wenn Infrastruktur und Umschaltlogik stimmen, lohnt sich der Rest überhaupt.
DNS ist kein Detail, sondern der erste Engpass
Beim Relaunch wird DNS oft wie ein Verwaltungsproblem behandelt. In Wahrheit ist es ein Ablauf mit Nebenwirkungen. Änderungen verbreiten sich nicht gleichzeitig, Cache-Layer im Netz verhalten sich unterschiedlich, und manche Resolver hängen länger an alten Einträgen als einem lieb ist. Deshalb reicht es nicht, „um 18 Uhr live“ zu planen. Es braucht die Frage, was um 18:05, 19:30 und am nächsten Morgen noch aufgelöst wird.
Sinnvoll ist in der Praxis:
• TTLs mehrere Tage vor dem Wechsel senken
• Zonenänderungen dokumentieren, nicht nur „irgendwo“ im Panel klicken
• DNS-Propagation vorab testen, auch von externen Netzen
• Mail, API, CDN und Hauptdomain getrennt betrachten
Vor allem Mail wird gern vergessen. Ein sauberer Web-Relaunch kann trotzdem scheitern, wenn MX-Einträge, SPF, DKIM oder Webhooks mitziehen und plötzlich ins Leere laufen. Dann sind es nicht die Besucher, sondern die internen Prozesse, die still stehen.
Deployment ohne Rollback ist nur ein Hoffnungsschimmer
Ein sauberes Deployment braucht einen Rückweg. Das klingt banal, wird aber erstaunlich oft ignoriert. Viele Projekte haben einen präzisen Go-Live-Plan, aber keinen belastbaren Plan für den Fall, dass eine Datenmigration, ein Cache-Fehler oder ein vergessener Cronjob das neue System ausbremst.
Meine Einschätzung nach fast 30 Jahren Webentwicklung: Ein Rollback ist keine Schwäche, sondern ein Zeichen von Reife. Wer ihn nicht vorbereitet, baut nicht robuster, sondern nur riskanter. Die schlechtesten Relaunches, die ich erlebt habe, waren nicht die mit großen Bugs. Es waren die, bei denen niemand sicher wusste, wie man ohne weitere Schäden zurückkommt.
Praktisch heißt das:
• alte Version und alte Datenbank mindestens bis zum ersten stabilen Betriebsfenster vorhalten
• Migrationsskripte idempotent bauen, wenn irgend möglich
• Konfigurationsstände versionieren
• Zugangsdaten, Secrets und Umgebungsvariablen getrennt dokumentieren
• vor dem Go-Live einen echten Rücksprung testen, nicht nur besprechen
Gerade bei Shops, Portalen oder Mitgliederbereichen ist das wichtig. Ein neues Frontend kann gut aussehen und trotzdem an der Session-Verwaltung, am Login oder an einer veränderten Cache-Regel scheitern. Dann nützt das schönste Design wenig.
Cache-Warming, CDN und Performance: nicht erst nach dem Schalter umlegen
Wenn große Relaunches ins Stocken geraten, liegt das selten an einem einzelnen langsamen Server. Häufig sind es die ersten Minuten nach dem Livegang. Niemand hat die wichtigsten Seiten vorgeladen, das CDN kennt die neuen Assets nicht, und die Datenbank muss aus dem kalten Zustand dutzende Anfragen gleichzeitig bedienen.
Cache-Warming ist deshalb kein Luxus. Es ist schlicht vernünftige Betriebsplanung. Startseiten, Kategorie-Landingpages, Top-Produktseiten, Login-Flows und die wichtigsten Suchergebnisse sollten vor dem Go-Live einmal durchlaufen werden. Dazu kommen Assets, Fonts, kritische CSS-Dateien und API-Endpunkte, die direkt nach der Umschaltung gebraucht werden.
Wer hier spart, bezahlt später mit Ladezeiten und Support-Tickets. Im schlimmsten Fall passiert genau das, was jeder vermeiden will: Das neue System ist technisch online, fühlt sich aber an wie ein halbfertiger Testserver.
Suchmaschinenprobleme entstehen oft durch schlechte Übergaben
In Relaunch-Projekten wird SEO gern als eine Liste von Weiterleitungen verstanden. Das ist zu kurz gegriffen. Redirects sind wichtig, aber sie lösen nur einen Teil des Problems. Entscheidend ist die saubere Übergabe des gesamten Systems: Statuscodes, Canonicals, interne Verlinkung, Sitemaps, Robots-Steuerung, Indexierungsfreigaben und Monitoring nach dem Livegang.
Wer das Thema sauber aufziehen will, findet in Content-SEO ohne Keyword-Stuffing: Warum Themencluster und interne Verlinkung heute zählen die inhaltliche Ergänzung. Ein Relaunch ohne funktionierende interne Verlinkung verliert schnell Sichtbarkeit, selbst wenn die Seite technisch erreichbar bleibt.
Wichtig ist dabei die Reihenfolge. Erst Infrastruktur stabilisieren, dann Crawling zulassen, dann Sitemaps aktualisieren, dann die Suchmaschinen kontrolliert neu laufen lassen. Alles andere produziert unnötige Nebengeräusche.
Der Go-Live braucht ein kleines, reales Betriebsteam
Große Übergaben scheitern oft an der Annahme, eine Person könne alles gleichzeitig prüfen. Das klappt in der Theorie, in der Praxis selten. Besser ist ein kleines Team mit klarer Rollenverteilung:
• eine Person für DNS und Hosting
• eine Person für Deployments und Logs
• eine Person für SEO/Redirects
• eine Person für fachliche Freigaben und Content-Checks
Mehr ist oft nicht nötig. Aber weniger wird schnell chaotisch. Besonders bei Agenturprojekten lohnt sich das Vier-Augen-Prinzip an den richtigen Stellen. Nicht jeder Klick muss abgesegnet werden, aber die kritischen Schalter schon.
Ein weiterer Punkt aus der Praxis: Monitoring nicht erst nach dem Start hochziehen. Fehlerseiten, Ladezeiten, Datenbanklast, Zertifikate und Cronjobs müssen während der ersten Stunden eng beobachtet werden. Wer das Monitoring erst am Folgetag anschaut, sammelt meist nur noch die Trümmer auf.
Weiterführend in dieser Serie
Für die SEO- und Migrationsseite dieses Themas passen besonders diese Beiträge:
SEO-Grundlagen 2026: Technik, Content, Autorität für Nischenportale und Agenturseiten
Technisches SEO: Crawling, Indexierung, Canonicals, Sitemaps und Core Web Vitals richtig steuern
Content-SEO ohne Keyword-Stuffing: Warum Themencluster und interne Verlinkung heute zählen
Fazit
Ein Relaunch braucht mehr als ein neues Design und einen sauberen Code-Stand. Ohne vorbereitete DNS-Änderungen, getesteten Rollback, gewärmte Caches und klare Zuständigkeiten wird aus einem geplanten Livegang schnell ein improvisierter Nachtbetrieb. Wer Hosting und Infrastruktur früh mitdenkt, macht den eigentlichen Unterschied: weniger Downtime, weniger Suchmaschinenstress, weniger Panik. Genau das sollte ein Relaunch leisten.
bye
mo