WordPress-Hosting ist 2026 eine Architekturentscheidung, nicht nur ein Tarif. Sie legen fest, wo PHP läuft, wo MySQL liegt, was an der Edge gecacht wird und welche Unterauftragsverarbeiter personenbezogene Daten Ihrer Nutzer in der EU verarbeiten.
Dieser Leitfaden vergleicht Managed Hosting, Cloud-IaaS/PaaS und Edge-Schichten. Danach geht es um PHP-Worker, Object Cache, WooCommerce-Grenzen an der Edge, den Datenspeicherort nach DSGVO und darum, wie CI/CD Umgebungen reproduzierbar hält. Ziel ist eine Entscheidungsgrundlage für Ihr Betriebsteam, keine Anbieterliste.
Beim Übergang von der Auswahl zur Messung helfen unser Beitrag zur WordPress-Geschwindigkeitsoptimierung und die Serverkapitel im WordPress Advanced Administration Handbook.
Was Managed-, Cloud- und Edge-Hosting für WordPress unterscheidet
Die drei Modelle lösen unterschiedliche Probleme. Wer sie falsch kombiniert, zahlt für Komplexität, ohne dort eine niedrigere TTFB zu bekommen, wo es zählt.
Managed WordPress-Hosting
Managed-Plattformen besitzen den Stack: PHP-FPM, Nginx oder LiteSpeed, MySQL, tägliche Backups, Staging und oft WP-CLI. Das Betriebssystem patchen Sie nicht selbst, aber Sie übernehmen die Grenzen des Anbieters bei gleichzeitigen Workern, Cron-Intervallen und unterstützten Object Caches.
Typischer Einsatz: Marketingseiten, Blogs, kleinere WooCommerce-Shops mit planbarem Traffic und Teams ohne eigenes DevOps. Schwäche: Stößt die Kasse oder das Backend an die Worker-Grenze, bleiben nur die Knöpfe „Tarif upgraden“ oder „umziehen“.
Cloud-Hosting (IaaS und PaaS)
Auf AWS, Google Cloud, Azure oder europäischen Alternativen bauen Sie VMs, eine verwaltete Datenbank, Load Balancer und Netzwerk selbst auf (oder per Terraform). Kubernetes ist bei großen Flotten üblich, aber eine gut dimensionierte Autoscaling-Gruppe mit PHP-FPM und Redis reicht vielen mittelgroßen Shops.
Vorteil: Sie steuern CPU-Burst, Datenbank-IOPS und Region. Nachteil: Patching, Zertifikate, Log-Aggregation und Failover sind Ihre Aufgabe. Cloud ohne Runbooks ist nur teurere Ausfallzeit.
Edge-Hosting mit CDN und Workers
Edge heißt hier CDN, HTML-Cache an der Edge und Rechenleistung nahe am Nutzer (zum Beispiel Cloudflare Workers, mehr dazu in unserem Beitrag zu Workers vor WordPress und WooCommerce). Edge ist selten „WordPress ohne Origin“. Es ist eine Schicht vor dem Origin: Cache-Treffer für anonyme Seiten, Bot-Filterung, Bildumwandlung, A/B-Tests ohne PHP-Aufruf.
Cache-Misses, eingeloggte Nutzer und POST-Anfragen an die Kasse gehen weiterhin zum Origin. Planen Sie das ein, sonst wird die Edge zur Illusion von Geschwindigkeit.
Welche PHP- und Datenbankversionen WordPress empfiehlt
Bevor Sie Anbieter vergleichen, prüfen Sie die Grundvoraussetzungen. Auf der Anforderungsseite empfiehlt WordPress.org PHP 8.3 oder neuer, MySQL 8.0 oder neuer oder MariaDB 10.11 oder neuer sowie HTTPS-Unterstützung. Das sind Empfehlungen an den Hoster, keine Garantie, dass jedes Ihrer Plugins dieselbe Version unterstützt.
Praktisch ergeben sich drei Fragen an einen neuen Anbieter: Welche PHP-Version läuft heute in Produktion, wie schnell kommt die nächste, und lässt sich die Version pro Umgebung wählen, damit Staging vor der Produktion auf der neuen getestet werden kann. Ein Managed-Tarif, der Sie auf einem älteren PHP-Zweig festhält, beschert Ihnen ein Upgrade-Projekt im Zeitplan des Anbieters statt in Ihrem eigenen.
Wie viele PHP-Worker braucht WordPress
Ein PHP-Worker ist ein Prozess (in manchen Stacks ein Thread), der jeweils eine Anfrage bearbeitet. Die Zahl der Worker mal die durchschnittliche Verarbeitungszeit bestimmt die Obergrenze an Anfragen pro Sekunde, bevor die Warteschlange wächst und die TTFB steigt.
Rechenbeispiel: Ein Shop mit 20 Workern und 400 ms durchschnittlicher PHP-Zeit schafft grob 50 Anfragen pro Sekunde, bevor sich eine Warteschlange bildet. Braucht jede ungecachte Produktseite 800 ms, weil Plugins externe APIs aufrufen, halbiert sich die Kapazität. Die Lösung sind selten „mehr Plugins“, meist weniger synchrone Aufrufe, besserer Page Cache und mehr Worker nur dort, wo Messungen den Bedarf zeigen.
Praktische Maßnahmen:
- Messen Sie die Wartezeit in PHP-FPM (
slowlog, APM), bevor Sie die Worker verdoppeln. - Trennen Sie Backend und Cron vom Frontend mit eigenen Pools, wo die Plattform es erlaubt.
- Lassen Sie wp-cron nicht bei jeder Frontend-Anfrage laufen; nutzen Sie System-Cron.
- Halten Sie Sessions und temporäre Dateien von langsamen lokalen Platten fern, wenn mehrere Knoten die Last teilen.
Die Serverdokumentation von WordPress.org betont, dass Hosting mehr ist als „PHP plus MySQL“: Dateirechte, HTTPS und Prozessisolation beeinflussen Sicherheit und Stabilität.
Wie man pm.max_children in PHP-FPM einstellt
Auf eigenem Server oder in der Cloud sind Worker eine Einstellung, die Ihnen gehört. Das PHP-Handbuch zu FPM beschreibt drei Modi für pm: static liefert eine feste Zahl von Kindprozessen, dynamic passt die Zahl zwischen pm.start_servers, pm.min_spare_servers und pm.max_spare_servers an, und ondemand startet Prozesse erst, wenn Anfragen eintreffen. Allen gemeinsam ist pm.max_children, das laut Handbuch „die Obergrenze für die Zahl gleichzeitig bedienter Anfragen festlegt“ (eigene Übersetzung).
In der Praxis setzt der Arbeitsspeicher die Grenze: Jeder PHP-Prozess belegt RAM, und wenn pm.max_children mal typische Prozessgröße den freien Speicher übersteigt, tauschen Sie Warteschlange gegen Swapping. Um zu sehen, wohin die Zeit geht, setzen Sie request_slowlog_timeout auf einige Sekunden. FPM schreibt dann für jede längere Anfrage einen PHP-Backtrace in die slowlog-Datei, und Sie sehen, welches Plugin oder welcher externe Aufruf den Worker blockiert.
Wann Redis oder Memcached unter WordPress sinnvoll sind
Der Object Cache speichert die Ergebnisse von wp_cache_*-Aufrufen und persistente Objekte zwischen Anfragen. Ohne persistentes Backend lebt der Cache nur für die Dauer einer Anfrage im Speicher. Die Dokumentation zu WP_Object_Cache sagt es deutlich: „Standardmäßig ist der Object Cache nicht persistent“ (eigene Übersetzung), und nichts überdauert einen Seitenaufruf, bis Sie ein persistentes Backend als Drop-in in wp-content installieren. Mit Redis oder Memcached werden Options, Postmeta-Hotspots und Transients über Worker hinweg wiederverwendet.
Wo der Object Cache am meisten bringt:
- WooCommerce mit vielen Produkten und Varianten
- Seiten mit schweren
WP_Query-Abfragen, die nicht im Page Cache landen - Multisite oder viele aktive Plugins, die Options wiederholt lesen
Wo er wenig bringt:
- Rein statische Landingpages, die schon vollständig im CDN gecacht sind
- Falsch konfigurierte Plugins, die den Object Cache umgehen oder riesige Objekte schreiben
- Eine Datenbank, die bei schreiblastigen Checkout-Abläufen bereits der Engpass ist
Setzen Sie TTLs bewusst. Leeren Sie aggressive Schlüssel beim Deploy. Überwachen Sie die Trefferquote: „Redis ist an“ ohne Trefferquote ist Theater. Betreiben Sie Redis in derselben Region wie PHP; ein Object-Cache-Sprung auf einen anderen Kontinent kostet mehr, als er spart.
Was Cloudflare vor WordPress standardmäßig cacht
Viele gehen davon aus, dass ein CDN vor WordPress automatisch ganze Seiten cacht. Cloudflares eigene Dokumentation zum Standard-Cacheverhalten sagt etwas anderes: „Das Cloudflare-CDN cacht HTML und JSON standardmäßig nicht“ (eigene Übersetzung). Ohne eigene Regeln werden Dateien nach Endung gecacht, etwa Bilder, CSS, JS, Schriften und PDF, während das von PHP erzeugte HTML jedes Mal zum Origin geht.
Dieselbe Seite nennt, was das Caching auch nach dem Einschalten verhindert: ein Set-Cookie-Header vom Origin, Cache-Control: private, no-store, no-cache oder max-age=0 sowie jede Anfragemethode außer GET. Um HTML zu cachen, empfiehlt Cloudflare eine Cache-Regel, die alles cacht, oder Workers für eigene Logik.
Für WordPress heißt das: Ein Plugin, das auf jeder Seite ein Cookie setzt, macht den Edge-Cache still wertlos. Prüfen Sie die Antwort-Header einer anonymen Produktseite, bevor Sie schließen, dass „das CDN nichts bringt“.
Welche WooCommerce-Seiten an der Edge gecacht werden können
WooCommerce mischt cachebare Katalogseiten mit hochdynamischen Pfaden: Warenkorb, Kasse, Mein Konto, REST-Endpunkte für Zahlungsanbieter, Webhooks von PayPal, Klarna oder Stripe. Ein Edge-Cache, der anonymes HTML für /produkt/ ausliefert, ist gut. Ein Edge-Cache, der dasselbe HTML an einen Nutzer mit gefülltem Warenkorb ausliefert, zerstört die Conversion.
Edge-Regeln, die sich in der Praxis bewähren:
- GET für Katalog, Beiträge und cachebare Landingpages cachen
- Bypass bei Cookies wie
woocommerce_items_in_cart,wp_woocommerce_session_*und Login-Cookies - Nie POST, admin-ajax-Warenkorbanfragen oder Zahlungs-Callbacks cachen
- Den Origin nahe an Zahlungs- und ERP-Integrationen halten; die Edge kann PCI- oder Session-Logik nicht einfach „verschieben“
Der eigene Leitfaden von WooCommerce zu Caching-Plugins bestätigt die Grenze: Warenkorb, Mein Konto und Kasse müssen aus dem Cache bleiben, weil sie Informationen zum jeweiligen Kunden zeigen. Die Cookie-Liste dort lautet woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed und store_notice[notice id]. Bietet die Cache-Schicht Datenbank-Caching, empfiehlt der Leitfaden zusätzlich, _wc_session_ auszunehmen. Nutzen Sie diese Liste als Ausgangspunkt für die Bypass-Regel an der Edge, statt zu raten.
Ein typisches Szenario: eine Black-Friday-Kampagne mit viel Katalog-Traffic aus Deutschland, Österreich und der Schweiz. CDN und Edge-Cache übernehmen Landing- und Produktseiten. Die Kasse bleibt auf dem Origin in einer EU-Region mit genug PHP-Workern und Redis. Wer „den ganzen Shop auf Workers“ versucht, hat immer noch keine maßgebliche Datenbank für Bestand, Bestellungen und Umsatzsteuer.
Messen Sie die TTFB bei Cache-Treffern und bei Cache-Misses. Der TTFB-Leitfaden von web.dev trennt Serverantwort von Netzwerkverzögerung; die Edge verbessert meist Letzteres für statische Inhalte, während PHP- und Datenbank-Traces eine ungecachte Kasse weiter dominieren.
DSGVO und Datenspeicherort bei der Wahl des WordPress-Hostings
Die Wahl des Hosters ist auch die Wahl eines Auftragsverarbeiters: Wo liegen MySQL-Snapshots, Logs, Backups, Support-Zugriffe und Unterauftragsverarbeiter?
Checkliste vor der Unterschrift:
- Primärregion für Datenbank und Dateien (zum Beispiel EU/EWR). „Global Anycast“ beim CDN ist nicht dasselbe wie der Speicherort personenbezogener Daten.
- Ein Vertrag zur Auftragsverarbeitung (AV-Vertrag) mit klarer Liste der Unterauftragsverarbeiter.
- Eine Übermittlungsgrundlage, wenn Daten den EWR verlassen (Standardvertragsklauseln, ergänzende Maßnahmen). „Ich nutze ein US-CDN“ ohne Dokumentation ist ein Risiko, kein Feature.
- Logs und APM: Enthalten sie E-Mail-Adressen, IPs, Bestellnummern, und wie lange werden sie aufbewahrt?
- Support-Zugriff: Wer darf per SSH oder SFTP zugreifen, und wird das protokolliert?
Für US-Anbieter gibt es eine weitere Übermittlungsgrundlage: Am 10. Juli 2023 hat die Europäische Kommission einen Angemessenheitsbeschluss zum EU-US Data Privacy Framework angenommen. Laut der Seite der Kommission zu Datenübermittlungen in die USA gilt er nur für Unternehmen, die am Framework teilnehmen. Prüfen Sie also, ob genau Ihr Hosting- oder CDN-Anbieter auf der Teilnehmerliste steht, statt anzunehmen, „die USA sind abgedeckt“.
Edge-Compute, das mit personenbezogenen Daten arbeitet (A/B-Tests, Personalisierung), ist als Verarbeitung zu bewerten. Cache-Schlüssel mit Nutzer-ID an Hunderten von Standorten vergrößern die Angriffsfläche. Halten Sie persönliche Inhalte auf dem Origin oder in kurzlebigen, sauber verschlüsselten Schichten.
Wie man wp-cron durch System-Cron ersetzt
WP-Cron läuft nicht nach der Uhr. Es wird geprüft, wenn jemand eine Seite lädt, deshalb verzögern sich geplante Aufgaben auf ruhigen Websites und konkurrieren auf stark besuchten mit den Besuchern. Die Entwicklerdokumentation von WordPress zeigt die Lösung in zwei Schritten. Zuerst schalten Sie den trafficgesteuerten Auslöser in wp-config.php ab:
define( 'DISABLE_WP_CRON', true );Danach ruft der Systemplaner wp-cron.php per Webanfrage auf. Die Dokumentation nennt */15 * * * * als Beispiel für alle 15 Minuten und zeigt einen wget-Aufruf gegen wp-cron.php. Wählen Sie das Intervall nach den tatsächlichen Jobs: Ein Shop mit Abo-Verlängerungen braucht ein kürzeres Intervall als ein Blog mit geplanten Beiträgen. Fragen Sie beim Managed-Hoster nach, wie er Cron betreibt, bevor Sie etwas ändern, denn manche erledigen das bereits.
Wie man CI/CD für WordPress-Hosting einrichtet
Ohne CI/CD wird Staging zu „manuellem FTP am Donnerstagabend“. 2026 sollten Code, Themes, eigene Plugins und Infrastrukturdefinitionen durch eine Pipeline laufen.
Ein Minimum, das funktioniert:
- Git als maßgebliche Quelle für eigenen Code (Theme, mu-plugins, Infrastructure as Code).
- Build und Tests in CI: PHPStan oder Psalm, wo vorhanden, PHPUnit für eigene Plugins, Linting für das Theme.
- Deploy auf Staging mit derselben PHP-Version und denselben Extensions wie in Produktion.
- Smoke-Tests: Startseite, eine Produktseite, In den Warenkorb, Login.
- Produktion mit atomarem Release (neues Release-Verzeichnis plus Symlink) oder Container-Image mit Healthcheck.
- Datenbankmigrationen per WP-CLI oder kontrollierten Migrationsskripten, nie „in Produktion bearbeiten“.
Secrets (API-Schlüssel, Datenbankpasswörter) gehören in einen Vault oder den Secret Store der Plattform, nicht in Git. Object-Cache- und CDN-Purges sollten nach dem Deploy automatisch laufen, nicht nach dem Motto „wir denken daran, Redis zu leeren“.
Bei Managed Hosting: Nutzen Sie dessen Git-Deploy oder rsync-Hooks, behalten Sie aber dasselbe Test-Gate. In der Cloud: Terraform oder Ansible plus vorgefertigte Images verringern Einzelstück-Server. An der Edge: Workers- und CDN-Konfiguration aus demselben Repository deployen wie den WordPress-Code, mit Review der Cache-Regeln, die die Kasse brechen könnten.
Wie man eine WordPress-Hosting-Architektur in der Praxis wählt
Beginnen Sie mit der Arbeitslast, nicht mit Marketingbegriffen.
- Inhaltsstarker, geografisch verteilter Lese-Traffic: Managed- oder Cloud-Origin plus aggressiver Edge-Cache.
- WooCommerce mit lokalen Zahlungsarten und ERP: Origin in einer EU-Region, Redis, genug PHP-Worker, Edge nur für den Katalog.
- Strenge Compliance-Anforderungen: Cloud oder Managed mit dokumentierter Speicherung in EU/EWR und kurzer Liste von Unterauftragsverarbeitern.
- Kleines Team, planbarer Traffic: zuerst Managed; in die Cloud wechseln, wenn Worker-Grenze und Datenbank-I/O die gemessene Begrenzung sind.
Hybrid ist der Normalfall: Managed oder Cloud für WordPress, Redis in derselben Region, CDN und Workers davor. Reines „Serverless-WordPress überall“ bleibt ein Sonderfall, nicht der Standard für echte Shops.
Welche Leistungswerte man vor einem Hostingwechsel erfassen sollte
Ein Hostingwechsel ohne Ausgangswerte ist Raten. Protokollieren Sie mindestens eine Woche lang:
- TTFB und LCP auf den wichtigsten Templates (Startseite, Kategorie, Produkt, Kassenschritte)
- PHP-FPM-Warteschlange und langsame Anfragen
- MySQL-Slow-Query-Log
- Cache-Trefferquote (Page und Object)
- Fehlerquoten bei Zahlungs-Webhooks
web.dev rät, zu verstehen, was die TTFB tatsächlich misst, bevor man einer magischen Zahl hinterherjagt. Dort ist die TTFB die Summe aus Weiterleitungen, DNS-Abfrage, Verbindungs- und TLS-Aufbau und der Wartezeit bis zum ersten Byte. Als grobe Richtschnur nennt web.dev 0,8 Sekunden oder weniger gut und mehr als 1,8 Sekunden schlecht. Eine internationale Marketingseite kann bei Cache-Treffern eine niedrige TTFB haben und trotzdem eine langsame Kasse. Optimieren Sie die Schicht, die tatsächlich der Engpass ist.
Häufige Hosting-Fehler bei WordPress-Websites
- Edge-Cache ohne Cookie-Bypass für WooCommerce-Sitzungen
- Zu wenige PHP-Worker, ausgeglichen durch mehrere Cache-Plugins, die um dasselbe HTML konkurrieren
- Redis in einer anderen Region als PHP
- Backups nur auf derselben Platte wie die Produktion
- Kein Staging, das PHP-Version und Extensions spiegelt
- Personenbezogene Daten in CDN-Logs ohne Aufbewahrungsrichtlinie
- Deploys ohne Page-Cache-Purge, sodass alte HTML-Fragmente stundenlang leben
Jeder dieser Fehler lässt sich mit Messung und Konfiguration günstiger beheben als mit „wir wechseln wieder den Anbieter“.
Hilfe bei der Wahl des WordPress-Hostings
Wir erfassen den bestehenden Stack, messen Worker und Cache und schlagen Managed, Cloud oder Hybrid vor, ohne Edge dort zu überverkaufen, wo die Kasse konsistent bleiben muss. Die Arbeit umfasst meist Architekturwahl, Redis- und Page-Cache-Tuning, CDN-Regeln für WooCommerce und CI/CD bis Staging und Produktion.
Wenn Sie eine konkrete Prüfung Ihrer Infrastruktur brauchen, melden Sie sich über die Kontaktseite.
Wie man 2026 zwischen Managed, Cloud und Edge entscheidet
Managed bringt Betriebshilfe und eine Obergrenze. Cloud bringt Kontrolle und Verantwortung. Edge bringt niedrige Latenz für cachebare Inhalte, keinen Ersatz für PHP und MySQL auf dynamischen WooCommerce-Pfaden. PHP-Worker und Object Cache bestimmen die Kapazität am Origin. DSGVO und Datenspeicherort bestimmen Region und Unterauftragsverarbeiter. CI/CD hält Änderungen reproduzierbar.
Wählen Sie die Architektur nach gemessener Last und Compliance, danach stimmen Sie Cache und Worker ab. Das hält länger als die Jagd nach dem neuesten Hosting-Etikett.
