How to Update an AI-Built Website with GitHub and Cloudflare

Need the complete setup and update walkthrough? Explore BUILD • PUBLISH • OWN IT, the $99.99 Colby Technologies guide to ChatGPT, GitHub, and Cloudflare.

Define one change and what must stay intact

Before editing, open the current website and write down the problem. Identify the page, the requested change, and how you will know it worked. Save a screenshot when appearance matters.

For example: “Update the Services page with the approved service description below. Keep its address, contact form, and phone number unchanged. Check the page on a phone before publishing.” That gives your AI assistant a concrete outcome and protects details you already approved.

Ask the assistant to inspect the current repository before editing. An old copy of the website may contain different content or integrations. Avoid combining a small content update with unrelated dependency upgrades or a complete redesign.

Use a branch and preview when you need a review

Confirm which branch Cloudflare treats as production. A commit to that branch may publish automatically when Git integration is enabled. Use a separate branch when you want to inspect the result first.

A GitHub pull request shows the proposed changes before they are merged. Its changed-file view helps you spot an unexpected deletion, a modified phone number, or changes outside the requested page. You do not need to understand every line of code to ask why an unrelated file changed.

With preview deployments enabled, Cloudflare Pages can build a separate version for a branch. Open its preview address and check the content. These previews are public by default unless access controls are configured, so keep confidential material out of them.

GitHub's pull request documentation and Cloudflare's preview deployment documentation explain the review tools and deployment behavior.

Test the actions customers actually use

Start with the changed page, then check the shared elements it touches. If you updated the header, test navigation across several pages. If you changed a form, verify delivery instead of stopping at the success message.

• Open the mobile menu and follow important links.
• Check headings, text wrapping, images, and buttons on a narrow screen.
• Try phone and email links on a suitable device.
• Submit a test inquiry and confirm receipt.
• Open affected pages directly, then refresh them.
• Verify that existing page addresses and approved business facts remain correct.

For a new page, check its title, description, canonical address, and links from related pages. Use the intended production address in permanent page metadata. A preview looking correct does not prove that external integrations are configured for the live domain.

Publish, then verify the production version

Merge the approved change into the production branch when you are ready. Watch the Cloudflare deployment status and confirm that the successful deployment corresponds to your change. A saved GitHub commit alone is not confirmation that the public site updated.

Open the live domain and repeat the relevant checks. Check an affected page in a fresh browser session if an older version appears. Record the published change and the deployment or commit that introduced it.

Use the build troubleshooting guide if the deployment fails. Domain-only failures need a different check; see the custom domain guide.

Know how to recover before the next update

Cloudflare Pages supports restoring a previously successful production deployment; preview deployments are not rollback targets. Choose a version you know worked and verify the website after restoring it.

A deployment rollback does not repair the repository. Correct or revert the faulty source change before another deployment reintroduces it. Also check any separate service affected by the update; restoring website files does not reverse a payment or restore deleted external data.

Cloudflare's rollback documentation describes the supported production recovery process. Keep updates small so the source of a problem is easier to identify.

For a deeper review of test-site access and configuration, see Cloudflare Pages preview versus production. It explains deployment-specific URLs, public preview access, and why test forms and other integrations need separate settings.

For a more complete recovery plan, follow the DIY website backup and restore guide. It separates source archives, hosting settings, credentials, and data held in other services.

For a new interior page, follow the page, path, and navigation checklist. If a confirmed deployment still looks old, use the cache diagnosis guide before changing the source again.