303リダイレクト（See Other）

TL;DR — 303 See Otherは、ブラウザーを別のページへ送り、GET（またはHEAD）で取得させるリダイレクトです。主な役割はウェブ開発の定番で、フォーム送信後にサーバーが結果ページへ移し、更新しても元のフォーム送信を再送せず結果ページを再取得させます。SEO目的で意図的に設定することはほとんどありません。これは「ページが移動した」という話ではなく、フォームやアプリのための仕組みです。正直に言えば、GoogleもBingも303専用のSEO助言を公開しておらず、語れることはほとんどありません。

303リダイレクトとは

ブラウザーがページを要求すると、サーバーは3桁のHTTPステータスコードで応答します。200は「ページはこちら」、404は「見つからない」という意味です。303は**「See Other」**を意味し、要求した内容をそのまま表示せず、別のURLをGETまたはHEADで取得するよう指示します。

GETまたはHEADへ切り替えることが303の核心であり、近い種類のリダイレクトと異なる理由です。詳しく見ていきましょう。

本来の用途は1つだけ

注文、コメント、支払いなどのフォーム送信を考えてみてください。ブラウザーはPOSTリクエストを送ります。サーバーがPOSTの応答内で確認ページを直接返すと、問題が起きます。更新するとブラウザーが「このフォームを再送しますか？」と尋ね、何も考えず再読み込みすれば注文が二重になります。

303はこれを解決します。流れは次のとおりです。

1. フォームを送信する → ブラウザーがPOSTを送ります。
2. サーバーが処理し、結果ページを指す303で応答します。
3. ブラウザーが303に従い、その結果ページへ新しいGETを送ります。

これで通常のGET可能な確認ページが表示されます。更新や戻る操作をしても、元のPOSTを再送せず、そのページを再取得するだけです。開発者はこれを**Post/Redirect/Get（PRG）**パターンと呼び、303が中央の「リダイレクト」を担います。ただし効果を正確に理解しましょう。PRGが防ぐのはブラウザー更新による再送であり、厳密な一度きりの保証ではありません。再試行、ダブルクリック、タイムアウト、同時リクエストによって注文や請求が重複する可能性は残るため、書き込み処理自体に冪等性キーやトランザクション検査など、アプリ独自の安全策が必要です。

SEOではほとんど意味を持たない理由

303はページ移行の道具ではなく、ウェブアプリケーションの動作です。URLを恒久的に移すなら301、一時的に移すなら302を使います。303でページを移すことはほとんどありません。そもそもそのために作られていないからです。Ahrefsで私が書いたとおり、「SEO目的で303リダイレクトを使うことは通常なく、使った場合も302/307と同じように扱われます」と考えるのが実務的です。

この話の正直な結論は、GoogleもBingも303専用のSEOガイダンスを公開していないということです。Googleは303を302・307と同じ「一時的」リダイレクトのグループに一度だけ含めています。リダイレクト自体は、恒久的な301のように移転先を正規URLにするシグナルではありませんが、別のシグナルによって移転先がインデックスされることはあります。学ぶべき秘密の303挙動はありません。クロールツールがサイト上の303を報告しても、ほとんどの場合はフォームフローという意図的なアプリパターンであり、壊れたものでも「修正」すべきものでもありません。 Evidence for this claim Google groups HTTP 303 with temporary redirects, follows it, and does not use it as a signal that the destination should become canonical. Scope: Google Search canonicalization behavior for server-side temporary redirects. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search

壊れたページや移転ページと混同しない

「ページが移動した」または「ブラウザーがURLを見つけられない」ときに303が起きると説明するサイトがありますが、これは301/302やエラーとの混同です。303は異常の印ではありません。通常はフォーム処理の直後に、アプリが意図的に返す応答です。

302や307との技術的な比較、Googleの文書が実際に述べていること（John Muellerの率直な一言を含む）、開発者の視点で返すタイミングを知りたい場合は、Advancedタブへ進んでください。

TL;DR — 303（HTTP「303 See Other」）は一時的なリダイレクトで、元のリクエストのメソッドに関係なく、クライアントに別のリソースをGETまたはHEADで取得させます。これがPost/Redirect/Get（PRG）パターンを支えます。POST → 303 → GETの結果ページという流れなので、更新してもフォームを再送せずページを再取得します。常にメソッドを維持する307や、メソッド処理が歴史的に曖昧だった302とは異なります。ページ間のSEOリダイレクトとしては非常にまれで、URL移行の道具ではなくウェブアプリケーションの仕組みです。**Googleは303を302・307と同じ一般的な「一時的」3xxグループの一員（弱い正規化シグナル）としてのみ説明し、303専用のガイダンスを公開していません。私が確認した範囲ではBingにもありません。**存在しない権威を作らず、語れることは少ないと明言しましょう。

303の実体

303は本文より前のレスポンスヘッダーで返されるHTTPステータスコードで、クライアントが次に取得すべきURLを指すLocationヘッダーを伴います。意味は狭く明確です。リクエストへの応答は別の場所にあるため、GETまたはHEADで取得してください。 Evidence for this claim RFC 9110 defines 303 See Other as directing the client to retrieve another resource identified by Location using GET or HEAD. Scope: HTTP semantics for 303 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.4 — 303 See Other

このGETまたはHEADによる取得動作こそが、303を独立したコードとして存在させる理由であり、3種類の一時的なリダイレクトを分ける軸です。

303・302・307の違い：メソッドの問題

SEOの観点では3つとも「一時的」で、Googleは弱いシグナルとして同じグループにまとめます。ただし技術的には、クライアントがリダイレクトに従うとき、どのHTTPメソッドを使うかという問いへの答えが異なります。

303と307は、302をめぐる混乱を明確化するためにも導入されました。フォーム送信後にメソッドをGETへ固定したいなら303です。元のメソッドを引き継ぎ（たとえば新しいエンドポイントへPOSTを再発行し）たいなら307です。302はどちらにも決めきれない、歴史的に緩い中間にあたります。

もう1つ実務上の違いがあります。303のレスポンスは既定ではキャッシュ可能ではありませんが、301はキャッシュされます。ブラウザーやCDNが移転先を不適切にキャッシュする心配がある場合に重要ですが、303ならその懸念はありません。

Post/Redirect/Getパターンを正確に理解する

PRGは303の典型的な用途であり、エラー状態ではなく意図的で正しい設計パターンです。

1. クライアントがPOSTでフォームを送信します（注文作成、コメント投稿、支払い実行など）。
2. サーバーが副作用を処理し、GET可能な結果URL（領収書、確認ページ、更新済みリソース表示など）を指すLocationヘッダー付きの**303 See Other**を返します。
3. クライアントがそのURLへGET（またはHEAD）で従います。ブラウザーの履歴と更新ボタンは安全で冪等な取得を指すため、再読み込みや戻る操作ではPOSTを再実行せず結果ページを再取得します。

通常のブラウザー更新ならフォームの再送を止められるため、「フォーム再送信を確認」というダイアログは出ません。ただし意味を正確に捉えましょう。PRGが防ぐのはその特定の再送経路であり、重複書き込みのすべてではありません。厳密な一度きりの処理も保証しません。再試行、タイムアウト、ダブルクリック、同時リクエストによって元のPOSTが2回実行される可能性は残るため、注文・支払い・コメント投稿など状態を変える処理には、重複が問題になる場合、冪等性キー、トランザクション境界、重複リクエスト検出などアプリ側の制御が必要です。REST APIでは、影響を受けたリソースの表現へクライアントを送るため、PUTやDELETEの後に303を返すこともあります。

Googleは303をどう扱うか（語れることが少ない理由）

このテーマの中心となる正直な結論は、Googleに303専用のSEOガイダンスはないということです。Googleのリダイレクト文書では、302・307と並ぶ「一時的」リダイレクト表の1行として登場するだけです。Google自身の説明は明確で、クローラーはリダイレクトに従いますが、インデックス処理ではリダイレクト自体を移転先が正規URLであることのシグナルとして使いません。ただし別のシグナルで移転先がインデックスされることはあります。これは恒久的な301が提供する強い正規化とは異なり、範囲も狭いものです。 Evidence for this claim Google groups HTTP 303 with temporary redirects, follows it, and does not use it as a signal that the destination should become canonical. Scope: Google Search canonicalization behavior for server-side temporary redirects. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search

John Mueller自身の非公式なリダイレクト解説は、さらに示唆的です。301、302、307を詳しく説明した後、303については短い脇注でこう述べています。「303？304.5？ほかの種類のリダイレクトに強い思いがあるなら、自由に使ってください。」実務上重要なのは続く点です。「コンテンツをどのURLでインデックスするかは判断する必要があるので、そこにも強い思いがあるなら、別の正規化シグナルを追加してください。」つまり、303を使うことになり、どのURLをインデックスさせるかが重要なら、リダイレクト種別だけに頼らず、rel="canonical"、内部リンク、サイトマップで補強します。

Googleの文書には、これらすべてのコードに共通する重要な注意もあります。同じように扱うとしても、「意味は異なることを忘れず、リダイレクトに適したステータスコードを使う」よう求めています。したがって「SEOでは気にされない」からといって恒久移転に303を付けてよいわけではありません。意図に合うコードを使い、他のクライアントにも正しく動作させてください。 “keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect.” (翻訳)「意味は異なることを忘れず、リダイレクトに適したステータスコードを使う、という注意です。」

Bingは303をどう扱うか

率直に言うと、Bing Webmaster Toolsヘルプの一般的なHTTPステータスコード資料を除き、Bingが303をどう扱うかという公開ガイダンスは見つけられませんでした。Fabrice CanelやMicrosoftの他の人物が303だけを取り上げた検証済みの発言もありません。これは「文書がない」という正当なデータポイントであり、空白を推測で埋めるべきではありません。BingがGoogleの説明と同じ挙動をすると仮定するつもりもありません。文書がないことは同一の扱いの証拠ではなく、Bingについて確定的な答えが必要なら、未解決の問いとして扱うべきです。

303はSEOで意味があるか？ まれです。

正直な結論は、私が公開してきた説明とも一致します。303はページ移行の道具ではありません。*「11 Types Of Redirects & Their SEO Impact」*では、303について「要求したものに似たリソースへユーザーを送り、一時的なリダイレクトとして機能します。ブラウザーの戻るボタンでフォームが再送されるのを防ぐ用途が一般的です。SEO目的で303リダイレクトを使うことは通常ありませんが、使えば302/307と同じように扱われます」と説明しました。

自分の過去の説明にある正直な緊張関係も示しておきます。HTTPステータスコードとSEOへの影響では、303の扱いを「未定義……機能によって301または302として扱われる可能性がある」と説明しました。現在なら、より正確にこう整理します。Googleの文書は、303が302・307と同じ一時的で弱いグループに属すると明確にしています。実務で「未定義」に感じられたのは、303が実際には非常にまれで、Googleがエッジケースを公に明確化する必要がなかったからであり、隠れた強い挙動があるからではありません。文書化された既定（弱い／一時的、302・307と同じグループ）を基本にし、意外な結果は秘密のルールではなく、まれさの結果と考えてください。

意味を持つ可能性があるのは、フォームやチェックアウトが多いサイト、またはステータスコードのクロールで303が現れるAPI駆動アプリくらいです。その場合も通常は「意図どおり動いているので、そのままにする」が答えです。URLを意図的に移すなら303は使わず、恒久移転には301、一時移転には302を使い、メソッドを維持する必要がある場合は308／307を選びます。

303と201・202・204の違い：書き込みに適したステータスを選ぶ

状態を変えるリクエストの後に使えるのは303だけではなく、習慣で選びやすいコードでもありません。ブラウザーのフォームフローではなくAPIなら、3つの2xxコードのほうが適することがよくあります。

• 201 Created — リクエストが1つ以上のリソースを同期的に作成した場合です。主なリソースを特定するため、Locationがあればそこに、なければ対象URI自体を示します。作成が完了し、新しいリソースを別のGET往復なしでクライアントに直接渡したいときに使います。
• 202 Accepted — リクエストを受け付けたものの処理がまだ終わっていない場合です（キュー処理や非同期ジョブ）。応答は意図的に確定させず、現在の状態を説明し、可能ならクライアントがポーリングできる状態監視先を示します。
• 204 No Content — 処理は成功し、返すものが何もない場合です。本文もリダイレクトも不要で、応答はヘッダー部分で終わります。

303はこの3つとは異なる形です。書き込み後にクライアントが別途識別された結果リソースを取得すべき場合、つまりブラウザーのPRGパターンでよく使います。同期作成（201）、非同期受付（202）、単純な成功で追加処理がない場合（204）の代替にはなりません。それぞれがリダイレクトでは伝えられない固有の結果を示すからです。

よくある誤解

• 「303はページが移動した、または壊れたことを意味する」 — いいえ。通常はPOST／PUT／DELETEの後に返す、メソッドを変更する意図的な応答です。「コンテンツ移転」やエラーのシグナルではありません。「ページが移動したためブラウザーがURLを見つけられない」と説明するサイトは、301／302や404と混同しています。
• 「303は301のようにSEO価値を渡す」 — そうではありません。Googleの文書では302・307と同じ一時的で弱いグループです。
• 「SEO担当者は一般的なリダイレクトに303を使うべきだ」 — そのためのコードではありません。フォーム／API向けの狭いパターンで、通常のURL移行に使うのは異例です。
• 「Googleには303専用の詳細ルールがある」 — ありません。グループ内で一度触れられ、Muellerが「自由に使ってください」と肩をすくめた記録がすべてです。
• 「303と302は技術的に同じだ」 — 検索上の扱いは同じグループでも技術的には異なります。303は後続リクエストをGETまたはHEADに変えますが、302のメソッド処理は歴史的に一貫していませんでした。だからこそ303と307が302を明確化するため導入されました。

このコードの位置づけ

303は一時的リダイレクト群の1つです。最も近いのは、同じグループにまとめられることが多い緩やかな一時リダイレクトの302と、メソッドを維持する反対側の307です（307はメソッドを維持し、303はGETまたはHEADへ切り替えます）。一方、301はランキングシグナルを実際に集約し、303には想定されていないURL移行を担う恒久リダイレクトです。全体像（恒久的な301／308、一時的な302／303／307、消滅を示す404／410、5xxエラー）は、このページが属するHTTPステータスコードのクラスターを参照してください。

303フローを安全に検証する

実際の環境で303を信頼する前に、盲目的に自動追従せず確認します。Locationの値自体（絶対か、相対か、解決可能か）を調べ、リダイレクトループや不要なチェーンがないかを確認し、後続リクエストが実際にGETまたはHEADを使っていること、最終応答のステータスと内容を確認します。フォームやAPIフローでは、元の書き込みが再実行されていないことをアプリケーションログでも確認してください。

注意点が1つあります。単一クライアントの挙動を普遍的なルールに一般化しないでください。ブラウザー、HTTPクライアント、フレームワークの自動追従は、製品・バージョン・設定によって異なります。特定のクライアント／バージョンの報告は、すべてに当てはまる証拠ではありません。URLレベルのチェッカーでリダイレクトと移転先の形は確認できますが、冪等性、資格情報の扱い、オリジン間セキュリティまでは検証できないため、実際の送信フローをテストする必要があります。

AI summary

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

• 303 = HTTP「303 See Other」 — 元のリクエストのメソッドに関係なく、クライアントに別リソースをGETまたはHEADで取得させる一時リダイレクトです。
• Post/Redirect/Get（PRG）パターンのために存在します： POST（フォーム送信）→ 303 → GET／HEADの結果ページ。更新や戻る操作では元のPOSTを再送せず結果ページを再取得します。これはブラウザー更新による再送を特に防ぎますが、厳密な一度きりの保証ではありません。再試行、タイムアウト、ダブルクリック、同時リクエストによる書き込み重複を防ぐには、冪等性キーやトランザクション検査などアプリ側の制御が必要です。
• 違いの軸はメソッドです： 303はGET／HEADへ切り替え、307は常にメソッドを維持し、302は歴史的に曖昧でした。303と307は302を明確化するため導入されました。
• ステータスだけではヒューリスティックにキャッシュされません（301とは異なります）。別途取得される結果リソースが独自のキャッシュポリシーを持ちます。
• 201／202／204の代替ではありません： 303はクライアントが別の結果リソースを取得する場合に適し、同期作成（201）、非同期受付（202）、本文のない成功（204）を置き換えません。
• SEOの現実は明快です： Googleは303を302・307と同じ「一時的」リダイレクト群の1行としてのみ文書化しています。リダイレクト自体は移転先を正規URLにするシグナルではありませんが、別のシグナルでインデックスされる可能性はあります。これは恒久的な301の正規化より狭い扱いです。Googleに303専用のガイダンスはなく、Bingでも見つかりませんでした。 Bingの文書がないことはGoogleと同じ扱いの証拠ではありません。John Muellerの説明も「303？……自由に使ってください」という趣旨で、どのURLをインデックスさせたいかが重要なら、他の正規化シグナルで補うよう述べています。
• SEOで関係することはまれです： URL移行の道具ではなくウェブアプリケーションのパターンです。PatrickがAhrefsで説明したように、SEO目的で303を使うことは通常なく、使えば302／307と同じように扱われます。
• 壊れたページや移転ページと混同しないでください。 303は意図的な応答でありエラーではありません。URLを実際に移すなら303ではなく、恒久移転の301または一時移転の302を使います。

公式ドキュメント

303に特化した一次資料のSEO文書はほとんどありません。他の一時的リダイレクトとまとめて、付随的に触れられるだけです。関連する資料は次のとおりです。

Google

• Google検索とリダイレクト — HTTP 303 (see other)を302・307と同じ「一時的」リダイレクト群に掲載しています。303専用の扱いに関する注記はありません。
• HTTPステータスコード、ネットワーク、DNSエラーがGoogle検索に与える影響 — 3xx節で303 (see other)を列挙し、Googleがこれらの一時的コードを弱いシグナルとして扱う一般則を示す一方、「意味は異なる」と注意しています。

Bing / Microsoft

• 303専用のガイダンスは見つかりませんでした。Bing Webmaster ToolsのヘルプはHTTPステータスコードを一般的に扱いますが、303だけを取り上げてはいません。

技術資料（SEO資料ではありません）

• MDN — 303 See Other — PUT／POST／DELETEとPRGの用途を素早く確認できる資料です。ただし「常にGET」という表現は現行仕様より緩くありません（下記参照）。
• RFC 9110 — HTTP Semantics, §15.4.4 — 支配的な技術定義です。Locationの移転先は元の対象と同等ではなく、ユーザーエージェントは常にGETではなくGETまたはHEADで取得します。

出典からの引用

303に関する公的な発言は多くありません。この少なさ自体がテーマの実情なので、無理に水増しせず、確認できる範囲を正直に示します。各リンクは引用箇所へ直接移動します。

Google／John Mueller — 303についての（非常に短い）記録

• 「What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them. We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.」 (翻訳)「303？304.5？ほかの種類のリダイレクトに強い思いがあるなら、自由に使ってください。コンテンツをどのURLでインデックスするかは判断する必要があるので、そこにも強い思いがあるなら、別の正規化シグナルを追加してください。」 — John Mueller、個人ブログ『検索エンジン向け301・302・307…ガイド』。Google関係者による303への最も直接的な発言ですが、意図的に肩の力を抜いた内容です。 Jump to quote

Google — 303が受け継ぐ「一時的グループ」の扱い

• 「By default, Google’s crawlers follow the redirect… Google systems use the redirect as a weak signal that the redirect target should be processed.」 (翻訳)「既定ではGoogleのクローラーがリダイレクトに従い、Googleのシステムはリダイレクト先を処理すべきことを示す弱いシグナルとしてリダイレクトを使います。」（303が属する一時的リダイレクトのGoogleによる説明） — Google Search Central『HTTPステータスコード…がGoogle検索に与える影響』。 Jump to quote
• “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…” (翻訳)「Googleはこれらのステータスコードを同じように扱いますが、意味は異なることを忘れないでください。リダイレクトに適したステータスコードを使ってください……」 Jump to quote

MDN — 改めておきたい一般的な表現

• 「The method used to display this redirected page is always GET.」 (翻訳)「このリダイレクト先ページを表示するために使われるメソッドは常にGETです。」 — MDN『303 See Other』。 Jump to quote — 無批判に繰り返すのではなく、注意書きとして扱うべき表現です。現行仕様は「常にGET」より許容範囲が広く、RFC 9110 §15.4.4は後続取得をGETまたはHEADと定義し、Locationの対象を異なる非同等リソースとしています。この技術的事実が、メソッドを維持する307と、歴史的に曖昧な302から303を分けます。

Patrick（Ahrefs）— SEOにおける実務上の結論

• 「A 303 redirect forwards the user to a resource similar to the one requested and is a temporary form of redirect. It’s typically used for things like preventing form resubmissions when a user hits the ‘back’ button in their browser. You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.」 (翻訳)「303リダイレクトは、要求したものに似たリソースへユーザーを送り、一時的なリダイレクトとして機能します。ブラウザーの戻るボタンでフォームが再送されるのを防ぐ用途が一般的です。SEO目的で303リダイレクトを使うことは通常ありませんが、使えば302／307と同じように扱われます。」 — Patrick Stox『リダイレクトのSEOへの影響』（Ahrefs）。 Jump to quote

303 See Otherの誤用

303を一般的な「ページ移動」コードとして扱う

303は通常、状態を変えるリクエストの後にクライアントを別リソースへGETまたはHEADで送るためのものです。恒久的なページ移転には301、通常の一時的なページリダイレクトには302を使います。

元のメソッドを維持すべきときに303を使う

このコードは後続リクエストで元のメソッドを意図的に破棄します。POST、PUT、DELETE、Webhook、APIペイロードをそのまま移転先へ届ける必要があるなら、307（一時的）または308（恒久的）を使います。

303を強い恒久SEOシグナルとして説明する

Googleは303を301／308ではなく一時的リダイレクトに分類します。URL移行の統合に使ったり、恒久移転のように動作すると主張したりしないでください。

GoogleやBingに303専用の詳細ルールがあると考える

Googleが示すのは一時的リダイレクトとしてのグループ扱いだけで、この記事で確認できるBingの専用公開ガイダンスもありません。文書の空白を確実性で埋めず、結論は狭く保ってください。

302と303は技術的に同一だと呼ぶ

検索上の扱いは同じグループでも、メソッドの意味は異なります。303の後続リクエストはGETまたはHEADですが、302では歴史的にPOSTからGETへの曖昧な挙動が許されていました。

クライアント・資格情報・オリジン間の挙動を普遍化する

具体的なクライアント、バージョン、設定を示さずに、「ブラウザー」や「クライアント」が303をまたぐリクエスト本文、ヘッダー、Cookie、資格情報をどう扱うかを事実として述べないでください。自動追従や資格情報の転送は異なります。1つの課題スレッドや逸話はすべてのクライアントの証拠ではなく、実際のフローに対するセキュリティレビューの代わりにもなりません。

生のHTTPで見るPost/Redirect/Get

この簡略化したフローは、303が得意とする狭い役割を示します。

1. ブラウザーがフォームを送信する

POST /orders HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

item=book&quantity=1

2. サーバーが処理し、結果を指し示す

HTTP/1.1 303 See Other
Location: /orders/confirmation

303は新しいURLでPOSTを繰り返しません。別リソースをGET（またはHEAD）で取得するようクライアントに明示し、リンクに従うブラウザーはGETで取得します。

3. ブラウザーが安全な結果ページを取得する

GET /orders/confirmation HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Order received</h1>

ここで更新すると繰り返されるのはGETであり、注文を作成するPOSTではありません。対照的に307はPOSTとその本文を維持します。APIリクエストの移転には便利ですが、このPRGの結果には不適切です。

自分で確認：303 See Other

303リダイレクトについての5つの短い質問です。各問に答えてから確認しましょう。

変更履歴