Die Migration verlief gut. SSL OK, DNS propagiert, reaktionsschnelle Unterstützung. Dennoch wird die Website immer noch in vier Sekunden geladen – manchmal schlechter als zuvor. Die Versuchung besteht darin, dem neuen Gastgeber die Schuld zu geben. Oftmals macht der Server genau das, was von ihm verlangt wird: ein umfangreiches WordPress ohne konsistenten Cache mit einer über Jahre gewachsenen Datenbank bereitzustellen.
Durch einen Wechsel des Hostings ändert sich das Problem. Es löst das Problem nicht, wenn die Antragsschuld mit den Dateien wandert.
Die häufigsten Ursachen nach der Migration
| Symptom | Wahrscheinliche Ursache | Wo handeln |
|---|---|---|
| Hohe TTFB (>600ms) | Langsames PHP, SQL-Abfragen, kein Seitencache | Basis, Plugins, Server-Cache |
| Schwere Seite (> 3 MB) | Unkomprimierte Bilder, Schriftarten, Skripte | Thema, Medien, CDN |
| Nur langsamer Administrator | Backend-Plugins, Heartbeat, Autoload | Plugins, wp-config |
| Geografische Langsamkeit | Kein CDN, Remote-Rechenzentrum | CDN, Region |
| Zufällige Spitzen | Cron, Backups, Sicherheitsscan | Planung, Randzeiten |
Ein schnellerer Host ohne Diagnose ist eine neue Adresse für dieselbe überlastete Engine.
Diagnose-Checkliste in nützlicher Reihenfolge
Sauber messen mit WebPageTest, Lighthouse oder GTmetrix. Überprüfen Sie den Cache: Bietet der neue Host Server-Cache? Ist Ihr Plugin kompatibel? Audit-Plugins im Staging. Überprüfen Sie die Datenbank: große Autoloads, abgelaufene Transienten, unbegrenzte Revisionen. Upgrade auf PHP 8.1+, falls kompatibel.
Was der neue Host ändert – und was er nicht ändert
CPU/RAM hilft, wenn die alte gemeinsam genutzte CPU ausgelastet war. Der integrierte Edge-Cache hilft, wenn er aktiviert ist. Page-Builder-Theme, vierzig aktive Plugins, 4000-Pixel-Bilder: Nein – sie begleiten die Migration.
Klassische Fehler: schlecht umkonfiguriertes Cache-Plugin des alten Hosts, Redis nicht aktiviert, obwohl das Angebot es vorschlägt, Datenbank ohne Bereinigung importiert.
Der Gipfel: Migration macht Schulden sichtbar, sie schafft sie nicht
Teams erwerben manchmal einen Premium-VPS als Alternative zu einem Plugin-Audit. Der VPS hilft – wenn jemand Autoload bereinigt, den Objekt-Cache konfiguriert und das Theme aufhellt.
Entscheide dich und gehe ohne blinden Fleck voran
Messen Sie TTFB und Seitengewicht vor und nach der Migration. Konfigurieren Sie eine einzelne konsistente Seiten-Cache-Ebene. Bereinigen Sie zuerst Autoload und Transienten im Staging. Reduzieren Sie Plugins auf das Wesentliche für das Unternehmen. Fügen Sie CDN hinzu, wenn die Zielgruppe weit vom Rechenzentrum entfernt ist.
Vergleichen Sie WordPress-Hosts über das Verzeichnis und von WordPress verwaltet.
Häufig gestellte Fragen
Wie lange nach einer Migration sollte die Leistung beurteilt werden?
Warten Sie, bis ein stabiles DNS und ein stabiler Cache vorhanden sind. Wenn die TTFB nach 48 Stunden ohne Datenverkehr hoch bleibt, sehen Sie sich die Anwendungs- und Konfigurationsseite an.
Kann ein schnellerer Host zehn schwere Plugins kompensieren?
Nicht dauerhaft. Die CPU verbirgt die Schulden vorübergehend, dann übernehmen SQL-Abfragen und Frontend-Skripte.
Sollten wir alle verfügbaren Caches aktivieren?
Nein. Eine konsistente Strategie ist besser als überlappende Caches, die zu Konflikten und veralteten Inhalten führen.
Woher weiß ich, ob die Datenbank fraglich ist?
Achten Sie auf langsame Abfragen, große Autoloads (>1 MB) und ungereinigte Transienten – sie verlangsamen jede Seite.
Ein Host-Wechsel ohne WordPress-Audit bedeutet den Umzug eines vollgestopften Dachbodens in eine neuere Garage. Die Garage ist besser – das Chaos auch.