Create a dev branch
Cloudflare Pages creates preview deployments for branches other than the production branch. If main is production, a dev branch can be used for review.
After pushing dev, Pages can create a URL such as dev.example-project.pages.dev. That is useful, but it may be visible to anyone who knows the URL.
If unpublished articles, layout changes, or client review pages are involved, preview should be treated as a protected environment, not a public one.
Create a fixed dev subdomain
A fixed dev subdomain is easier to operate than copying a pages.dev URL every time. For example, production can be column.example.com and dev can be dev-column.example.com.In DNS, point the dev subdomain to the branch preview URL, such as dev.example-project.pages.dev. The branch name in the CNAME target is what makes the subdomain follow the dev branch preview.
This gives you a stable URL for review, Tag Assistant checks, and Access policy configuration.
Protecting only the dev subdomain is not enough
If Cloudflare Access protects dev-column.example.com, the dev subdomain is closed. But the underlying pages.dev preview URL may still be open.Someone can access dev.example-project.pages.dev directly unless that host is also covered by Access.
This is the important operational trap. The visible dev domain and the underlying preview host are different entry points.
Protect pages.dev preview hosts with Access
In practice, protect *.example-project.pages.dev with Cloudflare Access. This covers the branch preview and many deployment URLs that remain available over time.
You can protect only dev.example-project.pages.dev, but Pages keeps deployment URLs around. A wildcard policy is usually simpler and safer.
Preview URLs are not something to manage by deleting one by one. They are better managed by wrapping the preview namespace with Access.
Do not put production behind Access
The production custom domain should not be included in the Access application. It is the public website.
The clean split is public production, protected dev custom domain, and protected pages.dev preview namespace.
After configuration, test in guest mode or with curl: production should return 200, while dev and preview hosts should redirect to Access.
Summary
Cloudflare Pages is easy to start with, but production operations require clear separation between Git integration, preview URLs, Access policies, and old project cleanup.
The key question is always the same: which project, repository, branch, and commit is the visible site actually coming from?