301リダイレクト(恒久的リダイレクト)

301は、あるURLから別のURLへ恒久的に転送するHTTPレスポンスです。転送先が今後の優先URLになることを示します。

301が決めること

301 Moved Permanentlyのレスポンスは、ブラウザーやクローラーを転送元URLから転送先URLへ送ります。伝えるのはURL同士の関係であり、検索順位やトラフィックを約束するものではありません。Googleは、恒久的なリダイレクトを正規化のシグナルとして説明しています。移動が元に戻らない場合、転送先が検索結果に表示される候補になります。

判断のポイントは2つです。1つ目は、旧リソースに本当に長く使える後継があること。2つ目は、転送先が同じ検索意図、またはより役に立つ内容に応えていることです。後継のない販売終了商品は、カテゴリページやホームページへリダイレクトするより、404や410が適する場合があります。終了したURLをすべて1つの広いページへ転送すると、ユーザーにもクローラーにも関係が分かりにくくなります。

301リダイレクト(恒久的リダイレクト)の主な入力、チェック、判断の流れを示す図です。
恒久的リダイレクトは、全体の仕組みの中の1つのシグナルです。canonicalタグ、内部リンク、サイトマップ、転送先のレスポンスも、これと一致している必要があります。301を設定しても、決まったスケジュールでインデックス登録が変わるわけではありません。

恒久的リダイレクトが適する場面

旧URLが長期的に移動した場合は301を使います。ページ名の変更、重複ページの統合、プロトコルやホストの統一、ページ単位で設計したサイト移行などが該当します。旧ページは、残るページのうち最も近いものへ対応づけます。古いブックマークや外部リンクから来たユーザーに役立つ道筋が残り、クローラーにも迷いのない経路を示せます。

適切な対応
旧ガイドを同じ作業を扱う新ガイドに置き換え、1回のリダイレクトでその新ガイドへ転送する。
不適切な対応
終了した商品を、関係のないランディングページへ、そのページがあるというだけで転送する。
移動ではないケース
ページが後で戻る可能性がある、または短期間のテスト中である場合。一時的なルーティングの問題として扱います。

移行では、ナビゲーションを変更する前にリダイレクトマップを作ります。1行ごとに、転送元のパス、選んだ転送先、その理由、公開後に確認したレスポンス、例外の担当者を記録します。ページ単位のマップで最終的なレスポンスの経路をテストすれば、ホスト全体に適用した広いルールが、無関係な数千ページを知らないうちにホームページへまとめてしまう事態を防げます。

実装と確認

  1. アクセスや被リンクがある旧URLを洗い出し、意味のあるページごとに、インデックス登録できる最終的な転送先を1つ決めます。
  2. ページの内容を返す前に、HTTPの301ステータスとLocationヘッダーを返すよう、サーバーまたはプラットフォーム側でリダイレクトを設定します。
  3. 内部リンク、XMLサイトマップ、canonicalタグの参照先を最終URLに更新します。リダイレクト元を指したままにしません。
  4. 転送元URLにリクエストし、チェーンをたどります。ステータスの順序と最終URLを記録し、最終ページが正常なレスポンスを返すか確認します。
  5. 公開後、対象のURLを再クロールします。ループ、複数ホップのチェーン、リダイレクトからリダイレクトへ続くルール、ブロックやnoindexが設定された転送先がないか調べます。
bash
curl -I https://example.com/old-page
# Expect: HTTP/2 301 and a Location header
curl -IL https://example.com/old-page
# Inspect every hop and the final response

設定の書き方はプラットフォームによって異なります。ルールをそのままコピーするより、守るべき原則が重要です。転送元は1回のホップで、意図した正規URLの転送先へたどり着くようにします。一時的なインフラのルールとコンテンツの移動は分けて管理します。そうすれば、メンテナンス用の変更を元に戻したときに、移行マップまで壊してしまうことがありません。

よくある失敗と限界

よくある誤解は、301を設定すれば機械的に「評価が引き継がれる」というものです。検索エンジンは複数のシグナルを評価し、再クロールも独自のスケジュールで行います。確認できるのはもっと限られた範囲です。サーバーが意図したステータスを返していること、転送先に到達でき、インデックス登録できること、マップの内容が適切であること、サイト内の参照が最終URLを使っていることです。リンク評価の引き継ぎ率を固定の数字で語ったり、検索結果が入れ替わる時期を保証したりするのは避けます。

  • 2つ目の移行ルールを追加した後にチェーンが発生します。転送元から最終URLへの直接のルールに置き換えます。
  • ホストやプロトコルのルールがページのルールと矛盾すると、リダイレクトループが起きます。HTTP/HTTPSとホストの両方のパターンをテストします。
  • 301の転送先が404、noindexのページ、ブロックされたルートになっている場合は、転送先を直してから、転送元の対応づけが完了したと判断します。
  • 古いサイトマップが公開されたままの場合は、リダイレクトされるURLを削除し、サイトマップには最終的にインデックス登録するページだけを載せます。

FAQ

302ではなく301を使うのは、どのような場合ですか?
旧URLが戻ることはなく、転送先がその恒久的な後継になる場合は301を使います。元のURLが今後も長期的な基準であり続ける見込みの場合に限り、一時的なリダイレクトを使います。
削除したURLは、すべてホームページへリダイレクトすべきですか?
いいえ。内容が近く、役に立つ後継ページがある場合だけリダイレクトします。関係のないホームページへのリダイレクトはユーザーを混乱させ、コンテンツの移動も明確に示せません。
301を安全に確認するには、どうすればよいですか?
転送元URLにリクエストしてリダイレクトをたどり、最終的なステータス、転送先、canonicalタグの方針、インデックス登録の可否、内部リンクを確認します。ルールを変更したら、代表的なURLの一部でも必ずテストします。
301なら検索順位が維持されると保証されますか?
いいえ。301は移動を伝える強いシグナルですが、表示への影響はクロール、インデックス登録、転送先の関連性などによって決まります。