IT用語集 2024/12/19

リダイレクトとは？ 10分でわかりやすく解説

コラム

リダイレクトは、旧URLに来たユーザーや検索エンジンを、適切な別URLへ案内する仕組みです。実務では、まず恒久的な移転か、一時的な切り替えかを決め、その後に301 / 308 / 302 / 307 / 303のどれを使うかを選びます。通常はサーバーサイドのリダイレクトを優先し、移転先がないページまで無理にトップページへ飛ばすことは避けたほうが安全です。

判断を先にまとめると、URL変更やサイト移転のような恒久的な変更では301または308、一時的な案内や短期的な切り替えでは302または307、POST送信後に確認画面へ移す処理では303が候補になります。SEOだけでなく、ユーザーが迷わないこと、設定後に保守しやすいことまで含めて設計する必要があります。

まず決めること	選び方の目安
URL変更は恒久か	恒久なら301または308、一時なら302または307を検討する
HTTPメソッドを保持したいか	保持したいなら308または307、POST後にGETへ切り替えたいなら303を使う
どこで設定するか	原則はサーバーサイド。meta refreshやJavaScriptは代替手段として扱う
移転先が本当にあるか	対応先がないページは、無理に転送せず404エラーや410を検討する

リダイレクトとは何か

リダイレクトとは、あるURLへのアクセスを別のURLへ転送する仕組みです。ページ移転、URL整理、ドメイン変更、重複URLの統合などで使われます。単に「別ページへ飛ばす」ための機能ではなく、ユーザーと検索エンジンの両方に、どのURLを今後参照してほしいかを伝える役割があります。

サーバーサイドで行うリダイレクトは、主にHTTPの3xxステータスコードで実装します。一方で、meta refresh や JavaScript のように、HTMLやスクリプト側でページ遷移を起こす方法もあります。ただし、安定した運用を優先するなら、まずサーバーサイドで実装できるかを確認するのが基本です。

リダイレクトが必要になる場面

実務でリダイレクトが必要になる場面は、だいたい次の四つに集約できます。

場面	何を防ぐために使うか
URLの変更	リニューアルやディレクトリ変更後に、旧URLから新URLへ案内するため
ドメインやプロトコルの統一	wwwあり／なし、HTTP／HTTPSなどの分散を防ぐため
重複URLの整理	同じ内容が複数URLで見える状態を整理し、評価を集約しやすくするため
一時的な切り替え	メンテナンスや短期キャンペーン中に、利用者を別ページへ案内するため

canonicalとの違い

リダイレクトと混同されやすいのが canonical の指定です。両者は役割が違います。リダイレクトは、ユーザーもクローラーも別URLへ移動させます。これに対して canonical は、ユーザーはそのまま現在のURLを見続けたまま、検索エンジンに対して「正規URLはこちら」と伝える仕組みです。

つまり、ユーザーも旧URLを使わせたくないならリダイレクト、同じ内容を複数URLで公開せざるを得ないが検索評価は一つに寄せたいなら canonical を検討します。ここを混ぜると、URL整理がうまく進みません。

リダイレクトの種類と使い分け

実務で迷いやすいのは、「301か302か」だけではありません。HTTPメソッドを保持する必要があるか、恒久か一時か、検索エンジンにどちらのURLを主として扱ってほしいかまで含めて選ぶ必要があります。

301と308：恒久的な移転に使う

301は、ページやURLが恒久的に移転したことを示すリダイレクトです。サイト移転、URL変更、重複URLの統合など、今後も新URLを使い続ける場面で使います。検索エンジンに対しても、転送先を正規URLとして扱ってほしいというシグナルになります。

308も同じく恒久的な移転を示しますが、301との違いは、GET以外のリクエストでもHTTPメソッドと本文を保持する点です。フォーム送信やAPI通信のように、メソッド保持が意味を持つ場面では、308のほうが意図に合いやすくなります。

301：恒久移転。一般的なページ移転、URL変更、統合に向く
308：恒久移転。メソッドや本文を変えたくない恒久移転に向く

通常のコンテンツページ移転では301で足りることが多い一方、アプリケーション的な挙動まで考えるなら308も選択肢に入ります。

302と307：一時的な切り替えに使う

302は、ページが一時的に別URLに移っていることを示すリダイレクトです。メンテナンス中の案内ページ、短期キャンペーン、期間限定の導線変更など、元URLを将来的に戻す前提がある場面で使います。

307も一時的な移転を示しますが、302と違ってHTTPメソッドと本文を保持する点が重要です。GETリクエストだけを見る一般的なページでは差が見えにくくても、フォーム送信やアプリケーション処理では意味が変わります。

302：一時移転。通常の一時案内や短期切り替えに向く
307：一時移転。メソッドや本文を保持したい一時切り替えに向く

短期切り替えなのに301を入れる、恒久移転なのに302を長く使い続ける、といった運用は混乱のもとです。まず恒久か一時かを決め、その次に302か307を選ぶほうが整理しやすくなります。

303：POST後に別ページを見せたいときに使う

303 See Other は、POSTの結果として、確認ページや完了ページのような別のGETページへ誘導したいときに使います。例えばフォーム送信後に「送信ありがとうございました」の画面へ移す処理では、303のほうが意図が明確です。

303は、単純なページ移転のためのコードというより、操作結果を別ページで見せるための制御に近い位置づけです。301 / 302 / 307 / 308 と同じ文脈で雑に選ぶと、アプリケーションの挙動とずれます。

meta refreshとJavaScriptリダイレクトは代替手段

meta refresh は、HTMLの <meta http-equiv="refresh"> を使ってページ遷移させる方法です。サーバー設定を変えられない環境では使えることがありますが、通常のURL移転で第一候補にするものではありません。

JavaScript リダイレクトも、条件分岐に応じた転送には便利ですが、検索エンジンへの伝わり方や動作の安定性では、サーバーサイドより不利です。JavaScriptのレンダリングや実行に依存するため、URL移転の主手段としては最後の選択肢と考えたほうが安全です。

つまり、優先順位はおおむね次の通りです。

サーバーサイドの301 / 308 / 302 / 307 / 303
meta refresh
JavaScript リダイレクト

リダイレクトの設定方法

設定方法は、使っているWebサーバー、アプリケーション、CMSによって変わります。大事なのは、どの方法でも「転送元と転送先の対応表」を先に作ることです。先に対応関係を固めずに設定へ入ると、チェーンや漏れが増えます。

.htaccess を使う方法（Apache）

Apache を使っている環境では、.htaccess でリダイレクトを設定できます。シンプルな301の例は次の通りです。

Redirect 301 /old-page.html https://www.example.com/new-page.html

この方法は分かりやすい反面、ルールが増えるほど管理が煩雑になります。ディレクトリ単位の統一、wwwやHTTPSの統合、正規表現を使った一括処理まで含めて整理しないと、あとでチェーンや競合を起こしやすくなります。

サーバーサイドプログラムで制御する方法

アプリケーション側で条件分岐を使いたい場合は、PHP や Python などのサーバーサイド言語でリダイレクトを返す方法があります。例えば PHP なら、次のように301を返せます。

<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: https://www.example.com/new-page.php");
exit;
?>

会員状態、言語設定、公開期間などに応じて転送先を切り替える場合は、この方法が扱いやすくなります。ただし、アプリ側の条件分岐が増えるほど、予期しないループや分岐漏れも起きやすくなるため、URL設計とテストが前提です。

CMSの機能や拡張で管理する方法

CMSには、管理画面や拡張機能からリダイレクトを管理できるものがあります。編集担当が直接触れる点は利点ですが、担当者ごとに場当たりでルールを追加し始めると、重複登録やチェーンが発生しやすくなります。

CMSで管理する場合も、次の三点は外せません。

転送元URLと転送先URLの一覧を持つ
設定ルールの命名と管理責任者を決める
公開後にログと動作確認を行う

meta refresh と JavaScript の例

どうしてもサーバー側を触れない場合は、次のような方法があります。

<meta http-equiv="refresh" content="0; url=https://example.com/new-location">

<script>
window.location.href = "https://example.com/new-location";
</script>

ただし、これらは常用の標準手段ではありません。URL移転やSEOを重視する場面では、できるだけサーバーサイドへ寄せたほうが運用は安定します。

SEOと運用で外しやすい注意点

リダイレクトは設定できた時点で終わりではありません。むしろ、ここからの設計ミスで評価も運用も崩れやすくなります。

チェーンとループを作らない

A → B → C のようなリダイレクトチェーンは、表示速度にも保守性にも不利です。さらに、元URLへ戻るようなループがあると、ユーザーもクローラーも処理できません。基本は転送元から最終URLへ一回で送ることです。

サイトリニューアルのたびにルールを継ぎ足すと、古い中継URLが残りやすくなります。新しい設定を足す前に、既存ルールを整理するほうが先です。

移転先がないページをトップへ送らない

旧ページに対応する新ページがないのに、すべてトップページへ301する運用は避けたほうが安全です。ユーザーは探していた情報にたどり着けず、検索エンジンにも不自然な転送として扱われやすくなります。

対応する近いページがあるならそこへ送る。近い内容のページがないなら、404エラーや410を返す。この切り分けのほうが自然です。

HTTPS統一・www統一・内部リンク更新をセットで行う

HTTP から HTTPS へ、www あり／なしの統一を行うときは、リダイレクトだけで済ませないほうがよいです。内部リンク、サイトマップ、canonical、構造化データ、外部連携先のURLも見直して、サイト全体で同じ正規URLを参照する状態に寄せる必要があります。

リダイレクトだけで正規化を済ませようとすると、クローラーにも運用担当にも余計な負荷が残ります。

テストは「通るか」だけでなく「どこへ何回飛ぶか」を見る

設定後の確認では、「飛んだのでOK」で終わらせないことが重要です。最低でも次の点は見ておきたいところです。

転送元URLが想定した転送先へ一回で到達するか
ステータスコードが意図通りか
モバイルとPCで挙動が変わらないか
フォーム送信や会員導線で意図しない遷移が起きていないか
公開後に404やリダイレクトエラーが増えていないか

curl -I、ブラウザの開発者ツール、サーバーログ、検索エンジン向けの管理ツールを組み合わせると、チェーンや誤設定を見つけやすくなります。

大規模移行ではURL対応表が中心になる

サイト移転や大規模リニューアルでは、URL対応表を作らずに進めると、ほぼ確実に漏れが出ます。旧URLと新URLの1対1対応、統合対象、削除対象を分け、公開前にテストし、公開後はエラー監視を続ける。この流れを外さないことが重要です。

規模が大きいほど、リダイレクト設定そのものよりも、URL対応表・テスト・監視の運用設計が成否を分けます。

まとめ

リダイレクトで最初に決めるべきなのは、URL変更が恒久か一時か、そしてHTTPメソッドを保持したいかです。恒久なら301または308、一時なら302または307、POST後の確認画面へ移すなら303が基本になります。通常はサーバーサイドで設定し、meta refresh や JavaScript は代替手段として扱うほうが安定します。

また、リダイレクトはSEOのためだけに入れるものではありません。ユーザーが探していたページへ自然に到達できるか、チェーンやループがないか、移転先がないページを無理に飛ばしていないかまで含めて設計する必要があります。URL対応表、テスト、監視まで揃えてはじめて、実務で使えるリダイレクト運用になります。