𝟯 Cloudflare Pagesのビルド後、私が必ず行う3つのポストデプロイ・チェック
本番環境のデバッグに2週間を費やしました。
サイトマップのルールがインデックスファイルをブロックしたり、レースコンディションによって画像のアップロードに失敗したりしました。これらの問題は、デプロイ後にしか発生しませんでした。
現在、私はビルドのたびに3つの特定のチェックを行っています。フルセットのテストスイートは使いません。実際の失敗ポイントを狙った、迅速なチェックを行っています。
これらは、Astro 5 SSGで構築された3つのサイト（aiappdex.com、findindiegame.com、ossfind.com）で実施しています。
𝟭. サイトマップの可用性と整合性
すべてのドメインで sitemap-index.xml がステータスコード200を返すことを確認します。
また、sitemap-0.xml もチェックします。URLの数が最小しきい値を満たしていることを確認します。aiappdex.comの場合、そのしきい値は1,000です。もしこれを下回っていれば、データパイプラインが失敗したことを意味します。
これは苦い経験から学びました。不適切なリダイレクトルールが、ブラウザでは正常に動作するものの、クローラーをブロックしてしまうことがあったのです。curl を使ってステータスコードを確認することで、エラーを即座に検知できるようになりました。
𝟮. IndexNowへの送信
サイトマップのチェックを通過した後、スクリプトを実行してURLをIndexNowに送信します。これにより、Bing、Yandex、Naver、Seznamに新しいコンテンツを通知できます。
IndexNowが403エラーを返す場合、キー検証ファイルが不足しているか、リダイレクトルールによってパスが壊れています。これを早期に発見することで、インデックス登録の遅延を防ぐことができます。
これはデプロイ後に手動で実行しています。これにより、実際に稼働しており、安定しているURLのみを送信できるようにしています。
𝟯. Lighthouseのトレンドモニタリング
毎週月曜日に定期的にLighthouseチェックを実行しています。このチェックでは、パフォーマンス、レイアウトシフト、アクセシビリティを確認します。
致命的なエラーよりも、トレンド（傾向）を注視しています。スコアがわずかに低下しても、デプロイをブロックすることはありません。これらの結果を利用して、Tailwindの設定やレイアウトコンポーネントにおけるリグレッション（退行）を特定します。
なぜこの3つなのか？
Cloudflareを信頼しているため、アップタイムモニタリングは使用していません。また、サイトが静的であるため、エンドツーエンド（E2E）テストも使用していません。静的なCDNデプロイメントにおいて、これら3つのチェックは主要なリスクをカバーしています。
出典: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-3a61