WordPress Hosting wechseln ohne Downtime
WordPress Hosting wechseln ohne Downtime: Backup, DNS-TTL senken, Migration per Plugin oder Umzugsservice, Test via hosts-Datei — plus häufige Fehler.
Ein Hosting-Wechsel klingt nach Risiko — Downtime, verlorene E-Mails, verschwundene Bestellungen. Mit der richtigen Reihenfolge ist er das nicht: DNS-Umstellungen lassen sich vorbereiten, Migrationen lassen sich testen, bevor auch nur ein Besucher etwas davon merkt. Dieser Guide zeigt dir den Ablauf Schritt für Schritt — inklusive der ehrlichen Warnung, wann ein Hosting-Wechsel gar nicht dein eigentliches Problem löst.
Ein Hosting-Wechsel ist außerdem der Moment, in dem viele Betreiber gleichzeitig Altlasten loswerden wollen: veraltete Plugins, ungenutzte Themes, aufgeblähte Datenbanktabellen. Das ist grundsätzlich sinnvoll, gehört aber getrennt vom eigentlichen Migrationsschritt behandelt — vermische nicht „aufräumen" mit „umziehen", sonst wird die Fehlersuche bei Problemen unnötig komplex. Nutze im Zweifel unsere Checkliste als Leitfaden für die Vorbereitung.
Schritt 1: Vollständiges Backup vor allem anderen
Bevor du irgendetwas anfasst: ein vollständiges Backup von Dateien und Datenbank, extern gespeichert (nicht nur auf dem alten Server). Die meisten Managed-Hoster bieten automatische Backups, aber verlass dich vor einer Migration nicht allein darauf — lade eine eigene Kopie herunter oder exportiere sie über ein Backup-Plugin. Das ist die einzige Absicherung, falls während der Migration etwas schiefgeht.
Schritt 2: DNS-TTL rechtzeitig senken
Der Time-to-Live-Wert (TTL) deiner DNS-Einträge bestimmt, wie lange DNS-Resolver weltweit eine Antwort zwischenspeichern, bevor sie erneut nachfragen. Ein hoher TTL-Wert (üblicherweise 3.600–86.400 Sekunden im Normalbetrieb) sorgt dafür, dass nach der eigentlichen Umstellung manche Besucher stunden- oder sogar tagelang noch auf dem alten Server landen.
Deshalb: Senke den TTL-Wert deines A-Records 24–48 Stunden vor dem geplanten Wechsel auf 300–600 Sekunden (5–10 Minuten). So übernehmen die meisten Resolver weltweit rechtzeitig den niedrigen Wert, und die eigentliche Umstellung wirkt innerhalb weniger Minuten statt Stunden. Der häufigste Fehler an dieser Stelle: den TTL erst am Umzugstag selbst zu senken — dann ist es zu spät, weil viele Resolver den alten, hohen Wert bereits zwischengespeichert haben.
Schritt 3: Migrationsmethode wählen
Drei Wege stehen offen, mit unterschiedlichem Aufwand:
Migrations-Plugin (für die meisten der richtige Weg). Tools wie All-in-One WP Migration, Duplicator oder UpdraftPlus verpacken Dateien und Datenbank in ein Paket, das du beim Zielhosting wieder einspielst. Für Standard-WordPress-Installationen ohne exotische Server-Konfiguration meist der schnellste Weg mit überschaubarem Risiko.
Manuelle Migration per SSH/phpMyAdmin. Volle Kontrolle, aber auch voller manueller Aufwand: Datenbank-Dump exportieren und importieren, wp-content/ per rsync oder SFTP übertragen, wp-config.php mit neuen Zugangsdaten anpassen, Suchen-und-Ersetzen für die Domain in der Datenbank (falls sich diese ändert, etwa bei einem Wechsel von www. auf eine reine Domain oder umgekehrt). Sinnvoll bei sehr großen Installationen, bei denen Plugin-basierte Exporte an Speicher- oder Zeitlimits des alten Hostings scheitern, oder wenn du technisch ohnehin fit bist und volle Kontrolle über jeden Schritt willst. Der Nachteil: Jeder manuelle Schritt ist eine zusätzliche Fehlerquelle — ein vergessener Datenbank-Präfix oder eine falsch kopierte .htaccess reicht, um die neue Installation lahmzulegen, obwohl die Migration „eigentlich" abgeschlossen war.
Kostenloser Umzugsservice des Zielhosters. Der bequemste Weg, sofern dein neuer Hoster ihn anbietet — und mehrere der auf dieser Seite besprochenen Anbieter tun das:
| Hoster | Kostenlos? | Ablauf/Dauer | Besonderheit |
|---|---|---|---|
| Raidboxes* | Ja | Testkopie in bis zu 2 Werktagen, bis zu 14 Tage Testphase vor Aktivierung | Multisite-Migrationen laufen über Partner Codeable (Raidboxes — Migration) |
| WPspace* | Ja | Terminvereinbarung, Umzug meist innerhalb einer Stunde | Inklusive kostenloser PageSpeed-Beratung nach dem Umzug (WPspace Help Center) |
| Kinsta* | Ja, unbegrenzt viele Seiten | In der Regel unter 24 Stunden, ohne Downtime | Entfernt gefundene Malware kostenlos mit (Kinsta — Migration) |
Mehr zur Einordnung der einzelnen Anbieter in Raidboxes Erfahrungen und im Vergleich Kinsta vs. Raidboxes.
Schritt 4: Testen über die hosts-Datei, bevor DNS umgestellt wird
Der entscheidende Trick für einen Wechsel ohne Downtime: Du kannst die neue Installation vollständig testen, bevor die eigentliche DNS-Umstellung erfolgt. Dazu trägst du auf deinem eigenen Rechner in der hosts-Datei (unter Windows C:\Windows\System32\drivers\etc\hosts, unter macOS/Linux /etc/hosts) einen Eintrag ein, der deine Domain manuell auf die neue Server-IP umleitet — nur für deinen Rechner, nicht für den Rest der Welt. So siehst du in deinem Browser bereits die neue Installation unter der echten Domain, kannst Formulare, Login, Checkout und Darstellung prüfen, während der Rest der Besucher weiterhin unbemerkt auf dem alten Server landet. Erst wenn hier alles funktioniert, folgt die eigentliche Umstellung.
Konkret solltest du in dieser Testphase mindestens prüfen: Login ins WordPress-Backend, Kontaktformulare (inklusive tatsächlichem Mailversand-Test), bei Shops den kompletten Checkout-Prozess inklusive Zahlungsanbieter-Sandbox, eingebundene externe Schriftarten und Skripte, sowie SSL-Zertifikat-Warnungen im Browser. Ein häufig übersehener Punkt: Trage den hosts-Eintrag nach Abschluss der Tests wieder aus deiner lokalen hosts-Datei aus — sonst siehst du nach dem eigentlichen Go-Live weiterhin die (dann veraltete) Testversion, während alle anderen Besucher längst auf dem neuen Server landen, und wunderst dich über Unterschiede, die es in Wirklichkeit nicht mehr gibt.
Schritt 5: Go-Live — DNS umstellen
Mit gesenktem TTL und getesteter neuer Installation: A-Record auf die neue Server-IP ändern. Lass den alten Server für mindestens 48 Stunden parallel erreichbar und unverändert — manche Resolver brauchen trotz niedrigem TTL etwas länger, und ein sofortiges Abschalten des alten Servers wäre an dieser Stelle unnötiges Risiko.
Schritt 6: Nach dem Umzug
- TTL zurücksetzen auf den ursprünglichen, höheren Wert (spart DNS-Anfragen im Regelbetrieb).
- SSL-Zertifikat prüfen — auf dem neuen Server muss ein gültiges Zertifikat für die Domain aktiv sein, bevor Besucher in großer Zahl ankommen.
- Cache vollständig leeren, sowohl serverseitig als auch in einem eventuell genutzten CDN, damit keine veralteten Inhalte ausgeliefert werden.
- E-Mail-Versand (MX-Records) gesondert prüfen. Das ist der mit Abstand häufigste Fehler bei Hosting-Wechseln: Wenn E-Mail über einen separaten Anbieter läuft (oft der Fall), dürfen die MX-Records beim Domain-Wechsel nicht versehentlich mitgeändert oder gelöscht werden — sonst gehen eingehende Mails ins Leere.
- Speed-Test durchführen. Miss die neue Installation über /speed-test/ und vergleiche mit deinen Erwartungen an das neue Hosting.
Häufige Fehler beim Hosting-Wechsel
- TTL nicht rechtzeitig gesenkt — der mit Abstand häufigste Fehler, siehe Schritt 2.
- Kein eigenes Backup vor der Migration, sondern blindes Vertrauen auf automatische Backups des alten Hosters, auf die im Streitfall kein Zugriff mehr besteht.
- MX-Records beim Domain-Umzug vergessen oder versehentlich überschrieben.
- Doppelte Cron-Jobs während der Übergangsphase. Läuft
wp-cronauf beiden Servern parallel (z. B. für E-Mail-Versand oder geplante Beiträge), kann das zu doppelt versendeten Mails oder Konflikten führen — deaktiviere zeitkritische Cron-Aufgaben auf dem alten Server, sobald der neue produktiv läuft. - Cache nach Go-Live nicht geleert, sodass Besucher trotz erfolgreicher Migration noch alte Inhalte sehen und der Wechsel fälschlich als „funktioniert nicht" wahrgenommen wird.
- Suchmaschinen-Indexierung ignoriert bei gleichzeitigem Domain- oder URL-Wechsel — ohne 301-Redirects auf die neuen URLs verlierst du Rankings, die mit dem Hosting selbst nichts zu tun haben.
Die ehrliche Warnung: Wann du NICHT wechseln solltest
Ein Hosting-Wechsel ist kein Allheilmittel. Wenn deine Seite langsam ist, liegt die Ursache in vielen Fällen nicht am Hosting, sondern am Theme, an zu vielen oder schlecht programmierten Plugins, an unoptimierten Bildern oder an fehlender Cache-Konfiguration — Themen, die ein neuer Hoster nicht automatisch löst. Bevor du den Aufwand eines Wechsels auf dich nimmst, miss deine aktuelle Seite über /speed-test/ und lies WordPress langsam? So findest du die tatsächliche Ursache, um die eigentliche Diagnose zu stellen. Zeigt sich dabei ein strukturelles Hosting-Problem (durchgängig hoher, schwankender TTFB trotz gutem Cache-Setup), ist ein Wechsel gerechtfertigt — zeigt sich stattdessen ein Plugin- oder Bild-Problem, hast du mit einem neuen Hoster nur Geld ausgegeben, ohne die Ursache zu beheben.
Wenn du die Diagnose selbst durchgeführt hast, aber weder Zeit noch Nerven für die eigentliche Optimierung hast: Panomity übernimmt die Speed-Optimierung deiner bestehenden WordPress-Seite als Dienstleistung, unabhängig vom Hosting-Wechsel — mehr dazu unter /hilfe/.
Entscheidungsstruktur
Wenn dein TTFB strukturell zu hoch ist (siehe TTFB verbessern WordPress für die Diagnose) und dein aktuelles Hosting das nicht lösen kann: Wechsel ist sinnvoll — nutze wenn möglich den kostenlosen Umzugsservice deines Zielhosters und die Testphase, bevor du kündigst.
Wenn deine Seite aus anderen Gründen langsam ist (Bilder, Plugins, Theme): Erst optimieren, dann neu messen, dann erst über einen Wechsel nachdenken — sonst trägst du das Problem unverändert auf den neuen Server mit.
Wenn du unsicher bist, welcher Fall vorliegt: Fang mit dem Speed-Test an. Er zeigt dir, wo der Engpass tatsächlich liegt, bevor du dich für einen der beiden Wege entscheidest.
Am Ende steht in jedem Fall dieselbe Empfehlung: Nutze die kostenlose Testphase, die dir ein neuer Hoster über den Umzugsservice bietet, um deine eigene, fertig eingerichtete Seite dort zu messen, statt dich auf Werbeversprechen zu verlassen — und kündige das alte Hosting erst, wenn die neue Installation nachweislich läuft und schneller ist.
Weiterführend: Raidboxes Erfahrungen und Kinsta vs. Raidboxes für die Anbieterauswahl, WordPress Hosting Vergleich für die Gesamtübersicht, WordPress langsam? für die Ursachendiagnose, oder Speed-Test starten.