Pages or Workers for a new site

For years the answer was Pages. Connect a repository, get a preview URL for the branch, merge to deploy. Workers was the thing you reached for when you needed an API. That division no longer exists, because a Worker can serve a directory of static files, and Cloudflare now points new projects at Workers.

What Workers with static assets gives you

You put your build output in a directory and point the assets config at it. Requests to static assets are free and unlimited and there is no charge for storing them, so a purely static site costs nothing to serve, the same as it did on Pages. You are billed only when your script actually runs.

Most of the Pages workflow came with it. Workers Builds connects a GitHub or GitLab repository, builds on push, and produces a preview URL for each version before you promote it. _headers and _redirects are parsed natively when you leave them in the asset directory. not_found_handling covers single-page apps and custom 404 pages without writing any code. Assets are served before your script runs unless you set run_worker_first, which means the common case costs no invocations at all.

Cloudflare Pages vs Workers

Compute and bindings. This is the real gap. Cron Triggers, Durable Objects, Email Workers, Queue consumers, and rate limiting bindings are Workers features that Pages never got. If a site starts as static and later needs a scheduled job or a queue consumer, on Pages that is a migration. On Workers it is a config change.

Observability and deploys. Workers Logs, Logpush, Tail Workers, source maps, and gradual deployments are all Workers-side. Pages gives you build logs and not much after that. For anything serving real traffic, this matters more than the initial setup convenience.

Custom domains. Pages can attach a domain that lives outside Cloudflare via CNAME. Workers custom domains require the zone to use Cloudflare nameservers. If you cannot move DNS, this is a hard blocker and the one case where Pages is not merely preferable but necessary.

Branch controls. Pages branch deploy configuration is still more flexible than the Workers equivalent. Preview deployments on Pages remain genuinely good, and this is the part of Pages I miss.

Early Hints. Native on Pages, manual header configuration on Workers.

Caching. The defaults match. Both serve assets as public, max-age=0, must-revalidate with an ETag, and a _headers file overrides that the same way on either. The traps do not match. On Pages, hand-rolled Cache Rules are easy to get wrong, and the usual symptom is content cached for far longer than intended with a Purge Everything as the way out. On Workers, enabling Workers Cache puts a cache in front of the script and makes static asset requests billable at the standard request rate, because each one now consults that cache. Leave both alone unless you have a reason.

Routing. Workers can serve assets on a subpath and deploy to non-root routes. Pages Functions folder-based routing has no direct equivalent, so file-routed projects need a framework like HonoX or a Wrangler compilation step instead.

Is Cloudflare Pages deprecated?

Technically no, but I would mentally treat it as deprecated. Existing Pages projects work, they are not being switched off, and there is no deadline to move. But Pages scores a 6 here almost entirely on trajectory. New platform features arrive on Workers first and often only there. A product that still works while development happens elsewhere is not a product I would start something new on, and that is a different judgment from a product being broken.

Migrating from Pages to Workers

There is no urgency. If a Pages site is doing its job, leave it. The migration is worth doing when you hit something Pages cannot do, which in practice means you want a cron trigger, a queue consumer, real logs, or gradual deployments. At that point Cloudflare’s migration guide covers it, and for a static site the work is mostly moving configuration into wrangler.jsonc and keeping your _headers and _redirects files where they are.

The one thing to check before you start is DNS. If the domain is not on Cloudflare nameservers, the migration stops there.

When Pages is still the right call

A domain you cannot move onto Cloudflare DNS. An existing Pages project that works and has no unmet needs. Branch deploy behavior you have configured carefully and do not want to rebuild. Outside those, I would start on Workers.