我在每次 Cloudflare Pages 构建后都会运行的 3 项部署后检查

我曾花了两个星期来调试那些只在生产环境中出现的问题。

一个 sitemap 规则拦截了我的 sitemap 索引。另一个问题涉及图片上传延迟。

我并不使用完整的端到端（end-to-end）测试套件。相反，我使用三项特定的检查来捕捉我实际遇到的错误。

我在三个使用 Astro 5 SSG 构建并部署在 Cloudflare Pages 上的网站上运行这些检查。

  1. Sitemap 验证

我会检查 sitemap-index.xml 在所有域名上是否都返回 200 状态码。

我还会检查 sitemap-0.xml。我会确保它包含最少数量的 URL。对于其中一个网站，这个数字是 1,000。如果数量下降，说明我的数据流水线（data pipeline）出故障了。

这是我吃过亏才学到的教训。曾经有一个重定向规则导致我的 sitemap 损坏了五天。在浏览器中看起来一切正常，但对爬虫来说却失效了。使用 curl 帮助我立即发现了这个错误。

  1. IndexNow 提交

在 sitemap 检查通过后，我会运行一个脚本将 URL 提交给 IndexNow。这会将我的 URL 发送给 Bing、Yandex、Naver 和 Seznam。

如果 IndexNow 返回 403 错误，说明我的密钥验证文件缺失或重定向规则已损坏。在部署后立即捕捉到这一点可以防止索引延迟。

我在部署后手动运行此操作，而不是在 GitHub Actions 内部运行。这可以确保我提交的是已上线且稳定的 URL。

  1. 每周 Lighthouse 审计

我在每周一的 04:30 UTC 运行 Lighthouse 检查。

我会监控性能、布局偏移（layout shifts）和无障碍评分（accessibility scores）。由于这些网站使用 Astro SSG 且没有客户端 JS，评分应该保持稳定。评分下降则意味着 CSS 或组件的更改破坏了布局。

我不会利用这些评分来阻止部署，而是用它们来监控趋势。

为什么是这三项？

我不使用运行时间监控（uptime monitoring）或 API 检查。我的网站是静态的。Cloudflare 处理基础设施。数据库仅在构建时进行查询。

对于静态 CDN 部署，这三项检查涵盖了我实际面临的风险。

来源：https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-2862