WordPress-Website parallel aufbauen (ohne Downtime)
Sie wollen Ihre Website neu bauen, aber die alte darf keine Minute ausfallen und soll ihre Google-Rankings behalten. Der saubere Weg: Sie bauen die neue WordPress-Site an einem zweiten Ort auf – Subdomain, Staging oder lokal – und tauschen erst am Ende die Live-Domain um. Diese Anleitung geht die drei Varianten durch, sperrt die Baustelle zuverlässig vor Google und führt Sie durch den Domain-Wechsel ohne Broken Links und ohne Downtime.
Drei Wege, parallel zu arbeiten
1. Subdomain beim selben Hoster. Sie legen neu.ihredomain.de oder staging.ihredomain.de an und installieren dort ein frisches WordPress. Vorteil: gleiche Server-Umgebung, gleiche PHP-Version, gleiche Datenbank-Zugänge wie später live – Überraschungen beim Umzug bleiben aus. Das ist für die meisten der beste Kompromiss.
2. Staging-Funktion des Hosters. Managed-Hoster wie SiteGround, Kinsta, WP Engine, Raidboxes oder Cloudways bieten Staging auf Knopfdruck: Sie klonen die Live-Site in eine geschützte Kopie und schieben Änderungen später per „Push to Live“ zurück. Bei einem kompletten Neuaufbau ist das weniger praktisch, weil Sie ja gerade nicht die alte Site kopieren, sondern bei null anfangen. Für Redesigns auf bestehender Basis ist es ideal.
3. Lokal auf dem eigenen Rechner. Mit LocalWP (früher „Local by Flywheel“), DevKinsta oder XAMPP entwickeln Sie offline, ohne Serverkosten und ohne dass jemand mitliest. Nachteil: Kunde und Team können nicht einfach draufschauen, und der Umzug ins Web ist ein zusätzlicher Schritt.
Für einen echten Neuaufbau empfehlen wir Variante 1 oder 3. Wenn Sie ohnehin schon eine Domain haben, aber noch keinen Platz zum Bauen suchen, hilft Ihnen der Beitrag Website erstellen ohne Domain weiter.
Neue WordPress-Installation aufsetzen
Auf einer Subdomain sind es drei Schritte:
- Im Hosting-Panel (Plesk, cPanel, IONOS, Strato …) die Subdomain anlegen und einen eigenen Ordner zuweisen, z. B.
/httpdocs/neu/. - Eine eigene, leere Datenbank für die neue Installation erstellen. Nutzen Sie nicht dieselbe Datenbank wie die alte Site – sonst überschreiben sich beide.
- WordPress installieren, meist über den 1-Klick-Installer des Hosters oder klassisch per Upload nach
wp-admin/install.php.
Legen Sie für die Subdomain gleich ein SSL-Zertifikat an (bei den meisten Hostern per Let’s Encrypt kostenlos), damit Sie von Anfang an über https:// arbeiten und später kein Mixed-Content-Problem bekommen.
Die Baustelle vor Google verstecken
Das ist der wichtigste und am häufigsten übersehene Punkt. Eine öffentlich erreichbare Zweit-Site mit denselben Inhalten produziert Duplicate Content und kann bei Google indexiert werden – im schlimmsten Fall rankt die Staging-URL statt Ihrer echten Seite. Sichern Sie die Baustelle doppelt ab:
- Suchmaschinen aussperren: In WordPress unter Einstellungen → Lesen die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“ aktivieren. Das setzt einen
noindex-Hinweis, ist aber nur eine höfliche Bitte an die Crawler. - Passwortschutz per HTTP-Auth: Der zuverlässige Riegel. Über den „Verzeichnisschutz“ im Hosting-Panel oder manuell per
.htaccessund.htpasswd. Beispiel für die.htaccessim Subdomain-Ordner:
AuthType Basic
AuthName "Baustelle"
AuthUserFile /pfad/zu/.htpasswd
Require valid-user
So sieht weder Google noch ein zufälliger Besucher etwas, ohne Zugangsdaten geht nichts.
Tragen Sie sich unbedingt einen Reminder ein, beide Sperren beim Go-live wieder zu entfernen. Eine live geschaltete Seite, die versehentlich auf noindex steht, verschwindet innerhalb von Tagen aus dem Index.
Design und Inhalte aufbauen
Jetzt bauen Sie in Ruhe: Theme oder Page Builder (Elementor, Bricks, Divi, Block-Editor) einrichten, Seitenstruktur festlegen, Inhalte anlegen. Ein paar Dinge, die den späteren Umzug erleichtern:
- URL-Struktur früh festlegen. Behalten Sie – wo möglich – dieselben Permalinks wie auf der alten Site. Jede geänderte URL kostet Sie sonst später eine 301-Weiterleitung.
- Bilder als Mediathek-Uploads, nicht per absoluter URL fest verdrahten. Das erleichtert das Suchen-Ersetzen beim Umzug.
- Benötigte Plugins installieren: ein SEO-Plugin (Yoast, Rank Math), Caching und ggf. ein Cookie-Banner für die DSGVO. Wenn Ihnen später der Cache in die Quere kommt, hilft Wo finde ich den WordPress-Cache?.
Go-live: Domain umziehen ohne Ausfall
Wenn die neue Site fertig ist, tauschen Sie sie gegen die alte. Der Ablauf, der Downtime vermeidet:
1. Frisches Backup beider Seiten. Vollständig, Dateien und Datenbank. Falls Sie bei IONOS sind, zeigt IONOS Website-Backup erstellen den Weg; grundsätzlich funktioniert auch Duplicator oder All-in-One WP Migration.
2. DNS-TTL vorab senken. Setzen Sie die TTL des A-Records ein bis zwei Tage vor dem Umzug auf 300 Sekunden. Dann wirkt die spätere DNS-Umstellung fast sofort statt erst nach Stunden.
3. Dateien und Datenbank auf die Hauptdomain umziehen. Entweder ziehen Sie die Installation vom Subdomain-Ordner in den Hauptordner um, oder Sie richten die Hauptdomain auf den bestehenden Ordner. Der entscheidende Punkt danach: alle alten URLs in der Datenbank ersetzen.
4. Suchen-Ersetzen – aber richtig. In der WordPress-Datenbank stehen https://neu.ihredomain.de an hunderten Stellen. Ein einfaches SQL-REPLACE zerstört aber serialisierte Daten (z. B. Widget- und Builder-Einstellungen), weil sich die gespeicherten Zeichenlängen ändern. Nutzen Sie deshalb ein Werkzeug, das Serialisierung versteht:
Per WP-CLI (erst als Probelauf mit --dry-run):
wp search-replace 'https://neu.ihredomain.de' 'https://ihredomain.de' --all-tables --dry-run
wp search-replace 'https://neu.ihredomain.de' 'https://ihredomain.de' --all-tables
Ohne Kommandozeile leistet das Plugin Better Search Replace dasselbe (Haken bei „Run as dry run“ zum Testen).
5. Site-URL prüfen. Unter Einstellungen → Allgemein müssen „WordPress-Adresse“ und „Website-Adresse“ auf die finale Domain zeigen. Notfalls in der wp-config.php erzwingen:
define( 'WP_HOME', 'https://ihredomain.de' );
define( 'WP_SITEURL', 'https://ihredomain.de' );
6. Geänderte URLs per 301 weiterleiten. Haben sich Permalinks geändert, richten Sie 301-Weiterleitungen von den alten auf die neuen Adressen ein – per Plugin „Redirection” oder direkt in der .htaccess:
Redirect 301 /alte-url/ /neue-url/
Prüfen Sie die Umleitung anschließend mit einem Tool, das den HTTP-Statuscode anzeigt (z. B. den Redirect-Check-Funktionen der Search Console oder curl mit curl -I), damit wirklich 301 und nicht 302 zurückkommt. So bleiben Rankings und Backlinks erhalten.
7. Aufräumen. noindex deaktivieren, Passwortschutz entfernen, Permalinks einmal neu speichern (setzt die .htaccess-Regeln zurück), Cache leeren und die neue Sitemap in der Google Search Console einreichen.
Typische Fehler und ihre Lösung
- Staging wurde von Google indexiert. Ursache: kein Passwortschutz. Lösung: HTTP-Auth setzen, indexierte URLs in der Search Console per „Entfernen“ austragen.
- Nach dem Umzug sind Bilder und Layout kaputt. Ursache: URLs nicht (oder mit SQL statt serialisierungssicher) ersetzt. Lösung: Better Search Replace bzw.
wp search-replaceerneut laufen lassen. - Live-Seite bleibt weiß oder zeigt die alte Version. Meist Caching – Server-, Plugin- und Browser-Cache leeren, ggf. Objekt-Cache. Was ein solcher Totalausfall bedeuten kann, erklärt Was bedeutet „Website abgestürzt“?.
- Seite ist nach Go-live aus Google verschwunden. Fast immer der vergessene
noindex-Haken aus Schritt „Baustelle verstecken“. Deaktivieren, dann Re-Indexierung anfordern.
FAQ
Muss die alte Website offline gehen, während ich baue? Nein. Genau das ist der Sinn des parallelen Aufbaus: Die alte Site läuft unter der echten Domain weiter, die neue entsteht auf Subdomain, Staging oder lokal. Erst der finale DNS- bzw. Ordner-Wechsel schaltet um – und der dauert bei niedriger TTL nur Minuten.
Verliere ich meine Google-Rankings beim Umzug? Nicht, wenn Sie die URL-Struktur beibehalten oder geänderte Adressen per 301 weiterleiten und die Baustelle vorher nie indexiert wurde. Reichen Sie nach dem Go-live die aktualisierte Sitemap in der Search Console ein.
Kann ich einfach dieselbe Datenbank für beide Seiten nutzen? Nein. Alte und neue Installation brauchen getrennte Datenbanken (oder zumindest getrennte Tabellen-Präfixe). Teilen sie sich eine Datenbank, überschreiben sich Einstellungen und Inhalte gegenseitig.