検索順位を大きく落とさずにドメインを移行する方法

ドメイン変更は、技術的には小さなミスでも、非常に短時間で目に見える影響が出やすいSEOプロジェクトのひとつです。リダイレクトの欠落、クロール経路のブロック、canonicalの設定漏れだけで、単純なリブランディングが数週間にわたる順位変動につながることがあります。

多少の変動は通常起こります。検索エンジンは、古いURLをクロールし、リダイレクトを発見し、シグナルを処理し、新しいドメインをインデックス内に落ち着かせる時間を必要とします。目的は、あらゆる下落を避けることではありません。目的は、移行を退屈なものにすることです。つまり、1つの古いURLが1つの対応する新しいURLを指し、サーバーが明確に応答し、重要なものが何も消えない状態にすることです。

リダイレクトルールではなく、棚卸しから始める

移行で最もよくある失敗は、それをサーバー設定の作業として扱うことです。実際にはそうではありません。これは最終的にサーバー設定へ至る、情報アーキテクチャの作業です。

DNSに触れる前に、重要なURLの一覧を作成します。

• オーガニックトラフィックを受けているURL
• 外部バックリンクがあるURL
• コンバージョン、リード獲得、キャンペーン支援に関わるURL
• 現在のXMLサイトマップに含まれるcanonical URL
• 外部からリンクされているPDF、画像、ダウンロード可能ファイル
• 現在のナビゲーションには表示されない可能性がある高価値のレガシーURL

古いURLごとに、新しいドメイン上の移行先を割り当てます。多くの場合、その移行先は同じ意図を持つ同じページであるべきです。/pricingがhttps://newdomain.com/pricingになるなら単純です。3つの古い製品ページを1つの新しいガイドに統合するなら、その判断を意図的に記録してください。

怠惰なパターン、つまりすべてを新しいホームページへリダイレクトすることは避けましょう。便利ではありますが、関連性を捨てることになります。検索エンジンもユーザーも、移行先が元のURLと同じニーズに答えることを期待しています。

可能な限りURL構造を維持する

ドメイン移行は、パスが安定しているほど容易になります。oldsite.com/blog/exampleからnewsite.com/blog/exampleへ移るほうが、ドメイン、CMS、スラッグ、フォルダ構造、コンテンツを同時に変更するよりもはるかにクリーンです。

再設計やCMS移行によってURL変更が避けられない場合もあります。その場合は、判断を切り分けてください。

1. ドメイン変更が原因で変わるものは何か？
2. サイト構造の変更が原因で変わるものは何か？
3. 削除、統合、または書き換えられるものは何か？

変数を増やすほど、後から問題を診断するのが難しくなります。移行が重要で、現在のサイトが好調に機能しているなら、まずドメインを移し、再設計は後にすることを検討してください。

永続的なワンホップリダイレクトを使う

本格的なドメイン移行では、古いURLから対応する新しいURLへ、サーバーサイドの301または308リダイレクトを使用します。一時的なリダイレクトは一時的な状況のためのものです。JavaScriptリダイレクト、meta refresh、ソフトリダイレクトはシグナルとして弱く、壊れやすくなります。

リダイレクトの目標は単純です。

• 重要な古いURLはすべて永続リダイレクトを返す。
• 各リダイレクトは最終的な移行先へ直接向かう。
• HTTPからHTTPSへきれいにリダイレクトされる。
• wwwありとwwwなしのバリアントが一貫して処理される。
• 必要な場合を除き、壊れやすいクエリ文字列の挙動に依存しない。

悪いチェーンは次のようなものです。

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

最終的には正しいページに到達するかもしれませんが、遅く、クロールしにくく、ミスを見えにくくします。すべての古いバリアントから最終的な新しいURLまで、ワンホップを目指してください。

挙動を検証するときは、ブラウザに表示される内容を信じるのではなく、実際のHTTPレスポンスを確認してください。ここでは、本番環境でリダイレクトとHTTPヘッダーをデバッグするための小さなツールキットが役立ちます。ブラウザは丁寧すぎるため、チェーンをたどって厄介な部分を隠してしまうからです。

公開前にDNSと証明書を準備する

DNSが順位を直接引き継ぐわけではありませんが、DNSの不備は移行が壊れているように見せることがあります。公開時間帯の前にTTL値を下げ、変更がより予測しやすく伝播するようにします。新しいドメインに、Webトラフィック、メール、必要なサブドメイン向けの正しいレコードがあることを確認してください。

また、両方のドメインに有効なTLS証明書が必要です。これは見落とされがちです。移行後も、古いドメインはHTTPSリダイレクトを提供する必要があります。その証明書が期限切れになると、ユーザーやクローラーは新しいサイトに到達する前にブラウザの警告にぶつかる可能性があります。

移行がメールに影響する場合、それを後回しにしてはいけません。ドメイン変更は、SPF、DKIM、DMARC、MXレコード、トラッキングリンク、トランザクションメールを壊すことがよくあります。重要なレコードを復習するには、開発者向けのMX、SPF、DKIM、DMARCガイドをご覧ください。

canonical、内部リンク、サイトマップを確認する

公開後、新しいドメインは、あたかも以前からそのコンテンツのcanonicalな本拠地であったかのように振る舞うべきです。

つまり、次の状態です。

• canonicalタグが古いドメインではなく、新しいURLを指している。
• 内部リンクが新しいドメインまたはルート相対パスを使用している。
• XMLサイトマップには、最終的でインデックス可能な新しいURLだけが含まれている。
• hreflangアノテーションを使用している場合は、新しいURLを参照している。
• Open Graph、構造化データ、alternateリンクが更新されている。
• Robots.txtが重要なセクションをブロックしていない。

古いURLだらけのサイトマップを公開し、リダイレクトが片付けてくれると期待してはいけません。サイトマップは、インデックスしてほしいURLの一覧であるべきです。移行後は、それは新しいドメイン上の最終URLを意味します。

canonicalの矛盾にも注意してください。古いURLから新しいURLへリダイレクトされる一方で、canonicalが古いドメインを指しているページは、混在したシグナルを送ります。検索エンジンは多少の不整合なら通常処理できますが、こちらからそれを求めるべきではありません。

公開日にすべてを変えない

移行はそれだけで十分大きなイベントです。可能であれば、大規模なコンテンツ整理、テンプレートの書き換え、ナビゲーション変更、JavaScriptレンダリングの変更、新しいパフォーマンス特性との同時実施は避けてください。

これは迷信ではありません。デバッグの規律です。公開後に順位が下がった場合、その原因がリダイレクトマッピング、クロールアクセス、変更されたコンテンツ、レンダリングの遅さ、構造化データの欠落、その他の何かのどれなのかを知る必要があります。

初回公開は、実用上可能な限り旧サイトに近い状態に保ちます。新しいドメインが安定してから、より大きな編集やデザインの変更を小さな単位で行ってください。

何が変わったかを検索エンジンに伝える

Google Search Consoleで、古いドメインと新しいドメインの両方を確認します。そのうえで、移行がドメインレベルの変更であり、コンテンツが新しいドメインへ移る場合は、Change of Addressツールを使用します。公開後に新しいサイトマップを送信してください。

これはリダイレクトの代わりにはなりません。リダイレクトを補助するものです。検索エンジンがURL単位の対応関係を理解するには、依然としてクロール可能で永続的なリダイレクトが必要です。

Bingやその他の検索エンジンについては、利用可能な場合はそれぞれのwebmaster toolsを使用してください。また、自分で管理できる場所も更新します。ソーシャルプロフィール、ビジネスリスティング、広告のリンク先、メール署名、ドキュメント、パートナーリンク、シンジケートコンテンツ内のcanonical参照などです。

外部リンクがすべて更新されることはありませんし、それで問題ありません。ただし、最も重要なものは更新されるべきです。主要なパートナー、アプリマーケットプレイス、ドキュメントポータル、プレスページが古いドメインへリンクしている場合は、更新を依頼してください。

公開後は適切なものを監視する

移行後の最初の数日は、祝うのではなく能動的に監視する期間です。

確認するものは次のとおりです。

• 古いドメインと新しいドメインにおけるクロール活動のサーバーログ
• 404と予期しない5xxエラー
• リダイレクトチェーンとループ
• Search Consoleでのインデックス登録状況
• サイトマップの検出と処理
• オーガニックのランディングページとクエリパターン
• 古いURLに依存するコンバージョン経路
• アナリティクスのフィルターと参照元除外

レポートにはノイズが出るものと考えてください。一部のアナリティクスツールは、適切に設定されていない限り、新しいドメインを新しいプロパティとして扱います。一部のダッシュボードは旧ドメインのトラフィックと新ドメインのトラフィックを比較し、移行を実際より悪く見せることがあります。

検索での可視性は数週間変動する可能性があります。避けたいのは、高価値の古いURLが繰り返しクロールされているのに正しくリダイレクトされていない、または新しいページが発見されているのに古いドメインの重複として扱われる、というパターンです。

パフォーマンスも無視すべきではありません。新しいドメインが重いテンプレート、壊れたキャッシュ、最適化されていないアセットとともに公開されると、ユーザーは移行を遅さとして感じるかもしれません。チェックの一部としてLighthouseを使っているなら、優先順位を意識して読みましょう。意味のある問題とノイズを分ける方法は、慌てずにLighthouseレポートを読む方法で説明しています。

古いドメインを長期間維持する

移行が「うまくいった」からといって、古いドメインを失効させてはいけません。できるだけ長く、登録を維持し、証明書を有効に保ち、リダイレクトを稼働させ続けてください。実務上、それは多くの場合、数年を意味します。

古いリンクは、ブログ記事、ブックマーク、ドキュメント、PDF、メール、ソーシャル投稿の中に残り続けます。リダイレクトは、その歴史的な足跡と新しいドメインをつなぐ橋です。早すぎる停止は、ユーザーの経路を壊し、蓄積されたシグナルを無駄にします。

リダイレクトマップと公開時のメモのコピーも保管しておきましょう。6か月後、誰かがレガシーURLの挙動について尋ねてきたとき、記録しておいてよかったと思うはずです。

<!-- tool-cta:start -->

💡 これを試してください: 切り替え後、古いURLを Redirect Checker でトレースし、それぞれが正しい新しいページに単一の301ホップで解決されることを確認してください。

<!-- tool-cta:end -->

現実的な移行チェックリスト

公開前:

• Search Consoleで両方のドメインを確認する。
• 現在のサイトをクロールし、重要なURLをエクスポートする。
• 1対1のリダイレクトマップを作成する。
• DNSのTTLを下げる。
• 古いドメインと新しいドメインのTLS証明書を準備する。
• canonical、内部リンク、hreflang、構造化データ、サイトマップを更新する。
• ステージングまたは管理された環境でリダイレクトをテストする。

公開当日:

• リダイレクトをデプロイする。
• HTTPからHTTPSへの挙動を確認する。
• すべてのテンプレートタイプから重要なURLサンプルをテストする。
• 新しいサイトマップを送信する。
• 適切な場合はChange of Addressツールを使用する。
• サーバーエラー、リダイレクトループ、ブロックされたリソースを監視する。

公開後:

• クロールエラーとインデックス登録レポートを監視する。
• 可能な範囲で重要な外部リンクを更新する。
• ドメイン合計だけでなく、ランディングページの意図別にトラフィックを比較する。
• リダイレクトを無期限に稼働させる。
• 無関係な再設計やコンテンツ実験は、移行が安定するまで延期する。

ドメイン移行にリスクがないわけではありませんが、管理は可能です。順位が損なわれるのは、多くの場合、移行が不明確なシグナルを送っているときです。リダイレクトの欠落、変更されたコンテンツ、矛盾するcanonical、ブロックされたクローラー、忘れられた古いドメインなどが原因です。検索エンジンとユーザーに明確な地図を渡せば、移行ははるかに穏やかなものになります。