Cloudflare's Own Docs Now Open With "Are You Sure You Want to Use Pages?" — What the Move to Workers Means for an Astro Site Like Ours

Cloudflare has not killed Pages, but it no longer pretends it is where the platform is going. The Pages documentation now opens with a banner that literally reads "Are you sure you want to use Pages?" and tells you to start new projects on Workers, the official Pages-to-Workers migration guide was last updated on September 22, 2026, and on October 1 Cloudflare opened Artifacts — its own Git platform — in beta with billing starting October 14, 2026. For a static Astro site like mintec.co, the migration is a configuration exercise, not a rewrite: _headers and _redirects carry over natively. The risk sits in one paragraph of the guide about serving order, and it is the reason we are staging a migration instead of executing one.

The signal, with dates

Three first-party data points, because "Cloudflare deprecated Pages" is the kind of thing everyone repeats and nobody checks:

• August 25, 2026 — the banner. The developers.cloudflare.com/pages/ overview page now starts with: "Are you sure you want to use Pages? Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare's primary platform for building applications. Start new projects with Workers." That is not a forum comment. It is the product's own front door.
• September 22, 2026 — the guide. Cloudflare's Migrate from Pages to Workers documentation was updated on that date and walks through frameworks, project configuration, builds, previews, headers, redirects, pages.dev domains, custom domains and a feature-by-feature compatibility matrix.
• October 1, 2026 — the platform around Pages moves too. Artifacts, Cloudflare's Git platform for repositories, went into open beta, available on the Workers Paid plan. Cloudflare's docs say billing starts October 14; Cloudflare's own blog post says October 15. Their two pages disagree by a day, which tells you how fast this is moving.

None of this is an end-of-life announcement. Pages projects keep deploying, and Cloudflare's own guide says static asset requests on Workers are free and Pages Functions invocations are priced like Workers, so "similar cost structure" is the official position. The message is about direction, and direction is what you plan against.

We have skin in this game: we moved mintec.co from Next.js on Vercel to Astro on Cloudflare Pages in July and publicly called Pages "more than sufficient" for a content site. That answer is still true today. It is just no longer the whole question — and six months after Cloudflare acquired the Astro team, we no longer treat the hosting layer as neutral plumbing.

What Pages guessed for you, and what Workers makes you say

The migration is small enough to read in one sitting. Most of the work is replacing Cloudflare's old habit of inferring your intent:

That last row is where the guide stops being a checklist and starts being an architecture decision.

The four-line paragraph that decides whether your site still works

The guide's section on _routes.json and Pages Functions middleware says it plainly: Pages defaulted to running your functions ahead of static assets, and _routes.json plus middleware let you customize that. Workers does the opposite by default — static assets are served first, and your Worker only runs if you set assets.run_worker_first: true.

We opened our own repo rather than reasoning hypothetically, and the inversion lands directly on how mintec.co is built:

• public/_routes.json is 17 lines: include: ["/*"], excluding /_astro/*, /images/*, favicons, robots.txt, llms.txt, rss.xml and the sitemaps. Under Pages, that meant our function layer saw essentially every HTML request.
• functions/_middleware.ts is not decorative. It resolves legacy paths and returns 410 Gone or a 301 that carries utm_* and gclid parameters across the hop so attribution survives. If that middleware stops running on the paths it used to see, old campaign links silently die.
• There are five API endpoints beside it — contact-lead, project-intake, maia-lead, geo.json (which reads request.cf.country) and a Meta conversions helper — plus public/_headers with cache rules that assume assets are served without touching a function: HTML is max-age=0, must-revalidate, /assets/* is immutable for a year, /images/* gets a week with stale-while-revalidate, /api/* is no-store.
• public/_redirects is 1,000 lines and 82 KB, auto-generated on every build from redirects_map.json by scripts/sync-redirects.mjs.

Two of those files transfer cleanly: the migration guide explicitly confirms that _headers and _redirects are supported natively in Workers with static assets, as long as they sit in the asset directory — and ours live in public/, which Astro copies into dist/ on every build. What does not transfer is the assumption about who runs first. With run_worker_first: true, every image and hashed asset request also enters the Worker, which is exactly what our cache rules were written to avoid. With the default, the middleware only fires where static assets miss — probably fine for legacy URLs that no longer exist as files, but "probably" is not a cutover criterion for a site with 1,000 redirects.

What transfers cleanly, and what does not

A quick audit of the rest of the guide against our own setup:

• Custom domains: fine. Workers does not support domains whose nameservers are not managed by Cloudflare. We checked: mintec.co resolves to jacob.ns.cloudflare.com and grace.ns.cloudflare.com, so this common blocker does not apply to us. If your DNS lives at another registrar, it is your hard blocker — plan for it before anything else.
• Deploys: one setting change. The repo has no .github/workflows/; deploys ride Cloudflare's Git integration. The guide says to connect the repository to Workers Builds and then disable automatic deployments on the Pages project.
• Pages Functions: framework swap, not a rewrite. Our functions are already plain Web-standard Request/Response handlers, which is what Workers expects — the same reasoning behind Cloudflare making the Node.js compatibility layer the default. The file layout changes; the logic does not.
• Previews: config, not features. Per-branch preview URLs become preview_urls: true plus a previews block, with preview builds enabled in Workers Builds (new projects default to wrangler preview).
• Performance: unchanged, if the serving order stays honest. Field data is what we optimize against — our BEACON readings across real Cloudflare traffic are the reason we keep /images/* and /_astro/* out of the function layer at all.

The framework we use to decide

Our call: stage it, do not cut it over. Nothing we run today needs Cron Triggers or Durable Objects, so there is no payoff for taking on a routing-verification window this quarter. But the direction is unambiguous, and a wrangler.jsonc that exists in a branch and builds in CI costs almost nothing to maintain. The trigger to execute will be either a feature we actually need or a deadline Cloudflare sets — not the banner.

That is the honest version of this decision for most content sites: the migration is real, it is small, and the only expensive part is the paragraph you will be tempted to skim.