The Last Mile Before Shipping on Cloudflare Pages

A successful build does not mean a site is ready for the public. The real launch work lives in the last mile: agreeing on one domain, showing search engines the preferred URL, making error pages useful, updating caches safely, and knowing how to return to a previous release.

This checklist is for content sites generated by Astro or a similar static builder and deployed to Cloudflare Pages.

Establish one production address

Pages supplies a project.pages.dev address. A custom domain adds another route to the same content. If search engines can browse both freely, they may treat the pages as duplicates.

Set the build’s site value to the final production origin so canonical links, RSS, and sitemap all agree. Redirect non-preferred hostnames rather than relying only on canonical hints inside the page.

Before launch, check that HTTP moves to HTTPS, www and the apex domain converge, old paths return 301 to the right destination, missing pages return an actual 404 status, and every production page has exactly one canonical URL.

Keep response headers deliberate

Static sites can define headers through a root _headers file. X-Content-Type-Options: nosniff, a strict referrer policy, and a minimal Permissions Policy make a reasonable baseline.

Do not paste a large security configuration without understanding its effects. An overly strict Content Security Policy can block fonts, analytics, or ads. Cross-origin isolation can prevent third-party resources from loading. Inventory existing sources, test in preview, and tighten gradually.

Hashed build assets are good long-cache candidates:

/assets/*
  Cache-Control: public, max-age=31536000, immutable

HTML should not receive the same policy. It needs to point visitors to current assets, and the Pages defaults are usually the safer starting point.

Make the site legible to crawlers

A sitemap helps discovery, robots.txt states crawl policy, and RSS serves subscribers. All three should use the production origin and update with every build.

Article pages need unique titles, independent descriptions, canonical links, and readable HTML content. Do not paint the primary text into Canvas or wait for client JavaScript to fetch it. Static HTML is one of this architecture’s accessibility and indexing advantages.

Before adding AdSense, make sure About, Contact, and Privacy are substantive pages. Put the exact publisher record supplied by AdSense at the root ads.txt; do not ship fake ad code or imitation ad placeholders while approval is pending.

Preview, release, and roll back

Cloudflare Pages keeps a deployment history. Open the preview URL before production and inspect the homepage, an article, the 404 page, mobile layout, and important external links. Promote the same reviewed change rather than rebuilding a different artifact by hand.

If production breaks, restoring a known-good deployment is often safer than editing in a rush. Recover service first, reproduce the fault locally, and then publish the correction.

A release script should preserve these gates:

select Node → install locked dependencies → type check → build → upload dist

No upload should follow a failed step. Never deploy the development directory itself; it may include drafts, source files, and configuration that do not belong online.

The first week after launch

Watch real traffic for 404 paths, Core Web Vitals, mobile errors, sitemap access, and incorrectly cached documents. Record a baseline for build time, page count, major asset size, and the most useful performance measures.

A reliable static site is not one that never fails. It is one where every change can be checked, every deployment traced, and every bad release reversed.

Put the last mile into the repository. The next launch will no longer depend on remembering a private checklist.