HTTP 301 と 302 リダイレクト

恒久性はリソース関係を表現する

HTTP 301 は、対象リソースに新しい恒久的な URI があることを伝え、302 は一時的な場所を伝えます。 HTTP リダイレクトのセマンティクス はその区別と Location フィールドの役割を定義しています。リダイレクト先は、同一オリジン上の別パスでも、別オリジンでも構いません。

恒久的に移動した古い記事には、301 が意図した関係を表現します。短期間のルーティング判断には、302 を使うことで、将来的な参照として元の URL を維持できます。ブラウザにページを離れさせたいという動機ではなく、実際に想定しているライフサイクルからステータスを選んでください。

マッピングは具体的に保ちましょう。存在しないすべての記事をホームページへリダイレクトすると、各リソースの意味が保持されません。クライアントはホームページには正常に到達できても、要求した記事の取得には失敗している可能性があります。リダイレクトを受け入れる条件の一部として、宛先のタイトルと関連する本文内容を検証してください。

メソッド保持は別個の要件

301 と 302 は、リダイレクトに従う際にユーザーエージェントが POST を GET に変更することを許可します。この歴史的な挙動は、フォームや API にとって重要です。なぜなら、リダイレクトされたリクエストが元の操作を表さなくなる可能性があるからです。リクエストメソッドにビジネス上の意味がある場合、恒久性だけで両者を選ばないでください。

307 は一時的なメソッド保持型の代替であり、308 は恒久的なメソッド保持型の代替です。メソッド保持であっても、とくにリクエストボディや認証情報が関わる場合は、宛先の検査が不要になるわけではありません。別オリジンへのリダイレクトは、セキュリティおよびアプリケーションの境界を別個に形成します。

仮想的なエクスポート送信について、クライアントが別のエンドポイントで送信を繰り返すべきか、それとも操作後に結果ページへ遷移すべきかを判断してください。これらは異なるワークフローです。303 は、ある操作の後に別のリソースを取得することを表現できます。すべてのリダイレクトステータスを単なるナビゲーション制御として同一視するのではなく、望ましいメソッドと結果となるリソースを文書化してください。

一時リダイレクトもキャッシュされうる

キャッシングは、ステータスのセマンティクス、レスポンスヘッダー、およびキャッシュに適用されるルールに依存します。 HTTP キャッシング仕様 は鮮度と保存条件を説明しています。301 は関連するルールの下でヒューリスティックキャッシュの対象となり、302 も明示的な条件が許可する場合にはキャッシュされ得ます。

キャッシュポリシーは意図的に設定してください。過度に長い鮮度期間を持つ一時的なルーティング実験は、ルーティングルールが変更された後も可視のまま残ることがあります。不整合なキャッシュ動作を伴う恒久的な移動も、クライアントごとに異なる観測結果を生む可能性があります。ステータスコードとキャッシュ設定は、整合したストーリーを伝える必要があります。

クリーンなクライアント状態と、すでにリダイレクトを観測した状態の両方でテストしてください。検査時点のレスポンスヘッダーとチェーンを記録します。異なるクライアントが異なる宛先に到達する場合、オリジンが異なるマッピングを配信していると決めつける前に、保存済みリダイレクトと中継の挙動を比較してください。キャッシングは背景ノイズではなく、証拠の一部です。

検索シグナルは意図した移動と一致させる

検索エンジンは恒久的リダイレクトと一時的リダイレクトを、優先されるURLに関する異なるシグナルとして解釈します。 Google Search redirect guidance は、サーバーサイド・リダイレクトの種類と正規化への影響を説明しています。これらのシグナルは、意図したリソース対応関係と一致している必要があります。

恒久的なサイト移転では、内部参照も更新し、一貫した移行先を公開する必要があります。新しい構造が存在する場所としてリダイレクトだけに依存しないでください。一時的なキャンペーン用の移行先には明確な終了条件を設け、短命なルールが、文書化されていない恒久ルートにならないようにします。

検索結果がいつ変わるかについて保証することは避けてください。クロールとインデックス作成は別個のプロセスであり、有効なリダイレクトがあっても、すべての検索面が即座に更新されるわけではありません。まずリダイレクトを技術的に検証し、そのうえで検索上の観測結果を、それ自体の証拠とタイミングに基づいて評価してください。プロトコルの正しさと、ランキングやインデックス結果に関する仮定は切り離して考えます。

チェーン全体と最終表現を検証する

リダイレクト検査では、元のURL、各ホップ、そのステータス、解決されたLocation値、最終URLを取得する必要があります。ループを停止し、クライアント設定でチェーン長に上限を設けてください。最終レスポンスが成功であっても、その本文がログインページやホームページ、無関係なリソースであれば十分ではありません。

相対パスの移行先は、正しいレスポンスURLに対して解決してください。関連するクエリパラメータは意図的に維持し、機密値を別のオリジンへ誤ってコピーしないようにします。すべての認証情報がリダイレクトに同行すべきだと想定してはいけません。クライアントおよび認証スキームの文書化されたセキュリティ動作に従ってください。

エンドポイントがGET以外のメソッドも受け付ける場合は、メソッド依存のケースを含めます。受信側のエンドポイントが、意図したメソッドとオペレーションを確実に受け取っているかをテストしてください。リダイレクトは、ブラウザのアドレスバー上では正しく見えても、API送信を壊すことがあります。ルーティングの仕組みだけでなく、ボディの意味も取得し、テストが実際の利用者を正しく表現するようにします。

検索データセットでURLの出自を保持する

検索データセットは、結果で観測されたURLと、その後のナビゲーションで解決された移行先のURLを区別すべきです。 Scrapeless Google Search API は構造化された検索データを提供し、その後のエンリッチメントで別のURL観測値が追加されることがあります。元のフィールドを、黙って上書きせずに保持してください。

この redirect-aware search URL contract は、リダイレクトのラッパーとパブリッシャーの移行先を、明示的に扱う必要がある理由を示しています。解釈に影響する場合は、解決時刻と結果を保存してください。解決に失敗したとしても、元の検索結果が存在しなかったことの証明にはなりません。

正規URLには、さらに別の区別が必要です。ページが宣言するcanonicalは、そのページ自身による主張であり、リダイレクト後の最終アドレスと同一とは限りません。各フィールドについて、そのソースと取得方法を保持してください。取得計画には最新の Scrapeless pricing を用い、URLエンリッチメントは、独自のカバレッジと制限を持つ別個のワークロードとして評価します。

出口戦略を含めてリダイレクトを選択・展開する

リソースが恒久的に移動した場合は301を、代替の移行先が一時的な場合は302を選び、メソッド保持は別途確認します。オペレーションでメソッドを保持する必要がある場合は、対応する308または307の動作を評価してください。キャッシュポリシーは、ロールアウト設定の一部として扱います。

URLのグループを変更する前に、マッピングの棚卸しを作成します。想定される移行先、所有者、クエリの扱い、最終コンテンツに対する受け入れチェックを含めてください。一時的なルールには、それを解除する条件を記録します。恒久的なルールでは、自身で管理できるリンクを更新し、クライアントが回避可能なホップにいつまでも依存しないようにします。

展開後のチェーンは、利用者の環境から観測してください。リバースプロキシやCDNが、アプリケーション設定には現れないリダイレクトを追加することがあります。展開済みレスポンスを意図したマッピングと比較し、代表的なパスについて証拠を保存してください。明確なロールアウト記録があれば、後のルーティングやキャッシュの不整合を説明しやすくなります。

結論

HTTP 301 と 302 のリダイレクトは、リソースの想定される恒久性に従い、メソッド保持とキャッシュポリシーは別途確認する必要があります。すべてのホップと最終コンテンツを検証してください。データパイプラインでは、観測されたURLを保持し、解決済みまたは正規URLを、それぞれの出自とともに記録することで、ルーティング変更がソースが実際に示していた内容を消し去らないようにします。

参考文献

• Google Search API structured results
• Scrapeless Google Search API
• 検索パイプラインにおけるリダイレクトURLの出自