URL リダイレクトの種類: 301、302、307、308 など

URL リダイレクトには 301 対 302 の議論が示す以上の種類があり、誤った選択をすると静かに速度やランキングを失うことになります。2 つのファミリーに分かれています。サーバーサイドの HTTP リダイレクトはページが読み込まれる前にサーバーが返すステータスコードです - 301、302、303、307、308。クライアントサイドのリダイレクトはページが読み込まれた後にブラウザで発生します - meta refresh タグまたは JavaScript によるホップ。サーバーサイドはユーザーとクローラーの双方にとって高速でクリーンです。クライアントサイドは低速で効果が弱く、サーバーが手の届かない場所にある場合にのみ使用します。

私はリダイレクトパスを担当しているので、具体的な内容に絞ります。各種類がネットワーク上で何を行うか、検索エンジンがどう読み取るか、そして実際にどれを使うべきか。最もよく使う 2 つの詳細については301 対 302 リダイレクトでそのペアを詳しく解説しています。この記事は全体マップです。

最初に短く結論をまとめます。恒久的な移動には 301、一時的な移動には 302、POST を維持する必要がある場合はメソッド保持型の 308/307 を追加し、サーバーを設定できない場合を除きクライアントサイドの選択肢は避けてください。

リダイレクトの 2 つのファミリー

リダイレクトとは別の場所へ移動する指示に過ぎませんが、その指示がどこにあるかによって動作のすべてが変わります。

サーバーサイドのリダイレクトは、ページコンテンツが送られる前にサーバーが「ここにはない、あちらへ」と答えるものです。ブラウザはステータスコードと Location ヘッダーを受け取り、すぐに移動します。元の URL ではコンテンツが読み込まれないため、高速で明確です。クライアントサイドのリダイレクトはその逆です。元のページが完全に読み込まれた後、初めて meta タグまたはスクリプトが訪問者を次の場所へ送ります。つまりページ読み込みの無駄、視覚的なちらつき、そして検索エンジンへの弱いシグナルが発生します。検索エンジンはリダイレクトに気づくためにページを読み込み、場合によっては実行する必要があります。サーバーサイドのコードの正式な定義は RFC 9110 にあり、実際のブラウザの動作は MDN の HTTP リダイレクトガイドに記載されています。

「ページの前か、ページの後か」というこの 1 つの区別が、この記事全体を通じて「できる限りサーバーサイドのリダイレクトを使用してください」という話に戻ってくる理由です。

HTTP ステータスコードのリダイレクト

これが本物のリダイレクトです。サーバーが 3xx の範囲で返します。重要なものは 5 つです。

表を整理する 2 つの軸は恒久性とメソッド処理です。恒久性は SEO の軸です。301 と 308 は恒久的であるため、検索エンジンはランキングシグナルを引き継ぎ、ターゲットを正規として扱います。一方 302、303、307 は一時的であり、元の URL がインデックスに残ります。メソッド処理はエンジニアリングの軸です。307 と 308 は HTTP メソッドを厳密に保持するため POST は POST のままですが、301 と 302 は歴史的に GET へのドリフトを許容してきました。303 は特殊で、フォーム送信後に GET を強制するために作られたものです。ページを更新してもデータが再送信されないようにします。Google 自身のリダイレクトドキュメントは、恒久的なコードを正規化シグナルとして扱うことを確認しています。

GET リクエストである日常的なウェブリンクにとって、メソッドの軸は消え、恒久的か一時的かの選択だけが残ります。これがまさに 301 対 302 の判断です。

クライアントサイドのリダイレクト: Meta Refresh と JavaScript

サーバーを設定できない場合、ブラウザレベルの 2 つの選択肢が残りますが、どちらも妥協です。

meta refresh はページのヘッダーにある HTML タグで、指定した遅延後に新しい URL を読み込むようブラウザに指示します。「5 秒後にリダイレクトされます」というパターンです。機能しますが、ページはすでに読み込まれてから実行されるため低速で、検索エンジンには一貫性なく読み取られます。即時の meta refresh は通常恒久的なリダイレクトとして扱われますが、遅延のあるものは曖昧でソフト 404 と読み取られる可能性があります。JavaScript リダイレクトはさらに弱く、クローラーがスクリプトを実行した場合にのみ機能します。Google は JavaScript をレンダリングしますが遅延があり、多くの他のクローラーはまったく実行しないため、リダイレクトが完全に見逃される可能性があります。

選択肢の正直なランキングは単純です。最初にサーバーサイドの 3xx、HTML は制御できてもサーバーは制御できない場合のみ meta refresh、それ以外何も制御できない場合の最終手段として JavaScript リダイレクト。これはマネージドなショートリンクには当てはまりません。ショートリンクは常にサーバーサイドリダイレクトを使用します。クライアントサイドの手法は、リダイレクト設定のない静的ホストのような状況のためのものです。

どのリダイレクトを使うべきか

1 回で判断できるよう整理します。

• 恒久的な移動、通常のリンク: 301。完全なランキング引き継ぎ、正規として扱われます。
• 一時的な移動、通常のリンク: 302。元の URL をインデックスに残し、リンクを編集可能に保ちます。
• POST または API コールを伴う移動: 恒久的には 308、一時的には 307 を使用してメソッドを維持します。
• フォーム送信後: 303、ページを更新してもフォームが再送信されないようにします。

4 つすべての背後にあるメタルール: ステータスコードを移動の実態に合わせてください - 恒久的か、そしてメソッドが重要かどうか。このペアを誤るとリダイレクトが静かにランキングを失うか、フォームを壊します。

ウェブサーバーを手動設定せずに正しく動作させたい場合は、[Elido ワークスペースを無料で開始](/pricing)してリダイレクトをリンク層に任せてください。

ショートリンクが使うリダイレクト

マネージドなショートリンクはサーバーサイドのリダイレクトです。それには十分な理由があります - 高速でクローラーフレンドリーなファミリーだからです。興味深い選択はどのコードかという点であり、ほとんどのショートリンクへの答えは 302 です。

SEO 的にはおかしく聞こえますが、ショートリンクの目的を思い出してください。302 はリンクを編集可能に保ちます。印刷や共有後でも向き先を変えられます。また毎回のクリックがサーバーに届くため、分析が正確に保たれます。どちらもハードキャッシュされた 301 では犠牲になるものです。ブラウザキャッシュの落とし穴を含む詳細な理由は301 対 302 リダイレクトにあり、エッジでのリダイレクト解決の仕組みはURL 短縮サービスの仕組みで解説しています。コードを問わず適用される 1 つのルール: ホップを 1 回に抑えること。別のリダイレクトを指すリダイレクトはクロールバジェットとレイテンシを無駄にし、ショートリンクが本来保持するSEO を最速で損なう方法です。

全体像は一文でまとめられます。本物のリダイレクトにはサーバーサイドのコード、SEO には恒久的対一時的、GET 以外のリクエストにはメソッド保持バリアント、サーバーが使えない場合のみクライアントサイドの手法。移動の実態に合わせて選び、チェーンを 1 ホップに抑えれば、リダイレクトは意図通りに機能します。

ブログの関連記事

• 301 対 302 リダイレクト: ショートリンクはどちらを使うべきか
• URL 短縮サービスは SEO に悪影響を与えるか - 正直な答え
• URL 短縮サービスの内部的な仕組み
• FRA・ASH・SGP からのリダイレクトで p95 を 15ms 以下に抑える
• URL リダイレクトのキャッシュ戦略: L1 LRU + L2 Redis
• オープンリダイレクトの脆弱性とその防ぎ方
• リダイレクトループとは：ERR_TOO_MANY_REDIRECTSの見つけ方と直し方
• URLをリダイレクトする方法：6つの選択肢と、それぞれが正しいタイミング