Back to posts

ホスティング移行後の確認リスト：当日・数日・数週間で見るもの

Published
CATEGORIES
Cloudflare
Tags
#Cloudflare Pages #移行 #運用

このサイトの Netlify から Cloudflare Pages への移行について、先に「NetlifyからCloudflare Pagesへ移すときのチェックリスト」として、切り替え前に洗い出す項目をまとめました。今回はその続きで、切り替えた後に見るものです。

DNS を切り替えて新しいサイトが表示された時点で、移行の山は越えたように見えます。ただ、実際に事故が起きるのはその後です。旧 URL へのアクセスが意図しない飛び方をしていないか、計測が止まっていないか、検索エンジン側の情報が新しい URL に移っているか。どれも「表示された」だけでは分かりません。

先行記事（移行前）この記事（移行後）
目的移行に必要なものを漏れなく洗い出す切り替えが正しく効いているかを確認し、後始末を終わらせる
見るものビルド設定・ドメイン・リダイレクト・代替手段表示・ステータスコード・インデックス・計測・契約
期間切り替え前まで切り替え当日〜数週間

考え方： 移行の完了は「新しいサイトが表示された日」ではなく、「旧 URL・計測・旧ホスティングの後始末が終わった日」。この記事のリストは、その後始末を時点ごとに並べたものです。

切り替え当日：まず「正しく届いているか」

当日に見るのは、サイトが新しい配信先から正しく届いているかどうかです。項目は多いですが、どれも数分で終わります。

  • トップページと、アクセスの多い記事ページ数本が表示される（PC とスマートフォンの両方）
  • 代表的な旧 URL を踏んで、新 URL に着地するか。あわせて、恒久移転のつもりのものが 301 で飛んでいるか（後述の 302 問題）
  • www あり・なしの両方でアクセスし、寄せ先が決めた側（このサイトでは apex）に統一されるか
  • HTTPS で開けて証明書エラーが出ないか。Cloudflare ダッシュボードのカスタムドメインが Active になっているか
  • 存在しない URL を開いて、自前の 404 ページが返るか（真っ白や素のエラーページになっていないか）
  • サイト内検索で既存の記事がヒットするか
  • 問い合わせフォームなど、送信を伴う機能があればテスト送信して届くか
  • RSS フィードが新しいドメインで取得できるか。favicon や OGP 画像など、静的ファイルの欠けがないか

リダイレクトのステータスコードは、当日のうちに必ず見ます。Cloudflare Pages の _redirects は、ステータスコードを省略すると 302（一時的な移転）になります。移行前の設定を書き写したルールほど、「恒久移転のつもりで 302」は起きやすい組み合わせです。ブラウザの開発者ツールか curl -I で、代表的な旧 URL 数本の応答を確認するのが確実です。

証明書がなかなか有効にならない場合は、ドメイン側の検証が通っていない可能性があります。Cloudflare の既知の問題として、証明書の検証リクエスト（/.well-known/acme-challenge/ 配下）へのアクセスが制限されているとドメインが有効化されない、というケースが公式ドキュメントに挙がっています。当てはまりそうなら、Access や Worker でそのパスを塞いでいないかを先に疑います。

数日後：検索と計測が「移ったか」

当日の確認が終わっても、検索エンジンと計測の側はすぐには追いつきません。数日置いてから見る項目です。

  • Google Search Console のカバレッジレポートで、旧 URL のインデックスが新 URL に移り始めているか
  • 「見つかりませんでした（404）」が急に増えていないか。増えていたら、上位の URL から順にリダイレクトの追加漏れを疑う
  • サイトマップが Search Console に正しく読み込まれているか
  • 解析側でセッションやページビューが受信できているか
  • 外部サイトからよくリンクされている記事が、リンク先 URL のままで開けるか

解析については、このサイト特有の事情があります。旧サイトの解析タグは Universal Analytics の ID のままで、移行前から計測が止まっていました。なので移行後の確認は「元に戻ったか」ではなく、「移行のついでに入れ直した計測が、実際に受信しているか」を見ることになります。タグを入れたことと、データが届いていることは別なので、リアルタイムレポートで自分のアクセスが拾えるかまで見ます。

Search Console の数字は反映に数日かかるので、切り替え翌日に 404 が並んでいても慌てて設定をいじらない方がいいです。見るべきは絶対数より増え方で、収束していくなら様子見、増え続けるなら URL の棚卸しに戻ります。

注意： 404 の全件対応は目指さない。存在しない URL へのアクセス自体は移行前からあるもので、リダイレクトが必要なのは「以前は記事があった URL」と「外部からリンクされている URL」だけです。

数週間後：旧ホスティングの片付け

表示もインデックスも安定したら、最後に旧環境の後始末です。ここを放置すると、「二重デプロイ」と「払い続けているだけの契約」という、静かな事故の種が残ります。

  • 旧ホスティング（Netlify）の自動デプロイが止まっているか。リポジトリ連携が残っていると、push のたびに旧サイト側もビルドされ続ける
  • 旧ホスティング側に残した独自ドメイン設定や DNS レコードの控えを整理したか
  • 旧ホスティングのプランと請求を確認し、不要なら解約する。ドメイン自体の契約はレジストラ側の話なので、ホスティングの解約と混同しない
  • www の寄せ先やリダイレクトまわりで、移行時に「暫定」にした設定があれば、この時点で正式な形に直す
  • _redirects の件数が上限（静的 2,000 件＋動的 100 件）に近づいていないか。旧 URL の付け替えが今後も増えるなら、Bulk Redirects への移行を検討する

旧ホスティングをいつ閉じるかは、少し悩むところでした。切り替え直後は、何かあったときに旧環境へ戻れることが保険になります。一方で、連携を残したままにすると「どちらが本番か分からない」状態が続きます。自分の判断基準は、Search Console の 404 が収束し、解析が安定して受信できていること。この2つが見えてから連携解除と解約に進む、という順番にしました。

_redirects の上限は、個人ブログの規模では当面ぶつからない数字です。ただ、Cloudflare Pages ではクエリパラメータを条件にしたリダイレクトが _redirects で書けないなど、Netlify 時代の書き方がそのまま通用しない部分もあります。「件数」より「移しきれなかったルールが残っていないか」を、移行後の棚卸しで一度は見ておく方が実用的でした。

おわりに

移行作業というと切り替え当日の話になりがちですが、作業量としては、その後の確認と片付けの方が地味に長いです。このリストは今回の移行用に作りましたが、時点ごとに「何を見るか」だけを抜き出してあるので、次にホスティングを移すことがあっても、そのまま使い回せる形にしておきました。

参考

Tags Categories