WordPress-Launch-Checkliste für Business-Sites

Eine Business-WordPress-Site kann in Staging fertig aussehen und am Tag eins trotzdem scheitern. Formulare gehen ins Leere, Zertifikate laufen mitten in der Kampagne ab, Backups werden nie mit einem Restore-Test geprüft, und niemand weiß, wer den Hosting-Login besitzt, wenn um 21 Uhr etwas kaputtgeht.

Launch ist ein Operations-Gate. Design und Copy zählen, aber Go-Live heißt Evidenz, dass die Site online bleiben, Leads annehmen und ohne heldenhafte Vermutungen gewartet werden kann. Dieser Leitfaden führt durch eine WordPress-Launch-Checkliste für Business-Sites: Preflight-Ownership, Hosting, Security, Plugins, Backups, Performance, leichtes SEO und Measurement-Setup, Handoff und die ersten zwei Wochen nach dem DNS-Flip.

Preflight: Owner, Zugang und die Go-Live-Entscheidung

Bevor Sie DNS anfassen, schreiben Sie auf, wer welche Schicht besitzt. Business-Launches stocken, wenn Zugang in der Inbox eines Freelancers liegt und Billing auf einer privaten Karte, die nach Projektende niemand findet.

Benennen Sie Owner für Domain-Registrar, DNS, Hosting-Panel, WordPress-Admin, E-Mail (falls Mail auf derselben Domain liegt), Analytics, Search Console und Payment- oder CRM-Accounts. Bevorzugen Sie business-eigene E-Mails und geteilte Password-Vaults statt persönlicher Gmail-Forwards. Wenn eine Agentur die Site gebaut hat, entscheiden Sie schriftlich, ob sie nach Launch Admin-Zugang behält – und auf welchem Permission-Level.

Definieren Sie „fertig“, bevor Sie den Schalter umlegen. Eine brauchbare Go-Live-Leiste für ein Service-Business umfasst meist: HTTPS auf dem Live-Hostname, Homepage und zentrale Money-Pages ohne PHP-Fatals, Kontaktformular an eine überwachte Inbox oder CRM, Backups aktiv mit mindestens einem erfolgreichen Restore-Drill und kein Staging-URL- oder „Coming soon“-Plugin mehr aktiv auf Production.

Haftnotizen für Domain-, DNS-, Hosting-, WordPress-Admin- und Analytics-Owner vor dem DNS-Cutover.

Tipp: Legen Sie die Go-Live-Entscheidung in eine kurze geteilte Notiz. Wenn Marketing am Dienstag ankündigen will und Ops noch keinen Restore-Nachweis hat, ist Dienstag der falsche Tag.

Hosting und Environment-Bereitschaft

Hosting ist der Ort, an dem viele Geschichten „WordPress ist langsam / WordPress wurde gehackt“ wirklich starten. Für eine Business-Site wählen Sie einen Plan, der zu Traffic und Update-Gewohnheiten passt. Die billigste Shared-Box, die WordPress mit einem Klick installiert, ist selten dieser Plan.

Bestätigen Sie, dass PHP- und MySQL-Versionen dem entsprechen, was aktuelle WordPress-Requirements unterstützen. Schalten Sie automatische Security-Updates für WordPress Core ein, wenn Host oder Management-Workflow das sicher erlauben, und halten Sie einen Rollback-Pfad bereit, falls ein Update ein Custom-Theme bricht. HTTPS auf Host- oder Reverse-Proxy-Ebene erzwingen, damit Mixed-Content-Warnungen nicht erst erscheinen, nachdem Sie die URL in Slack teilen.

Prüfen Sie, dass die Production-Site die Live-Domain in WordPress Einstellungen → Allgemein nutzt (WordPress-Adresse und Website-Adresse). Staging-URLs hartcodiert in der Datenbank sind eine klassische Post-Migrations-Überraschung. Search-Replace bei Migration sorgfältig; blindes Find-Replace kann serialisierte Theme-Optionen zerbrechen.

Disk, Inodes und E-Mail-Versand zählen mehr als Broschüren-Claims zu „unlimited“. Formulare, die auf PHP mail() setzen, landen oft im Spam oder scheitern still. Bevorzugen Sie authentifiziertes SMTP über einen Transaktionsanbieter oder Ihre Workspace-Suite und senden Sie einen echten Test von der Live-Domain.

Check	Bestanden sieht so aus	Nicht bestanden sieht so aus
PHP / DB	Unterstützte Versionen laut WordPress-Docs	End-of-Life-PHP „weil das Theme läuft“
HTTPS	Gültiges Zertifikat auf dem Live-Hostname	Browser-Warnungen oder HTTP noch kanonisch
URLs	Website-Adresse entspricht Production	Staging-Subdomain noch in den Einstellungen
Mail	SMTP-Test landet in der Inbox	Formular „sendet“, aber nichts kommt an
Ressourcen	Spielraum für Media und Spikes	Disk nach einer Woche Uploads voll

Hosting-Bereitschaft als HTTPS, unterstütztes PHP, Datenbank-Gesundheit und Mail, die wirklich ankommt.

Wenn Sie eher rebuilden als eine brandneue Property launchen, behandeln Sie Migration als eigenes Projekt mit Redirects und Freeze-Fenster. Ein sauberes WordPress-Setup-Engagement fixiert Environment-Entscheidungen meist vor Design-Politur, damit Launch-Woche nicht mit Host-Streitungen verbracht wird.

Security-Baseline, bevor die öffentliche URL live ist

Sie brauchen am Tag eins keine Festung. Sie brauchen Defaults, die die langweiligen Angriffe stoppen, die jedes freiliegende wp-login.php treffen.

Nutzen Sie einzigartige, starke Admin-Passwörter und hören Sie auf, einen einzelnen „admin“-Account über das ganze Team zu teilen. Legen Sie rollengerechte User an (Administrator, Editor, Autor) und entfernen Sie ungenutzte Accounts von Freelancern. Bevorzugen Sie einen Custom-Admin-Username und halten Sie den Default-admin-Account weg, falls er je existiert hat.

Halten Sie WordPress Core, Themes und Plugins vor Launch aktualisiert. Warten bis „nach der Kampagne“ ist, wie bekannte CVEs eine öffentliche Homepage treffen. Ungenutzte Themes und Plugins löschen statt deaktiviert liegen lassen; deaktivierter Code liegt weiter auf Disk. Login-Versuche limitieren oder Login hinter Host-Schutz legen, wenn der Provider das anbietet. Dateirechte für das Host-Modell prüfen und sicherstellen, dass wp-config.php nicht world-readable ist.

Schalten Sie eine Web Application Firewall nur ein, wenn Sie verstehen, was sie blockiert. Fehlkonfigurierter Bot-Schutz kann legitime Crawler und Ihr eigenes Monitoring blockieren. Zwei-Faktor-Authentifizierung für Administrator-Accounts lohnt die Reibung auf jeder Site, die Leads oder Payments annimmt.

Warnung: Lassen Sie WP_DEBUG auf Production nicht aktiv. Debug-Output kann Pfade und Plugin-Internals in HTML oder Logs leaken, die Besucher nie sehen sollten.

Day-one-Security als starke Accounts, Updates, Login-Reibung und abgesicherte Dateien.

Prüfen Sie die WordPress-Hardening-Guidance für Ihren Stack und wenden Sie nur an, was Sie warten können. Eine halbfertige „Security Suite“ mit widersprüchlichen Firewall-Regeln ist schlechter als eine kurze, owned Checkliste.

Plugin-Disziplin beim Launch

Plugins machen WordPress zum Business-Tool. Sie sind auch, wie Sites Konflikt, Gewicht und abandoned Code ansammeln.

Inventarisieren Sie jedes aktive Plugin und schreiben Sie einen Satz, warum es existiert. Duplikate mergen (zwei SEO-Plugins, zwei Formular-Plugins, zwei Cache-Schichten). Bevorzugen Sie gut gewartete Plugins mit klarem Update-Rhythmus gegenüber „free forever“-Klonen ohne Support-Pfad. Page Builder können für redaktionelle Flexibilität in Ordnung sein; sie werden zur Haftung, wenn jede Landingpage ein einzigartiger Schneeflocke ohne geteilte Templates ist.

Demo-Content-Importer, Migrationshelfer und „Coming soon“-Tools auf Production deaktivieren oder entfernen. Alles, was URLs umschreiben oder Rewrites flushen kann, bewusst nutzen, dann entfernen oder absichern.

Plugin-Klasse	Launch-Regel
Formulare	Ein primärer Formular-Stack; jedes Ziel testen
SEO	Ein SEO-Plugin oder Framework; keine konkurrierenden Sitemaps
Cache / Optimize	Ein Caching-Ansatz, abgestimmt auf den Host
Security	Ein kohärenter Stack; überlappende Firewalls vermeiden
Backup	Unabhängig vom Theme; Restore getestet
Builder	Geteilte Templates; keine abandoned Demo-Seiten

Aktive Plugins vor Go-Live in Behalten, Mergen und Entfernen sortiert.

Häufiger Fehler: Ein „Performance“-Plugin installieren, das CSS minifiziert, während der Host schon minifiziert und ein CDN schon Bilder optimiert. Einen Owner für Caching wählen und dokumentieren.

Backups, die Sie wirklich restore können

Ein Backup, das Sie nie restored haben, ist eine Hoffnungsdatei. Business-Sites brauchen einen Schedule, eine Offsite-Kopie und einen Restore-Drill, bevor Marketing-Spend die URL trifft.

Entscheiden Sie, was Sie backen (Dateien, Datenbank oder beides), wie oft und wo Kopien liegen. Hosting-Snapshots sind nützlich; sie sollten nicht die einzige Kopie sein, wenn ein Billing-Streit oder Account-Compromise das Panel wischen kann. Mindestens ein aktuelles Backup außerhalb des Primär-Hosts halten.

Vor Launch einen Restore in eine disposable Staging-Umgebung fahren. Zeit messen. Notieren, welche Credentials und DNS-Tricks nötig waren. Wenn Restore einen halben Tag und undokumentiertes SSH braucht, den Prozess fixen, solange die Site noch ruhig ist.

Nach Launch bestätigen, dass Backups auf dem Live-Hostname weiterlaufen und Cron oder der Host-Scheduler nicht auf Staging zeigen. Dokumentieren, wer die Failure-Mail bekommt, wenn ein Backup-Job stirbt.

Dateien und Datenbank fließen zu Offsite-Storage, mit explizitem Restore-Test-Schritt.

Best Practice: Den Restore-Drill in derselben Woche wie den DNS-Cutover kalendern. Einen fehlgeschlagenen Drill als Launch-Blocker behandeln.

Performance, bevor Sie Traffic kaufen

Langsame First Loads verbrennen Paid Ads und Sales-Demos. Sie brauchen keinen perfekten Lighthouse-Score, um eine Broschüren-Site zu launchen, aber Sie sollten wissen, wie sich Money-Templates auf einem Mid-Range-Phone auf gewöhnlichem WLAN anfühlen.

Homepage, eine zentrale Service- oder Produktseite und den Kontakt- oder Checkout-Pfad messen. Hero-Bilder vor Upload komprimieren und resizen; nicht auf ein Plugin setzen, das ein 4-MB-PNG rettet. Nicht-kritische Scripts deferen, wo das Theme es erlaubt. Am Tag eins nicht drei Analytics-Tags, Chat-Widget, Heatmap-Tool und Popup stapeln, es sei denn, jedes hat Owner und Measurement-Job.

Bei CDN bestätigen, dass die Live-Domain korrekt angebunden ist und jemand im Team Cache-Purge ausführen kann. Nach Deploy purgen, damit Editoren nicht einen Nachmittag „ich habe es aktualisiert, aber die Site zeigt noch das alte Logo“ hinterherlaufen.

Caching-Plugins und Host-Level-Page-Cache sollten sich nicht bekämpfen. Den einzelnen Pfad für „ich brauche jetzt eine frische Seite“ dokumentieren.

Launch-Performance als Bildgewicht, ein Caching-Pfad und ein Phone-Smoke-Test.

Core Web Vitals und tiefere Crawl-Themen können auf einen fokussierten Pass warten, wenn die Site stabil ist. Wenn organische Suche schon ein Growth-Kanal ist, technischen Review separat schedulen statt ein volles Audit in die Launch-Nacht zu stopfen.

SEO-Basics, die zum Go-Live gehören

Launch-SEO heißt, sich nicht selbst ins Bein zu schießen. Es ersetzt keine laufende Content- und Technikarbeit.

Bestätigen Sie, dass die Site auf Production indexierbar ist (Einstellungen → Lesen entmutigt Suchmaschinen nicht). Passwortschutz und Basic-Auth vom öffentlichen Hostname entfernen. Eine saubere XML-Sitemap in der Google Search Console einreichen, sobald die Live-Domain verifiziert ist. Bevorzugte URL-Form wählen (www oder non-www, Trailing-Slash-Policy) und Redirects konsistent halten.

Jede Money-Page braucht einen einzigartigen Title und eine Meta Description, die ein Mensch anklicken würde. Die Homepage-H1 sollte das Business-Angebot nennen. „Willkommen“ der Intranet überlassen. Organization- oder LocalBusiness-Schema nur, wenn die Daten korrekt und gepflegt sind; falsches NAP in JSON-LD erzeugt später Cleanup-Arbeit.

Bei Migration von einer alten Site vor der Ankündigung eine Redirect-Map für High-Traffic- und High-Conversion-URLs ausliefern. Soft-Launch ohne Redirects ist, wie Rankings und Bookmarks in derselben Woche sterben.

Indexierbare Production, Sitemap-Submission, Titles und Redirects als Launch-SEO-Boden.

Halten Sie diesen Abschnitt absichtlich dünn. Tiefe Crawl-, Canonical- und Core-Web-Vitals-Arbeit verdient einen eigenen Pass, sobald die Ops-Checkliste grün ist.

Formulare, Analytics und Conversion-Plumbing

Eine Business-Site, die keinen Lead annehmen kann, ist noch ein Draft. Jedes öffentliche Formular auf der Live-Domain mit echter Submission testen. Thank-you-State, Notification-Mail, CRM- oder Spreadsheet-Ziel und Spam-Filter prüfen, der Kunden nicht still droppt.

Privacy-Erwartungen für Ihre Region prüfen. Cookie-Banner und Consent-Tools sollten dazu passen, wie Sie Analytics und Ads-Pixel tatsächlich laden. Kaputte Consent-UX, die das Formular blockiert, ist ein Launch-Defekt.

Analytics mit dokumentierter Property-ID und Access-Liste installieren. Launch-Datum in den Notizen markieren, damit späteres Reporting ein klares Before/After hat. Bei Google Analytics oder einer privacy-first Alternative Real-time-Hits aus einer Incognito-Session auf Production verifizieren. Search-Console-Verifizierung gehört ebenfalls hierher, damit Coverage-Themen früh sichtbar werden.

Chat-Widgets, Scheduler und Payment-Buttons bekommen dieselbe Behandlung wie Formulare. Ein fehlgeschlagenes Calendly-Embed auf der „Call buchen“-Seite kostet mehr als eine Woche Copy-Tweaks.

Lead-Pfad vom Formular zu Inbox oder CRM, mit Analytics und Search Console angebunden.

Zentrale Erkenntnis: Conversion-Plumbing ist Teil der Launch-QA. Design-Review ersetzt keinen geloggten Test-Lead mit Timestamp.

Saubere Übergabe nach Go-Live

Handoff ist, wo Freelance- und Agenturprojekte still scheitern. Die Site ist live, Rechnungen bezahlt, und institutionelles Wissen geht mit dem Builder weg.

Liefern Sie ein kurzes Operations-Paket. Hosting- und DNS-Login-Orte (keine Passwörter in E-Mail), WordPress-Admin-URL, wie man eine neue Seite aus dem Standard-Template anlegt, wie man Cache purgt, Backup-Schedule und Restore-Kontakt, Plugin-Liste mit Zweck-Notizen und wen man in den ersten 30 Tagen bei Notfällen anruft.

Den Editor auf dem Workflow trainieren, den er wöchentlich nutzt. Ein 40-minütiges Loom zu „Service-Seite hinzufügen“ und „Homepage-Hero aktualisieren“ schlägt einen generischen WordPress-Kurs. Temporäre Admin-Accounts entfernen, wenn Training endet.

Kommerzielle Erwartungen abstimmen. Laufende Updates, Security-Monitoring und kleine Content-Edits sind Maintenance. Neue Templates, Checkout-Redesigns und Migrationen sind Projekte. Wenn Sie nach Launch retained Care brauchen, sagen Sie das explizit statt zu hoffen, „ein kurzer Blick“ decke Ransomware-Woche ab.

Operations-Paket, Editor-Walkthrough und definiertes Support-Fenster nach Cutover.

Praxisbeispiel für eine regionale Service-Firma

Stellen Sie sich eine 12-Seiten-Site für eine regionale Professional-Services-Firma vor. Staging wirkte poliert. Launch-Woche brauchte trotzdem eine Checkliste mit Biss.

Montag füllte das Ownership-Sheet. Domain und DNS lagen beim IT-Contractor der Firma. Hosting und WordPress-Admin beim Web-Partner. Analytics nutzte ein Firmen-Google-Konto statt dem persönlichen Login des Designers.

Dienstag bestätigte Hosting auf aktuellem PHP, stellte das HTTPS-Zertifikat für Apex und www aus und verband SMTP mit dem Workspace der Firma. Ein Search-Replace fixte drei interne Links, die noch auf die Staging-Subdomain zeigten.

Mittwochs Security-Pass entfernte zwei ungenutzte Builder-Demo-Plugins, rotierte das geteilte Admin-Passwort in individuelle Editor-Accounts und aktivierte 2FA für Administratoren. Das Backup-Plugin schrieb zu Offsite-Storage, und ein Restore in eine Wegwerf-Subdomain gelang in unter einer Stunde.

Donnerstag erledigte den Image-Pass am Homepage-Hero und Teamfotos, dokumentierte einen Caching-Pfad und testete Formulare an Inbox der Office Managerin und CRM. Eine Notification-Regel war noch auf der Staging-Adresse und wäre still gescheitert.

Freitagmorgen verifizierte Search Console, reichte die Sitemap ein und uncheckte „Suchmaschinen abschrecken“. Redirects für fünf alte Service-URLs der vorherigen Broschüren-Site gingen raus. Soft Launch nur an Staff.

Freitagmittag zahlte sich der frühere DNS-TTL-Drop aus. Cutover, CDN purgen, Formulare auf dem öffentlichen Hostname erneut testen. Die Handoff-Notiz ging mit Editor-Loom und zweiwöchigem Hypercare-Fenster für Break/Fix raus.

Diese Sequenz ist gewöhnlich. Sicher machte sie Evidenz an jedem Gate. Ein schickeres Theme hätte diese Checks nicht ersetzt.

Eine fünftägige Launch-Woche mit Ownership-, Hosting-, Security-, QA- und Cutover-Gates.

Erste zwei Wochen nach Launch

Post-Launch ist, wenn echte Nutzer und Bots Annahmen stressen. Hosting-Ressourcen-Graphs, Error-Logs und Formular-Notification-Failures in der ersten Woche täglich beobachten. Bestätigen, dass Backups auf der Live-Site weiter gelingen. Search Console auf Coverage- oder Security-Meldungen prüfen, sobald Daten fließen.

Content-Edits erwarten. Editoren pasten aus Docs, laden übergroße Bilder hoch und installieren „nur ein Plugin“, wenn Permissions es erlauben. Kurzes Change-Log für das Hypercare-Fenster führen, damit Sie „wir haben X installiert“ mit „Formulare brachen am Dienstag“ korrelieren können.

Wenn Paid Campaigns sofort starten, UTM-Konventionen und Landingpage-Cache-Verhalten abstimmen, bevor Spend skaliert. Eine gecachte Thank-you-Seite, die noch das Formular zeigt, verwirrt Nutzer und Attribution.

Hypercare-Loop, der nach Go-Live Logs, Backups, Formulare und Search Console beobachtet.

Den nächsten Ops-Meilenstein planen, solange der Launch frisch ist. Monatliche Updates, ein quartalsweiser Restore-Drill und ein tieferer SEO- oder Conversion-Pass, sobald Traffic-Muster real sind, gehören in den Kalender. Launch-Vollständigkeit und langfristiges Wachstum sind unterschiedliche Jobs.

Häufig gestellte Fragen

Wann sollten wir DNS relativ zu Content-Freezes flippen?

Strukturelle und Plugin-Änderungen 24–48 Stunden vor Cutover einfrieren, wenn möglich. Copy-Tweaks auf bestehenden Seiten sind meist in Ordnung. Große Theme- oder Builder-Änderungen mitten im Cutover machen es schwer, DNS-Lag von einer echten Regression zu unterscheiden.

Brauchen wir Staging für immer?

Staging behalten, wenn Sie Plugins monatlich updaten oder nicht-triviale Theme-Änderungen ausliefern. Winzige Broschüren-Sites, die selten ändern, können manchmal mit Host-Level-Staging on demand leben. Die Regel ist einfach: Wenn Sie sich einen Tag kaputte Homepage nicht leisten können, behalten Sie einen Ort zum Testen von Updates.

Ist ein Page Builder für einen Business-Launch okay?

Ja, wenn das Team tatsächlich in geteilten Templates editiert und jemand Updates besitzt. Teuer wird es, wenn jede Seite ein One-off ist und Builder, Theme und „Helper“-Plugins alle koordinierte Updates brauchen. Das Editing-Modell vor Launch entscheiden. Warten bis zur ersten kaputten Homepage kostet eine Support-Woche.

Was ist die minimale Backup-Policy für eine Lead-Gen-Site?

Tägliche Datenbank-Backups, regelmäßige Full-Site-Backups, eine Offsite-Kopie und ein Restore-Test vor Go-Live. Frequenz erhöhen, wenn Sie den ganzen Tag publishen oder Orders annehmen. Hosting-Snapshots allein sind Single Point of Failure, wenn das Panel der Incident ist.

Sollten Security-Plugins Hosting-Firewalls ersetzen?

Sie lösen unterschiedliche Schichten. Host- und Netzwerk-Controls stoppen viel Rauschen, bevor PHP läuft. Application-Level-Plugins helfen bei Login-Missbrauch und File Integrity. Überlappende Produkte, die beide .htaccess umschreiben oder jeden Besucher challengen, erzeugen Support-Tickets. Einen Stack wählen und dokumentieren.

Wie technisch sollte der Client-Handoff sein?

Technisch genug, dass der Client Zugang wiederherstellen und Routine-Edits ohne Sie machen kann. Nicht so dicht, dass es ein ungelesenes PDF wird. Login-Map, Editing-Workflow, Backup-Kontakte und Eskalationspfad schlagen ein 40-Seiten-Manual.

Können wir ohne Search Console launchen?

Ja, aber Sie fliegen blind bei Indexierung und Security-Notices. Verifizierung ist billig relativ zu einer Woche „warum tauchen wir nicht auf“. Während Launch-Woche erledigen, wenn Google-Suche fürs Business überhaupt zählt.

Was gehört in Hypercare versus ein neues Projekt?

Hypercare deckt Defekte aus Build und Launch-Konfiguration ab. Neue Seiten-Templates, neue Integrationen und Redesigns sind neuer Scope. Diese Grenze aufschreiben, damit Goodwill nicht zu unbezahlter Produktarbeit wird.

Das Gate schließen, dann die Lichter anlassen

Eine WordPress-Launch-Checkliste für eine Business-Site ist wirklich eine Evidenz-Checkliste. Owner benannt, Hosting zweckmäßig, Security-Defaults gesetzt, Plugins begründet, Backups einmal restored, Performance gut genug für echte Phones, SEO nicht selbstsabotiert, Formulare bewiesen und ein Handoff, den Leute nutzen.

Wenn diese Gates grün sind, kann Marketing spendieren und Editoren publishen, ohne Ops unter Druck zu erfinden. Wenn sie gelb sind, die Ankündigung verzögern. Die URL wartet; ein öffentlicher Failure nicht.

Wenn Sie Hilfe wollen, daraus einen konkreten Go-Live-Plan oder einen sauberen Build vor dem DNS-Flip zu machen, melden Sie sich über das Kontaktformular.