URL移行への対処法

URLが変わるタイミング

URLが変わるタイミングは様々です。よくあるパターンとしては以下のようなケースがあります。

• サイトの再構築やブランドの変更、またはWebプラットフォームの変更
• ドメインの変更
• HTTPSへの移行
• アナリティクスの変更（トラッキングパラメータ）

ドメイン vs URLパス

ドメインの移行はURLパスの移行とは非常に異なるため、両者は別々に対処し、同時に実行しないようにしましょう。ドメインの移行は非常にシンプルで、個別のプロセスに従って実行します。

計画

URL移行を計画するにあたり、たくさんの考慮すべき要素や問題があります。既存のURLが許容できるのであれば、そのままにしておきましょう。そうでなければ、この移行プロセスを別の新規プロジェクトと認識するのではなく、既存のURLを改善する機会だと捉えましょう。URLがサイトのパフォーマンスを妨げる原因となっている場合には、少し様子を見ましょう。

デザイン

新しいURL構造をデザインする際、リダイレクトができるようにしてください。リダイレクトは移行を成功させ、過去のURLフォーマット（依然としてリンクされている可能性がある）を記憶しておくために欠かせません。 ルックアップテーブルはできるだけ使わないようにしましょう。これは、ルックアップテーブルの開発が難しく、長期的な維持が困難であり、かつパフォーマンスに問題が発生する可能性があるためです。

次のステップは移行で検証するために、URLを照合する作業です。リンクされたURLやインデックスされているオーガニック検索でのランディングページのリストを集めるために、サイトをクロールしましょう。そしてこれらを使って新しく移行したURLへの実際の訪問者数をシミュレーションします。

リダイレクトの設定には、DeepCrawlのURLリライト機能を使えば、リダイレクトのルールを指定して、本番環境に反映する前にうまく機能するか検証することができます。

検証

次のステップはSEO担当者、またはディベロッパーが新しいURLを使ってステージングサイトで実際のリダイレクトを行うことです。これが完了したらステージングサイトにある古いURLのクロールを実行して、実際にリダイレクトが機能するか検証しましょう。実際に運用が開始してから負荷に耐えきれなくなるケースも多いため、このタイミングで負荷テストも併せて行っておきましょう。そしてできる限りリダイレクトを許容する割合を制限せず、全て許容するようにしておいてください。どうしてもできない場合には、トラフィックやバックリンクに応じて優先順位の高い順にリダイレクトを設定しましょう。

DeepCrawlを使うことで、リダイレクトとリダイレクトチェーンを容易に検出することができます。リダイレクトチェーンについては、３回以上リダイレクトするものがないようにしましょう。ドメインやプロトコルのレベルへのリダイレクトや、URLパスに対しては２回目のリダイレクトを行うことが適している場合がありますが、リダイレクトチェーンにおいては必ず３回以上リダイレクトが発生しないようにしてください。

URLのリダイレクトについての詳細は こちらの記事をご確認ください。

リリース

テストクロールで全てのリダイレクトが404エラーなく機能していることが分かったら、リダイレクトのルールを本番環境へと移行して、新しくクロールを実行してください。それがうまく行けば、リダイレクトするURLだけのサイトマップファイルを作成してGoogleへ送信してください。これによりGoogleがURLを再度クロールし、新たなリダイレクトを検出します。

サーチコンソールにリダイレクトのサイトマップを送信したら、インデックスの割合を確認してください。この割合が０となっていれば、サイトマップを削除して問題ありません。

これでURLの移行が全て問題なく完了したので、あとはリダイレクトをできるだけ適切な場所に残し、リダイレクトしていないURLに関してはGoogleアナリティクスやサーチコンソールを使ってモニタリングしていきましょう。