307 リダイレクトは SEO に影響する？Google の扱いと正しい使い分け

サイトの引っ越しや URL の変更でリダイレクトを設定するとき、気になるのは「検索結果にどう影響するのか」でしょう。とくに 307 は、301 ほど解説が多くないため、「SEO 上、使っても大丈夫なのか」「301 のほうが安全なのか」と迷う方が少なくありません。

結論を先に述べると、307 は一時的な移動を伝える番号であり、検索エンジンもそのように扱います。問題が起きるのは、307 自体が悪いからではなく、恒久的に移したいのに一時的な番号を使ってしまったときです。この記事では、Google 検索セントラルの文書に書かれている内容を軸に、307 と検索の関係を整理します。確認日は 2026 年 10 月 9 日です。

Google の扱い

307 は 302 と同等の、一時的な転送として扱われます。

検索結果の URL

一時的な転送では、移動元のページが表示されることがあります。

使い分け

引っ越しは 301 か 308、短期の案内は 307 や 302 です。

連鎖

転送を重ねすぎず、最終地点へ直接つなぎます。

番号を取り違えたときに起きること

リダイレクトの番号は、検索エンジンに対する「意思表示」でもあります。取り違えると、意図と異なる結果になります。

恒久的に移したのに、307 を使ってしまった

もっとも典型的な失敗です。ドメインを変更して、旧サイトから新サイトへ 307 を設定したとします。307 は「一時的な移動」の宣言なので、Google は旧 URL を本来の住所とみなし続けます。Google 検索セントラルの文書にも、一時的な転送では、検索結果に移動元（元のページ）が表示されると書かれています。引っ越しが完了しているのに、検索結果には旧 URL が出続ける、という状況になりかねません。

一時的な案内のつもりが、301 で固定された

逆の失敗もあります。メンテナンス中の案内として 301 を設定すると、恒久的な移動と宣言したことになります。Google の文書では、恒久的な転送では、検索結果に移動先（転送先のページ）が表示されます。メンテナンス用のページが検索結果に出てしまい、元に戻した後も、元の URL が表示されるまでに時間がかかるおそれがあります。文書も、恒久的な転送は「転送を元に戻さないと確信できるときに」使うよう助言しています。

転送が連鎖して、速度と処理に悪影響が出る

引っ越しを何度か繰り返したサイトでは、旧 URL から新 URL までに、転送が複数回連なることがあります。Google のサイト移転に関する文書は、連鎖の数を低く保つこと、理想は 3 回以内で、5 回未満にすることを助言しています。Googlebot は最大 10 回まで追えますが、連鎖が長いと利用者の待ち時間が増え、すべてのブラウザーが長い連鎖に対応するわけでもない、とされています。

方法を誤って、転送が認識されない

サーバー側で転送できないからと、JavaScript で転送する方法があります。しかし文書によれば、Google は JavaScript を実行して内容を確認しますが、描画に失敗すると、転送に気づけないことがあります。JavaScript による転送は、サーバー側の転送も meta refresh も使えない場合だけに限る、と助言されています。

こうした失敗は、番号と目的の対応を理解すれば避けられます。次の章から、Google の文書に沿って整理します。

Google は 307 をどう扱うか

Google の文書では、リダイレクトを大きく 2 種類に分けています。

種類 該当する番号 検索結果に表示される URL
恒久的な転送 301、308 移動先
一時的な転送 302、303、307 移動元（移動先が表示されることもある）

クロールに関する文書では、さらに踏み込んで、307 は 302 と同様に、308 は 301 と同様に扱うと書かれています。301 は、移動先を正規 URL として処理するための強いシグナル、302 は弱いシグナルです。したがって、307 と 302 のあいだで、検索への影響に差を心配する必要はありません。

なお、この文書や転送の解説ページには、転送が検索順位そのものにどう影響するかについての記述はありません。ここで言えるのは、検索結果に表示される URL が、転送の種類によって変わるという事実までです。

307 の強みは「一時的」を正しく伝えられること

では、検索の観点で、307 はどんな場面で役立つのでしょうか。

短期の案内に向いている

Google の文書は、一時的なサーバー側の転送を、サービスが一時的に利用できないといった短期的な状況に勧めています。このとき、元の URL が検索結果に残り続けます。たとえばメンテナンスで別のページへ案内するときや、障害時に代替の場所へ振り向けるときに、検索結果に表示される URL を変えずに対応できます。

引っ越しの試験運用に使える

サイトの引っ越しでは、いきなり恒久的な転送を公開するのではなく、一時的な転送で動作を確かめてから切り替える進め方が安全です。恒久的な転送は、ブラウザーや検索エンジンに保存されうるため、誤りの取り消しに時間がかかります。307 で検証し、問題がなければ 301 か 308 に切り替える流れなら、誤りの影響を小さくできます。

POST を扱うページでも使える

検索エンジンのクローラーは主に GET で巡回するため、検索への影響の話にメソッドの違いは出てきません。しかし、同じ URL をフォーム送信や API にも使っているサイトでは、利用者側の動作を壊さない番号を選ぶ必要があります。307 なら、検索エンジンには一時的な転送として伝わり、利用者の POST も保たれます。検索対策と機能面の両立ができる点が、307 の強みです。

サイトを移転するときの設定

サイトのドメイン変更や URL 構造の変更では、Google の文書に沿って、次の方針で進めます。

恒久的な転送を使う

サイト移転の文書は、可能であれば恒久的な転送、たとえば 301 や 308 を使うよう推奨しています。そして、サーバー側で行える場合は、サーバー側の恒久的な転送を選ぶこと、としています。

旧 URL から新 URL へ、1 対 1 でつなぐ

旧サイトの全ページをトップページに集めるのではなく、各ページを対応する新しいページへ直接つなぎます。連鎖を避けるために、旧 URL は最終的な URL へ直接転送します。

転送は長く保つ

文書は、転送をできるだけ長く、一般には少なくとも 1 年間保つよう助言しています。利用者にとっては、さらに長く保つほうが便利です。一方で、転送は表示を遅くするため、自サイトのリンクや、アクセスの多い外部リンクは、新しい URL に更新するよう勧めています。

設定後に確認する

文書は、転送が有効になってから、個別の URL はサーチコンソールの URL 検査ツールで、大量の URL はコマンドラインツールやスクリプトで確認するよう勧めています。

# 旧 URL の一覧を順に調べ、番号・転送先・回数を表示する
while read -r url; do
  curl -s -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' -L "$url"
done < old-urls.txt

このスクリプトで、想定した最終 URL に着いているか、転送の回数が多すぎないかを一覧で確認できます。

旧 URL が検索結果に残る期間

転送を設定しても、旧 URL がすぐに検索結果から消えるわけではありません。Google の文書によれば、Google は転送元と転送先の両方を把握し、一方を正規 URL、もう一方を別名として扱います。検索の内容によっては、利用者が信頼しやすい旧 URL を表示することがあり、ドメイン移転の後も、旧 URL が時折表示されることがあります。これらの別名は、特に何もしなくても、時間とともに薄れていく、とされています。

他の転送方法との関係

転送の方法は、HTTP の応答だけではありません。検索エンジンがどの方法をどう解釈するかを知っておくと、サーバーを自由に設定できない環境でも、最善の選択をしやすくなります。

Google の文書では、HTTP の転送以外の方法にも触れています。

  • meta refresh（待ち時間 0 秒）: 恒久的な転送として解釈されます。
  • meta refresh（待ち時間が 0 秒より長い）: 一時的な転送として解釈されます。
  • JavaScript による転送: 描画に失敗すると認識されないおそれがあり、他の方法が使えない場合に限ります。
  • 「移動しました」と表示するだけのページ: 転送とは認識されないことがあり、これに頼らないよう助言されています。

サーバーを設定できるなら、HTTP の転送（301・308・302・307）が最も確実です。Google の文書も、サーバー側の恒久的な転送を、目的のページに確実にたどり着かせる最良の方法として位置づけています。共用のサーバーなどで設定を変えられない場合に限って、meta refresh や JavaScript といった代替手段を検討してください。

正規化の転送は、恒久的な番号で

Google の文書は、転送を使う場面として、新しいドメインへの移転、サイトの統合、削除したページから代わりのページへの案内に加えて、同じ内容へ至る複数の入り口を減らすことを挙げています。たとえば「www あり」と「www なし」のどちらかを正規の URL に決め、もう一方からそちらへ転送する場合です。

この種の転送は、一時的なものではなく、サイトの正規の形を決める恒久的な設定です。307 や 302 ではなく、301 か 308 を選びます。http から https への切り替えも同じ考え方です。一時的な転送のまま運用すると、検索エンジンに「これは仮の転送で、元の URL が本来の住所だ」と伝え続けることになります。

移転作業のチェックリスト

最後に、サイトを移転するときの流れを、順番に整理します。

  1. 旧 URL と新 URL の対応表を作る。 各ページを、対応するページへ 1 対 1 でつなぎます。
  2. まず一時的な転送（307 など）で動作を確かめる。 パス、クエリ、転送の回数、メソッドの扱いを確認します。
  3. 問題がなければ、恒久的な転送（301 か 308）に切り替える。 切り替えたら、再度、全 URL を確認します。
  4. 自サイトの内部リンクを、新しい URL に更新する。 転送を経由せずに到達できる状態にします。
  5. 転送を、少なくとも 1 年間は保つ。 期間中も、定期的に確認します。

手順 2 と手順 3 を分けておくと、誤った転送が検索エンジンやブラウザーに保存される危険を減らせます。手順 3 のあとに、転送の対応表と実際の応答に食い違いがないかを、全件で突き合わせる作業を入れておくと、見落としがちな抜けや誤りを早い段階で見つけられます。とくに、ページ数の多いサイトでは、スクリプトによる一括確認を前提に、対応表を機械で読める形式で管理しておくと、作業の負担が大きく減ります。切り替えの日付と確認の結果は記録として残しておき、後から検索結果の表示が想定と違ったときに、設定の変更履歴をたどれるようにしておきましょう。

検索の観点での 307 の使い方

要点を整理します。

  • Google は、307 を 302 と同等の一時的な転送として、301 と 308 を恒久的な転送として扱います。
  • 一時的な転送では移動元が、恒久的な転送では移動先が、検索結果に表示されます。
  • 引っ越しなど恒久的な移動には 301 か 308、短期の案内には 307 か 302 を選びます。
  • 転送の連鎖は、理想は 3 回以内、5 回未満に抑え、旧 URL から最終 URL へ直接つなぎます。
  • 引っ越しの転送は、少なくとも 1 年間は保ちます。設定したら必ず確認します。

番号ごとの意味は301・302・303・307・308 の違いに、サーバーでの設定はnginx、Apache、PHP の各解説にまとめています。