HTTPステータスコード クローラーの要求、コンテンツの読み込み、ページが検索に表示されるかどうかなどを制御します。200、301、404、503 などの応答が、クロール、クロール予算、ホスティングをどのように連携させ、典型的な障害はどのようなものかを紹介します。.
中心点
- クロール予算 クリーンなステータス応答に直接依存します。.
- 2xx/3xx インデックス作成を可能にし、4xx/5xx をブロックします。.
- 転送 チェーンやループは使用しないでください。.
- サーバー時間 そして、稼働時間はクローラーの信頼性を形成します。.
- モニタリング ログ、GSC、クローラーを使って運営してるよ。.
ステータスコードがクロールを制御する理由
クローラーはまず ステータスコード, 、その後にコンテンツのレンダリングと評価が続きます。そのため、私はタイトルタグや内部リンクよりも回答の正確性を優先しています。200 OK はコンテンツを即座に読み込みますが、4xx および 5xx は時間、予算、信頼を損ないます。エラーが頻繁に発生すると、ボットはアクセスを減らし、新しいコンテンツの登録を遅らせます。その結果、明確なルールによって SEO の損失が静かに発生します。 サーバーの応答 回避することができます。.
2xx: インデックスへの直接アクセス
200 OK はクローラーにとって 青信号. 私は、内容が完全な本物のページにのみ 200 を返し、200 を返すが付加価値のないソフト 404 を防ぎます。コンテンツが乏しい、H1 が欠落している、テキストがほぼ同一であるといった場合は、このような設定ミスがある可能性があるので注意が必要です。 ここで整理することで、クロール予算を節約し、テーマの関連性を強化することができます。さらに、スニペットと内部リンクを最適化して、クローラーとユーザーが 呼びかけ 正しい目標を達成する。.
3xx: 損失のない転送
301 はコンテンツを恒久的に移動し、新しい URL にシグナルを転送します。302 は一時的な解決策を表します。 コンテンツが実際に移動した場合は 301 を使用し、余分なホップは時間と予算を無駄にするため、チェーンやループは削除します。内部リンクを確認してください。内部 301 チェーンは、自ら作り出した渋滞です。移動については、すべてが目的の URL を明確に示すように、一貫したルールを計画します。その重要性を以下で説明します。 リダイレクトチェーン, 、測定可能な読み込み時間とクロールに負荷がかかる。.
4xx: リモートコンテンツの明確なシグナル
404 は明確に伝えています:この リソース ありません。私は、実際に削除されたページには 404 を残し、エラーページには 200 を送信しないことでソフト 404 を回避しています。410 は、ページが完全に削除されたことをより明確に示します。適切な代替ページがない古い URL には、このコードを意図的に使用しています。 404 の内部リンクは予算の無駄なので、私はそれらを速やかに修正するか、最適なテーマの代替ページに意図的にリダイレクトします。そうすることで、クローラーを実際の 価値 を届ける。
5xx:サーバーエラーがボットとユーザーを遅らせる
5xx は、サーバーがリクエストを処理できなかったことを意味します。 操作する. 。頻繁に発生すると、クローラーはサイトを信頼できないと評価し、訪問頻度を減らします。メンテナンスのために、ボットがいつ再取得すべきかを認識できるように、503 に「Retry-After」を設定しています。503 が継続する場合は、ログを分析し、CPU、RAM、データベース、レート制限のボトルネックを解消します。WordPress については、このガイドで実用的なヒントを集めています。 503エラー, メンテナンスの時間を管理し、短く抑えるためです。.
キャッシュ、304、ETag:リスクなしで予算を節約
304 Not Modified を節約 帯域幅, クライアントがそのコピーを引き続き使用できるためです。 私は、クローラーが If-Modified-Since を正しく使用できるように、ETag または Last-Modified を正確に設定しています。これにより、変更されていない CSS、JavaScript、および画像の呼び出しが短縮されます。ロジックが正しくない場合、ボットは不要なファイルを多数ロードしたり、更新を見逃したりします。そのため、私はバリエーションをテストし、レスポンスヘッダーを確認し、304 レスポンスをすべてで一貫して維持しています。 資産.
クロール予算:それを高く保つ方法
クロール予算は、3つの要素、すなわちコードの品質、, パフォーマンス および内部構造。転送チェーン、重複コンテンツ、TTFBの遅延など、時間を浪費する要素を削減します。内部リンクは、ボットが優先順位をより迅速に認識できるよう、少数の明確なパスにまとめます。エラーのあるページや孤立したページは、予算を消費する前に迅速に修正します。これには、ページネーション、正規化、hreflang のステータスコードも含まれます。 エラー信号 走らなければならない。.
ステータスコードに影響を与えるホスティング要因
優れたハードウェア、クリーンなサーバー構成、そして容量に見合った キャッシング 5xxのピークを防止します。十分なPHPワーカー、データベースパラメータ、キープアライブ、HTTP/2またはHTTP/3に注意を払っています。また、ボットのレート制限も、実際のユーザーをブロックしないように適切に設定する必要があります。負荷のピーク時には、エッジキャッシュと静的アセットのルールが役立ちます。ステータスコードとホスティングパフォーマンスが関連している理由については、こちらをご覧ください。 HTTPステータスとサーバーパワー.
モニタリング:ログ、GSC、クローラーを正しく活用する
サーバーログから始めます。なぜなら、それらは実際の お問い合わせ 表示し、すべての回答を記録します。その後、Search Console でカバレッジエラー、サイトマップ、レンダリングステータスを確認します。 SEO クローラーによるデスクトップおよびモバイルのクロールでは、リダイレクト、4xx、5xx を 1 回の実行で検出します。詳細な分析のために、エラーをリリースやトラフィックピークのタイミングと関連付けます。これにより、ロールアウト、プラグイン、CDN ルールセットが 回答 変化した。.
概要:ステータスコードと対応策
次の表は、典型的な回答を適切なステップに分類し、ホスティングのポイントを強調したものです。私は、日常的な迅速な意思決定の指針としてこの表を利用しています。.
| ステータスコード | クローラーの反応 | アクション | ホスティングに関する注意 |
|---|---|---|---|
| 200 OK | コンテンツが取得され、評価されます。 | 本物のコンテンツを提供し、ソフト404を回避する | TTFBを低く保ち、キャッシュを温める |
| 301 恒久的に移動しました | ターゲットURLへの信号 | チェーンを削除し、内部リンクを更新する | リライトルールを明確に保つ |
| 302 発見 | 一時的、ソースは信号を保持 | 短期間のみ使用 | 定期的に確認する |
| 304 変更なし | キャッシュを使用、ダウンロードなし | ETag/Last-Modified を正しく設定する | CDN によるアセットの配信 |
| 404 見つかりません | URLがインデックスから削除されます | 内部リンクを修正し、ソフト404を回避する | エラーページをスリムに保つ |
| 410 Gone | より迅速な除去 | 恒久的に削除されたコンテンツに使用 | 真の選択肢がある場合にのみ転送 |
| 500 内部エラー | ボットが訪問数を減らす | ログを確認し、原因を修正する | リソースと制限の増加 |
| 503 サービス利用不可 | メンテナンスモードを受け入れる | „「再試行後」を設定し、時間を短く保つ | メンテナンスウィンドウの計画 |
エラー処理:私が最初に確認すること
私はまず スコープ:このエラーはすべてのユーザーに影響しているのか、ボットのみか、モバイルのみか?その後、サーバー、アプリケーション、CDN のいずれで最後に変更があったかを確認します。負荷がかかった場合にのみエラーが発生する場合は、一時的にリソースを増やし、トレースでボトルネックを探します。 5xx が繰り返し発生する場合は、ログパターンとステータスエンドポイントにアラートを設定します。これにより、差し迫った問題を迅速に解決し、それが クロール予算 さらに引き下げる。.
リリース前の技術チェック
ロールアウトの前に、クリティカルパスを ステージング-クロールして、ステータスコードをライブバージョンと比較する。重要なURLのリストを用意しておく:ホームページ、カテゴリー、製品、フィルター、検索、サイトマップ、API。その後、キャッシュコントロール、バリアブル、リダイレクトルール、正規化などのヘッダーをチェックする。機能フラグについては、意図せずに302や404を生成しないように、明確な条件を設定する。 ステータスコード、ロード時間、レンダリング結果が安定していることが確認できた場合にのみ、 リリース 無料だ。
robots.txt、サイトマップ、およびサブURL
私はまず、次のことを確認する。 robots.txt 200 で安定して応答します。robots.txt で 5xx または 403 を返すと、クローラーが不安になり、クロールが抑制されます。robots.txt で 404 を返すことは「制限なし」とみなされますが、クロールに問題のあるサイトにとっては悪いシグナルとなります。 サイトマップ 私は 200 のみを受け入れ、ファイルは小さく、gzip で圧縮され、正しい lastmod フィールドを持つもののみとします。サイトマップへの 3xx は技術的には許可されていますが、直接の 200 応答を優先して回避します。 フィード, AMP- または API-リソースについては、HTMLページが200を返す場合に404や5xxを返さないよう注意しています。そうしないと、レンダリングや構造化データの評価が不安定に中断してしまうからです。.
Canonical、Hreflang、およびページネーションは 200 のみ
次のような信号 rel=canonical, hreflang またはページネーションは、ターゲットURLと参照URLが200で最終的にロードされた場合にのみ効果を発揮します。3xx、404、noindex URLへの正規化URLは、クローラーを混乱させるため避けています。hreflangについては、以下を確認しています。 逆参照 そして、どのバリエーションも最終的には 200 で終わることを確認します。ページ番号付きリスト (page=2,3,…) は、確実に 200 を返さなければなりません。私は、結果がない場合に明確なコンテンツと内部リンクを提供し、それでも正しいステータスを送信することで、空のページがソフト 404 を発生させることを防ぎます。.
429 とレート制限を正しく使う
429 リクエストが多すぎる 個々のボットが攻撃的すぎる場合に、細かい調整を行うためのツールです。私は 再試行後 クローラーがリクエストを分散できるように、適切な時間指定をしてください。429 は 503 メンテナンスの代わりにはならず、正当なユーザーに影響を与えてはいけません。 WAF または CDN では、ユーザーエージェント、IP、パスを区別して、メディアアセットは 200/304 を引き続き配信し、HTML は一時的にスロットリングします。重要:429 は永続的なものにしてはいけません。そうしないと、ボットはサイトへのアクセスが困難であると判断し、予算を減らしてしまいます。.
401/403/451:意図的にブロックされている – しかし一貫性がある
401 ログイン保護された領域に使用します。, 403 不正アクセスに対して。私は、厳格なボットフィルターなどを通じて、これらの応答が誤って Googlebot に適用されないように注意しています。地理的制限や法的要件がある場合は、 451 その理由を社内で記録します。インタースティシャル(「アクセス拒否」)による 200 応答は使用しません。このようなページはソフト 404 と同じような効果があります。代替手段がある場合は、アクセス可能なコンテンツに明確にリンクし、ブロックされた URL は正しい 4xx ステータスを送信するようにします。.
回答の均等性:モバイル、デスクトップ、動的な再生
モバイルボットとデスクトップボットが同じ ステータスコード 見る。動的な再生(A/B テスト、機能フラグ、地理的コンテンツ)は、個々のユーザーエージェントに対して 302/403 をトリガーしてはなりません。私は 可変-ヘッダーは控えめに、意識的に(例:Accept-Language)使用して、不要なキャッシュの分割を避け、すべてのバリエーションのパスが 200/304 で一貫して終わるよう注意してください。 パリティの破損は、ボットが 404 を認識する一方でユーザーが 200 を認識する場合、インデックス作成の問題につながります。私は、明確なルールとバリエーションごとのテストによって、このようなケースを排除しています。.
HEAD、OPTIONS、および API エンドポイント
多くのクローラーを送信 HEAD-空き状況やサイズを確認するためのリクエスト。私のサーバーは、GET と同じロジックで応答します。ただし、ボディは含まれません。GET が 200 を返す場合、HEAD で 405 を回避します。. オプション また、CORS プレフライトについては、サードパーティのソースからのアセットが正常にロードされるように処理しています。 APIエンドポイント, レンダリング時にデータを提供するAPIについては、安定した200/304と、実際のエラーでは明確な4xxに注意を払っています。APIが散発的に5xxを返す場合は、HTMLページが200を返しているにもかかわらず、レンダリングエラーの原因となる可能性があるため、ログに別途記録しています。.
CDN ルール、ステール戦略、5xx シールド
CDN では、200、301、および静的な 404 を制御してキャッシュしますが、 503 または管理ページがキャッシュに保存される場合があります。 もしエラーなら ボットがエラーを認識することなく、一時的な 5xx をバイパスすることができます。私は サロゲート・コントロール エッジ信号については、HTML の TTL をアセットよりも短く設定しています。ETag は クラスタ対応 (どこでも同じか無効化)して、304 が確実に機能し、ハッシュの差異によって失効しないようにします。重要:リダイレクト(301/302)は CDN で無期限にキャッシュすべきではありません。そうしないと、古いパスがチェーンとして残ってしまいます。.
Eコマースの事例:売り切れ、バリエーション、フィルター
製品が一時的に在庫切れの場合、製品ページはそのまま残ります。 200 明確な表示と、意味のある内部リンク(カテゴリー、代替品)を付ける。永久に削除された商品については、以下のいずれかを選択する。 301 最適な代替URL(真に一致する場合のみ)および 410, 適切な代替手段がない場合。私は、ソフト404のように機能するホームページへの大量リダイレクトは避けています。 フィルターおよびパラメータURL 私は明確なルールを採用しています。インデックスに関連する組み合わせのみを 200 で、その他は 301 を使用して正規の URL にリダイレクトするか、noindex を設定します。ただし、ソフト 404 検出器をトリガーする、空のページやほぼ同一のページに 200 を設定することは決してありません。.
Noindex、ロボット、ステータスコードを明確に区別する
インデックスなし はコンテンツ信号であり、ステータスコードはトランスポート信号です。クローラーを混乱させる混合形式は避けてください。noindex ページへの 301、リソースが存在しない場合の「アクセス制限」プレースホルダー付き 200 は使用しないでください。 ページは、インデックス可能(200 + index)か、削除済み(404/410)か、一時的に利用不可(503、Retry-After 付き)のいずれかです。robots.txt はクロールのみをブロックし、すでに知られている URL のインデックスはブロックしません。そのため、実際に削除されたコンテンツには 404/410 ロボットのロックの代わりに。.
私が注目している指標と閾値
- 5xxレート:0.1% を大幅に下回る状態が持続する場合。スパイクは直ちに調査すること。.
- 4xxレート:サイトタイプに応じて 1~2%。内部 4xx は 0% に対して行うべき。.
- 3xxの割合: できるだけ低い;; リダイレクト・チェーン 0に設定。.
- 304の割合 資産の場合:高いほど良い – キャッシュが機能していることを示す指標。.
- TTFB HTMLの場合:安定して低い。外れ値は5xx/429と相関関係がある。.
- サイトマップ-健康: 200、有効な lastmod、リンク切れなし。.
- パリティ モバイルとデスクトップ:同じステータスコードと最終URL。.
私はこれらの指標を、デプロイ、トラフィックのピーク、インフラストラクチャのイベントと関連付けます。そうすることで、パターンを認識することができます。 クロール予算 ランキングが反応するずっと前に影響を与えます。.
エッジケース:1xx、405、410 対 404
1xx-応答はSEOにとって実質的に無関係です。サーバーとCDNが正しくアップグレードされていることを確認するだけです(例:HTTP/2/3)。. 405 メソッドが許可されていません HEAD/POST がブロックされているにもかかわらず GET 200 を返す場合に発生します。これは無害ですが、一貫して設定する必要があります。選択時には 404 対 410 私は、意図的に削除した永続的なコンテンツには 410 を、不明または誤ってリンクされたパスには 404 を使用しています。重要なのは、 一貫性, これにより、クローラーは繰り返しパターンから学習することができます。.
ロールバック戦略と耐障害性
私は、ステータスコードにエラーがあった場合に素早く戻れるようにリリースを計画しています。 ブルー/グリーン-デプロイ、細かい機能フラグ、可逆的な書き換えルール。メンテナンスには、 メンテナンスページ, バックグラウンドジョブの実行中に 503 を返す。インフラストラクチャレベルでは、正当なクロールを妨げずに攻撃を遮断するヘルスチェック、自動再起動、レート制限を用意している。これらの対策はすべて、, 200/304 を最大化し、障害発生時には4xx/5xxを制御し、短くわかりやすく保つこと。.
要約:クリーンなシグナル、より高速なクロール
私は、誰もが ステータスコード 明確なメッセージ:コンテンツには 2xx、チェーンなしには 3xx、削除されたページには 4xx、本当に例外的な場合にのみ 5xx を使用。 304 によるキャッシュはサーバーの負荷を軽減し、一貫した 200 レスポンスはボットに信頼感を与えます。これを機能させるために、ログ分析、GSC データ、定期的なクロールを組み合わせています。ホスト側では、レスポンス時間を低く抑え、適切な制限を設定し、メンテナンスを適切に計画しています。これにより、品質、インデックス作成可能性、可視性が向上します。 クロール予算 最も効果のある場所に流れ込む。.


