Marico's space
花了两个礼拜排查只在生产环境才会暴露的问题——一个是 _redirects 规则把我自己的 sitemap-index.xml 给拦了，另一个是 Bluesky 图片上传撞上 Cloudflare Pages 部署延迟的竞态问题——之后，我在工作流里加了三个部署后检查。执行快、针对性强，只覆盖我实际踩过的坑，不是一套大而全的端到端测试。
三个站点放在 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；如果部署后低于这个数，说明数据管道可能静默坏了。
这个检查存在的原因：我之前有个 _redirects 规则把 sitemap-index.xml 重写到了 sitemap-0.xml，当紧急 workaround，结果是错的。这规则在线上跑了五天才发现。它把真正的 sitemap-index.xml 拦在爬虫外面，浏览器看起来正常（跟着重定向走了）。curl 用 -o /dev/null -w "%{http_code}" 默认不跟随重定向，所以当时就能发现。
每次 sitemap 检查成功后，运行 node scripts/indexnow.mjs。脚本从每个域名的 live sitemap 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）没有正确部署，或者某个 _redirects 规则把路径搞坏了。部署后立即捕获这个问题很重要，因为 IndexNow 密钥验证窗口不是即时生效的——让它在坏状态里躺着会延迟收录。这个 IndexNow 配置我在本周工具帖子里写过更多细节。
我在部署后手动运行，而不是写在 GitHub Actions 工作流里，因为 Cloudflare Pages 构建需要 2-3 分钟，而 IndexNow 用 live URL 效果最好。用独立的 workflow_dispatch 触发器在部署成功后运行，意味着我提交的是真正已经上线的 URL，而不是可能还在部署中的。
第三个检查用的是 cron——每周一 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 数据库只在 SSG 模式下构建时查询，运行时没什么可查的。
对动态渲染站点来说，这些缺口会有问题。对静态 CDN 部署来说，整个运行时就是预构建好的 HTML、CSS 和几个 JSON 文件，上面的三个检查覆盖了我实际遇到过的失败面。
发布管道有自己的幂等层（从文章 frontmatter 读取 published_urls，跳过已分发的文章），所以每次部署后不需要验证跨分发状态。这是另一个独立的问题。
这是持续 6 个月运行三个 AI 策展目录站点实验的一部分。技术陈述是真实的；这篇文章由 AI 辅助写作。