ドメイン変更後も旧URLが出る？AI検索に備えるホームページ移転の確認手順

移転後に旧URLが残るのは異常とは限らない

ドメイン変更の直後に旧URLが検索結果へ出ていても、それだけで移転失敗とは判断できません。Googleの「サイトを移転する方法」では、Googlebotが新旧サイトのURLをクロールし、移転をURL単位で処理すると説明しています。小規模から中規模のサイトでも、大半のページの移転が反映されるまで数週間かかる場合があり、その間は掲載順位が変動することも示されています。

また、Google Search Consoleのアドレス変更ツールの公式ヘルプでは、ツールを使っても旧サイトが自動的にインデックスから削除されるわけではなく、新サイトに対応ページがない旧URLは検索結果に残る場合があると説明しています。

これらを踏まえ、本記事では「旧URLをすぐ消す」ことより、「旧URLを開いた人やクローラーが、内容の対応する新URLへ迷わず到達できる状態」を先に作ることを推奨します。AI検索についても、まず公式サイト側で新旧情報の関係を明確にするための手順であり、各AIサービスの更新を直接操作する方法ではありません。

最初に旧URLと新URLの対応表を作る

Googleのサイト移転資料では、旧URLの一覧を用意し、それぞれをどの新URLへ移すか決める「URLマッピング」が重要な作業として示されています。小規模事業者の場合も、トップページだけでなく、サービス、料金、店舗、会社情報、問い合わせ、記事、PDF、画像など、外部から参照される可能性があるURLを対象にします。

実務上は、次のような表を作り、公開担当者と制作担当者が同じ対応関係を確認できるようにすると整理しやすくなります。

確認項目	記録する内容	判断のポイント
旧URL	現在公開されている正確なURL	www、http・https、末尾の違いも確認する
新URL	内容が対応する移転先URL	同じ目的のページへ結び付ける
扱い	移転、統合、終了のいずれか	後継ページがないURLを無理に転送しない
重要度	問い合わせ、閲覧、外部リンクなど	重要URLから先にテストする
確認結果	転送先、応答、表示内容	担当者と確認日を残す

Googleの公式資料は、多数の旧URLを関連性の低い新サイトのトップページへ一括転送すると、利用者を混乱させ、soft 404と判断される場合があると注意しています。対応するページがある場合はそのページへ、複数ページを実際に統合した場合は統合後のページへ結び付けます。後継コンテンツがない場合は、制作担当者と相談し、404または410を返す選択も含めて整理します。

対応する新URLへ恒久リダイレクトする

Googleのリダイレクトに関する公式資料では、URLを恒久的に変更する場合、可能な限りサーバー側の恒久リダイレクトを使うことを推奨しています。HTTPステータスコードの301と308は恒久移転、302・303・307は一時的な移転として扱われます。

したがって、ドメイン変更で元に戻す予定がないページは、旧URLから対応する新URLへ301または308で直接転送するのが基本です。旧URLから中間URL、さらに新URLへ移す転送の連鎖は、遅延や管理漏れの原因になるため、可能なら最終URLへ直接つなぎます。

Googleのサイト移転資料では、リダイレクトをできるだけ長く、一般的には1年以上維持するよう案内しています。実務上は、旧ドメインの契約、SSL証明書、DNS、ホスティングの維持費も移転計画に含めることを本記事では推奨します。ただし、設定方法は利用中のWordPressプラン、サーバー、CDNなどで異なるため、未確認のコードをそのまま本番へ貼り付けないでください。

canonical・内部リンク・サイトマップを新URLへ揃える

リダイレクトだけでなく、新サイト自身が参照するURLも確認します。Googleのサイト移転資料では、新しい各ページに新URLを指す自己参照のrel="canonical"を設定し、内部リンクを旧URLから新URLへ更新し、新URLを含むサイトマップを用意する手順が案内されています。

Googleのcanonicalに関する公式資料では、リダイレクトとrel="canonical"は正規URLを示す強いシグナルで、サイトマップはそれより弱いシグナルと説明されています。複数の方法を使う場合も、別々のURLを正規版として指定せず、すべて同じ新URLを示す必要があります。

• 新ページのcanonicalが旧ドメインを指していないか
• メニュー、本文、パンくず、画像、PDFのリンクに旧URLが残っていないか
• XMLサイトマップに新URLだけが掲載されているか
• 開発中に設定したnoindexやクロール制限が残っていないか
• フォーム送信後や予約完了後の移動先が新ドメインか

Googleのサイトマップ公式資料では、サイトマップは重要なページや更新情報を検索エンジンへ伝え、効率的なクロールを助けるものとされています。一方、サイトマップに含めても、すべてのURLのクロールやインデックス登録が保証されるわけではありません。

アドレス変更ツールを使う範囲を間違えない

Google Search Consoleのアドレス変更ツールは、あるドメインまたはサブドメインから別のドメインまたはサブドメインへサイトを移すときに使う機能です。公式ヘルプでは、移転とリダイレクトを実施した後に使用し、新旧両方のプロパティを同じGoogleアカウントで所有していることが要件として示されています。

同じ公式ヘルプによると、次の変更ではアドレス変更ツールを使いません。

• 同一ドメイン内でページのパスだけを変更する
• wwwあり・なしを同じドメイン内で切り替える
• httpからhttpsへ変更する
• URLを変えずにホスティング事業者やCDNだけを変更する

実務上は、アドレス変更ツールを「転送設定の代わり」と考えず、URLマッピング、リダイレクト、canonical、サイトマップを確認した後のGoogle検索向け通知として扱うと整理しやすくなります。これはGoogle検索の機能であり、他社のAI検索へ同時に移転を通知する機能ではありません。

公開前後の確認順序を決める

Googleのサイト移転資料では、ドメイン変更とCMS変更、レイアウト変更などを同時に行わず、変更を一つずつ進めるよう案内しています。小規模な運営体制では、原因の切り分けが難しくならないよう、移転日と作業順を1枚のチェック表にまとめることを本記事では推奨します。

公開前

1. 旧URL一覧と新URLの対応表を確定する
2. 新サイトの主要ページ、フォーム、予約、計測をテストする
3. 新旧両ドメインのSearch Console所有権を確認する
4. リダイレクト、canonical、robots.txt、noindex、サイトマップの担当を決める
5. 旧ドメインと旧サーバーを維持できる期間を確認する

公開時

1. 新サイトを公開し、開発用のnoindexやアクセス制限を外す
2. 旧URLから対応する新URLへの恒久リダイレクトを有効にする
3. 重要URLをPCとスマートフォンで開き、表示と転送を確認する
4. 内部リンク、canonical、サイトマップが新URLで統一されているか確認する
5. 該当するドメイン移転であればアドレス変更ツールを実行する

公開後

1. 新しいサイトマップをSearch Consoleへ送信する
2. 重要な旧URLと新URLをURL検査やブラウザーで確認する
3. 404、転送ループ、別ページへの誤転送を記録して修正する
4. アクセス解析と問い合わせ・予約の動作を確認する

移転後に監視する項目

移転作業は公開日で終わりではありません。実務上は、問い合わせにつながるページや外部リンクの多いページから優先して、新旧URLの状態を定期的に確認すると整理しやすくなります。

• 旧URLが1回の転送で正しい新URLへ到達するか
• 新URLが正常に表示され、意図しないnoindexがないか
• Search Consoleでクロール、インデックス、検索流入の変化が確認できるか
• アクセス解析で404や旧ドメインへの流入が続いていないか
• Google ビジネス プロフィール、SNS、広告、メール署名、業界団体などの公式リンクを更新したか
• 問い合わせ、予約、資料請求、決済など事業上重要な導線が動くか

本記事では、公開直後は重要ページを短い間隔で、その後は移転状況が落ち着くまで月次で確認する運用を推奨します。これは反映時期や効果を保証する頻度ではありません。ページ数、更新量、サーバー環境に合わせて調整してください。旧URLを示すAI回答を見つけた場合も、まず回答の出典、新旧URLの転送、公式プロフィールのリンクを記録し、どの情報源が残っているかを切り分けます。