Cloudflare Pages oder Workers: Welches Hosting passt zu Deiner Website?

Für eine neue Website ist Workers mit Static Assets der passende Ausgangspunkt, auch ohne eigene Serverfunktionen. Ein gut laufendes Pages-Projekt kannst Du weiter nutzen, solange Dir dort nichts fehlt. Bei einem großen Bestand prüfst Du zuerst den fertigen Build: Dateizahl, größte Datei und dynamische Aufrufe entscheiden über den Tarif.

Cloudflare empfiehlt in seiner Einstiegsdokumentation für Pages ausdrücklich Workers für neue Projekte, nennt dabei aber kein Abschaltdatum für Pages. Ein Umzug braucht deshalb einen konkreten Nutzen, etwa eine benötigte Workers-Funktion oder einen besseren Ablauf für künftige Änderungen.

Was beide gemeinsam haben

Pages und Workers können fertige HTML-Seiten, Bilder, CSS und JavaScript ausliefern. Ein Werkzeug wie Astro erzeugt diese Dateien vorab beim sogenannten Build. Beim Besuch einer solchen Seite muss dann kein PHP-Code erst den Inhalt aus einer Datenbank holen.

Bei Workers heißt dieses Hosting Static Assets, wobei eigener Worker-Code laut Dokumentation optional ist. Du kannst also mit einer schlichten Website anfangen und später eine Schnittstelle ergänzen, während Pages dafür Pages Functions bietet. Die Trennung „Pages für Websites, Workers nur für Code“ hilft heute kaum noch.

Beide Wege ersparen Dir den Betrieb eines eigenen Webservers für diese Dateien. Was Du bei einem eigenen Server selbst verwaltest, erklärt unser älterer Grundlagenbeitrag zum VPS-Hosting. Seine alten Softwareversionen sind keine Empfehlung für eine heutige Installation, doch die Frage nach der Verantwortung für Updates und Betrieb bleibt relevant.

Wo Pages und Workers sich unterscheiden

Die folgenden Grenzen stammen aus der Cloudflare-Dokumentation, geprüft am 9. September 2026. Bei Pages heißen die bezahlten Tarife unter anderem Pro und Business, während Workers Paid ein eigener Tarif ist. Ein bezahlter Workers-Zugang ist deshalb nicht automatisch ein Pages-Pro-Tarif.

Für 100.000 Dateien verlangt die Pages-Limitseite zusätzlich die Projektvariable PAGES_WRANGLER_MAJOR_VERSION=4. Bei Workers nennt die Limitseite für die erhöhte Dateizahl mindestens Version 4.34.0 von Wrangler, Cloudflares Werkzeug zum Hochladen und Verwalten der Projekte.

Auf beiden Plattformen endet ein gehosteter Build nach spätestens 20 Minuten. Bei Workers Builds kannst Du GitHub oder GitLab anbinden, musst also nicht zwingend auf Deinem Rechner bauen. Laut den Build-Konditionen kosten weitere Paid-Minuten jeweils 0,005 US-Dollar; der Arbeitsbereich eines Workers-Builds hat 20 GB Platz.

Diese 20 GB sind kein Speicherpaket für Deine Website, und die geprüften Tabellen nennen kein eigenes Gesamtgrößenlimit für das Deployment. Eine Zusage für beliebig große Uploads folgt daraus nicht: Prüfe Dateizahl, Einzeldateien und den Platz während des Builds getrennt.

Kleine statische Website: Pages funktioniert, Details zählen

Bei unserer Portierung von heimkino-atmos.de vom 26. bis 28. Juli 2026 entstand eine Astro-Site mit 75 Seiten, die auf Pages live ging. Der überschaubare Umfang passte gut zum Hosting, doch beim Veröffentlichen stolperten wir über Dateien, Fehlerseiten und Einstellungen.

Schon bei den Medien zeigte sich, wie wenig die Seitenzahl über den Platzbedarf aussagt. Allein 13 Videos umfassten zusammen 1,47 GB, wobei die größte Datei 416 MB hatte. Diese Medien kamen in Cloudflares Objektspeicher R2, der Dateien getrennt vom Website-Build aufbewahrt. Zwei übersehene VOB-Dateien mit 31 und 29 MB ließen zunächst trotzdem einen Deploy scheitern. Ein höherer Pages-Tarif hätte uns dabei nicht geholfen, weil die Grenze pro Datei bestehen bleibt.

Auch kleinere Bilder lösen nicht jedes Größenproblem, wie unser WebP-Praxisbericht von 2019 anhand der entstehenden Bildvarianten zeigt. Die damaligen Hinweise zur Browserunterstützung sind historisch; für Deinen Build zählt aber jede zusätzliche Variante als Datei, selbst wenn sie wenig Platz braucht.

Eine fehlende Seite muss als fehlend antworten

Bei den Fehlerseiten stießen wir im Juli auf das nächste Problem: Unserem Pages-Build fehlte zunächst die Datei 404.html. Unbekannte Pfade lieferten daraufhin die Startseite mit HTTP 200, meldeten also Erfolg, obwohl die angefragte Seite nicht existierte. Cloudflare beschreibt dieses Fallback-Verhalten von Pages: Ohne oberste Fehlerseite nimmt Pages eine Single Page Application an, bei der JavaScript im Browser die Ansichten steuert.

Für unseren Inhaltsbestand war das falsch, und zusätzlich mussten wir rund 40.000 Spam-URLs aus einem früheren Hack behandeln. Sie nutzten Parameter an der Startseitenadresse, weshalb eine neue Fehlerseite allein diesen Fall nicht löst: Der Startseitenpfad existiert. Die Antworten mit Status 410 für diese URLs setzten wir deshalb über Pages Functions um.

Für einen Wechsel zu Workers beschreibt die Anleitung für statische Seiten die nötigen Einstellungen: assets.not_found_handling wählt mit 404-page eine vorhandene Fehlerseite und liefert Status 404. In der wrangler.jsonc zeigt assets.directory auf den fertigen Buildordner, etwa ./dist.

Die Einstellung assets.html_handling steuert zusätzlich die Form Deiner HTML-Adressen, unter anderem über auto-trailing-slash, force-trailing-slash und drop-trailing-slash für den abschließenden Schrägstrich. Übernimm beim Umzug die bisherige URL-Form bewusst und prüfe die Weiterleitungen, damit Deine vorhandenen Adressen weiter funktionieren.

Weiterleitungen, Header und der richtige Branch

Bei unseren Pages-Portierungen im Juli 2026 stolperten wir auch über Regeln, die beim Deploy still verworfen wurden. Eine Redirect-Quelle mit vollständigem Hostnamen funktionierte nicht, weshalb wir www und Hauptdomain über eine Redirect Rule der Cloudflare-Zone bündelten. Diese Regeln gelten auf Ebene der Domain, während die Dateien _redirects und _headers zum Website-Build gehören.

Bei zwei getrennten /*-Blöcken fehlte außerdem ein Teil unserer Header, sodass wir sie in einem Block zusammenfassten. Das bleibt unser damaliger Befund und ist kein allgemeines Verbot mehrerer passender Header-Regeln. Laut heutiger Dokumentation unterstützt auch Workers Static Assets diese Dateien, die jedoch keine beliebige Logik für dynamische Antworten ersetzen.

Selbst eine erfolgreiche Veröffentlichung bedeutete noch nicht, dass unsere Besucher den neuen Stand sahen. Das Pages-Projekt erwartete als Production-Branch main, unser lokaler Branch hieß aber master, weshalb der Deploy nur als Vorschau landete. Wir mussten deshalb auch den für die Produktion vorgesehenen Branch bewusst abgleichen.

Für die Spam-URLs blieb eine weitere Grenze relevant: Die Redirect-Datei prüft keine Query-Parameter als Bedingung und erzeugt keine 410-Antworten. Das ist bei beiden Plattformen von einer Weiterleitung auf eine Zieladresse mit Parametern zu unterscheiden. Für solche Sonderfälle brauchst Du passende Zonenregeln oder Code, wie wir ihn über Pages Functions einsetzten. Aus den Portierungen nehmen wir deshalb mit: Zum fertigen Build gehören auch passende Fehlerantworten, geprüfte Regeln und die richtige Produktionsfassung.

Großer WordPress-Bestand: Beiträge sind keine Dateizahl

Bitblokes läuft weiterhin auf WordPress. Am 26. Juli 2026 bauten und prüften wir daneben einen lokalen statischen Kandidaten. Er ist kein abgeschlossener Live-Umzug, doch seine Zahlen zeigen gut, warum eine Schätzung allein nach Beiträgen zu kurz greift.

• 9.674 veröffentlichte Beiträge lagen in der Quelle vor.
• Der fertige Build enthielt 25.671 HTML-Seiten und insgesamt 40.654 Dateien.
• Die Gesamtgröße betrug 2.226.620.667 Bytes, also rund 2,23 GB.
• Keine einzelne Datei überschritt 25 MiB.

Neben den Beiträgen entstehen Seiten für Kategorien, Tags, Datumsarchive und deren Folgeseiten; Bilder, Feeds und Suchdateien kommen hinzu. Unser Kandidat überschritt damit das Free-Dateilimit beider Plattformen deutlich, passt nach den heute geprüften Grenzen aber bei der Dateizahl in beide passenden Paid-Angebote.

Wir hatten Workers Static Assets als Ziel des Kandidaten vorgesehen, doch die Dateizahl allein erzwingt diese Wahl heute nicht. Ein höherer Tarif, getrennte Teilprojekte oder ausgelagerte Medien sind mögliche Wege, wobei beim Aufteilen die bisherigen URLs und Verweise weiter funktionieren müssen.

R2 hilft vor allem bei vielen Medien oder großen Einzeldateien, entfernt aber keine HTML-Archive aus Deinem Build. Bei unserem Kandidaten lagen schon die HTML-Seiten über 20.000, sodass es für Free nicht reichen würde, nur die Bilder auszulagern. Streiche Archive auch nicht blind: Prüfe zuerst, welche Seiten und Pfade erhalten bleiben müssen.

Dynamische Funktionen und Kosten getrennt planen

Ein Kontaktformular, ein Login oder eine Suche auf dem Server braucht ausführbaren Code. Eine Suche im Browser kann dagegen mit einer vorab erzeugten Datei arbeiten. Entscheidend ist also, was bei jedem Aufruf tatsächlich auf dem Server passiert.

Pages Functions können ebenso wie Workers über sogenannte Bindings auf KV, D1 und R2 zugreifen. Dabei speichert KV Werte unter Schlüsseln, D1 hält Daten in SQL-Tabellen und R2 nimmt Dateien auf. Datenbankzugriff allein verlangt deshalb keinen Umzug zu Workers.

Direkt ausgelieferte statische Assets sind kostenlos und ohne Request-Limit, bei Pages allerdings nur, wenn der Aufruf keine Function startet. Bei Workers werden passende Assets standardmäßig vor eigenem Code ausgeliefert; schaltest Du Code über run_worker_first davor, zählen diese Aufrufe als Worker-Ausführung.

Die Angaben zu Abrechnung und Bindings stammen aus der Cloudflare-Dokumentation; für die Funktionsaufrufe nennt die Workers-Preisliste am 9. September 2026:

• Free: 100.000 Requests pro Tag und höchstens 10 Millisekunden CPU-Zeit je Aufruf. Das Tageskontingent teilen sich Workers und Pages Functions.
• Paid: mindestens 5 US-Dollar pro Konto und Monat. Enthalten sind 10 Millionen Requests und 30 Millionen CPU-Millisekunden pro Monat.
• Mehrverbrauch: 0,30 US-Dollar je weitere Million Requests und 0,02 US-Dollar je weitere Million CPU-Millisekunden.

CPU-Zeit ist die verbrauchte Rechenzeit, die sich von der Wartezeit auf eine Datenbank unterscheidet. Auch die optionale Funktion Workers Caching hat eine eigene Abrechnungsregel: Ihre Cache-Hits zählen als Requests. Du darfst sie deshalb nicht mit dem kostenlosen direkten Static-Assets-Hosting gleichsetzen.

Führe deshalb vier Posten in Deiner Kalkulation: statische Dateien, Funktionsaufrufe, Builds sowie Daten und Medien. Für D1, KV und R2 gelten eigene Kontingente und Abrechnungsregeln. Ein günstiger Hostingtarif sagt noch nichts über eine häufig abgefragte Datenbank aus.

Eigene Domain, Vorschau und Rückweg

Die Dokumentation beschreibt für beide Plattformen eigene Domains, Vorschauen und Rollbacks mit unterschiedlichen Voraussetzungen. Bei Pages braucht die Hauptdomain eine Cloudflare-Zone, während sich eine Subdomain auch per CNAME bei einem anderen DNS-Anbieter anbinden lässt. DNS ordnet dabei den Namen dem Hostingziel zu, damit Besucher Deine Website erreichen. Bei Workers Custom Domains braucht die Domain eine aktive Cloudflare-Zone; DNS-Eintrag und Zertifikat werden automatisch erstellt.

In unserem Pages-Ablauf vom Juli 2026 mussten wir den DNS-Eintrag separat setzen. Das ist keine allgemeine Regel für den heutigen Dashboard-Ablauf: Bei einer Cloudflare-Zone kann Pages ihn nach Bestätigung automatisch anlegen. Prüfe nach dem Verknüpfen trotzdem, ob die eigene Domain die gewünschte Fassung zeigt.

Für Tests bietet Pages eigene Branch- und Deployment-Vorschauen; die normale Projektadresse unter pages.dev ist dagegen keine getrennte Testumgebung. Bei unserem Juli-Umzug zeigte auch ein Branch-Alias kurzzeitig noch den alten Stand, während die eindeutige Adresse des einzelnen Deployments bereits die neue Fassung zeigte. Ein Rollback führt Dich zu einer früheren erfolgreichen Produktionsveröffentlichung zurück.

Workers bietet Vorschauadressen für Versionen und benannte Aliase, sodass Du eine Version hochladen und prüfen kannst, bevor sie den Produktivverkehr übernimmt. Aktivierte Vorschauen sind zunächst öffentlich; für beschränkten Zugriff gibt es Cloudflare Access. Bei einem Rollback wählst Du eine frühere Version, setzt aber keine angebundene Datenbank zurück. Alter Code muss deshalb weiterhin zu den vorhandenen Daten passen.

Bestehendes Pages-Projekt: bleiben oder umziehen?

Bleibe zunächst bei Pages, wenn Dein Build hineinpasst und alle benötigten Funktionen laufen. Die folgenden Schritte beruhen auf der offiziellen Anleitung von Pages zu Workers. Der fertige statische Inhalt kann meist bleiben, während Konfiguration, Funktionen und die Reihenfolge der Anfrageverarbeitung Aufmerksamkeit brauchen.

1. Build sichern: Bewahre Quelltexte, Medien und die zuletzt funktionierende Ausgabe auf und halte auch Redirects und Domain-Einstellungen fest.
2. Konfiguration übertragen: Setze den Asset-Ordner, Fehlerseiten und URL-Verhalten und übernimm die Header- und Redirect-Dateien in den statischen Ausgabeordner.
3. Funktionen übernehmen: Pages Functions müssen in ein Worker-Skript übersetzt werden, wobei bei einem Framework ein passender Adapter nötig sein kann.
4. Routing prüfen: Eine bisher vorgeschaltete Anmeldung darf beim Wechsel nicht hinter die direkte Dateiauslieferung rutschen.
5. Vorschau abnehmen: Teste normale Seiten, Bilder, alte Weiterleitungen, unbekannte Pfade und dynamische Antworten, bevor Du die eigene Domain und den Rückweg prüfst.

Für einen späteren Anbieterwechsel brauchst Du ebenfalls Deine Quellen und Daten. Reine Dateien lassen sich leichter mitnehmen als Cloudflare-spezifische Funktionen und Bindings. Unser älterer Beitrag zur Datensicherung samt Wiederherstellungsnotizen erklärt das Grundprinzip, wobei seine Serverbefehle von 2017 keine Anleitung für diesen Cloudflare-Umzug sind.

Starte die Entscheidung mit einem vollständigen Build und einer Liste Deiner dynamischen Funktionen. Passt ein bestehendes Pages-Projekt weiterhin, kannst Du dort bleiben. Für ein neues Projekt prüfst Du Workers mit Static Assets zuerst. Den Tarif wählst Du danach anhand der Dateien und der tatsächlich benötigten Ausführung.