301リダイレクトと302リダイレクトは、サイトのURLを別の場所に転送するための仕組みです。両者の違いを理解しないまま設定すると、検索結果に表示されるURLや評価の引き継ぎに思わぬ影響が出ることがあります。
この記事では、301と302の違いを実務目線で整理したうえで、.htaccessを使った具体的な書き方とエックスサーバー・WordPressでの設定方法までを通しで解説します。読み終えたときにできるようになるのは、次のとおりです。
- 301と302をどちらに使うべきかを場面ごとに判断できる
- .htaccessでドメイン単位・ページ単位・SSL化・www統一のリダイレクトを書ける
- エックスサーバー管理画面やWordPressプラグインでの設定もできる
- 設定後に「ちゃんと動いているか」を自分で検証できる
301リダイレクトと302リダイレクトの基本的な違い
301と302はどちらもHTTPの「リダイレクト」を表すステータスコードですが、伝える意味が真逆です。
301は「このURLは恒久的に移動した」、302は「このURLは一時的に別の場所に移動している」というメッセージをブラウザと検索エンジンに送ります。
301リダイレクトは「恒久的にURLを変える」とき
301は「Moved Permanently(恒久的に移動した)」を意味し、HTTPの公式仕様であるRFC 7231で定義されています。
ドメイン変更・サイトリニューアル・複数ページの統合のように、旧URLを将来にわたって使わないと言い切れる場面で使うのが基本です。
301の挙動でおさえておきたいのは、ブラウザに強くキャッシュされる性質です。一度301を設定すると、訪問者のブラウザ側に「このURLは新URLにすり替えるもの」として記録され、旧URLへ戻すのが難しくなります。
設定前に「本当に恒久的な移行か」を確認するクセを持つと安全です。
302リダイレクトは「一時的にURLを変える」とき
302は「Found(旧名 Moved Temporarily)」を意味し、こちらもRFC 7231で定義された仕様です。
メンテナンス中の一時的な迂回・A/Bテスト・キャンペーン期間中だけのページ差し替えなど、いずれ元のURLに戻すことが前提の場面で使います。
302はブラウザのキャッシュも比較的弱く、検索結果に表示されるURLも「元のURL」のまま保持されるのが特徴です。「短期間だけ別のページに飛ばしたい」というニーズに素直にマッチします。
301と302の違いを表で整理する
2つを並べてみると、性格の差がはっきりします。301と302で同じ観点を比べた一覧が以下です。
| 観点 | 301リダイレクト | 302リダイレクト |
|---|---|---|
| 意味 | 恒久的に移動した | 一時的に移動している |
| HTTPメソッド | POSTがGETに変換される | 元のメソッドを維持する |
| 検索結果のURL | 徐々に新URLへ切り替わる | 元URLが残り続ける |
| SEO評価の伝播 | 引き継がれる(現在のGoogle方針) | 引き継がれる(現在のGoogle方針) |
| ブラウザキャッシュ | 強くキャッシュされる | 比較的弱い |
| 向くシーン | ドメイン変更・統合・恒久移行 | メンテ・A/Bテスト・短期キャンペーン |
この表のうち、特に判断ミスが起きやすいのが「向くシーン」と「ブラウザキャッシュ」です。一時的な変更のつもりで301を入れてしまうと、後から戻すのに苦労します。
SEOへの影響｜古い理解と現在のGoogle方針
301と302をめぐっては、いまも古いSEO情報が現役で流通しています。実務で判断ミスをしないためにも、ここは現在の公式方針で更新しておきたいところです。
「301は評価を引き継ぐ、302は引き継がない」は古い理解
かつては「301を使うとPageRankの一部が失われる」「302はSEO評価を引き継がない」といった解説が広く流通していました。2010年代前半までのSEO書籍やブログでは半ば常識のように扱われていた説です。
ただ、この理解はすでに古く、いまの仕組みとは一致していません。
2016年からのGoogleの公式方針：30xはPageRankを失わない
2016年にGoogleのGary Illyes氏が「30x redirects don’t lose PageRank anymore(30xリダイレクトはPageRankを失わない)」と表明し、その後Search Consoleのヘルプにも「301や302のリダイレクトはPageRankの損失につながりません」という方針が明文化されています。
補足つまり、現在のGoogleの仕組みでは「301を選んだか302を選んだか」でSEO評価の伝播そのものに差が出ることは、基本的にはありません。判断軸は「評価を渡せるかどうか」ではなく、「検索結果にどちらのURLを表示させたいか」に変わっています。
差が出るのは「検索結果に出るURL」と「インデックスの扱い」
同じく評価が伝播するとしても、検索結果に出るURLは301と302で違います。301を入れると、新URLが徐々に検索結果に表示されるようになり、最終的には旧URLが姿を消していくでしょう。
逆に302のままにしておくと、検索結果には旧URLが表示され続けます。
「ドメインを変えたので今後は新ドメインで検索結果に出てほしい」のなら301、「テスト的に飛ばしているだけで、元のURLは検索結果に残しておきたい」のなら302、という選び方になります。
302を長く放置するとGoogleが「事実上の301」とみなす挙動
302を一時的なつもりで設定したまま、数ヶ月以上も元に戻さずに放置すると、Googleが「これはもう恒久的な移動だ」と解釈して、新URLを検索結果に切り替えていく挙動が複数のSEO実証実験で報告されています。
期間の具体的な目安についてGoogleの公式明言はありませんが、「302はあくまで一時利用」という前提を持っておくと安全です。
301と302のメリット・デメリットを整理
違いをふまえたうえで、それぞれのメリット・デメリットを実務目線で整理しておきます。
メリット301リダイレクトのメリット・デメリット
- メリット：新URLに完全に切り替わるので検索結果のURLもクロールも新URL中心になりやすい。サイト全体の評価を新ドメインや新URL構造に集約させやすい。
- デメリット：ブラウザキャッシュが強く、いったん設定すると簡単には戻せない。一時的な変更に誤って使うと取り返しがつきにくい。
注意302リダイレクトのメリット・デメリット
- メリット：元URLを保持できるので戻すのが簡単。メンテナンスやA/Bテストのように「いずれ元に戻す」前提のリダイレクトに向く。
- デメリット：長期で放置するとGoogleに「実質301」とみなされ、本来意図しないインデックスの入れ替えが起きる場合がある。検索結果に古いURLが残り続けるので、本格的な移行用途には不向き。
.htaccessでのリダイレクト設定の基本
ここからが実装の話です。.htaccessはApacheサーバーが読み込む設定ファイルで、サイトのルートディレクトリ(だいたいの場合 `/public_html/` 直下)に配置します。
ドメイン単位・ページ単位・ディレクトリ単位の3パターンの書き方を、それぞれ見ていきます。
編集前に押さえておきたい注意点
警告
.htaccessは構文ミスがあるとサイト全体が500エラーで表示されなくなることがあります。編集前に必ず現状の.htaccessをバックアップし、レンタルサーバーが提供する管理画面の自動バックアップ機能も活用してください。FTP直接編集よりも、エックスサーバーなどの管理画面の「.htaccess編集」機能を使うほうが事故りにくいです。
ページ単位のリダイレクト：旧URL→新URLの転送
特定の1ページを別のページに転送するときの書き方が以下です。記事の統合や移動でよく使います。
RewriteEngine on
RewriteRule ^old-page\.html$ https://www.example.com/new-page.html [R=301,L]`^` と `$` で囲んで完全一致を担保しないと、`old-page.html?param=1` や `old-page.html.bak` のような別URLまで巻き込みかねません。
`[R=301,L]` の `R=301` で301リダイレクト、`L` で「このルールが当たったら以降のルールを処理しない」を指示します。302で書きたいときは `[R=302,L]` に変えるだけです。
ドメイン単位のリダイレクト：サイト全体を別ドメインへ
ドメインを丸ごと引っ越すときの書き方です。ディレクトリ構造を変えずに移行する場合に使えます。
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.old-domain\.com$
RewriteRule ^(.*)$ https://www.new-domain.com/$1 [R=301,L]ポイントは2つです。1つ目は、ドメイン名のドットを `\.` でエスケープすること。
正規表現上ドットは「任意の1文字」を意味するので、そのまま書くと意図しないドメインまでマッチしてしまいます。
2つ目は、`^(.*)$` でパス部分をキャプチャし、新URL側の `$1` で受け取ることで、サブページのパス(`/about/`、`/blog/123/`など)を保持したまま移行できる点です。
サイトのリニューアルでドメインや構造ごと刷新する場合は、古いホームページのリニューアル時期に関する解説もあわせて確認しておくと、移行作業全体の段取りが組みやすくなります。
ディレクトリ単位のリダイレクト：特定フォルダだけ転送
「`/old-dir/` 配下のページだけ、全部 `/new-dir/` 配下に振り分けたい」というケースです。
RewriteEngine on
RewriteRule ^old-dir/(.*)$ https://www.example.com/new-dir/$1 [R=301,L]3パターンを比較表でまとめると、書き方の違いがイメージしやすくなります。下表が、ページ単位・ドメイン単位・ディレクトリ単位の構文の早見表です。
SSL化・wwwあり/なし統一・index.html正規化
サイト運営で必ず一度は通る、サイト全体に効くリダイレクトのパターンです。順番を間違えるとリダイレクトが2段3段と重なってしまうため、組み合わせに少しコツが要ります。
httpからhttpsへ強制リダイレクト
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]`RewriteCond %{HTTPS} !on` は「HTTPSで来ていないリクエストだけ」を判定するための条件です。ここを書き忘れると、https側のリクエストがまたhttpsにリダイレクトされる無限ループに陥りかねません。
エックスサーバーを使っているなら、管理画面の「SSL設定」から「サイトを常時SSL化する(httpsへの転送)」をONにすれば、同等の.htaccess記述が自動で挿入されます。
wwwあり↔wwwなしを統一する
SEO上の重複コンテンツを避けるため、wwwあり・なしは片方に揃えるのが基本です。どちらに統一するかは運用上の好みでかまいません。
「wwwなし」に統一する例が以下です。
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.example\.com$
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]逆に「wwwあり」に統一する場合は、`RewriteCond %{HTTP_HOST} ^example\.com$` のように条件を入れ替え、転送先を `https://www.example.com/$1` にします。
URL末尾のindex.htmlを消す正規化
`/about/index.html` と `/about/` は実質同じページですが、URLとしては別物として扱われ、検索エンジンの重複コンテンツ判定の対象になります。`/about/` に統一する場合の書き方が以下です。
RewriteEngine on
RewriteCond %{THE_REQUEST} ^.*/index\.html
RewriteRule ^(.*)index\.html$ https://www.example.com/$1 [R=301,L]`%{THE_REQUEST}` を使うのは無限ループを防ぐためです。`%{REQUEST_URI}` で判定するとリダイレクト後のURLが再評価されてしまい、ループに入ることがあります。
メモ設定の組み合わせ順：SSL化 → www統一 → index.html正規化、の順で.htaccessに書くのが定石です。順番を間違えると、`http://example.com/page/index.html` から `https://www.example.com/page/` まで3段リダイレクトが発生するなど、検索エンジンのクロール効率を落とす結果になります。
エックスサーバーの管理画面で設定する
エックスサーバーを使っているなら、サーバーパネルから直接.htaccessを編集できるので、FTPに触れずに済みます。基本的な「常時SSL化」「httpsへの転送」もチェック1つでONにできるため、初心者ほどこのルートを使うのが安全です。
- SSL化のリダイレクト：サーバーパネル → 「SSL設定」 → 対象ドメインを選び、「サイトを常時SSL化する(httpsへの転送)」をONにする。自動で必要な記述が.htaccessに追加される。
- カスタムリダイレクト：サーバーパネル → 「.htaccess編集」 → 対象ドメインを選び、ブラウザ上のテキストエリアでルールを追記する。「現在の.htaccess」も自動でバックアップされる。
- 反映確認：保存直後に反映される。ブラウザのキャッシュを切ったうえで対象URLを叩き、想定通りに転送されるかを確認する。
管理画面の「.htaccess編集」はバックアップが自動で残るため、書き換えで500エラーになってもひとつ前の状態に戻せます。ローカルPCにも編集前の.htaccessをコピペして保存しておけば、二重の安全策になるでしょう。
WordPressでのリダイレクト設定(Redirectionプラグイン)
WordPressサイトなら、.htaccessを直接編集せず、プラグインでリダイレクトを管理する方法もあります。実務でよく使われるのが「Redirection」というプラグインです。
Redirectionでリダイレクト管理する利点
- .htaccessに触れずGUIでリダイレクトを追加・編集できる
- 404エラーの自動追跡機能があり、リダイレクト漏れ(旧URLが404になっているページ)に気づける
- 設定をCSVでインポート／エクスポートできるためバックアップしやすい
- 301／302の切り替えも、設定画面のステータスコード選択で行える
基本的な使い方の流れ
WP管理画面の「プラグイン」 → 「新規追加」で「Redirection」を検索 → インストール → 有効化。その後「ツール」 → 「Redirection」から管理画面に入ります。
あとは「ソースURL(旧URL)」と「ターゲットURL(新URL)」を入れて保存するだけで、基本的な301リダイレクトが効きます。
.htaccessと併用するときの住み分け
プラグインだけで完結させるよりも、SSL化やwww統一のような「サイト全体に効くルール」は.htaccessに書き、「特定の個別ページ移行」だけをRedirectionで管理する住み分けが扱いやすいです。
WordPressの処理が走る前にサーバー側で完了する分、全体ルールは.htaccessのほうが軽く速く動きます。
HP保守費用とチェックポイントの解説でも触れていますが、リダイレクトの管理ルールが場当たり的になっていないか、保守の文脈で定期的に見直しておくと事故を減らせます。
リダイレクト設定でやらかしやすい失敗と回避策
リダイレクトチェーン・ループに気をつける
A→B→C→Dのように複数段のリダイレクトをつないでしまう「リダイレクトチェーン」は、可能なかぎりA→Dに直すのが原則です。段数が増えるほど検索エンジンの追跡効率が落ち、最終URLのインデックス化が遅れる可能性があります。
さらに怖いのが、A→B→Aのように一周してしまう「リダイレクトループ」です。これに陥るとサイトが開けなくなる致命的事故になります。
SSL化とwww統一を同時に設定するときに、条件指定を間違えるとよく発生します。
設定が反映されないときに見る場所
- ファイル名が `.htaccess` ではなく `htaccess.txt` のままになっている(Windowsで起こりがち)
- ブラウザに301の強キャッシュが残っている → シークレットウィンドウや別ブラウザで確認する
- 上位ディレクトリの.htaccessが先に発火している(サブディレクトリ用の記述が無視される)
- サーバー側で mod_rewrite が無効になっている(共有サーバーだとまれにある)
JavaScript・metaリフレッシュとの違い
HTMLに `` を書く方法や、JavaScriptの `location.href` で飛ばす方法も技術的には可能ですが、検索エンジンがそれらを「リダイレクト」として解釈してくれるとは限りません。可能なかぎり、HTTPヘッダーで返す.htaccess方式(または同等のサーバー側設定)を選ぶほうが安全です。
不正なリダイレクト(クローキング)は厳禁
回避
検索エンジンとユーザーで異なるコンテンツを返す「クローキング」はGoogleのスパムポリシー違反です。「Googlebotから来たときだけAページを返し、ユーザーには別の収益化ページを返す」といった設定はインデックス削除・手動対策のリスクが大きく、絶対に避けてください。
リダイレクト設定後に確認しておきたいこと
.htaccessやプラグインに書き込んだあと、本番に反映されているかを必ず自分の目で確認します。「動いている気がする」では、サイト全体がリダイレクトループで死んでいても気付けません。
ブラウザのシークレットモードで実際に踏んでみる
通常のブラウザだとキャッシュが効いて挙動が分かりにくくなるため、シークレットウィンドウから旧URLを叩きます。アドレスバーが新URLに切り替わるか、想定外のページに飛んでいないかを目で確認してください。
curlコマンドでステータスコードを確認する
ターミナルが使える環境なら、`curl -I` でレスポンスヘッダーを直接見るのが確実です。
curl -I https://www.example.com/old-page.htmlレスポンスの1行目が `HTTP/2 301` や `HTTP/1.1 301 Moved Permanently` になっていれば301、`302 Found` であれば302です。
`Location:` ヘッダーの転送先URLも合わせて確認し、想定したURLに飛ばしているかをチェックします。
Search Consoleで新URLの認識を確認する
Search Consoleの「URL検査」で新URLを検査し、インデックス登録の状況を確認します。サイトマップを更新して再送信し、新URLが含まれているかも見ておきましょう。
旧URLが検索結果から完全に消えるまでには時間がかかるので、設定直後にすべてが切り替わらなくても焦らないでください。
リダイレクトチェーンが意図せず増えていないかを点検
過去にリニューアルを何度か経験しているサイトだと、旧URL→中間URL→新URL……と知らないうちにチェーンが伸びていることがあります。
Screaming Frog SEO Spiderのようなクロールツールでサイト全体のリダイレクト構造をスキャンしておくと、不要な中間ステップを発見しやすくなります。
ドメインの管理体制と合わせて点検しておきたい方は、ドメインの有効期限管理を怠ると乗っ取られる？自動更新設定と実務チェックリストもあわせて読むと、リダイレクト設定とドメイン管理の両方を「サイト運用の盲点」として整理しやすくなります。
301・302リダイレクトのよくある質問
リダイレクト設定で迷ったら
301と302の選択や.htaccessの書き方は、1ページの移動なら自分で完結させやすい一方、ドメイン移転や大規模リニューアルのように判断ミスがそのままサイト全体の評価喪失につながる場面では、設定前にもう一段の確認をかけておきたいところです。
「.htaccessの編集に不安がある」「リダイレクトを書き換えてからサイトの調子がおかしい」といった状況であれば、お問い合わせからお気軽にご相談ください。