Der Tag danach: Was beim Go-Live wirklich schiefgeht.

Der Go-Live hat eine eigene Dramaturgie. Der letzte Build läuft durch. Die Domain zeigt auf die neue Umgebung. Die Startseite lädt. Irgendwo sagt jemand: „Passt, wir sind online.“ Für einen kurzen Moment fühlt es sich an, als wäre das Projekt abgeschlossen.

Ein Go-Live ist kein Schlussstrich. Er ist der erste echte Betriebstag.

Die meisten Probleme entstehen nicht, weil vorher schlecht gearbeitet wurde. Sie entstehen, weil nach dem Launch niemand mehr auf dieselben Details schaut.

Die gefährlichste Annahme lautet: Jetzt läuft es von selbst.

Genau an diesem Punkt wechseln viele Projekte zu früh von Projektmodus auf Entspannung. Dabei beginnt jetzt die Phase, in der echte Nutzer, echte Geräte, echte Suchmaschinen und echte Prozesse auf die Website treffen.

Der Launch prüft nicht nur Code.

Er prüft Zuständigkeit, Inhalte, Tracking, DNS, E-Mail-Zustellung, Suchmaschinen-Signale und die Fähigkeit, kleine Fehler schnell einzuordnen.

Der Tag danach ist deshalb interessanter als der Launch selbst. Am Launch-Tag wird meist kontrolliert, ob die Website grundsätzlich erreichbar ist. Am Tag danach zeigt sich, ob sie im Betrieb verstanden wurde. Ob jemand Mails erhält. Ob alte URLs richtig weiterleiten. Ob Statistikdaten ankommen. Ob Platzhalter verschwunden sind. Ob die richtigen Personen wissen, was bei Problemen zu tun ist.

Viele kleine Unternehmen unterschätzen diese Phase nicht aus Nachlässigkeit. Sie unterschätzen sie, weil der Weg bis zum Go-Live mental bereits genug Kraft gekostet hat. Inhalte, Layout, technische Umsetzung, Freigaben, rechtliche Seiten, Kontaktwege, letzte Korrekturen – irgendwann will man fertig sein. Das ist menschlich. Nur technisch ist es riskant.

Die Ziellinie ist oft nur eine optische Linie

In Website-Projekten entsteht gegen Ende fast immer Tunnelblick. Alle sehen auf die sichtbaren Teile: Startseite, Navigation, Hero, Kontaktformular, Impressum, Datenschutz, mobile Ansicht. Das ist wichtig, aber nicht vollständig.

Was unter der Oberfläche liegt, wirkt weniger spektakulär und wird deshalb leichter verschoben: Redirects, Suchmaschinen-Signale, Alt-Texte, Tracking-Konfiguration, E-Mail-Authentifizierung, Admin-Rechte, Backup- und Rollback-Plan, Monitoring, interne Zuständigkeiten.

Das Problem: Diese Punkte werden nach dem Go-Live nicht automatisch leichter. Sie werden nur unsichtbarer. Wer sie nicht vor dem Launch greifbar macht, findet sie später oft erst dann wieder, wenn etwas nicht funktioniert.

Go-Live-Qualität ist operative Qualität.

Eine Website ist nicht fertig, wenn sie gut aussieht. Sie ist erst stabil, wenn Inhalte, Technik, Zuständigkeit und Messung zusammenpassen.

Der typische Denkfehler

1. Vor dem Launch wird alles Sichtbare priorisiert.
2. Operative Details wandern in die Liste für später.
3. Nach dem Launch fehlt der Projektfokus.
4. Kleine Lücken werden erst durch Nutzer, Suchmaschinen oder Supportfälle sichtbar.

Der Tag danach braucht einen Plan.

Nicht als schweres Prozesshandbuch. Aber als klare, kurze Betriebslogik: Wer prüft was, wann und mit welchem Eskalationsweg?

Blinder Fleck 1: Content, Redirects und SEO-Reste

Content-Fehler sind beim Launch besonders unangenehm, weil sie öffentlich wirken. Ein Lorem-Ipsum-Rest, ein veralteter CTA, ein falscher Ansprechpartner oder ein Platzhalterbild ist selten technisch kritisch. Trotzdem beschädigt es Vertrauen.

Noch folgenreicher sind alte URLs ohne saubere Weiterleitung. Wenn eine bestehende Website ersetzt wird, ändern sich oft Pfade. Aus alten Leistungsseiten werden neue Strukturen. Aus alten Blogartikeln werden Insights. Aus Kontaktseiten werden neue Kontaktwege. Ohne Redirects landen Nutzer und Suchmaschinen auf 404-Seiten.

Das ist nicht nur unschön. Es unterbricht Nachfrage. Jemand klickt aus Google, aus einem alten Angebot, aus einem Social-Media-Profil oder aus einer gespeicherten Kundenmail – und kommt nicht dort an, wo er hinwollte.

• Redirects: Alte relevante URLs brauchen eine Zuordnung auf neue Zielseiten. Nicht jede alte Seite braucht ein eigenes Denkmal, aber wichtige Einstiege müssen abgefangen werden.
• Indexierbarkeit: Robots-Regeln, Canonicals, Sitemap und Seitentitel sollten nicht erst Wochen später geprüft werden.
• Alt-Texte: Bilder brauchen sinnvolle Beschreibungen. Nicht für Keyword-Stuffing, sondern für Barrierefreiheit, Kontext und saubere Bildsignale.
• Platzhalter: Mustertexte, Dummy-Badges, temporäre Hinweise und alte Debug-Ausgaben gehören vor dem Launch bewusst gesucht.

Blinder Fleck 2: Der Hypercare-Irrtum

Viele Projekte planen den Launchtermin. Weniger Projekte planen die ersten 72 Stunden danach. Genau dort passiert aber die meiste echte Einordnung: Rückmeldungen, kleine Layoutfehler, Formularmeldungen, unerwartete Browserunterschiede, Weiterleitungsfragen, erste Suchmaschinenbeobachtungen.

Hypercare bedeutet nicht, dass ein Team tagelang nervös vor Dashboards sitzen muss. Es bedeutet, dass klar ist, wer erreichbar ist, welche Fehler kritisch sind, was sofort behoben wird und was in einen normalen Verbesserungsprozess wandert.

Ohne diese Klärung entsteht ein vertrautes Muster: Alle glauben, jemand anderer schaut drauf. Entwickler schließen das Projekt mental ab. Inhalte werden nicht mehr konsequent geprüft. Der Kunde meldet etwas per Chat. Irgendwo ist ein Screenshot. Niemand weiß, ob es schon ein Issue gibt.

Blinder Fleck 3: Das vergessene Admin-Team

Bei kleinen Unternehmen gibt es oft kein klassisches Admin-Team. Es gibt eine Person, die „sich auskennt“. Oder eine externe Betreuung. Oder jemanden, der Zugriff hat, aber nicht genau weiß, was nach dem Launch regelmäßig zu prüfen ist.

Das ist nicht schlimm. Schlimm wird es erst, wenn Zugriff mit Verantwortung verwechselt wird. Admin-Rechte bedeuten noch nicht, dass Betrieb verstanden wurde.

Nach einem Go-Live sollte klar sein: Wer kann Inhalte ändern? Wer darf technische Einstellungen ändern? Wo liegen Zugangsdaten? Was gehört in Bitwarden oder ein anderes Passwortmanagement? Wer prüft Kontaktanfragen? Wer bekommt Systemmails? Wer hat Zugriff auf Analytics, Search Console, Hosting, DNS und Deployment?

• Zugänge: Admin-, Hosting-, DNS-, Mail-, Analytics- und Deployment-Zugänge müssen dokumentiert und sicher abgelegt sein.
• Rollen: Nicht jede Person braucht Vollzugriff. Weniger Rechte sind oft bessere Betriebsqualität.
• Routinen: Ein kurzer Monatscheck ist wertvoller als ein perfektes Betriebshandbuch, das niemand liest.
• Übergabe: Der Go-Live braucht eine Betriebsübergabe. Auch dann, wenn das Projekt klein ist.

Blinder Fleck 4: Analytics und Tracking-Blindheit

Statistikdaten werden häufig erst dann vermisst, wenn man sie schon gebraucht hätte. Welche Seiten wurden aufgerufen? Welche Kontakt-Buttons funktionieren? Kommen Formularanfragen an? Lesen Menschen die Insights oder springen sie sofort ab?

Der Go-Live ist ein schlechter Zeitpunkt für Messblindheit. Gleichzeitig ist Tracking kein Freibrief. Gerade in Europa müssen Datenschutz, Consent, Zweck, technische Umsetzung und Dokumentation zusammenpassen.

Typische Fehler sind banal: Der Tracking-Code ist in der Live-Umgebung nicht aktiv. Der Cookie-Banner blockiert alles, auch nach Zustimmung. Events heißen anders als im Dashboard. Interne Aufrufe verfälschen die ersten Daten. Oder die Website misst Seitenaufrufe, aber keine relevanten Handlungen.

• Vor dem Launch: Messkonzept klären: Was zählt wirklich? Seitenaufrufe, CTA-Klicks, Kontaktmodal, Formularerfolg, qualifiziertes Lesen?
• Beim Launch: Live prüfen, ob Events tatsächlich ankommen und Consent-Zustände korrekt wirken.
• Nach dem Launch: Die ersten Tage nicht überinterpretieren, aber technische Ausfälle sofort erkennen.

Blinder Fleck 5: Formulare, Mail-Zustellung und DNS

Der unangenehmste Go-Live-Fehler ist oft nicht sichtbar. Die Website sieht gut aus. Das Formular meldet Erfolg. Der Nutzer glaubt, die Anfrage wurde gesendet. Nur im Postfach kommt nichts an – oder die automatische Antwort landet im Spam.

Das ist kein exotisches Problem. Kontaktformulare, transaktionale Mails und automatische Benachrichtigungen hängen an mehr als nur Code. Mailserver, Absenderdomain, SPF, DKIM, DMARC, Weiterleitungen, Spamfilter und Empfängerregeln spielen zusammen.

Ein grünes Formular ist noch kein zugestelltes Mail.

Der Test muss dort enden, wo der Geschäftsprozess endet: im richtigen Postfach, mit korrektem Absender, ohne Spam-Umweg und mit nachvollziehbarem Fehlerfall.

Für kleine Unternehmen ist das besonders relevant. Die Website ist oft der zentrale Kontaktpunkt. Wenn Anfragen verloren gehen, wirkt das nicht wie ein technischer Fehler. Es wirkt, als würde niemand reagieren.

Eine kurze Geschichte aus der Praxis

Ein kleiner Shop geht live. Die Produktseiten sind sauber, der Checkout funktioniert, das Design ist deutlich besser als vorher. Im Test sieht alles gut aus. Erst nach einigen Tagen fällt auf: Kunden erhalten Rechnungs- und Bestellmails verzögert oder gar nicht im Posteingang.

Technisch war der Shop nicht kaputt. Der Bestellprozess lief. Aber die Domain- und Mailkonfiguration war nicht vollständig auf den neuen Versandweg abgestimmt. Aus Sicht des Kunden war das Ergebnis trotzdem einfach: Unsicherheit. Habe ich bestellt? Kommt die Rechnung? Ist das seriös?

Genau das ist der Punkt. Go-Live-Qualität entsteht nicht nur im Frontend. Sie entsteht dort, wo Website, DNS, Mail, Tracking, Support und interne Abläufe zusammenkommen.

Die Checkliste für den Tag danach

Eine gute Go-Live-Checkliste muss nicht lang sein. Sie muss nur die richtigen Fragen stellen und einen Owner haben.

• Erreichbarkeit: Startseite, Kernseiten, Kontaktseite, Impressum, Datenschutz, Sitemap und robots.txt prüfen.
• Redirects: Wichtige alte URLs, Kampagnenlinks, Social-Profile und häufig genutzte Einstiege testen.
• Formulare: Testanfrage senden, Zustellung prüfen, Absender prüfen, Spam prüfen, Fehlerfall prüfen.
• Analytics: Live-Events kontrollieren: Seitenaufruf, CTA-Klicks, Kontaktmodal, Formularerfolg, Artikelinteraktion.
• SEO-Basis: Seitentitel, Meta-Beschreibungen, Canonicals, Alt-Texte, Indexierbarkeit und Sitemap prüfen.
• Hypercare: Für mindestens 72 Stunden Owner, Eskalationsweg und Prioritäten festlegen.
• Admin-Betrieb: Zugänge, Rollen, Passwortablage, Update- und Wartungsroutine dokumentieren.
• Monitoring: Fehlerseiten, Build-/Deployment-Status, Server-/Hosting-Meldungen und Mailzustellung beobachten.

Warum Woche drei wichtiger ist als der Launchmoment

Ein Launch kann sauber wirken und trotzdem operativ schwach sein. Umgekehrt kann ein Launch mit kleinen sichtbaren Korrekturen sehr professionell sein, wenn die Betriebsphase gut geführt wird.

Die Qualität eines Go-Live misst sich deshalb nicht an der Minute, in der die Website online geht. Sie misst sich daran, ob sie in Woche drei noch stabil läuft, ob Anfragen zuverlässig ankommen, ob Suchmaschinen sauber geführt werden, ob Statistikdaten verwertbar sind und ob das Unternehmen weiß, wie es mit Änderungen umgeht.

Go-Live ist kein Feuerwerk, sondern ein Übergang in den Betrieb. Die Website soll sichtbar machen, Vertrauen schaffen und langfristig wartbar bleiben. Genau deshalb gehört der Tag danach nicht ans Ende der Aufmerksamkeit, sondern in die Planung.

Wer eine Website vorbereitet, sollte also nicht nur fragen: Wann gehen wir live? Die bessere Frage lautet: Was muss am Tag danach bereits klar sein, damit aus dem Launch kein loses Ende wird?