WordPress Hosting: Wofür Sie Wirklich Bezahlen

WordPress Hosting wird in einer Preisspanne verkauft, die von etwa 3 £ im Monat bis zu mehreren Hundert reicht, und die Tarife an beiden Enden beschreiben sich mit fast identischen Worten. Schnell. Sicher. Gesichert. Betreut. Die Spezifikation, an der ein Käufer sie unterscheiden könnte, also welcher PHP-Zweig die Website ausführt, welche Datenbank-Engine dahintersteht, wie viele Caching-Schichten existieren und welche davon tatsächlich eingeschaltet sind, fehlt auf der Seite, von der aus Sie kaufen sollen, in aller Regel.

Dieses Fehlen ist Teil des Produkts. “Managed” ist eine Marketingkategorie und keine technische, und kein Normungsgremium definiert den Begriff. Zwei Anbieter, die dasselbe Wort verwenden, können sich darin unterscheiden, ob ein persistenter Object Cache läuft, ob Sie Ihr eigenes Caching-Plugin behalten dürfen, ob ein Backup ihre Infrastruktur verlassen darf und ob Sie überhaupt eine Shell öffnen können.

Was folgt, ist die Spezifikation, die diese Seiten weglassen: was WordPress verlangt, welche Teile des Stacks die Seitengeschwindigkeit bewegen, was Managed Hosting hinzufügt und stillschweigend wegnimmt, und realistische Monatsbänder für jede Stufe.

Wofür bezahlen Sie bei WordPress Hosting eigentlich? Für vier Dinge. Eine PHP-Version und eine Datenbank-Engine, die die von WordPress veröffentlichte Basis erfüllen. Caching-Schichten, die Sie sonst selbst installieren und abstimmen müssten. Betriebsarbeit, also Updates, Staging, Backups und eine Firewall. Und Reserve für Anfragen, die sich nicht cachen lassen. Eine Broschüren-Website braucht von diesem vierten Punkt fast nichts. Ein Shop oder eine Mitgliederseite gibt dort den größten Teil ihres Budgets aus.

WordPress Hosting ist ein Kategoriename, keine Spezifikation

Die Preisspanne innerhalb einer einzigen Kategorie ist der verräterische Punkt. Zwei Tarife, beide als Managed WordPress Hosting bezeichnet, können bei 20 £ und bei 250 £ im Monat liegen, und der Werbetext erklärt die Lücke nicht, weil die Lücke aus Dingen besteht, die der Text nicht erwähnt.

Am günstigen Ende kaufen Sie einen Anteil an einer geteilten Maschine mit einem PHP-FPM-Pool, einem Page Cache und einem Control Panel. Am teuren Ende kaufen Sie isolierte Rechenleistung, einen persistenten Object Cache, eine Staging-Umgebung, eine verwaltete Firewall, ein Support-Team, das Ihr Fehlerprotokoll liest, und jemanden, der vertraglich verantwortlich ist, wenn ein Core-Update ein Template zerlegt.

Beides sind legitime Produkte. Das Problem ist, dass der Käufer nicht erkennen kann, welches davon vor ihm liegt, also fällt die Entscheidung über den Preis und über Vergleichsportale, die nach Affiliate-Provision sortieren. Das Ergebnis ist in beide Richtungen vorhersehbar. Broschüren-Websites landen auf 150-£-Tarifen, die sie nie ausschöpfen werden, und WooCommerce-Shops landen auf 5-£-Tarifen, die am ersten umsatzstarken Samstag an der Kasse zusammenbrechen.

Der Ausweg besteht darin, nach vier Fragen einzukaufen statt nach dem Namen der Stufe: welcher PHP-Zweig, welche Caching-Schichten, wie viele nicht cachebare Anfragen der Tarif verkraftet und was mit Ihren Daten passiert, wenn Sie gehen.

Was WordPress tatsächlich von einem Server verlangt

WordPress veröffentlicht eine Anforderungsseite, und sie ist kurz, was genau der Grund ist, warum sie übersprungen wird. Lesen Sie sie als Einkaufsspezifikation, denn ein Tarif, der daran scheitert, ist disqualifiziert, bevor über Leistung überhaupt gesprochen wird.

Die PHP-Version

Die WordPress-Anforderungsseite nennt als empfohlene Basis “PHP Version 8.3 oder höher”. Sie enthält außerdem eine Warnung, die schwerer wiegt als die Empfehlung: WordPress “läuft weiterhin auf PHP 7.4+ und MySQL 5.5.5+, aber diese Versionen haben das offizielle Ende ihrer Lebensdauer erreicht und können Ihre Website Sicherheitslücken aussetzen”.

Das ist die ganze Falle in einem Satz. WordPress weigert sich nicht, auf einem uralten PHP-Zweig zu starten. Es läuft, sieht normal aus und sitzt still auf einem Interpreter, der seit Jahren keinen Sicherheits-Fix mehr bekommen hat.

Die Datenbank

Dieselbe Seite verlangt “MariaDB 10.11+ oder MySQL 8.0+”. Ältere Engines funktionieren weiterhin, weshalb so viele Websites darauf laufen. Die eigene Nutzungsstatistik von WordPress zeigt, dass etwa jede sechste Installation eine MySQL-5.x-Version meldet, deutlich unter der genannten Untergrenze, wobei allein MySQL 5.7 rund 12 Prozent der meldenden Websites ausmacht.

Die Folge ist nicht, dass die Website kaputtgeht. Die Folge ist, dass Ihnen Engine-Verbesserungen entgehen, die genau für die schwer cachebaren Lasten zählen, und dass Sie eine Migration erben, die Sie ohnehin irgendwann durchführen müssen.

HTTPS und die Erweiterungen

HTTPS ist als “für jede Installation erforderlich” aufgeführt, nicht als Empfehlung. Ein Hoster, der ein Zertifikat im Jahr 2026 noch als kostenpflichtigen Zusatz behandelt, sagt Ihnen damit etwas über den Rest des Tarifs.

Darüber hinaus nennt das WordPress Hosting Handbook json und mysqli als erforderlich sowie curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml und zip als dringend empfohlen. Zwei davon lohnt es sich, gegenüber einem Vertriebsmitarbeiter zu benennen. Ohne zip lassen sich Plugin- und Core-Update-Pakete nicht entpacken. Ohne imagick fallen Medien-Uploads auf eine schwächere Bildbibliothek zurück, und Ihre Bilder werden schlechter, bevor überhaupt jemand ein Optimierungs-Plugin anfasst.

Die PHP-Version ist der wirksamste Posten auf der Rechnung

Von allem, was ein Hoster kontrolliert, hat der PHP-Zweig das beste Verhältnis von Wirkung zu Aufwand. In den meisten Panels ist es ein Auswahlmenü. Nichts wird neu gebaut, nichts migriert, und eine Website, die ohnehin kompatibel war, läuft ab sofort einfach auf einem schnelleren und besser unterstützten Interpreter.

Dass er jahrelang unverändert bleibt, hat organisatorische und keine technischen Gründe. Niemand ist zuständig. Die Agentur, die die Website gebaut hat, ist weitergezogen, der Hoster ändert es nicht eigenmächtig, weil ein fataler Fehler in einem verwaisten Plugin dann seine Schuld wäre, und das Unternehmen hat keinen Anlass, über eine Zahl nachzudenken, die ihm nie gezeigt wurde.

Die erste Frage an einen künftigen Hoster ist deshalb keine Frage nach Geschwindigkeit. Sie lautet, welchen PHP-Zweig der Tarif standardmäßig ausführt, welche Zweige er anbietet und ob Sie ihn selbst wechseln können, ohne ein Ticket zu eröffnen. Ein Hoster, der nur einen Zweig anbietet, den WordPress nicht mehr empfiehlt, hat damit zugleich jede andere Frage beantwortet.

Testen Sie im Staging, schalten Sie niemals die Produktion um. Eine Website, die von PHP 7.4 auf 8.3 wechselt, fördert meist zwei oder drei Deprecation-Hinweise aus ungepflegten Plugins zutage, und das sind die eigentlichen Kosten. Kalkulieren Sie einen halben bis einen ganzen Entwicklertag ein, ausführlicher behandelt in unserem Leitfaden zu WordPress-Entwicklerhonoraren und den richtigen Fragen.

Die Sicherheitshälfte des PHP-Arguments

Leistung ist der Grund, den Menschen für ein PHP-Upgrade angeben. Sicherheit ist der Grund, auf den es tatsächlich ankommt, und sie ist messbar statt diskutierbar.

PHP veröffentlicht einen eigenen Zeitplan der unterstützten Versionen. Jeder Zweig erhält zwei Jahre aktiven Support und zwei weitere Jahre ausschließlich Sicherheits-Fixes. Stand September 2026 heißt das: PHP 8.2 bekommt bis zum 31. Dezember 2026 nur noch Sicherheits-Fixes, PHP 8.3 bis zum 31. Dezember 2027, nachdem der aktive Support am 31. Dezember 2025 endete. PHP 8.4 bleibt bis zum 31. Dezember 2026 im aktiven Support mit Sicherheits-Fixes bis zum 31. Dezember 2028, PHP 8.5 bis zum 31. Dezember 2027 mit Sicherheits-Fixes bis zum 31. Dezember 2029. Alles Ältere ist erledigt: PHP 8.1 endete am 31. Dezember 2025, PHP 8.0 am 26. November 2023 und PHP 7.4 am 28. November 2022.

Halten Sie das gegen das, was WordPress-Websites tatsächlich ausführen. Die WordPress-Statistikseite meldet rund 38,8 Prozent der Installationen auf einem Zweig, der vollständig am Ende seiner Lebensdauer ist, und etwa 23,2 Prozent noch auf PHP 7.4 oder älter. Nur rund 36,4 Prozent erfüllen die von WordPress empfohlene Basis PHP 8.3, und weitere 24,8 Prozent sitzen auf PHP 8.2, das Ende dieses Jahres den Sicherheits-Support verliert.

Eine Mehrheit der WordPress-Websites läuft also auf einem Interpreter, der entweder keine Sicherheits-Fixes erhält oder nur Monate davon entfernt ist, und fast immer ist es eine Hosting-Einstellung, die niemand angesehen hat. Die Korrektur kostet weniger als eine Plugin-Lizenz, weshalb unsere Checkliste zur WordPress-Sicherheitshärtung sie als Schritt eins behandelt.

Die Caching-Schichten in der Reihenfolge, in der eine Anfrage sie trifft

Fast jede Leistungsbehauptung eines Hosters ist eine Behauptung über Caching, und fast jeder Käufer hört sie als ein einziges undifferenziertes Versprechen. Es gibt vier verschiedene Schichten, sie liegen in einer festen Reihenfolge, und jede spart eine andere Art von Arbeit. Die Reihenfolge unten ist die, die eine einzelne Anfrage durchläuft, und eine Anfrage, die eine frühere Schicht beantwortet, erreicht die späteren nie.

Der Edge- oder CDN-Cache

Das Erste, was eine Anfrage trifft, ist ein Cache vollständig außerhalb Ihres Servers, in einem Netz von Points of Presence in der Nähe des Besuchers. Liegt die Antwort dort bereits, sieht Ihr Hoster die Anfrage überhaupt nie.

Diese Schicht spart Netzwerkdistanz ebenso wie Rechenzeit. Ein Besucher in Manchester, der einen Edge-Knoten in London erreicht, vermeidet einen transatlantischen Umweg. Für statische Assets ist sie nahezu kostenlos und immer sinnvoll. Für HTML ist sie mächtig, aber an Bedingungen geknüpft, denn dem Edge muss gesagt werden, welche Antworten persönlich sind und niemals geteilt werden dürfen.

Der Full Page Cache

Die zweite Schicht speichert das fertige HTML einer Seite, damit PHP und die Datenbank nicht erneut laufen. Das WordPress Hosting Handbook empfiehlt einen Reverse Proxy wie NGINX oder Varnish, der “die Ausgabe direkt in den Serverspeicher oder auf die Festplatte schreibt”, und ergänzt die Regel, die darüber entscheidet, ob die Schicht überhaupt funktioniert: “Es ist eine gute Idee, alle eingeloggten Benutzer vom Cache auszuschließen, weil sie personalisierte Inhalte sehen sollen.”

Das ist die Schicht, die günstiges Hosting schmeichelhaft aussehen lässt. Wenn sie funktioniert, bekommt ein Besucher eine Datei ausgeliefert, und PHP-Version, Datenbank-Engine und Plugin-Anzahl spielen für diese Anfrage keine Rolle mehr, weil keines davon ausgeführt wird.

Der Object Cache

Die dritte Schicht cacht die Ergebnisse einzelner Datenbankabfragen und berechneter Werte. WordPress liefert sie standardmäßig mit, aber nicht persistent. Die Dokumentation zu WP_Object_Cache ist deutlich: “Standardmäßig ist der Object Cache nicht persistent. Das bedeutet, dass die im Cache abgelegten Daten nur im Arbeitsspeicher und nur für die Dauer der Anfrage liegen.”

Persistent wird er, indem Redis oder Memcached per Drop-in dahintergestellt wird, was den Cache von etwas, das bei jedem Seitenaufruf neu aufgebaut wird, in etwas verwandelt, das über Anfragen und Besucher hinweg geteilt wird. Es ist die Schicht, auf die es ankommt, sobald Seiten nicht mehr als Ganzes cachebar sind, und die in günstigen Tarifen am häufigsten fehlt.

Der Opcode-Cache

Die vierte Schicht ist OPcache, die den kompilierten Bytecode Ihrer PHP-Dateien im gemeinsam genutzten Speicher hält, damit der Interpreter sie nicht bei jeder Anfrage erneut parst und kompiliert. Das Hosting Handbook hält fest, dass “für produktive WordPress-Umgebungen empfohlen wird, OPcache für Web-Anfragen zu aktivieren und für die Website oder die Hosting-Plattform zu dimensionieren”.

Daraus folgt etwas für Deployments. Weil OPcache kompilierten Code hält, muss ein Deployment ihn zurücksetzen oder die geänderten Dateien invalidieren, sonst führt der Server weiter die vorherige Version aus. Ein Hoster, der Ihnen nicht sagen kann, wie OPcache invalidiert wird, ist ein Hoster, bei dem ein Plugin-Update mehrere Minuten lang scheinbar nichts bewirkt.

Warum eine Broschüren-Website auf fast jedem Hoster schnell ist

Verfolgt man diese vier Schichten zu Ende, ist die Schlussfolgerung für die Hosting-Branche unangenehm. Wenn jeder Besucher anonym und jede Seite cachebar ist, beantwortet der Full Page Cache nahezu den gesamten Verkehr, und die Spezifikation der Maschine dahinter fällt kaum ins Gewicht.

Deshalb kann eine fünfseitige Firmenwebsite auf einem 4-£-Tarif mit einem ordentlichen Page Cache eine bessere Server-Antwortzeit erreichen als eine überladene Website auf einem 200-£-Tarif. Die günstige Website liefert Dateien aus. Die teure führt PHP aus.

Die Zahl, auf die es ankommt, ist die Time to First Byte, die selbst kein Core Web Vital ist. Googles Überblick über die Web Vitals führt sie unter den unterstützenden Metriken, nützlich zum “Diagnostizieren von LCP-Problemen”, die durch langsame Server-Antwortzeiten verursacht werden. Genau dieser Ausschnitt der Seitengeschwindigkeit wird vom Hoster kontrolliert.

WordPress sieht das ähnlich genug, um es in den Core geschrieben zu haben. Der in WordPress 6.1 ergänzte Site-Health-Test für den Full Page Cache prüft, “ob die Website eine Full-Page-Cache-Lösung nutzt und ob die Antwortzeit akzeptabel ist”, mit einem Standardschwellenwert von 600 Millisekunden. Liegt Ihre Website darüber, obwohl ein Page Cache angeblich aktiv ist, funktioniert der Cache nicht, und zusätzliche CPU verdeckt das nicht.

Für eine Broschüren-Website ist ein Hosting-Upgrade daher meist der falsche Kauf. Langsam machen sie häufiger ein überdimensioniertes Hero-Bild, ein Page Builder, der Hunderte Kilobyte CSS ausliefert, oder sechs Schriftschnitte, was das Argument unseres Vergleichs von Elementor und einem eigenen Theme ist.

Eingeloggter Verkehr und WooCommerce brechen das Modell

Alles bisher Gesagte setzt voraus, dass der Page Cache antworten kann. In dem Moment, in dem Besucher sich anmelden, bricht diese Annahme zusammen und die Ökonomie des Hostings kehrt sich um.

WooCommerce dokumentiert das direkt. Seine Caching-Hinweise verlangen, Warenkorb, Mein Konto und Kasse vom Page Caching auszunehmen, weil diese Seiten “dynamisch bleiben müssen, da sie Informationen anzeigen, die für den aktuellen Kunden und seinen Warenkorb spezifisch sind”. Aufgeführt werden auch Cookies, die den Cache umgehen müssen, darunter woocommerce_cart_hash, woocommerce_items_in_cart und wp_woocommerce_session_, sowie der Rat, _wc_session_ vom Datenbank-Caching auszuschließen.

Als Hosting-Spezifikation gelesen sagt das etwas Unmissverständliches. In einem Shop sind genau die Seiten, die Umsatz erzeugen, die Seiten, die der Page Cache nicht anfassen kann. Katalog- und Produktseiten lassen sich für anonyme Besucher cachen. Warenkorb und Kasse niemals, für niemanden.

Dasselbe gilt für Mitgliederseiten, Lernplattformen, Foren und jede Website mit einem Kundenportal. Sobald ein Session-Cookie gesetzt ist, liefern die meisten Caching-Plugins diesem Besucher überhaupt kein gecachtes HTML mehr aus, also führt jeder Klick PHP aus und trifft die Datenbank. Hier hört der Object Cache auf, eine Optimierung zu sein, und wird tragend, und hier tut ein günstiger Tarif auf eine Weise weh, die kein synthetischer Startseitentest zeigt, wie in warum Ihr WooCommerce-Shop langsam ist beschrieben.

Was Managed WordPress Hosting tatsächlich enthält

Nimmt man die Adjektive weg, löst sich Managed Hosting in ein recht konsistentes Bündel an Betriebsarbeit auf. Es lohnt sich, diese Arbeit ehrlich zu bepreisen, denn für ein Unternehmen ohne technisches Personal ist sie oft günstiger eingekauft als selbst erledigt.

Updates

Managed-Tarife spielen Core-Updates meist automatisch ein, manchmal auch Plugin-Updates, gelegentlich mit einer visuellen Regressionsprüfung davor und danach. Nützlich zu wissen ist, wie viel WordPress bereits kostenlos erledigt.

WordPress aktualisiert kleinere Core-Releases und Übersetzungsdateien seit Jahren standardmäßig automatisch, und seit 5.6 sind bei Neuinstallationen automatische Updates aktiviert, sowohl für kleinere als auch für große Core-Releases, sofern kein Versionskontroll-Checkout erkannt wird, während bestehende Installationen das ältere Verhalten behalten. Der bezahlte Teil sind also nicht die kleinen Core-Updates. Es sind die Plugin-Updates, das Zurückrollen, wenn eines kaputtgeht, und jemand, der bemerkt, dass es kaputtgegangen ist.

Staging und Backups

Eine Staging-Umgebung auf Knopfdruck ist wirklich wertvoll und wirklich lästig, wenn man sie selbst bauen muss. Beurteilen Sie sie an zwei Details statt an ihrer bloßen Existenz: ob das Zurückspielen von Staging in die Produktion die Live-Datenbank überschreibt, was seit der Kopie eingegangene Bestellungen und Kommentare verwerfen würde, und ob die Staging-Website für Suchmaschinen und für den Mailversand gesperrt ist.

Firewall und Malware-Scanning

Die meisten Managed-Tarife enthalten eine Web Application Firewall am Edge und irgendeine Form von Malware-Scanning. Die Firewall ist echter Gegenwert, denn virtuelles Patchen auf Netzwerkebene verschafft Zeit zwischen der Veröffentlichung einer Plugin-Schwachstelle und Ihrem Update.

Scanning ist schwächer, als es klingt. Es erkennt in der Regel bekannte Signaturen schädlicher Dateien, fängt also Massenware ab und übersieht gezielte Angriffe. Behandeln Sie es als Rauchmelder und nicht als Schloss, und behalten Sie die Härtungsarbeit auf Ihrer Seite der Linie.

Was Managed Hosting wegnimmt

Die Einschränkungen sind die Hälfte, die niemand liest, und sie wiegen meist schwerer als die Funktionen. Es gibt für sie vertretbare Gründe, aber es sind die Gründe des Anbieters und nicht Ihre.

Das klarste veröffentlichte Beispiel ist die Liste unzulässiger Plugins von WP Engine, die ganze Kategorien verbietet statt einzelner Übeltäter. Caching-Plugins sind verboten, weil sie “mit der eingebauten Caching-Struktur unserer Plattform in Konflikt geraten können”. Backup-Plugins sind mit der Begründung verboten, sie würden “Ihre Website unnötig aufblähen”. Plugins für verwandte Beiträge sind als “extrem datenbankintensiv” verboten. Plugins mit dokumentierten Schwachstellen sind rundheraus verboten, ebenso Plugins, die Plattformfunktionen doppeln.

Jede einzelne dieser Regeln ist eine vernünftige technische Entscheidung. Zusammengenommen bedeuten sie, dass Ihre Website nicht in der Weise portabel ist, die Sie angenommen haben. Hängt Ihr Aufbau an der Konfiguration eines bestimmten Caching-Plugins, zieht diese Konfiguration nicht mit um.

Shell-Zugang ist die andere häufige Auslassung. Viele Managed-Tarife bieten überhaupt kein SSH oder eine eingeschränkte Shell ohne WP-CLI, was Routinearbeit wie ein Massen-Suchen-und-Ersetzen nach einem Domainwechsel in ein Support-Ticket verwandelt. Zwei weitere Punkte überraschen Käufer: Lang laufende Prozesse sind häufig gedeckelt, sodass ein Import von 50.000 Produkten in Stücke zerlegt werden muss, und ausgehende Mail wird oft blockiert oder gedrosselt, in der Annahme, eine kompromittierte Website werde für Spam benutzt.

Die Leistungsversprechen, die einen Test nicht überstehen

Hosting-Marketing lebt von einer kleinen Auswahl an Behauptungen, die in dem Moment auseinanderfallen, in dem Sie fragen, was gemessen wurde.

“Zwanzigmal schneller” nennt fast nie eine Vergleichsgrundlage. Schneller als was, auf welcher Seite, mit welchen Plugins, bei welcher Parallelität? Ohne diese vier Angaben ist die Zahl ein Verhältnis zwischen zwei ungenannten Größen.

“Unbegrenzte Bandbreite” steht in derselben Tabelle neben einem monatlichen Besuchskontingent. Bandbreite ist bei einer WordPress-Website ohnehin selten die Grenze. Die Grenze ist die gleichzeitige PHP-Ausführung, die der Tarif meist überhaupt nicht erwähnt.

“99,9 Prozent Verfügbarkeit” klingt absolut und ist es nicht. Über einen Monat mit dreißig Tagen erlaubt sie rund 43 Minuten Ausfall. Drei Neunen sind ein üblicher Wert für Shared Hosting, vier Neunen erlauben etwa vier Minuten im Monat, und der Unterschied ist der zwischen einer Unannehmlichkeit und einem Ausfall, den niemand bemerkt. Lesen Sie nach, was die Gutschrift tatsächlich zahlt, wenn der Wert verfehlt wird, ein Thema, das wir gesondert in Uptime-SLAs, die etwas bedeuten behandelt haben.

Die letzte Behauptung ist die häufigste und die irreführendste: ein Screenshot eines Speedtests auf einer gecachten Startseite. Das misst den Page Cache, nicht den Hoster, und der Page Cache ist die eine Komponente, die überall ungefähr gleich ist.

Wie man einen Hoster richtig testet

Hosting zu testen ist nicht schwierig, aber es muss auf dem Pfad geschehen, der den Server tatsächlich fordert. Fünf Schritte, der Reihe nach.

Erstens: Testen Sie einen nicht gecachten Pfad. Hängen Sie eine eindeutige Query-Zeichenfolge an, um den Page Cache auszuhebeln, oder rufen Sie eine Seite ab, die nie gecacht wird, etwa einen Warenkorb oder eine Kontoseite. Wenn Sie keine Anfrage stellen können, die PHP ausführt, testen Sie einen Dateiserver.

Zweitens: Wiederholen Sie es. Eine einzelne Anfrage sagt nichts über die Streuung, und in der Streuung zeigt sich günstiges Hosting. Nehmen Sie mindestens zwanzig Messwerte und lesen Sie das 75. Perzentil ab, die Statistik, die Google für Felddaten verwendet.

Drittens: Testen Sie von dort, wo Ihre Besucher sind. Eine Antwortzeit, die aus dem Rechenzentrum nebenan gemessen wird, ist nicht die Antwort, die Ihre Kunden in Leeds erhalten.

Viertens: Testen Sie unter Parallelität. Setzen Sie zehn oder zwanzig gleichzeitige, nicht cachebare Anfragen ab. Das ist der einzige Test, der die Erschöpfung der PHP-Worker sichtbar macht, und genau die legt einen Shop während einer Aktion lahm.

Fünftens: Vergleichen Sie Gleiches mit Gleichem, also gleicher PHP-Zweig, gleicher Plugin-Satz, gleiches Theme, gleiches Inhaltsvolumen. Eine Migration, die den Plugin-Stack gleichzeitig mit dem Hoster wechselt, hat über keines von beidem etwas bewiesen. Wenn Sie das an einer echten Website statt an einem Kandidaten durchgeführt haben wollen, ist genau das ein WordPress-Performance-Audit.

Welche Core Web Vitals das Hosting tatsächlich bewegt

Bei den Core Web Vitals werden Hosting-Versprechen und Suchrankings vermischt, deshalb lohnt es sich, genau zu benennen, welche Metrik ein Server beeinflussen kann.

Es sind drei, bewertet am 75. Perzentil der Seitenaufrufe und getrennt nach Mobil und Desktop. Largest Contentful Paint misst das Laden und ist gut bei 2,5 Sekunden oder weniger, verbesserungswürdig zwischen 2,5 und 4,0 Sekunden und schlecht jenseits von 4,0. Interaction to Next Paint misst die Reaktionsfähigkeit und ist gut bei 200 Millisekunden oder weniger, verbesserungswürdig bis 500 Millisekunden und schlecht darüber. Cumulative Layout Shift misst die visuelle Stabilität und ist gut bei 0,1 oder weniger, verbesserungswürdig bis 0,25 und schlecht darüber. First Input Delay wurde eingestellt und durch INP ersetzt, das 2024 zu einem stabilen Core Web Vital wurde.

Hosting bewegt davon genau eine direkt. Die Server-Antwortzeit ist Teil des LCP, also nimmt ein Hoster, der 400 Millisekunden davon abschneidet, jedem Besucher 400 Millisekunden vom LCP. Auf einem langsamen Hoster kann das der Unterschied zwischen Bestehen und Durchfallen sein.

Für CLS tut es fast nichts, denn der entsteht durch Bilder ohne Abmessungen und spät ladende Schriften, und für INP sehr wenig, das von JavaScript im Haupt-Thread dominiert wird. Die Regel lautet: Ist der LCP schlecht und liegt Ihre ungecachte Server-Antwort über der 600-Millisekunden-Marke, die WordPress markiert, ist Hosting Teil des Problems. Ist die Antwort komfortabel und der LCP trotzdem schlecht, liegt der Fehler in der Seite, und unser Leitfaden zum Bestehen der Core Web Vitals 2026 ist der bessere Ort für das Budget.

Backups und der Teil, den niemand prüft

Jeder Tarif oberhalb des günstigsten wirbt mit Backups. Fast niemand, der einen kauft, stellt die Fragen, die darüber entscheiden, ob das Backup etwas wert ist.

Ob jemand jemals eines zurückgespielt hat

Das NCSC formuliert es in seinem Leitfaden für kleine Organisationen unmissverständlich: Wenn Sie ein Backup erstellt haben, “ist es wichtig, dass Sie wissen, wie Sie es wiederherstellen, und prüfen, dass es alle Ihre wichtigen Daten enthält”. Ein ungetestetes Backup ist eine Überzeugung, keine Kontrolle.

Fragen Sie den Anbieter, wie eine Wiederherstellung angestoßen wird, wie lange sie für eine Website Ihrer Größe dauert und ob mit der Datenbank auch das Uploads-Verzeichnis zurückkommt. Machen Sie es dann einmal im Staging, bevor Sie es brauchen. Der Fehlerfall, auf den Sie achten müssen, ist eine Wiederherstellung, die Dateien zurückbringt, aber nicht die Datenbank, oder eine, die gelingt und dabei still alles verliert, was seit der Kopie entstanden ist.

Aufbewahrung und Häufigkeit

Tägliche Backups mit sieben Tagen Aufbewahrung klingen großzügig, bis man betrachtet, wie eine WordPress-Website tatsächlich ausfällt. Eine verunstaltete Website fällt in Stunden auf. Eine Kompromittierung, die still Spam-Links in alte Beiträge einschleust, fällt erst in Wochen auf, und bis dahin enthält jede aufbewahrte Kopie die Einschleusung.

Dreißig Tage sind für alles Kommerzielle eine sinnvollere Untergrenze, und eine separate Monatskopie ist eine günstige Versicherung. Ein Shop braucht außerdem ein Datenbank-Backup-Intervall, das am Bestellvolumen gemessen wird, denn vier Stunden Bestellungen zu verlieren gehört nicht in dieselbe Kategorie wie vier Stunden Blog-Änderungen.

Wo die Kopie liegt und in welchem Format

Der andere Punkt des NCSC lautet, dass ein Backup, das am Live-System hängen bleibt, nicht getrennt ist: Ein Gerät, das Backups hält, “sollte nicht mit Ihrem Gerät verbunden bleiben, wenn es nicht benutzt wird”, weil alles, was die Quelle kompromittiert, es erreichen kann. Auf Hosting übertragen teilt ein Backup, das im selben Konto liegt und nur über dasselbe Panel wiederherstellbar ist, das Schicksal dessen, was es schützt.

Das Format ist die feinere Variante desselben Problems. Wenn der einzige Weg, ein Backup zu lesen, die Wiederherstellungsschaltfläche des Anbieters ist, haben Sie eine Bequemlichkeitsfunktion und keine portable Kopie. Die Prüfung lautet, ob Sie heute einen einfachen SQL-Dump und ein Dateiarchiv herunterladen können, die ein kompetenter Entwickler anderswo aufsetzen könnte. Falls nicht, hört Migration auf, eine technische Entscheidung zu sein, und wird zur Verhandlung.

Wo die Daten liegen und warum das für britische Käufer zählt

Hosting-Entscheidungen sind Datenschutzentscheidungen, und für ein britisches Unternehmen lautet die Frage nicht, wo die Firma registriert ist, sondern wo personenbezogene Daten liegen und wer sie erreichen kann.

Der Leitfaden der ICO zu internationalen Übermittlungen formuliert einen dreistufigen Test. Wenn die UK-DSGVO auf Ihre Verarbeitung anwendbar ist, Sie die Übermittlung anstoßen und die empfangende Organisation eine eigene juristische Person ist, führen Sie eine beschränkte Übermittlung durch. Die ICO stellt ausdrücklich fest, dass die Regeln “für alle beschränkten Übermittlungen gelten, auch für kleine und seltene”, und jede Organisation erfassen, die personenbezogene Daten verarbeitet, “einschließlich Einzelunternehmern und Selbstständigen”.

Beachten Sie, was als Übermittlung zählt. Die ICO zählt dazu sowohl das Senden personenbezogener Daten als auch das “Zugänglichmachen” gegenüber einer Organisation außerhalb des Vereinigten Königreichs. Ein Support-Team im Ausland mit Zugriff auf Ihr Backend oder ein extern gelagertes Backup, das in eine andere Region repliziert wird, kann diese Definition jeweils erfüllen.

Jede beschränkte Übermittlung muss durch eines von drei Dingen gedeckt sein: britische Angemessenheitsregelungen für das Zielland, geeignete Garantien wie das International Data Transfer Agreement, das Addendum oder verbindliche interne Datenschutzvorschriften, oder eine Ausnahme. Wo Sie sich auf Garantien stützen, erwartet die ICO zusätzlich eine Risikobewertung der Übermittlung, die zeigt, dass der Schutz danach nicht wesentlich geringer ist. Nichts davon macht einen ausländischen Hoster unbrauchbar. Es macht ihn zu einer Entscheidung, die dokumentiert werden muss, und Dokumentieren ist vor einer Migration weit günstiger als während einer Auskunftsanfrage.

Was eine Auftragsverarbeitungsvereinbarung enthalten sollte

Ihr Hoster ist Auftragsverarbeiter und Sie sind Verantwortlicher, ein schriftlicher Vertrag ist also nicht optional. Die ICO listet auf, was dieser Vertrag enthalten muss, und vier ihrer Klauseln lesen sich unmittelbar als Hosting-Fragen.

Unterauftragsverarbeiter kommen zuerst. Nach Artikel 28(3)(d) darf der Auftragsverarbeiter ohne Ihre Genehmigung keinen weiteren Verarbeiter hinzuziehen, muss Sie über beabsichtigte Änderungen informieren, damit Sie widersprechen können, und muss gleichwertige Pflichten in der Kette weitergeben. In Hosting-Begriffen sind das das CDN, das Backup-Ziel, das Mail-Relay und der zugrunde liegende Cloud-Anbieter. Fordern Sie die Liste an.

Sicherheit ist der zweite Punkt. Artikel 28(3)(c) verlangt Maßnahmen, die Artikel 32 genügen, und die ICO buchstabiert aus, was dazugehört: Verschlüsselung und Pseudonymisierung, Widerstandsfähigkeit der Verarbeitungssysteme, “die Fähigkeit, den Zugang zu personenbezogenen Daten bei einem Vorfall wiederherzustellen”, und “Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der Maßnahmen”. Das ist Wiederherstellungstest, geschrieben ins Gesetz statt in einen Best-Practice-Artikel.

Drittens der Ausstieg. Nach Artikel 28(3)(g) muss der Auftragsverarbeiter nach Ihrer Wahl alle personenbezogenen Daten am Ende des Vertrags löschen oder zurückgeben und vorhandene Kopien löschen. Ein Anbieter, dessen Backups seine Plattform nicht verlassen können, hat neben einem praktischen auch ein vertragliches Problem. Viertens die Prüfung, die Ihnen nach Artikel 28(3)(h) Anspruch auf die zum Nachweis der Einhaltung nötigen Informationen sowie auf seine Zertifizierungen und Berichte gibt.

Die Stufen und was sie im Vereinigten Königreich kosten

Vier Stufen decken fast jede WordPress-Website ab, und die Grenzen zwischen ihnen werden von der nicht cachebaren Last gesetzt und nicht vom Verkehr. Die Bänder unten sind das, was britische Käufer typischerweise pro Monat zahlen. Es sind Kategoriebänder und keine Preisliste eines einzelnen Anbieters, behandeln Sie sie also als Plausibilitätsprüfung für ein Angebot und nicht als Angebot.

Shared Hosting, 3 bis 15 £ im Monat

Für eine cachebare Broschüren-Website völlig ausreichend und ein wirklich schlechtes Geschäft, sobald sich jemand anmeldet. Sie teilen sich PHP-Kapazität mit Nachbarn, die Sie nicht sehen, also beißt unter Last die Streuung und nicht der Durchschnitt. Prüfen Sie zuerst den PHP-Zweig, denn in dieser Stufe ballen sich die Interpreter am Ende ihrer Lebensdauer.

Managed WordPress, 20 bis 400 £ im Monat

Die richtige Standardwahl für Content-Websites und kleine Shops. Sie kaufen Updates, Staging, eine Firewall, einen persistenten Object Cache und ein Support-Team und bezahlen dafür mit den oben genannten Einschränkungen. Der Bereich von 20 bis 100 £ deckt eine einzelne Website mit mäßigem Verkehr ab. Darüber zahlen Sie meist für mehr Websites, mehr Besuche oder mehr PHP-Worker.

VPS oder Cloud mit eigenem Stack, 15 bis 120 £ plus Betreuung

Eine bescheidene Cloud-Instanz kostet 15 bis 120 £ im Monat, aber die Maschine ist der günstige Teil. Jemand muss das Betriebssystem patchen, den Reverse Proxy abstimmen, den Object Cache betreiben und Backups erledigen, und das einzukaufen kostet weitere 150 bis 600 £ im Monat. Lohnt sich, wenn die nicht cachebare Last real ist oder wenn Ihr Stack Anforderungen hat, die eine Managed-Plattform verbietet.

Maßgeschneiderte Infrastruktur, ab 400 £ im Monat

Deployments über mehrere Regionen, Ereignisse mit hoher Parallelität, strikte Datenresidenz oder eine Architektur, in der WordPress eine Komponente unter mehreren ist. Hosting hört auf, eine Produktentscheidung zu sein, und wird Teil des Baus, so gehen wir es innerhalb eines Auftrags zur Website-Entwicklung an.

Dimensionierung nach nicht cachebaren Anfragen, nicht nach Seitenaufrufen

Hosting-Tarife werden in monatlichen Besuchen verkauft, weil das eine Zahl ist, die Käufer kennen. Für die Kapazitätsplanung ist sie nahezu nutzlos, denn 100.000 gecachte anonyme Seitenaufrufe kosten fast nichts, und 10.000 eingeloggte können einen kleinen Server sättigen.

Die Zahl, auf die es ankommt, sind gleichzeitige nicht cachebare Anfragen, und die Rechnung ist einfach. Ein PHP-Worker bearbeitet eine nicht cachebare Anfrage zur Zeit. Die Zahl der benötigten Worker ist ungefähr die Spitze der nicht cachebaren Anfragen pro Sekunde multipliziert mit der durchschnittlichen PHP-Antwortzeit in Sekunden. Zwanzig nicht cachebare Anfragen pro Sekunde zu je 400 Millisekunden brauchen etwa acht Worker, um Schritt zu halten, und Sie wollen mindestens die Hälfte davon noch einmal als Reserve.

Stellen Sie also zwei Fragen, die keine Tarifseite beantwortet: Wie viele PHP-Worker betreibt dieser Tarif, und wie hoch ist das Speicherlimit pro Prozess? Beide Zahlen existieren und keine von beiden wird üblicherweise veröffentlicht. Der Support nennt sie normalerweise, wenn Sie direkt fragen, und die Antwort sagt mehr über den Tarif als jeder Benchmark auf der Seite.

Schätzen Sie danach Ihre eigene Seite ehrlich ein. Zählen Sie den Anteil der Sitzungen, die eingeloggt sind, den Kassen- und Kontoverkehr in Ihrer stärksten Stunde statt in Ihrer durchschnittlichen, und jeden Admin-Ajax- oder REST-Verkehr, den Ihre Plugins im Hintergrund erzeugen, der in der Analytics unsichtbar und im Serverlog sehr sichtbar ist.

Plugin-Anzahl und redaktionelles Volumen sind Hosting-Entscheidungen

Zwei Dinge innerhalb der Website bestimmen, wie viel Hosting sie braucht, und beide werden meist als Inhaltsentscheidungen von Menschen behandelt, die die Rechnung nie sehen.

Das Erste ist der Plugin-Stack. Jedes aktive Plugin ergänzt automatisch geladene Optionen, die bei jeder Anfrage geladen werden, geplante Ereignisse, die bei Besucheranfragen auslösen, weil WordPress-Cron kein echter Cron ist, und Abfragen pro Seitenaufbau. Dreißig Plugins auf einer gecachten Broschüren-Website sind überlebbar. Dreißig Plugins auf einem Shop, auf dem nichts cacht, bedeuten dreißig Plugins, die bei jedem Kassenschritt ausgeführt werden. Der WordPress-Core hat eine grobe Vorstellung davon, wann das zu beißen beginnt: Die Site-Health-Prüfung für den persistenten Object Cache empfiehlt Object Caching, sobald eine Website Schwellen wie 2.000 Beiträge, 2.000 Benutzer oder 600 automatisch geladene Optionen überschreitet.

Das Zweite ist das redaktionelle Volumen. Revisionen sammeln sich standardmäßig ohne Grenze an, Mediatheken wachsen auf Zehntausende Dateien mit jeweils mehreren erzeugten Größen, und beides bläht die Datenbank und das Backup-Fenster auf. Eine Website, die fünf Jahre lang täglich veröffentlicht, ist ein deutlich anderes Hosting-Problem als dasselbe Design mit monatlicher Veröffentlichung, und nichts auf der Tarifseite bildet das ab. Den Aufbau zu prüfen und nicht den Tarif ist das, was ein WordPress-Entwickler tun sollte, bevor er eine Migration anbietet.

Der Reihe nach auswählen

Arbeiten Sie es in dieser Reihenfolge ab, und die Entscheidung trifft sich meist von selbst. Ermitteln Sie, welcher Anteil Ihres Verkehrs nicht cachebar ist, denn diese eine Zahl wählt Ihre Stufe. Bestätigen Sie, dass PHP-Zweig und Datenbankversion die veröffentlichte Basis erfüllen, denn ein Tarif, der dort scheitert, ist unabhängig vom Preis disqualifiziert. Klären Sie, welche Caching-Schichten enthalten sind und welche Sie selbst beisteuern müssen. Fragen Sie, wo Backups liegen, in welchem Format und ob Sie heute eines herunterladen können. Lesen Sie dann die Auftragsverarbeitungsklauseln zu Unterauftragsverarbeitern, Datenstandort und Löschung am Vertragsende. Erst nach all dem bedeutet der Preis etwas, denn bis dahin vergleichen Sie Produkte, die nicht dasselbe Produkt sind.

Mecanik erledigt das als festen Arbeitsblock vor jeder Migration, meist begleitend zu einem Auftrag zur Website-Entwicklung, und übernimmt es als laufende Betreuung über unseren Dienst WordPress-Entwickler mieten. Wenn Sie abwägen, wohin sich die Plattform selbst bewegt, ist unser Beitrag zu WordPress 7.0 und dem AI-Client im Core eine sinnvolle Ergänzung zu diesem hier.

Häufig gestellte Fragen

Wie viel sollte WordPress Hosting im Vereinigten Königreich kosten? Das hängt fast ausschließlich davon ab, wie viel Ihres Verkehrs sich cachen lässt. Eine Broschüren-Website mit anonymen Besuchern ist mit 3 bis 15 £ im Monat auf Shared Hosting gut bedient. Eine Content-Website oder ein kleiner Shop gehört meist auf Managed WordPress Hosting für 20 bis 100 £ im Monat, steigend auf 100 bis 400 £ für stark frequentierte oder Multisite-Tarife. Ein Shop oder eine Mitgliederseite mit viel eingeloggtem Verkehr braucht typischerweise einen VPS oder Cloud-Stack für 15 bis 120 £ für die Maschine plus 150 bis 600 £ im Monat, wenn jemand anderes sie betreut.

Ist Managed WordPress Hosting das zusätzliche Geld wert? Ja, wenn Sie niemanden für den Betrieb haben, denn Sie kaufen Updates, Staging, Backups, eine Firewall und einen persistenten Object Cache, die Sie sonst selbst konfigurieren müssten. Der Preis dafür sind echte Einschränkungen. Anbieter verbieten routinemäßig Caching-Plugins, Backup-Plugins und datenbankintensive Plugins, halten oft den Shell-Zugang zurück, deckeln lang laufende Prozesse und blockieren ausgehende Mail. Prüfen Sie diese Grenzen gegen Ihren Aufbau, bevor Sie sich binden, nicht danach.

Welche PHP-Version braucht WordPress im Jahr 2026? WordPress empfiehlt PHP 8.3 oder höher. Es läuft weiterhin auf PHP 7.4 und darüber, aber diese Zweige sind am Ende ihrer Lebensdauer und erhalten keine Sicherheits-Fixes. PHP 8.1 endete am 31. Dezember 2025, PHP 8.0 am 26. November 2023 und PHP 7.4 am 28. November 2022, während PHP 8.2 bis zum 31. Dezember 2026 nur noch Sicherheits-Fixes bekommt. Rund 38,8 Prozent der WordPress-Installationen melden noch einen vollständig abgelaufenen Zweig.

Verbessert besseres Hosting die Core Web Vitals? Nur eine der drei, und nur indirekt. Die Server-Antwortzeit ist Teil des Largest Contentful Paint, ein schnellerer Hoster senkt den LCP also für jeden Besucher. Für den Cumulative Layout Shift tut er fast nichts, denn der entsteht durch Bilder ohne Abmessungen und spät ladende Schriften, und für Interaction to Next Paint sehr wenig, das von JavaScript im Haupt-Thread dominiert wird. Ist Ihre Server-Antwort bereits komfortabel, liegt das verbleibende Problem in der Seite.

Warum ist mein WooCommerce-Shop auf einem Tarif langsam, der sich als schnell bezeichnet? Weil die Seiten, auf die es ankommt, nicht gecacht werden können. WooCommerce verlangt, dass Warenkorb, Mein Konto und Kasse dynamisch bleiben, und setzt Session-Cookies, die den Page Cache für eingeloggte Käufer umgehen. Der Speedtest auf Ihrer Startseite misst eine gecachte Datei, während die Kasse bei jeder Anfrage PHP ausführt und die Datenbank trifft. Kapazität für nicht cachebare Anfragen und nicht die Zahl der gecachten Startseite ist das, was ein Shop tatsächlich kauft.