Warum WordPress nicht am CMS scheitert — sondern am Hosting

WordPress hat einen Ruf. Langsam, anfällig, ständig kaputt. Wer im IT-Umfeld arbeitet, hört diesen Reflex regelmäßig — und doch betreibt rund 40 Prozent des Webs WordPress, viele davon störungsfrei über Jahre. Der Widerspruch löst sich auf, sobald man den Blick verschiebt: Die meisten WordPress-Probleme, die in Agenturen und KMU auf den Tisch kommen, sind keine WordPress-Probleme. Es sind Hosting-Probleme.

Das CMS selbst ist über zwanzig Jahre alt, vielfach durchgetestet und bei sauberer Konfiguration solide. Was dagegen oft fehlt, ist eine Betriebsumgebung, die WordPress die Bedingungen gibt, unter denen es zuverlässig läuft. Wer das Setup richtig wählt — als Agentur für Kunden, als Unternehmen für die eigene Site — spart sich einen großen Teil der Reibungspunkte, die später als „WordPress-Pflege” auf der Rechnung stehen.

Wo Standard-Hosting in der Praxis versagt

Das klassische Shared-Hosting-Paket liefert WordPress zuverlässig aus, solange wenig passiert. Sobald das Setup gefordert wird — Lastspitzen, größerer Plugin-Stack, gleichzeitige Backups — beginnen die Probleme. Der Grund liegt im Modell: Hunderte von Sites teilen sich CPU, Arbeitsspeicher und Datenbankserver. Wenn ein Nachbar einen Crawl bekommt oder ein Plugin außer Kontrolle gerät, leidet die eigene Site mit, ohne dass man eingreifen kann.

Hinzu kommt die PHP-Konfiguration. Standard-Hoster fahren konservative Defaults — niedriges memory_limit, kein OPcache aktiviert, kein Object Cache, oft veraltete PHP-Versionen aus „Kompatibilitätsgründen”. Für eine schlanke Visitenkarten-Site reicht das. Für eine Site mit WooCommerce, Mehrsprachigkeit oder ein paar dutzend aktiven Plugins ist es der Unterschied zwischen flotter Auslieferung und dauernder Trägheit. Die meisten dieser Stellschrauben sieht der Nutzer nicht, weil er gar keinen Zugriff hat.

Der dritte und unsichtbarste Punkt ist das Backup. „Tägliches Backup inklusive” steht auf jeder Hoster-Seite. Was meist nicht dasteht: dass dieses Backup oft auf demselben physischen Server liegt, dass der Restore-Prozess nirgends dokumentiert ist, und dass im Ernstfall — Hardware-Ausfall, Ransomware, fehlerhaftes Update — niemand den Restore je getestet hat. Backup ohne getesteten Restore ist Hoffnung, nicht Schutz.

Was sich mit Container-Hosting verändert

Container-Hosting ist nichts Esoterisches. Es bedeutet, dass jede WordPress-Instanz in einer abgeschotteten Umgebung läuft — mit eigenen Ressourcen, eigener Konfiguration, eigener PHP-Version. Was der Nachbar tut oder lässt, ist irrelevant. Lastspitzen einer Site beeinflussen andere nicht. Sicherheitsprobleme breiten sich nicht horizontal aus.

Der zweite Effekt ist Reproduzierbarkeit. Eine Container-basierte Umgebung lässt sich identisch für Staging und Produktion betreiben. Was auf Staging funktioniert, funktioniert auch live — und was auf Staging bricht, hat man wenigstens nicht erst in der Produktion entdeckt. Diese Symmetrie ist auf Shared-Hosting kaum herzustellen, weil man nicht weiß, was der Hoster wann ändert.

Der dritte Effekt betrifft Wechsel und Migration. Wenn die Umgebung in Code definiert ist, lässt sie sich kopieren, versionieren und auf einen anderen Anbieter überführen. Aus Lock-in wird Optionalität. Das ist auch dann wertvoll, wenn man nicht wechseln will — weil es bedeutet, dass man wechseln könnte.

Backups, die ihren Namen verdienen

Die nüchterne Faustregel ist als 3-2-1 bekannt: drei Kopien der Daten, auf zwei verschiedenen Medien, eine davon räumlich getrennt vom Original. Für WordPress heißt das praktisch: regelmäßiger Dump der Datenbank plus der uploads-Verzeichnisse, abgelegt an einem Ort, der nicht vom Server-Crash mitgerissen wird, und an einem zweiten zur Sicherheit.

Wichtiger noch ist der Restore-Test. Ein Backup, das nie zurückgespielt wurde, ist mit höherer Wahrscheinlichkeit kaputt, als man denkt. Verzeichnisse fehlen, Datenbank-Dumps sind unvollständig, Verschlüsselungs-Keys lagern an unauffindbarer Stelle. Wer einmal pro Jahr einen vollständigen Restore gegen eine Test-Umgebung fährt und das Vorgehen protokolliert, weiß, dass sein Backup eines ist.

In der Toollandschaft sind UpdraftPlus, Duplicator und All-in-One WP Migration etablierte Plugin-Lösungen — gut für kleinere Setups. Für ernsthafte Anwendungen ist eine Backup-Lösung auf Server-Ebene (Datenbank-Dump plus File-Sync zu einem getrennten Backup-Ziel) zuverlässiger, weil sie unabhängig von der WordPress-Instanz selbst läuft. Wenn die Site ausfällt, läuft das Backup trotzdem.

Updates ohne Tränen

Die zweite operative Disziplin heißt Update-Strategie. Auto-Updates für WordPress-Core-Sicherheitspatches sind sinnvoll und seit vielen Jahren stabil — sie zu deaktivieren ist meist ein Fehler. Auto-Updates für Major-Versionen und Plugins sind eine andere Frage. Plugins können brechen, sich gegenseitig in die Quere kommen oder ein Theme inkompatibel machen. Ein Auto-Update am Freitagabend, das die Site bis Montag stört, ist kein guter Tausch gegen drei Klicks Pflege pro Monat.

Der saubere Weg ist Staging plus Disziplin. Updates erst auf einer identischen Staging-Umgebung einspielen, kurz prüfen, dann auf Produktion. Plugins, die seit über einem Jahr keine Updates erhalten haben, gehören auf eine Liste — entweder ersetzt oder entfernt. Eine WordPress-Installation mit dreißig Plugins, von denen die Hälfte verwaist ist, ist kein Setup, sondern ein Schadensfall in Wartestellung.

Was eine Agentur Kunden mindestens versprechen sollte

Wer für Kunden WordPress betreibt, hat eine kurze Liste an Mindestversprechen, unter der kein professioneller Dienstleistungsvertrag mehr stehen sollte: tägliche Backups mit dokumentiertem, mindestens jährlich getestetem Restore; eine Staging-Umgebung für Updates; klare Reaktionszeiten bei Sicherheitsvorfällen; ein Monitoring, das nicht nur „Site erreichbar” prüft, sondern auch Antwortzeiten und Fehlerraten; eine geführte Liste aktiver Plugins mit Update-Status.

Das klingt nach viel und ist doch der Standard, an dem sich seriöse Agenturarbeit messen lassen muss. Wer es nicht selbst leisten will oder kann, kauft die Operations-Schicht zu — bei einem Hoster, der genau diese Garantien gibt, statt sie nur zu suggerieren.

solidport.de ist unser Container-basiertes WordPress-Hosting. Wir richten die Punkte oben ein, weil wir sie selbst seit Jahren brauchen — für eigene und für Kundenprojekte. Es ist nicht das einzige gute Setup auf dem Markt, aber eines, hinter dem wir technisch und operativ stehen können.