X记录空间在花了两个星期调试只在生产环境中出现的问题之后——一个站点地图重定向规则阻塞了我自己的 sitemap-index.xml 文件，以及Bluesky 图片上传与 Cloudflare Pages 部署延迟之间的冲突——我在工作流程中添加了三个部署后检查。这些检查快速且针对我实际遇到的故障模式，而不是完整的端到端测试套件。
三个网站（aiappdex.com、findindiegame.com、ossfind.com）都托管在 Cloudflare Pages 上，并使用了 Astro 5 SSG。以下是我的检查内容。
检查 1：网站地图可访问性
最简单的检查，也是我从一开始就应该做的。在 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实际生成的 URL 子站点地图@astrojs/sitemap，并确认其包含的 URL 数量至少达到预期最低值。对于 aiappdex.com，该阈值为 1000；如果在部署后 URL 数量低于此值，则 ETL 数据管道可能已悄然中断。
之所以有这个检查：我之前为了应急，写了一条_redirects规则来重写重定向，结果发现是错的。这条规则生效了五天才被发现。它阻止了爬虫程序访问真实的页面，但在浏览器中却显示正常（浏览器跟随了重定向）。Curl 默认不会跟随重定向，所以它应该能立即发现这个问题。sitemap-index.xmlsitemap-0.xmlsitemap-index.xml-o /dev/null -w "%{http_code}"
检查 2：IndexNow 批量提交
每次成功检查站点地图后，我都会运行该脚本node scripts/indexnow.mjs。该脚本会从每个域读取实时站点地图 XML，收集所有 URL，并使用特定于站点的键将它们 POST 到 Bing、Yandex、Naver 和 Seznam 的 IndexNow 端点。
输出结果如下：
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）部署不正确，或者某个规则破坏了路径。部署后立即发现此问题至关重要，因为 IndexNow 的密钥验证窗口并非瞬时完成——让它处于错误状态会延迟索引。我在本周的工具文章_redirects中详细介绍了 IndexNow 的设置。
我选择在部署完成后手动运行此操作，而不是将其集成到 GitHub Actions 工作流中，因为 Cloudflare Pages 构建需要 2-3 分钟，而 IndexNow 最适合处理已上线的 URL。workflow_dispatch在部署成功后单独触发此操作，意味着我提交的是实际已上线的 URL，而不是可能仍在部署中的 URL。
检查3：每周灯塔抽查
第三项检查通过定时任务运行——每周一 04:30 UTC——而不是每次部署后都运行。它的速度较慢（每个站点 3-4 分钟，总共 9 个 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/ }
我正在监控性能指标是否低于 80、CLS 指标是否高于 0.1 或可访问性评分是否下降。不使用客户端 JS 的 Astro SSG 在这三项指标上应该保持稳定——如果出现下滑，则意味着 Tailwind v4 配置或广告位组件的布局绘制行为发生了变化。结果会上传，temporaryPublicStorage以便我比较更新前后的差异，从而发现问题所在。
我不会设置会阻止部署的硬性失败阈值。这些网站目前还没有盈利，流量几乎为零；仅仅因为 Lighthouse 评分从 94 降到 88 就阻止部署，未免太过分了。我把 Lighthouse 当作趋势监控工具，而不是门槛。
我故意不去检查的内容
没有正常运行时间监控——我依赖于 Cloudflare 自身的基础设施状态。没有端到端用户流程测试。没有 API 可用性检查——Turso 数据库仅在 SSG 模式下构建时查询，因此运行时无需进行任何检查。
对于动态渲染的网站来说，这些缺陷至关重要。但对于静态 CDN 部署而言，由于整个运行时环境都是预先构建的 HTML、CSS 和少量 JSON 文件，上述三项检查已经涵盖了我遇到的实际故障情况。
发布管道有自己的幂等层（它published_urls从文章的 frontmatter 读取信息并跳过已发布的文章），所以我不需要在每次部署后验证交叉发布状态。那是另一个问题。
