# Website-Launch-Checkliste: Was Qualität nach dem Go-live von Pfusch unterscheidet > URL: https://4eck-media.de/blog/website-launch-checkliste-nach-go-live/ > Language: de > Description: Was passiert nach dem Website Launch? Matthias Petri zeigt die interne After-Live-Checkliste von 4eck Media – von Indexierung, PageSpeed und Security Headers bis Backups, Redirects und KI-Sichtbarkeit. --- Es gibt ein Wort, das in jedem Projektchat einen kleinen Jubel auslöst: „live“. Die Domain zeigt auf den neuen Server, das Schloss im Browser ist da, die Startseite lädt. Und genau in diesem Moment passiert in vielen Projekten ein stiller Fehler: Alle feiern – und niemand prüft weiter. Dabei beginnt jetzt erst die Phase, in der sich entscheidet, ob das Projekt sauber abgeschlossen wird oder ob der Kunde die nächsten Wochen als unbezahlter Tester arbeitet. Ich halte wenig von dem Satz „Wir stellen die Seite jetzt online und schauen dann, ob noch etwas auffällt.“ Natürlich fällt noch etwas auf. Eine Website läuft nach dem Launch unter anderen Bedingungen als in der Entwicklungsumgebung: echte Domain, echtes SSL, öffentliches Caching, reale Mailserver, Consent-Management, Suchmaschinen, Bots, Besucher. Diese Unterschiede sind normal. Nicht normal ist, sie dem Zufall zu überlassen. Deshalb gibt es bei uns eine zweite Liste. Alles, was [vor der Veröffentlichung kontrolliert werden muss](https://4eck-media.de/blog/website-checkliste-vor-go-live-qualitaet-statt-pfusch/), habe ich im ersten Teil beschrieben. Dieser Artikel beginnt dort, wo Teil 1 aufhört: auf der echten Domain, unter echten Bedingungen. Und auch diese Liste ist kein Geheimnis – wer selbst eine WordPress-Website betreibt, kann sie Punkt für Punkt abarbeiten. Man braucht kein magisches Agenturwerkzeug. Man braucht Zeit, Zuständigkeiten und die Bereitschaft, unangenehme Ergebnisse nicht schönzureden. Wir launchen übrigens nie um 16:55 Uhr am Freitag. Ein Go-live findet dann statt, wenn Entwickler, Projektleitung und notfalls der Hoster erreichbar sind. Danach wird nicht gefeiert, sondern geprüft. Feiern kann man später wesentlich entspannter. Online ist nicht fertig - Die Produktionsumgebung verändert Domain, SSL, Cache, E-Mail, Tracking und externe Dienste. - Vorbereitete Einstellungen werden auf der echten URL erneut kontrolliert. - Kritische Funktionen werden nicht nur angesehen, sondern vollständig ausgeführt. - Der Launch bekommt ein Zeitfenster mit erreichbaren Verantwortlichen. - Ein Haken gilt erst, wenn das Ergebnis dokumentiert und reproduzierbar ist. ## Entwicklungsseite abschalten: Die Website muss wirklich öffentlich sein Der erste Punkt klingt beinahe lächerlich, bis man erlebt hat, wie oft er vergessen wird. Nach dem Launch darf keine Wartungsseite, keine Coming-soon-Seite und kein Passwortschutz mehr vor der Website stehen. Und das prüfe ich grundsätzlich nicht in meinem normalen Browser – dort können Cookies und meine WordPress-Sitzung dafür sorgen, dass ich die echte Seite sehe, während jeder neue Besucher weiter vor einer Sperre steht. Also: privates Fenster, zweites Gerät, möglichst eine andere Verbindung. Und nicht nur die Startseite, sondern auch Unterseiten, ein Beitrag, ein Formular. Die alte Staging-Umgebung bleibt dabei trotzdem am Leben – aber sauber getrennt: geschützt, auf noindex, außerhalb der Sitemap. Eine frei erreichbare Kopie der Website produziert Duplicate Content, enthält oft Testdaten und ist eine unnötige Angriffsfläche. Bei einem Relaunch kontrolliere ich zusätzlich, welche Version die Domain gerade wirklich ausliefert: DNS und Caches brauchen Zeit, und einzelne Besucher können noch die alte Seite sehen. Das lässt sich nicht auf die Minute verhindern, aber man muss es wissen, bevor man Fehlerberichte einsammelt. ## Indexierung freigeben: das gefährlichste Häkchen von WordPress WordPress hat unter Einstellungen → Lesen eine unscheinbare Option: „Suchmaschinen davon abhalten, diese Website zu indexieren“. In der Entwicklung ist das Häkchen sinnvoll. Nach dem Launch ist ein vergessenes Häkchen an dieser Stelle der teuerste Einzelfehler, den eine neue Website haben kann – sie ist dann online, funktioniert perfekt und existiert für Google schlicht nicht. Ich verlasse mich dabei nicht auf die Beschriftung im Backend. Die Option ist nur ein Signal; Plugins und Serverregeln können eigene noindex-Angaben erzeugen. Also prüfe ich den Quellcode der wichtigsten Seitentypen, den HTTP-Header X-Robots-Tag, die robots.txt und die XML-Sitemap. Das Ziel ist keine pauschale Freigabe von allem, sondern eine klare Entscheidung pro Seitentyp: Startseite, Leistungen und Beiträge müssen indexierbar sein; interne Suchseiten, Warenkorb oder technische Archive bleiben je nach Projekt bewusst draußen. Nach einem Domainwechsel suche ich außerdem nach Resten der Entwicklungsadresse: Canonical-Tags, OG-Bilder, strukturierte Daten, interne Links und Sitemap-URLs dürfen nicht mehr auf dev. oder eine Agentur-Subdomain zeigen. Ein einziger falscher Canonical erzählt Google, die frisch gelaunchte Seite sei nur die Kopie einer Testadresse. Zum Abschluss dieses Punkts nutze ich die URL-Prüfung in der Google Search Console. Der Live-Test beantwortet die entscheidende Frage: Kann Google die Seite abrufen, darf sie indexiert werden, und welche kanonische URL wird erkannt? Direkt nach dem Launch zeigt der Index oft noch den alten Stand – das ist kein Problem, sondern Physik. Der Live-Test trennt ein normales „noch nicht neu gecrawlt“ von einem echten technischen Fehler. Die Sitemap wird eingereicht, und in den Wochen danach schaue ich regelmäßig in Indexierungsberichte und 404-Statistiken. Wer die Search Console erst drei Monate später öffnet, übersieht drei Monate lang ein lösbares Problem. ## Yoast finalisieren: Vorlagen statt Einzelseiten prüfen Die Grundeinstellungen von Yoast sind schon vor dem Launch kontrolliert – das steht in Teil 1. Auf der echten Domain geht es jetzt um die Ausgabe: Ich öffne mehrere repräsentative Inhalte und prüfe, ob Titel sinnvoll aufgebaut sind, die Domain überall stimmt und keine Platzhalter sichtbar bleiben. Entscheidend sind die Vorlagen: Ein einzelner sauber gepflegter Artikel beweist nichts, wenn Kategorien, Leistungsseiten oder ein ganzer Custom Post Type falsche Meta-Daten oder ein versehentliches noindex erben. Ich prüfe mindestens Startseite, einen normalen Inhalt, ein Archiv und jeden wichtigen Inhaltstyp – bei mehrsprachigen Websites in jeder Sprache. Die Ampelfarbe von Yoast ist für mich dabei ein Hinweis, kein Qualitätsurteil. Ein Text kann grün sein und trotzdem austauschbar klingen. Wichtiger ist die technische Ausgabe: Ist der Titel eindeutig? Fehlt auf einer zentralen Seite die Description? Zeigt das Social Preview das richtige Bild? ## Barrierefreiheit auf der echten Domain: der Cookie-Banner ist der erste Eindruck Warum noch einmal Barrierefreiheit, wenn sie vor dem Launch schon geprüft wurde? Weil beim Go-live neue Elemente dazukommen: Cookie-Banner, Tracking-Dialoge, Captchas, Chats, Sicherheitslösungen. Und ausgerechnet der Consent-Dialog liegt über der gesamten Website – er ist damit funktional wichtiger als fast jeder Inhaltsblock. Wenn der erste Dialog der Website nicht per Tastatur bedienbar ist, der Fokus dahinter verschwindet oder „Ablehnen“ kaum lesbar gestaltet wurde, ist die schönste zugängliche Unterseite dahinter wertlos. Ich lasse deshalb AccessibilityChecker und AccessScan auf der Produktionsseite noch einmal laufen und speichere das Ergebnis mit Datum. So ein Bericht ist kein lebenslanges Zertifikat – schon das nächste Plugin-Update kann den Zustand ändern. Er dokumentiert einen Zeitpunkt, und genau dafür ist er da. Dazu kommen die manuellen Handgriffe aus Teil 1, jetzt eben auf der Live-Seite: ohne Maus navigieren, Fokus verfolgen, Formularfehler provozieren, Zoom testen. Wer dabei Unterstützung braucht: Unsere Herangehensweise steht unter [Barrierefreiheit von Websites](https://4eck-media.de/kompetenzen/agentur-barrierefreiheit/). ![WCAG-2.2-Audit der Bolzakademie-Website mit 90 von 100 Punkten und null kritischen Fehlern](https://4eck-media.de/wp-content/uploads/2026/07/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif) ## PageSpeed in Produktion: erst die echte Domain sagt die Wahrheit Die Zielwerte kennen Sie aus Teil 1: mindestens 90, angestrebt 94, 95 und mehr – der Puffer ist Absicht. Neu ist nach dem Launch die Umgebung. Auf der echten Domain kommen CDN, Caching-Regeln, Consent-Manager und alle Drittanbieter-Skripte zusammen, die im Staging oft fehlten oder im Testmodus liefen. Eine Messung vor dem Aktivieren des Consent-Managers ist mit einer Messung danach schlicht nicht vergleichbar. Ich messe mit [PageSpeed Insights](https://pagespeed.web.dev/) Mobile und Desktop getrennt und mehrmals: erst den kalten Aufruf, dann den wiederholten. Wenn die Ergebnisse stark schwanken, ist die Schwankung selbst der Befund – eine schnelle Website ist nicht nur im Bestfall schnell. Und ich messe nicht nur die Startseite: Leistungsseite, Blogartikel, Übersicht, Kontakt, bei Shops Produkt und Checkout. Jede Vorlage lädt andere Bilder und Skripte; eine blitzschnelle Startseite beweist nichts über einen Produktfilter mit mehreren Megabyte JavaScript. Felddaten realer Nutzer fehlen direkt nach dem Launch übrigens noch oder beziehen sich auf die alte Website – auch das ist normal. Für die erste Woche zählen die Labordaten und die Ursachen dahinter: LCP, INP, CLS. Details zu unserem Vorgehen stehen auf der Seite zur [PageSpeed-Optimierung und den Core Web Vitals](https://4eck-media.de/kompetenzen/pagespeed-optimierung-core-web-vitals/). ![Google PageSpeed Insights Bericht der Bolzakademie-Website mit Bewertung der Ladezeit](https://4eck-media.de/wp-content/uploads/2026/07/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif) Unser PageSpeed-Puffer - 90 Punkte sind unser Mindestwert, 94 bis 95 oder mehr unser Startziel. - Mobile und Desktop werden getrennt und auf mehreren Seitentypen gemessen. - LCP, INP und CLS sind wichtiger als ein isolierter Gesamtscore. - Mehrere Messungen zeigen, ob das Ergebnis stabil oder nur zufällig gut ist. - Der Puffer schützt die grüne Zone vor späteren Bildern und Marketing-Skripten. ## Security Header: Schutz prüfen, ohne einer Schulnote hinterherzulaufen Security Header sind Regeln, die der Server dem Browser mitgibt: HTTPS erzwingen, fremdes Einbetten verhindern, Skriptquellen begrenzen. Viele davon lassen sich erst auf der öffentlichen Domain sinnvoll prüfen. Wir nutzen dafür [SecurityHeaders.com](https://securityheaders.com/) – und ich sage dazu ehrlich: Die Note dort ist ein Hinweis, kein Selbstzweck. Eine extrem strenge Content Security Policy, die nebenbei den Zahlungsanbieter, das Video oder den Consent-Manager blockiert, ist keine gelungene Sicherheitsmaßnahme. Sie ist ein neuer Fehler mit besserer Bewertung. Mindestens bewerte ich Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy und den Frame-Schutz. Und nach jeder Änderung wird die Website funktional getestet: Formular, Videos, Karten, Consent, Fonts – und ein Blick in die Browserkonsole auf blockierte Ressourcen. Header sind aktive Regeln, keine Deko. Genau deshalb darf man sie weder ignorieren noch gedankenlos aus einer Vorlage kopieren. ![Security-Headers-Report der Bolzakademie-Website mit der Bestnote A+ und allen aktiven Headern](https://4eck-media.de/wp-content/uploads/2026/07/sicherheit-security-header-website-bolzakademie-bestnote.avif) ## Favicon und Structured Data: zwei kurze, aber echte Live-Prüfungen Das Favicon habe ich in Teil 1 als den am zuverlässigsten vergessenen Punkt beschrieben. Auf der Live-Domain kommt eine Eigenheit dazu: Browser cachen Favicons erstaunlich hartnäckig. Dass mein Browser das neue Icon zeigt, heißt nicht, dass ein neuer Besucher es auch bekommt – oder umgekehrt. Also: privates Fenster, zweites Gerät, direkte favicon.ico-Adresse, helle und dunkle Browseroberfläche. Bei den strukturierten Daten geht es nach dem Launch vor allem um eines: Reste. Nach einem Relaunch stecken in Schema-Graphen gern noch alte Bildadressen, Staging-URLs oder IDs der Testumgebung – der sichtbare Inhalt liegt auf der neuen Domain, das Markup erzählt eine andere Geschichte. Ich validiere die öffentlichen URLs mit dem [Schema.org Validator](https://validator.schema.org/) und, wo Google einen Typ unterstützt, mit dem [Rich Results Test](https://search.google.com/test/rich-results). Der Grundsatz aus Teil 1 gilt unverändert: Valide heißt noch nicht wahr. Name, Adresse, Telefonnummern und Bilder müssen mit dem übereinstimmen, was auf der Seite sichtbar ist. Markup nach dem Launch - Die öffentliche URL mit Schema.org Validator und Googles Werkzeugen prüfen. - Fehler, Warnungen und widersprüchliche Angaben getrennt bewerten. - Staging-URLs, alte IDs, falsche Bilder und veraltete Kontaktdaten suchen. - Nur sichtbare, reale und belegbare Informationen auszeichnen. - Entitäten über stabile IDs zu einem nachvollziehbaren Graphen verbinden. ## E-Mails und Formulare: auf der Live-Domain ändert sich alles Formulare wurden vor dem Launch getestet – und werden nach dem Launch komplett neu getestet. Das ist keine Pedanterie: Mit der Domain ändern sich Absenderadresse, SPF- und DKIM-Zusammenhang, SMTP-Konfiguration, Captcha-Schlüssel und manchmal das zuständige Postfach. Genau deshalb kann ein Formular im Staging funktionieren und in Produktion Nachrichten verlieren – lautlos, hinter einer freundlichen grünen Erfolgsmeldung. Ich fülle jedes wichtige Formular wie ein echter Nutzer aus: erst Pflichtfelder leer lassen, dann eine ungültige E-Mail-Adresse, dann eine gültige Anfrage. Die muss im richtigen Postfach ankommen – nicht irgendwo auf dem Mailserver, sondern bei der Person, die sie bearbeiten soll. Im Posteingang kontrolliere ich Absendername, Betreff, Reply-To und alle übermittelten Felder; eine Antwort muss an den Besucher gehen können, ohne dass eine Serveradresse im Empfänger steht. Der Spamordner gehört genauso zum Test wie die Versand-Logs. Und bei mehrsprachigen Websites wird jede Sprachversion einzeln getestet – samt automatischer Bestätigung, deren Sprache und Links. Zum Schluss die unbequeme Frage, die kaum jemand stellt: Was passiert, wenn der Maildienst kurz nicht erreichbar ist? Wird die Anfrage gespeichert, erneut versucht oder still verworfen? Bei geschäftskritischen Formularen reicht „sollte funktionieren“ nicht. Der Kunde muss wissen, wo er einen Ausfall erkennt. ## Backups: einrichten, prüfen – und einmal wirklich wiederherstellen Viele Hoster werben mit automatischen Sicherungen. Gut. Aber das beantwortet nicht die Fragen, auf die es im Ernstfall ankommt: Wie oft wird gesichert? Wie lange aufbewahrt? Liegt die Sicherung auf derselben Infrastruktur, die gerade ausgefallen ist? Sind Datenbank und Dateien enthalten? Wer darf wiederherstellen, und wie lange dauert das? Unsere Grundlinie: Der Hoster darf die schnelle erste Ebene stellen, zusätzlich geht mindestens täglich eine Sicherung auf einen getrennten Speicher – Cloud-Konto des Kunden oder nach Vereinbarung unsere Infrastruktur. Eine Kopie auf demselben Webspace ist kein Schutz gegen ein kompromittiertes Konto. Und dann der Schritt, der fast überall fehlt: Ich stelle mindestens stichprobenartig wieder her, in einer sicheren Umgebung. Archive können unvollständig, beschädigt oder von einer Plugin-Version abhängig sein. Wer das erst während eines Ausfalls herausfindet, hat keine Sicherungsstrategie – er hat eine Sammlung von Dateien. Backup ohne Restore-Test ist Hoffnung - Hosting-Backup plus getrennte externe Sicherung vereinbaren. - Mindestens täglich sichern; bei Transaktionen das Intervall anpassen. - Dateien und Datenbank gemeinsam berücksichtigen. - Aufbewahrung, Verschlüsselung, Zuständigkeit und Datenschutz dokumentieren. - Eine echte Wiederherstellung in sicherer Umgebung testen. ## Seobility nach dem Launch: die öffentliche Website komplett crawlen Vor dem Launch prüfen wir Stichproben, nach dem Launch lasse ich die öffentliche Website vollständig crawlen. Der Crawler arbeitet mit der echten Domain, den echten Protokollen und allen Sprachversionen – und findet die typischen Launch-Reste: alte Entwicklungslinks, doppelte Titel, fehlende Descriptions, Ressourcen, die noch über HTTP laden. Ich kontrolliere auch, ob HTTP konsequent auf HTTPS führt und ob sich www- und Non-www-Varianten eindeutig verhalten. Es darf nicht mehrere öffentlich erreichbare Versionen derselben Website geben. Bei der Struktur schaue ich weniger auf rote Ampeln als auf die Frage, ob der Crawler dieselbe Website findet wie ein Mensch: Sind zentrale Leistungen näher an der Startseite als alte Pressemitteilungen? Gibt es verwaiste Seiten? Erzeugen Filter oder Archive Tausende unnötiger URLs? Seobility ist für uns keine Maschine zum Erzeugen einer schönen Prozentzahl, sondern eine strukturierte Aufgabenliste: relevante Befunde abarbeiten, neu crawlen, bewusste Ausnahmen dokumentieren. Ein ignorierter Fehler ohne Begründung ist kein Qualitätsmanagement. Für den großen Rundumblick gibt es das [SEO-Audit mit technischer und inhaltlicher Prüfung](https://4eck-media.de/kompetenzen/seo-audit-analyse-und-optimierung/). ![Seobility-Analyse der Bolzakademie-Website mit 96 Prozent On-Page-Score](https://4eck-media.de/wp-content/uploads/2026/07/seo-onpage-optimierung-analyse-website-bolzakademie.avif) ## Agent Ready: die Website für KI-Systeme lesbar machen Nach dem klassischen SEO-Check prüfen wir inzwischen eine zweite Lesbarkeit: die für KI-Systeme. Dafür gibt es neue Werkzeuge – Agent-Ready-Plugins, llms.txt, Analysen wie Ranketic. Meine Haltung dazu ist unaufgeregt: Solche Werkzeuge machen technische Lücken sichtbar und ergänzen Signale. Sie machen aus austauschbaren Werbesätzen keine belastbaren Fachinformationen. KI-Systeme brauchen eindeutige Aussagen: Wer bietet was an, für wen, in welcher Region, mit welchen Belegen? Diese Antworten müssen im sichtbaren Inhalt stehen und zum Markup passen. Konkret kontrolliere ich nach dem Launch: Dürfen relevante KI-Crawler die Inhalte laut robots.txt abrufen? Sind Leistungen, Organisation und Personen im HTML klar benannt? Ist das Schema-Markup konsistent und mit stabilen IDs verbunden? Und – besonders wichtig – erzeugt ein zusätzliches Plugin keine doppelten Meta-Tags, Sitemaps oder Schema-Blöcke? Auf einer WordPress-Website arbeiten oft schon Yoast, Theme und individuelle Structured-Data-Funktionen; ein weiteres Werkzeug kann helfen oder dieselbe Information ein zweites Mal anders ausgeben. Mehr Code ist nicht automatisch mehr Sichtbarkeit. Die strategische Seite dieses Themas steht in unserem [GEO-Framework für KI-Sichtbarkeit und Empfehlungen](https://4eck-media.de/blog/geo-framework-ki-sichtbarkeit-empfehlungen/). ![Cloudflare-Scan der Bolzakademie-Website mit Level 5 Agent-Native und Score 86](https://4eck-media.de/wp-content/uploads/2026/07/ki-optimierung-agent-native-website-bolzakademie-cloudflare.avif) ## AI-Bot-Logger: messen, wer wirklich kommt Wenn wir wissen wollen, ob KI-Crawler die Website besuchen, brauchen wir Daten statt Gefühl. Ein AI-Bot-Logger protokolliert Zugriffe bekannter User-Agents. Nach dem Launch prüfe ich drei Dinge: Läuft er wirklich? Sind die Daten plausibel? Und bremst er die Seite nicht? Dazu gehört ein ehrlicher Vorbehalt: Ein User-Agent ist keine beglaubigte Identität – er lässt sich fälschen. Die Statistik ist ein Beobachtungsinstrument, keine Besucherliste. Und eine Warnung vor der neuen Eitelkeitsmetrik: Zehntausend Bot-Aufrufe sind kein Geschäftserfolg. Eine einzige qualifizierte Empfehlung kann mehr wert sein. Das Ziel ist nicht, möglichst viele Maschinen anzulocken, sondern relevante Systeme mit klaren, aktuellen, zitierbaren Informationen zu versorgen. Auch bei den Logs gilt Datenschutz: Zweck, Zugriff und Löschfrist müssen geklärt sein – wir speichern nicht unbegrenzt alles, nur weil es technisch geht. ## Tracking und Cookies: die Einwilligung muss technisch wirken Tracking wird nur eingerichtet, wenn es vorgesehen und rechtlich geklärt ist – technisch nicht notwendige Technologien brauchen in Deutschland in der Regel eine wirksame Einwilligung; die Unterscheidung erklärt auch die [Bundesbeauftragte für den Datenschutz und die Informationsfreiheit](https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Cookies.html). Was das praktisch heißt: Banner anzeigen und Analytics trotzdem sofort laden ist keine Einwilligung, sondern Dekoration. Nach dem Launch teste ich deshalb drei Zustände: keine Entscheidung, Ablehnung, Zustimmung. Vor der Zustimmung dürfen einwilligungspflichtige Skripte, Requests und Speicherungen nicht stattfinden, nach der Ablehnung ebenfalls nicht – und das kontrolliere ich in den Browser-Werkzeugen, nicht in der Anzeige des Consent-Plugins. Dazu kommt die Beobachtung, die ich erstaunlich oft mache: ein deutscher Cookie-Banner auf einer englischen oder polnischen Seite. Eine Einwilligung kann nur informiert sein, wenn der Nutzer versteht, worüber er entscheidet. Kategorien, Buttons und Hinweise gehören in die Sprache der Seite, ein Link zu den Cookie-Einstellungen auf jede Sprachversion – und Ablehnen darf nicht durch Farbe oder Extra-Klicks künstlich erschwert werden. Wenn Tracking läuft, muss es auch stimmen: Kommen Seitenaufrufe im richtigen Konto an? Sind interne Zugriffe gefiltert? Funktionieren die Events für Formulare und Käufe? Eine technisch eingebundene Analytics-ID ist noch kein Messkonzept. ## Redirects live ausführen: jetzt zählen Statuscodes, nicht Pläne Die Redirect Map wurde in Teil 1 vorbereitet – jetzt wird sie unter echten Bedingungen ausgeführt und getestet. Ich prüfe Statuscode und Ziel: in der Regel direkt per 301 auf die endgültige HTTPS-URL, ohne Ketten über HTTP, www und Zwischenstationen. Interne Links werden anschließend auf die endgültigen URLs umgestellt, damit die eigene Website nicht dauerhaft über Umleitungen navigiert. Wie Ketten und Schleifen aussehen und warum sie schaden, zeigt das Diagramm in Teil 1. [Google empfiehlt bei Umzügen mit geänderten URLs](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=de), Weiterleitungen mindestens ein Jahr bestehen zu lassen – und in den meisten Projekten gibt es keinen Grund, sie danach schnell zu entfernen. Alte Links leben in Dokumenten, E-Mails und Verzeichnissen weiter. Wichtig: Die Map ist nach dem Start nicht „erledigt“. Die realen 404-Aufrufe der ersten Wochen ergänzen sie – wenn ein wertvoller alter Pfad fehlt, wird die Weiterleitung nachgezogen und erneut getestet. Ein Relaunch verliert Sichtbarkeit selten durch einen großen Fehler. Meistens sind es viele kleine vergessene URLs. ## Spam-Schutz: erst der Honeypot, dann erst schwerere Geschütze Sobald ein Formular öffentlich ist, finden Bots es – das ist keine Frage von ob, nur von wann. Unsere erste Schutzebene ist ein Honeypot: ein für Menschen unsichtbares Feld, das nur Bots ausfüllen. Für echte Nutzer entsteht null zusätzliche Arbeit. Nach dem Launch teste ich beide Seiten: Eine normale Anfrage muss durchkommen, ein simuliertes Bot-Muster muss hängen bleiben. Ein zu aggressiver Schutz ist genauso ein Fehler wie gar keiner – wenn Kundenanfragen verschwinden, hat die Website ihr Ziel verfehlt, auch wenn der Spamordner vorbildlich leer bleibt. reCAPTCHA und ähnliche Dienste setze ich erst ein, wenn Honeypot, Zeitprüfung und serverseitige Regeln nicht reichen. Externe Captchas kosten Datenschutz-Klarheit, Barrierefreiheit und Ladezeit, und ihre Schlüssel sind an Domains gebunden – auch das ist ein Live-Test, kein Staging-Test. In den ersten Tagen beobachten wir das reale Spamaufkommen und stimmen die Schutzstufe darauf ab. Sicherheit ist kein Schalter, sondern ein Verhältnis zwischen Schutz und Nutzbarkeit. ## Die ersten 24 Stunden: beobachten, priorisieren, nicht hektisch werden Die unmittelbare Checkliste ist nach einigen Stunden abgearbeitet. Danach beginnt die Beobachtung: Fehlerlogs, 404-Aufrufe, Formularzustellung, Caching, Verfügbarkeit. Bei Shops zusätzlich Bestellungen, Zahlungen, Transaktionsmails; bei Portalen Registrierung und Passwort-Reset. Und weil in dieser Phase garantiert Funde auflaufen, brauchen sie Prioritäten – sonst erzeugt die Liste Aktivität statt Qualität. ![Übersicht der Fehler-Prioritäten nach dem Launch: P0 kritisch sofort, P1 hoch innerhalb von 24 Stunden, P2 normal dokumentiert und geplant](https://4eck-media.de/wp-content/uploads/2026/07/launch-priorities-p0-p1-p2.avif) Jeder Fund braucht dabei einen brauchbaren Beleg: URL, Gerät oder Browser, Schritte zur Reproduktion, erwartetes und tatsächliches Verhalten. „Formular geht nicht“ ist keine Aufgabe. „Kontaktformular auf iPhone/Safari zeigt nach gültigem Versand eine Endlosschleife; Nachricht wird nicht zugestellt“ ist eine. Nach der Korrektur prüft nicht nur derjenige, der sie umgesetzt hat – und ich teste angrenzende Funktionen gleich mit: Eine Änderung am Consent-Manager kann das Tracking reparieren und nebenbei ein Video blockieren. Technische Systeme bestehen aus Beziehungen. Nach einer Woche kommen die echten Daten dazu: Search Console, Server-Logs, rechtmäßig eingesetztes Analytics, Supportanfragen. Ich erwarte keine perfekte Linie – Rankings schwanken während einer Migration, Crawler brauchen Zeit, Nutzer lernen eine neue Navigation. Wichtig sind Muster: Steigen 404-Fehler stark? Brechen Formulareinreichungen ein? Verschlechtert sich der mobile LCP? Solche Veränderungen brauchen eine Ursache, keine Ausrede. ## Das Launch-Protokoll: Wer, wann, womit bewiesen Nach ein paar Wochen fragt garantiert jemand: Wurde das Formular nach dem Launch wirklich getestet? Welche PageSpeed-Werte hatten wir? Waren die Redirects vollständig? Ohne Protokoll antwortet jeder aus dem Gedächtnis – und Erinnerungen sind im Projektalltag bemerkenswert flexibel. Unser Launch-Protokoll ist bewusst einfach: Prüfpunkt, verantwortliche Person, Datum und Uhrzeit, geprüfte URL, Ergebnis, Beleg. Ein Beleg ist ein Screenshot mit Kontext, ein Tool-Bericht, eine empfangene Testmail – er muss zur Behauptung passen. Ein grünes Formularbild beweist keine Zustellung; die empfangene Nachricht schon. Die Uhrzeit ist übrigens nicht Pedanterie: Ein PageSpeed-Test vor dem Aktivieren des Consent-Managers dokumentiert eine andere Website als danach. Wir dokumentieren auch bewusste Abweichungen: Vielleicht erreicht eine Seite wegen eines unverzichtbaren Buchungsdienstes nur 92 statt 95 Punkte – dann steht im Protokoll die fachliche Entscheidung, nicht einfach „ignoriert“. Das Protokoll schützt dabei weniger die Agentur als den Betrieb: Wenn sechs Monate später ein Problem auftaucht, sehen wir den damaligen Stand und suchen nicht im Nebel. Und der Kunde bekommt eine Übergabe, mit der ein späterer Dienstleister arbeiten kann. Gute Arbeit darf übergabefähig sein. Zur Übergabe gehören schließlich geordnete Zugänge – jede Person nur mit den Rechten, die sie braucht, Testkonten raus – und eine verständliche Einweisung in die Handgriffe des Alltags: Inhalte pflegen, Bilder vorbereiten, Alt-Texte, Formulareinträge finden. Die beste technische Basis wird beschädigt, wenn ein Redakteur 12-Megabyte-Bilder hochlädt, weil ihm niemand den Unterschied erklärt hat. Der Kunde nimmt Fachliches ab und gibt Inhalte frei. Er ist nicht dafür zuständig, unsere Redirect-Ketten zu finden. Der Kunde soll die Website nutzen können – nicht die Arbeit der Agentur zu Ende testen. Mein Maßstab nach dem Launch - Die Live-Domain wird als neues technisches Umfeld behandelt und vollständig geprüft. - Keine Erfolgsmeldung ersetzt Zustellung, Indexierbarkeit oder echte Funktion. - Scores helfen bei der Suche, entscheiden aber nicht allein über Qualität. - Kritische Funde erhalten Verantwortliche, Frist und unabhängigen Gegentest. - Der Kunde übernimmt eine dokumentierte Website und keine offene Baustelle. ## Die komplette After-Live-Checkliste auf einen Blick Wie in Teil 1 gilt: Die Übersicht ist die verdichtete Version unserer internen Liste, kopieren ist erwünscht, und jeder Punkt braucht einen Namen. Ein Shop ergänzt Zahlungs- und Bestelltests, ein Portal Rollen und Rechte, eine internationale Website Sprachwechsel und lokalisierte Formulare. | Prüfpunkt | Was konkret kontrolliert wird | Folge, wenn er fehlt | | --- | --- | --- | | Entwicklungsseite | Wartungsmodus, Passwortschutz und öffentliche Erreichbarkeit | Besucher sehen eine Sperre oder falsche Version | | Indexierung | WordPress-Leseeinstellung, noindex, robots.txt, Canonical, Sitemap | Suchmaschinen können zentrale Seiten nicht sauber aufnehmen | | Yoast | Titel, Descriptions, Canonicals, Social Preview, Seitentypen | Falsche oder doppelte Suchsignale | | Accessibility | Scanner, Tastatur, Fokus, Formulare und Consent-Layer | Nutzer werden ausgeschlossen; rechtliche und qualitative Risiken | | PageSpeed | Mobile, Desktop, Templates, LCP, INP, CLS | Langsame Nutzung und kein Puffer für spätere Inhalte | | Security Header | HSTS, CSP, Referrer-, Permissions- und Frame-Regeln | Vermeidbare Angriffsfläche oder durch falsche Regeln blockierte Funktionen | | Favicon | Browser, direkte Datei, helle und dunkle Oberfläche | Unfertiger Markenauftritt | | Structured Data | Schema.org, Rich Results, sichtbarer Inhalt, stabile IDs | Widersprüchliche oder nicht verarbeitbare Maschinensignale | | Formulare und E-Mail | Validierung, Versand, Zustellung, Reply-To, Sprachen | Anfragen gehen unbemerkt verloren | | Backups | Intervall, externer Speicher, Aufbewahrung und Restore | Ausfall wird zum Datenverlust | | Seobility | Technik & Meta, Struktur und Inhalt | Launch-Reste und Crawlprobleme bleiben verborgen | | Agent Ready | KI-Crawler, Inhalte, Schema, llms.txt und Plugin-Konflikte | Website ist für KI-Systeme schwerer einzuordnen | | AI-Bot-Logger | Funktion, Plausibilität, Datenschutz und Aufbewahrung | Keine belastbaren Daten über Bot-Zugriffe | | Tracking und Cookies | Zustimmung, Ablehnung, Skript-Blocking und Sprache | Falsche Daten und Datenschutzrisiken | | Redirect Map | 301-Ziele, Ketten, Schleifen und reale 404-Aufrufe | Verlorene Besucher und Suchsignale | | Spam-Schutz | Honeypot, legitime Anfragen, bei Bedarf Captcha | Spamflut oder blockierte Kunden | ## Fazit: Nach dem Go-live zeigt sich, ob die Website fertig ist – oder nur online Der eigentliche Launch dauert länger als der DNS-Wechsel. Entwicklungsseite abschalten, Indexierung freigeben, Accessibility und PageSpeed auf der echten Domain, Security Header, Markup, E-Mails, Backups mit Restore-Probe, Crawl, KI-Lesbarkeit, Consent, Redirects, Spam-Schutz, Protokoll: Erst dieses Gesamtbild macht aus einer veröffentlichten Website ein abgeschlossenes Projekt. Der Unterschied zwischen Qualität und Pfusch ist dabei nicht Fehlerfreiheit. Websites sind komplex, Geräte vielfältig, externe Dienste veränderlich. Der Unterschied ist Verantwortlichkeit: wahrscheinliche Fehler systematisch suchen, kritische Funktionen beweisen, auf neue Befunde vorbereitet sein. Eine schlechte Übergabe lautet: „Die Seite ist online, melden Sie sich, wenn etwas ist.“ Eine gute enthält Prüfergebnisse, offene Punkte, Zuständigkeiten und einen erreichbaren Ansprechpartner. Wenn Sie eine WordPress-Website planen, relaunchen oder unabhängig prüfen lassen möchten: Mehr über unsere Arbeit steht unter [UI/UX-Design und Webentwicklung](https://4eck-media.de/kompetenzen/ui-ux-design-webentwicklung/), oder Sie [sprechen direkt mit uns](https://4eck-media.de/kontakt/) – gern auch mit Ihrer eigenen Checkliste. Konkrete Fragen sind fast immer ein gutes Zeichen. ## Häufige Fragen zur Website-Launch-Checkliste Was muss man direkt nach dem Website Launch prüfen? Direkt nach dem Launch gehören öffentliche Erreichbarkeit, Indexierung, Canonicals, Sitemap, Yoast, Formulare und E-Mail-Zustellung, PageSpeed, Accessibility, Security Header, Structured Data, Backups, Redirects, Tracking und Spam-Schutz auf die Liste. Bei Shops und Portalen kommen geschäftskritische Spezialfunktionen hinzu. Warum reicht die Prüfung vor dem Go-live nicht aus? Die Produktionsumgebung verändert Domain, SSL, Caching, E-Mail, externe Skripte, Consent-Management und öffentliche Erreichbarkeit. Viele vorbereitete Einstellungen lassen sich erst auf der echten Domain vollständig bestätigen. Wie schnell sollte die After-Live-Prüfung erfolgen? Geschäftskritische und technische Grundprüfungen erfolgen unmittelbar nach dem Domainwechsel. Logs, Indexierung, 404-Entwicklung, reale Core Web Vitals und Nutzungsdaten werden danach über Tage und Wochen weiter beobachtet. Welcher PageSpeed-Wert ist nach dem Launch gut? Bei 4eck Media gilt 90 als Mindestwert. Wir starten möglichst mit 94 bis 95 Punkten oder mehr, damit spätere Bilder, Videos oder Marketing-Skripte nicht sofort aus der grünen Zone führen. Zusätzlich werden LCP, INP, CLS und mehrere Seitentypen bewertet. Braucht jede WordPress-Website ein externes Backup? Wir empfehlen neben der Sicherung des Hosters eine getrennte Kopie beim Kunden oder in einer vereinbarten Cloud. Entscheidend sind passendes Intervall, Aufbewahrung, Datenschutz und ein getesteter Restore. Eine Sicherung auf demselben Webspace schützt nicht vor jedem Ausfall. Was bedeutet Agent Ready bei einer Website? Eine agentenfähige Website ist für KI-Crawler technisch erreichbar und beschreibt Organisation, Personen, Leistungen und Fachwissen eindeutig im sichtbaren HTML und im strukturierten Markup. Plugins und llms.txt können unterstützen, ersetzen aber keine konkreten, vertrauenswürdigen Inhalte. Reicht ein Cookie-Banner für datenschutzkonformes Tracking? Nein. Einwilligungspflichtige Skripte müssen vor der Zustimmung und nach einer Ablehnung technisch blockiert bleiben. Der Banner muss verständlich, zugänglich, widerrufbar und bei mehrsprachigen Websites in der richtigen Sprache verfügbar sein. Wie lange sollten Redirects nach einem Relaunch bestehen bleiben? Google empfiehlt, Weiterleitungen bei Website-Umzügen möglichst lange und im Allgemeinen mindestens ein Jahr beizubehalten. Häufig ist eine längere Laufzeit sinnvoll, weil alte Links aus Dokumenten, Verzeichnissen und Lesezeichen weiterhin genutzt werden.