URL の変更を伴うサイト移転

この記事では、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

概要

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

URL の変更を伴うサイト移転に関するよくある質問

  • 全体を一度に移転するべきですか。それとも、段階的に移転する方がよいでしょうか?
    段階的に移転することをおすすめします。
  • インデックス登録されたページ数を調べるにはどうすればよいですか。
    Search Console で各プロパティのデータを個別に確認します。インデックス ステータス レポートで概要を把握し、サイトマップの URL については、サイトマップ レポートでインデックス登録されたサイトマップの数を確認します。
  • URL の変更が Google に認識されるまでどのぐらいかかりますか?
    クロールの頻度は一定ではありません。サイトのサイズやクロールの速度によって異なります。移転は URL ごとに行われます。
  • 新しい URL にリダイレクトすると、リンクのクレジットは失われますか?
    いいえ。301 や 302 のリダイレクトは PageRank の損失につながりません。

HTTP から HTTPS への移行

  • HTTPS に関するおすすめの方法を確認します
  • Search Console に HTTPS のプロパティを追加します。 Search Console では、HTTP と HTTPS を別々に扱うため、これらのプロパティのデータは Search Console で共有されません。そのため、両方のプロトコルのページを用意する場合は、Search Console でそれぞれのプロパティを指定する必要があります。
  • HTTP から HTTPS へのページの移行に関するその他のよくある質問は以下のとおりです。

    HTTP から HTTPS への移行に関するよくある質問

    この HTTPS の移行はランキングに影響を与えますか?

    移行する場合の常として、移行中にランキングの変動が起きる可能性があります。 ただし、HTTPS に固有の問題を避けるために、HTTPS ページを実装する場合のおすすめの方法を確認してください。

    HTTPS サイトになるとランキングが少し上昇しますが、顕著な変化は期待しないでください。Google は HTTPS をポジティブなランキング要素として使用します。これは数あるランキング要素の一つに過ぎず、現在のところ高品質のサイト コンテンツよりもウェイトが小さいため、HTTPS に移行しても短期的に見て SEO のメリットが大きく増えるとは期待できません。長期的には、HTTPS サイトであるということの影響が強まる可能性もあります。

    一部のページだけを HTTPS に移行してもかまわないでしょうか?

    はい、問題ありません。一部分だけ移行し、テストしてから、ご自分のペースで移行できます。

    HTTP から HTTPS に段階的に移行する場合、段階的な URL が早期にインデックス登録されないようにするには、リダイレクトではなく rel=canonical を使用することをおすすめします。リダイレクトを使用した場合、リダイレクトされるページをテストできなくなります。

    どの証明書が必要ですか?

    Google 検索では、最新のブラウザに対応している最新の証明書を使用できます。

    HTTPS サイトの検索キーワードを確認できますか?

    この点は HTTPS でも変わりません。Search Console で検索クエリを確認できます。

    robots.txt で HTTP のサイトマップを参照しています。robots.txt を更新して新しい HTTPS のサイトマップを含める必要はありますか?

    HTTP 用と HTTPS 用に別々の robots.txt ファイルを用意し、HTTP と HTTPS の別々のサイトマップ ファイルを指定することをおすすめします。また、個々の URL を一方のサイトマップ ファイルにのみ記載するようおすすめします。

    HTTPS のテスト中のセクションは、どのサイトマップでマッピングすればよいですか。

    サイトの更新したセクションについてのみ、別個のサイトマップを作成します。そうすることで、テスト中のセクションのインデックス登録をより正確に追跡できるようになります。URL は他のサイトマップで重複しないようにしてください。

    (HTTP から HTTPS、または HTTPS から HTTP への)リダイレクトがある場合、サイトマップにはどの URL を記載すればよいですか?

    ユーザーがページにアクセスするときのリダイレクトには関係なく、HTTP の URL はすべて HTTP のサイトマップに記載し、HTTPS の URL はすべて HTTPS のサイトマップに記載します。リダイレクトに関係なくサイトマップにページを記載しておくと、検索エンジンが新しい URL をより早く検出できるようになります。

    HTTPS 用の robots.txt に追加する必要のある項目は他にありますか?

    ありません。

    HSTS に対応するべきですか?

    HSTS はセキュリティを向上させますが、ロールバックの手法が複雑になります。詳しくは、HTTPS に関するおすすめの方法をご覧ください。

    サイト全体に対して 1 つの Google ニュース サイトマップを使用しています。サイトを段階的に移行する場合、どうすればよいですか?

    新しい HTTPS のセクションに Google ニュース サイトマップを使用する場合は、ニュースチームに連絡して、プロトコルの変更について知らせる必要があります。さらに、Search Console の HTTPS プロパティで、サイトの各セクションを HTTPS に移行するたびに、新しい Google ニュース サイトマップを送信します。

    HTTPS の移行に関して Google ニュース パブリッシャー センターでの推奨事項はありますか?

    Google ニュース パブリッシャー センターでは、HTTP から HTTPS への移行をユーザーに意識させないように処理しています。通常は、ニュース サイトマップを使用していない限り、Google ニュースについて何か行う必要はありません。ニュース サイトマップを使用している場合は、ニュースチームに連絡して、変更について知らせてください。セクションの変更についてニュースチームに知らせることもできます。たとえば HTTPS に移行する場合は、http://example.com/sectionhttps://example.com/section に移行することを指定できます。

新しいサイトを準備する

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

  • 新しいコンテンツ管理システム(CMS)をセットアップして、コンテンツを追加します。
  • 現在ホストしている画像やダウンロード ファイル(PDF ドキュメントなど)を移行します。
    Google 検索やリンクからこれらのコンテンツにアクセスしているトラフィックがすでに存在する可能性があるため、ユーザーと Googlebot に新しい場所を伝えておくと効果的です。
  • HTTPS に移行する場合は、必要な TLS 証明書を入手してサーバーに設定します。

新しいサイトの robots.txt を設定する

サイトの robots.txt ファイルは、Googlebot がクロールできる領域を制御します。新しいサイトの robots.txt ファイルのディレクティブで、クロールをブロックする部分が正確に反映されていることを確認してください。

場合によって、サイトの開発中はすべてのクロールをブロックすることもあります。その場合は、サイト移転開始後の robots.txt ファイルの内容をあらかじめ準備しておきます。同様に、開発中に noindex ディレクティブを使用する場合は、URL リストを作成しておき、サイト移転の開始時にそのリストから noindex ディレクティブを削除します。

削除または結合されたコンテンツについてエラーを表示する

新しいサイトに移行しない元のサイトのコンテンツについては、その孤立した URL から適切に HTTP 404 または 410 のエラー レスポンス コードが返されるようにします。新しいサイトの設定パネルで元の URL のエラー レスポンス コードを返すか、新しい URL へのリダイレクトを作成して、そこから HTTP エラーコードを返すことができます。

Search Console の設定が適切か確認する

サイトの移転が成功するかどうかは、Search Console の設定が適切かつ正確であるかどうかにかかっています。

まだ確認していない場合は、Search Console で元のサイトと新しいサイト両方の所有者であることを確認します。元のサイトと新しいサイトの両方の類似パターンすべてについて確認を行うようにしてください。たとえば、HTTPS URL を使用している場合は、www.example.comexample.com を確認して、HTTPS サイトと HTTP サイト両方の類似パターンが含まれているようにします。この確認を元のサイトと新しいサイト両方について行ってください。

Search Console の確認機能を確認する

Search Console の所有権確認機能がサイト移転後も引き続き動作するようにします。別の確認方法を使用している場合は、URL が変更すると確認トークンも変わる場合があることにご注意ください。

Search Console でサイトの所有権の確認に HTML ファイルによる証明を使用している場合は、サイトの新しいコピーに現在の確認ファイルを含めることを忘れないようにご注意ください。

同様に、サイトの所有権の確認にメタタグまたは Google アナリティクスを参照するインクルード ファイルを使用している場合は、新しい CMS コピーに同じものを組み込むようにします。

Search Console の設定を確認する

元のサイトで Search Console の設定の一部を変更していた場合は、これらの変更が新しいサイトの設定にも反映されていることを確認します。たとえば次のようにします。

  • URL パラメータ: URL パラメータを設定して元の URL のクロールやインデックス登録を制御していた場合は、必要に応じて新しいサイトにもその設定が適用されるようにします。
  • 地域ターゲティング: 元のサイトに明示的な地域ターゲット(例: 地域ターゲティング設定可能なドメイン)や、国コードのトップレベル ドメイン(例: .co.uk)が設定されている場合があります。同じ地域ターゲット設定を継続する場合は、新しいサイトにも同じ設定を適用します。ただし、サイトの移転が世界的な事業展開の一環であり、サイトを特定の国や地域に関連付けたくない場合は、[サイトの設定] ページのプルダウン リストで [指定なし] を選択します。
  • クロール頻度: 元の URL と新しい URL のいずれについても、Search Console で Googlebot のクロール頻度を制限しないことをおすすめします。また、クロール頻度の設定も行わないことをおすすめします。クロール頻度は、サイトが Googlebot のクロール量に対応できないことがわかっている場合にのみ設定してください。元のサイトですでに Googlebot のクロール頻度を制限していた場合は、制限の解除を検討しましょう。Google はさまざまなアルゴリズムを使用してサイトが移転されたことを自動検知すると、移転がインデックス登録に速やかに反映されるように Googlebot のクロール挙動を適宜変更します。
  • 否認済みのバックリンク: 元のサイトでバックリンクを否認するためのファイルをアップロードしていた場合は、新しいサイトの Search Console アカウントを使用して再度アップロードすることをおすすめします。

最近購入したドメインに問題がないかを確認する

新しいサイトに最近購入したドメインを使用する場合は、前の所有者からの未解決の問題が残っていないかを確認することをおすすめします。次の設定を確認します:

  • 以前のスパムに対する手動による対策。Google では、ウェブマスター向けガイドラインに準拠していないサイトに対して、手動による対策を積極的に講じて掲載順位を下げたり、検索結果から完全に削除したりしています。Search Console の [手動による対策] ページで、新しいサイトに手動による対策が適用されていないかどうかを確認し、問題が表示されている場合は、再審査リクエストを提出する前に問題に対処してください。
  • 削除された URL。前の所有者による URL の削除(特にサイト全体を対象とした URL の削除)が残っていないことを確認してください。この点についても、コンテンツの URL 削除リクエストを送信する前に、URL 削除ツールを使用すべきでない場合について確認してください。

ウェブ解析を使用する

サイトの移転中は、元のサイトと新しいサイトの両方の使用状況を解析することが重要です。ウェブ解析ソフトウェアがこの目的に役立ちます。通常、ウェブ解析の設定は、ページに JavaScript を埋め込んで行います。さまざまなサイトのトラッキングの詳細は、使用する解析ソフトウェアや、そのソフトウェアのロギング、処理、フィルタリングの設定によって異なります。不明な点はお使いの解析ソフトウェアのプロバイダにお問い合わせください。また、解析ソフトウェアの設定の変更を予定している場合は、今が良いチャンスです。Google アナリティクスを使用しており、コンテンツ レポートで明確に分割する場合は、新しいサイト用に新しいプロファイルを作成することを検討します。

新しいドメインでリソースを確実に配信する

移転後、Google は新しいサイトを通常よりも多くクロールします。これは、サイトが元のサイトから新しいサイトにトラフィックをリダイレクトし、元のサイトのクロールが新しいサイトにリダイレクトされるうえ、他のクロールも行われるためです。Google からのトラフィックの増加に対処できるよう、新しいサイトに十分なホスト負荷があることを確認してください。

データ ハイライターを更新する

データ ハイライターを使用して元のページのマッピングが行われている場合は、新しいサイトでマッピングをやり直してください。

HTTPS ページの準備が整ったらすぐに、Google 検索結果に表示されたときにアプリでウェブページを開くためのすべてのアプリリンクを更新します。これらのリンクを更新して、新しい HTTPS URL を指すようにします。これらのリンクではリダイレクトは動作しなくなります。モバイルのブラウザでのクリックは、アプリのリンク処理を更新しない限り、アプリではなくブラウザでページが開きます。

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

URL マッピングを準備する

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

1. 現行の URL を特定する

最も簡単なサイトの移転では、現在の URL のリストを生成する必要がない場合もあります。たとえば、サイトのホストのみを変更する(例: example.com から example.net へ)場合は、ワイルドカードによるサーバー側のリダイレクトを使用できます。

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

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

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

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

3. 全 URL の詳細情報を更新する

URL マッピングを定義したら、最終的な URL マッピングの移転準備を整えるために次の 3 つを行うことをおすすめします。

  1. 各ページにの HTML またはサイトマップ エントリ内のアノテーションを更新する。
    1. 各リンク先 URL に、自己参照 rel="canonical" LINK タグが必要です。
    2. 移転したサイトに、rel-alternate-hreflang アノテーションを使用した多言語または多国籍のページがある場合は、新しい URL をアノテーションに反映させます。
    3. 移転したサイトにモバイル版がある場合は、rel-alternate-media アノテーションを更新してください。詳しくは、スマートフォン ウェブサイトのガイドラインをご覧ください
  2. 内部リンクを更新する。
    新しいサイトの内部リンクを、元の URL から新しい URL に変更します。必要に応じて、先ほど生成したマッピングをリンクの検出と更新に利用できます。
  3. サイトマップとリンクリストを作成して保存する。
    最終的な移転に向けて次のリストを保存します。
    • マッピングの中の新しい URL を含むサイトマップ ファイル
    • マッピングの中の前の URL を含むサイトマップ ファイル
    • 現行のコンテンツにリンクしているサイトのリスト

    詳しくはサイトマップをご覧ください。

4. 301 リダイレクトを準備する

マッピングと新しいサイトの準備ができたら、次はマッピングで指定した元の URL から新しい URL への HTTP 301 リダイレクトをサーバーにセットアップします。

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

  • HTTP 301 リダイレクトを使用する: Googlebot は複数の種類のリダイレクトに対応していますが、できれば HTTP 301 リダイレクトを使用することをおすすめします。
  • リダイレクトの連鎖は避ける: Googlebot とブラウザは複数のリダイレクトの「チェーン」をたどることができますが(例: ページ 1 > ページ 2 > ページ 3)、最終的なリダイレクト先にリダイレクトすることをおすすめします。それができない場合は、連鎖するリダイレクトの数をできるだけ少なくします。5 個未満、できれば 3 個以下にしてください。リダイレクトが連鎖していると、ユーザーの待ち時間が長くなり、ブラウザによっては長いリダイレクト連鎖に対応していないことがあります。
  • リダイレクトをテストする: 個々の URL をテストするには、URL 検査ツールを、多数の URL をテストするにはコマンドライン ツールやスクリプトを使用できます。

サイト移転を開始する

URL マッピングが適切で、リダイレクトが動作することが確認できたら、移転準備完了です。

  1. サイトの移転方法を決定します - すべてを一度に移転する方法と、区分ごとに移転する方法があります。
    • 小規模または中規模のサイト: 区分ごとに移動するのではなく、一度にサイトのすべての URL を移転することをおすすめします。一度に移転することで、ユーザーが新しい形式のサイトを使いやすくなるともに、Google のアルゴリズムによるサイト移転の検出とインデックス登録の更新がより速くなります。
    • 大規模のサイト: 大規模のサイトでは分割して区分ごとに移転する方法もおすすめです。区分ごとに移動すると、監視や検出が簡単になり、問題を迅速に修正できるようになります。
  2. robots.txt ファイルを更新します。
    • 元のサイトで、すべての robots.txt ディレクティブを削除します。削除することで、Googlebot が新しいサイトへのすべてのリダイレクトを検出してインデックスを更新できるようになります。
    • 新しいサイトrobots.txt ファイルですべてのクロールが許可されていることを確認します。クロール対象ではないことが確実な URL を除き、画像や CSS、JavaScript も含めたページアセットのクロールが許可されている必要があります。
  3. [HTTP から HTTPS 以外の移行のみ] 元のサイトの Search Console で、アドレス変更の通知を送信します。HTTP から HTTPS にサイトを移行するだけの場合は、アドレス変更を送信しないでください。
  4. URL マッピングに基づいて、元のサイトから新しいサイトにユーザーと Googlebot をリダイレクトするように設定します。
  5. 元のサイトで、元の URL と新しい URL を含む、事前に用意した 2 つのサイトマップを送信します。これにより、Google のクローラが元の URL から新しい URL へのリダイレクトを検出しやすくなり、サイトの移転がスムーズに進むようになります。
  6. リダイレクトの期間はできるだけ長くするようにし、無期限とすることも検討します。ただし、リダイレクトはユーザーを待たせることになるため、ご自身のサイトのリンクや、アクセス数が多い他のサイトのリンクをできるだけ更新して、新しい URL を指すようにしてください。

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

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

  • 外部リンク: 現在のコンテンツにリンクされているサイトを保存したリストにあるサイトに連絡して、リンク先を新しいサイトに更新するよう依頼します。この際、外部からのアクセス数が多いリンクを優先することを検討してください。
  • Facebook、Twitter、LinkedIn などからのプロフィール リンク。
  • 新しいランディング ページに誘導する広告キャンペーン。

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

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

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

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

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

サイトにウェブ解析ソフトウェアをインストールしている場合、またはお使いの CMS に解析機能がある場合は、元のサイトから新しいサイトへのトラフィックの進捗を確認できるように、その方法でトラフィックを確認することもおすすめします。特に、Google アナリティクスではリアルタイム レポートを提供しており、これはサイト移転の初期段階に便利な機能です。元のサイトのトラフィックが減り、新しいサイトのトラフィックが増えるのが確認できるはずです。

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

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

よくある誤り

noindex または robots.txt によるブロック

移行にのみ必要な noindex や robots.txt によるブロックは必ず削除してください。

サイトに robots.txt ファイルがなくても問題ありませんが、robots.txt ファイルがリクエストされているのに提供されていない場合は、適切な 404 をできるだけ早く返すようにしてください。

確認方法

  • HTTPS サイトで robots.txt ファイルを調べて、変更が必要かどうかを確認します。
  • URL 検査ツールを使用して、新しいサイトで Google によって検出されていないと思われるページを確認します。

不正確なリダイレクト

元のサイトから新しいサイトへのリダイレクトを確認します。新しいサイトで間違った(存在しない)URL を指定していることがよくあります。

その他のクロールエラー

インデックス カバレッジ レポートで、移行イベント中に新しいサイトでその他のエラーが急増していないかどうかを確認します。

ホスト負荷が不十分

移転後、Google は新しいサイトを通常よりも多くクロールします。これは、元のサイトから新しいサイトにトラフィックがリダイレクトされ、元のサイトのクロールが新しいサイトにリダイレクトされるうえ、他のクロールも行われるためです。Google からのトラフィックの増加に対処できるよう、新しいサイトに十分なホスト負荷があるようにしてください。

アプリ内でウェブページを開く場合は、アプリリンクを新しい URL に更新してから、元のページから新しいページへのリダイレクトを実装してください。それ以外の場合は(Google では、アプリを使用して検索結果で新しい URL を開くことは推奨していませんが)、代わりにブラウザでユーザーをウェブサイトに誘導します。

サイトマップが更新されていない

サイトマップがすべて新しい URL で更新されていることを確認してください。

データ ハイライターが更新されていない

データ ハイライターを使用して元のページのマッピングが行われている場合は、新しいサイトでマッピングをやり直す必要があります。