LinkedIn アカウントを開設しました: Google 検索でサイトを見つけやすくするためのニュースやリソースについては、LinkedIn アカウントをフォローしてください。

サイトを移転する方法

このドキュメントでは、Google 検索結果への悪影響を最小限に抑えながら、サイトの既存のページの URL を変更する方法について説明します。このサイト移転の例としては次のようなものがあります。

HTTP から HTTPS への URL の変更
ドメイン名の変更（例: example.com から example.net）、または複数のドメインやホスト名の統合
URL パスの変更: example.com/page.php?id=1 から example.com/widget、または example.com/page.html から example.com/page.htm

概要

サイトの移転に関する一般的なベストプラクティス。手順の概要とユーザーや掲載順位に与える影響について確認しておきます。HTTP から HTTPS へ移転する場合は、HTTPS に関するおすすめの方法を確認してください。
新しいサイトを準備して、十分にテストします。
現在の URL から対応する新しい形式への URL マッピングを準備します。
元の URL から新しい URL にリダイレクトするようサーバーを設定して、サイトの移転を開始します。
元の URL と新しい URL 両方のトラフィックを観察します。

サイトの移転に関する一般的なベストプラクティス

数回に分けて段階的に移転作業を行う（サイトに適している場合）。
サイトの規模が大きく技術的に可能な場合は、最初にサイトの一部を移転してトラフィックと検索のインデックス登録への影響をテストすることをおすすめします。その後で、サイトの残りの部分を一度に、またはいくつかに分けて移転します。サイトの中で最初にテストする部分を選ぶ際は、あまり頻繁に変更されない部分、よく起きる状況や予測できない出来事によって大きな影響を受けない部分を選択します。また、一部分だけ移転するのはよいテスト方法ですが、検索に関しては、必ずしもサイト全体を移転する場合のサンプルにはならないこともあります。移転するページが多いほど、解決すべき問題がさらに発生する可能性が高くなります。慎重にプランニングすることで問題を最小限に抑えてください。
一度に行う変更を 1 つのみにする
サイトに対する変更を 1 つずつ順に行い、すべてを同時に変更しないように変更内容を計画します。たとえば、サイトを新しいドメイン名に移転する必要がある場合は、コンテンツマネジメントシステム（CMS）を変更して新しいレイアウトを使用するようにサイトを更新します。それらの処理を一度に 1 つずつ行い、新しいドメインに移転してサイトのレイアウトを変更します。
移転作業はトラフィックの少ない時間帯に行う（可能である場合）。
トラフィックが周期的に変動する場合、または特定の曜日に少なくなる場合は、トラフィックが多くないときにタイミングを合わせて移転するのが得策です。そうすれば、サイトの移転中に問題が発生したとしても、影響を受けるユーザーを最小限にとどめることができるだけでなく、サイトをクロールする Googlebot のためにより多くのサーバーリソースを割くことができます。
移転中、サイトのランキングが一時的に変動することを想定する。
サイトの大幅な変更があった場合は、Google がサイトを再クロールしてインデックスに登録し直す間にランキングが変動することがあります。原則として、中規模のサイトでほとんどのページの移転がインデックスに反映されるのに数週間かかり、より大規模なサイトであればそれより長くかかります。Googlebot と Google のシステムが移転した URL を検出して処理する速度は主に URL の数とサーバーの速度によって異なります。サイトマップを送信すると検出プロセスの時間を短縮できます。サイトはセクション単位でも移転できます。
リンククレジットについては要件を設けない。
301 や 302 などのサーバーサイドのリダイレクトによって PageRank の損失が生じることはありません。
Search Console を使用する。
Search Console は優れたツールであり、特にサイトを移転する際に活用できます。Search Console で各プロパティのデータを個別に確認します。インデックスステータスレポートで概要を確認します。サイトマップレポートを使用して、サイトマップで送信された URL のうち、インデックス登録された URL の数を確認します。
これには時間を要します
サイトの移転が完了したことを認識するため、Googlebot は少なくとも 1 回、新旧両サイトのすべての URL にアクセスする必要があります。クロールの頻度は一定ではありません。Googlebot のクロール頻度はサイトのサイズと可能なクロール速度によって異なります。移転は URL ごとに行われます。

新しいサイトを準備する

準備作業の詳細は、サイト移転のケースによってそれぞれ異なりますが、一般に次のいずれか 1 つまたは複数の作業を行うことになります。

CMS を設定（おそらく使用中の旧サイトと同じ設定を行うことになります）し、旧サイトからコンテンツをインポートします。
現在ホストしている画像やダウンロードファイル（PDF ドキュメントなど）を移行します。
Google 検索やリンクからこれらのコンテンツにアクセスしているトラフィックがすでに存在する可能性があるため、ユーザーと Googlebot に新しい場所を伝えておくと効果的です。
HTTPS に移行する場合は、必要な TLS 証明書を入手してサーバーに構成します。
新しいサイトに robots.txt を設定し、新しいサイトの robots.txt ファイルのルールがクローリング対象から除外する必要がある部分を正しく反映するようにします。

場合によって、サイトの開発中はすべてのクロールをブロックすることもあります。その場合は、サイト移転開始後の robots.txt ファイルの内容をあらかじめ準備しておきます。同様に、開発中に noindex ルールを使用する場合は、URL リストを作成しておき、サイト移転の開始時にそのリストから noindex ルールを削除します。
従来のコンテンツのすべてを新規のサイトに移転するわけではない場合は、削除または結合されたコンテンツについてエラーを表示して、移転先のサイトでそれらの URL が HTTP 404 または 410 のエラーレスポンスコードを返すようにします。
サイトの移転を支援可能な正しい Search Console 設定を行うようにします。

まだ行っていない場合は、Search Console で新旧の両サイトを確認します。元のサイトと新しいサイトの両方の類似パターンすべてについて確認を行うようにしてください。たとえば、HTTPS URL を使用している場合は、www.example.com と example.com を確認して、HTTPS サイトと HTTP サイト両方の類似パターンが含まれているようにします。この確認を元のサイトと新しいサイト両方について行ってください。
- Search Console の確認機能を確認する
  
  Search Console の所有権確認機能がサイト移転後も引き続き動作するようにします。別の確認方法を使用している場合は、URL が変わると確認トークンも変わる場合があることにご注意ください。
  
  Search Console でサイトの所有権の確認に HTML ファイルによる証明を使用している場合は、サイトの新しいコピーに現在の確認ファイルを含めることを忘れないようにご注意ください。
  
  同様に、サイトの所有権の確認に meta タグまたは Google アナリティクスを参照するインクルードファイルを使用している場合は、新しい CMS コピーに同じものを組み込むようにします。
- 従来のサイトに対して行っている場合は Search Console の構成設定を確認して、これらの変更も反映するように移転先のサイトの設定も更新します。次に例を示します。
  - クロール頻度: 新旧両サイトのクロール頻度を「Googlebot に決定を委ねる」に設定します。
  - 否認済みのバックリンク: 元のサイトでバックリンクを否認するためのファイルをアップロードしていた場合は、新しいサイトの Search Console アカウントを使用して再度アップロードすることをおすすめします。
- 最近購入したドメインをクリーンアップする: 前の所有者により未解決の問題が残されていないかを確認することをおすすめします。次の設定を確認します:
  - 以前のスパムに対する手動による対策。新しいサイトに適用される手動による対策を実施する場合は、一覧に示されている問題を解決して再審査リクエストを送信してください。
  - 削除された URL。前の所有者による URL の削除（特にサイト全体を対象とした URL の削除）が残っていないことを確認してください。
ウェブ解析を使用して元のサイトと新しいサイトの両方の使用状況を解析します。ウェブ解析ソフトウェアがこの目的に役立ちます。通常、ウェブ解析の構成は、ページに JavaScript を埋め込んで行います。さまざまなサイトのトラッキングの詳細は、使用する解析ソフトウェアや、そのソフトウェアのロギング、処理、フィルタリングの設定によって異なります。ご不明な点については、ご利用の解析ソフトウェアのプロバイダにお問い合わせください。また、解析ソフトウェアの構成の変更を予定している場合は、今が良いチャンスです。Google アナリティクスを使用しており、コンテンツレポートで明確に分割する場合は、新しいサイト用に新しいプロファイルを作成することを検討します。
サーバーに十分なコンピューティングリソースを確保する: 移転後、Google は一時的に通常より高い頻度で移転先のサイトをクロールします。これは、元のサイトから新しいサイトにトラフィックがリダイレクトされ、元のサイトのクロールが新しいサイトにリダイレクトされるうえ、他のクロールも行われるためです。Google からのトラフィックの増加に対処できるよう、新しいサイトに十分な処理能力があることを確認してください。サイトのサイズが特に大きい場合は、ホスティングプロバイダに連絡して、計画しているサイトの移転に関する情報を伝えます。

URL マッピングを準備する

元のサイトの URL から新しいサイトの URL へのマッピングは重要な項目です。このセクションでは、2 つのサイトの URL を適切に特定してマッピングをスムーズに行うための一般的なアプローチをいくつかご紹介します。このマッピングの具体的な生成方法の詳細は、現在のウェブサイトのインフラストラクチャとサイトの移転の詳細によって異なります。

元の URL を特定する

単純なサイト移転では、元の URL のリストを生成する必要がない場合もあります。たとえば、サイトのドメインを変更する場合は（例: example.com から example.net へ）、ワイルドカードによるサーバーサイドのリダイレクトを使用できます。

より複雑なサイト移転では、元の URL のリストを作成して、各 URL を新しい移転先にマッピングする作業が必要になります。元の URL のリストを取得する方法は現行のウェブサイトの構成により異なりますが、便利な方法をいくつか紹介します。

重要な URL から始める。重要な URL を特定する方法は次のとおりです。
- サイトマップを調べます。これは、最も重要な URL は、その方法で Search Console に送信されている可能性があるためです。
- サーバーログまたは解析ソフトウェアで、特にトラフィックの多い URL を調べます。
- Search Console のサイトへのリンク機能で、内部リンクと外部リンクのあるページを確認します。
コンテンツマネジメントシステムを使用する。通常、コンテンツマネジメントシステムではコンテンツをホストするすべての URL のリストを簡単に取得できます。
サーバーログを確認する。最近 1 回以上アクセスのあった URL を調べます。サイトに適している期間を選びます。周期的なトラフィックの変動を考慮してください。
画像や動画を含める。埋め込みコンテンツ（動画、画像、JavaScript、CSS ファイル）の URL がサイトの移転計画に含まれていることを確認してください。これらの URL も、ウェブサイトの他のすべてのコンテンツと同じように移行する必要があります。

元の URL から新しい URL へのマッピングを作成する

元の URL のリストを用意したら、各 URL をどの URL にリダイレクトするかを決めます。このマッピングを保存する方法は、ご利用のサーバーや移転するサイトによって異なります。一般的なリダイレクトパターンについては、データベースを使用する方法や、システムでいくつかの URL 書き換えルールを構成する方法があります。

新しいサイトですべての URL の詳細情報を更新する

URL マッピングを定義したら、通常はページでトラフィックを受信するための準備として、次の 3 つのことを行います。

各ページの HTML またはサイトマップエントリ内の新しい URL を参照するようにアノテーションを更新する。
1. 移転先の各 URL に、自身を参照する rel="canonical" <link> タグが必要です。
2. 移転したサイトに、rel-alternate-hreflangアノテーションを使用した多言語または多国籍のページがある場合は、新しい URL を使用するようにアノテーションを更新します。
内部リンクを更新する。
新しいサイトの内部リンクを、元の URL から新しい URL に変更します。必要に応じて、先ほど生成したマッピングをリンクの検出と更新に利用できます。
最終的な移転に向けて以下のリストを保存する。
- マッピング内の新しい URL を含むサイトマップファイル。サイトマップの作成に関するドキュメントをご覧ください。
- 元の URL にリンクしているサイトのリスト。サイトへのリンクは Search Console で確認できます。

リダイレクトに関する戦略を策定する

マッピングと新しいサイトの準備ができたら、次はリダイレクトに関する戦略について計画します。マッピングで示したように、元の URL から新しい URL へのサーバーサイドの永続的なリダイレクトをおすすめします。技術的に可能なサーバーサイドのリダイレクトの種類について、サーバー管理者（またはホスティング会社）に確認します。サーバーが Apache HTTP サーバーまたは CMS のリダイレクト機能を使用している場合は、.htaccess ファイル内のリダイレクトルールである可能性があります。

サーバーサイドのリダイレクト設定が不可能な場合は、最終的な解決策としてクライアントサイドのリダイレクトを設定できます。

サイトの移転方法を決定します - すべてを一度に移転する方法と、区分ごとに移転する方法があります。

小規模または中規模のサイト: 区分ごとに移転するのではなく、一度にサイトのすべての URL を移転することをおすすめします。一度に移転することで、ユーザーが新しい形式のサイトを使いやすくなるとともに、Google のアルゴリズムによるサイト移転の検出とインデックス登録の更新がより速くなります。
大規模なサイト: 大規模なサイトでは分割して区分ごとに移転する方法もおすすめです。区分ごとに移転すると、監視や検出が簡単になり、問題を迅速に修正できるようになります。

次の点にご注意ください。

技術的に可能な場合はサーバーサイドの永続的なリダイレクトを使用してください。Googlebot は複数の種類のリダイレクトに対応していますが、可能であれば永続的な HTTP リダイレクト（例: 301、308）を使用することをおすすめします。
リダイレクトのチェーンを避ける。Googlebot は複数のリダイレクトの「チェーン」（例: ページ 1 > ページ 2 > ページ 3）に含まれる最大 10 個のホップをたどることができますが、最終的な宛先に直接リダイレクトすることをおすすめします。直接リダイレクトできない場合は、チェーン内のリダイレクトの数を 5 個未満（理想的には 3 個以下）に抑えてください。リダイレクトのチェーンを使用すると、ユーザーにとってはレイテンシが増大します。また、一部のユーザーエージェントとブラウザは長いリダイレクトチェーンに対応していません。

サイト移転を開始する

URL マッピングが適切な状態になり、リダイレクト方法に関する計画が確定すれば、移転準備完了です。

リダイレクトを実装するまたは有効にする: 決定したリダイレクト戦略に応じて、更新情報をサーバーの構成ファイルにプッシュする、またはカスタムコードを使用して CMS を更新するなどの対応を行います。
関連性の低いリダイレクトは行わない
多数の元の URL から、関連性の低い 1 つの URL（新しいサイトのホームページなど）にリダイレクトすることは避けてください。このようなリダイレクトはユーザーに混乱をきたし、soft 404 エラーとみなされる場合もあります。ただし、以前は複数のページでホストしていたコンテンツを新しい 1 つのページに統合した場合は、元の複数の URL を新しい統合後のページにリダイレクトしても問題ありません。
rel="canonical" link アノテーションと robots meta ルールを確認します。リダイレクトがアクティブになったら、新しいサイトの rel="canonical" link アノテーションが新しい URL を使用していることを確認します。同様に、新しい URL のインデックスが先立って登録されてしまわないよう noindex robots meta ルールを新しいサイトに追加していた場合は、それらのルールを更新します。
リダイレクトをテストする: 個々の URL をテストするには URL 検査ツールを使用し、多数の URL をテストするにはコマンドラインツールまたはスクリプトを使用します。
Search Console で、元のサイトのアドレス変更の通知を送信します。
サイトを HTTP から HTTPS に移行する場合、アドレス変更ツールを使用する必要はありません。
リダイレクトをできるだけ長く保持します（一般的には 1 年以上）。この期間、Google は古い URL を指している他のサイト上のリンクの再クロールや再割り当てなどを行い、すべてのシグナルを新しい URL に転送できます。

ユーザーの観点から、リダイレクトを無期限に保持することを検討してください。ただし、リダイレクトはユーザーにとっては低速であるため、サイト内のリンクと、他のサイトからのアクセス数が多いリンクをできるだけ更新して、新しい URL を参照するようにしてください。
Search Console で新しいサイトマップを送信します。これにより、Google は新しい URL を認識できます。今後 Google は新しいサイトマップを使用するため、この時点で元のサイトマップを削除できます。

Googlebot と Google のシステムがサイト移転の対象となったすべての URL を検出して処理するのにかかる時間は、お使いのサーバーの速度と対象 URL の数によって異なります。原則として、小規模から中規模のサイトで大半のページの移転が反映されるのには数週間かかり、より大規模なサイトであればそれより長くかかります。Googlebot と Google のシステムが移転された URL を検出して処理する速度は、URL の数とサーバーの速度によって異なります。

リンクを更新する

サイトの移転を開始したら直ちに、可能な限り多くのリンクを更新するように努めてください。リンクを更新すると、ユーザーエクスペリエンスが向上し、ご自身のサーバーの負荷が軽減されます。リンクには次のようなものがあります。

内部リンク: 先ほど作成した URL マッピングに基づいてご自身のページを指していた URL をすべて置き換えます。
外部リンク: 現在のコンテンツにリンクされているサイトを保存したリストにあるサイトに連絡して、リンク先を新しいサイトに更新するよう依頼します。その際、外部からのアクセス数が多いリンクを優先することを検討してください。
Facebook、Twitter、LinkedIn などからのプロフィールリンク。
新しいランディングページに誘導する広告キャンペーン。

トラフィックを監視する

サイトの移転が開始したら、新しいサイトと元のサイトでユーザーとクローラーのトラフィックがどのように変化するかを監視します。元のサイトのトラフィックが減少し、新しいサイトのトラフィックが増加していくのが理想的です。Search Console などのツールを使用すると、サイトでのユーザーとクローラーのアクティビティを確認できます。

Search Console を使用してトラフィックを監視する

Search Console には、サイト移転の監視に役立つ多くの機能があります。たとえば次のような機能があります。

サイトマップ: 先ほどマッピングから保存した 2 つのサイトマップを送信します。最初は、新しい URL を含むサイトマップはページが 1 つもインデックス登録されておらず、これに対して元の URL を含むサイトマップは多数のページがインデックス登録されている状態です。時間の経過とともに、元の URL のサイトマップからインデックス登録されているページの数がゼロになり、これに対応して新しい URL のインデックス登録が増えます。なお、Search Console は、元の URL を含むサイトマップについて URL のリダイレクトに関する警告を表示する場合があります。これは正常な状態であり、警告を無視して問題ありません。実際には新しい URL に移行中の状態です。
インデックスカバレッジレポート: サイトの移転を反映して、元のサイトでインデックスに登録された URL の数が減り、新しいサイトでのインデックス登録が増える様子がグラフに表示されます。予期しないクロールエラーがないかどうかを定期的に確認してください。
検索クエリ: 新しいサイトにインデックス登録され検索結果に表示されるページが増えるにつれて、検索クエリレポートで、新しいサイトの URL の検索表示回数やクリック数が表示されるようになります。

他のツールを使用してトラフィックを監視する

サーバーのアクセスログとエラーログに注意してください。特に Googlebot によるクロール、予期しない HTTP エラーステータスコードを返した URL、通常のユーザートラフィックを確認します。

サイトにウェブ解析ソフトウェアをインストールしている場合、またはご利用の CMS に解析機能がある場合は、元のサイトから新しいサイトへのトラフィックの移行を確認できるように、上記と同様の方法でトラフィックを確認することをおすすめします。特に、Google アナリティクスにはリアルタイムレポート作成機能が用意されており、これはサイト移転の初期段階に活用できる機能です。元のサイトのトラフィックが減少し、新しいサイトのトラフィックが増加することを確認できます。

その他のリソース

サイトの移転には多くの複雑な作業を必要とする場合があり、進め方についても多くの考え方があります。Aleyda Solis 氏のサイト移転に関するチェックリストは非常に役立ちます。サイト移転に関する Screaming Frog ツールガイドも同様に活用できると考えられます。

いずれかの段階で行き詰まった場合は、Google 検索セントラルのヘルプをご覧ください。
Google のヘルプページにはおすすめのアドバイスが、またユーザーフォーラムには回答済みの具体的なケースがたくさん集められています。回答が見つからない場合は、SEO のオフィスアワーで Google 検索スペシャリストに質問できます。

サイトの移転に関するトラブルシューティング

URL の変更（HTTP から HTTPS への変更を含む）を伴うサイトの移転でよく見られるミスを以下に示します。このようなミスがあると、新しいサイトがインデックスに完全に登録されないことがあります。

よくある誤り
`noindex` または robots.txt によるブロック	移転にのみ必要な `noindex` や robots.txt によるブロックは必ず削除してください。サイトに robots.txt ファイルがなくても問題ありませんが、robots.txt ファイルが存在しない場合は、適切な `404` HTTP ステータスコードを返すようにしてください。確認方法 HTTPS サイトで robots.txt ファイルを調べて、変更が必要かどうかを確認します。 URL 検査ツールを使用して、新しいサイトで Google によって検出されていないと思われるページを確認します。
不正確なリダイレクト	元のサイトから新しいサイトへのリダイレクトを確認します。新しいサイトで間違った（存在しない）URL にリダイレクトしていることがよくあります。 Search Console を使用すると、「Not found」のエラーが通常よりも多く報告されているかどうかを確認できます。または、Screaming Frog などのその他のツールを使用してリダイレクトが想定どおりに機能しているかどうかを確認することもできます。
その他のクロールエラー	インデックスカバレッジレポートで、移転イベント中に新しいサイトでその他のエラーが急増していないかどうかを確認します。
サーバーの処理能力の不足	移転後、Google は新しいサイトを通常よりも多くクロールします。これは、元のサイトから新しいサイトにトラフィックがリダイレクトされ、元のサイトのクロールが新しいサイトにリダイレクトされるうえ、他のクロールも行われるためです。Google からのトラフィックの増加に対処できるよう、サイトに十分な処理能力があることを確認してください。
サイトマップが更新されていない	サイトマップがすべて新しい URL で更新されていることを確認してください。