I lost time to a mistake so common it deserves its own error message:
I deployed the right code to the wrong Cloudflare product.
Everything "looked" fine. Builds ran. The dashboard nodded politely. And yet my site behaved like it had amnesia.
This post is a practical field guide to avoiding that trap — plus a dead-simple checklist to diagnose it when it happens anyway (because it will).
Why this happens (Cloudflare made it… convenient)
Cloudflare's developer platform has been converging the experience for a while — you'll often find both under "Workers & Pages" in the dashboard. That's great for workflow, but it also makes it easier to click the wrong "Create application" path and end up deploying to the wrong target. Cloudflare's own docs reflect this shared entry point in the dashboard for both products.
Here's the key mental model:
- Pages is primarily for sites: static output + a structured deployment pipeline (Git integration, preview deploys, etc.).
- Workers is primarily for compute: request-handling code (APIs, middleware, edge logic), and now also can serve static assets in several patterns.
They overlap. A lot. That's the problem.
The "symptoms" of picking the wrong one
When you deploy to the wrong product, it rarely explodes. It just… doesn't do what your brain expected.
Common vibes:
- You see a default page (or an older version) even though you "deployed."
- Your build succeeds, but the URL you're testing isn't the one actually attached to your project.
- Your static files are there, but routing behaves differently than expected.
- You expected "site-style" behavior (Pages conventions), but you're in "app-style" behavior (Worker entrypoint rules).
- Custom domain is attached to a different project than the one you're editing (classic).
If you're thinking "wow that's vague," yes — welcome to the exact emotional experience of troubleshooting it.
Pages vs Workers: the quick decision rule
If you remember nothing else, remember this:
- Start with Pages if your primary deliverable is a website (static build output, JAMstack, docs site, marketing site).
- Start with Workers if your primary deliverable is logic (API endpoints, middleware, auth gates, request rewriting, edge compute).
Yes, Pages has Functions and those run on the Workers runtime — but Pages still has its own conventions and project structure. Cloudflare describes Pages Functions as executing code on their network using Cloudflare Workers.
The "don't make me think" comparison
| What you're building | Pick this first | Why |
|---|---|---|
| Static site (HTML/CSS/JS) or framework that outputs static assets | Pages | Pages is optimized for site deploy workflow + preview deploys + simple hosting |
| API, webhook handler, middleware, auth, request transforms | Workers | Workers is built for request/response code and edge routing control |
| Full-stack app (static + API) and you want one "app brain" | Workers (often) | Workers can own the routing and serve assets too; more control |
| Mostly a site, with a little server-side glue (forms, auth, tiny endpoints) | Pages | Pages Functions gives you "just enough" compute without changing your mental model |
The fastest way to confirm you deployed to the wrong place
Do this before you change code, configs, or your entire belief system:
- Find the project in the Cloudflare dashboard under Workers & Pages.
- Look at the project type and its deployment pipeline:
- If it's a Pages project, you should see a Pages-style deployment flow (build settings, preview deploys, etc.).
- If it's a Worker, you should see Worker settings (entrypoint behavior, builds/deploys for Workers, etc.).
- Confirm the URL you're testing is actually associated with that project:
- Preview URLs and custom domains can point at a different project than you think.
- Especially if you created multiple projects while troubleshooting (ask me how I know).
- Check which project owns the custom domain (if you're using one). If the domain is attached to a different project, your deploy can be perfect and still invisible.
If your domain points to Project A but you're deploying Project B, congratulations: you built a flawless deployment pipeline for the wrong universe.
How to fix it cleanly (without starting over)
Fix strategy depends on what you actually want:
Scenario A: You wanted a Pages site but created a Worker
- Create a Pages project targeting the same repo (or upload method you intended).
- Set the correct build command + output directory (for your framework/site generator).
- Attach your custom domain to the Pages project (or move it from the Worker project).
Scenario B: You wanted a Worker app but created a Pages project
- Create a Worker app (or migrate) and move your request-handling logic into the Worker entrypoint.
- If you need static assets too, use a Workers static-assets pattern and keep everything unified under the Worker's routing.
Cloudflare even provides migration guidance for moving from Pages to Workers for static asset hosting patterns, which is a strong hint that this overlap is now "officially a thing."
Hard-earned lessons (so you don't repeat my pain)
- Name projects like you mean it. Example:
myapp-pagesvsmyapp-worker. Future-you will send you a thank-you card. - Keep a single source of truth for your "live" domain. One domain should map to one intended project at a time.
- Don't trust "build succeeded" as proof of "deployment is live." Verify the domain/project mapping.
- If you're unsure, start with Pages for sites. If you outgrow it, migrating to Workers is a known path.
Closing (Reps4Thor rule)
Cloudflare didn't "break." Your code didn't "break." Reality didn't "break."
You just shipped to the wrong runway and wondered why the plane didn't take off.
Next time your deployment "works" but nothing changes, don't panic — check the product, check the project, check the domain mapping. Then proceed to be smug about how fast you fixed it.