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

我花了两个星期来调试生产环境中的问题。

一个 sitemap 规则拦截了我的 XML 文件；一个竞态条件（race condition）导致了图片上传失败。我不再靠猜测，而是向我的工作流中添加了三项特定的检查。

我在三个 Astro 5 SSG 网站上运行这些检查：aiappdex.com、findindiegame.com 和 ossfind.com。

这些检查针对的是我实际遇到的故障模式。

  1. Sitemap 验证

我会检查所有域名下的 sitemap-index.xml 是否返回 200 状态码。我使用不跟随重定向的 curl。这可以捕获那些错误重写 URL 的规则。

我还会检查子 sitemaps。我会验证它们是否包含最少数量的 URL。例如，如果 aiappdex.com 的 URL 数量降至 1,000 以下，说明我的数据流水线（data pipeline）出故障了。

  1. IndexNow 提交

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

我会留意 403 错误。403 通常意味着我的密钥验证文件部署失败，或者重定向规则破坏了路径。及早发现这一点可以防止索引延迟。

我在部署后手动运行此操作。这可以确保我提交的是已经在 CDN 上实际生效的 URL。

  1. 定期 Lighthouse 审计

我每周一通过 cron job 运行 Lighthouse 检查。每个网站我会检查一个首页和一个深层页面。

我监控以下指标：

  • Performance（目标值 80 以上）
  • CLS（目标值 0.1 以下）
  • Accessibility 分数

我将 Lighthouse 用作趋势监控工具。如果分数轻微下降，我不会阻止部署。我会利用这些数据来发现 Tailwind 配置或组件布局中的回归（regressions）问题。

为什么是这三项？

我并不使用可用性监控（uptime monitoring）或端到端用户测试。我的网站是静态 SSG 部署。整个运行时（runtime）都是预构建的 HTML 和 CSS。

故障面很小。这三项检查涵盖了生产环境最可能出现故障的情况。

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