Remove the custom domain first
Before deleting an old Pages project, remove its custom domain. If the production domain is still attached to the old project, cleanup work can affect production.
Move the custom domain to the new project first and confirm that production works from the new Git-integrated project.
Only after the old project no longer owns the production domain should you start deleting deployments or the project itself.
Too many deployments can block project deletion
When deleting an old Pages project, Cloudflare may show an error such as: Your project has too many deployments to be deleted.
This means the project has too many deployment records for the dashboard deletion flow to complete directly.
The project itself cannot be removed until the deployments are reduced.
Log in with Wrangler
Wrangler can list and delete Pages deployments. Start with npx wrangler login and approve the Cloudflare OAuth prompt in the browser.
Then list projects with npx wrangler pages project list and confirm the exact old project name.
This confirmation matters. Pages accounts often contain multiple projects, and the delete commands should be scoped to the old project only.
Delete deployments
List deployments with npx wrangler pages deployment list --project-name columns-old.Delete individual deployments with npx wrangler pages deployment delete DEPLOYMENT_ID --project-name columns-old --force. The force flag may be needed for aliased deployments.In the actual cleanup, the old project had hundreds of deployments, so the deployments were deleted in batches until only the live deployment remained.
Delete the project
After reducing deployments, delete the project with npx wrangler pages project delete columns-old.
Wrangler asks for confirmation. Check that the project name is exactly the old project, then continue.
Finally, run npx wrangler pages project list again and confirm that the old project is gone.
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?