10 WordPress Staging Best Practices, die Katastrophen auf der Live-Website verhindern

Sie aktualisieren ein Plugin auf Ihrer Live-Website, weil es nur 30 Sekunden dauert. Dann ist Ihre Homepage leer.

Es ist fast jedem WordPress-Website-Besitzer irgendwann passiert.

Ein schnelles Update, eine kleine Änderung, ein „Das wird schon gut gehen“-Moment, der nicht gut ging. Und jetzt starren Sie auf einen weißen Bildschirm, während echte Besucher versuchen, Ihre Website zu erreichen.

Das ist das Problem, das eine Staging-Umgebung löst. Es ist eine private Kopie Ihrer Live-Website, auf der Sie Änderungen testen, bevor sie in die Produktion gelangen. Wenn auf Staging etwas schiefgeht, sehen es nur Sie.

Die meisten Gelegenheitsnutzer von WordPress wissen, dass Staging existiert. Die meisten überspringen es auch, weil es nach zusätzlicher Arbeit klingt.

Ich verstehe das. Aber nachdem ich einen WooCommerce-Checkout mitten im Sale wegen eines Plugin-Konflikts abstürzen sah, den man auf Staging in zwei Minuten hätte erkennen können, habe ich aufgehört, es als optional zu betrachten.

In diesem Beitrag zeige ich Ihnen, was eine Staging-Umgebung ist, wann Sie eine benötigen, wie Sie schnell eine einrichten und welche Praktiken das Staging überhaupt erst lohnenswert machen.

Hier sind die wichtigsten Erkenntnisse:

• Staging ist nicht für jede Änderung gedacht. Kleinere Bearbeitungen wie Tippfehler, Preisaktualisierungen und neue Beiträge erfordern keinen Staging-Workflow.
• Tests mit einer wochenalten Kopie Ihrer Website liefern unzuverlässige Ergebnisse. Das Aktualisieren von Staging vor jeder Änderungsrunde behebt dies vollständig.
• Das Übertragen der gesamten Datenbank von Staging in die Produktion zerstört Live-Inhalte. Bestellungen, Formulareingaben und Benutzerregistrierungen, die auf der Produktion eingingen, während Sie an Staging arbeiteten, werden überschrieben. Übertragen Sie Code, nicht die Datenbank.
• Eine ungeschützte Staging-Umgebung schadet dem SEO Ihrer Live-Website. Passwortschutz und Noindex-Einstellungen sind nicht verhandelbar.
• Der Debug-Modus auf Staging deckt Fehler auf, die auf der Produktion verborgen sind. PHP-Hinweise und Warnungen, die auf Ihrer Live-Website stillschweigend existieren, werden hier zuerst angezeigt.
• Das Aktualisieren eines Plugins nach dem anderen ist der einzige zuverlässige Weg, einen Konflikt zu verfolgen. Massenaktualisierungen machen es unmöglich zu identifizieren, welche Änderung ein Problem verursacht hat.
• Das Backup vor dem Push macht eine fehlerhafte Bereitstellung wiederherstellbar.
• Alte Staging-Umgebungen werden zu Sicherheitsrisiken. Löschen Sie sie, wenn Sie fertig sind.

Inhaltsverzeichnis

Staging ist kein Backup. Wenn Ihre Live-Website abstürzt, können Sie nicht von Staging wiederherstellen.

Sie dienen unterschiedlichen Zwecken: Backups sind Ihr Wiederherstellungstool; Staging ist Ihre Testumgebung.

Staging ist auch nicht dasselbe wie eine lokale Entwicklungsumgebung. Eine lokale Umgebung läuft auf Ihrem Computer, offline, getrennt von realen Serverbedingungen.

Staging läuft auf einem tatsächlichen Server mit einer echten URL, sodass es widerspiegelt, wie sich Ihre Website in der Produktion tatsächlich verhält.

Wenn Sie einen vollständigen Neuaufbau durchführen oder eine Website von Grund auf neu starten möchten, sind lokale Tools wie XAMPP, WAMP oder MAMP sinnvoll. Zum Testen von Updates und Änderungen im Vergleich zum tatsächlichen Serververhalten ist Staging die zuverlässigere Option.

Und Staging ist keine dauerhafte zweite Website. Es ist eine temporäre Arbeitsumgebung. Sie nehmen Änderungen vor, testen sie, pushen, was funktioniert, und setzen zurück oder aktualisieren, wenn Sie die nächste Runde beginnen.

Wann Sie eine Staging-Umgebung verwenden sollten (und wann Sie sie überspringen können)

Jeder Beitrag über Staging wird Ihnen sagen, dass Sie es für alles verwenden sollen. Das ist nicht realistisch, und die Befolgung dieses Ratschlags führt zu Prozessermüdung, bei der Sie Staging schließlich ganz einstellen, auch für die Änderungen, die es tatsächlich benötigen.

Hier ist eine ehrlichere Einschätzung.

Änderungen, die Staging rechtfertigen

Dies sind die Situationen, in denen etwas schiefgeht auf einer Live-Website echte Konsequenzen hat: verlorene Verkäufe, defekte Formulare, ausgesperrte Benutzer oder eine Homepage, die nicht geladen wird.

Der Zeitaufwand für Staging ist nichts im Vergleich zu den Wiederherstellungskosten, wenn eine dieser Situationen schiefgeht.

• WordPress Core-Updates, insbesondere Major-Versionen
• Plugin- oder Theme-Updates, insbesondere WooCommerce, Page Builder und Sicherheits-Plugins
• Jede Änderung an Ihrer PHP-Version oder Serverkonfiguration
• Hinzufügen eines neuen Plugins, das den Checkout, Formulare oder die websiteweite Funktionalität beeinflusst
• Benutzerdefinierter Code oder CSS-Änderungen, die Vorlagen oder Theme-Dateien berühren
• Vollständige Neugestaltungen oder signifikante Layoutänderungen

Änderungen, die kein Staging benötigen

Staging hat einen Mehraufwand. Einen Klon erstellen, eine Änderung vornehmen und ihn zurückpushen: das ist Overkill für Bearbeitungen, die kein echtes Risiko bergen.

• Tippfehler beheben oder einen Preis aktualisieren
• Einen neuen Blogbeitrag veröffentlichen oder ein Produkt hinzufügen
• Einen Menüpunkt austauschen oder ein Widget anpassen
• Kleine Bildaktualisierungen ohne Codeabhängigkeit

Wenn etwas in dieser Liste Ihre Website irgendwie kaputt gemacht hätte, würde die Behebung weniger Zeit in Anspruch nehmen als die Staging-Einrichtung. Sparen Sie den Prozess für Zeiten, in denen er sich lohnt.

So richten Sie eine WordPress-Staging-Umgebung ein

Wenn Ihr Hoster integriertes Staging anbietet, ist das ein vernünftiger Ausgangspunkt. WP Engine, Kinsta und SiteGround integrieren es in ihre Dashboards.

Wenn Ihr Hoster es nicht anbietet (oder Sie etwas wollen, das unabhängig davon, wo Ihre Website gehostet wird, auf die gleiche Weise funktioniert), ist Duplicator Pro das, was ich benutze.

Es verwandelt jedes vollständige Website-Backup mit wenigen Klicks in eine Staging-Website. Sie benötigen kein separates Hosting-Konto, kein FTP und keine manuelle Datenbankarbeit.

Sie beginnen mit der Erstellung eines vollständigen Backups Ihrer Website.

Gehen Sie dann zu Staging » Erste Staging-Website erstellen.

Wählen Sie das von Ihnen erstellte Backup als Vorlage für die Staging-Site. Achten Sie darauf, auch ein eindeutiges Admin-Farbschema auszuwählen, damit Ihr Staging-Dashboard immer anders aussieht.

Duplicator installiert das Backup als komplett neue Staging-Site. Alle hier vorgenommenen Änderungen wirken sich nicht auf Ihre echte Website aus.

Der manuelle Weg ist ebenfalls eine Option: Konfigurieren Sie ein Subdomain oder Unterverzeichnis, übertragen Sie Dateien per FTP, duplizieren Sie die Datenbank in phpMyAdmin, aktualisieren Sie Ihre wp-config.php-Zugangsdaten und synchronisieren Sie URLs in der wp_options-Tabelle. Es funktioniert, aber es gibt viele Schritte, bei denen man Fehler machen kann.

Weitere Staging-Methoden finden Sie in unserem Beitrag So erstellen Sie eine WordPress-Staging-Site.

10 WordPress-Staging-Best-Practices, die jeder Website-Besitzer befolgen sollte

Das Einrichten von Staging ist der einfache Teil. Hier sind einige Best Practices für WordPress-Staging, um häufige Fehler zu vermeiden:

• Beginnen Sie immer mit einem frischen Backup. Ihr Wiederherstellungspunkt, falls die Staging-Einrichtung fehlschlägt oder eine übernommene Änderung die Live-Site beschädigt.
• Private, Index-blockierte, separate Datenbank. Drei verschiedene Einstellungen, die jeweils eine andere Art von Schaden verhindern.
• Spiegeln Sie Ihre Produktionsumgebung. PHP-Version, Servertyp, Caching-Ebenen und Firewall-Regeln sollten mit der Produktion übereinstimmen, sonst können Ihre Testergebnisse nicht vertrauenswürdig sein.
• Aktivieren Sie den Debug-Modus. Zeigt PHP-Fehler im Staging an, die standardmäßig auf Ihrer Live-Site ausgeblendet werden.
• Eine Aktualisierung nach der anderen. Der einzige Weg, einen Konflikt auf die spezifische Änderung zurückzuführen, die ihn verursacht hat.
• Staging als letztes QA-Gate. Ein vollständiger Testlauf, der Navigation, Formulare, Checkout, mobile Geräte und Seitengeschwindigkeit abdeckt, bevor etwas live geht.
• Code zur Produktion, nicht zur Datenbank. Das Übernehmen der gesamten Datenbank überschreibt Live-Inhalte, die während Ihrer Arbeit im Staging angekommen sind.
• Vor jeder Runde aktualisieren. Veraltetes Staging liefert unzuverlässige Ergebnisse. Ziehen Sie vor jeder neuen Änderungsgruppe aus der Produktion.
• Produktion vor dem Übernehmen sichern. Unmittelbar vor der Bereitstellung, nicht am Vortag.
• Regelmäßige Bereinigung. Löschen Sie alte Staging-Umgebungen, wenn Sie fertig sind, um Verwirrung und Sicherheitslücken zu vermeiden.

1. Beginnen Sie immer mit einem frischen Backup

Bevor Sie eine Staging-Umgebung erstellen, erstellen Sie ein vollständiges Backup Ihrer Produktions-Site. Wenn die Staging-Einrichtung schiefgeht, haben Sie einen sauberen Wiederherstellungspunkt.

Wichtiger noch, dieses Backup wird zu Ihrer Wiederherstellungsoption, wenn Sie Änderungen übernehmen, die etwas auf der Live-Site kaputt machen.

Wenn Sie eine Staging-Site mit Duplicator erstellt haben, haben Sie bereits ein frisches Backup Ihrer Site. Das ist der erste Schritt des Staging!

Während Sie das Backup erstellen, empfehle ich, mindestens eine Kopie in die Cloud zu senden. Duplicator Cloud bietet Ihnen ein Off-Site-Wiederherstellungs-Dashboard, falls etwas mit Ihrer echten Website passiert.

2. Halten Sie Staging privat, blockieren Sie die Indizierung und verwenden Sie eine separate Datenbank

Beginnen Sie mit Passwortschutz. Ihre Staging-URL sollte niemals öffentlich zugänglich sein, Punkt.

Jeder, der darauf landet, sieht eine unfertige, potenziell fehlerhafte Version Ihrer Website. Die meisten Hoster und Staging-Plugins erledigen dies automatisch, aber überprüfen Sie es selbst, anstatt es anzunehmen.

Suchmaschinen blockieren ist ein separater Schritt und genauso wichtig. Gehen Sie zu Einstellungen » Lesen in Ihrem Staging-WordPress-Dashboard und aktivieren Sie Suchmaschinen davon abhalten, diese Website zu indizieren.

Duplicator sollte dies automatisch tun, aber es schadet nicht, es zu überprüfen.

Eine nicht blockierte Staging-Site kann indiziert werden. Google unterscheidet nicht immer zwischen Staging und Produktion, wenn die URL zugänglich ist, und der SEO-Schaden durch doppelte Inhalte kann die Rankings Ihrer Live-Site monatelang beeinträchtigen.

Die Datenbankregel ist anders, aber genauso wichtig. Teilen Sie niemals eine Datenbank zwischen Ihrer Live-Site und Staging.

Eine gemeinsam genutzte Datenbank bedeutet, dass eine Staging-Aktion wie ein versehentliches Speichern oder eine Konfigurationsänderung echte Produktionsdaten überschreiben kann. Sie könnten Bestellungen, Formularübermittlungen, Benutzerkonten oder veröffentlichte Inhalte verlieren.

Halten Sie die Datenbanken vollständig getrennt. Die meisten Staging-Setups handhaben dies standardmäßig, aber wenn Sie ein manuelles Setup durchführen, ist dies die eine Sache, die es wert ist, vor dem Start noch einmal überprüft zu werden.

3. Spiegeln Sie Ihre Produktionsumgebung so genau wie möglich

Der Sinn von Staging ist es, zu testen, was auf Ihrer Live-Site passieren wird. Wenn Staging nicht mit der Produktion übereinstimmt, sind die Testergebnisse nicht sehr aussagekräftig.

Die PHP-Version ist die häufigste Diskrepanz. Wenn Ihre Staging-Umgebung PHP 8.1 ausführt und die Produktion PHP 8.3, kann ein Plugin, das auf Staging einwandfrei funktioniert, auf der Live-Site Fehler verursachen.

Stellen Sie sicher, dass beide Umgebungen dieselbe Version ausführen, bevor Sie etwas testen. Möglicherweise müssen Sie die PHP-Version einer Website aktualisieren.

Wenn Sie Duplicator zum Erstellen von Staging-Sites verwenden, erstellen Sie eine neue, bevor Sie eine neue Testrunde starten. Eine alte Umgebung ist keine genaue Kopie Ihrer Website.

Löschen Sie die alte Staging-Site, generieren Sie eine frische Kopie Ihrer Website und verwenden Sie diese, um eine neue Staging-Site zu erstellen.

Die gleiche Logik gilt für Ihren Webserver. Apache und Nginx behandeln bestimmte Konfigurationen unterschiedlich. Wenn die Umgebungen unterschiedlich sind, können Sie Fehler erhalten, die wirklich schwer zu verfolgen sind.

Caching-Ebenen sind ebenfalls wichtig, insbesondere für Leistungstests. Wenn die Produktion Redis oder Memcached verwendet und Staging nicht, spiegeln die auf Staging durchgeführten Seitengeschwindigkeits-Benchmarks keine realen Bedingungen wider.

Spiegeln Sie die Caching-Einrichtung sowie Ihre Firewall- und Sicherheitsregeln. Ein Sicherheits-Plugin oder eine WAF-Regel, die in der Produktion aktiv ist, aber nicht im Staging, kann Konflikte verursachen, die Sie erst nach der Bereitstellung entdecken.

Je enger die Übereinstimmung, desto mehr können Sie dem vertrauen, was Ihnen Staging sagt.

4. Aktivieren Sie den Debug-Modus auf Staging

WordPress blendet PHP-Fehler in der Produktion standardmäßig aus. Das ist die richtige Entscheidung für eine Live-Site, da Sie nicht möchten, dass Besucher rohe Fehlermeldungen sehen. Aber es bedeutet auch, dass Probleme auf Ihrer Website ohne sichtbares Zeichen bestehen können.

Staging ist der Ort, an dem Sie sie aufdecken, und das können Sie mit WordPress-Debugging tun.

Fügen Sie define('WP_DEBUG', true); zu Ihrer wp-config.php-Datei in der Staging-Umgebung hinzu. Dies aktiviert die Fehlerberichterstattung und zeigt PHP-Hinweise und Warnungen an, die sonst verborgen bleiben würden.

Wenn ein Plugin-Update eine Deprecation Warning einführt oder eine Theme-Funktion einen Fehler auslöst, sehen Sie dies auf der Staging-Umgebung, bevor es Ihre Live-Website erreicht.

Es lohnt sich auch, WP_DEBUG_LOG daneben zu aktivieren. Dies schreibt Fehler in eine debug.log-Datei in Ihrem wp-content-Ordner, sodass Sie eine Aufzeichnung zum Überprüfen haben, anstatt Fehler in Echtzeit erfassen zu müssen.

Lassen Sie den Debug-Modus auf der Produktionsumgebung deaktiviert. Die Einstellungen gelten nur für die Staging-Umgebung.

5. Aktualisieren Sie jeweils nur eine Sache

Wenn Sie sechs Plugin-Updates warten, möchten Sie vielleicht alle auswählen und alles auf einmal aktualisieren. Das ist schneller, aber wenn nach einem Massenupdate etwas schiefgeht, wissen Sie nicht, welches Plugin es verursacht hat.

Aktualisieren Sie einzeln. Führen Sie nach jeder Aktualisierung eine schnelle Überprüfung durch.

Laden Sie die Homepage, klicken Sie sich durch ein paar Seiten und stellen Sie sicher, dass nichts Offensichtliches kaputt gegangen ist. Aktualisieren Sie dann das nächste.

Das verlängert den Prozess um ein paar Minuten, gibt Ihnen aber eine klare Übersicht darüber, was wann geändert wurde, wenn etwas schiefgeht.

Dies gilt auch für WordPress-Core-Updates. Wenn Sie Core und mehrere Plugins in derselben Sitzung aktualisieren, aktualisieren Sie zuerst den Core, testen Sie ihn und arbeiten Sie sich dann einzeln durch die Plugins.

Ein Konflikt zwischen einem wichtigen Core-Update und einem bestimmten Plugin ist viel einfacher zu diagnostizieren, wenn Sie nicht mehrere Dinge gleichzeitig geändert haben.

6. Nutzen Sie Staging als Ihr letztes QA-Gate vor jedem Push

Staging ist nicht nur ein Ort, um mit Änderungen zu experimentieren. Es ist die obligatorische letzte Überprüfung, bevor etwas Ihre Live-Website berührt.

Führen Sie vor dem Übertragen von Änderungen einen vollständigen Testlauf durch. Das bedeutet mehr als nur die Überprüfung der Seite, die Sie gerade aktualisiert haben.

Hier sind einige wichtige Schritte, die Sie unternehmen sollten:

• Klicken Sie sich durch Ihre Hauptnavigation auf Desktop und Mobilgeräten.
• Senden Sie alle Formulare, die die Website verwendet, einschließlich Kontaktformulare, Newsletter-Anmeldungen und alles, was an einen Drittanbieter-Dienst weitergeleitet wird.
• Wenn Sie WooCommerce verwenden, durchlaufen Sie den vollständigen Checkout-Ablauf: In den Warenkorb legen, zur Kasse gehen, bezahlen.
• Überprüfen Sie Ihre Seitenladezeit mit Google PageSpeed Insights und vergleichen Sie sie mit Ihrer Baseline.
• Betrachten Sie die Seiten, die Ihre Änderung beeinflussen sollte, und einige Seiten, die sie überhaupt nicht berühren sollte.

Konflikte treten nicht immer dort auf, wo Sie es erwarten. Ein Plugin-Update, das Ihren Checkout beeinflusst, bricht möglicherweise nicht visuell die Checkout-Seite, kann aber stillschweigend Bestellbestätigungs-E-Mails beschädigen.

Zehn Minuten gründliches Klicken fangen das auf, was eine Fünf-Sekunden-Stichprobe übersieht.

7. Code pushen, nicht die ganze Datenbank

Wenn Sie Änderungen von Staging nach Produktion übertragen, verschieben Sie Code – Themes, Plugins, benutzerdefinierte Skripte und Konfigurationsänderungen. Pushen Sie nicht die gesamte Datenbank, es sei denn, Sie haben einen bestimmten Grund und verstehen vollständig, was Sie überschreiben.

Während Sie auf Staging gearbeitet haben, lief Ihre Live-Website weiter. Neue Bestellungen kamen herein. Kontaktformulare wurden gesendet. Benutzer registrierten sich. Blog-Kommentare wurden gepostet.

Wenn Sie eine vollständige Datenbank von Staging nach Produktion pushen, überschreiben Sie all das.

Die Regel lautet: Code fließt von Staging zu Produktion; Inhalte bleiben auf der Produktion.

Wenn Sie auf Staging Inhaltsänderungen vorgenommen haben, die live gehen sollen, migrieren Sie diese Teile manuell, anstatt die gesamte Datenbank zu pushen.

Wenn Ihr Hoster oder Staging-Plugin selektives Pushen unterstützt, nutzen Sie es. Es ermöglicht Ihnen, bestimmte Dateien oder Tabellen zu pushen, ohne alles andere zu berühren. Dieses Maß an Kontrolle ist viel wert, wenn Ihre Live-Site aktive Benutzer oder laufende Transaktionen hat.

Für Duplicator können Sie ein benutzerdefiniertes Backup der Staging-Site erstellen, das die Datenbank nicht enthält.

Laden Sie es herunter und laden Sie es dann auf Ihre Produktions-Site hoch.

Stellen Sie jedoch sicher, dass Sie einen Notfallwiederherstellungsplan haben und vermeiden Sie es, Änderungen während Zeiten mit hohem Datenverkehr zu pushen. Möglicherweise müssen Sie Fehler beheben oder ein Backup wiederherstellen, wenn auf der Produktions-Site etwas schief geht.

8. Aktualisieren Sie Staging vor jeder Änderungsrunde

Eine Staging-Umgebung, die Wochen oder Monate alt ist, ist keine zuverlässige Testumgebung. Es ist ein Schnappschuss dessen, wie Ihre Site aussah, als Sie sie erstellt haben, was heute möglicherweise nur noch wenig mit Ihrer Site gemeinsam hat.

Plugin-Versionen auf Staging können hinter der Produktion zurückliegen. Inhaltsstrukturen können sich geändert haben. Einstellungen, die Sie auf der Live-Site aktualisiert haben, existieren möglicherweise nicht auf Staging.

Wenn Sie gegen eine veraltete Kopie testen, spiegeln die Ergebnisse Bedingungen wider, die nicht mehr existieren.

Ziehen Sie vor jeder neuen Charge von Änderungen eine frische Kopie von der Produktion ab. Dies ist die einzige Gewohnheit, die die meisten Staging-Fehler eliminiert. Es bedeutet, dass jeder Test, den Sie durchführen, gegen eine aktuelle, genaue Version Ihrer Site durchgeführt wird.

Wenn Sie Duplicator Pro verwenden, ist das Aktualisieren von Staging so schnell wie die ursprüngliche Einrichtung: Führen Sie ein neues Backup durch, machen Sie daraus eine Staging-Umgebung, und Sie sind fertig.

9. Erstellen Sie ein Produktions-Backup, bevor Sie pushen

Selbst nach sorgfältiger, gründlicher Staging-Arbeit kann ein Push immer noch schief gehen. Server-Caching-Verhalten, ein Plugin, das in der Live-Umgebung anders reagiert, eine Konfiguration, die auf Staging funktioniert, aber in der Produktion Konflikte verursacht: Diese Dinge passieren und sind nicht immer vorhersehbar.

Die Antwort ist, immer einen Wiederherstellungspunkt bereitzuhalten, bevor Sie pushen.

Erstellen Sie unmittelbar vor dem Bereitstellen von etwas aus dem Staging eine neue vollständige Website-Sicherung Ihrer Produktionsumgebung. Auf diese Weise, wenn etwas auf der Live-Site kaputt geht, stellen Sie dieses Backup wieder her und sind in wenigen Minuten wieder normal.

Ohne sie debuggen Sie entweder eine defekte Live-Site in Echtzeit oder versuchen, die Dinge manuell wieder zusammenzusetzen.

Ich betrachte dies als einen nicht verhandelbaren Schritt. Staging kann perfekt laufen und der Push kann Sie immer noch überraschen. Das Backup macht dies wiederherstellbar, anstatt katastrophal zu sein.

Duplicator ist das einzige Backup-Plugin mit Notfallwiederherstellungs-URLs, die auch dann funktionieren, wenn WordPress nicht erreichbar ist. Nachdem Sie ein vollständiges Website-Backup erstellt haben, legen Sie es als Notfallwiederherstellungspunkt fest.

Kopieren Sie dann die Wiederherstellungs-URL und speichern Sie sie an einem sicheren Ort.

Wenn der Push schief geht, fügen Sie diesen Link in ein Browserfenster ein und stellen Sie Ihre Website sofort in ihren normalen Zustand wieder her.

10. Räumen Sie alte Staging-Umgebungen auf

Staging-Umgebungen können sich schnell aufbauen. Sie erstellen eine für ein Redesign, beenden das Projekt und machen weiter. Sechs Monate später sitzen drei alte Staging-Klone auf Ihrem Server oder Konto, keiner davon ist klar beschriftet, alle sind veraltet.

Das verursacht zwei Probleme. Erstens, Verwirrung: Wenn Sie zurückkehren, um weitere Arbeiten durchzuführen, ist nicht immer klar, welche Umgebung aktuell ist oder in welchem Zustand sich eine davon befindet.

Zweitens, Sicherheit: Eine alte Staging-Umgebung, die nicht mehr aktiv verwaltet wird, kann ungepatcht bleiben, und wenn sie nicht ordnungsgemäß passwortgeschützt ist, ist sie eine offene Tür.

Machen Sie es sich zur Gewohnheit, Staging-Umgebungen zu löschen, wenn Sie mit ihnen fertig sind. Sie können alle Ihre Staging-Websites von einem Ort im Duplicator-Dashboard aus verwalten.

Wenn Sie eine neue Arbeitsrunde beginnen, erstellen Sie einen frischen Klon von der Produktion, anstatt einen alten auszugraben. Das hält die Dinge sauber und stellt sicher, dass Sie immer genau wissen, womit Sie arbeiten.

Staging richtig gemacht: Eine Checkliste, bevor Sie in die Produktion pushen

Bevor Sie etwas von Staging in die Produktion einspielen, gehen Sie diese Liste durch. Es dauert fünf Minuten, und ich kann aus Erfahrung sagen, dass es mehr als ein paar schlechte Tage verhindert hat.

• Staging wurde vor dieser Testrunde aus der Produktion aktualisiert
• Alle Änderungen wurden auf Staging vorgenommen, nicht direkt auf der Produktion
• WP_DEBUG wurde auf Staging aktiviert und es wurden keine Fehler gefunden
• Jedes Update wurde einzeln angewendet, nicht alle auf einmal
• Vollständiger Website-Testabschluss: Navigation, Formulare, Kasse, mobiles Layout, Seitengeschwindigkeit
• Staging ist passwortgeschützt und von der Suchmaschinenindizierung blockiert
• Es werden nur Codeänderungen übertragen, nicht die gesamte Datenbank
• Ein frisches Voll-Website-Backup der Produktion wurde unmittelbar vor der Übertragung erstellt
• Sie kennen die genauen Schritte, um dieses Backup wiederherzustellen, falls die Übertragung etwas beschädigt

Der letzte Punkt ist der, den die Leute überspringen. Ein Backup zu machen und zu wissen, wie man es wiederherstellt, sind zwei verschiedene Dinge.

Wenn Sie noch nie ein Wiederherstellung mit Duplicator Pro durchgeführt haben, testen Sie es zuerst in einer Staging-Umgebung, damit Sie es nicht unter Druck auf einer defekten Live-Website herausfinden müssen.

Häufig gestellte Fragen (FAQs)

Staging verlangsamt Sie nicht. Die Wiederherstellung einer defekten Live-Site tut es.

Staging hat den Ruf, das zu sein, was man tun soll, aber nie dazu kommt. Es fühlt sich wie ein Mehraufwand an. Eine zusätzliche Ebene zwischen Ihnen und der Änderung, die Sie vornehmen möchten.

Die meisten Gelegenheits-WordPress-Benutzer behandeln es so, und die meisten von ihnen hatten auch schon ihre Live-Site im ungünstigsten Moment kaputt.

Der Zeitaufwand für Staging ist gering: ein paar Minuten zum Aktualisieren, ein paar Minuten zum Testen, ein Backup, bevor Sie übertragen. Der Zeitaufwand für die Wiederherstellung einer defekten Live-Site ist viel größer und mit dem zusätzlichen Stress verbunden, dass es öffentlich passiert.

Ein Staging-Workflow eliminiert das Risiko zwar nicht vollständig, fängt aber die überwiegende Mehrheit der Probleme ab, bevor sie überhaupt in die Produktion gelangen.

Mehr als 1,5 Millionen WordPress-Profis nutzen Duplicator Pro, um ihre Websites zu sichern, zu migrieren und zu stagen. Die Staging-Einrichtung ist mit wenigen Klicks erledigt, funktioniert auf jedem Hoster und erfordert kein separates Hosting-Konto oder technisches Hintergrundwissen, um sie in Betrieb zu nehmen.

Wenn dieser Beitrag Sie dazu gebracht hat, über den Schutz Ihrer Website nachzudenken, bevor Sie Änderungen vornehmen, sind diese Anleitungen eine Lektüre wert.

• So erstellen Sie eine WordPress-Staging-Site (für sicheres Testen)
• Benötigen Sie eine Staging-Site?
• So sichern Sie die Staging-Site Ihrer Website vor jedem Push
• Die 9 besten WordPress-Staging-Plugins (+ unsere Expertenbewertungen)
• So erstellen Sie eine WooCommerce-Staging-Site (+ Was Sie testen sollten, bevor Sie live gehen)
• WordPress-Datenbankwartung: Was Sie wöchentlich, monatlich und vierteljährlich tun sollten