Marico's space
花了两周排查只有生产环境才会暴露的问题——一个是 sitemap 的 _redirects 规则误把 sitemap-index.xml 给重定向走了，另一个是 Bluesky 图片上传跟 Cloudflare Pages 部署延迟的竞态条件——之后，我在工作流里加了三道部署后检查。它们很快，专门针对我实际踩过的坑，不是那种大而全的端到端测试套件。
三个站（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 生成的实际 URL 子 sitemap——并断言它至少包含最低预期的 URL 数量。对 aiappdex.com 来说阈值是 1000，如果部署后掉到这个数以下，那 ETL（数据抽取转换加载）管道大概率悄悄崩了。
这个检查存在的理由：我之前有一条 _redirects 规则把 sitemap-index.xml 重写到 sitemap-0.xml，当时是应急用的临时方案，结果是错的。这个规则在线上跑了五天才被发现。它把真正的 sitemap-index.xml 对爬虫隐藏了，但浏览器看起来正常（因为跟着重定向走了）。Curl 用 -o /dev/null -w "%{http_code}" 默认不跟随重定向，所以能立刻抓到这个问题。
每次 sitemap 检查通过后，运行 node scripts/indexnow.mjs。脚本从各个域名读取 live sitemap XML，收集所有 URL，然后 POST 到 IndexNow 端点，分别用各自的站点密钥提交给 Bing、Yandex、Naver 和 Seznam。
输出长这样：
aiappdex.com: submitted 1179 URLs → 200 OK
findindiegame.com: submitted 139 URLs → 200 OK
ossfind.com: submitted 144 URLs → 200 OK
如果某个站点 IndexNow 返回 403，通常意味着密钥验证文件（/<key>.txt）没有正确部署，或者 _redirects 规则把路径搞乱了。部署后立刻检查很关键，因为 IndexNow 密钥验证窗口不是即时生效的——让它卡在坏状态里会耽误收录。我在这周的 tools 文章里写过 IndexNow 的更多细节。
我是在部署完成后手动跑这个脚本，而不是放在 GitHub Actions 工作流里，原因是 Cloudflare Pages 构建要 2-3 分钟，而且 IndexNow 用 live URL 效果最好。作为独立的 workflow_dispatch 触发器在部署成功后再运行，意味着我提交的是真正已经上线的 URL，而不是可能还在部署中的。
第三个检查是定时任务——每周一 04:30 UTC——不是每次部署都跑。它比较慢（每个站 3-4 分钟，三个站共九个 URL），每天都跑对这种静态站点来说太浪费了，毕竟运行时本来就不会变。
工作流用 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、或者无障碍分数退化。Astro SSG 没有客户端 JS，三个指标应该很稳——如果滑了，说明 Tailwind v4 配置或者广告位组件改了布局渲染行为。结果会上传到 temporaryPublicStorage，方便我对比前后的退化情况。
我没有设硬性失败阈值来拦截部署。这些站现在还没开始变现，流量几乎为零，因为 Lighthouse 分数从 94 掉到 88 就拦截部署，太因噎废食了。我把 Lighthouse 当趋势监控，不是关卡。
没有 uptime 监控——我信 Cloudflare 自家的基础设施状态。没有端到端用户流程测试。没有 API 可用性检查——Turso DB 只在 SSG 模式下构建时查询，运行时根本没什么可查的。
对动态渲染站点来说，这些缺口会很要命。对静态 CDN 部署来说，整个运行时就是预构建的 HTML、CSS 和几个 JSON 文件，上面三个检查已经覆盖了我实际碰到的故障面了。
发布管道有自己的幂等层（它从文章 frontmatter 读取 published_urls，跳过已经分发过的帖子），所以每次部署后不需要验证跨平台分发状态。那是另一个维度的事。
原文链接：https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-1bpc