Website-Checkliste zum Launch: was Sie vor dem Go-live und in den ersten 90 Tagen prüfen

Eine Website-Checkliste für den Launch ist die geordnete Liste aller Prüfungen, die ein Team vor, während und nach dem Go-live einer neuen Website abarbeitet: Inhalte korrekturlesen, Formulare testen, Tracking und Cookie-Einwilligung, SEO und Weiterleitungen, Ladezeit, Barrierefreiheit, Sicherheit und Rechtstexte, die DNS-Umstellung selbst und die ersten Wochen Monitoring. Es gibt sie, weil sich die meisten Launch-Probleme auf der Staging-Umgebung günstig finden lassen und teuer werden, sobald Google die falsche Version gecrawlt hat.

Diese Checkliste richtet sich an Teams, die eine neue oder neu gebaute Unternehmenswebsite online stellen, intern oder mit einer Agentur, und an alle, die eine Website veröffentlichen wollen, ohne den Traffic der alten Seite zu verlieren. Sie folgt den drei Phasen, in denen tatsächlich gearbeitet wird: vor dem Launch, am Go-live-Tag und in den ersten 90 Tagen danach. Zu jedem Punkt steht, was Sie prüfen und, wo es darauf ankommt, mit welchem Tool Sie sehen, ob er erfüllt ist.

Ersetzt die neue Website eine alte, lesen Sie den Abschnitt zu Weiterleitungen zweimal. Dieser Schritt entscheidet, ob der Suchtraffic der alten Seite mitkommt. Für einen kompletten Relaunch mit neuer Struktur und neuen Zielen ergänzt unsere Website-Relaunch-Checkliste die Planung davor.

Eine brauchbare Go-live-Checkliste deckt drei Phasen ab. Die Prüfungen vor dem Launch laufen auf Staging und entscheiden, ob die Seite fertig ist. Am Launch-Tag geht es um die Umstellung selbst: DNS, Caches und Signale für die Indexierung. Die Prüfungen danach laufen rund 90 Tage und bestätigen, dass das, was auf Staging funktioniert hat, auch mit echtem Traffic, echten Browsern und echten Crawlern funktioniert. Viele veröffentlichte Checklisten hören beim Klick auf "Veröffentlichen" auf, deshalb bekommt die dritte Phase hier einen eigenen Teil.

Die Tabelle unten ist die Kurzfassung und funktioniert als Vorlage, die Sie in Ihr Projekttool kopieren können. Geben Sie jeder Zeile eine verantwortliche Person mit Namen. Ein Punkt, der "dem Team" gehört, gehört meist niemandem, und genau dieser Punkt ist am Launch-Morgen noch offen.

Inhaltliche Prüfungen sind der am wenigsten technische Teil einer Checkliste für die neue Website und der Teil, den Besucher zuerst bemerken. Lesen Sie jede Seite auf Staging, nicht im CMS-Editor, denn Templates verändern Zeilenumbrüche und Bildausschnitte. Gleichen Sie Preise, Telefonnummern, Adressen, Öffnungszeiten und Firmenangaben mit der Quelle ab und ersetzen Sie jeden Platzhalter, jeden Lorem-ipsum-Absatz und jedes Testbild. Defekte interne Links und Buttons ohne Ziel gehören in denselben Durchgang.

Inhalte und Korrektur

• Jede Seite hat einen eigenen Title-Tag, eine eigene Meta-Description und genau eine H1
• Bilder haben Alt-Texte, die sie beschreiben, und sind komprimiert (WebP oder AVIF)
• Copyright-Jahr, Social-Media-Links und der Logo-Link zur Startseite funktionieren
• Open-Graph-Bild und -Titel sehen richtig aus, wenn ein Link in Slack, LinkedIn oder WhatsApp geteilt wird
• Eine eigene 404-Fehlerseite führt Besucher zurück zu den Hauptbereichen

Formulare und E-Mail-Zustellung

Ein Formular, das sich absenden lässt, ist erst zur Hälfte getestet. Die andere Hälfte ist die Frage, ob die Benachrichtigung bei der Person ankommt, die antworten muss. Senden Sie jedes Formular mit realistischen Daten ab und prüfen Sie dann den Posteingang, den Spam-Ordner und das CRM oder die Tabelle, in der die Anfrage landen soll.

Verschicken Sie Formular-Benachrichtigungen über eine authentifizierte Domain oder einen Dienst für Transaktionsmails, nicht über die Standard-Mailfunktion des Webservers. Seit Februar 2024 verlangen die E-Mail-Absenderrichtlinien von Gmail von jedem Absender SPF oder DKIM und von Absendern mit mehr als 5.000 Nachrichten pro Tag beides plus einen veröffentlichten DMARC-Eintrag. Ein Kontaktformular erreicht dieses Volumen nie, aber nicht authentifizierte Mails von einer frischen Domain landen deutlich häufiger im Spam, und das merkt niemand, bis ein Kunde anruft und fragt, warum keiner geantwortet hat.

Analytics muss am Launch-Tag laufen und geprüft sein, denn Daten, die Sie in der ersten Woche nicht erfassen, lassen sich später nicht nachholen. Ein eingefügtes Tag reicht nicht. Legen Sie fest, welche Aktionen als Erfolg zählen (Kontaktanfragen, Angebotsanfragen, Anrufe, Käufe), markieren Sie sie in GA4 als Key Events und testen Sie jedes einzelne in DebugView oder Tag Assistant vor der DNS-Umstellung, solange Sie noch in Ruhe korrigieren können.

Bei Besuchern aus der EU müssen Cookie-Banner und Analytics zusammenarbeiten. In Deutschland verlangt § 25 TDDDG (bis Mai 2024 TTDSG) eine Einwilligung, bevor Informationen auf dem Endgerät gespeichert oder ausgelesen werden, sofern das für den gewünschten Dienst nicht unbedingt erforderlich ist. Google verlangt zusätzlich von Websites, die Nutzer im EWR mit seinen Tags messen, die Einwilligung einzuholen und über den Consent Mode weiterzugeben. Der Consent Mode hat die ursprünglichen Speichersignale um die Parameter ad_user_data und ad_personalization ergänzt. In der Praxis sollten Tags keine Analyse- oder Werbe-Cookies setzen, bevor der Besucher zustimmt, und Ablehnen sollte nicht mehr Aufwand machen als Zustimmen. Testen Sie beide Wege in einem privaten Fenster und prüfen Sie, ob das Ablehnen die Cookies wirklich stoppt.

Tracking-Checkliste

• GA4-Property angelegt, Traffic aus dem eigenen Büro herausgefiltert
• Key Events für jede Conversion definiert, die für das Geschäft zählt
• Search-Console-Property vor dem Launch bestätigt, am besten als Domain-Property
• Heatmap- und Session-Recording-Tools im Cookie-Banner und in der Datenschutzerklärung aufgeführt
• UTM-Benennung für die Launch-Ankündigung und alle Kampagnen abgestimmt

Die meisten SEO-Probleme am Launch-Tag entstehen durch Staging-Einstellungen, die in die Produktion wandern. Eine Staging-Seite ist meist für Suchmaschinen gesperrt, und diese Sperre muss in dem Moment fallen, in dem die Seite live geht. Laut Googles Dokumentation zum Blockieren der Indexierung kann Google die noindex-Regel einer Seite, die per robots.txt gesperrt ist, gar nicht lesen. Prüfen Sie beide Einstellungen deshalb zusammen und nicht nacheinander.

Signale für die Indexierung

• Entfernen Sie noindex-Meta-Tags und X-Robots-Tag-Header, die für Staging gesetzt wurden
• Die robots.txt der Live-Domain darf kein Disallow: / enthalten und kann mit einer Sitemap:-Zeile auf die Sitemap verweisen
• Jede Seite hat ein selbstreferenzierendes Canonical-Tag auf der Live-Domain, nicht auf der Staging-URL
• Eine Version der Domain (HTTPS, mit oder ohne www) ist die Hauptversion, die anderen leiten dorthin weiter
• Strukturierte Daten bestehen Googles Test für Rich-Suchergebnisse

XML-Sitemap

Erzeugen Sie eine Sitemap, die nur live geschaltete, indexierbare und kanonische URLs enthält. Googles Sitemap-Richtlinien begrenzen eine einzelne Datei auf 50.000 URLs oder 50 MB unkomprimiert und stellen klar, dass Google die Werte priority und changefreq ignoriert. Sie müssen sie also nicht feinjustieren. lastmod nutzt Google nur, wenn der Wert durchgehend stimmt.

Weiterleitungen von der alten Website

Ersetzt die neue Website eine alte, ist die Redirect-Map das wichtigste Dokument im Projekt. Crawlen Sie die alte Seite, exportieren Sie ihre URLs samt den Seiten mit Backlinks oder Suchtraffic und ordnen Sie jede einer möglichst passenden neuen Seite zu. Googles Anleitung für Website-Umzüge mit URL-Änderungen verlangt serverseitige permanente Weiterleitungen (301 oder 308), keine Weiterleitungsketten, keine Massenweiterleitungen auf die Startseite und Weiterleitungen, die mindestens ein Jahr bestehen bleiben. Unser Leitfaden zum Website-Umzug und die SEO-Relaunch-Checkliste führen Schritt für Schritt durch das Mapping.

Mehrsprachige Websites

Auf Websites mit mehreren Sprachen braucht jede Seite hreflang-Angaben, die alle Sprachversionen auflisten, sich selbst eingeschlossen, und jede Version muss zurückverweisen. Googles Dokumentation zu lokalisierten Versionen sagt, dass Angaben, die nur in eine Richtung zeigen, ignoriert werden. Ergänzen Sie einen x-default-Eintrag für die Sprachauswahl oder die Fallback-Seite. Für den DACH-Raum heißt das oft: getrennte Angaben für de-DE, de-AT und de-CH, sobald sich Preise, Rechtstexte oder Inhalte je Land unterscheiden.

Geschwindigkeit lässt sich am leichtesten vor dem Launch verbessern, solange die Templates noch offen sind. Googles Core Web Vitals geben klare Ziele vor. Web.dev definiert eine gute Nutzererfahrung beim 75. Perzentil der Seitenaufrufe, mobil und am Desktop, als Largest Contentful Paint von höchstens 2,5 Sekunden, Interaction to Next Paint von höchstens 200 Millisekunden und Cumulative Layout Shift von höchstens 0,1. INP hat 2024 First Input Delay als Core Web Vital abgelöst.

Vor dem Launch haben Sie nur Labordaten. Lassen Sie PageSpeed Insights und Lighthouse mit dem mobilen Profil über die Startseite und je eine Seite pro Template-Typ laufen (Leistungsseite, Artikel, Kontaktseite, Produktseite). Beheben Sie zuerst die schweren Brocken: unkomprimierte Hero-Bilder, Schriften aus mehreren Quellen sowie Chat- oder Tracking-Skripte, die den Main Thread blockieren. Unser Leitfaden zum Aufbau einer schnellen Website geht tiefer auf diese Korrekturen ein.

Fehler bei der Barrierefreiheit sind häufig und meist leicht zu finden. Der WebAIM Million Report 2026 fand erkennbare WCAG-2-Fehler auf 95,9% der eine Million meistbesuchten Startseiten: Text mit zu geringem Kontrast auf 83,9% davon, fehlende Alt-Texte bei Bildern auf 53,1% und fehlende Formular-Labels auf 51%. Automatische Tools wie axe oder WAVE markieren die meisten dieser Fehler auf Staging in wenigen Minuten pro Template.

Automatische Scans übersehen viel, deshalb gehört ein manueller Durchgang dazu. Gehen Sie jedes Template mit der Tabulatortaste durch, prüfen Sie, ob der Fokusrahmen sichtbar ist, und stellen Sie sicher, dass sich Cookie-Banner, Menüs und Pop-ups ohne Maus schließen lassen. Üblich ist WCAG 2.2 Stufe AA als Ziel.

In der EU gilt der European Accessibility Act seit Juni 2025 für viele digitale Dienste an Verbraucher. Deutschland setzt ihn mit dem Barrierefreiheitsstärkungsgesetz (BFSG) um, das seit dem 28. Juni 2025 unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr gilt, also etwa für Onlineshops, die sich an Verbraucher richten. Kleinstunternehmen, die Dienstleistungen anbieten (weniger als 10 Beschäftigte und höchstens 2 Mio. Euro Jahresumsatz oder Jahresbilanzsumme), sind von diesen Anforderungen ausgenommen. Unser Leitfaden für barrierefreie Websites listet die Prüfungen pro Komponente auf.

Sicherheitsarbeit vor dem Launch ist größtenteils Konfiguration. Das SSL-Zertifikat muss jeden ausgelieferten Hostnamen abdecken, mit und ohne www, und sich automatisch erneuern, und jede HTTP-Anfrage sollte auf HTTPS weiterleiten. Security-Header sind in einer Stunde eingerichtet und schließen häufige Lücken: Strict-Transport-Security, eine Content-Security-Policy (siehe MDN-Leitfaden zu CSP), X-Content-Type-Options und eine Referrer-Policy. Prüfen Sie sie mit einem externen Scanner, statt dem Hosting-Panel zu vertrauen.

• Admin-Konten nutzen eigene Passwörter und Zwei-Faktor-Authentifizierung, Standardkonten sind entfernt
• CMS, Plugins und Abhängigkeiten sind auf aktuellem Stand
• Automatische Backups laufen, liegen außerhalb des Servers, und eine Wiederherstellung wurde getestet
• Formulare haben Spamschutz, etwa ein Honeypot-Feld, Rate Limiting oder ein CAPTCHA
• Das Uptime-Monitoring alarmiert eine benannte Person, kein Sammelpostfach, das niemand liest

Impressum, Datenschutzerklärung und Cookies

Verlinken Sie Impressum, Datenschutzerklärung und, falls Sie eine führen, die Cookie-Richtlinie im Footer jeder Seite. In Deutschland steht die Impressumspflicht seit dem 14. Mai 2024 in § 5 DDG, dem Digitale-Dienste-Gesetz, das das Telemediengesetz und damit § 5 TMG abgelöst hat. Steht im Impressum noch "gemäß § 5 TMG", ist das ein schneller Hinweis darauf, dass die Rechtstexte veraltet sind. In Österreich ergeben sich die Informationspflichten aus § 5 E-Commerce-Gesetz, je nach Angebot ergänzt durch die Offenlegung nach § 25 Mediengesetz.

Die Datenschutzerklärung erfüllt die Informationspflichten nach Art. 13 DSGVO und muss die Tools nennen, die tatsächlich auf der Seite laufen. Schreiben Sie sie deshalb erst, wenn Analytics, Chat und eingebettete Inhalte feststehen, nicht vorher. Die Checkliste der IHK Köln für eine rechtssichere Webseite eignet sich als Abgleich, ersetzt aber keine anwaltliche Prüfung.

Der Launch-Tag sollte langweilig sein. Wählen Sie einen Vormittag unter der Woche, an dem Entwicklung und Content-Verantwortliche für den Rest des Tages verfügbar sind, und meiden Sie Freitagnachmittage. Frieren Sie Inhaltsänderungen auf der alten Seite einen Tag vorher ein, damit dort nichts erscheint, was die neue Seite nicht hat. Arbeiten Sie die Schritte dann in dieser Reihenfolge ab und haken Sie jeden ab, sobald er erledigt ist.

1. Senken Sie ein bis zwei Tage vorher die TTL der DNS-Einträge, die Sie ändern werden (300 Sekunden ist ein üblicher Wert). Resolver halten einen Eintrag so lange vor, wie seine TTL vorgibt, deshalb hilft das nur, wenn es vorab passiert.
2. Erstellen Sie ein letztes Backup der alten und der neuen Seite.
3. Deployen Sie und stellen Sie dann DNS oder die Hosting-Konfiguration um.
4. Leeren Sie jede Cache-Ebene (CDN, Server, CMS), damit niemand eine veraltete Version oder die Staging-Version ausgeliefert bekommt.
5. Prüfen Sie robots.txt und den noindex-Status auf der Live-Domain.
6. Crawlen Sie die Liste der alten URLs, um die Weiterleitungen zu bestätigen, und öffnen Sie die 20 Seiten mit dem meisten Traffic von Hand.
7. Reichen Sie die XML-Sitemap in der Search Console ein und führen Sie die URL-Prüfung für die Startseite und die wichtigsten Leistungsseiten aus. Hat sich die Domain selbst geändert, nutzen Sie das Tool zur Adressänderung, das Google für Umzüge zwischen Domains oder Subdomains vorsieht.
8. Senden Sie ein echtes Testformular ab und prüfen Sie, ob sowohl die E-Mail als auch das GA4-Key-Event ankommen.
9. Schalten Sie das Uptime-Monitoring ein und erhöhen Sie die TTL wieder, sobald die neue Umgebung stabil läuft.

Rechnen Sie mit einer Verzögerung, bis die Suche nachzieht. Laut Google kann das Crawling einige Tage bis einige Wochen dauern, und wer dieselbe URL mehrmals einreicht, beschleunigt es nicht. Nach einem Umzug können Rankings eine Weile schwanken, während Google die Weiterleitungen verarbeitet.

Im ersten Monat fangen Sie auf, was die Prüfung auf Staging übersehen hat. Echte Besucher kommen mit Browsern, Geräten und Wegen, die niemand getestet hat, und Crawler finden alte URLs, die niemand zugeordnet hat. Schauen Sie in den ersten zwei Wochen alle paar Tage in die Search Console, danach wöchentlich. Probleme, die Sie in diesem Zeitraum beheben, kosten wenig. Dieselben Probleme im vierten Monat haben bereits Traffic und Anfragen gekostet.

Search Console und 404-Fehler

• Achten Sie im Bericht "Seitenindexierung" auf steigende Zahlen bei "Nicht gefunden (404)", "Durch noindex-Tag ausgeschlossen" und "Seite mit Weiterleitung"
• Leiten Sie 404-URLs mit Backlinks oder Traffic auf die passenden neuen Seiten weiter
• Prüfen Sie, ob die Sitemap als fehlerfrei verarbeitet angezeigt wird
• Vergleichen Sie die Impressionen für Ihre wichtigsten Suchanfragen mit der Baseline der alten Seite

Analytics und Conversions

• Vergleichen Sie die Conversions in GA4 mit dem, was tatsächlich im CRM oder Posteingang angekommen ist, und klären Sie Abweichungen, bevor jemand mit den Zahlen arbeitet
• Suchen Sie nach Einstiegsseiten mit auffällig hohen Ausstiegsraten auf Mobilgeräten
• Prüfen Sie die Einwilligungsrate. Genau 0% oder genau 100% Zustimmung bedeutet, dass etwas falsch konfiguriert ist

Felddaten zur Performance

Laborwerte von vor dem Launch sind eine Prognose. Felddaten stammen von echten Chrome-Nutzern über den Chrome UX Report, der ein rollierendes 28-Tage-Fenster zusammenfasst. Der erste aussagekräftige Core-Web-Vitals-Bericht kommt daher etwa einen Monat nach dem Launch, und eine Seite mit wenig Traffic hat womöglich nie genug Daten für Ergebnisse auf Seitenebene. Dann füllen Daten auf Ebene des Ursprungs oder ein eigenes Real-User-Monitoring die Lücke.

Ab dem zweiten Monat gibt es genug Daten, um vom Reparieren zum Verbessern überzugehen. Die Frage verschiebt sich von "Ist etwas kaputt?" zu "Wo steigen Besucher aus, und warum?". Wählen Sie über die Berichte zu Conversion-Pfaden und Einstiegsseiten die zwei oder drei Seiten aus, die für Anfragen am wichtigsten sind, und beobachten Sie mit Heatmaps oder Session Recordings, wie Menschen sie nutzen, bevor Sie etwas ändern.

Ändern Sie jeweils nur eine Sache und messen Sie sie gegen die Baseline, denn Änderungen im Paket lassen sich keiner Ursache zuordnen. Reicht der Traffic, führen Sie einen sauberen A/B-Test nach dem Zyklus aus dem A/B-Testing-Leitfaden der Nielsen Norman Group durch: eine Hypothese, eine Variable, eine festgelegte Kennzahl und genug Zeit für ein Ergebnis. Auf B2B-Seiten mit wenig Traffic ist ein sauberer Vorher-nachher-Vergleich über mehrere Wochen oft die ehrlichere Alternative. Unser Leitfaden zur Conversion-Optimierung geht weiter.

Typische Verbesserungen in diesem Zeitraum:

• Kürzere Formulare, ohne die Felder, die der Vertrieb nie nutzt
• Klarere Calls-to-Action im ersten Bildschirm auf Mobilgeräten
• Seitenabschnitte, die nach Scrolltiefe neu angeordnet werden
• Interne Links von Blogartikeln zu den Leistungsseiten, die sie stützen
• Dünne Seiten, die ausgebaut oder mit stärkeren Seiten zusammengelegt werden

Wo KI-Tools helfen

KI-Tools sind gut in der Analysehälfte dieses Zyklus: Session Recordings zusammenfassen, Suchanfragen gruppieren, Auffälligkeiten in Analytics markieren und Testvarianten entwerfen. Für die Entscheidungshälfte braucht es weiterhin jemanden, der das Geschäft, seine Margen und seine Kunden kennt. Nutzen Sie KI, um den Weg von den Daten zur Hypothese zu verkürzen, und lassen Sie eine Person verantworten, was live geht.

Die meisten Launches scheitern am Prozess, selten an der Technik. Fast jedes Problem geht auf etwas zurück, das auf Staging stimmte und in der Produktion nicht mehr, oder auf eine Aufgabe, von der alle dachten, jemand anderes habe sie erledigt. Jeder der folgenden Fehler lässt sich mit einer verantwortlichen Person und einem Test günstig verhindern. Teuer wird er, wenn Sie ihn erst einen Monat später am Rückgang der Anfragen bemerken.

• Ein noindex-Tag oder eine robots.txt-Sperre aus Staging landet in der Produktion
• Es gibt keine Redirect-Map, oder alle Weiterleitungen zeigen auf die Startseite
• Analytics ist installiert, aber die Key Events wurden nie getestet, sodass der erste Monat an Conversion-Daten fehlt
• Ein Cookie-Banner lädt Tracker, bevor der Besucher zugestimmt hat
• Formular-Benachrichtigungen landen wochenlang unbemerkt im Spam
• Impressum oder Datenschutzerklärung fehlen oder sind am Launch-Tag noch Platzhalter
• Der Launch läuft spät am Freitag, und bis Montag ist niemand erreichbar
• Der Launch gilt als Projektende, und für Tag 30 oder Tag 90 ist keine Auswertung geplant

Ein Website-Audit rund drei Monate nach dem Launch findet, was durchgerutscht ist, und unser Leitfaden zur Website-Wartung beschreibt die Routinearbeit danach.

Eine Website-Checkliste für den Launch funktioniert, wenn sie geordnet ist, jeder Punkt eine verantwortliche Person hat und sie bis zum Ende abgearbeitet wird. Die Prüfungen vor dem Launch entscheiden, ob die Seite fertig ist. Der Launch-Tag ist eine kurze Abfolge von Umstellungen, die Sie vorher auf Staging proben sollten. In den 90 Tagen danach zeigt sich, ob die Seite mit echten Besuchern ihren Zweck erfüllt. Halten Sie die Baseline fest, geben Sie jeder Zeile eine verantwortliche Person und tragen Sie die Auswertungen an Tag 30 und Tag 90 vor dem Go-live in den Kalender ein.

Wenn Vezert eine Unternehmenswebsite oder eine Landingpage baut, ist eine Checkliste wie diese Teil der Übergabe. Nach dem Launch decken unsere Wartungspakete Performance-Monitoring, Sicherheitsupdates und Unterstützung bei Inhalten ab, und unsere SEO-Leistungen kümmern sich um Indexierung, Weiterleitungen, Inhalte und interne Verlinkung. Aktuelle Preise finden Sie auf der Preisseite.