Production serves the approved customer-facing website; a preview serves a separate version for review. In a Git-connected Cloudflare Pages project, the configured production branch controls production deployments, while allowed non-production branches can produce previews. Preview URLs are public by default. Their automatic noindex header is a search instruction, not a password or an access restriction.
Which URL should you use when reviewing a change?
Cloudflare distinguishes a deployment’s hash-based preview address from its branch alias. A branch alias points to the latest deployment for that branch, so the page at that address can change while a review is in progress. The hash-based address identifies a specific deployment.
For a clear approval record, save the exact deployment URL and the associated commit, plus the date and checks performed. Use a branch alias for ongoing work when that is useful, but recheck the current deployment before treating an earlier approval as current.
See Cloudflare’s preview deployment documentation for URL behavior and default access. Opening a preview link does not itself publish that version to your custom production domain.
Does every GitHub change publish to the live site?
It depends on the project’s branch settings. Check the production branch name and whether automatic production deployments are enabled. Do not assume a branch named main is only a working draft.
Cloudflare’s branch build controls let projects control production builds and which branches produce preview deployments. If a preview did not appear, check those settings and the deployment log before concluding that the code was lost.
Keep the review process explicit: make a proposed change, inspect its diff and preview, approve the exact version, then publish through the project’s agreed production workflow. The website update guide covers that end-to-end sequence.
Does noindex make a preview private?
No. A noindex instruction asks supporting search engines not to index a response. It does not stop someone with the link from opening the page. Google’s noindex documentation describes indexing control; sensitive content needs actual access protection.
If your review contains confidential information, use appropriate access controls before adding that content. Cloudflare documents an Access option for Pages previews. Verify what it protects, test in a signed-out browser, and check any custom preview domain separately. Do not assume that protecting one hostname protects every address where the same deployment is reachable.
The simplest early-stage approach is often to use approved public copy and synthetic test details. A hard-to-guess preview URL is still a public URL when no access restriction applies.
Which settings should be different in previews?
Separate anything that could affect a real customer or production records. A visually separate website can still call the same email service, database, booking system, or payment account as production.
- Email: send test notifications to a designated test inbox instead of staff or customers.
- Payments: use the provider’s test mode and matching test credentials.
- Data: use an isolated test data source when a form writes records or changes bookings.
- Anti-spam: configure permitted test hostnames and use the provider’s supported testing approach.
- Analytics: keep test visits from being mistaken for customer activity.
Cloudflare’s Functions bindings documentation describes configuring production and preview bindings. Review both environments deliberately; do not copy a production secret into a public file to make the preview work.
Some integrations need extra setup outside Cloudflare. Record those dependencies so “works on preview” does not conceal a production-only failure.
What does a safe preview review look like?
Example: adding a quote-request page
Create the change on a review branch. Confirm the preview uses a test inbox and no real customer data. Send one labeled test, check validation and failure states, and record the exact deployment reviewed. Once the approved version reaches production, send a new labeled test on the business domain and verify its real destination.
- Confirm the preview belongs to the right repository, branch, and commit.
- Check access restrictions before uploading confidential material.
- Verify test settings and recipients before clicking forms or transactional buttons.
- Review the page on a phone and with a keyboard.
- Record unresolved issues and approve only the version actually tested.
Use the launch testing checklist for the customer-facing checks. A preview is a place to gather evidence, not evidence that the checks have already passed.
What must be checked again after production deploys?
Verify the deployment succeeded for the expected commit, then open the actual public domain. Recheck the changed content, critical links, contact delivery, and any feature with environment-specific configuration.
Confirm public page canonicals use the production domain and that indexable production pages do not carry preview noindex settings. Keep preview URLs out of public navigation and the production sitemap.
If the production build fails, follow the build-error troubleshooting steps. If the new production site is faulty, use the project’s recovery plan and correct the repository before the next release.
The BUILD • PUBLISH • OWN IT guide brings these review habits into the larger ChatGPT, GitHub, and Cloudflare website workflow.
Keep review and publication clear
BUILD • PUBLISH • OWN IT is Colby Technologies’ 44-page PDF guide for $99.99 USD. It covers the ChatGPT, GitHub, and Cloudflare website workflow. Colby will personally assist if you get stuck following the guide. Additional hands-on work may carry a fee, with the scope and price agreed before work begins.
Applicable tax is shown at checkout. Third-party service charges are separate. Review the guide contents and purchase terms for the full details.