SEOのHTTPステータスコード：200・301・404・503

URLが消えると、技術チームはSEO担当に「このページは何のコードを返すべきですか」と尋ねることがあります。答えは暗記した表の中にあるわけではありません。代替コンテンツがあるか、中断が一時的か恒久的か、次のアクセスでクローラーに何をしてほしいかによって決まります。

誤ったHTTPステータスは、200を返すエラーページ、多段のリダイレクト、クロール速度を低下させる数千の503URLを生む可能性があります。正しく選べば、ブラウザ、検索ボット、キャッシュ、監視システムが同じ状態を理解できます。

HTTPステータスはサーバーからのメッセージです

ブラウザやクローラーがURLを要求するたびに、サーバーはステータスコードで応答します。主な分類は5つあります。

• 1xx：処理中の情報です。
• 2xx：リクエストを正常に処理しました。
• 3xx：別のアドレスや状態へ進む必要があります。
• 4xx：送信されたクライアントの要求には応えられません。
• 5xx：サーバーが有効なリクエストを完了できません。

SEOでは、ステータスコードとユーザーが見る内容を一致させる必要があります。「商品が見つかりません」と表示して200 OKを返すと、ソフト404になります。内容が完全に表示されていても500を返せば、クローラーはその内容を無視します。ステータスと本文が、異なる状態を伝えるべきではありません。

2xx：成功してもインデックス登録が保証されるわけではありません

200 OK：成功

200は、サーバーが正常に応答したことを示します。Googleは内容を次の処理へ進められますが、インデックス登録を約束しません。noindex、別URLへのcanonical、価値の低い内容、重複、品質シグナルの不足により、除外される可能性があります。

実際のコンテンツがあるURLだけに200を返してください。商品や記事を削除した後も、すべてのアドレスを「生かす」ために使わないでください。

204 No Content：本文なし

204は、要求は成功したものの本文がないことを示します。一部のAPIやコンテンツ不要の操作には適しますが、検索結果に出したいランディングページには不適切です。空のHTMLページでは、成功系のステータスでも有用な検索結果を作れません。

206 Partial Content：部分的なコンテンツ

206は、動画や大きなファイルなど、リソースの一部をクライアントが要求した場合によく使います。HTMLページの既定コードではありません。CDNやプロキシが突然すべてのドキュメントに206を返すなら、範囲リクエストとキャッシュの設定を確認してください。

3xx：意図を持ってアドレスを移動する

301 Moved Permanently：恒久的な移動

URLが恒久的に移動し、同等の移動先がある場合に301を使います。代表例は次のとおりです。

• 記事のスラッグ変更。
• HTTPからHTTPSへの移行。
• 同じ検索意図を持つ2記事の統合。
• カテゴリ構造の変更。
• 古い商品から、実質的に同等の後継版への移行。

移動先は、古いURLのニーズに近い必要があります。品切れ商品をホームページや広すぎるカテゴリへ転送すると、不満を招き、ソフト404と判断される可能性もあります。

302 Found：一時的な移動

302は、短期テスト、代替アドレスのあるメンテナンスページ、期間限定の振り分け、元のURLへ戻るキャンペーンなど、一時的な転送に適します。恒久的な移動になったら、すべてのシステムに意図が明確になるよう301へ変更してください。

実際には、Googleは全体のシグナルから、複数のリダイレクトを似た形で扱うことがあります。それでも、ブラウザ、キャッシュ、他のクライアント、保守担当者のために、正しいコードを選ぶことは重要です。

303 See Other：別リソースの参照

303は、POSTの後にGETで結果ページへ誘導する際によく使われます。例えば、フォーム送信後の確認ページへの移動です。これはアプリケーションのパターンであり、SEO用URL移行の主要手段ではありません。

307と308

307 Temporary Redirectと308 Permanent Redirectは、転送時にHTTPメソッドを維持します。308は恒久的、307は一時的な意味です。通常のGETリクエストでは移行に使えますが、フォームやAPIに使う前に、技術チームはメソッドの挙動を理解する必要があります。

リダイレクトチェーン：複数世代のURLにまたがる判断

記事がAからB、さらにCへ移ったとします。AがBへ、BがCへ転送し続けると、毎回2段階の移動が必要です。長年運営するサイトでは、誰も設計していない5〜6段階のチェーンが生まれることがあります。

影響は次のとおりです。

• ユーザーとクローラーの待ち時間が増えます。
• サーバーへのリクエストが増えます。
• canonicalや分析のデバッグが難しくなります。
• 途中のエラーやループのリスクが高まります。
• 廃止した構造への内部リンクが残ります。

各旧アドレスは現在の移動先へ直接向けるべきです。Redirect Chain Checkerで、すべての段階、ステータス、ループ、最終URLを確認してください。その後、内部リンク、canonical、サイトマップを最終アドレスに更新し、無期限にリダイレクトへ依存しないようにします。

4xx：URLまたはアクセス権限の問題

400 Bad Request：不正なリクエスト

クローラーとブラウザーの応答が異なる場合は、実際のリクエストと閲覧権限のあるサーバーまたはエッジのログを確認します。公開 Cloudflare 検出では WAF ルール、ヘッダー制限、アカウントポリシーは分かりません。

401 Unauthorized：認証が必要

401は認証を要求します。ログイン領域、非公開API、権限付き資料に適しています。順位を獲得したいコンテンツで、クローラーにログインを強いることはできません。クロール調整に401を使わず、サーバー負荷とURL構造を適切な場所で改善してください。

403 Forbidden：アクセス拒否

403は、要求を理解したものの提供を拒否することを示します。強すぎるCDN、WAF、ボット対策の設定が、正当なクローラーに誤って拒否応答を返す場合があります。公開ページが一斉にインデックスから消えたら、ユーザーエージェント文字列だけを信じず、時刻、ユーザーエージェント、検証済みIPでログを照合してください。

404 Not Found：見つかりません

404は、リソースがなく同等の代替もない場合の正しい応答です。すべての404がリダイレクトを要する「SEOの問題」ではありません。入力ミスのURL、完全に廃止した商品、削除したテスト記事は、通常どおり404を返せます。

404ページには、次を備えるべきです。

• 内容がなくなったことを簡潔に説明します。
• 適切であれば、ナビゲーションや検索欄を設けます。
• 自動転送せず、関連する領域を案内します。
• 200ではなく、引き続き404を返します。

410 Gone：削除済み

410は、意図的にリソースを削除したことを明示します。Google Searchでは、404も410も、その状態が続くとURLがインデックスに保持されなくなります。終了したことをシステムが確実に把握していれば410、単に見つからないなら404を選びます。早く削除されることを期待するだけで、数千の正常な404を410へ変更する必要はありません。

429 Too Many Requests：リクエスト過多

429は、クライアントの要求が多すぎることを示します。Googleはサーバー過負荷のシグナルとみなし、クロールを一時的に遅くする場合があります。頻繁にクローラーへ429を返すなら、割り当て、キャッシュ、識別ルールを見直してください。無制限に開放することも解決策ではなく、目標は安定した提供です。

5xx：サーバーが処理に失敗している

500 Internal Server Error：サーバー内部エラー

500は、アプリケーションやサーバーの未特定エラーです。一時的なエラーは起こり得ますが、多数のURLで高率に発生するなら、リリース、データベース、依存先、システム資源に問題があります。

502 Bad Gateway：不正な上流応答

502は、プロキシやCDNが上流から有効な応答を受け取れない場合によく発生します。アプリケーションサーバーの状態、層間のタイムアウト、内部DNS、接続上限を確認してください。

503 Service Unavailable：一時的に利用不可

503は、メンテナンスや一時的な過負荷に適しています。Retry-Afterヘッダーで再試行時期を伝えられます。メンテナンスページは200ではなく503を返す必要があります。そうしないと、検索エンジンはすべてのURLで同じ「メンテナンス中」のページを見る可能性があります。

実際にはサイトが閉鎖済み、またはURLが消えているのに、何日も503を続けないでください。サーバーエラーが長引くと、登録済みURLが徐々に除外され、サイト全体のクロールが遅くなる可能性があります。

504 Gateway Timeout：上流の応答待ち時間超過

504は、ゲートウェイが上流の応答を待ちすぎたことを意味します。遅いデータベースクエリ、依存API、キャッシュミス、ワーカー不足、CDNとサーバーのタイムアウトの不整合を調べてください。

状況別のステータス選択表

この表は出発点です。ECでは、一時的な品切れ商品は200を維持し、商品情報、在庫状態、代替候補を残すべきです。恒久的に販売終了し、ほぼ同等の後継モデルがあれば301を使えます。適切な代替がなければ、404や410の方が実態に合っています。

ソフト404：ステータスは成功でも内容は失敗

ソフト404は、次のような場合によく起きます。

• 商品のないページが200を返します。
• 誤ったURLがすべてホームページを表示します。
• 検索結果がないページがインデックス登録可能になっています。
• 内容が削除され、ヘッダーとフッターだけが残っています。
• 無関係なURLを広いカテゴリへ転送しています。

Search Consoleのページのインデックス登録レポートを確認し、URLを抽出してください。検出を避けるためにエラーページの文言だけを変えるべきではありません。正しいステータスを返すか、そのクエリに本当に役立つ内容を提供してください。

Robots.txtはステータスコードの代わりになりません

Robots.txtで/old-pageを許可しない設定は、クローラーに本文を取得できないと伝えるだけです。そのため、移動したのか、消えたのか、認証が必要なのか分からないまま、検索結果にページが残る場合があります。Robots.txt Checkerで確認してください。

URLが移動したら転送します。消えたら404または410を返します。利用できるが登録したくないなら、クローラーがアクセスしてnoindexを読めるようにします。Robots.txt Checkerは誤遮断を検出しますが、URLのライフサイクルは応答で示す必要があります。

見栄えのよい数URLだけでなく、テンプレート別に監査する

ホームページが200を返すだけでは、商品一覧の健全性は分かりません。テンプレート別に抽出して集計してください。

1. ホームページと主要ナビゲーション。
2. カテゴリ、ページ送り、フィルター。
3. 在庫あり、一時品切れ、販売終了の商品。
4. 新規、旧記事、スラッグ変更済み、削除済みのブログ記事。
5. パラメータ、大文字、スラッシュ、異なるホスト名を持つURL。
6. サイトマップ、robots.txt、主要画像、重要ファイル。

ステータスをcanonical、meta robots、サイトマップ、内部リンクと照合します。301のURLをサイトマップに残すべきではありません。404ページに数千の内部リンクを向けるべきではありません。登録したい200ページのcanonicalを他へ向けるべきではありません。

SEO Checkerで代表URLの応答とページ内シグナルを確認し、その後無料SEO監査でテンプレート単位の反復する問題を見つけてください。

トラフィックが減る前に監視する

5xxの割合、応答時間、重要URLのステータス変化にアラートを設定します。デプロイや移行のたびに、次のスモークテストを行ってください。

• ホームページ、ログインページ、収益ページ。
• 各テンプレートの代表URL。
• Robots.txtとサイトマップインデックス。
• 旧URLからのリダイレクト。
• 実際に404になることを確認する存在しないURL。

サーバーログには、ステータス、パス、所要時間、ユーザーエージェント、リクエストIDを、変更前後を比較できる十分な期間保存するべきです。ボットや特定地域だけに起きる障害では、1台のノートPCから再読み込みするより、通常はログの方が早く答えを得られます。

まとめ

HTTPステータスコードは、サーバーとクライアントの短い契約です。SEOでは、その契約から、内容が存在する、移動した、削除された、一時的に提供できないという状態を理解します。URLの実際のライフサイクルに合うコードを選び、本文と一致させ、変更のたびにサイトマップと内部リンクを整理してください。

すべてのエラーをホームページへ転送したり、空ページに200を返したり、未決定の判断をrobots.txtで隠したりしないでください。ステータスが明確なら、ユーザー、クローラー、運用チームが推測する負担を減らせます。

参考資料：Google Search CentralのHTTPコードがクローラーへ与える影響の解説、リダイレクトの処理ガイド。