WordPress 移行後の確認：検索流入、旧ホスト、更新契約の整理

新サイトが開き、移行ツールも完了と表示すると、すぐ旧ホストを解約したくなるかもしれません。しかし旧環境がメール、DNS、転送、ダウンロードファイルを提供し続けている場合があります。新サイトもトップページしか確認しておらず、フォーム通知や最新データは未検証かもしれません。移行の後始末では、こうした残る依存関係を一つずつ解決します。

後始末の文書を、サービスの引き継ぎ記録として考えます。何が移り、誰が確認し、何を残し、いつ支払いを止められるかを記します。本記事は切り替え後から始め、ファイル移行手順は繰り返しません。確認可能な証拠を残すことで、旧サービスを安心して停止し、新サイトの継続的な管理者も決めます。

切り替え時刻と比較の基準を残す

本番の切り替え日、タイムゾーン、主要 URL、新旧ホスト、変更範囲を記録します。ホストだけ変えたのか、ドメイン、画面構成、フォームサービスも変えたのか。範囲によって見るべき結果は違います。基準がなければ数日後のアクセス変動を見ても、どの設定を同時に変えたのか分からなくなります。

移行前の主要ページ一覧、重要機能のテスト結果、取得できるアクセスとエラーの記録を保存します。同じ時間帯と条件で比較してください。平日と休日、販促日と通常日には元から差があります。分析ツールやタグ設定も同時に変えた場合はその旨を記し、計測方法の変化を実際の訪問者減少と取り違えないようにします。

1. 切り替え時刻、URL、同時に変更した項目を記録する。
2. トップページ、人気記事、フォーム、ダウンロードページの検証基準を残す。
3. 毎日結果を確認する担当者と、主要機能が失敗した場合の連絡先を決める。

アクセス推移より先に機能を確認する

最初は訪問者が実際にする操作から始めます。記事を開く、サイト内を検索する、添付ファイルをダウンロードする、フォームを送る、必要なログインを行うなどです。いつものブラウザーだけでなく、スマートフォンや別の回線でも確認します。URL、時刻、操作、結果を毎回記し、失敗時は再現手順を残します。

新旧ホストのログを比較し、本番アクセスが徐々に新環境から提供されているか確かめます。旧サイトへのリクエストが残る場合は、通常の訪問者、定期的なコールバック、更新し忘れたダウンロードリンクなど、発生元を調べます。総リクエスト数だけで停止を決められません。特に旧ホストがサイト以外のサービスも担っている場合は注意が必要です。

旧サイトが最後に受け取ったコメントやフォームなど、データが両側に分かれていないか調べます。保存と対応が済んでから、旧サイトが不要な新規データを受け取らないようにします。稼働中の新サイトへ旧データベースを丸ごと上書きしてはいけません。切り替え後に増えた内容が消えるおそれがあります。データの種類ごとに統合方法を決めます。

検索レポートで問題を絞り、早合点しない

Search Console の検索パフォーマンスでは、ページ、クエリ、端末、日付ごとにクリック数と表示回数を見られます。まず同じ重要ページ群を比較し、サイト全体の変化か一部の記事の減少かを分けます。ドメインも変えた場合は旧新両方のデータを見て、新サイトで集まり始めた数値だけを追わないでください。最新データはまだ収集中の場合があり、一時間だけで結論を出せません。

インデックス登録レポートの「登録されていない」は、必ずしもエラーではありません。削除済みページ、妥当な重複 URL、意図して非公開にした内容には正当な理由があります。本来公開されるべき重要 URL については URL 検査ツールで状態を確認し、テスト用 noindex、誤った canonical、無効な転送が残っていないか調べます。

例えば以前よく読まれた手作りの解説記事が急に減少したら、旧リンクを実際に開き、正しい新記事へ行くか確認します。次に本文、画像、インデックス可能な状態を確認します。技術的な経路が正常なら、クエリと比較期間を調べます。原因を絞るための手順であり、発生時期が近いだけでホスト変更が検索順位を下げたとは断定できません。

新環境固有のバックアップと担当者を用意する

移行前のバックアップは旧環境のある時点を表します。新サイトの稼働後は、別のバックアップ予定、遠隔地での保存、復元方法が必要です。まず新環境のバックアップを手動で作成し、完全なデータを取得できることを確かめ、以後の定期処理が予定どおり動くか確認します。旧ホストに保存し続けると、その停止時に復旧手段まで失うかもしれません。

必要な移行前のコピー、切り替え記録、設定の差分を残し、ファイル名に環境と時刻を入れます。各バックアップの用途と保管責任者を決め、区別できない圧縮ファイルをため込まないでください。個人情報を含むコピーへのアクセスを制限し、内部の保存期限を過ぎたら手順に沿って処理します。

引き継ぐ人は少なくともログイン入口、障害時の連絡先、新バックアップの保存先、更新時間帯を知る必要があります。プラグインのライセンス、フォームの送信メール、定期実行ジョブの担当者も明記します。移行当日の作業者だけが設定を知っているなら、サイトが動いていても運用の引き継ぎは未完了です。

旧サービスを項目ごとに停止できるか判断する

旧アカウントのホスティング、メール、DNS、ドメイン、証明書、CDN、転送を表にし、それぞれ「移行済み」「使用継続」「要確認」と記します。ホスト変更はドメイン更新の停止を意味しません。ドメインも変えた場合は、旧ドメインをリンク転送やメール受信のために残すこともあるので、旧アカウント全体を一つの支出として扱わないでください。

「移行後何日で削除できる」という共通の答えはありません。停止前に主要機能の安定、旧環境に必要なリクエストやデータが残らないこと、新バックアップの利用可能性、依存サービスの移行先を確認します。未解決の項目には次の確認日と担当者を決め、早すぎる削除も無期限の放置も避けます。

サービス提供者に、自動更新停止、サイト削除、プラン削除、返金申請がそれぞれどのような結果になるか確認しましょう。本記事の確認時点の Hostinger 公式案内では、自動更新を止めても期間満了までサービスは維持されます。一方、条件を満たす返金の処理が完了するとサービスは終了します。二つのボタンを同じ請求整理だと考えてはいけません。

請求を確認し、後始末の証拠を残す

停止前には必要なサイトファイル、データベース、メールをダウンロードし、唯一のバックアップが失効予定のアカウントにないことを確かめます。Hostinger のサイト削除案内も事前のデータ保存を求め、関連メールを削除するかは選択肢として扱っています。古い手順のボタン位置や選択肢をそのまま使わず、現在の画面を一つずつ読んで操作してください。

操作後はサービス名、処理日、確認メッセージ、最終利用日を保存します。請求画面の「自動更新なし」は、当期の費用を支払い済みかどうかとは別です。支払済みの項目と別課金の追加サービスを確認します。サイトを使っていないだけで全請求が終わったと考えないでください。

後始末の文書には短い結果を載せます。新環境で主要機能が通ること、維持すべき旧項目と理由、停止済みのサービス、新バックアップ、運用担当者です。未完了の作業には次の手順と受け入れ条件を明記します。次のホスト変更、管理者交代、請求確認でも同じ記録から再開できます。

URL を維持してホストを移す手順

ドメイン変更時の検索とメールの引き継ぎ

新環境のバックアップ方法

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• WordPress