307一時リダイレクト

TL;DR — 307は302と同じ一時的なリダイレクトです。現在の間だけ利用者と検索エンジンを新しいURLへ送り、元のURLのランキングを新しいURLへ移すことはGoogleに伝えません。302との本当の違いは、リクエストのメソッドを変えない保証です。フォームを送信したPOSTはPOSTのままです。通常のページ間リンクでは見えない違いで、フォームやアプリでのみ重要になります。また、httpsへのアップグレードでブラウザーに表示される「307」は、実際のリダイレクトではないことがあります。

307リダイレクトとは

URLが永久ではなく、今だけ別の場所へ移動しているなら、サーバーは307 Temporary Redirectを返してブラウザーを新しい場所へ案内できます。基本的な考え方は302と同じです。一時的なので、Googleは永久リダイレクトのように元URLのランキングを新URLへ移すシグナルとは扱いません。これは弱い、正規URLを確定させないシグナルであり、元URLがランキングを保ち続けたり、永久にインデックスに残ったりする保証ではありません。メンテナンス中のページ、季節キャンペーン、後で戻す予定のページなどに一時的なリダイレクトを使います。

307と302の違い

違いは実質1つだけで、多くの人が遭遇しません。Webリクエストにはメソッドがあり、通常はページを取得するGETですが、フォーム送信のようにデータを送るPOSTの場合もあります。307はリダイレクトを追うときにブラウザーが同じメソッドを維持することを保証します。古いブラウザーは302でPOSTをGETに変えることがあり、フォーム送信を壊す可能性がありました。307は仕様によってそのリスクをなくします。 Evidence for this claim RFC 9110 defines 307 Temporary Redirect as a temporary move and requires clients not to change the request method when following it automatically. Scope: HTTP semantics for real server 307 responses, not browser-internal HSTS displays. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.8 — 307 Temporary Redirect

大半のリダイレクト、つまり誰かがページへのリンクをクリックするケースでは、どちらもGETリクエストなのでこの違いはまったく現れません。

307はSEOに悪影響があるか

ありません。Googleの公式文書は307を*“equivalent to”* (翻訳)「同等」と説明し、302と同じ扱いにしています。どちらも一時的なので、永久リダイレクト（301）のように古いページのランキングを新しいページへ移すことはありません。隠れたペナルティも隠れた加点もなく、307は302とまったく同じように処理されます。

リダイレクトではない「307」

ここが混乱の原因です。サイトがHSTSというセキュリティ機能でhttpsを強制すると、http版のページを開いたとき、ブラウザーの開発者ツールに「307」と表示されることがあります。サーバーが送ったものではなく、ブラウザーが自分で安全な版へ直接移動したことを説明するために作った表示です。0バイトのレスポンスになることも、その手掛かりです。

監査ツールやブラウザーが突然307を報告しても、サーバーの設定ミスだと慌てないでください。通常は新しいシークレットウィンドウでブラウザーが学習したHSTS状態を避け、実際のステータスコードを確認できます。ただし、ブラウザー内蔵のHSTS preload リストに載るドメインでは、シークレットウィンドウでも状態を消せません。サーバーが実際に返す内容を見るには、リダイレクトチェッカーかcurlリクエストのほうが確実です。

仕様の文言、John Muellerの発言、HSTSの仕組みの詳細、そして実際に307を返す方法を知りたいなら、Advancedタブへ進んでください。

TL;DR — 307はRFC 9110に従う一時的なリダイレクトで、“MUST NOT change the request method.” (翻訳)「リクエストメソッドを変更してはならない」という302にはない厳格な保証があります。SEO上は動きがなく、Googleの文書では*“Equivalent to 302”* (翻訳)「302と同等」という弱い一時シグナルです。Muellerも307と302の選択は*“doesn’t really matter”* (翻訳)「実際には重要ではない」と述べており、差が出るのはPOSTやAPIのトラフィックを正しく扱う必要があるかどうかです。実際に混乱を招く307はHSTSのブラウザー内アーティファクトで、サーバーが送っていない0バイトの「リダイレクト」です。httpをhttpsへブラウザーが自動更新したときに作られます。この2つの機能的に無関係なケースを分けることがこの記事の中心です。

307にはまったく異なる2つのケースがある

以下を整理する軸は、私のステータスコードガイド から直接導いたものです。そこでは307に2つの別々の項目があります。“307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (翻訳)「307 Temporary Redirect — 302リダイレクトと同じ機能だが、POSTとGETを切り替えられない」と、“307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP.” (翻訳)「307 HSTS Policy — HTTPではなくHTTPSでリクエストするようクライアントに強制する」です。同じ番号を共有するだけで、ほかはほとんど別物です。

1. 実サーバーが発行する一時的な307 — 非GETリクエストでHTTPメソッドとボディを保つために意図的に選ぶ、またはフレームワークが既定値として選ぶものです。
2. HSTSによるブラウザーアーティファクトとしての307 — サーバーレスポンスではありません。ブラウザーがhttpをhttpsへ内部的に更新し、その更新に307というラベルを付けます。

この2つを混同することが、307をめぐる混乱の最大の原因です。ここから1つずつ見ていきます。

ケース1：実際の307 — 仕様が要求すること

RFC 9110（現在のHTTPセマンティクス仕様）§15.4.8の文言は明確です。

“The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (翻訳)「307（Temporary Redirect）ステータスコードは、対象リソースが一時的に別のURIに存在することを示し、ユーザーエージェントは自動リダイレクトを行う場合にリクエストメソッドを変更してはなりません。」

この*“MUST NOT”* (翻訳)「変更してはならない」は提案ではなく、厳格な要件です。307が解決するために作られた歴史的な302の混乱を、§15.4.3の記述と比べてください。“For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (翻訳)「歴史的な理由から、ユーザーエージェントは後続リクエストでPOSTからGETへメソッドを変更してもよい。この動作が望ましくない場合は、代わりに307（Temporary Redirect）を使える」と書かれています。つまり307は、古いクライアントが302で持っていたPOST→GETの曖昧さをなくすために存在します。

MDNは同じ違いを実用的に説明しています。

“The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET. 307 and 302 responses are identical when the request method is GET.” (翻訳)「307と302の違いは、リダイレクト後のリクエストでクライアントがメソッドとボディを変更しないことを307が保証する点です。302では古いクライアントが誤ってメソッドをGETに変更しました。リクエストメソッドがGETなら、307と302のレスポンスは同一です。」

最後の文がSEOにとって最も重要です。SEO担当者が扱うリダイレクトのほとんど、つまり古いページを新しいページへ移すケースはGETリクエストであり、GETでは307と302は文字どおり同一です。メソッド維持の保証が効くのは、メソッドがGETではない場合だけです。フォームの再送、APIエンドポイント、Webhookの宛先、決済や認証のPOST引き継ぎなどが該当します。仕様が保証するのはメソッドとボディであり、リプレイ時のヘッダー、資格情報、クロスオリジンリクエストの扱いまで自動的に決めるわけではありません。実際のクライアントで確認し、バイト単位の動作を思い込まないでください。通常のページ移動で2つのコードを比較する場合は、専用の302と307の記事で詳しく扱っています。この記事は一時リダイレクトの基本を知っている前提で、307固有の点に集中します。

302・303・307を1つの表で比較

3つともRFCの「一時的」な分類に入りますが、重要な2軸、つまりメソッド維持とキャッシュでは同じ動作をしません。

3つとも既定ではヒューリスティックにキャッシュ可能ではありません。307（302や303と同様）をキャッシュが再確認なしに保存するには、Cache-ControlやExpiresなど明示的な鮮度シグナルが必要です。

ケース1・続き：Googleは実際の307をSEO上どう扱うか

短く言えば、302とまったく同じです。Googleの*“HTTP Status Codes”* (翻訳)「HTTPステータスコード」文書では307の行を*“Equivalent to 302”* (翻訳)「302と同等」とし、307が引き継ぐ302の行は次の意味を説明しています。

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (翻訳)「既定ではGoogleのクローラーがリダイレクトに従い、Googleのシステムはリダイレクトを、対象を処理すべきだと示す弱いシグナルとして使います。」

「弱い」が重要な語です。一時的なリダイレクトは、永久リダイレクトのように対象へ正規化を集約しません。Googleの*“Redirects and Google Search”* (翻訳)「リダイレクトとGoogle検索」文書は302、303、307を「temporary」としてまとめ、動作を直接説明しています。“Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (翻訳)「Googlebotはリダイレクトに従うが、インデックス処理パイプラインは対象を正規URLにすべきだというシグナルとしてリダイレクトを使わない」としています。同じページは、“If you just want to send users to a different page temporarily, use a temporary redirect.” (翻訳)「利用者を一時的に別ページへ送るだけなら、一時的なリダイレクトを使う」と説明します。

307と308の行の直後に、Googleは壁に刻んでおきたい注意書きを加えています。

“While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (翻訳)「Googleはこれらのステータスコードを同じように扱うが、意味は異なることを覚えておく必要がある。ほかのクライアント（電子書籍リーダーや別の検索エンジンなど）が恩恵を受けられるよう、リダイレクトに適したステータスコードを使うべきだ。」

Googleはランキング上は307と302を同じ箱に入れますが、意味に合うコードを選ぶようにも求めています。SEOについての答えはこれに尽きます。 Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search John MuellerはSearch Off the Record第51回「Let’s talk redirects」でさらに率直に、“with 307, 308, it also forwards POST requests” (翻訳)「307と308ではPOSTリクエストも転送される」と説明しました。301/302がGETリクエストを転送するのとは対照的です。そして結論として次のように述べています。

“I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (翻訳)「SEOでは実際には重要ではないと思う。むしろ、APIで機能するかどうかだ。通常、APIは検索に直接インデックスさせる必要があるものではない。」

一時的なリダイレクトを307へ変えても、ランキング上の利点はありません。選ぶ正当な理由はメソッドとボディの維持、または後述する一般的な将来対応の好みだけです。

ケース1・続き：フレームワークとCDNの既定値

「なぜ307なのか」という質問の多くは、意図的な選択ではなくフレームワークの既定値です。Next.jsのredirect()関数は307を既定値にしており、見出しそのものが*“Why does redirect use 307 and 308?”* (翻訳)「なぜredirectは307と308を使うのか」となっています。文書は理由を、“The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests.” (翻訳)「redirect()メソッドは302の一時リダイレクトではなく、既定で307を使うため、リクエストは常にPOSTとして保持される」と明記します（Next.jsはServer Actions内では303を使い、308については別のpermanentRedirect()を提供します）。自分で307を書いていないのに見えるなら、フレームワークやエッジプラットフォームが非GETリダイレクトに既定で使っていないか確認してください。通常はそれが理由で、正しい動作です。

ケース2：サーバーが送っていないHSTSの「幻の307」

ここは十分に説明されておらず、専用の307記事が価値を持つ領域です。サイトがStrict-Transport-Security（HSTS）ヘッダーを送ると、ブラウザーに「これからは常にhttpsだけで読み込む」と伝えます。次にhttp版へリクエストすると、ブラウザーはサーバーと通信せず自分でhttpsへ更新し、その内部更新を開発者ツールやクローラーに「307」と表示します。

John Muellerは自身のサイトでこの仕組みを説明しました。

“After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page. Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (翻訳)「HSTSヘッダー付きのHTTPS URLを見た後（例えばHTTP版からのリダイレクトを通じて）、次にHTTPページへアクセスするとChromeは307リダイレクトを見ているように動作する。サーバーは307を返しておらず、Chromeが自分のためにリダイレクトしていることを説明するためにそう表示しているだけだ。」

0バイトのボディが手掛かりです。Muellerも、“the 307 isn’t actually a redirect at all, it’s just a placeholder.” (翻訳)「307は実際にはリダイレクトではなく、単なるプレースホルダーだ」と加えています。私のリダイレクト ガイド は監査上の実務的な結論を、“When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code.” (翻訳)「WebサーバーがクライアントにHTTPS接続だけを要求する場合（HSTSポリシー）、ブラウザーにキャッシュされるためGoogleは307を見ない。キャッシュなしの最初のアクセスでは、おそらく301または302のサーバーレスポンスになる。しかしブラウザーは後続リクエストで307を表示するため、トラブルシューティングが難しくなる。返されたステータスコードを見るには新しいシークレットセッションが必要だ」と説明しています。

HSTSについてGooglebotが実際に見るもの（そして変化した経緯）

5年離れたGoogleの2つの発言を一緒に読む価値があります。2015年12月、当時GoogleにいたZineb Ait BahajjiはSearch Engine Roundtable 経由で、“With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (翻訳)「HSTSを実装するとGooglebotは301リダイレクトを見る（Fetch as Googleで試せる）。307は単なる『内部リダイレクト』だ」と述べました。2020年10月、MuellerのAsk Google Webmasters動画（Search Engine Journal 経由）の表現は少し違い、“In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (翻訳)「要するに、[Googlebot]はそれらとやり取りしない。307リダイレクトは通常、本物のリダイレクトではない」としました。いずれにせよ、クローラーは人間が開発者ツールで見る同じ「307」を見ていません。Fetch as GoogleがURL Inspectionに置き換えられるなど、ツールとクロール基盤は変わりましたが、HSTSの場合にサーバー発行の本物の307はないという点は少なくとも10年間変わりません。2020年の発言を現行指針として扱い、2015年の発言は有用な歴史として扱ってください。

実務上の重要な結論は、HSTSはブラウザーの利便性であってクロール発見の仕組みではないということです。クローラーにもhttp→httpsの経路を機能させたいサイト所有者は、本物のサーバー側リダイレクト（実際の301）を用意し続ける必要があります。

Bingは307をどう扱うか

率直に言えば、文書上の空白があります。Bingが307という名前、またはHSTSによる307を具体的に扱う公開声明は見つかりませんでした。Bingのリダイレクトガイダンス（2011年の*“Managing redirects – 301s, 302s and canonicals”* (翻訳)「リダイレクトの管理 — 301、302、正規URL」記事と、2020年の*“Website Migration with Bing”* (翻訳)「Bingを使ったウェブサイト移行」記事）は301/302の永久・一時の分離だけを扱い、307、308、HSTSには触れていません。したがってGoogleと同じだと仮定せず、Bingは307について公開の具体的説明をしていないとそのまま扱うべきです。現象自体は検索エンジンに関係なく実在し、クローラーにも関係します。Screaming FrogのSEO SpiderがHSTSがクロールに影響するため*“Respect HSTS Policy”* (翻訳)「HSTSポリシーを尊重」トグルを備えているのはそのためですが、これはBingの声明ではなくツールの文書です。

307を意図的に選ぶ場面

元のメソッドやボディを失うと動作が壊れる場合は、302ではなく307を選びます。

• APIエンドポイントとWebhookの宛先 — POST/PUT/PATCHを受け取るもの。
• フォーム送信（POST）の流れ — 処理後にリダイレクトするもの。
• 決済／ログインのPOST引き継ぎ — ホスト間で処理を渡すもの。
• ボディを持つリクエスト全般 — 失う余裕がないもの。

通常のページ間移動では、302と307はGoogleにとって区別できないため、SEOの観点ではどちらでも構いません。このメソッド維持ロジックの永久版を扱うなら、301と308の関係になります。307が302に対応するように、308は301に対応します。

私のリダイレクト ガイド で示した好みは、「どちらでもよい」という一般的な説明より踏み込んでいます。“my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” (翻訳)「私の好みの順序は307 / 302 / 303 ＞ Meta refresh 0 / HTTP refresh 0」です。一時的な選択肢では307を先頭に置いています。一貫して使えば、メソッド維持の面では常に安全になるという、Muellerの「完全性」に近い考え方です。どれを選んでも、本物の307（またはHSTSアーティファクト）が長いリダイレクトチェーンの1ホップにならないよう注意してください。余分なホップは遅延と効率低下を生みます。

AI要約

Advanced版の要約です。

• 307には無関係な2つのケースがあります。 (1) HTTPメソッドとボディを維持する、サーバー発行の本物の一時リダイレクト、(2) ブラウザーがhttpをhttpsへ自動更新したときに作る、サーバーが送っていない0バイトのHSTS アーティファクトです。この2つを分けることが中心です。
• ケース1 — 仕様上の保証： RFC 9110は307が、 “MUST NOT change the request method.” (翻訳)「リクエストメソッドを変更してはならない」と述べます。MDNは*“307 and 302 responses are identical when the request method is GET”* (翻訳)「リクエストメソッドがGETなら307と302のレスポンスは同一」と補足しており、重要なのはPOST/PUT/PATCH（フォームやAPI）だけです。保証対象はメソッドとボディで、リプレイ時のヘッダー、資格情報、クロスオリジンの処理はクライアントに依存します。
• 302・303・307： 302は歴史的にはPOSTからGETへ変えられることがあり、303は対象をGET/HEADで取得し、307はメソッドを変えてはなりません。3つとも既定ではヒューリスティックにキャッシュされません。
• SEOの答え： Googleの文書は307を*“Equivalent to 302”* (翻訳)「302と同等」とし、対象へ正規化を集約しない弱い一時シグナルと説明します。MuellerのSEO上の答えは*“it doesn’t really matter”* (翻訳)「実際には重要ではない」で、実際の問いは*“does it work for APIs”* (翻訳)「APIで機能するか」です。
• フレームワークの既定値： Next.jsのredirect()は307（Server Actions内は303、permanentRedirect()は308）を既定にしてPOSTを保ちます。意図しない307のよくある原因ですが、通常は正しい動作です。
• ケース2 — HSTS： ブラウザーは0バイトの307を表示しますが、実サーバーのコードは通常301または302です。Googlebotはその307を見ません（Mueller 2020の*“doesn’t interact with them”* (翻訳)「それらとやり取りしない」、Zineb 2015の*“sees a 301”* (翻訳)「301を見る」）。http→httpsには本物のサーバー側301が必要です。リダイレクトチェッカーかプレーンなcurlで監査してください。新しいシークレットウィンドウでも通常は確認できますが、内蔵HSTS preloadリストのドメインでは使えません。
• Bing： 307固有の公開声明はなく、Googleとの同等性を示す文書上の根拠もありません。
• 好み： 307へ変えるランキング上の理由はありません。将来のメソッド維持を考え、私の順序では一時的な選択肢の先頭に307を置いています。

公式ドキュメント

一次資料と仕様です。

Google

• “HTTP Status Codes, Network and DNS Errors, and Google Search” (翻訳)「HTTPステータスコード、ネットワーク・DNSエラー、Google検索」 — 「307 (temporary redirect) — Equivalent to 302」の行、302の「弱いシグナル」という文言、意味は異なるという注意書きを確認できます。
• “Redirects and Google Search” (翻訳)「リダイレクトとGoogle検索」 — 302/303/307を「temporary」としてまとめ、対象を正規URLにするシグナルとしてリダイレクトを使わないと説明します。

Bing / Microsoft

• “Managing redirects – 301s, 302s and canonicals” (翻訳)「リダイレクトの管理 — 301、302、正規化」 — Bingのリダイレクトガイダンス（301/302のみで、307/HSTSへの言及はありません）。
• “Website Migration with Bing” (翻訳)「Bingでのサイト移行」 — 移行ガイダンスも301/302のみです。

HTTP仕様

• “RFC 9110 §15.4.8 — 307 Temporary Redirect” (翻訳)「RFC 9110 §15.4.8 — 307一時リダイレクト」 — “MUST NOT change the request method.” (翻訳)「リクエストメソッドを変更してはなりません。」
• “RFC 9110 §15.4.3 — 302 Found” (翻訳)「RFC 9110 §15.4.3 — 302発見」 — 307を参照する歴史的なPOST→GETの説明です。

技術リファレンス

• “MDN — 307 Temporary Redirect” (翻訳)「MDN — 307 Temporary Redirect」 — メソッドとボディの維持、およびGETでは同一の動作を説明します。

フレームワーク

• “Next.js — redirect() function reference” (翻訳)「Next.js — redirect()関数リファレンス」 — 「Why does redirect use 307 and 308?」FAQ、既定値が307（Server Actions内は303）であることを確認できます。

クローラーツール

• “Screaming Frog — An SEO’s Guide To Crawling HSTS & 307 Redirects” (翻訳)「Screaming Frog — HSTSと307リダイレクトのクロールガイド」 — 「Respect HSTS Policy」設定とHSTSの仕組みを扱います。

出典からの引用

記録に残る発言です。各リンクは、引用箇所またはその箇所を記録したページへ移動します。

Google文書 — SEO上の扱い

• “307 (temporary redirect) — Equivalent to 302.” (翻訳)「307（一時リダイレクト）— 302と同等。」 — Google Search Central、“HTTP Status Codes, Network and DNS Errors, and Google Search” (翻訳)「HTTPステータスコード、ネットワークとDNSエラー、Google検索」。 引用箇所へ
• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (翻訳)「既定ではGoogleのクローラーがリダイレクトに従い、Googleのシステムは対象を処理すべきだと示す弱いシグナルとして使う。」（307が引き継ぐ302の行） 引用箇所へ
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (翻訳)「Googleは同じように扱うが意味は異なる。ほかのクライアントも恩恵を受けられるよう適切なコードを使うべきだ。」 引用箇所へ
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (翻訳)「Googlebotはリダイレクトに従うが、インデックス処理パイプラインは対象を正規URLにすべきというシグナルとして使わない。」 — Google Search Central、“Redirects and Google Search” (翻訳)「リダイレクトとGoogle検索」。 引用箇所へ

HTTP仕様／MDN — 技術上の保証

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (翻訳)「307（Temporary Redirect）は対象リソースが一時的に別URIにあることを示し、自動リダイレクト時にユーザーエージェントはメソッドを変更してはならない。」 — RFC 9110 §15.4.8。 節を読む
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (翻訳)「歴史的な理由から、後続リクエストでPOSTからGETへ変更してもよい。この動作が望ましくなければ307を使える。」 — RFC 9110 §15.4.3（302の節）。 節を読む
• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made… 307 and 302 responses are identical when the request method is GET.” (翻訳)「307はリダイレクト時のメソッドとボディを変更しないことを保証し、リクエストがGETなら307と302のレスポンスは同一である。」 — MDN、307 Temporary Redirect。 引用箇所へ

John Mueller、Google — SEOとメソッド維持

• “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (翻訳)「SEOでは実際には重要ではない。APIで機能するかどうかであり、通常APIを検索へ直接インデックスさせる必要はない。」 — Search Off the Record第51回「Let’s talk redirects」（2022年11月17日）。 文字起こしPDF
• “And with 307, 308, it also forwards POST requests” (翻訳)「307と308ではPOSTリクエストも転送される」（301/302はGETリクエストを転送）。 — 同じ回。

John Mueller、Google — HSTSの「幻の307」

• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (翻訳)「サーバーは307を返しておらず、Chromeが自分のためにリダイレクトしていると説明するためにそう表示しているだけだ。307は実際にはリダイレクトではなく、単なるプレースホルダーだ。」 — John Mueller、HTTPS & HSTS: 301, 302, or 307?（johnmu.com、元Google+、2016年6月）。 引用箇所へ
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (翻訳)「要するに、[Googlebot]はそれらとやり取りしない。307リダイレクトは通常、本物ではない。」 — John Mueller、Ask Google Webmasters（2020年10月、Search Engine Journal経由）。 引用箇所へ

Zineb Ait Bahajji、Google — HSTS、2015年（伝聞）

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (翻訳)「HSTSを実装するとGooglebotは301リダイレクトを見る（Fetch as Googleで試せる）。307は単なる『内部リダイレクト』だ。」 — Zineb Ait Bahajji（Google）、Search Engine Roundtable経由（2015年12月）。 引用箇所へ

今見ている307はどれか

307に関する質問のほぼすべては、まったく異なる2つのもののどちらかに行き着きます。順に確認しましょう。

避けるべき神話と誤り

「307は302のようにリンク評価を渡さない。」 これは「307は302より悪い」という見方としては誤りで、主要なSEOブログにも広がっています。Googleの公式文書は307と302を同じように処理し、どちらも正規化しない「弱いシグナル」の一時的なリダイレクトとしています。Googleの*“HTTP Status Codes”* (翻訳)「HTTPステータスコード」文書も307を*“Equivalent to 302”* (翻訳)「302と同等」と明記しています。307だけが302より少なく評価を渡すという文書上の根拠はありません。Googleが示しているのは、一時リダイレクト全般が永久リダイレクトのようにランキングシグナルを対象へ集約するためのものではないという点です。「307だけが評価を保留する」という主張に押されて、不要な変更をしないでください。

「Networkタブの307は、サーバーがリダイレクトを誤設定した証拠だ。」 多くの場合は誤りです。HSTSが有効で、ブラウザーが以前Strict-Transport-Securityヘッダーを見ていると、http→httpsの更新を自分の説明として307と表示します。サーバーはそれを返しておらず、0バイトのボディが手掛かりです。通常は新しいシークレットウィンドウで実際のコードを見られますが、ブラウザー内蔵のHSTS preloadリストのドメインでは確認できません。その場合は、設定ミスを探す前に、HSTS未設定のリダイレクトチェッカーかcurlでテストしてください。

「HSTSサイトでブラウザーに見える307と同じものをGooglebotも見る。」 完全には正しくありません。Google関係者の説明では、Googlebotは301を見る（Zineb、2015年）か、307/HSTSの仕組みとは一切やり取りしません（Mueller、2020年）。いずれにせよ、人間に見える「307」と同じではありません。その経路をクローラーに発見させたいなら、http→https用の本物のサーバー側301が必要です。

「303と307はほぼ同じように使える。」 重要な1軸では正反対です。303は常にメソッドをGETへ変える（Post/Redirect/Getパターン）のに対し、307はメソッドが変わらないことを保証します。どちらも302の隣にある「一時的」な分類なので混同しやすいだけです。

「ランキングを上げるため、すべての一時リダイレクトを307に切り替える。」 加点はありません。302より307を選ぶ有効な理由は、実際にメソッドとボディを維持する必要があること（または一般的な将来対応）だけです。すべての302を307へ変更しても何も得られず、エラーを持ち込むリスクがあります。

「302は必ずPOSTをGETに変えるので、フォームには根本的に壊れている。」 言い過ぎです。POST→GETの変換は、古く一貫しなかったクライアントでは現実の問題でした。だからこそ307が保証された選択肢として存在します。しかし現在のブラウザーははるかに一貫しており、307は現在のクライアント動作に頼るのではなく仕様で曖昧さをなくします。302が「壊れている」という意味ではありません。

HSTSアーティファクトではない実際のステータスコードを見る

HSTSがキャッシュされると、実際の301/302が幻の307の背後に隠れます。curlは既定ではHSTSを適用しないため、単純な実行ならサーバーへ直接アクセスして真実を表示します。ただし--hstsキャッシュファイルを指定して実行しないでください。そうすると、排除したい同じクライアント側の書き換えを再び導入することになります。

リダイレクトチェーン全体を追跡し、ヘッダーだけを確認

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

リダイレクトを追わずに1つのURLのステータスコードを確認

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

Chrome DevToolsのConsole — 幻の307を見つける

Consoleタブに貼り付けてください。実サーバーのリダイレクトならredirectedフラグと解決済みURLが現れますが、HSTSの更新はリクエストがブラウザーを出る前に発生します。

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

Chrome自身のHSTS記録をchrome://net-internals/#hstsで直接読むこともできます。ドメインを検索し、static_upgrade_mode／dynamic_upgrade_modeがhttpsを強制しているか確認してください。Networkタブに表示される307はそれによって発生します。

ブックマークレット — 現在のタブのヘッダーを素早く確認

このURLをブックマークとして登録し、ページ上でクリックすると、現在のURLのステータスとリダイレクト状態をConsoleへ記録できます。

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

注：ブラウザーのfetch()はクロスオリジンの不透明なリダイレクトボディを読めません。権威ある複数ホップの追跡では、上記のcurl -sILを正解としてください。

本物の307を返す

フレームワークの既定値に任せるのではなく307を返す目的は、メソッドとボディが維持されることを保証することです。明示的に返す一般的な方法を示します。

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js（App Router） — 307は既定値なので、コードを書くことは多くありません。 それだけです:

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

生の307レスポンスはどのように見えるか

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

HSTSの「幻の307」はどのように見えるか（ブラウザーのみ）

開発者ツールのステータス行は同じでも、手掛かりを見てください。発生源はサーバーではなくブラウザーで、0バイトのボディを伴います。

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

Non-Authoritative-Reason: HSTS（Chrome）や、HSTSを適用しないクライアントでテストすると消える0バイトの「307」が見えるなら、それがアーティファクトです。サーバーが送ったリダイレクトではありません。正確なヘッダー名とDevToolsのラベルはChrome固有の実装詳細であり、HTTPやHSTS仕様の保証ではありません。ブラウザーやバージョンをまたぐ自動化の根拠ではなく、例示として扱ってください。

メソッド、期間、発生源のフレームワーク

307を変更する前に、次の3軸で評価します。

1. メソッド： 対象は元のメソッドとリクエストボディを受け取る必要がありますか。はいなら、307は両方を維持する一時リダイレクトです。通常のページ間GETでは通常この性質は不要です。
2. 期間： 移動は本当に一時的ですか。元URLが戻ると予想される間だけ307を使います。永久移動なら、永久リダイレクトを選ぶべきで、無期限に一時ステータスを使うべきではありません。
3. 発生源： 307はサーバーが送ったのか、フレームワークが選んだのか、ブラウザーが内部HSTS更新として合成したのか。DevTools “Internal Redirect”は、オリジンのルールを書き換える理由ではありません。

本物と幻の307sを分けるツール

• Redirect Checker： 1つのブラウザーのHSTS状態に頼らず、サーバーから見えるステータス、宛先、すべてのホップを確認します。
• Redirect Chain Mapper： 307が長いリダイレクト経路の一部である場合に、ホップごとの表示を使います。
• HTTP Header Checker： LocationとStrict-Transport-Securityを調べ、エッジとオリジンの手掛かりを比較します。
• curl： ブラウザー内部のHSTS表示の外でcurl -I http://example.com/path を実行します。POST維持は自分が管理する安全なエンドポイントでだけテストしてください。
• ブラウザーDevTools： 「Internal Redirect」と表示され、転送量が0バイトなら、ブラウザーが生成したHSTS更新の可能性が高いと判断します。

デプロイ後に307を検証する

ステータスと宛先のテスト

実行するテスト： Redirect Checkerまたはcurl -Iでソースを確認します。**期待する結果：**意図したLocationを持つ307が1つ返ること。**失敗の解釈：**別のレイヤーがルールまたは対象を変更しています。**監視期間：**即時。**ロールバックのトリガー：**ループ、壊れた宛先、意図しないホスト名が現れること。

メソッド維持のテスト

**実行するテスト：**管理下のテストルートへ無害なPOSTを送り、宛先が何を受け取るか確認します。**期待する結果：**宛先が元のボディを伴うPOSTを受け取ること。**失敗の解釈：**中間レイヤーがメソッドを変えたか、別のコードを返しました。**監視期間：**即時。**ロールバックのトリガー：**フォーム、Webhook、チェックアウトのリクエストからメソッドまたはボディが失われること。

HSTS分離のテスト

**実行するテスト：**DevTools（または新しいシークレットウィンドウ）と、HSTSキャッシュを設定していないcurl -Iリクエストを比較します。**期待する結果：**ブラウザーの「Internal Redirect」と実サーバーのレスポンスを区別でき、HTTPにもサーバー側リダイレクトが存在すること。**失敗の解釈：**HSTSがオリジンのルール欠落を隠しています。ブラウザー内蔵のHSTS preloadリストのドメインでは状態が閲覧履歴に依存せず残るため、シークレットウィンドウだけでは不十分です。**監視期間：**即時。**ロールバックのトリガー：**オリジンの変更によって動作していたHTTP→HTTPSリダイレクトが消えること。

自分で確認する：307 Temporary Redirect

307とは何か、Googleがどう扱うか、HSTSアーティファクトとは何かを確認する5問です。各問に答えてから解説を確認してください。

役立つ資料

関連する記事

• “11 Types Of Redirects & Their SEO Impact” (翻訳)「リダイレクト11種とSEOへの影響」 — 307の定義、HSTSの注意点、私の好みの順序（307 / 302 / 303を先頭）の出典です。
• “HTTP Status Codes & Their SEO Impact” (翻訳)「HTTPステータスコードとSEOへの影響」 — 307の2つの項目、一時リダイレクトとHSTSポリシーのケースを扱う記事です。
• “The Beginner’s Guide to Technical SEO” (翻訳)「テクニカルSEO入門」 — 大きな枠組みの中でリダイレクトが占める位置を説明します。

講演

• “How Search Works” (翻訳)「検索の仕組み」 （SlideShare）— クロール、レンダリング、インデックス、ランキングを扱い、リダイレクトの処理も説明する講演です。（定型の注意書き：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳)「これはシステムについての私の理解であり、100%完全または正確とは限りません。」）

業界の資料

• “John Mueller — HTTPS & HSTS: 301, 302, or 307?” (翻訳)「John Mueller — HTTPSとHSTS：301、302、307のどれか」 — HSTSの「幻の307」（「your server’s not returning a 307」）を説明する最も明確な一次資料です。
• “Search Off the Record, ep. 51 — Let’s talk redirects” (翻訳)「Search Off the Record第51回 — Let’s talk redirects」 （文字起こしPDF）— 307/308がなぜ存在するか、そして「SEOでは実際には重要ではない」というMuellerとSplittの説明です。
• “Google on 307/HSTS Redirects” (翻訳)「Googleの307／HSTSリダイレクト解説」 （Search Engine Journal）— 「307リダイレクトは通常本物ではない」というMueller動画の要約です。
• “GoogleBot Treats 307 Redirects As 301s?” (翻訳)「Googlebotは307を301として扱うか」 （Search Engine Roundtable）— HSTSでGooglebotが何を見るかについてのZineb Ait Bahajjiの2015年の発言です。
• “MDN — 307 Temporary Redirect” (翻訳)「MDN — 307 Temporary Redirect」 — メソッドとボディの保証に関する標準的な技術リファレンスです。
• “An SEO’s Guide To Crawling HSTS & 307 Redirects” (翻訳)「SEO担当者のHSTSと307リダイレクトのクロールガイド」 （Screaming Frog）— HSTSによる307を扱う最良のクローラー設定資料です。
• “Next.js — redirect() reference” (翻訳)「Next.js — redirect()リファレンス」 — 大手フレームワークが非GETリダイレクトを307にする理由を説明します。

変更履歴