サイト移行後のページがインデックスされない：完全リカバリーガイド
サイト移行はブラウザ上では問題なく完了しましたが、Googleは新しいURLを認識するのに苦労しています。重要な90日間のウィンドウを理解し、移行後のインデックスを妨げるリダイレクト、canonical、検証の問題を修正しましょう。
このガイドの内容
サイト移行はSEOにおいて最もリスクの高い作業の1つです。新しいドメインへの移動、URL構造の変更、HTTPからHTTPSへの移行、CMSプラットフォームの切り替え、複数サイトの統合のいずれであっても、移行はGoogleのサイト理解を根本的に混乱させます。何年もインデックスされていたページが突然検索結果から消える可能性があります。古いURLを置き換えるべき新しいURLがクロールキューで停滞します。Googleがサイト全体を新しい形で再評価するため、ランキングが全体的に低下します。
移行後の最初の90日間は重要です。この期間中、Googleはあなたのサイトを積極的に再クロールし、リダイレクトを処理し、新しいURLを評価し、新しいサイト構造が古いものと同じインデックスカバレッジとランキングに値するかどうかを判断しています。このウィンドウ中のミスは、数ヶ月にわたるトラフィック損失をもたらす可能性があります。しかし、よく実行された移行でも、新しいサイトの一部のページがインデックスされず、対応する古いURLがインデックスから削除されているインデックスギャップが一般的に発生します。
移行後のインデックス問題は、2つの状態間の遷移を伴うため、通常のインデックス問題とは異なります。Googleは、古いURLの削除と新しいURLの追加を同時に処理し、リダイレクトを通じて古いページから新しいページへ権威を移転し、サイトのコンテンツに関する既存の理解を新しい構造と調整する必要があります。これにより、通常のサイト運用では発生しない混乱、シグナルの欠落、インデックスギャップの機会が生まれます。
本ガイドでは、サイト移行中および移行後に発生する具体的なインデックス問題、それらを特定するための診断手順、そして移行期間中のトラフィック損失を最小限に抑えるために迅速に解決する修正方法を扱います。
重要な移行後90日間ウィンドウ
サイト移行に対するGoogleの反応は、約90日間にわたって展開されますが、正確なタイムラインはサイトサイズ、クロール頻度、変更の範囲によって異なります。このタイムラインを理解することで、期待値を設定し、インデックスの遅延が正常な場合と問題を示している場合を識別できます。
移行後の最初の1〜2週間で、Googleは変更を発見し始めます。古いURLから新しいURLへの301リダイレクトを設定している場合、Googleは古いURLの通常のクロール中にこれらのリダイレクトに遭遇します。各リダイレクトは、古いURLが恒久的に新しい場所に移動したことをGoogleに伝えます。Googleはこれらのリダイレクトを処理し、新しいURLをクロールキューに追加し始めます。この段階では、検索結果に古いURLと新しいURLが混在して表示されますが、これは正常です。
2〜4週目には、Googleは新しいURLのクロールを加速します。新しいURL構造を持つ新しいsitemapを送信し、Google Search Consoleで新しいドメインを検証している場合、Googleは新しいサイトの探索を加速します。インデックス内の古いURLと新しいURLの比率が新しいURLに向かってシフトするのが見られるはずです。Googleがすべてのリダイレクトをまだクロールおよび処理していないため、一部の古いURLは検索結果に表示され続けます。
4〜8週目には、遷移の大部分が完了するはずです。ほとんどの古いURLは適切にリダイレクトされ、ほとんどの新しいURLはインデックスされ、ランキングは移行前のレベルまたはその近くで安定し始めるはずです。ランキングが以前よりも大幅に低い場合、品質シグナルに影響を与えるリダイレクトの問題、コンテンツの変更、または新しいサイトの技術的問題がある可能性があります。
8〜12週目には、新しいサイトに対するGoogleの信頼が固まります。まだインデックスされている残りの古いURLは処理されるべきです。移行が正しく実行されていれば、ランキングは移行前のレベルまで回復するはずです。この時点で特定のページがまだインデックスされていない場合、それらにはターゲットを絞ったトラブルシューティングが必要な個別の問題があります。
この90日間のウィンドウ全体を通して、サイトへの追加の大きな変更を避けてください。新しいサイトを再設計しない、URLを再び再構築しない、コンテンツを大幅に変更しないでください。追加の変更ごとにGoogleの評価プロセスの一部がリセットされ、リカバリータイムラインが延長されます。移行後の90日間を、唯一の変更が移行関連の問題の修正であるべき安定化期間として扱ってください。
301リダイレクトのチェーン、ループ、マッピングギャップ
リダイレクトの実装は、移行後のインデックスにおいて最も重要な単一の要因です。ランキング、トラフィック、またはバックリンクを持っていたすべての古いURLは、新しいサイトで最も関連性の高いページにリダイレクトする必要があります。リダイレクト実装のミスは、移行後のインデックス失敗の大部分の原因です。
リダイレクトチェーンは、1つのリダイレクトが別のリダイレクトを指し、それが別のリダイレクトを指すときに発生します。たとえば、http://old-domain.comはhttps://old-domain.comにリダイレクトし、それがhttps://new-domain.com/pageにリダイレクトします。Googleはリダイレクトチェーンに従うことができますが、チェーンの各ホップでレイテンシが発生し、一部のリンクエクイティが失われる可能性があります。Googleは、単一の301リダイレクトを通じてPageRankを完全に渡すと述べていますが、チェーンについてはあまり明確ではありません。ベストプラクティスは、チェーンを最大2ホップに最小化し、理想的には各古いURLから最終目的地への直接の1ホップリダイレクトを実装することです。
リダイレクトループは、URL AがURL Bにリダイレクトし、URL BがURL Aに戻るときに発生します。これによりGoogleは最終目的地ページに到達できず、クロールエラーになります。ループは、HTTPがHTTPSにリダイレクトし、HTTPSバージョンにも特定のパスをHTTPに戻すリダイレクトルールがある場合、またはwwwと非wwwのリダイレクトが互いに競合する場合によく発生します。各URLの完全なリダイレクトパスをたどるリダイレクトチェーンチェッカーツールを使用してリダイレクト実装をテストしてください。
マッピングギャップは、新しいURLへのリダイレクトを持たない古いURLです。Googleが古いURLをクロールし、リダイレクトの代わりに404エラーを受け取った場合、そのURLをインデックスから削除します。同等のページが新しいサイトに存在するがリダイレクト計画にマッピングされていなかった場合、Googleは古いページの権威を新しいページに接続する方法がありません。新しいページはゼロからインデックスを獲得しなければならず、蓄積されたすべてのランキングシグナルを失います。
マッピングギャップを特定するには、古いインデックスされたURLの完全なリスト（移行前にGoogle Search Consoleからエクスポートするか、移行前のクロールから）をリダイレクトマッピングファイルと比較します。対応するリダイレクトを持たない古いURLはギャップです。新しいサイトに直接相当するものがない古いURLについては、404にさせるのではなく、最も関連性の高い親ページまたはカテゴリーにリダイレクトしてください。やや関連性のあるページへのリダイレクトは、リンクエクイティの観点から常に404よりも優れています。
移行後は、古いURLのクロールエラーについてGoogle Search Consoleを監視してください。古いURLパターンでの404エラーの急増は、欠落しているリダイレクトを示しています。最初の90日間は404エラーリストを定期的に確認し、エラーを返している高トラフィックまたは高権威の古いURLにリダイレクトを追加してください。
Google Search Consoleの検証とsitemap管理
適切なGoogle Search Consoleの設定は、移行後のインデックスにとって重要です。移行にドメイン変更、URL構造の変更、またはプロトコルの変更が含まれる場合、Search Consoleのセットアップには、Googleが遷移を正しく処理できるよう、特定の更新が必要です。
ドメイン移行（old-domain.comからnew-domain.com）では、古いドメインと新しいドメインの両方をGoogle Search Consoleで検証する必要があります。古いドメインプロパティを削除しないでください。Googleが古いURLからの遷移をどのように処理するかを監視し、アドレス変更ツールを使用するために必要です。古いドメインのSearch Consoleプロパティで、設定に移動し、アドレス変更機能を使用して、サイトが新しいドメインに移動したことをGoogleに正式に通知してください。これにより、Googleのドメイン変更処理が加速され、遷移中のランキングシグナルの保持に役立ちます。
新しいドメインについては、移行直後にSearch Consoleでドメインプロパティとして検証してください。すべての新しいURLを含む新しいXML sitemapを送信します。新しいsitemapには、新しいURL構造のみをリストするべきです。古いURLを新しいsitemapに含めないでください。古いsitemapがまだ古いドメインでアクセス可能な場合、一時的にそのままにしておきます。Googleは古いsitemapをクロールし、各URLのリダイレクトに遭遇し、新しいURLまでそれらに従うため、発見に役立ちます。
同じドメインでのURL構造の変更（たとえば、/blog/post-titleを/articles/post-titleに変更）については、新しいURLパターンを持つ更新されたsitemapを送信します。URL検査ツールを使用して、最も重要な新しいURLの再クロールをリクエストしてください。Googleは通常のクロール中にリダイレクトを通じてURLの変更を発見するはずですが、sitemapの送信によってプロセスが加速されます。
HTTPからHTTPSへの移行については、まだ追加していない場合は、ドメインのHTTPSバージョンをSearch Consoleに追加して検証してください。HTTPS URLを持つ新しいsitemapを送信します。Googleは一般的にHTTPSの移行をスムーズに処理しますが、HTTPS URLがインデックス内でHTTP URLを置き換えていることを確認するため、その後の数週間にわたってHTTPS URLのインデックスを監視してください。
よくあるミスは、新しいサイトに古いURLを持つsitemapを送信することです。移行後、含まれるすべてのURLが新しいサイトで有効なリダイレクトしないURLであることを確認するために、sitemapを監査してください。古いURLまたはリダイレクトするURLを参照するsitemapは、Googleに混乱したシグナルを送り、新しいURL構造のインデックスを遅らせる可能性があります。
移行後のインデックスに影響を与えるコンテンツとテンプレートの変更
多くのサイト移行には、URLの変更だけでなくそれ以上のものが含まれます。再設計、CMSの切り替え、コンテンツの再構築、またはテンプレートの更新と同時に行われることがよくあります。これらのコンテンツレベルの変更は、URL移行の課題を複合させる独立したインデックス問題を引き起こす可能性があります。
CMSの切り替えがページのレンダリング方法を変更すると、以前は存在しなかったJavaScriptレンダリングの問題が発生する可能性があります。WordPressのようなサーバーレンダリングCMSからReactやVueのようなJavaScriptフレームワークに移行した場合、以前はサーバーレンダリングされていたページが現在はクライアントサイドレンダリングされている可能性があります。Googleは、初期HTMLから以前はインデックスできたページを処理するためのJavaScriptレンダリングキューを待たなければなりません。これだけで、すべてのページのインデックスタイムラインに数日が追加される可能性があります。
テンプレートの変更は、サイトの内部リンク構造を変える可能性があります。異なるナビゲーション、異なるサイドバーウィジェット、異なるフッターリンク、または異なる関連コンテンツセクションを持つ新しいデザインは、どのページがどの他のページにリンクするかを変えます。再設計中に重要な内部リンクが削除された場合、一部のページは古いサイトで強力な内部リンクを持っていたにもかかわらず、新しいサイトで孤立する可能性があります。新しいサイトをクロールし、内部リンクグラフを古いサイトと比較して、内部リンクサポートを失ったページを特定してください。
移行中のコンテンツの変更は、善意のものであっても、インデックスに影響を与える可能性があります。ページタイトルを書き直したり、ページを結合または分割したり、コンテンツセクションを追加または削除したり、見出し構造を変更したりした場合、Googleはこれらを古いコンテンツの更新版として認識するのではなく、新しいコンテンツとして評価します。大幅なコンテンツ変更は、Googleがリダイレクトを通じて古いページの権威を引き継ぐのではなく、ページの品質をゼロから再評価する原因となる可能性があります。
最も安全な移行アプローチは、URL移行をコンテンツ／デザイン移行から分離することです。まず、コンテンツやテンプレートを変更せずにURLとリダイレクトを移行します。GoogleにURL変更を処理させ、4〜6週間にわたってインデックスを安定化させます。次に、デザインとコンテンツの変更を段階的に行います。この段階的なアプローチにより、どの変更がどの効果を引き起こしたかが正確にわかるため、問題の診断が容易になります。すべてを一度に行うと、URLの問題、コンテンツの問題、技術的な問題がすべて絡み合うため、トラブルシューティングがほぼ不可能になります。
ステップバイステップガイド
すべての古いURLのリダイレクト実装を検証する
古いサイトからインデックスされたURLの完全なリスト（移行前のクロールまたはSearch Consoleエクスポートから）をエクスポートします。一括リダイレクトチェッカーツールを使用してすべてのリダイレクトをテストします。各古いURLが302ではなく301で正しい新しいURLにリダイレクトすることを確認してください。リダイレクトチェーン（複数ホップ）、リダイレクトループ（循環リダイレクト）、マッピングギャップ（404を返す古いURL）を特定して修正します。最もトラフィックが多く、最もバックリンクが多く、最もランキングが強いページのリダイレクト修正を優先してください。欠落したまたは壊れたリダイレクトはすべて、漏洩したランキングシグナルです。
新サイト用にGoogle Search Consoleをセットアップする
Google Search Consoleで新しいドメインまたはURL構造をドメインプロパティとして検証します。古いドメインプロパティをアクティブのままにしてください。ドメインを移行する場合は、古いドメインのSearch Consoleプロパティのアドレス変更ツールを使用して、Googleに移動を通知します。新しいURL構造のみを含む新しいXML sitemapを新しいプロパティに送信してください。sitemapが送信後48時間以内にGoogleによって正常に読み取られていることを確認します。インデックスをブロックする可能性のあるセキュリティ問題や手動アクションが新しいプロパティにないかを確認してください。
新しいsitemapの正確性を監査する
新しいsitemapをダウンロードし、その中のすべてのURLを検証します。各URLは200ステータスコードを返し、別のURLにリダイレクトせず、noindexタグを持たないようにしてください。sitemapを新しいサイトのページの完全なリストと相互参照して、ページが欠けていないことを確認します。リダイレクトしたりエラーを返したりするURLをsitemapから削除してください。CMSが自動的にsitemapを生成する場合、新しいURL構造用に設定されており、まだ古いURLパターンを生成していないことを確認してください。クリーンアップしたsitemapをGoogle Search Consoleに送信します。
新サイトでの技術的ブロッカーを確認する
新サイトのrobots.txtがすべての重要なページのクロールを許可していることを確認します。ステージングまたは開発環境からグローバルなnoindexタグが残っていないかを確認してください。多くのCMSプラットフォームはステージング環境にnoindexを適用し、この設定が本番URLへの移行後も持続する可能性があります。異なるセクションの5〜10ページでURL検査ツールを使用して、新サイトのレンダリングをテストしてください。ページコンテンツが正しくレンダリングされ、JavaScriptやリソースの読み込みエラーがGoogleがコンテンツを見ることを妨げていないことを確認します。HTTPSへの移行の場合は、SSL証明書の有効性を確認してください。
Search Consoleでインデックスの遷移を監視する
移行直後から、最初の2週間は毎日、その後の10週間は毎週、古いプロパティと新しいプロパティの両方のGoogle Search Consoleでページレポートを監視します。新しいプロパティのインデックスされたページ数（増加しているはず）、古いプロパティのインデックスされたページ数（減少しているはず）、両方のプロパティのクロールエラー数、および出現する新しい「インデックス未登録」の理由を追跡してください。これらの指標を時間の経過とともに追跡するスプレッドシートを作成し、遷移プロセスのトレンドと停滞を特定できるようにします。
優先度の高い新しいURLのインデックスをリクエストする
最も重要なページ（最高のトラフィック、最高の収益、最も多くのバックリンク）の上位50〜100ページを特定し、新しいURLでインデックスされていることを確認します。まだインデックスされていないものについては、URL検査ツールを使用して個別にインデックスをリクエストしてください。何百または何千もの重要なページを持つ大規模なサイトについては、IndexBoltを使用して新しいURLを一括送信し、より迅速なインデックスを実現してください。移行前に強いランキングを持っていたページを優先してください。これらは、インデックスの遅延が最も大きなビジネスインパクトを持つページだからです。
30日後に残っているインデックスギャップを調査して修正する
30日経過後、まだ新しいURLでインデックスされていないページには、通常の移行遷移を超える特定の問題がある可能性が高いです。各インデックスされていないページについて、次を確認してください。古いURLからのリダイレクトは正しく機能していますか？新しいURLは200ステータスコードを返しますか？新しいURLのコンテンツは古いURLと実質的に同じですか？新しいURLに新しいcanonical、noindex、またはレンダリングの問題はありますか？ページは新しいサイトの他のインデックスされたページから内部リンクを受け取っていますか？各問題を個別に対処し、インデックスのために再送信してください。識別可能な技術的問題なしに60日後もまだインデックスされていないページは、現在の品質しきい値を満たすためにコンテンツの改善が必要かもしれません。
よくある問題と解決方法
移行から数ヶ月経っても古いURLが検索結果に表示され続ける
原因： GoogleはまだこれらのURLのリダイレクトをクロールおよび処理していません。これは、移行前に頻繁にクロールされていなかった古いURL、または非常に大きなURL数を持つサイトでは一般的です。また、リダイレクトが301（恒久的）ではなく302（一時的）を返している可能性も示している可能性があり、これによりGoogleはリダイレクトを一時的なものとして扱いながら、古いURLをインデックスに保持します。
解決方法： リダイレクトが302（一時的）ではなく301（恒久的）であることを検証します。古いドメインのSearch Consoleプロパティでhttps://www.google.com/search?q=URL検査ツールを使用して、永続的な古いURLの再クロールをリクエストしてください。これにより、Googleがリダイレクトに遭遇して処理することを強制します。アドレス変更ツールを使用している場合、正しく設定されていることを確認してください。大規模サイトについては、IndexBoltを使用して新しいURLを直接送信してください。これにより、リダイレクト処理と並行して新しいページがインデックスに追加されます。
移行後、新しいURLが「クロール済み — インデックス未登録」と表示される
原因： Googleは新しいURLをクロールしましたが、インデックスの品質しきい値を満たしていないと判断しました。これは、移行に大幅なコンテンツ変更が含まれた場合、新しいテンプレートが古いものよりも少ないコンテンツを提供する場合（たとえば、サイドバーコンテンツや関連投稿セクションの削除）、または遅いページ速度やレンダリングの問題などの技術的な問題により、Googleの新サイトに対する品質評価が古サイトよりも低い場合に発生する可能性があります。
解決方法： 新しいURLのコンテンツを古いURLのキャッシュバージョンと比較します。移行中に削除または変更されたコンテンツを特定してください。移行中に削除されたユニークなコンテンツを復元します。新サイトのページ速度とCore Web Vitalsを確認してください。大幅なパフォーマンスの低下は品質シグナルに影響を与える可能性があります。新サイトのナビゲーションからの内部リンクがこれらのページに到達することを確認してください。コンテンツが同等の場合、IndexBoltを通じてURLを送信し、Googleに再評価を促してください。
移行後、Search Consoleで404エラーが大量に急増している
原因： Googleが以前クロールしていた古いURLが、それらに対してリダイレクトが実装されていないため、現在404を返しています。これは、リダイレクトマッピングが不完全で、すべての古いURLではなく最も重要なページのみをカバーしていた場合によく発生します。また、Googleが移行を完全に処理する前に古いサーバーまたはホスティングがオフラインにされた場合にも発生します。
解決方法： 古いドメインプロパティのSearch Consoleで404エラーリストを監査します。重要なトラフィック、バックリンク、またはランキングを持っていた404 URLのリダイレクト実装を優先してください（移行前のデータと照合）。トラフィックやバックリンクのないURLについては、Googleが自然にインデックスから削除するため404が許容されます。Googleがすべてのリダイレクトを処理する時間を確保するために、移行後少なくとも6ヶ月間は古いドメインのホスティングとリダイレクト設定をアクティブのままにしてください。古いドメインのホスティングを早期に停止しないでください。
移行後にランキングが大幅に低下し、回復していない
原因： 厳密にはインデックス問題ではありませんが、ランキングの低下は移行中のインデックス問題に伴うことがよくあります。一般的な原因には、リンクエクイティを希釈するリダイレクトチェーン、バックリンクを持つページのリダイレクト欠落、Googleがあまり好意的に評価しない大幅なコンテンツ変更、新サイトでの遅いページ速度、新デザインでのモバイルユーザビリティの問題、古サイトでクリック率を高めていた構造化データやリッチリザルトの喪失などがあります。
解決方法： 古いサイトと新しいサイトの間で包括的な比較を実施してください。リダイレクトチェーンの深さを確認し、1ホップを超えるチェーンを修正します。バックリンクのあるすべてのページに直接リダイレクトがあることを確認してください。古いサイトと新しいサイトのCore Web Vitalsを比較します。構造化データの実装を比較してください。モバイルユーザビリティを比較します。それぞれの不足に対処してください。新しいサイトが技術的に健全でコンテンツが同等であれば、Googleの新サイトに対する信頼が構築されるにつれて、ランキングは通常60〜90日以内に回復します。90日を超える持続的なランキング低下は、調査が必要な実質的な品質差を示しています。
古いURLと新しいURLの両方で同時にページがインデックスされる
原因： Googleは遷移の過程にありますが、これらのページのリダイレクトをまだ完全に処理していません。これにより、同じコンテンツがインデックス内の2つのURLに表示され、ランキングの混乱と古いURLと新しいURLの間でのトラフィック分割を引き起こす可能性があります。通常、4〜6週間以内に自然に解決しますが、リダイレクトが301ではなく302として実装されている場合は持続することがあります。
解決方法： すべてのリダイレクトが301（恒久的）であることを検証します。302リダイレクトを使用している場合は、すぐに301に変更してください。URL検査ツールを使用して、古いURLと新しいURLの両方を確認します。古いURLがリダイレクト付きでインデックスされていると表示される場合、Googleはそれを処理していますが、遷移をまだ完了していません。これは最初の数週間は正常です。6週間を超えて持続する場合は、Googleにリダイレクトを処理させるために古いURLの再クロールをリクエストしてください。新しいURLのcanonicalタグが古いURLではなく自身（自己参照）を指していることを確認してください。
プロのヒント
よくある質問
Googleの観点から、完全なサイト移行の完了にはどのくらいの時間がかかるべきですか？+
ほとんどのサイト移行は、60〜90日以内にGoogleによって完全に処理されます。最初の2週間は、インデックスに古いURLと新しいURLが混在して表示されます。4週目までに、ほとんどの新しいURLがインデックスされ、ほとんどの古いURLがリダイレクトしているはずです。8週目までに、エッジケースのみが残り、遷移は実質的に完了しているはずです。非常に大規模なサイト（数百万ページ）は、Googleのクロール容量が有限であるため、時間がかかる場合があります。移行が90日以内に実質的に完了していない場合、調査が必要な技術的な問題（壊れたリダイレクト、ブロックされたクロール、レンダリングの問題）がある可能性が高いです。
サイト移行には301と302のどちらのリダイレクトを使用すべきですか？+
サイト移行には常に301（恒久的）リダイレクトを使用してください。301リダイレクトは、移動が恒久的であることをGoogleに伝え、これによりGoogleはランキングシグナルを新しいURLに転送し、最終的に古いURLをインデックスから削除します。302（一時的）リダイレクトは、移動が逆転する可能性があることをGoogleに伝え、これによりGoogleは古いURLをインデックスに保持し、権威を完全に転送しません。Googleは長期にわたる302を最終的に301と同様に扱うと述べていますが、最初から301を使用することで遅延と曖昧さを回避できます。302を使用する唯一の理由は、リダイレクトが本当に一時的であり、古いURLを復元する予定がある場合です。
HTTPからHTTPSに移行しています。これらすべての手順を実行する必要がありますか？+
はい、HTTPからHTTPSへの移行は最も単純なタイプであり、Googleが最もスムーズに処理しますが、それでも必要です。すべてのHTTP URLからそのHTTPS相当へ301リダイレクトを実装し、sitemapをHTTPS URLを使用するように更新し、Google Search ConsoleでHTTPSプロパティを検証し、canonicalタグをHTTPSを使用するように更新する必要があります。HTTPS移行の主な利点は、Googleが積極的に推奨しているため、処理が速くなる傾向があることです。ほとんどのHTTPS移行は、3〜4週間以内に完全に処理されます。ただし、同じリダイレクトマッピング、sitemap、監視要件が適用されます。
新しいドメインに移行すると、バックリンクはどうなりますか？+
古いドメインへのバックリンクは、301リダイレクトを通じて新しいドメインに価値を渡し続けますが、その過程でいくらかの価値損失があります。Googleは301リダイレクトがリンクエクイティの大部分を渡すことを確認していますが、正確な量は開示されていません。一部のSEO研究は、リダイレクトホップあたり10〜15%の損失を示唆しています。バックリンク価値の保存を最大化するために、各古いURLから新しい相当へ直接の1ホップ301リダイレクトを実装してください。最も重要なバックリンク（最も権威の高いドメインから）については、リンク元のサイトに連絡し、リンクを更新して新しいURLを直接指すよう依頼することを検討してください。リダイレクトを完全にバイパスできます。
サイトを段階的に、1つのセクションずつ移行できますか？+
段階的な移行は可能ですが、複雑さが増します。1つのセクションずつ移行する（たとえば、最初に/blog/、次に/products/、その後その他）と、Googleは1つの包括的な変更ではなく、複数ラウンドの変更を処理しなければなりません。利点は、ミスのブラスト半径が制限されることです。ブログの移行で何か問題が発生しても、商品ページは影響を受けません。欠点は、合計移行タイムラインが長くなり、一部のセクションが新しい構造にあり他がまだ古い構造にある場合、リダイレクトの管理がより複雑になることです。ほとんどのサイトでは、よく計画された単一の移行が段階的なアプローチよりも好ましいです。