302が決めること
302 Foundのレスポンスは、今回のリクエストを別のURLへ転送しますが、その移動が恒久的であるとは宣言しません。Googleは、一時的なリダイレクトについて、Googlebotはリダイレクトをたどるものの、転送先を正規URLにするシグナルとしては使わないと説明しています。この違いがあるため、期間と意図が技術的な判断の一部になります。
302が役立つのは、元のURLが今後も長期的なアドレスであり、短期間の運用上の都合で迂回させる場合です。移行用リダイレクトの控えめな版ではありません。元のURLに戻す予定がなくなったら、判断を見直し、一時的なルールを恒久的な対応づけに置き換えます。誤解を招くステータスを放置してはいけません。
一時的な転送が適する場面
よくある例は、説明ページを用意した短期間のサービス停止、期間限定キャンペーンの転送先、ログインのフロー、公開されている正規ページを置き換えない地域の提案などです。どの場合も、一時的な事情が終われば、ユーザーが元のリソースへ戻れる状態にしておきます。
- 適切な対応
- 機能が一時的に使えなくなり、サービスが復旧するまで、転送元URLからステータスページや代替案のページへユーザーを案内する。
- 見直しが必要
- 「一時的」なキャンペーン用ルールが、キャンペーン終了後も残っている。転送元と転送先を見直す。
- 不適切な対応
- ページが新しいURLへ恒久的に移動したのに、サーバーがまだ302を返している。
地域別のルーティングでは、ユーザーが選択をやり直せるようにします。位置情報の判定結果を、1つのバージョンが検索結果のほかのすべてのURLに取って代わる根拠として扱ってはいけません。インデックス登録と言語・地域の戦略には、canonicalタグと代替ページを使った別の設計が必要です。
実装と確認
- 一時的になる業務上または運用上の事情、転送元URL、転送先、見直し日を書き出します。
- クライアント側のレンダリングに頼らずレスポンスを確認できるよう、サーバーまたはアプリケーションの層でHTTPの302を返します。
- 元のURLは本来の用途で使える状態に保ちます。内部リンク、サイトマップ、canonicalタグが、短命な転送先へ知らないうちに移ってしまわないようにします。
- HTTPクライアントでレスポンスの経路をたどり、一時的なホップが1回であること、Locationが意図どおりであること、最終ページが動作することを確認します。
- 事情が終わったらルールを削除します。変更が恒久的になる場合は、意図的に恒久的なリダイレクトマップを作り、サイト内の参照を更新します。
curl -I https://example.com/original
# Expect: HTTP/2 302 and a Location header
curl -IL https://example.com/original
# Check the temporary hop and final responseサーバーのフレームワークによっては、リダイレクト用の標準ヘルパーが302を返します。意図したステータスが出力されていると決めつけず、実際のレスポンスを調べます。ブラウザーのナビゲーションでは途中のリクエストが見えないことがあります。正確なチェーンが必要なときは、開発者ツールやHTTPクライアントを使います。
よくある失敗と限界
よくある誤りは、長く続く302を、害のない恒久的な移動として扱ってしまうことです。検索エンジンは、長期にわたるパターンをほかのシグナルと合わせて評価することがあります。ただし、公式に示されていない基準値に頼らず、実装の側で本来の意図を正しく伝えるべきです。終了予定日を過ぎたらステータスを見直し、転送元が戻るのか、一時的なルーティングを続けるのか、恒久的に移動するのかを明確に決めます。
- サイトやプロトコルの移行に302を使っている場合は、移動が元に戻らないなら、恒久的なページ単位の対応づけに置き換えます。
- 一時的な転送先自体がリダイレクトされる、または利用できない場合は、経路を単純にし、最終ページを修正します。
- ユーザーが地域の転送ループに閉じ込められる場合は、選択をやり直せるようにし、代表的なロケール設定でテストします。
- ルールに担当者や期限がない場合は、リリース記録に加え、意図して削除できるようにします。