Marico's space
花了两个礼拜排查只在线上环境才暴露的问题——一个 _redirects 规则把我自己的 sitemap-index.xml 给拦了，还有一个 Bluesky 图片上传和 Cloudflare Pages 部署延迟的竞态问题。痛定思痛，我在 workflow 里加了三个部署后检查。速度快、针对性强，专门对付我自己踩过的坑，不是那种大而全的端到端测试套件。
三个站点（aiappdex.com、findindiegame.com、ossfind.com）跑在 Cloudflare Pages 上，用的是 Astro 5 SSG（静态站点生成）。说说我的检查逻辑。
最简单的一个，也是本该第一天就加上的。Cloudflare Pages 部署完成后，验证三个域名的 sitemap-index.xml 都能返回 200：
for domain in aiappdex.com findindiegame.com ossfind.com; do status=$(curl -s -o /dev/null -w "%{http_code}" "https://$domain/sitemap-index.xml") echo "$domain/sitemap-index.xml → $status" if [ "$status" != "200" ]; then echo "FAIL: $domain sitemap unreachable" fi
done
还会检查 sitemap-0.xml，这是 @astrojs/sitemap 生成的子 sitemap，我断言它至少包含预期的最小 URL 数量。拿 aiappdex.com 来说，阈值是 1000 条——部署后如果低于这个数，说明 ETL 数据管道可能在静默失败。
这个检查的起因是：之前我写了一条 _redirects 规则，把 sitemap-index.xml 重写到 sitemap-0.xml 当作紧急 workaround，结果是错的。这条规则在线上跑了五天才被发现。它让真正的 sitemap-index.xml 无法被爬虫抓取，但浏览器访问时因为跟随重定向，看起来一切正常。用 curl 的 -o /dev/null -w "%{http_code}" 不会跟随重定向，所以马上就能发现这个问题。
每次 sitemap 检查通过后，我就运行 node scripts/indexnow.mjs。这个脚本从各域名读取线上 sitemap XML，收集所有 URL，然后 POST 到 Bing、Yandex、Naver、Seznam 的 IndexNow 接口，使用站点专属的 key。
输出长这样：
aiappdex.com: submitted 1179 URLs → 200 OK
findindiegame.com: submitted 139 URLs → 200 OK
ossfind.com: submitted 144 URLs → 200 OK
如果某个站点返回 403，通常说明 key 验证文件（/<key>.txt）部署有问题，或者某个 _redirects 规则把路径搞乱了。部署后立即捕获很关键，因为 IndexNow key 验证不是即时的，长时间处于错误状态会延迟页面被索引。
我选择手动触发而不是集成到 GitHub Actions workflow 里跑，主要是因为 Cloudflare Pages 构建需要 2-3 分钟，而 IndexNow 要求提交真实可访问的 URL。用 workflow_dispatch 单独触发意味着我提交的是已完全上线的链接，而非仍在部署中的。
第三个检查跑在 cron 上——每周一 04:30 UTC——不是每次部署都跑。速度较慢（每站点 3-4 分钟，9 个 URL 合计），对静态站点来说每天跑太浪费了。
workflow 用的是 treosh/lighthouse-ci-action，每个站点测一个首页和一个深层入口页：
matrix: site: - { domain: aiappdex.com, sample: /models/timm-vit-base-patch16-clip-224-openai/ } - { domain: findindiegame.com, sample: /games/dredge-1562430/ } - { domain: ossfind.com, sample: /alternatives/ghost/ }
我盯着 Performance 低于 80、CLS（布局偏移）超过 0.1、或 accessibility score 下降这几个指标。Astro SSG 加零客户端 JS 应该在这三项上稳稳的——如果分数下滑，通常意味着 Tailwind v4 配置或广告位组件改了布局渲染行为。跑完的结果会上传到 temporaryPublicStorage，方便我对比前后版本的差异。
我没有设置硬性失败阈值来阻止部署。这些站点目前 pre-revenue（预收入阶段），流量基本为零，因为 Lighthouse 分数从 94 掉到 88 就阻止上线太因噎废食了。我把 Lighthouse 当趋势监控，不当关卡。
没有 uptime 监控——依赖 Cloudflare 自有的基础设施状态。没有端到端用户流程测试。没有 API 可用性检查——Turso DB（分布式 SQLite 数据库）只在 SSG 模式下构建时查询，运行时压根没有东西可查。
换做动态渲染站点，这些缺口可能就是坑。但对于静态 CDN 部署，整个运行时就是预先生成的 HTML、CSS 和几个 JSON 文件，上面三个检查已经覆盖了我遇到的实际问题面。
发布 pipeline 有自己的幂等层（从文章 frontmatter 读取 published_urls，跳过已分发的帖子），所以部署后不需要验证跨平台分发状态。那是另一码事。
原文链接：https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-2m5j