HTTPステータスコード

要点 — HTTPステータスコードは、サーバーがページを配信するたびに返す3桁の番号です。ブラウザや検索エンジンに、成功、リダイレクト、「見つからない」、サーバーエラーなど、何が起きたかを伝えます。SEOではコードがページ自体と同じくらい重要です。Googleがページをインデックスするか、リダイレクトをたどるか、後で再訪するか、URLを除外するかを左右します。有名な 404 は、一般にランキングを 下げません。

HTTPステータスコードとは

HTTPステータスコードは、リクエストに対するサーバー応答を標準化して分類したものです。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes 検索エンジンはクロールとインデックス登録の処理でこれらの応答を解釈します。その挙動はHTTP仕様とは別に文書化されています。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTP and network errors

ブラウザ（またはGooglebot）がサーバーにページを要求するたび、サーバーはほかのデータを送る前に3桁の番号で応答します。この番号が HTTPステータスコード であり、リクエストに何が起きたかを一言で示すサーバー側の要約です。ページが存在しないときの 404 は見覚えがあるでしょう。目立たない 200 は「ページを返しました。問題ありません」という意味です。

コードは先頭の数字によって、次の5つのグループに分かれます。

• 1xx — 情報。 「処理中なので待ってください」。目にすることはほとんどありません。
• 2xx — 成功。 「どうぞ」。重要なのは 200 OK です。
• 3xx — リダイレクト。 「移動したので、こちらへ」。リダイレクトはこの分類です。
• 4xx — クライアントエラー。 「リクエストに問題があります」。代表例は 404 Not Found です。
• 5xx — サーバーエラー。 「サーバー側の問題で、今は配信できません」。

コードがSEOで重要な理由

検索エンジンは最初にステータスコードを読み、それに応じてページの扱いを決めます。

• 検索結果に載せたいページでは 200 が望ましく、処理を進められる合図になります。
• 301 リダイレクト（恒久的）は、ページの移転先とランキングシグナルの移行先をGoogleに伝えます。302（一時的）は “this is only for now.” (翻訳) 「今だけの移転です」という意味です。
• 404 または 410 はページがなくなったことを伝え、時間の経過とともにインデックスから外れます。
• 500 または 503 のサーバーエラーは障害を示します。Googleは即座にページを削除せず、クロールを控えて後で再試行します。

多くの人が誤解していること

404エラーは一般にランキングを下げません。 Google Search Consoleのヘルプにも明記されています。本来存在しないページなら、404を返して問題ありません。そのエラーは安全に無視できます。404の実質的な損失は 間接的 で、そのページが得ていたトラフィックやリンクを失うことです。避けるべきなのは、壊れたページを 200 OK のまま公開することです。Googleが実在するコンテンツとして壊れたページをインデックスする可能性があります。

5つの分類ごとの詳細、Googleによるリダイレクトやサーバーエラーの扱い、ソフト404の落とし穴、各ページのコードを確認する方法は、上級者向け タブで解説します。

要点 — ステータスコードはページ内容とは独立した、SEO上の重要なシグナルです。2xx はインデックス登録の必要条件ですが、十分条件ではありません。301 / 308 は正規化シグナルを渡し、302 / 307 は渡しません。4xx のページは時間とともにインデックスから外れ、404 は一般にランキングを下げません。5xx と 429 はインデックス削除ではなく、クローラーを 減速 させます。2xx に戻ると徐々に回復します。落とし穴は ソフト404 です。「存在しない」という内容なのに 200 を返すページをGoogleはコンテンツ層で検出し、本物の404と同様に扱います。コードを実態に合わせ、恒久的な移転には恒久的リダイレクトを使い、停止中は 503 を返し、壊れた 200 を返さないでください。

ステータスコードの本質

5つの応答クラスはHTTP仕様のRFC 9110に由来します。これはプロトコル上の意味であり、SEOスコアそのものではありません。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes その仕様を前提としたGoogleの文書は、クロールやインデックス登録の正確な時期を保証せず、想定される処理結果を説明しています。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTP and network errors

Google自身の文書が最も明快に定義しています。“HTTP status codes are generated by the server that’s hosting the site when it responds to a request made by a client, for example a browser or a crawler.” (翻訳) 「HTTPステータスコードは、サイトをホストするサーバーが、ブラウザやクローラーなどのクライアントからのリクエストに応答するときに生成します」。SEOで重要なのは、コードが後から続くHTMLとは別個の 独立したシグナル であることです。人には完璧に見えるページでも、サーバーが最初に返した番号のために検索に表示されないことがあります。

SEOの観点から見た5つの分類

1xx — 情報。 100 Continue や 101 Switching Protocols など、「処理中」を示す暫定応答です。SEOに関係することはほぼありませんが、現代的な例外が 103 Early Hints です。完全な応答の準備前に重要リソースのプリロード開始をブラウザへ知らせられるため、Core Web Vitalsの小幅な改善には役立ちますが、インデックス登録を促すものではありません。

2xx — 成功。 インデックス可能なページは 200 OK を返します。ただし 200 は 必要条件であって十分条件ではありません。品質、重複などの理由で、Googleが200のページをインデックスしないことはあります。覚えておきたい境界例は、本文が空の成功応答 204 No Content です。インデックスする内容がないため、ソフト404として扱われる可能性があります。

3xx — リダイレクト。 正規化に関する違いが現れる分類で、このテーマで最も誤解されがちな部分です。Googleのリダイレクト文書によると、次のように分かれます。

• 301（恒久的）と 308 — Googleはリダイレクトをたどり、さらに「インデックス処理パイプラインは、リダイレクト先を正規URLとすべきことを示すシグナルとしてリダイレクトを使用」します。ランキングシグナルは移転先に統合されます。
• 302（一時的）と 307 — Googleはリダイレクトをたどりますが、「インデックス処理パイプラインは、リダイレクト先を正規URLとすべきことを示すシグナルとしてリダイレクトを使用しません」。恒久的な移転に 302 を残すのは典型的な設定ミスです。長期間続く302をGoogleが実質的に301として扱う場合はありますが、それに頼るべきではありません。

Googleは恒久的な移転では、可能な限り “use a permanent server-side redirect whenever possible” (翻訳) 「恒久的なサーバー側リダイレクトを使用する」よう推奨しています。また、“By default, Google’s crawlers follow up to 10 redirect hops.” (翻訳) 「デフォルトでは、Googleのクローラーがたどるリダイレクトは最大10ホップ」と上限も明記しています。それを超えるリダイレクトチェーンは途中で打ち切られます。（11種類のリダイレクトとSEOへの影響は、リソース欄でリンクしたAhrefsの記事にまとめました。このハブは詳細解説ではなく、全体像を示す地図です。）3xxには 304 Not Modified もあります。キャッシュ済みのコピーが最新だとクローラーに伝える応答で、ランキングへ直接作用しませんが、大規模サイトの効率的なクロールに役立ちます。

4xx — クライアントエラー。 リクエスト側の事情によりページを配信できない状態です。対象が存在しない、禁止されている、またはこのクライアントに対してブロックされている場合などです。Googleは明確に、“Google doesn’t use the content from URLs that return 4xx status codes,” (翻訳) 「Googleは4xxステータスコードを返すURLのコンテンツを使用しない」、また “if a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time.” (翻訳) 「以前使用していたURLが現在4xxを返す場合、Googleのシステムは時間の経過とともにそのURLの使用を停止する」と説明しています。404 については、“the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed.” (翻訳) 「以前インデックスされていたURLはインデックスから削除され、新たに検出した404ページは処理されない」としています。

ここには、重要な注意点が2つあります。

• 404 はランキングを下げません。 Search Consoleヘルプは、“In general, 404 errors won’t impact your site’s search performance.” (翻訳) 「一般に、404エラーはサイトの検索パフォーマンスに影響しない」と明記しています。404のリスクは、そのページが得ていたトラフィックやリンクを失うこと、また大規模に発生した場合はクロール予算を浪費することです。
• Googlebotに対して 401 / 403 を乱用しないでください。 Googleは、“Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (翻訳) 「クロール頻度の制限に401と403を使わないでください。429を除く4xxはクロール頻度に影響しない」と警告しています。401 / 403 でGooglebotをブロックしても減速にはならず、コンテンツを見えなくするだけです。

クライアントエラーの各コードには、それぞれ固有の論点があります。アクセスと認証の 401、403、消失を示す 404、410 とその使い分け、レート制限の 429、法的理由によるブロックの 451 です。各コードは個別の記事で詳しく解説しています。下の「次に読む記事」を参照してください。

5xx — サーバーエラー。 リクエストは正しかったものの、サーバーが処理できなかった状態です（500 Internal Server Error、502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout）。SEOで重要なのは、これらが 即座にインデックス削除を起こすわけではない ことです。Googleの文書では、5xx and 429 server errors “prompt Google’s crawlers to temporarily slow down with crawling,” (翻訳) 「5xxと429のサーバーエラーは、Googleのクローラーに一時的なクロール減速を促す」とされ、“once the server starts responding with a 2xx status code, Google gradually increases the crawl rate.” (翻訳) 「サーバーが2xxで応答し始めると、Googleは徐々にクロール頻度を上げる」と説明されています。減速の程度についても、“the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error.” (翻訳) 「クロール頻度の低下は、サーバーエラーを返す個別URLの数に比例する」とされています。一時的な障害では既存のインデックスURLが維持され、削除につながるのはエラーが 長期化 した場合だけです。

クロールとインデックス登録を結び付ける考え方

これらのコードの背景には、異なる2つの問いがあります。

1. このURLをクロールすべきか。 5xx / 429 は「減速して後で再試行」、301 / 302 は「代わりにこちらへ」という意味です。実際にクロール頻度を抑えるのは 429 と5xxだけです。
2. この内容をインデックスすべきか。どのURLを使うべきか。 2xx は処理対象になり得る、4xx は除外、301 / 308 は移転先へ統合、という意味です。

両者をつなぐ仕組みを崩す例外が ソフト404 です。ここでは コード と コンテンツ が食い違います。

ソフト404 — 見落としやすい例外

ソフト404とは、成功コード（200）を返しながら、項目が存在しないと内容で示すページです。空のページ、「見つかりません」というメッセージ、内容の乏しい、または空白の結果などが該当します。GoogleはHTTPコードにかかわらず、コンテンツ層 で問題を検出します。“if the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (翻訳) 「コンテンツがGoogle検索にとってエラーを示す場合、空のページまたはエラーメッセージの場合、Search Consoleにはsoft 404エラーが表示される」と説明しています。

ページが「正常に表示される」のに、なぜ問題なのでしょうか。クロール予算を浪費するからです。Googleの大規模サイト向けガイドは、“soft 404 pages will continue to be crawled, and waste your budget.” (翻訳) 「ソフト404ページは引き続きクロールされ、クロール予算を浪費する」と明言しています。原因は、存在しないルートにも 200 を返すCMSやJavaScriptフレームワークの設定ミスであることが一般的です。修正方法は コード を実態に合わせることです。本物の 404（または 410）を返し、GoogleがURLを適切に除外できるようにします。このクラスターにはソフト404専用の記事もあります。

404と410 — 実際に違いはあるのか

SEO上の違いはほとんどありません。John Muellerは2024年に、“The difference in processing of 404 vs 410 is so minimal that I can’t think of any time I’d prefer one over the other for SEO purposes,” (翻訳) 「404と410の処理差は非常に小さく、SEO目的で一方を優先する場面は思い付かない」と説明し、さらに “Google does not penalize for 404’s (those pages drop out of the index though).” (翻訳) 「Googleは404にペナルティを科さない（ただしページはインデックスから外れる）」と述べています。410（Gone）は恒久性をわずかに早く伝え、人やほかのツールに意図をより明確に示せます。Matt Cuttsによる以前の説明では、410 の削除処理は「少し速い」程度で、差は長くても数日でした。削除が恒久的だと確信しているなら 410、ページが戻る可能性がある、または不明なら 404 を使います。Googleのクロール予算ガイドはどちらでもよいとしており、“a 404 status code is a strong signal not to crawl that URL again.” (翻訳) 「404はそのURLを再度クロールしないよう示す強いシグナル」と説明しています。詳細は404と410の比較記事で解説します。

ダウンタイムと移行でステータスコードを使う方法

計画停止、メンテナンス、移行期間には、503 Service Unavailable を返します。壊れた 200 を返してはいけません。John Muellerは、“if something goes drastically wrong with your hoster, and you can’t host your website anymore, please return a ‘503 Service unavailable’ HTTP result code.” (翻訳) 「ホスティングで重大な問題が起き、サイトをホストできなくなった場合は、503 Service unavailableのHTTP結果コードを返してください」と明言しています。避けるべき2つの方法についても、“returning an error page with ‘200 OK’ will result in us indexing the change of content like that (and if all of your pages return the same error page, then we may assume that these URLs are duplicates). Redirecting to a temporary page will result in that redirect being used for indexing.” (翻訳) 「エラーページを200 OKで返すと、その変更後の内容がインデックスされる。全ページが同じエラーページを返せば重複URLと見なされる可能性がある。一時ページへリダイレクトすれば、そのリダイレクトがインデックス登録に使われる」と説明しています。オリジンサーバーが完全に停止した場合は、DNSを一時サーバーへ向け、そこで 503 を配信する方法があります。

ただし、期間は短くしてください。Gary Illyesは、“Serving a 503 status code for an extended period of time will cause a decrease in crawl rate,” (翻訳) 「503を長期間配信するとクロール頻度が低下する」としつつ、“10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” (翻訳) 「ときどき10〜15分という程度は決して『長期間』ではないので問題ない」と述べています。目安として、503 は数週間ではなく数時間の停止に使います。数週間続けば、Googleはページが実際になくなったと扱い始めます。移行時の手法は503の記事で詳しく説明します。

ページのステータスコードを確認する方法

• ブラウザの開発者ツール — Networkタブを開いて再読み込みし、documentリクエストを選んでStatus列を確認します。
• コマンドライン — 1回のリクエストのヘッダーなら curl -I https://example.com/page、リダイレクトチェーン全体をたどるなら curl -IL https://example.com/page を実行します。
• Google Search Console — URL検査ツールでクロール時のステータスを確認します。
• Bing Webmaster Tools — URL InspectionツールでBingbotに対して同様に確認します。
• クローラー — Screaming Frog SEO SpiderとAhrefs Site Auditはサイト全体をクロールし、ステータスコード、リダイレクトチェーン、4xx / 5xxのURLをまとめて抽出します。無料のAhrefs SEO Toolbarでは、閲覧中ページのコードを確認できます。

競合ガイドが見落としがちな注意点があります。1回の確認で分かるのは、その1回のリクエストだけです。 ステータスはリクエストメソッド、ユーザーエージェント、認証、地域、時刻に加え、途中のキャッシュやCDNによって変わります。手元で正常でもGooglebotが同じ応答を受けたとは限りません。簡潔な診断手順は次のとおりです。

• メソッド — HEAD リクエストは GET と同じヘッダーを持つべきですが、サーバーはコンテンツ生成が必要なフィールドを省略できます。そのため HEAD の確認だけでは実際の GET 応答を証明できません。結果が異なる場合は GET で再確認します。
• ユーザーエージェント — Bot検出、地域ブロック、クローキングにより、Googlebotには 200、ブラウザには 403 が返る場合があります（またはその逆）。
• 地域 — 地域ブロックや地域別CDNルールが疑われる場合は、複数の場所またはIPから再確認します。
• キャッシュ — オリジン自体の不具合と判断する前に、ブラウザキャッシュやCDNエッジキャッシュに古い応答が残っていないかを確認します。
• チェーン — 最終コードだけでなく、リダイレクトチェーン全体を記録します。途中のホップが本当の問題かもしれません。
• ログ — コードが想定と違う場合は、Googlebotが実際に受け取った応答を確認します。単一のブラウザやチェッカーでは分からない事実を示すのがサーバーログです。

Bingに関する補足

Bingが公開しているステータスコードの説明はGoogleより限定的です。Googleの文書ほど詳しく「ステータスコードがクロールに及ぼす影響」をまとめた正式文書はなく、調査時にはBing担当者による発言も見つかりませんでした。方向性としては同じで、正確なコードを返し、継続する 4xx / 5xx を修正し、恒久的な移転には恒久的リダイレクトを使います。存在しないBingの引用を作るより、この点を率直に示します。

次に読む記事：HTTPエラーコードのクラスター

このハブは概要です。HTTPエラーコード のサブハブでは、実際にトラブルシューティングするコードを個別の記事で詳しく解説します。

• 401 Unauthorized と 403 Forbidden — アクセスと認証のコード、およびクロール制限に使うべきでない理由。
• 404 Not Found、410 Gone、404 と 410 の比較 — 「ページがなくなった」場合のコードと使い分け。
• 429 Too Many Requests — レート制限、およびほかの4xxと異なりクロール頻度に影響する仕組み。
• 451 Unavailable For Legal Reasons — 403 とは異なる、法律や規制によるブロック。
• 500 Internal Server Error、502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout — サーバーエラー、クロール減速、メンテナンスで 503 を使う方法。
• ソフト404 — 実際にはエラーなのに 200 を返す状態と、その修正方法。

各記事はこのハブの下に配置され、サイドバーにも掲載されています。リダイレクトがランキングシグナルを統合する仕組みは 正規化 を、5xx / 429 によるクローラーの減速は クロール を参照してください。

AIによる要約

上級者向け解説を短くまとめると、次のとおりです。

• コードはコンテンツとは別個のSEOシグナルです。 見た目が完璧なページでも、サーバーが最初に返した番号によって検索に表示されないことがあります。
• 5つの分類： 1xxは情報（103 Early Hints はCore Web Vitalsに有用）、2xxは成功（200 はインデックス登録の 必要条件だが十分条件ではない）、3xxはリダイレクト、4xxはクライアントエラー、5xxはサーバーエラーです。
• リダイレクト： 301 / 308 は恒久的で正規化シグナルを渡し、302 / 307 は渡しません。Googleがたどるのは最大 10リダイレクトホップ です。
• 4xx： Googleは 4xx のコンテンツを使わなくなり、404 のURLを時間とともにインデックスから外します。404 は一般にランキングを下げません（Search Consoleヘルプ）。Googlebotの減速に 401 / 403 を使ってはいけません。クロール頻度に影響するのは 429 と5xxだけです。
• 404と410： 処理差は「非常に小さい」（Mueller）ため、通常は問題になりません。恒久的な削除が確実なら 410、それ以外は 404 を使います。
• 5xx / 429： クローラーは 一時的に減速 しますが、即座にインデックスを削除しません。2xx が戻るとクロール頻度は徐々に回復し、削除につながるのはエラーが 長期化 した場合だけです。
• ソフト404： 「存在しない」という内容なのに 200 を返す状態です。Googleはコンテンツ層で検出し、404 と同様に扱います。クロール予算も浪費します。
• ダウンタイム： 503 を返し、壊れた 200 は避けます（数週間ではなく数時間）。そうしないと、Googleが壊れた内容をインデックスする可能性があります。
• コードの確認： 開発者ツールのNetworkタブ、curl -I / curl -IL、GSC / BingのURL検査、Screaming Frog / Ahrefs Site Auditを使います。1回の確認で証明できるのはそのリクエストだけです。メソッド、ユーザーエージェント、地域、キャッシュで結果が変わるため、チェーン全体を確認し、Googlebotが実際に受け取った応答をサーバーログで確かめます。

公式ドキュメント

プロトコル仕様と検索エンジンが公開している一次資料です。

基礎となる仕様

• RFC 9110 — HTTP Semantics, §15 Status Codes — 5つのステータスコード分類を定める実際のプロトコル仕様です。RFC 9110が定義するのはリクエストと応答の意味であり、SEO上の結果ではありません。以下はすべて、Googleが検索で各コードをどう解釈するかを説明した文書です。

Google

• HTTPステータスコード、ネットワーク／DNSエラーとGoogle検索 — コードの意味、4xxによる削除、ソフト404、5xx / 429によるクロール減速をまとめた正式文書です。
• Google検索によるリダイレクトの処理 — 301 / 302 / 307 / 308、正規化の違い、10ホップの上限を解説します。
• クロール予算を最適化する — 404 / 410を「強いシグナル」とする説明と、ソフト404による予算浪費について扱います。
• Fix Search Console errors (404 / crawl errors) — 「404エラーはサイトの検索パフォーマンスに影響しない」という記述の出典です。
• John Mueller — “503s” — ダウンタイムに503を返すことと、200やリダイレクトを使う問題点についての本人による説明です。

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — 特定URLのインデックス状況、クロール可能性、HTTP応答コードを確認します。
• Bing Webmaster Tools — Crawl error alerts — クロールエラーがあるURLとステータスコードをCrawlレポートで確認します。

出典からの引用

Googleとその担当者が公に述べた内容です。各リンクから、出典ページ内の引用箇所へ直接移動できます。

Google — ステータスコードの定義と4xx / 404の挙動

• “HTTP status codes are generated by the server that’s hosting the site when it responds to a request made by a client, for example a browser or a crawler.” (翻訳) 「HTTPステータスコードは、サイトをホストするサーバーが、ブラウザやクローラーなどのクライアントからのリクエストに応答するときに生成します」。 — Google Search Centralの文書。 引用箇所へ
• “Google doesn’t use the content from URLs that return 4xx status codes.” (翻訳) 「Googleは4xxステータスコードを返すURLのコンテンツを使用しません」。 引用箇所へ
• “In general, 404 errors won’t impact your site’s search performance.” (翻訳) 「一般に、404エラーはサイトの検索パフォーマンスに影響しません」。 — Google Search Consoleヘルプ。 文書を読む

Google — ソフト404とクロール予算

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (翻訳) 「コンテンツがGoogle検索にとってエラーを示す場合、空のページまたはエラーメッセージの場合、Search Consoleにはsoft 404 エラーが表示されます」。 引用箇所へ
• “soft 404 pages will continue to be crawled, and waste your budget.” (翻訳) 「ソフト404ページは引き続きクロールされ、クロール予算を浪費します」。 引用箇所へ
• “a 404 status code is a strong signal not to crawl that URL again.” (翻訳) 「404ステータスコードは、そのURLを再度クロールしないよう示す強いシグナルです」。 引用箇所へ

Google — 5xx / 429によるクロール減速と、401 / 403の誤用

• 5xx and 429 server errors “prompt Google’s crawlers to temporarily slow down with crawling.” (翻訳) 「5xxと429のサーバーエラーは、Googleのクローラーに一時的なクロール減速を促します」。 引用箇所へ
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate.” (翻訳) 「サーバーが2xxステータスコードで応答し始めると、Googleは徐々にクロール頻度を上げます」。 引用箇所へ
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (翻訳) 「クロール頻度の制限に401と403を使わないでください。429を除く4xx ステータスコードはクロール頻度に影響しません」。 引用箇所へ

Google — リダイレクトと正規化

• “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.” (翻訳) 「Googlebotはリダイレクトをたどり、インデックス処理パイプラインは、リダイレクト先を正規URLとすべきことを示すシグナルとしてリダイレクトを使用します」。（301 / 308） 引用箇所へ
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (翻訳) 「Googlebotはリダイレクトをたどりますが、インデックス処理パイプラインは、リダイレクト先を正規URLとすべきことを示すシグナルとしてリダイレクトを使用しません」。（302 / 307） 引用箇所へ
• “By default, Google’s crawlers follow up to 10 redirect hops.” (翻訳) 「デフォルトでは、Googleのクローラーがたどるリダイレクトは最大10ホップです」。 引用箇所へ

John Mueller（Google）— ダウンタイム時の503

• “if something goes drastically wrong with your hoster, and you can’t host your website anymore, please return a ‘503 Service unavailable’ HTTP result code.” (翻訳) 「ホスティングで重大な問題が起き、サイトをホストできなくなった場合は、503 Service unavailableのHTTP結果コードを返してください」。 投稿を読む
• “Returning an error page with ‘200 OK’ will result in us indexing the change of content like that (and if all of your pages return the same error page, then we may assume that these URLs are duplicates).” (翻訳) 「エラーページを200 OKで返すと、その変更後の内容がインデックスされます（全ページが同じエラーページを返す場合、URLが重複していると判断される可能性があります）」。 投稿を読む

John Mueller（Google）— 404と410

• “The difference in processing of 404 vs 410 is so minimal that I can’t think of any time I’d prefer one over the other for SEO purposes.” (翻訳) 「404と410の処理差は非常に小さく、SEO目的で一方を優先する場面は思い付きません」。
• “Google does not penalize for 404’s (those pages drop out of the index though).” (翻訳) 「Googleは404にペナルティを科しません（ただしページはインデックスから外れます）」。 2024年4月にSearch Engine JournalがRedditのr/SEOへの回答を紹介し、Search Engine Roundtableも裏付けた発言です。記事

Gary Illyes（Google）— 503とクロール頻度

• “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate.” (翻訳) 「503ステータスコードを長期間配信すると、クロール頻度が低下します」。
• “Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” (翻訳) 「ときどき10〜15分という程度は決して『長期間』ではないので、問題ありません」。 2024年4月のGoogle SEO Office Hoursについて、Search Engine Journalが紹介した発言です。記事

どのステータスコードを返すべきか

上から順に確認し、最初に該当するものを選びます。

ページを新しいURLへ移転した。

• 恒久的な移転 → 301（または 308）。Googleはランキングシグナルを移転先に統合します。
• 一時的な移転（A/Bテスト、地域別切り替え、短期キャンペーン）→ 302（または 307）。正規化シグナルは渡らないため、恒久的な移転に残さないでください。

ページを削除し、今後も復活しない。

• 恒久的だと確信している → 410。恒久性をわずかに早く伝えます。
• 復活する可能性がある、または不明 → 404。どちらでもGoogleは時間とともにインデックスから外します。SEO上はいずれも問題なく、違いは「ごくわずか」です。
• 「見つかりません」という内容を 200 で返してはいけません。これは ソフト404 で、Googleがクロールを続けて予算を浪費します。

ページにログインが必要、またはアクセスが制限されている。

• → 401（認証が必要）または 403（禁止）。Googlebotを減速させる目的で使わないでください。クロール頻度を抑えず、コンテンツを隠すだけです。

一時的な障害がある、またはメンテナンスや移行を実施している。

• 数週間ではなく数時間の計画停止 → 503。可能なら Retry-After ヘッダーも付けます。Googleはクロールを控えて再訪し、メンテナンスページをインデックスしません。
• 実際にサーバーでエラーが起きている → 500 / 502 / 504。Googleはクロールを減速し、一時的な障害中は既存のインデックスURLを維持します。長期化する前に修正してください。
• 大量のリクエストをレート制限する → 429。Googleのクロール頻度を実際に下げる唯一の4xxです。

法的理由でコンテンツがブロックされている（裁判所命令、GDPR、ライセンス、国単位の禁止）→ 451。通常の 403 とは異なり、法的 なブロックであることを示します。

問題なく、ページをインデックスしてほしい → 200。必要条件ではありますが十分条件ではなく、Googleがインデックスしない判断をする場合もあります。

各コードの詳細記事は、HTTPエラーコードのクラスターにあります。

SEO向けHTTPステータスコード完全リファレンス

5つの分類を一覧で確認

SEOに関係するコードを個別に確認

重要な3つのグループ

• Googleが対応する強いシグナル： 301 / 308（正規URL）、404 / 410（インデックスから削除）。
• 主にUXやアクセスに関係し、クロール頻度には影響しない： 401、403、451。
• 運用上の一時的な問題で、クロールを減速させる： 429、500、502、503、504。

早わかり

• 200 だけではインデックス登録を保証しません。
• Googleのクロール頻度を抑えるのは 429 と 5xx だけです。
• Googleがたどるリダイレクトは最大 10ホップ で、それより長いチェーンは打ち切られます。
• ソフト404 = 200 + 「存在しない」という内容。404 と同様に扱われ、クロール予算を浪費します。
• ダウンタイムには 503。数時間ならよいものの数週間は不可です。Illyesによれば「ときどき10〜15分」なら問題ありません。
• 確認手段：開発者ツールのNetworkタブ、curl -I / curl -IL、GSC / BingのURL検査、Screaming Frog、Ahrefs Site Audit / Toolbar。

読む価値のあるリソース

私の記事

• HTTPステータスコードとSEOへの影響 — Ahrefsで公開した 1xx〜5xx と非標準コードの網羅的なリファレンスで、このハブの基礎になった記事です。
• 11 Types Of Redirects & Their SEO Impact — 3xx の各リダイレクトをいつ、なぜ使うかを詳しく解説した関連記事です。
• The Beginner’s Guide to Technical SEO — ステータスコードをテクニカルSEO全体の中で位置付けます。

業界のリソース

• HTTPステータスコード、ネットワーク／DNSエラーとGoogle検索 （Google）— このハブの主な主張を裏付ける正式文書です。
• Google検索によるリダイレクトの処理 （Google）— 301 / 302 / 307 / 308の正規化の違いと10ホップの上限を解説します。
• “503s” （John Mueller）— ダウンタイムに 503 を返す理由と、壊れた 200 の問題を述べた本人の説明です。
• John Muellerが404と410の混同を解説 （Search Engine Journal）— 「違いは非常に小さい」という発言を紹介します。
• 503ステータスコードがSEOへ及ぼす影響についてのGoogleの説明 （Search Engine Journal）— Gary Illyesの「10〜15分」という説明を紹介します。
• SEO向けHTTPステータスコード完全ガイド （Search Engine Land）— コードごとの詳しいリファレンスです。
• HTTPステータスコード （Screaming Frog）— 実践的な検出方法と一括エクスポート手順です。
• ページのHTTPステータスコードを確認する方法 （Ahrefs Help）— SEO ToolbarとSite Auditでコードを確認する方法です。

引用の出典

引用タブの全出典です。各記述を自分で確認できます。

• HTTPステータスコード、ネットワーク／DNSエラーとGoogle検索 — Google Search Central。ステータスコードの定義、4xx、ソフト404、5xx / 429の引用元です。
• Google検索によるリダイレクトの処理 — Google Search Central。301 / 308と302 / 307の正規化の違い、10ホップ上限の引用元です。
• クロール予算を最適化する — Google Search Central。「再クロールしない強いシグナル」と「ソフト404が予算を浪費する」という引用元です。
• Fix Search Console errors — Google Search Consoleヘルプ。「404エラーはサイトの検索パフォーマンスに影響しない」という記述の出典です。
• “503s” — John Muellerの個人サイト。ダウンタイム時の503と、200やリダイレクトを使う問題点の出典です。
• John Muellerが404と410の混同を解説 — Search Engine Journal（Redditの回答を紹介）。
• 503ステータスコードがSEOへ及ぼす影響についてのGoogleの説明 — Search Engine Journal（Office Hoursの発言を紹介）。

まずクロール、次にインデックス登録

ステータスコードに関するSEO上の疑問には、常に次の2段階モデルを使います。

第1段階：クローラーは利用可能な応答を取得できるか

• 2xx はリクエスト成功を示し、コンテンツを次の処理へ進められます。
• 3xx はクローラーを別のURLへ送ります。恒久的コードと一時的コードでは、正規化シグナルが異なります。
• ほとんどの 4xx は、要求されたコンテンツが存在しない、または利用できないことを示します。
• 5xx と 429 はサーバーの障害や過負荷を示すため、クローラーがリクエスト頻度を下げる場合があります。

取得に失敗したリクエストは、コンテンツ品質やページ内最適化では救えません。まず通信上の問題、またはURLに意図した状態を修正します。

第2段階：取得したコンテンツをインデックスすべきか。どのURLを使うべきか

200 は最初の関門を通過するだけです。内容が乏しい、重複している、ブロックされている、またはエラーに見えるコンテンツをGoogleがインデックスしない場合はあります。エラーページが200を返せばソフト404になる可能性があります。リダイレクトをたどれても、その移転先がインデックス登録に失敗することもあります。成功応答は処理対象になる資格であり、ランキングやインデックス登録の保証ではありません。

実践的な診断手順

1. 実際のステータスと、すべてのリダイレクトホップを記録します。
2. その応答がURLの意図した状態と一致するか判断します。
3. 利用可能な2xxページに到達したら、インデックス可能性と正規化シグナルを確認します。
4. 4xxを返す場合は、ページの消失が意図したものか判断します。
5. 5xxまたは429を返す場合は、検索パフォーマンスを解釈する前に、信頼性と影響範囲を調査します。

最初の応答を確認する

macOSまたはLinuxのシェルで次を実行すると、リダイレクトをたどらずに対象URLのヘッダーを表示できます。

curl -sS -D - -o /dev/null https://www.example.com/page

ステータスコードだけを表示する場合：

curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/page

PowerShellで同じ処理を行う場合（PowerShell 7以降）：

$response = Invoke-WebRequest -Uri 'https://www.example.com/page' -Method Head -SkipHttpErrorCheck
$response.StatusCode
$response.Headers

サーバーが HEAD を別の方法で処理する場合は、結論を出す前に通常の GET リクエストで確認してください。

リダイレクト経路をたどって表示する

-L はリダイレクトをたどり、-v は各リクエストと応答を表示します。ターミナルで実行し、< HTTP と < location: で始まる行を確認します。

curl -sS -L -o /dev/null -v https://www.example.com/old-page

ターミナル出力より見やすい単一URLまたは一括表示が必要なら、リダイレクトチェーンマッパー を使ってください。

ステータスの挙動を確認するツール

• HTTPステータスコード一括チェッカー — 最大500件のURLを確認し、各リダイレクトチェーンと最終到達先を表示し、SEO上の問題を絞り込んで結果をエクスポートできます。「どのURLが誤ったコードを返しているか」を調べるときに使います。
• HTTPヘッダーチェッカー — リダイレクトの各ホップで完全な応答ヘッダーを確認します。キャッシュ、CDN、圧縮、一部のセキュリティシグナルも対象です。ステータスだけでは足りない場合に使います。
• リダイレクトチェッカー — 1件または少数のURLについて、最終ステータス、到達先、ホップの順序をすばやく確認します。
• Webサイト停止チェッカー — 5xxやタイムアウトが断続的に起きている可能性があるとき、外部の観測地点から現在の到達可能性と応答時間を調べます。
• ブラウザ開発者ツール → Network — ページを再読み込みし、documentリクエストを選び、Status CodeとResponse Headersを確認します。対話的なデバッグに便利ですが、クライアント側で描画されたエラーメッセージとdocumentのHTTPステータスを混同しないでください。

理解度チェック：HTTPステータスコード

ステータスコードがSEOに及ぼす影響を問う5問です。各問で答えを選び、結果を確認してください。

変更履歴