How to Fix a Cloudflare Pages Project Stuck on an Old GitHub Connection

Changing the Git remote is not enough

Cloudflare Pages is convenient when it is connected to GitHub. Push to the production branch, and Pages deploys the site automatically.

The problem appears when the GitHub repository is renamed or the Pages connection is disconnected. The local remote can point to the new repository, and GitHub can show the latest main branch, while Cloudflare Pages still serves an older deployment.

In that situation, the issue is not the local Git push. The issue is which repository and deployment state the Pages project is actually using.

Create deployment is not the same as reconnecting GitHub

Cloudflare Pages has a Create deployment button. The label can make it feel like Cloudflare will simply pull the latest GitHub commit again.

Depending on the project state, it may instead lead to Direct Upload, where you upload HTML, CSS, JavaScript, or a folder manually.

Direct Upload is useful when you intentionally want to publish prebuilt files. It is not a GitHub reconnection flow. For a content site managed through Git, mixing the two makes it harder to know which commit is live.

Direct Upload projects cannot be switched to Git integration later

Cloudflare documentation explains that a Direct Upload Pages project cannot later be switched to Git integration. If you want automatic Git deployments, you need to create a new Pages project connected to Git.

That means the practical recovery path is usually not to search for a reconnect button inside the old project. It is to create a new Git-integrated Pages project.

Static files may still work when uploaded manually, but production traceability matters more. A business or media site needs a clear relationship between Git history and the live site.

Create a new Pages project

Create a new Cloudflare Pages project and connect it to the correct GitHub repository. Set the production branch to main.

Before moving the custom domain, check the generated pages.dev URL. Confirm that the latest commit is reflected, the top page works, the sitemap is current, removed pages are gone, and analytics tags are present.

Only after that should you remove the custom domain from the old project and attach it to the new one. Moving the production domain should be the final step, not the first experiment.

What to verify

Do not rely only on GitHub showing the latest commit. Check that Cloudflare Pages has a deployment for that commit.

Also confirm that the new project has Git Provider enabled, the production branch is main, and the old project no longer owns the custom domain.

The dangerous assumption is that a successful push means production changed. In Cloudflare Pages operations, the deployment history is the source of truth.

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?