308恒久リダイレクト

TL;DR — 308 Permanent Redirectは「恒久的に移動した」と伝えるコードで、301と同じです。ただし1つ大きな保証があり、移転先でリクエストメソッドを変更してはなりません。ブラウザーは新しいリクエストを作るのではなく同じリクエストを繰り返すため、フォームのデータを含むボディも通常は一緒に届きます。フォーム送信は、気づかないうちに単なるページ閲覧へ変わりません。検索エンジンにとって2つのコードは同じなので、通常の「このページは移動した」というリダイレクトなら301で十分です。ページをクリックするだけではないAPIやフォームを移動し、元のリクエストを完全なまま届かせる必要があるときに308を選びます。

308とは何か

サーバーがブラウザーをあるURLから別のURLへ送るとき、レスポンスに番号、つまりステータスコードを付けます。そのうち「このページは恒久的に移動した」という意味を持つものが2つあります。

• 301 — 「Moved Permanently（恒久的に移動）」。最初に作られた恒久リダイレクトコードで、初期のWeb時代から使われています。
• 308 — 「Permanent Redirect（恒久リダイレクト）」。2015年に仕様へ追加された新しいコードで、同じ役割に加えて、301にはなかった保証を1つ持ちます。

この保証が308の存在理由です。ページを訪れるとき、ブラウザーは通常、単純なGET（「このページをください」）を送ります。しかしフォーム送信やログインでは、入力したデータを運ぶPOSTを送ります。旧来の301では、新しいURLへ向かう途中でPOSTを通常のGETへ変えてよいとブラウザーが技術的に解釈でき、その場合データが失われます。308ではその変更が許されません。ブラウザーは新しいリクエストを作るのではなく同じものを繰り返すため、データも通常は一緒に届きます。ただしAPI呼び出しや決済フローなど、構築しているものにとって重要なら、仕様の文言だけを信じず、実際のリクエストをテストして新URLにボディが届くことを確認してください。

308はSEOに悪影響があるか

ありません。Googleの公式文書は308を*「Equivalent to 301」* (翻訳)「301と同等」と明記しています。どちらも恒久リダイレクトで、ページのランキングシグナルを同じように新URLへ渡します。Bingも同じように扱います。308を使うランキング上のボーナスもペナルティもありません。選択理由は上で説明した技術的な動作であり、検索順位ではありません。 Evidence for this claim Google treats 308 as equivalent to 301 for Search and groups both as permanent redirects. Scope: Google Search processing; the two status codes remain semantically different for HTTP clients. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search Google: Redirects and Google Search

では、いつ使うべきか

通常のページを移動した場合、新URLへの変更、httpからhttpsへの切り替え、ドメイン変更なら、単純な301が扱いやすく普遍的な選択です。すべてのブラウザー、プラグイン、ホスティングツールが理解します。

リダイレクト対象が単なるページではないときに限って、308を使います。

• 他のソフトウェアから呼び出されるAPI。
• データを送るフォームまたはログイン。
• 別サービスがPOSTする自動URLであるWebhook。

この場合、リクエストが気づかないうちに格下げされてデータを失う余裕はありません。308はそうならないことを保証します。

仕様の経緯、GoogleとBingの正確な引用、コピーして使えるサーバーの断片を確認したいなら、Advancedタブへ進んでください。

TL;DR — 308は恒久的で、メソッドを厳密に保持するリダイレクトです。301と同じ正規化シグナル（Googleの文書は*「Equivalent to 301」* (翻訳)「301と同等」と説明）を持ちながら、新しいURLでクライアントがメソッドを変更しないことを保証します。準拠クライアントは新しいリクエストではなく同じリクエストを繰り返すため、ボディも一緒に送られます。HTTPには一時的なメソッド保持コード（307）が、恒久版より何年も先に存在しました。RFC 7538（2015年）がその空白を埋め、現在のRFC 9110は301自身の定義から308を直接参照しています。SEO上は2つを交換可能に扱えます（IllyesはGoogleが308を「統合」すると述べ、BingのCanelも同等性を確認しています）。APIやバージョン移行、Webhook URL、認証／フォームのPOSTフローなど、非GETリクエストを生かす必要がある場合に308を選びます。ただし仕様だけで判断せず、実際のクライアントでメソッドとボディの保持を確認してください。それ以外は301が既定です。2026年の308のブラウザー対応は強く、caniuseは現在およそ96,5 %以上を追跡していますが、RFC 9110自身は308を新しく、どこでも認識されるとは限らないとしています。一部のCMSプラグイン、エッジルールUI、古いプロキシは今も301/302/307しか提供しません。

308の機械的な意味

308 Permanent Redirectは301と同じ「このリソースは恒久的に新しいURLにある」というメッセージを運びます。そこに、301にはなかった1つの追加があり、クライアントは移転先でリクエストメソッドを変更してはなりません。クライアントは新しいリクエストを発行するのではなく同じリクエストを繰り返すので、仕様に準拠したクライアントならボディも一緒に移ります。これはメソッド保証の結果であり、別個に認証された約束ではありません。自分のクライアントとサーバーでエンドツーエンドに確認してください。MDNは、308をリダイレクトをまたいでリクエストメソッド（実際にはボディも）を変更しないコードとして説明しており、301ではそうならない可能性があります。

Ahrefsのリダイレクトガイド で使っている平易な説明は、「A 308 redirect is the same as a 301 redirect, except it retains the HTTP method of the original request, GET or POST, when performing the redirect.」 (翻訳)「308リダイレクトは301リダイレクトと同じだが、リダイレクト時に元のリクエストのHTTPメソッド（GETまたはPOST）を保持する」です。さらに短く、HTTPステータスコードのガイド では、「308 Permanent Redirect – Has the same functionality as a 301 redirect, except you can’t switch between POST and GET.」 (翻訳)「308恒久リダイレクトは301と同じ機能だが、POSTとGETを切り替えられない」と説明しています。 Evidence for this claim RFC 7538 defines 308 Permanent Redirect as a permanent move whose redirect follow-up must not change the request method. Scope: HTTP semantics for 308 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 7538 §3 — 308 Permanent Redirect

具体例で違いを見てみましょう。クライアントがJSONボディ付きでPOSTを/api/ordersへ送るとします。

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{ "sku": "A-100", "qty": 2 }

そのエンドポイントが301で応答し、クライアントが歴史的な「GETへ切り替えてよい」という許可に従うと、新URLには空のGETとしてリクエストが届き、ボディが消えて注文が失われる可能性があります。308ならクライアントは新URLでPOSTを繰り返さなければなりません。準拠クライアントはボディも一緒に運ぶので注文は通りますが、自分のクライアントとサーバーログで確認してください（Scriptsタブを参照）。どの環境でも普遍的にそうなると仮定しないでください。これが実務上の違いのすべてで、元のリクエストが単純なGETではないときだけ現れます。

なぜ308が存在するのか — 仕様の経緯

多くの解説が飛ばす部分ですが、このコードを理解する最も明快な方法です。

307が先でした。 HTTPにはすでに、一時的でメソッドを保持するリダイレクト、つまり307がありました。恒久的な対応物が存在するよりずっと前です。元の中核仕様（RFC 7231）は307の恒久版を定義していませんでした。そのため、一時的な「メソッドを保持する」コードと、恒久的だが「メソッドを変更してよい」コード（301）はあっても、恒久的な「メソッドを保持する」コードはありませんでした。

RFC 7538が空白を埋めました。 308は、欠けていた恒久版307として追加されました。最初は実験的な RFC 7238 （2014年6月）、その後 RFC 7538 （2015年4月）として標準化されました。301の置き換えではなく、実際に存在した穴を埋めるものです。

現行仕様は直接308を指します。 RFC 9110 は現在のHTTPセマンティクス仕様で、301に組み込まれた曖昧さを今も記録し、自身の301定義の中で308を解決策として示しています。「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 308 (Permanent Redirect) status code can be used instead.」 (翻訳)「歴史的な理由から、ユーザーエージェントは後続リクエストでPOSTからGETへメソッドを変更してもよい。この動作が望ましくない場合は、308（Permanent Redirect）ステータスコードを代わりに使えます。」この一文が、権威ある仕様から見た308の存在理由です。308自身の節では、「is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.」 (翻訳)「兄弟コードよりはるかに新しく（2014年6月）、そのためどこでも認識されるとは限らない」と付記しています。

つまり301のPOSTからGETへの動作はバグではありません。仕様に組み込まれた「歴史的な理由による」許可で、308はそれを避けるために公式に認められた方法です。

301と308 — 実務上の違いを1つの表で

要点は、圧倒的多数のリダイレクト、つまり単純なGETでは、301と308はまったく同じ動作をするということです。保証が意味を持つのは、ボディを伴う非GETメソッドが関係するときだけです（完全な比較は専用の301と308の比較記事を参照）。

GoogleはSEO上、308を301と同じように扱うか

はい、明確に同じで、文書にも記載されています。GoogleのHTTPステータスコード文書 は、301を「Googleが*「use[s]… as a strong signal that the redirect target should be processed」* (翻訳)「対象を処理すべきだという強いシグナルとして使う」と説明するリダイレクト」とし、308は単に*「Equivalent to 301」* (翻訳)「301と同等」と記載しています。さらに、「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に罰せられませんが、他のソフトウェアがこの違いに依存するため、リクエストに正しいコードを使うべきです。

Googleのリダイレクト文書 は、2つのコードを同じ推奨層に置いています。「The 301 and 308 status codes mean that a page has permanently moved to a new location.」 (翻訳)「301と308のステータスコードは、ページが恒久的に新しい場所へ移動したことを意味する」と説明します。サイト移転のガイダンスも、308を301の後付けではなく明示的に挙げ、恒久移転には「301や308など」の恒久HTTPリダイレクトを使うよう推奨しています。

この同等性がいつも文書化されていたわけではないことも知っておく価値があります。Gary IllyesはGoogleが内部で308を301に統合すると述べ、Search Engine Roundtableの報道は、非公式な補足がついに頼れる公式文書になった瞬間として説明しています。数年前に「本当に文書化されているのか」と尋ねたサイト所有者が慎重だったのは妥当でしたが、基礎動作自体は変わっていません。Googleと担当者の正確な文言を確認したいなら、検証済みの引用と深いリンクをQuotesタブで確認してください。

Bingは308を301と同じように扱うか

はい。BingにはGoogleのように308を詳しく説明する専用文書ページはありませんが、MicrosoftのFabrice Canelが2024年9月、Search Engine Roundtableの報道 でX上の発言として直接確認しました。Bingは308リダイレクトを301リダイレクトと同じように扱います。これがBingについての権威ある声明です。逐語引用はQuotesタブを参照してください。

実際に308を使う場面

ここに308単独の根拠があります。ほぼいつも、非GETリクエストが関係します。

APIエンドポイントとバージョン移行。 /v1/を/v2/へ移す、またはAPIホストを移すのが典型例です。クライアントはPOST/PUT/PATCH/DELETEと実際のボディでこれらのエンドポイントを呼び出します。308はメソッドとペイロードがホップを越えて残ることを保証しますが、301では静かな格下げが起こり、リクエストが行き場を失う可能性があります。

POST中心のサイト移転。 チェックアウト、ログイン／認証エンドポイント、フォームの送信先はすべてPOSTデータを送ります。移転中にそれらのURLが変わるなら、301では失われるかもしれない送信内容を308が保持します。

Webhook URLの変更。 別サービスが移動中のWebhook URLへPOSTするとき、308はそのHTTPクライアントにボディを保持したまま新しいアドレスへ再POSTさせます。Webhookの受け手が必要とする動作そのものです。

共通するのは、ボディを失ったりメソッドが静かにGETへ落ちたりすると機能が壊れる場所では、SEOの価値を少し並べ替えるためではなく308を使うということです。

これらのどれかを切り替える前に、単なるステータスコードではなく統合テストとして確認してください。

• ステージング環境の新しいエンドポイントへ、実際のメソッドとペイロードを再送する。
• 認証ヘッダーやCookieを引き継ぐべきか確認し、実際に引き継がれることを点検する。
• 元のリクエストが冪等でない場合（注文を作るPOSTなど）は、リダイレクトのホップ中に副作用が二重にならないか監視する。
• ボディだけでなく、クエリ文字列とContent-Typeヘッダーも残ることを確認する。
• Webhook送信元、API SDK、ブラウザーなど実際のクライアントが、古いエンドポイントを廃止する前に308を自動追従することを検証する。すべてのHTTPクライアントが既定でそうするわけではありません。

301が今も現実的な既定値である場面

単純なGETであるものはすべて、301が妥当な既定値です。

• 通常のコンテンツ／ページURLの変更。
• HTTP → HTTPSの移行。
• ドメイン変更と標準的なサイト移転。
• 末尾スラッシュとwww／非wwwの正規化。

ここではリクエストが単純なGETなので、308の保証は何も買いません。301は普遍性で勝ち、どちらを選んでもSEO上のコストはありません。ランキング上昇を狙って既存の301を308へ一括移行しないでください。その利点は存在しません。Ahrefsのリダイレクトガイド のリダイレクト選好階層でも、308と301はメタリフレッシュ、JavaScript、その他の回避策より上の最上位層に並ぶ同格です。階段ではありません。

採用状況とサポートの注意 — 2026年に本当にリスクになるもの

ブラウザー対応は、かつてほど実務上のリスクではありません。 caniuse の現在の追跡では、308は世界全体でおよそ96,5 %以上に対応しています。今日の数値は変動するため、ライブ表で確認してください。目立つ非対応は、何年も前に廃れたブラウザー、つまりIE11より前、古いChrome／Firefox／Safari、旧Android Browserに集中しています。「IE11は308で失敗する」という古い注意書きがまだ見えるなら、主流トラフィックには古すぎます。

現在の注意点はツールです。 2026年現在の正直な空白は、すべての層が308の選択肢を公開しているわけではないことです。一部のCMSリダイレクトプラグイン、CDN／エッジのリダイレクトルールUI、古いリバースプロキシやロードバランサーは、301/302/307しか選べません。308を使う前に、実際にリダイレクトを配信する層が、静かに格下げせず308を出せることを確認してください。Scriptsタブにはワイヤー上の実ステータスコードを確認する1行があります。RFC 9110自身の「はるかに新しく、どこでも認識されるとは限らない」という注意は、ブラウザーだけに限定されません。308の一般的な展開上の注意であり、2026年には主にブラウザーではなくツールに現れます。ただし仕様の基準として読む価値があります。

非標準の脚注：「308 Resume Incomplete」

308がまだ新しいコードであることを示す奇妙な点があります。実際には308はリダイレクトコードだけではありません。Google DriveのアップロードAPIは、チャンク分割したアップロードが止まり、クライアントが再開すべきことを示す「Resume Incomplete」というまったく別の意味で308を再利用します。John Mueller自身がこれを指摘し（Quotesタブを参照）、MDNも同じ非標準用途を記録しています。308をリダイレクトとして使う場合の意味は変わりませんが、由緒ある301より新しく、文化的に定着していないステータスコードであることを示すよい例です。

リダイレクトチェーンとホップも同じように適用される

ここまでの内容はリダイレクトチェーンの仕組みを変えません。Googleのクローラーは既定で最大10ホップまで追従しますが、これは既定値であって普遍的な定数ではありません。Google自身の文書は、URL Inspectionツールのように製品によってはリダイレクトをまったく追従しない場合があると記載しているため、10を永遠に固定された数として扱わず、現在のGoogle文書を確認してください。301sのホップでも308sのホップでも既定の上限は同じです。古いAPIパスが着地前に2回ホップするなど、リダイレクトを積み重ねているなら、可能な範囲でチェーンを1ホップに畳み、ループを避ける同じ衛生管理が必要です。仕組みは専用のリダイレクトチェーン記事を参照してください。

AI要約

Advanced版の要点を短くまとめます。

• 308＝恒久的＋メソッド厳密保持。 301と同じ「恒久移動」のメッセージに、301にはない保証、つまり新URLでクライアントがリクエストメソッドを変更してはならないという条件が加わります。準拠クライアントは同じリクエストを繰り返すため、ボディも一緒に届きます。仕様だけで決めず、自分のクライアントでエンドツーエンドに確認してください。
• SEO上は301と同等。 Googleの文書は308を*「Equivalent to 301」* (翻訳)「301と同等」としています。Gary IllyesはGoogleが308を301に統合すると述べ、BingのFabrice Canelも同じ扱いを確認しています。ランキング上の利点もペナルティもありません（Illyes、Mueller、Canelの発言はSearch Engine Roundtable経由の伝聞なので、最終的な根拠として扱う前に原文を確認してください）。
• 存在理由。 HTTPには一時的なメソッド保持リダイレクト（307）が、恒久版より何年も先にありました。RFC 7538（2015年）が空白を埋め、RFC 9110は301定義から308を参照します。301の「歴史的な理由でPOSTからGETへメソッドを変更してもよい」という許可と、望ましくなければ308を使えるという文言を、仕様の引用として確認できます。
• 308を使う場面。 API／バージョン移行、Webhook URL、フォーム／認証POSTなど、メソッドやボディを失うと機能が壊れる場所です。切り替える前にステージングで実メソッドとペイロードを再送し、認証ヘッダー、冪等性、クライアントの追従動作を確認してください。
• 301を使う場面。 通常のページ移動、HTTP→HTTPS、ドメイン変更、正規化など、すべて単純なGETで308の保証が役立たない場所です。301のほうが普遍的に対応されています。
• 採用状況。 ブラウザー対応は強く、caniuseは現在およそ96,5 %以上を追跡していますが、RFC 9110は「新しく、どこでも認識されるとは限らない」という一般的な注意を残しています。2026年には主にツールの差として現れ、一部CMSプラグイン、CDN／エッジUI、古いプロキシは301/302/307しか出せません。リダイレクト層が実際に308を出せることを確認してください。308はヒューリスティックにキャッシュ可能なので、誤った308やロールバック後の308がキャッシュに残ることにも注意します。
• 脚注。 Google Driveはアップロード停止時に「308 Resume Incomplete」を再利用します。リダイレクトではない用途があり、308が301より新しく、まだ定着途上であることを示します。

公式ドキュメント

検索エンジンとHTTP仕様が示す、308に関する一次資料です。

Google

• HTTPステータスコード、ネットワークおよびDNSエラー、Google検索 — 308を「Equivalent to 301」とし、「意味は異なるが同じように扱う」という注意と、10ホップのリダイレクト上限を記載しています。
• リダイレクトとGoogle検索 — 「301と308のステータスコードは、ページが恒久的に新しい場所へ移動したことを意味する」という説明です。
• URL変更を伴うサイト移転 — 恒久移転には「301や308など」の恒久HTTPリダイレクトを推奨しています。

HTTP仕様

• RFC 9110 — HTTPセマンティクス — 現行仕様です。§15.4.9で308と*“much younger… might not be recognized everywhere”* (翻訳)「はるかに新しく、どこでも認識されるとは限らない」という注意を定義し、§15.4.2で301を定義して、望ましくないPOSTからGETへの変換を直す方法として308を示します。
• RFC 7538 — HTTPステータスコード308（恒久リダイレクト） — 308を導入した標準（2015年4月）で、実験的なRFC 7238（2014年6月）を置き換えました。

参考資料

• MDN — 308恒久リダイレクト — メソッド／ボディ保持の意味と、Google Driveの非標準「Resume Incomplete」用途を説明します。
• caniuse — HTTPステータスコード308 — ブラウザー対応表（世界全体でおよそ96,5 %以上）です。

出典からの引用

Google、Bing、HTTP仕様による記録上の発言です。各リンクは引用箇所へ深くリンクしています。

Google — 中心となる同等性

• 「301 (moved permanently): Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.」 (翻訳)「301（恒久移動）：Googleはリダイレクトに従い、Googleのシステムは対象を処理すべきだという強いシグナルとしてリダイレクトを使います。」 — Google Search Centralの文書。 引用箇所へ
• 「308 (moved permanently): Equivalent to 301。」 (翻訳)「308（恒久移動）：301と同等です。」 引用箇所へ
• 「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はこれらのステータスコードを同じように扱うが、意味は異なることを覚えておく必要があります。ほかのクライアントも恩恵を受けられるよう、リダイレクトに適したコードを使うべきです。」 引用箇所へ
• 「The 301 and 308 status codes mean that a page has permanently moved to a new location.」 (翻訳)「301と308のステータスコードは、ページが恒久的に新しい場所へ移動したことを意味します。」 引用箇所へ

Gary Illyes、Google

• 308をGoogleがどう扱うかについて：「we just merge that with 301 so we really don’t care iirc.」 (翻訳)「私たちはそれを301に統合するので、実際には気にしていません（記憶が正しければ）。」 Search Engine Roundtableの逐語報道、Google Officially Treats 308 Redirects As 301 Redirects （2021年7月）経由。最終的な根拠として扱う前に原文で確認してください。

John Mueller、Google

• 非標準用途について：「Google Drive uses a 308 redirect as a Resume Incomplete response to indicate to the client when an incomplete upload stalled. So that is a bit different. But you can use it as a normal redirect.」 (翻訳)「Google Driveは不完全なアップロードが停止したとき、クライアントに知らせるResume Incompleteレスポンスとして308リダイレクトを使います。その点は少し異なりますが、通常のリダイレクトとして使うこともできます。」 Search Engine Roundtable経由、Googleは308リダイレクトを301として扱えること （2018年5月）。原文で確認してください。

Fabrice Canel、Microsoft Bing

• 「I accidentally deleted my reply, so confirming again: Bing treats 308 redirects the same as 301 redirects.」 (翻訳)「返信を誤って削除したため、もう一度確認します。Bingは308リダイレクトを301リダイレクトと同じように扱います。」 Fabrice CanelのX上の発言（2024年9月）、Search Engine Roundtable経由、Bingは308リダイレクトを301と同じように扱うこと。最終的な根拠として扱う前に原文で確認してください。

RFC 9110 — HTTPセマンティクス仕様

• 308の存在理由について、301の定義そのものから：「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 308 (Permanent Redirect) status code can be used instead.」 (翻訳)「歴史的な理由から、ユーザーエージェントは後続リクエストでPOSTからGETへメソッドを変更してもよい。この動作が望ましくない場合は、308（Permanent Redirect）ステータスコードを代わりに使えます。」 RFC 9110を読む
• 採用について：308は*「is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.」* (翻訳)「兄弟コードよりはるかに新しく（2014年6月）、そのためどこでも認識されるとは限りません。」 RFC 9110を読む

このリダイレクトは308にすべきか

301と308はSEO上同等なので、これはランキングの判断ではありません。問うべきことは1つ、ボディ付きの非GETリクエストが関係し、リダイレクト層が実際に308を出せるかです。順番に確認しましょう。

要するに、単純なGET → 301、保持すべき非GETリクエスト（かつスタックが出せる） → 308です。SEO上は2つを交換可能に扱うため、決め手はメソッドの要件と、「自分のツールは実際にそれを出せるか」という短い確認だけです。

308についての神話と誤り

私が最もよく見る失敗パターンをそのまま取り上げます。

「308は301よりSEOに有利だ。」 誤りです。Googleの文書は*「Equivalent to 301」* (翻訳)「301と同等」とし、Illyes、Mueller、BingのCanelも同等性を確認しています。どの検索エンジンも308をSEO上優位とは扱いません。選択理由はメソッドとボディの正しさであり、ランキング上の優位ではありません。

「既存の301をすべて308sへ移行すべきだ。」 ランキング上の利点がない、純粋な入れ替えです。ページ間リダイレクトの圧倒的多数は単純なGETなので、301は実際の動作でも308と同じです。切り替えるのは、非GETメソッドを実際に運ぶリダイレクトに限ってください。

「308は新しいから安全ではない。」 ブラウザーについては言い過ぎです。RFC 7538は10年以上前の仕様で、GoogleとBingはエンジン側の対応を確認しており、caniuseもおよそ96,5 %以上のブラウザー対応を示しています。RFC 9110には、308は「新しく、どこでも認識されるとは限らない」という一般的な注意が残っています。2026年には主にツールの空白（すべてのCMSプラグイン、CDNリダイレクトルールUI、古いプロキシが308を出せるわけではない）として現れます。クライアントや検索エンジンの空白ではありませんが、完全に引退した注意でもありません。

「301は必ずPOST／APIリクエストを壊す。」 言い過ぎです。多くの現代的なクライアントは妥当な動作を保持します。仕様が文書化する本当のリスクは、RFC 9110が「歴史的な理由」で許している特定のPOSTからGETへの変換で、クライアントがその古い許可に従うと問題になります。308はそのリスクを完全に除きますが、保証された普遍的な失敗を修正するコードではありません。

「308は常にリダイレクトコードだけだ。」 そうとは限りません。Google Driveの非標準「308 Resume Incomplete」は停止したアップロードのためにコードを再利用し、まったく別の意味を持ちます。308の実世界での利用が301より新しく、まだ定着していないことを思い出させる例です。

補足 — 「恒久リダイレクトはPageRankを失う。」 この記事の中心ではありませんが、一文で触れる価値があります。Googleの公式ガイダンスは301と308を、処理対象の新URLを正規URLとして扱うシグナルに使う恒久リダイレクトとして同じグループに置いています。これは価値の毀損ではなく継続性として読めます。「PageRankが絶対に失われない」という広い主張ではなく、現在のソースが実際に支える、より狭い正規化シグナルの説明として扱ってください。

308を確認して実装する

308で最も役に立つ作業は、ワイヤー上の実ステータスコードを確認することです。最も多い失敗はブラウザーではなく、ツールの層が意図した308を301へ静かに格下げすること（またはリダイレクトをまったく出さないこと）だからです。

curlでステータスコードを確認する

# Show only the response headers; -I sends a HEAD request.
curl -sI https://example.com/old-path | head -n 1
# → HTTP/1.1 308 Permanent Redirect     (what you want)
# → HTTP/1.1 301 Moved Permanently      (your layer downgraded it)

POSTでメソッドが実際に保持されること（308の本来の目的）を確認するには、-Lでリダイレクトを追い、到着したものを監視します。-X POSTと--dataは、サーバーが308または307を返した場合にだけ、ホップを越えてPOSTのままになります。

curl -sIL -X POST --data '{"sku":"A-100"}' \
  -H 'Content-Type: application/json' \
  https://api.example.com/v1/orders
# Inspect each hop's request line; a 308 keeps it "POST", a 301 may show "GET".

チェーン全体を追跡する

経路が1回を超えてホップするなら、すべてのステータスコードを出力し、格下げや意図しない余分なホップを見つけられるようにします。

curl -sIL https://example.com/old-path \
  | grep -iE '^HTTP/'
# Each line is one hop. Collapse chains to a single hop where you can.

ロールバック前に308がキャッシュされているか確認する

RFC 9110では308はヒューリスティックにキャッシュ可能です。つまり明示的なCache-Controlヘッダーがなくても、クライアントや中間層がキャッシュすると決めることがあります。誤った308（または元に戻す必要がある308）が、オリジンのルールを直した後もキャッシュから提供され続ける可能性があります。リダイレクトが「固まった」と判断する前に確認してください。

• 新しいクライアント（プライベート／シークレット、過去に訪問していないもの）と、古いURLにすでにアクセスしたクライアントの両方でテストする。キャッシュ済みと未キャッシュのクライアントでは挙動が異なることがあります。
• curl -sIでCache-Control、Expires、Ageヘッダーをレスポンスから確認する。
• 単純なGETと、代表的な非GETリクエストを分けてテストする。キャッシュ動作はメソッドによって異なることがあります。
• 308を元に戻す必要があるなら、エッジ／CDNキャッシュを明示的に消去する。オリジンのルールを削除すれば十分だと考えず、古いリダイレクトをすでにキャッシュした一部クライアントが自動的に再リクエストしないことも想定する。

Chrome DevTools Console — ブラウザーからのリダイレクトを確認する

DevToolsのConsole（F12 → Console）へ貼り付けると、ページを離れずに最終URLとステータスを確認できます。手動リダイレクトのfetchは、最初のレスポンスのステータスを直接報告します。

// Reports the status of the first response (the redirect itself), not the target.
fetch('https://example.com/old-path', { method: 'HEAD', redirect: 'manual' })
  .then(r => console.log('type:', r.type, 'status:', r.status || '(opaqueredirect)'));

// Follow the chain and log where it lands:
fetch('https://example.com/old-path', { method: 'HEAD', redirect: 'follow' })
  .then(r => console.log('final URL:', r.url, 'final status:', r.status));

ブックマークレット — 「このURLは何を返すか」をワンクリックで確認

このURLをブックマークとして登録し、ページ上でクリックすると、URLの入力を求め、最終ステータスと着地URLを警告表示します。

javascript:(function(){var u=prompt('URL to check:',location.href);if(!u)return;fetch(u,{method:'HEAD',redirect:'follow'}).then(function(r){alert('Final status: '+r.status+'\nLanded on: '+r.url);}).catch(function(e){alert('Error: '+e);});})();

サーバーで308を実装する

Apache（.htaccess） — 明示的なR=308を使うmod_rewrite：

RewriteEngine On
RewriteRule ^old-path/?$ /new-path [R=308,L]

nginx — return 308は正確で曖昧さがありません。

location = /old-path {
    return 308 https://example.com/new-path;
}

Express.js（Node） — redirect()にステータスコードを渡します。

app.all('/api/v1/orders', (req, res) => {
  // 308 keeps the POST body intact on the way to /api/v2/orders
  res.redirect(308, '/api/v2/orders');
});

Next.js — permanent: trueを設定すると308を出します（Nextの恒久リダイレクトは308です）。

// next.config.js
module.exports = {
  async redirects() {
    return [
      { source: '/api/v1/:path*', destination: '/api/v2/:path*', permanent: true },
    ];
  },
};

フレームワークとホスティング層の挙動は、バージョンによって固定されていません。たとえばNext.js自身のリダイレクト処理も、バージョンや起動箇所によって違うことがあります。next.config.jsのredirects()エントリ、Server Action内のpermanentRedirect()呼び出し、ストリーミングレスポンスは、必ずしも同じステータスコードになりません。Apache／nginxモジュールのバージョンや、オリジンの前段にあるCDN／プロキシにも同じ注意が必要です。上の断片は出発点であって保証ではないため、自分のバージョンの現行文書を確認してください。

どれかをデプロイした後、上のcurl -sIチェックを再実行して、ワイヤー上に実際に308が載っていることを確認してください。この検証を飛ばして後悔する人が多いのです。

ワイヤー上の308を確認するツール

Patrickの無料ツール

• Redirect Checker — 1つのURLまたは短い一括処理を追跡し、最初のレスポンスが308であること、宛先が正しいこと、チェーンが健全な最終レスポンスで終わることを確認します。
• Bulk HTTP Status Code Checker — 最大500件の移行URLを確認し、予期しない301/302/307レスポンスを絞り込み、修正用にチェーンやループを書き出します。

厳密な動作が重要なときに証明する

• 安全なテストペイロードを使うcurl — ステージングまたは破壊的でないエンドポイントへ実際のメソッドを再送してリダイレクトを追い、送信元が308を出すことを確認します。
• アプリケーション／APIゲートウェイのログ — 対象が同じメソッド、コンテンツタイプ、ボディを受け取ったことを確認します。リダイレクトチェッカーはステータスと宛先を証明し、受信ログはエンドツーエンドのメソッド保持が機能したことを証明します。
• ブラウザーのDevTools Networkパネル — フォームと認証フローに役立ちますが、301ではなく308を選ぶ理由は相互運用性なので、WebhookとAPIクライアントは別にテストしてください。
• Google Search Console URL Inspection — インデックス対象のページURLについて、恒久移動が301と同じように処理され、宛先が選択された正規URLになっていることを確認します。

自分で確認する：308 Permanent Redirect

308とは何か、なぜ存在するのか、検索エンジンがどう扱うのかを確認する5問です。各問に答えてから解説を確認してください。

役立つ資料

私の執筆

• リダイレクト11種とSEOへの影響 （Joshua Hardwickとの記事）— 308の定義、「SEO上は同じだがフォームでは違う」という整理、308と301が最上位層を共有するリダイレクト選好階層の出典です。
• HTTPステータスコードとSEOへの影響 — 「308は301と同じ機能だがPOSTとGETを切り替えられない」、そして「308は301と同じように扱われ、シグナルを前方へ集約する」と明確に説明した記事です。
• 成功するウェブサイト移転にはチェックリスト以上が必要 — 恒久移動には302/307ではなく301または308を選ぶ理由を説明します。
• テクニカルSEO入門 — 大きな枠組みの中でリダイレクトが占める位置を説明します。

業界の資料

• リダイレクトとGoogle検索 — 301と308を恒久的な選択肢として並べるGoogle公式リダイレクトガイドです。
• HTTPステータスコード、ネットワークとDNSエラー、Google検索 — 「308は301と同等」とし、「意味は異なる」という注意を付ける文書です。
• RFC 9110 — HTTPセマンティクス — 現行仕様で、望ましくないPOSTからGETへの変換を直す方法として301定義から308を示します。
• RFC 7538 — HTTPステータスコード308（恒久リダイレクト） — 308を導入した標準です。
• MDN — 308恒久リダイレクト — メソッド／ボディの意味とGoogle Driveの「Resume Incomplete」注記を説明します。
• caniuse — HTTPステータスコード308 — 「308は脆い」という神話を検証するブラウザー対応表です。
• Bingは308リダイレクトを301と同じように扱うこと （Search Engine Roundtable）— Fabrice Canelによる2024年のBing同等性確認です。
• Google Officially Treats 308 Redirects As 301 Redirects （Search Engine Roundtable）— Gary Illyesの「301に統合する」という文脈と、公式文書化の瞬間を扱います。

変更履歴