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

我花了两个星期来修复生产环境中的 Bug。一个错误的重定向规则导致我的 sitemap 被拦截。由于部署延迟，导致图片上传失败。

现在，我在每次 Cloudflare Pages 构建后都会运行三项特定的检查。我并不使用完整的测试套件，而是使用针对我实际故障点的快速检查。

我在三个网站上使用 Astro 5 SSG：aiappdex.com、findindiegame.com 和 ossfind.com。

以下是这三项检查：

  1. Sitemap 验证 我会验证所有域名下的 sitemap-index.xml 是否返回 200 状态码。我也会检查 sitemap-0.xml。我会确保 URL 数量保持在设定的阈值以上。对于 aiappdex.com，我预期至少有 1,000 个 URL。如果数量下降，说明我的数据流水线（data pipeline）出问题了。

我使用不跟随重定向的 curl 命令。这可以捕获那些由于重定向规则导致 sitemap 在浏览器中看起来正常，但却会破坏爬虫抓取的错误。

  1. IndexNow 提交 在 Sitemap 检查通过后，我会运行一个脚本将 URL 提交给 IndexNow。这会通知 Bing、Yandex、Naver 和 Seznam 有新内容。

我在部署后手动运行此操作。这能确保我提交的是真正已上线的 URL。如果 IndexNow 返回 403 错误，我就知道是我的密钥验证文件丢失了，或者是重定向规则出错了。及早发现这一点可以防止索引延迟。

  1. 每周 Lighthouse 审计 我在每周一 UTC 时间 04:30 运行 Lighthouse 检查。每个网站我会检查一个首页和一个深层页面。

我会关注以下指标：

  • Performance 低于 80
  • CLS 高于 0.1
  • Accessibility 分数下降

由于我的网站使用静态 HTML 和 CSS，分数应该保持稳定。如果分数下降，很可能是最近对 Tailwind 或某个组件的更改破坏了布局。我利用这些结果来监控趋势，而不是用来阻止构建。

我不监控运行时间（uptime）或 API 的可用性。我的网站是静态的。数据库仅在构建时运行。对于静态 CDN 部署，这三项检查已经涵盖了我的主要风险。

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