301リダイレクトと302リダイレクトの違いは、URL変更が恒久的か、一時的かをブラウザや検索エンジンに伝える点です。今後は元URLへ戻さないサイト移転・URL変更・ページ統合なら301、期間終了後に元URLへ戻す案内なら302を使うのが基本です。
SEOでは、301を設定するだけで評価が自動的に同じ形で引き継がれるわけではありません。移転先との内容の対応、内部リンク、canonical、XMLサイトマップなども新URLへ統一し、サイト全体で一貫した移転シグナルを示す必要があります。
この記事では、301・302の選び方、SEO上の注意点、実装例、設定後の確認手順を解説します。
301と302の違い｜恒久的な変更は301、一時的な転送は302
元URLを廃止するなら301、再び使うなら302と判断します。どちらも訪問者を別URLへ自動転送するHTTPステータスコードですが、URL移転の性質が異なります。
| 項目 | 301リダイレクト | 302リダイレクト |
|---|---|---|
| HTTPステータス | 301 Moved Permanently | 302 Found |
| 意味 | URLは恒久的に移転した | URLは一時的に別の場所へ移っている |
| Google検索での基本的な扱い | 転送先を正規URLとして扱うためのシグナル | 元URLを検索結果に残すためのシグナル |
| 主な利用場面 | ドメイン変更、HTTPS化、URL変更、ページ統合 | 短期キャンペーン、一時的な案内、限定的な検証 |
| 元URLへ戻す予定 | 原則としてない | ある |
Google Search Centralは、301・308を恒久的なリダイレクト、302・307を一時的なリダイレクトとして案内しています。恒久的なリダイレクトは転送先を正規URLとして扱うためのシグナルになり、一時的なリダイレクトは原則としてその用途には使われません。
出典：Google Search Central「Redirects and Google Search」
301リダイレクトを選ぶケース
301リダイレクトは、旧URLを今後使わない場合に設定します。旧URLをブックマークしている利用者、外部サイトからのリンク、検索エンジンを、対応する新URLへ継続して案内するための方法です。
- サイトを別ドメインへ移転する
- HTTPからHTTPSへ恒久的に移行する
- wwwあり・なし、末尾スラッシュあり・なしを正規化する
- URL構造やWordPressのパーマリンクを変更する
- 複数ページを内容の近い1ページへ統合する
- 旧ページを対応する後継ページへ置き換える
たとえば「/service-old/」を「/service/」へ恒久移転するなら、旧ページから新ページへ301を設定します。トップページへ一律転送するのではなく、内容が最も近い移転先へ直接送ることが重要です。
302リダイレクトを選ぶケース
302リダイレクトは、元URLを将来また使う前提で、一時的に別URLを表示する場合に使います。元ページを検索結果で維持したい運用にも適しています。
- 開催期間中だけキャンペーンページへ案内する
- 一時的な障害時に専用の案内ページを表示する
- 公開前または検証中のページへ限定的に振り分ける
- 短期間だけ地域別・端末別の案内を行う
実際には元URLへ戻す予定がないのに302を長期間返し続けると、恒久移転というサイト運営者の意図が検索エンジンへ伝わりにくくなります。移転の実態が変わった時点で301への変更を検討してください。
ケース別：301・302の選び方
迷ったときは、実装方法より先に今後ユーザーに見せ続けるURLを決めます。URLを置き換えるのか、元へ戻すのかを明確にすれば、選択の大半は判断できます。
サイト移転・URL変更・ページ統合
ドメイン変更、HTTPS化、URL構造の変更、恒久的なページ統合には、基本的に301リダイレクトを使います。旧URLごとに対応する新URLを決め、できるだけ内容が近いページへ直接転送してください。
GoogleはURL変更を伴うサイト移転で、旧URLと新URLの対応表を作成し、サーバーサイドの恒久的なリダイレクトを設定することを推奨しています。移転後は、内部リンク、canonical、新しいXMLサイトマップも新URLへ更新します。
出典：Google Search Central「Site Moves and Migrations」
複数の記事を包括的な1記事へ統合した場合は、各旧記事から統合記事へ301を設定できます。一方、内容と関係のないトップページへの一律転送は、訪問者が目的の情報を見つけられず、Googleにソフト404として扱われる可能性もあるため避けてください。
メンテナンス・一時停止・キャンペーンの切り替え
一部ページを短期間だけ停止し、代替の案内ページを見せるなら302が選択肢です。たとえば予約ページの障害中だけ、復旧状況を示す案内ページへ転送し、復旧後に元ページへ戻す運用が該当します。
サイト全体や重要サービスを一時停止するメンテナンスでは、302だけでなく503 Service Unavailableも検討します。503は一時的にサービスを提供できない状態を示すHTTPステータスコードです。必要に応じてRetry-Afterヘッダーを返せば、クライアントに再試行時期の目安を伝えられます。
出典：HTTP Working Group「RFC 9110 – HTTP Semantics」
ただし、503を長期間返し続けるとクロールやインデックスに影響するおそれがあります。短期間のメンテナンスに限り、終了後は速やかに通常の応答へ戻してください。
在庫切れ・販売終了・代替商品への案内
商品ページでは、在庫状況と代替商品の関連性で判断します。再入荷予定がある商品は、商品ページを残して在庫切れ表示や再入荷通知を用意するほうが、検索経由の利用者にとって自然な場合があります。
販売終了で、用途や仕様が近い後継商品が明確にある場合は、後継商品への301を検討できます。対応する代替ページがない場合は、404または410を返し、ページ内で関連商品やカテゴリへ案内する方法も選択肢です。無関係な商品、カテゴリ、トップページへの転送は避けましょう。
301・302リダイレクトのSEO上の注意点
SEOで重要なのは番号そのものではなく、移転の実態とサイト内シグナルの一貫性です。恒久移転なら301または308、一時転送なら302または307を返し、内部リンクやcanonicalも同じURL方針にそろえます。
リダイレクトだけで正規URLが決まるわけではない
Googleは恒久的なリダイレクトを、転送先URLを正規URLとして扱うためのシグナルの一つとして使用します。ただし、Googleの正規URLの判断はリダイレクトだけで決まるものではありません。canonical、内部リンク、サイトマップ、コンテンツ内容などを総合的に参照します。
そのため、301を設定してもcanonicalや内部リンクが旧URLのままでは移転方針が一貫しません。URL移転後は、新URLをサイト内の基準に統一することが必要です。
出典：Google Search Central「How to Specify a Canonical with rel="canonical" and Other Methods」
避けたい設定ミス
リダイレクトの設定ミスは、表示遅延、閲覧不能、クロールの非効率化につながります。特に次のパターンを公開前に確認してください。
| 設定ミス | 起きる問題 | 改善方法 |
|---|---|---|
| リダイレクトチェーン | 中間URLを何度も経由し、表示が遅くなる | 旧URLから最終URLへ直接転送する |
| リダイレクトループ | 相互転送が続き、ページを開けない | http/https、www有無を含む条件を見直す |
| トップページへの一律転送 | 目的の情報に到達できない | 関連するページへ個別に転送する |
| 302の長期放置 | 恒久移転の意図が伝わりにくい | 戻さない変更なら301へ修正する |
Googleは複数段階のリダイレクトをたどることがありますが、チェーンは訪問者の待ち時間を増やします。特別な事情がなければ、中継URLを置かず最終URLへ送る設計にしてください。
出典：Google Search Central「Site Moves and Migrations」
301と302を間違えた場合の修正
設定を誤っても修正は可能です。まず、URL変更が恒久的か一時的かを再確認し、サーバー設定またはWordPress側の設定を正しいステータスコードへ変更します。
修正後は、HTTPレスポンス、転送先URL、canonical、内部リンク、XMLサイトマップを確認してください。過去に301を設定したURLを戻す場合は、ブラウザ、CDN、キャッシュプラグインに以前の応答が残ることがあります。キャッシュ削除後に複数の方法で検証すると安全です。
301・302リダイレクトの実装方法
実装場所はWebサーバー、CDN、レンタルサーバーの管理画面、CMSによって異なります。設定例のURLは説明用なので、本番環境へそのまま転記しないでください。必ずテスト環境または復旧可能な状態で確認します。
設定前にURL対応表とバックアップを用意する
設定前に、旧URL、新URL、リダイレクト種別、変更理由を一覧化します。URL数が多い移転では、対応表がないと転送漏れや重複ルールが起こりやすくなります。
| 旧URL | 新URL | 種別 | 理由 |
|---|---|---|---|
| /old-service/ | /service/ | 301 | サービスページを恒久的に刷新 |
| /campaign/ | /summer-campaign/ | 302 | 期間限定の案内先変更 |
.htaccessやNginx設定、WordPressの設定、利用プラグインのバックアップも取ります。リダイレクトの誤設定で管理画面を含むサイトが表示できなくなる場合があるため、作業前に復旧手順を決めることが大切です。
Apacheの.htaccessで設定する例
Apacheで.htaccessの利用が許可されている環境では、個別URLの転送を次のように記述できます。既存ルールとの競合を事前に確認してください。
# 301リダイレクト：恒久的なURL変更
Redirect 301 /old-page/ https://example.com/new-page/
# 302リダイレクト：一時的なURL変更
Redirect 302 /campaign/ https://example.com/temporary-campaign/正規表現や条件分岐が必要な場合はmod_rewriteを使う方法もあります。
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
RewriteRule ^campaign/?$ /temporary-campaign/ [R=302,L]設置場所や有効な記述はサーバー設定で異なります。WordPressが生成する既存のRewriteRuleブロックを不用意に変更するとパーマリンク表示に影響するため、現在の設定を確認してから追記してください。
Nginxで設定する例
Nginxでは、serverブロックやlocationブロック内でreturnディレクティブを使う方法があります。設定ファイルを編集できる権限がある場合のみ実施してください。
location = /old-page/ {
return 301 https://example.com/new-page/;
}
location = /campaign/ {
return 302 https://example.com/temporary-campaign/;
}設定ファイルの誤りはサイト全体の表示障害につながり得ます。構文チェック後に段階的に反映することを徹底し、CDNやロードバランサーにも転送設定がないか確認してください。
WordPressで設定する場合の注意点
WordPressでは、リダイレクト対応プラグイン、SEOプラグイン、テーマ機能、レンタルサーバーの管理画面などで設定できる場合があります。適切な方法は利用中の環境によって異なります。
サーバー側とWordPress側で同じURLの転送ルールを重複させると、意図しない302、チェーン、ループが発生するおそれがあります。恒久的なドメイン移転やHTTPS化では、転送ルールの管理場所を一本化することを検討してください。
設定後に確認するチェックリスト
リダイレクトは設定して終わりではありません。公開直後にステータス、転送先、サイト内URLを確認し、ユーザー導線と検索エンジンの処理に問題がないかを検証します。
HTTPステータスと転送先URLを確認する
ブラウザで旧URLを開き、意図した新URLへ移動するかを確認します。ただし、画面上で移動できても301か302かは判別できません。開発者ツールのNetworkタブやcurlで、応答ヘッダーを確認してください。
curl -I https://example.com/old-page/- HTTPステータスが意図した301または302か
- Locationヘッダーが正しい転送先を示すか
- 最終URLが200 OKを返すか
- 不要なチェーンやループがないか
- http/https、www有無、末尾スラッシュの扱いが統一されているか
内部リンク・canonical・XMLサイトマップを更新する
301を設定しても、サイト内リンクが旧URLを指し続けると、利用者とクローラーは不要な転送を通ることになります。本文リンク、ナビゲーション、パンくずリスト、構造化データ、画像URLなどを可能な範囲で更新してください。
canonicalは新URL自身を指定し、XMLサイトマップには原則として新URLだけを掲載します。旧URLをサイト内部で使い続けないことが、移転構造を明確にする基本です。
Google Search Consoleで確認する
Google Search ConsoleのURL検査ツールでは、旧URLが適切にリダイレクトされているか、新URLがGoogleに取得・インデックス可能な状態かを個別に確認できます。
ドメイン移転では旧ドメインと新ドメインの両方をSearch Consoleで管理し、必要に応じて住所変更ツールを利用します。HTTPからHTTPSへの移行に住所変更ツールは不要ですが、HTTPS側のプロパティでサイトマップとインデックス状況を確認してください。
出典：Google Search Central「Site Moves and Migrations」
307・308リダイレクトとの違い
307と308もHTTPリダイレクト用のステータスコードです。SEOの基本的な選択では、307は一時転送、308は恒久転送として考えると、302と301にそれぞれ近い位置づけになります。
| ステータス | 移転の性質 | HTTPメソッドと本文 |
|---|---|---|
| 301 | 恒久的 | 歴史的な理由から、POSTなどがGETへ変更される実装がある |
| 302 | 一時的 | 歴史的な理由から、POSTなどがGETへ変更される実装がある |
| 307 | 一時的 | 変更しない |
| 308 | 恒久的 | 変更しない |
通常のWebページ閲覧はGETリクエストが中心のため、SEO目的だけで301・302を307・308へ置き換える必要がある場面は多くありません。フォーム送信やAPIのように、リクエストメソッドの維持が必要な場合は開発担当者と相談してください。
出典：HTTP Working Group「RFC 9110 – HTTP Semantics」
301・302リダイレクトに関するよくある質問
設定や運用で迷いやすい点を補足します。ここでは、本文の手順だけでは判断しにくい変更後の運用上の疑問を扱います。
301リダイレクトは後から302へ変更できますか？
変更は可能です。ただし、301は恒久移転の意図を示すため、実際に一時的な転送だったと判明した場合に限って302へ修正します。変更後はキャッシュを削除し、HTTPステータス、canonical、内部リンクに矛盾がないかを確認してください。
301リダイレクトはいつまで残すべきですか？
サイト移転の301は短期間で削除しないことが重要です。Googleは一般に少なくとも1年間の維持を案内しており、利用者や外部リンクの観点から、可能であればさらに長く維持することが望ましいとしています。
出典：Google Search Central「Site Moves and Migrations」
JavaScriptリダイレクトやmeta refreshで代用できますか？
サーバー設定が可能なら、サーバーサイドの301・302を優先してください。HTTP応答として移転の意図を伝えられるため、ブラウザと検索エンジンが解釈しやすくなります。
Googleはmeta refreshやJavaScriptリダイレクトも処理できますが、JavaScriptはレンダリングが必要です。サーバー側を変更できない事情がある場合の代替手段として検討し、可能ならサーバーサイドリダイレクトへ移行してください。
出典：Google Search Central「Redirects and Google Search」
まとめ：URL変更の実態に合わせて301と302を選ぶ
301と302の使い分けは明確です。恒久的なURL変更なら301、一時的な転送なら302を選びます。
- ドメイン移転、HTTPS化、URL変更、ページ統合は301
- 短期キャンペーンや一時的な案内先変更は302
- 短期の全体メンテナンスでは503とRetry-Afterも検討する
- 旧URLは関連性が高い新URLへ直接転送する
- チェーン、ループ、トップページへの一律転送を避ける
- 公開後はHTTPステータス、Location、内部リンク、canonical、サイトマップを確認する
リダイレクトはSEO施策であると同時に、既存ユーザーや外部リンク経由の訪問者を迷わせないための仕組みです。変更の目的、元URLへ戻す可能性、対応する新ページを整理してから設定してください。
