Cloudflare Pages 上线前的最后一公里

构建成功不等于网站已经准备好公开。真正的上线工作集中在最后一公里：域名是否统一、搜索引擎看到哪个地址、错误页面是否可用、缓存能否安全更新，以及出问题时怎样回到上一个版本。

这份清单适用于由 Astro 等静态生成器构建、部署到 Cloudflare Pages 的内容站。

确定唯一正式地址

Pages 会提供 project.pages.dev 地址，绑定自定义域名后又会增加一个入口。搜索引擎若能同时访问多个地址，就可能把同一内容视为重复页面。

构建配置中的 site 应设置为最终正式域名，canonical、RSS 与站点地图都从它生成。随后为非首选域名建立重定向，而不是仅依赖页面里的 canonical 提示。

上线前检查几类 URL：

• HTTP 是否跳转到 HTTPS；
• www 与裸域名是否统一；
• 旧路径是否返回 301 到正确新路径；
• 不存在的页面是否返回真正的 404 状态；
• 每个正式页面是否只有一个 canonical。

响应头要保守而明确

静态站可以通过根目录下的 _headers 文件设置响应头。X-Content-Type-Options: nosniff、严格的 referrer policy 与最小权限的 Permissions Policy 是合理起点。

不要在不理解影响时复制一整套安全头。过于严格的 Content Security Policy 会阻断字体、统计或广告；跨源隔离头则可能让第三方资源无法工作。先列出现有资源来源，在预览环境验证，再逐步收紧。

带哈希的构建资源适合长期缓存：

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

HTML 不应套用同样策略。它需要及时指向最新资源，通常交给 Pages 的默认缓存行为更稳妥。

让爬虫读懂站点

站点地图负责发现页面，robots.txt 说明抓取范围，RSS 服务于订阅者。三者都要使用正式域名，并在每次构建时更新。

文章页至少应包含唯一标题、独立摘要、规范链接和可读取的正文。不要把主要内容只画进 Canvas 或等到客户端脚本运行后才请求。静态 HTML 正是这套架构在可访问性与索引方面的优势。

准备接入 AdSense 时，还要确保隐私政策、联系页面与关于页面不是空壳。ads.txt 必须放在域名根路径，并使用 AdSense 后台提供的真实发布商记录。批准前不要保留虚假的广告代码或模拟广告占位。

预览、发布与回滚

Cloudflare Pages 会保留部署历史。正式发布前先打开预览地址，检查首页、文章页、404、移动布局和关键外链。预览环境通过后，再把同一提交推进生产。

若生产版本出现问题，最快的处理通常是回滚到已知正常部署，而不是在线上匆忙修改。恢复服务之后，再在本地复现并发布修复版本。

脚本化部署也应保留这些安全门：

选择 Node 版本 → 安装锁定依赖 → 类型检查 → 构建 → 上传 dist

任何阶段失败，上传都不应继续。不要把本地开发目录直接上传，因为其中可能包含草稿、源文件和不需要公开的配置。

上线后的第一周

发布不是终点。第一周重点观察实际访问：404 路径、Core Web Vitals、移动端错误、搜索引擎能否读取站点地图，以及是否存在被错误缓存的页面。

同时记录第一版基线：构建时间、页面数量、主要资源体积和关键性能指标。以后每次增加功能，就能判断它究竟让网站变好了，还是只让技术栈变大了。

一个可靠的静态站，不是永远不出错，而是每次变更都可验证、每次发布都可追踪、每次故障都可回退。

把最后一公里写进项目，下一次上线就不必重新依赖记忆。这正是简单部署流程最重要的价值。