SEOで重要なHTTPステータスコード｜200・3xx・4xx・5xxの意味
目次
HTTPステータスコードは、ブラウザや検索エンジンがURLへアクセスしたとき、サーバーが返す処理結果です。画面が表示されていても、裏側で誤ったコードを返していると、検索エンジンはページの状態を正しく判断できません。
ECサイトでは、販売中、移動、終了、アクセス制限、障害といった状態に合うコードを返すことが重要です。すべて200にするのではなく、URLの現在地を機械にも伝えます。
200は正常なページ
200は、リクエストが成功し、内容を返したことを示します。販売中の商品、公開カテゴリ、記事など、正常に表示するページで使います。
ただし、200なら必ずインデックスされるわけではありません。noindex、canonical、内容、重複なども評価されます。また、商品が存在しないのに200で「見つかりません」と表示すると、soft 404として扱われる可能性があります。
3xxは転送
3xxは別URLへの転送を示します。301や308は恒久的な移動、302や307は一時的な移動として使います。旧商品URLを後継商品へ統合するなら恒久、短期間のメンテナンスやテストなら一時というように期間で判断します。
転送先は、利用者の意図に最も近いページを選びます。関係のない旧商品をすべてトップページへ送ると、soft 404と判断される場合があります。
404と410は存在しないページ
404はリソースが見つからないこと、410は恒久的に削除されたことを示します。販売終了商品で適切な代替先がなく、ページを残す価値もない場合に使えます。
利用者向けには、状況説明、検索、主要カテゴリへのリンクを含む分かりやすいエラーページを表示できます。ただしHTTP応答は404または410のままにします。
401と403はアクセス制限
401は認証が必要、403はアクセスを拒否している状態です。会員専用情報や管理機能は、noindexだけでなく実際の認証・認可で保護します。
検索対象にしたい商品ページが誤って403になる場合は、CDN、WAF、bot対策、地域制限を確認します。一般のブラウザでは表示できても、Googlebotだけ拒否していないかをログで調べます。
429はリクエスト過多
429は、短時間に多くのリクエストがあり処理できない状態を示します。検索エンジンのクローラーはサーバー過負荷の手掛かりとして扱い、取得を一時的に減らすことがあります。
通常のアクセス制御へ安易に使わず、レート制限の条件を確認します。セールや商品フィード更新時に429が増えるなら、キャッシュ、サーバー容量、不要URLへのアクセスを見直します。
5xxはサーバー側の障害
500、502、503などはサーバー側で処理できない状態です。継続するとクロールが減り、すでに登録されたURLも時間とともに検索対象から外れる可能性があります。
短いメンテナンスでは503を返し、復旧後に200へ戻す方法があります。障害ページを200で返すと正常ページとの区別がつかないため、適切なコードと監視が必要です。
304は未更新の再利用
クローラーが以前取得した内容から変わっていない場合、304 Not Modifiedを返すことで、同じ本文を再送せずキャッシュを利用できます。大規模サイトではサーバー資源の節約に役立ちます。
Last-ModifiedやETagの実装が実際の更新と一致していることが前提です。商品価格や在庫が変わったのに304を返すと、古い情報が使われる可能性があります。
ブラウザ表示だけでは判断できない
ブラウザは転送後の画面だけを表示するため、途中のコードや転送回数が分かりにくいことがあります。開発者ツール、コマンド、クロールツール、サーバーログで最初の応答から確認します。
商品URLのサンプルは、販売中、在庫切れ、販売終了、誤ったID、転送済みを用意します。状態変更のたびに期待するコードを自動テストできると事故を防げます。
Search Consoleで確認する
ページのインデックス登録レポートやURL検査では、404、サーバーエラー、転送エラーなどを確認できます。件数の増加を見つけたらURL例と発生時期を調べます。
エラーが意図した販売終了なのか、商品公開フローの障害なのかを分けます。404が存在すること自体ではなく、重要URLが誤った状態になっていないかが判断基準です。
よくある間違い
- 存在しない商品にも200を返す
- すべての販売終了商品をトップへ転送する
- 一時的な障害で恒久的な404を返す
- WAFがGooglebotへ403を返していることに気づかない
- 5xxや429の増加を監視しない
確認項目
- 販売中ページが200か
- 恒久移動と一時移動を使い分けているか
- 終了ページが404、410または適切な転送か
- エラー画面が200を返していないか
- 5xxと429を継続監視しているか
- 状態変更を自動テストしているか
商品状態とステータスを対応させる
商品管理上の状態とHTTPステータスは一対一ではありません。販売中は200、一時欠品も情報を残すなら200、終売で後継ありなら301、終売で代替なしなら404または410というように、利用者へ提供できる価値で決めます。
「非公開」という一つの管理フラグに、発売前、審査中、販売停止、データ不備が混在すると誤った応答になります。状態を細分化し、表示文言、リンク、サイトマップ、ステータスを対応表にします。
エラー監視の優先順位
5xxや429がサイト全体で増えた場合は、クロールだけでなく購入にも影響するため最優先です。主要商品やカテゴリの404も急いで調べます。一方、外部からの誤URLによる少数の404は自然に発生します。
ステータス別の件数だけでなく、URL種別、発生時刻、参照元、応答時間を確認します。デプロイ直後、商品一括更新時、セール開始時などとの関連を見ます。
CDN・WAF・アプリの応答を分ける
利用者が受け取るステータスは、アプリケーションだけでなくCDN、ロードバランサー、WAFが返す場合があります。アプリが200でもCDNが503、一般ブラウザは200でもbot対策がGooglebotへ403ということがあります。
各層のログと監視を用意し、どこでコードが変わったかを追えるようにします。キャッシュ済みエラーページが200で配信されないかも確認します。
リリース時の自動テスト
公開前後に、正常商品、在庫切れ、終売、存在しないID、旧URL、ログインページを自動で取得します。最初のステータス、転送回数、最終ページ、canonicalを期待値と比較します。
テンプレートやルーティングの変更は広いURLへ影響します。少数の画面確認だけで完了せず、ページ種別ごとの代表URLを継続的な回帰テストへ入れます。
障害時の応答を設計する
商品APIだけが停止したとき、共通ヘッダーと空の商品枠を200で返すのではなく、復旧可能な障害として5xxを返すか、キャッシュ済みの商品情報を安全に表示するかを決めます。古い価格や在庫を表示する場合は購入処理との整合も必要です。
計画メンテナンスでは503を返し、可能ならRetry-Afterで再試行時期を示します。メンテナンス終了後に503がキャッシュされ続けないよう、CDNと監視を確認します。
ECサイトでの確認例
販売中商品、在庫切れ、終売、未発売、存在しないIDを同じテンプレートで開き、ステータスと画面を比較します。終売商品が200で残るなら、商品情報と代替導線があるかを確認します。
旧商品URLの301は最終商品へ一回で到達し、転送先が200かを見ます。カートやログインは認証状態によって401、403、200が変わるため、検索対象ページと会員機能を分けてテストします。
まとめ
HTTPステータスコードは、URLが正常、移動、終了、制限、障害のどの状態かを検索エンジンへ伝えます。画面の見た目とHTTP応答を一致させることが基本です。
ECサイトでは商品状態ごとの期待コードを定義し、販売開始、終了、再公開、障害復旧をテストしてください。主要URLの誤った4xxや5xxを早く見つける監視も、テクニカルSEOの重要な運用です。
