リダイレクト設定 完全ガイド — 301/302/307の使い分け・チェーン回避・実装例とSEO最適化

リダイレクト設定とは — 概要

リダイレクト(redirect)とは、ある URL へのアクセスを別の URL に転送する仕組みを指します。ウェブサイトの構造変更、ページ移転、ドメイン変更、HTTP → HTTPS への強制など、さまざまな場面で用いられます。適切なリダイレクトはユーザー体験(UX)や検索エンジン最適化(SEO)に重要な役割を果たしますが、誤った設定や無駄なチェーン・ループは逆に悪影響を招くため、正しい理解と実装が必要です。

HTTP リダイレクトの種類(主なステータスコード)

  • 301 Moved Permanently — 永続的な移転。検索エンジンは新しい URL をインデックスするよう更新し、リンク評価(被リンクの効果)をほぼ引き継ぐとされています。長期的な移動や恒久的な正規化に使用。
  • 302 Found / 307 Temporary Redirect — 一時的な移転。302(歴史的)と 307(HTTP/1.1 での「メソッド保存」)は一時的な移動を示す。基本的に SEO 的には恒久移転ではないため被リンク評価は移転先に恒常的には移らないと考えられます。
  • 303 See Other — POST の後に GET へリダイレクトする際に使われることがある(フォーム送信後のリダイレクトなど)。
  • 308 Permanent Redirect — 301 と似ているが、HTTP メソッド(POST 等)を維持する特性がある恒久的リダイレクト。
  • 410 Gone — ページが恒久的に削除されたことを明示する。404 より速くインデックスから除外される可能性がある。

実装方法(代表的な例)

Web サーバーやアプリケーション層で実装できます。代表的な例を示します。

Apache (.htaccess / httpd.conf)

簡単な恒久リダイレクト(mod_alias):

Redirect 301 /old-page.html /new-page.html

より柔軟なルール(mod_rewrite):

RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]

Nginx

シンプルな恒久リダイレクト:

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

個別パスの例:

location = /old-page {
    return 301 /new-page;
}

PHP / アプリケーション層

// PHP の例
header("Location: /new-page", true, 301);
exit;

WordPress の例:

// functions.php など
function my_custom_redirect() {
    if (is_page('old-page-slug')) {
        wp_redirect(home_url('/new-page/'), 301);
        exit;
    }
}
add_action('template_redirect', 'my_custom_redirect');

外部リンクなどを安全に扱う場合は wp_safe_redirect を検討。

メタリフレッシュ / JavaScript

HTML の <meta http-equiv="refresh" ...> や JavaScript による location.href 書き換えでリダイレクト可能ですが、SEO やアクセシビリティの観点からはサーバーサイドの 3xx リダイレクトが推奨されます。

リダイレクトと SEO の影響・ベストプラクティス

  • 恒久移転には 301 を使う:コンテンツを恒久的に移動したときは 301 を基本にする。Google は 301 を受けた URL を新しいものに置き換える。
  • 一時的な移転には 302 / 307 を使う:元に戻す可能性がある場合は一時的なステータスを使う。
  • リダイレクトチェーンを避ける:A → B → C のような多段リダイレクトはクロール効率やページ速度に悪影響。可能な限り直接 A → C にする。
  • リダイレクトループを防ぐ:設定ミスで無限ループ(A → B → A)にならないよう注意。
  • 内部リンクは更新する:内部リンクを古い URL に残しておかず、可能な限り新しい URL に張り替える。これにより不要なリダイレクトを減らせる。
  • canonical タグは「補助」:rel="canonical" は検索エンジンへのヒントであり、リダイレクトとは異なる。恒久的に URL を変えるならリダイレクトが決定的手段。
  • 検索コンソールでドメイン移転を通知:サイト単位のドメイン移転は Google Search Console の「サイト移転」機能を活用するとスムーズ。

よくある運用例(事例)

  • HTTP → HTTPS:全ページを HTTPS に強制(HSTS を併用すると安全性向上)。
  • 非 www → www(またはその逆):正規ドメインを統一。
  • フォルダ構成変更:/products/old/ → /products/new/ のように恒久的に移した場合は 301。
  • ページ削除時:完全に削除であれば 410 を検討し、類似ページへ導くなら 301。

注意点・よくあるトラブル

  • キャッシュ:ブラウザや CDN が 301 をキャッシュするため、誤った 301 を出すと修正に時間がかかる。テストは慎重に。
  • POST データの扱い:301/302 はメソッドを変更してリクエストを GET にする挙動がブラウザで起きる場合があり、フォーム送信などでは 303/307/308 の選択を検討する。
  • オープンリダイレクト脆弱性:ユーザー入力でリダイレクト先を決める場合、検証・ホワイトリスト化を行わないと悪意ある外部サイトへ誘導される危険がある(OWASP による注意喚起あり)。
  • 相対パス/絶対パスの扱い:リダイレクト先は相対・絶対ともに指定できるが、クロスドメイン移動やスキーム変更時は完全な絶対 URL を使うと安心。

テストと確認方法

  • curl でヘッダを確認:curl -I -L https://example.com/old-page でステータスと Location ヘッダ、最終到達先を確認。
  • ブラウザ開発者ツール(Network タブ)でリダイレクトチェーンと所要時間を確認。
  • オンラインのリダイレクトチェッカーや SEO ツール(Screaming Frog、Sitebulb など)でサイト全体のルールを確認。
  • Google Search Console でインデックスの状態をチェック。大幅な移転なら Search Console の指示に従う。

実務上のチェックリスト(移転や大量リダイレクト時)

  • 1. 内部リンクと sitemap.xml を新 URL に更新する。
  • 2. 主要なページについて手動で curl / ブラウザで動作確認。
  • 3. リダイレクトチェーンがないか全ページでスキャン。
  • 4. CDN / キャッシュ設定の確認。キャッシュが残っていると古い挙動が続く。
  • 5. 外部からの重要な被リンクの所有者に可能なら更新依頼を出す(重要リンクのみ)。
  • 6. Search Console にて移転・再クロールを促す。

まとめ

リダイレクトは単純に「転送する」だけでなく、HTTP ステータスの選択、チェーンの最小化、キャッシュやメソッドの扱い、セキュリティ面の配慮などを総合的に考える必要があります。恒久移転には 301、短期的には 302/307 を使い、内部リンクの更新やテストを怠らないことが重要です。運用ミスは UX・SEO 双方に悪影響を与えるため、実装前後の確認を徹底してください。

参考文献