HTTPリダイレクト完全ガイド

HTTPリダイレクトとは

HTTPリダイレクト（URLリダイレクション）は、ユーザーをあるURLから別のURLに自動的に転送する仕組みです。ページをリクエストすると、サーバーが3xxステータスコードと新しいアドレスを指すLocationヘッダーで応答し、ブラウザがそのアドレスに自動的にアクセスします。

リダイレクトは多くの場面で使用されます：

• 新しいドメインへのサイト移行
• URLパス構造の変更
• HTTPからHTTPSへのアップグレード
• モバイルとデスクトップで異なるURLの提供
• URL短縮サービス（bit.ly、t.coなど）
• A/Bテストとトラフィック分割

リダイレクトの仕組み

クライアントリクエスト:
GET /old-page HTTP/1.1
Host: example.com

サーバーレスポンス:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

リダイレクトの種類

301 Moved Permanently

301は最も一般的なリダイレクトタイプです。リソースが新しいURLに恒久的に移動したことをクライアントと検索エンジンに伝えます。

SEO: 検索エンジンはリンク評価（PageRank）を新しいURLに引き継ぎ、インデックスを更新します。Googleは通常数週間以内にこれを完了します。

ブラウザの動作: ブラウザは301リダイレクトをキャッシュし、以降のアクセスで元のURLをスキップする場合があります。

302 Found（一時的）

302は一時的な移動を示します。元のURLは有効なままインデックスに保持されます。

303 See Other

303は、元のリクエストメソッドに関係なく、リダイレクト先をGETで取得するようクライアントに強制します。主にPOST送信後のフォーム再送信を防ぐために使用されます（Post/Redirect/Getパターン）。

307 Temporary Redirect

307は302と似ていますが、元のリクエストメソッドを厳密に保持します。POSTはリダイレクト後もPOSTのままです — 歴史的にメソッド変更を許容していた302とは異なります。

308 Permanent Redirect

308は301のメソッド保持版です。GETリクエストの場合、301と308の動作は同じです。リクエストメソッドを変更してはならない恒久的なリダイレクトが必要な場合に308を使用します。

クライアントサイドリダイレクト

Meta refresh

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

SEOには不向き — 検索エンジンが正しく処理できない場合があります。

JavaScriptリダイレクト

window.location.href = "https://example.com/new-page";

クローラーがJavaScriptを実行しない場合があるため、SEOには理想的ではありません。

使い分けの指針

• 恒久的なドメイン変更 → 301
• 一時的なメンテナンス → 302
• HTTP → HTTPS → 301
• www / non-wwwの正規化 → 301
• フォーム送信後 → 303
• A/Bテスト → 302
• 恒久的リダイレクト、メソッド保持 → 308
• 一時的リダイレクト、メソッド保持 → 307

SEOへの影響

リンク評価の引き継ぎ

301リダイレクトはリンク評価のほぼすべてを新しいURLに引き継ぎます。Googleは301がPageRankの約100%を引き継ぐと述べています。302は評価を引き継がず、元のURLがランキングシグナルを保持します。

インデックス更新のタイムライン

301設定後、Googleは通常：

• 数日以内にリダイレクトを発見
• 1〜4週間以内にインデックスを更新
• 1〜3ヶ月以内に評価を完全に引き継ぎ

リダイレクトチェーンの影響

チェーン内のホップが増えるたびに（A → B → C）、レイテンシが増加し評価が希薄化する可能性があります。Googleは約10ホップまでたどりますが、3を超えるチェーンは問題のサインです。常に元のURLから最終的なリダイレクト先に直接リダイレクトしてください。

よくある問題と対処法

1. リダイレクトループ

症状: ブラウザに「リダイレクトが多すぎます」と表示される。

よくある原因: CDN/オリジン間のHTTPS設定の競合、WordPressのsiteurl設定の誤り、Nginx/Apacheのリライトルールの重複、.htaccessの設定ミス。

# curlで診断
curl -I -L https://example.com

または301check.comでチェーン全体を可視化できます。

2. クエリ文字列の消失

リダイレクトルールでクエリパラメータが保持されるようにしてください。Nginxでは$request_uriまたは$is_args$argsを使用します。

3. キャッシュされた301

ブラウザは301リダイレクトをキャッシュします。リダイレクトを変更しても、ユーザーには古いリダイレクト先が表示される場合があります。プライベートウィンドウでテストするか、キャッシュをクリアしてください。

4. モバイルリダイレクトの不一致

モバイルユーザーが対応するモバイルページではなくホームページにリダイレクトされる場合は、URLマッピングを修正するか、レスポンシブデザインに切り替えてください。

ベストプラクティス

• 恒久的な変更には301を、一時的な変更には302を使用する
• 迷った場合はまず302で始める — 確定したら301にアップグレードできます
• リダイレクトチェーンを避け、最終URLに直接リダイレクトする
• リダイレクトルールでクエリ文字列を保持する
• 大規模な移行後はGoogle Search Consoleで監視する
• すべてのリダイレクトルールをドキュメント化し、チームで共有する
• 変更前後に301check.comでテストする