302リダイレクトとは？301との違い・SEOへの影響・正しい使い方を解説

302リダイレクトが意味する「一時的な転送」

302リダイレクトは、HTTPステータスコード（サーバーがブラウザに返す3桁の番号）の一つで、正式名称は「302 Found」です。サーバーが「リクエストされたページは一時的に別のURLにあります」とブラウザに伝え、ブラウザは自動的にその別のURLを表示します。

ここで押さえておきたいのは、「一時的」という点です。302リダイレクトを受け取った検索エンジンは、「この転送はいずれ解除されるだろう」と見なし、基本的には元のURLをインデックス（検索結果に表示する対象のURL）として保持しようとしますが、必ず表示され続けるわけではありません。

たとえばコンテンツとして充実している場合や、他サイトからのリンクが多く集まっている場合など、Googleが総合的に評価して新URLを正規URLとしてインデックスするケースもあります。「302＝旧URLが検索結果に残りやすいが、状況次第で新URLが選ばれることもある」と理解しておくのが正確です。

もう一つ大切なのは、Googleの公式ドキュメント「Redirects and Google Search」の説明です。同ドキュメントでは、302を含む一時的なリダイレクトについて、リダイレクト先が正規版であることを示すシグナルとしては使わないと案内されています。

この説明を要約すると、「302リダイレクトでも他の正規化シグナルがあれば新URLがインデックスされる可能性はあるが、302自体を根拠に新URLを正規URLだと強く判断するわけではない」ということです。301が「引っ越し完了の届出」だとすれば、302は「一時的な転居届」に近く、Googleは旧URLを検索結果に残しやすい状態で扱います。という理解が、現時点では最も公式説明に近いです。実務でも使えますね。

ここから導き出せる実務ルールを整理しておきましょう。

• 「いずれ元のURLへ戻る予定がある」場合に302リダイレクトを使うのが妥当です
• 「URLを永久に変更する」なら301リダイレクトを選んでおくと安心です
• 「とりあえず302リダイレクト」で長期間放置すると、Googleが意図と違う解釈をする可能性があります

では、ユーザーの目線では302リダイレクトが発動すると何が起きるのでしょうか。実はブラウザ上で体感できる変化はほとんどありません。

ユーザーが旧URLをクリックすると、ブラウザは一瞬で新URLのページを読み込み、画面にはコンテンツが表示されます。アドレスバーのURLも新しいものに切り替わります。ページが一瞬だけ白くなったり、読み込みバーが走ったりすることはありますが、ユーザーの体感としては「普通にページが開いた」のとほぼ同じです。

つまり、302リダイレクトはユーザーにとっては透明な処理であり、違いが生まれるのはあくまでブラウザと検索エンジンの裏側の扱い方です。ただし、転送先ページの内容が期待と大きくズレていると、ユーザーは「思っていたページと違う」と感じます。技術的に正しく302が返っていても、ユーザーの期待を裏切る導線になっていれば、離脱や不信感につながる点には注意が必要です。

301リダイレクトとの違いを正確に理解する

302と301の違いは、「一時的か永続的か」の一言に集約されます。ただ、SEOの実務ではこの違いが生む影響が複数あるので、整理しておきましょう。

• 301リダイレクト（永続的な転送）の場合
  Googleは新しいURLを正規URLとして扱います。元のURLが持っていた評価（リンクの信頼性など）は引き継がれやすいです。
• 302リダイレクト（一時的な転送）の場合
  Googleは旧URLを正規URLとして保持する傾向があります。

ただし前述のとおり、コンテンツやリンク状況によっては新URLが正規URLとして選ばれるケースもあります。検索結果には旧URLが表示されやすいものの、絶対ではありません。Googleは一時的なリダイレクト自体を正規化のシグナルとして使わないと案内しています。という整理です。

ここでユーザーが誤解しやすいポイントがあります。「302リダイレクトはSEO評価を失う」という情報を見かけることがありますが、正確には「評価を失う」のではなく「評価がとどまり続ける」というのが実態に近いです。302で評価がゼロになるわけではありません。ただ、本来301で転送すべき場面で302を使ってしまうと、新しいURLに評価が移らず、意図した検索結果にならないことがあります。

302リダイレクトを使うべき3つの場面

302リダイレクトが適切なのは、以下のように「元のURLに復帰前提がある」場面です。

サイトのメンテナンス中に、一時的に別ページへ誘導する場合です。メンテナンス完了後は元のURLへ戻るので、302リダイレクトが合っています。このときも、ユーザーが混乱しないよう、転送先には「現在メンテナンス中です」と分かる案内を出しておくと親切です。

A/Bテスト（2パターンのページを出し分けて効果を比較する手法）で、一時的に別バージョンのページを表示する場合です。テスト終了後は元に戻すので、302リダイレクトが適切です。検索エンジン対策だけでなく、どのパターンがユーザーにとって分かりやすいかを比較する目的でも使われます。

期間限定のキャンペーンページへ一時的にユーザーを誘導する場合です。キャンペーン終了後に元のページへ戻る想定なら302を選びましょう。特に、既存ページの評価を残しながら一時的にユーザーの導線だけ切り替えたい場面で有効です。

間違えやすい「302リダイレクトを使うべきでない」場面

反対に、以下のような場面では301リダイレクトを使うのが正解です。302リダイレクトを選ぶと、意図した通りにSEO評価が移行しない可能性があります。

ドメインを変更した場合。旧ドメインへ戻る予定がないなら301リダイレクトです。
URLの構造を永続的に変更した場合。例えばパーマリンク（記事ごとのURL）の形式を変えたときは301リダイレクトで対応しましょう。
ページを統合して、古いページを永久に廃止する場合。統合先に評価を集約したいなら301リダイレクトが適切です。
httpからhttpsへの常時SSL化。これも永続的な変更なので301リダイレクトを使います。

実務でよくある失敗は、「よく分からないからとりあえず302リダイレクトにしておこう」というパターンです。302リダイレクトのまま半年、1年と放置すると、Googleが「これは実質的に恒久移転だろう」と見なし、301リダイレクトとして再解釈することもあります。しかし、いつ・どう再解釈されるかはGoogleの解釈次第なので、最初から意図に合ったステータスコードを選んでおくのが安心です。

なぜ301リダイレクトではなく302リダイレクトを選ぶ必要があるのか

ここまで読んで「301リダイレクトの方が評価も移るし安全なら、全部301リダイレクトでいいのでは？」と思った方もいるかもしれません。しかし、一時的な転送に301リダイレクトを使ってしまうと、別のリスクが生まれます。

301リダイレクトをGoogleが受け取ると「このURLは完全に移転した」と見なし、元のURLをインデックスから外して新しいURLに評価を統合する処理を進めます。この処理が完了した後に「やっぱり元のURLに戻したい」と思って転送を解除しても、Googleにとっては元のURLが “新しいURL” として再登場したのと同じ状態になります。結果として、かつて持っていた検索順位や被リンク評価をゼロから再構築しなければならない可能性が出てきます。

一方、302リダイレクトであれば、Googleは「元のURLは一時的に留守にしているだけ」と解釈するため、元のURLの評価をそのまま保持しようとします。転送を解除して元のURLに戻したとき、評価が維持された状態でスムーズに復帰しやすいのです。

つまり、302リダイレクトと301リダイレクトは「どちらが優れているか」ではなく、「転送が一時的か永続的かという事実に合わせて使い分ける」のが正解です。

一時的な転送なのに301リダイレクトを使えば復帰時に評価を失うリスクがあり、永続的な転送なのに302リダイレクトを使えば評価の移行が不十分になるリスクがある。どちらに転んでも、実態と違うステータスコードを選んだ側が損をする構造になっています。

現場での選び方を一行にまとめると、こうなります。
「復帰前提があるなら302リダイレクトで評価を預けておく。戻さないなら301リダイレクトで評価ごと引っ越す。」

.htaccessで設定する方法（Apacheサーバーの場合）

Apache（Webサーバーソフトの一種）を使っている場合は、.htaccess（サーバーの設定ファイル）に以下のように記述します。

Redirect temp "/old-page" "https://example.com/new-page"

または、mod_rewrite（URLの書き換えモジュール）を使う方法もあります。

RewriteEngine on RewriteRule "^old-page$" "/new-page" [R=302]

設定後は、実際にブラウザで旧URLにアクセスして転送されるか確認しましょう。ブラウザの開発者ツール（F12キーで開けます）の「ネットワーク」タブで、ステータスコードが「302」になっていればOKです。

NGINXで設定する方法

NGINX（もう一つの代表的なWebサーバーソフト）の場合は、設定ファイルに次のように記述します。

location = /old-page { return 302 https://example.com/new-page; }

PHPで設定する方法

PHPを使っている場合は、ページの先頭（HTMLの出力より前）に以下のコードを記述します。

header('HTTP/1.1 302 Found');
header('Location: https://example.com/new-page');
exit();

WordPressで設定する方法

WordPressで302リダイレクトを設定したい場合は、.htaccessを直接編集する方法だけでなく、専用のプラグインを使う方法もあります。特にサーバー設定に慣れていない初心者ユーザーにとっては、管理画面から扱えるプラグインの方が導入しやすいことがあります。

ただし、プラグインで設定できることと、正しく302リダイレクトが返っていることは別です。プラグイン上で「302」を選択したつもりでも、設定の保存漏れや別のプラグインとの競合によって、意図した挙動にならないことがあります。そのため、プラグインで設定した後も、実際のレスポンスを必ず確認することが大切です。

WordPressでプラグインを使うメリットは、対象URLの追加・削除・変更を管理画面で行いやすい点です。複数の転送設定がある場合でも、プラグインなら一覧で把握しやすく、運用担当者が変わっても引き継ぎしやすいという利点があります。一方で、プラグインに頼りすぎると、どのプラグインがどの転送を管理しているのか分からなくなりやすいという弱点もあります。

また、キャッシュ系プラグインやセキュリティ系プラグインを導入しているサイトでは、リダイレクト用プラグインの変更がすぐ画面に反映されないことがあります。この場合は、プラグインの設定だけを見て安心せず、キャッシュ削除やシークレットウィンドウでの再確認が必要です。つまり、WordPressで302リダイレクトを扱うときは、プラグインの便利さと、プラグイン運用特有の注意点をセットで理解しておく必要があります。

パターン1：サイトリニューアルで302リダイレクトを使ってしまう

サイト全体のデザインやURL構造を刷新するリニューアルは永続的な変更です。にもかかわらず、「まだ微調整するかもしれないから、とりあえず302で」と一時転送にしてしまうケースがあります。

何が起きるか：旧URLと新URLの両方がインデックスに残り、Googleがどちらを正規とすべきか見極めきれない状態が続きます。こうなるとSEOにも影響が起き、検索結果に旧URLが表示されたり新URLが表示されたりと不安定になり順位が安定しません。さらに、検索結果から訪れたユーザーにとっても、「表示されたURLの印象」と「実際に見せたいページ」がズレやすくなります。リニューアルで得たかった「新しいURLへの評価集約」が進まないまま、ユーザー導線まで不安定になるのがこの失敗の厄介な点です。

現場の運用ルール：リニューアル＝戻さない＝301リダイレクト。微調整はリダイレクトではなくページ内の修正で対応する。

パターン2：http→https移行で302リダイレクトを使う

常時SSL化（httpからhttpsへの移行）は、セキュリティのための恒久的な変更です。しかし、サーバー設定のテンプレートやプラグインの初期値が302になっていることに気づかず、そのまま運用してしまう例があります。

何が起きるか：Googleがhttpsバージョンをなかなか正規URLとして認識しません。GSCで見ると、httpのURLがインデックスに残り続け、httpsのURLのインデックス登録が進まないという状態になります。サイト全体のURLに影響するため、SEOにとっても被害範囲が大きくなりやすいのが厄介な点です。

現場の判断ルール：SSL化＝戻さない＝301。設定後にすべてのURLで301が返っているか、開発者ツールで必ず確認する。

パターン3：URL変更を302リダイレクトのまま長期間放置する

パーマリンクの形式を変えた、カテゴリ構造を整理したなど、URLの恒久的な変更を302で設定し、そのまま忘れてしまうパターンです。これは前述の「とりあえず302リダイレクト」の典型例です。

何が起きるか：Googleは元のURLを正規として保持し続けるため、新URLにSEO評価が集まりません。時間が経つとGoogleが301リダイレクトと同等に再解釈する可能性はありますが、そのタイミングは予測できず、再解釈されるまでの間は順位が不安定になりがちです。さらに、旧URLが検索結果に表示され続けるため、ユーザーが旧URLをブックマークしたり共有したりする状態が長引きます。

現場の運用ルール：URL変更時に「復帰予定日」を即座に設定できないなら、それは恒久変更。最初から301リダイレクトを使う。

パターン4：canonicalタグの代わりに302リダイレクトを使う

「同じ内容のページが複数URLに存在しているので、正規URLに統一したい」という目的で、302リダイレクトを使ってしまうケースです。この場面では、本来canonicalタグで正規URLを指定するか、301リダイレクトで統合するのが正しい手段です。

何が起きるか：302は「一時的な転送」のシグナルなので、Googleは重複URLの統合ではなく「いずれ元に戻る転送」と解釈します。結果として、重複コンテンツの問題が解消されず、どのURLを正規とすべきかGoogleが迷い続けます。意図した正規化が進まないまま、複数URLのSEO評価が分散した状態が続くことになります。

現場の運用ルール：重複の正規化は「canonicalタグ」か「301リダイレクト」。302は正規化の手段ではない。

パターン5：リダイレクトチェーンの中に302が混在する

過去の設定が残ったまま新しいリダイレクトを追加した結果、A→B（302）→C（301）のように、一時転送と恒久転送が連鎖してしまうケースです。サイト運用が長くなるほど起きやすい問題です。

何が起きるか：チェーンの途中に302が含まれると、Googleは「途中で一時的な転送を挟んでいる」と解釈し、最終転送先への評価の受け渡しが不安定になります。クロールの負荷も増えるため、大規模サイトではクロールバジェット（Googleがサイトに割り当てるクロールの上限）にも影響する可能性があります。

現場の運用ルール：リダイレクトは「A→最終URL」の1段で完結させる。設定を追加する前に、既存のリダイレクトと重複・連鎖していないかを必ず確認する。

誤解1「302リダイレクトはSEO評価をすべて失う」

正しい理解：302リダイレクトでは、元のURLが引き続きインデックスされSEO評価は保持されます。「評価がゼロになる」わけではありません。ただし、新しいURLに評価を移したい場面で302リダイレクトを使うと、移行が不十分になる可能性はあります。

誤解2「302リダイレクトを長期間使っても問題ない」

正しい理解：技術的にはエラーにはなりませんが、SEO上は好ましくありません。Googleが「長期間の302は実質301だろう」と再解釈するケースがありますが、どのくらいの期間で再解釈が起きるかはGoogleから明示されておらず、こちらからはコントロールできません。元に戻る予定がなくなった時点で、速やかに301へ切り替えましょう。

誤解3「302リダイレクトと307リダイレクトは同じもの」

正しい理解：302（Found）と307（Temporary Redirect）はどちらも一時的なリダイレクトですが、HTTPの仕様上の違いがあります。302はリクエストメソッド（GETやPOSTなどの通信方法）が変更される可能性があるのに対し、307はリクエストメソッドを維持します。SEOの観点では、Googleはどちらも「一時的なリダイレクト」として同様に扱うと公式ドキュメントに記載しています。通常のWebページの転送であれば、302で問題ありません。

失敗ケース 「とりあえず302」で放置し、検索順位が崩れた

あるオウンドメディアのリニューアル案件で、カテゴリ構造の変更に伴い旧URL約50ページを新URLへリダイレクトすることになりました。制作会社から上がってきた設定が302だったのですが、当時の担当者は「リニューアル直後は微調整があるかもしれないから302のままでいい」と考えて、そのまま公開しました。

結果として、2か月ほど経ったころからGSCの平均掲載順位が目に見えて下がり始めました。変更前は主要キーワード群で平均12位台だったものが、302のまま3か月経過した時点で平均18〜19位台まで落ちていました。GSCの「ページのインデックス登録」レポートを見ると、旧URLと新URLの両方がインデックスに残っており、「重複」の警告が複数出ている状態でした。つまりGoogleが「どちらが正規URLなのか」を判断しきれず、評価が分散していたわけです。

振り返ると、「微調整があるかもしれない」は単なる心理的な保険で、実際にはURL構造を元に戻す予定はありませんでした。このとき気づいたのは、「とりあえず302」は決定の先送りであり、決定の先送りはSEO上のコストとして返ってくるということです。

改善ケース 301への切り替えで安定を取り戻した

問題に気づいた時点で、全50ページのリダイレクトを302から301に一括変更しました。

.htaccessの変更は単純で、「Redirect temp」を「Redirect permanent」に書き換えるだけです。

変更前： Redirect temp “/old-page” “https://example.com/new-page”
変更後： Redirect permanent “/old-page” “https://example.com/new-page”

切り替え後、1〜2週間はまだ旧URLがインデックスに残っていましたが、3〜4週間目あたりから新URLへのインデックス統一が目に見えて進みました。約6週間後にはGSCの平均掲載順位が13位台まで回復し、旧URLと新URLの混在による「重複」の警告も解消されました。

完全に元の12位台には届きませんでしたが、302放置中の不安定さは明らかに解消されました。順位回復の要因がリダイレクト変更だけとは断定できず、クロール頻度の変化や競合の動きも複合的に影響していると考えられます。ただ、3か月ふらつき続けた順位が、301切り替え後に安定傾向を見せたのは事実です。

1. 単一ページの一時転送

   用途：1ページだけを一時的に別ページへ転送したいとき。

   Redirect temp "/maintenance" "https://example.com/sorry"

   具体例：メンテナンス中のサービスページを「お知らせページ」へ転送する場合に使います。

2. ディレクトリごと一時転送

   用途：特定のディレクトリ配下をまとめて転送したいとき。

   RedirectMatch temp "^/campaign/(.*)" "https://example.com/special/$1"

   具体例：メンテナンス中のサービスページを「お知らせページ」へ転送する場合に使います。

3. トップページだけ一時転送

   用途：トップページのみを期間限定ページへ飛ばしたいとき。

   RewriteEngine on
   RewriteRule "^$" "/lp-summer" [R=302,L]

   具体例：夏季限定のランディングページへトップからの流入を集中させたい場合です。

4. パラメータ付きURLの一時転送

   用途：クエリパラメータ（?id=123など）を含むURLを転送したいとき。

   RewriteEngine on
   RewriteCond %{QUERY_STRING} ^id=old$
   RewriteRule "^product$" "/product?id=new" [R=302,L]

   具体例：商品IDが一時的に変わった場合、旧IDのURLを新IDのURLへ転送します。

5. デバイス判定での一時転送

   用途：スマートフォンからのアクセスだけを一時的にモバイル版へ転送したいとき。

   RewriteEngine on
   RewriteCond %{HTTP_USER_AGENT} "Mobile" [NC]
   RewriteRule "^service$" "/service-mobile[R=302,L]"

   具体例：モバイル専用ページのテスト期間中に、スマホユーザーだけを一時転送する場合です。

6. 特定の日付期間だけ転送（A/Bテスト向き）

   用途：テスト期間中だけ転送し、終了後は自動で解除したいとき。

   RewriteEngine on
   RewriteCond %{TIME} >20260401000000
   RewriteCond %{TIME}<20260415000000
   RewriteRule "^pricing$" "/pricing-test" [R=302,L]

   具体例：4月1日〜14日の2週間だけ、料金ページのテスト版を表示する場合です。

7. NGINX用の単一ページ一時転送

   用途：NGINXサーバーで1ページを一時転送したいとき。

   location = /old-page {
    return 302 https://example.com/temp-page;
   }

   具体例：NGINXで運用しているサイトのお問い合わせページを、メンテナンス中だけ別ページへ転送する場合です。

8. PHP用の一時転送（条件分岐あり）

   用途：特定の条件を満たすときだけ302転送したいとき。

   if ($is_maintenance === true) {
    header('HTTP/1.1 302 Found');
    header('Location:https://example.com/maintenance-info');
    exit();
   }

   具体例：管理画面でメンテナンスフラグをONにしたときだけ、管理側で必要な場合だけ自動で転送を発動させる場合です。

9. 多言語サイトの一時振り分け

   用途：ユーザーの言語設定に応じて一時的に別ページへ転送したいとき。

   RewriteEngine on
   RewriteCond %{HTTP:Accept-Language} ^ja [NC]
   RewriteRule "^about$" "/about-ja" [R=302,L]

   具体例：日本語ブラウザのユーザーだけを日本語版ページへ一時転送するテストを行う場合です。

10. リニューアル準備中の段階的転送

    用途：新デザインページを一部ユーザーにだけ先行公開したいとき。

    RewriteEngine on
    RewriteCond %{HTTP_COOKIE} "beta=true"
    RewriteRule "^top$" "/top-new" [R=302,L]

    具体例：Cookieに「beta=true」が設定されたテストユーザーだけを新デザインのトップページに転送する場合です。一般ユーザーには従来ページを見せつつ、一部ユーザーだけ先行体験させたいときに使えます。

ステップ1 転送の目的を明確にする

目的：「なぜ転送するのか」を言語化し、302リダイレクトが正しい選択かを判断します。

やること：「一時的な転送か、恒久的な転送か」を確認してください。

基準：「3か月以内に元のURLへ戻す予定があるなら302」「戻す予定がないなら301」が目安です。「数週間〜数か月以内に元のURLへ戻す予定があるなら302」「戻す予定がないなら301」が目安です。明確な解除予定日を設定できるなら302、期限が決められないなら301を選んでおく方が安全です。

ステップ2 旧URLと新URLを洗い出す

目的：漏れなく転送対象を把握し、リダイレクトマップ（旧URL→新URLの対応表）を作ります。

やること：スプレッドシートなどに「旧URL」「新URL」「リダイレクト種別（302）」「転送理由」「解除予定日」を一覧化します。

基準：対応表が完成し、すべての旧URLに新URLが紐づいていれば次へ進めます。

ステップ3 サーバー環境に合った方法で設定する

目的：実際にリダイレクトを設定します。

やること：.htaccess、NGINX設定ファイル、PHP、WordPressのプラグインなど、自分のサーバー環境に合った方法を選んで設定します。WordPressではプラグインで簡単に設定できる場合がありますが、プラグインの管理画面で保存しただけで安心せず、実際にどのステータスコードが返っているかまで確認しましょう。

基準：記述内容やプラグインの設定内容にミスがなく、保存・アップロードが完了していることを確認します。

ステップ4 動作確認をする

目的：設定が正しく反映されているかを確かめます。

やること：ブラウザの開発者ツール（ネットワークタブ）やHTTPステータス確認ツールで、元URLにアクセスしたときのレスポンスコードが「302」であることを確認します。

基準：ステータスコードが302であり、新URLが正しければOKです。もし「200」や「404」が返っている場合は、記述ミスの可能性があります。

ステップ5 GSCで経過を観察する

目的：リダイレクト設定後のインデックス状況を確認し、問題がないかモニタリングします。

やること：Google Search Consoleの「ページのインデックス登録」レポートで、転送元URLのステータスを確認します。「リダイレクトのあるページ」と表示されていれば、Googleがリダイレクトを認識しています。

基準：旧URLのインデックスが維持されている（一時転送として認識されている）ことが確認できれば想定通りです。転送を解除するタイミングが来たら、速やかに302設定を削除し、旧URLが正常に表示されるか確認しましょう。

いつ302リダイレクトの設定を見直すべきか

302リダイレクトは「一時的」が前提なので、定期的な見直しが必要です。以下のいずれかに当てはまったら、設定を確認しましょう。

まず、当初想定していた転送期間を過ぎている場合です。数週間の想定が数か月に伸びている、あるいは「いつ戻るか」が曖昧になっているなら、301リダイレクトへの切り替えを検討してください。Googleは「何か月で302を301と見なす」といった具体的な期間を公式に明示していないため、「期間が延びている」と気づいた時点で判断するのがSEO上の安全策です。

次に、GSCで「重複」や「インデックス未登録」の警告が出ている場合です。302が原因でインデックスが混在している可能性があります。また、A/Bテストやキャンペーンが終了した場合は、302を解除して旧URLに戻しましょう。さらに、新しいページが検索結果に表示されてほしいのに、旧URLが表示され続けている場合も見直しのサインです。

302リダイレクトの書き換え手順

1. リダイレクトマップ（旧URL→新URLの対応表）を最新化します。当初の設定時から状況が変わっていないかを確認してください。
2. 各リダイレクトが「まだ一時的か」「もう恒久的か」を確認します。恒久的なら302を301に書き換えます。不要になったなら302の記述自体を削除します。
3. 書き換え後、開発者ツールやHTTPステータス確認ツールで、期待するステータスコード（301 or 200）が返っているか確認します。WordPressのプラグインで管理している場合も同様で、管理画面上の設定表示だけで判断しないようにしましょう。
4. GSCの「URL検査」ツールで、対象URLのインデックス状況を確認します。変更後すぐに反映されるわけではないので、1〜2週間は経過観察してください。

効果測定 GSCで何を見ればよいか

302リダイレクトの設定変更後に確認すべきGSCのSEO指標は、主に3つです。

1. 表示回数です。リダイレクトの変更前後で、対象ページ（またはURL群）の検索結果での表示回数に大きな変動がないかを確認します。
2. 平均掲載順位です。302リダイレクトから301リダイレクトに変更した場合、新URLの順位が安定してくるかを数週間かけて観察します。
3. 「ページのインデックス登録」レポートです。旧URLが「リダイレクトのあるページ」から正しいステータスに変わっているか、重複の警告が解消されているかを確認しましょう。

書き換え時のNG例

やってはいけないパターンも確認しておきましょう。

• NG例1：302リダイレクトを削除しただけで、元のページが存在しない。302リダイレクトを解除した先に元のコンテンツがなければ、404エラーになります。解除前に必ず元のページが正常に表示されるか確認してください。
• NG例2：302リダイレクトから301リダイレクトに変えた直後に、またすぐ302リダイレクトに戻る。短期間でステータスコードを何度も変更すると、Googleのクローラーが混乱し、インデックスが不安定になりやすいです。変更は慎重に、一度決めたら一定期間は維持しましょう。
• NG例3：301リダイレクトに切り替えたのに、旧URLのページも残したまま放置。旧URLにコンテンツが残っていると、Googleが「どちらが正規か」を判断しにくくなります。301リダイレクトに切り替えたら、旧URLのコンテンツは削除するか、リダイレクトに任せる形にしましょう。

Q1. 302リダイレクトを設定すると、元のページのSEO評価は消えますか？

消えません。302リダイレクトでは、元のURLがGoogleのインデックスに残り続けるため、元のページの評価は維持されます。ただし、新URLに評価を移したい場合は301リダイレクトを使う必要があります。

Q2. 302リダイレクトを長期間使い続けるとどうなりますか？

Googleが「これは恒久的な移転だろう」と見なし、301リダイレクトと同様に扱い始める可能性があります。ただし、そのタイミングはGoogleの解釈次第で、こちらからコントロールできません。

意図しない形でインデックスが変わるリスクがあるため、当初の転送予定期間を過ぎたら速やかに見直すことをおすすめします。具体的な期間の基準はGoogleから明示されていませんが、数週間〜数か月が一つの目安です。設定時に「いつまでに見直すか」を決めておくのが最も確実です。

Q3. 302リダイレクトでリダイレクトチェーンが起きるとSEOに悪影響がありますか？

リダイレクトチェーン（A→B→Cのように転送が連鎖すること）が発生すると、クロールに余分な負荷がかかり、Googleが最終的なURLを正しく認識するまでに時間がかかることがあります。チェーンは最小限に抑え、できれば直接最終URLへ転送するのが望ましいです。

Q4. WordPressで302リダイレクトを設定する簡単な方法はありますか？

WordPressでは、リダイレクト管理用のプラグインを使うと、管理画面から302リダイレクトを設定しやすくなります。初心者ユーザーにとっては、.htaccessを直接編集するよりも、プラグインで管理した方が操作ミスを減らしやすい場面があります。

ただし、プラグインで設定できることと、正しく302が返っていることは別です。導入時も設定後も、開発者ツールや外部のHTTPステータス確認ツールで302が返っているか確認してください。複数のプラグインが同時にリダイレクト処理へ関わると挙動が不安定になることもあるため、不要なプラグインを増やしすぎないことも大切です。functions.phpに直接PHPコードを書く方法もありますが、運用のしやすさや再現性を考えると、まずは信頼できるプラグインを使う方法の方が扱いやすいです。

Q5. 302リダイレクトとcanonicalタグはどう使い分けますか？

302リダイレクトは「ユーザーを別のURLに転送する」処理で、canonicalタグは「このURLの正規版はこちらです」と検索エンジンに伝えるHTMLタグです。302はユーザーの目に見える転送が発生しますが、canonicalはユーザーには見えず、検索エンジンへのヒントにとどまります。一時的な転送が必要ならリダイレクト、同じコンテンツが複数URLに存在する場合の正規化ならcanonicalと覚えておくと使い分けしやすいです。

Q6. 302リダイレクトとmeta refreshの違いは何ですか？

302リダイレクトはサーバー側で処理される転送で、ブラウザがページのHTMLを受け取る前に新URLへ誘導されます。一方、meta refreshはHTMLの中に記述する転送指示で、ブラウザがHTMLを読み込んだ後に指定秒数（例：0秒や5秒）で転送を実行します。

SEOの観点では、Googleは「meta refresh（0秒）」を301リダイレクトに近いもの、「meta refresh（数秒以上）」を302リダイレクトに近いものとして扱うと公式ドキュメントに記載しています。ただし、meta refreshはサーバー側の転送と比べてGoogleの解釈が不安定になりやすく、ユーザー体験としてもページが一瞬表示されてから転送されるため違和感が生じます。リダイレクトの手段としては、サーバー側で302（または301）を設定する方が確実で、meta refreshをリダイレクトの代替手段として積極的に使う理由はほとんどありません。

Q7. プラグインで設定すれば .htaccess を触らなくても大丈夫ですか？

多くの場合、WordPressではプラグインで302リダイレクトを設定できます。そのため、必ずしも.htaccessを直接編集しなければならないわけではありません。ただし、プラグインで設定してもサーバー側の別設定と競合することはあります。大事なのは、プラグインを使ったかどうかではなく、最終的に正しい302が返っているかを確認することです。

Q8. プラグインで設定したのに302にならないのはなぜですか？

原因として多いのは、別のプラグインとの競合、キャッシュ系プラグインの影響、保存漏れ、記述済みの.htaccessルールとの重複です。つまり、プラグインを入れただけでは不十分で、プラグインの設定内容とサーバー側の実際の挙動が一致しているかを見る必要があります。