200 OK（HTTP 200）

TL;DR — 200 OKレスポンスは、サーバーが「here’s the page you asked for, everything’s fine.」 (翻訳)「このページですね、すべて問題ありません」と伝えている状態です。Googleに表示したいページなら望ましい、静かな成功コードです。ただし200だけでインデックス登録が保証されるわけではありません。Googleはコンテンツに登録する価値があるかを確認します。実際に壊れている、または空のページの200は、青信号ではなくバグです。

200 OKとは

ブラウザーやGooglebotがサーバーにページを要求するたび、サーバーは他のものを送る前に3桁のステータスコードで応答します。200 OKは「問題なし」を表すコードで、サーバーが要求されたものを見つけ、通常はページのコンテンツを含めて返します（仕様上、場合によっては本文が空の200も許されますが、読者に見せたいページなら毎回実体のある本文が必要です）。何も問題が起きなかったことを示すため、ほとんど意識されないコードです。 Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stoxは、AhrefsのHTTPステータスコードガイドで次の3語にまとめています。 「200 OK – All good. Everything is successful.」 (翻訳)「200 OK — すべて良好。すべて成功です。」

検索で見つけてもらいたいサイト内ページなら、返してほしいコードはまさに200です。

200だけでは全体を語れない理由

多くの「200とは何か」ページが省いているのはここです。**200はページをインデックス登録の対象として検討させますが、インデックス登録を保証するものではありません。**この2つはまったく違います。

200は入場券だと考えてください。ドアを通った後も、Googleはコンテンツを残す価値があるかを判断します。品質は高いか、別ページのほぼ重複ではないか、薄いまたは空ではないか、Googleに入るなと伝えるnoindexタグがないか。どれかに該当すれば、健全な200ページでもインデックス登録されないことがあります。

ページが200を返しているのにGoogleに表示されないなら、問題はステータスコードではなく、コンテンツか設定です。

本当は「見つからない」200の落とし穴

最も巧妙なミスは、200を返すページのコンテンツが「this doesn’t exist.」 (翻訳)「これは存在しない」と言っている状態です。在庫切れ商品の空白ページ、空のテンプレートを読み込み続ける削除済み記事、結果が0件の検索結果ページなどが該当します。サーバーは明るく200を返しますが、そこには実体がありません。

Googleはコードではなく実際のコンテンツを見て、ページが空またはエラーだと判断し、Search Consoleでソフト404とラベル付けします。実際の「not found」ページと同じように扱われます。詳しい仕組みはsoft-404-errors記事で説明しています。要点は、ページが本当に消えているなら200ではなく404または410を返すべきだということです。

覚えておくべき1つのルール

**Googleに載せたいページは、実体のあるコンテンツとともに200を返すべきです。**ページが消えたなら404または410、移動したなら301へリダイレクト、別ページとの重複ならcanonicalタグを使います。Googleの正確な文言、200と204の違い、Googlebotが実際に受け取ったものの確認方法を知りたい場合は、Advancedタブに切り替えてください。

TL;DR — 200 OKは標準的な2xx成功コード（RFC 9110 §15.3.1）です。サーバーはリクエストを処理し、GET/HEADでは本文がリソースの表現になります。デフォルトではヒューリスティックにキャッシュ可能です。SEOでは必要ですが十分ではありません。Googleの文書は、インデックス登録パイプラインが「may index the content, but that’s not guaranteed,」 (翻訳)「コンテンツを登録することがあるが、保証されない」と述べています。品質、重複、薄いコンテンツ、noindexは200の上で結果を左右します。典型的な失敗はソフト404です。エラーや空のコンテンツを200で包むと、Googleはコンテンツ層で検出し、コードに関係なくソフト404として報告します。200（本文を期待）と204（空の本文、ページではソフト404扱い）と304（キャッシュのシグナルで、インデックス登録の判断ではない）を区別してください。また、Googlebotが受け取ったものを確認してください。クローキング、ボットブロック、地域ルール、CDN/WAF設定により、ブラウザーとは違うコードが配信されることがあります。

仕様における200の意味

RFC 9110（HTTP Semantics）が現在の権威ある仕様で、§15.3.1は明快です。「The 200 (OK) status code indicates that the request has succeeded.」 (翻訳)「200（OK）ステータスコードは、リクエストが成功したことを示す。」本文の内容はリクエストメソッドによって異なります。ページに関係するGETとHEADでは、コンテンツは対象リソースの表現です。RFCはさらに、CONNECTへの応答を除けば、メッセージのフレーミングが長さ0を明示しない限り、200はコンテンツを持つことが期待されると説明しています。つまり「200には必ず本文がある」は略称であり、絶対条件ではありません。実際にインデックス登録したいページでは、空ではなく実体のある本文を目標にします。200は、cache-controlディレクティブで別途指定されない限り、デフォルトで「ヒューリスティックにキャッシュ可能」でもあります。そのため頻繁に再クロールされるページでは、ETagやLast-Modifiedのような検証ヘッダーが重要です。 Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

厳密には、200はページ専用ではありません。RFCはメソッドごとの「成功」の意味を示しています。

GET以外のメソッドでは200を見ないことも多く、MDNは成功したPUTまたはDELETEリクエストが「often do not result in a 200 OK response,」 (翻訳)「200 OKレスポンスにならないことが多い」と説明しています。201 Createdや204 No Contentのほうが一般的です。これはページURLのSEOには関係ありません。覚えておくべき一文は、インデックス登録したい文書では、実体のある本文付きの200が目標だということです。

インデックス登録には必要だが十分ではない

これは最も正しく理解すべき点で、競合する用語集ページの大半が明確に間違えている部分です。「200ならページがインデックス登録される」と書いています。 Google自身の文書はそうではないと説明します。200の場合、Googleは「passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.」 (翻訳)「受け取ったものを次の処理段階へ渡します。Google検索では次のシステムがインデックス登録パイプラインです。登録することはありますが、保証されません」としています。 Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

つまり200は、ページの検索での運命を約束するものではなく、HTTPレスポンスに関する契約です。200の後、Googleは次を独立して評価します。

• 品質 — 薄い、価値の低い、または自動生成されたページはインデックス登録されないことがあります。
• 重複 — より強いURLとほぼ重複するページは、自分のURLで登録されず、そのURLに統合されることがあります（これを制御するのがcanonicalタグです）。
• ディレクティブ — metaタグやX-Robots-Tagヘッダーのnoindexは、完全な200でもページを検索対象外にします。

PatrickのAhrefsガイドも、ステータスコード群について同じ線引きをしています。「Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.」 (翻訳)「この成功コード群の大半はページをインデックス登録可能にします。ただし、本文を返さない応答はソフトな「見つからない」扱いとなり、登録されません。」200はページを登録可能にしますが、登録済みにはしません。

ソフト404の落とし穴

「200だけでは全体を語れない」ことの最も明確な例がソフト404です。Googleのステータスコード文書は仕組みを次のように説明しています。「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はソフトエラーを表示します。」ここで重要なのは、分類がHTTPコードではなくレンダリングされたコンテンツに基づくことです。Googleのインデックス登録パイプラインは200の先にある実際のページを見て、「見つからない」ように読めば実際の404と同じように分類・報告します。

実際に確認すべきケースは、ページが空テンプレートになった販売終了商品、200のシェルを返し続ける削除済み記事、0件で「nothing here」と表示する絞り込みカテゴリや検索結果です。どれも技術的には正しい200を返しながら、ユーザーにもGoogleにも見るものがないと伝えます。

このサイトにはソフト404の検出方法と修正方法を扱う専用記事があります。ここでは繰り返しません。200の議論での要点は、実際に消えたページへ200を返すとソフト404の設定になることです。修正はコードを現実に合わせることです。

転送の成功はアプリケーションの成功ではない

APIや監視の分野で出てくるため、範囲を限定して補足します。**HTTP層とアプリケーション層は食い違うことがあります。**APIエンドポイントは本文にJSONエラーオブジェクトを入れたまま200を返せます。ページも、バックエンド依存先が黙って失敗し、本来のコンテンツの代わりに壊れたブロックを描画したまま200を返せます。ステータス行が言っているのは「正常に届けた」ということだけです。ペイロードが実際に正しいかは別の問いで、ステータスコードだけでは答えられません。APIがエラーを200以外で示すべきか、エラーペイロードを包んだ200で示すべきかについて実務者の意見は分かれています。これは各チームが選ぶ契約であり、HTTPのルールではありません。このサイトのSEOという目的では、同じ問題のページ版が上のソフト404です。ステータス行だけを信用せず、本文に何が含まれるかを見るという修正方針も同じです。

200と204と304を混同しない

人々が混同する3つのコードのうち、「ページはこちら」という成功を示すのは1つだけです。

204は本当の成功コードですが、本文が空なのでクローラーには登録するものがありません。そのためページURLではソフト404の分類になります（別記事で扱う話です。空本文のケースを通常の200と混同しないでください）。304は同じファミリーですらありません。If-None-Match / If-Modified-Sinceによる条件付きリクエストに応答し、キャッシュ済みコピーがまだ最新だとクライアントに伝えます。本文を持たず、登録すべきかどうかも示しません。重複した200ではなく、クロール効率化の仕組みです。「200と304は同じ考え方では？」というよくある疑問は、キャッシュ最適化と成功レスポンスを混同しています。

Googlebotが実際に見るものを確認する

競合記事のほとんどが省く大きな差があります。**同じURLでも、リクエスト元によって違うコードを受け取ることがあります。**ブラウザーにはきれいな200が見えても、Googlebotには別のものが返る場合があります。意図的なケースはスパムポリシー違反のクローキングで、より多いのはWAFやボットブロック、地域IPターゲティング、CDNエッジロジック、ボットに対して誤作動するA/Bテスト設定による偶発的な差です。

「ブラウザーでは200だった」は「Googleも200を見ている」という証明ではありません。正しい診断は、Googlebot自身が受け取ったものを確認することです。

• GSC URL Inspection — Live Testを実行し、あなたのマシンではなくGoogleが取得するステータスとレンダリング済みコンテンツを確認します。
• サーバー/CDNログ — 各ユーザーエージェントが実際に受け取ったコードの根拠です。

端末の単純なcurl -Iも役立ちますが、Googlebotとは異なるエッジルールに当たる可能性がある、もう1つのリクエスト元にすぎません。最終結論ではなくデータポイントとして扱ってください。

成功レスポンスを確認・監視する方法

• ブラウザーDevTools — Networkタブを開いて再読み込みし、documentリクエストをクリックしてStatus列を読みます。
• コマンドライン — 1回のリクエストのヘッダーには curl -I https://example.com/page を使い、リダイレクトチェーンの追跡には curl -IL を使います。
• Google Search Console — URL Inspectionがクロール時のステータスを報告し、Live Testを実行できます。
• Bing Webmaster Tools — URL InspectionはBingbotが受け取ったものを確認するBing側の方法です（Googleのように「ステータスコードがインデックス登録へ与える影響」をまとめた専用Bing文書はありません。存在しない方針を作るより、そう明記するほうがよいでしょう）。
• クローラー — Screaming FrogとAhrefs Site Auditはサイト全体のステータスコードをまとめて示します。無料のAhrefs SEO Toolbarは現在見ているページのコードを表示します。

「健全」とは、重要なcanonical URLが実体のあるコンテンツとともに一貫して200を返し、消えるべきまたは移動したページが誤解を招く200ではなく404/410または301を返す状態です。

1行での判断

コードを現実に合わせます。インデックスに必要 → 実体のあるコンテンツを伴う200。 完全に消えた → 404または410（404-not-foundを参照）。移動した → 301。別URLとの重複 → 200を維持し、優先版へcanonicalタグを付けます。200は本当に存在する価値のあるページへの青信号であり、それ以上でもそれ以下でもありません。

AIサマリー

Advanced版を凝縮すると、次のとおりです。

• 200 OKは標準的な2xx成功コード（RFC 9110 §15.3.1）です。サーバーはリクエストを処理し、GET/HEADでは本文がリソースを表します。デフォルトではヒューリスティックにキャッシュ可能です。RFCでは本文を期待されるものとしていますが絶対条件ではなく、長さ0の200も技術的には有効です。ただしインデックス登録したいページには実体のある本文が必要です。
• 必要だが十分ではない。 Googleの文書は、インデックス登録システムが「may index the content, but that’s not guaranteed.」 (翻訳)「コンテンツを登録することがあるが、保証されない」と述べています。品質、重複、薄いコンテンツ、noindexは200の上で別途評価されます。競合ページの多くは「200＝登録済み」と書いてここを誤っています。
• ソフト404の落とし穴： エラーや空のコンテンツを200で包むとコンテンツ層で検出され、Search Consoleでソフト404として報告されます。「if the content suggests an error… Search Console will show a soft 404 error.」 (翻訳)「コンテンツがエラーを示唆する場合、Search Consoleはソフト404エラーを表示します。」実際に消えたページの200は、この状態を作ります。soft-404-errors記事を参照してください。
• 並行する落とし穴： HTTP層とアプリケーション層は食い違うことがあります。200がAPIエラーペイロードを包んだり、バックエンドの壊れたブロックを黙って返したりします。ステータス行が保証するのは転送の成功だけで、ペイロードの正しさではありません。
• 200と204と304： 200＝実体のある本文による成功（登録対象）、204＝意図的に空の本文による成功で、ページURLではソフト404扱い（204-no-contentを参照）、304＝条件付きリクエストに答えるキャッシュのシグナルで、インデックス登録の判断ではありません。
• Googlebotが受け取ったものを確認する。 クローキング、ボットブロック、地域ルール、CDN/WAF設定により、1つのURLでもリクエスト元ごとにコードが違うことがあります。「ブラウザーで200」≠「Googleも200」。GSC URL InspectionのLive Testまたはサーバーログで確認し、ブラウザーやcurlだけに頼らないでください。
• コードを現実に合わせる： 必要なら200＋実体のあるコンテンツ、消失なら404/410、移動なら301、重複ならcanonicalタグです。Patrickの表現では「200 OK – All good. Everything is successful.」 (翻訳)「200 OK — すべて良好。すべて成功です。」つまり、本当に存在する価値があるページに対しての話です。

公式ドキュメント

200の意味とGoogleの扱いを確認するための一次資料です。

HTTP仕様とブラウザーリファレンス

• RFC 9110 §15.3.1 — 200 OK — 権威ある定義、リクエストの成功、メソッドごとの本文の意味、ヒューリスティックなキャッシュ可能性。
• MDN — 200 OK — 平易な説明、デフォルトでのキャッシュ可能性、PUT/DELETEでは201/204が一般的という補足。

Google Search Central

• HTTPステータスコード、ネットワークエラー、DNSエラーがGoogle検索に与える影響 — 「コンテンツを登録することがあるが、保証されない」という2xxの扱いと、ソフト404への参照。
• ソフト404エラー — ページのインデックス登録レポート — 200を返す実質エラーページのGoogle公式定義と、消えたページに成功コードを返すべきでない理由。
• クローキング — ユーザーとGooglebotに異なるコードやコンテンツを返す仕組みと、ランキング操作目的の場合に違反となる理由。

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — BingbotがURLで受け取ったHTTPレスポンスを確認するBing側の方法（ステータスコードがインデックス登録へ与える影響を説明するBing作成の専用文書はありません）。

出典からの引用

記録に残る発言です。各リンクは、出典ページの引用箇所へ移動するディープリンクです。

HTTP仕様

• 「The 200 (OK) status code indicates that the request has succeeded.」 (翻訳)「200（OK）ステータスコードは、リクエストが成功したことを示す。」 — RFC 9110, HTTP Semantics, §15.3.1。 セクションを読む

MDN Web Docs

• 「The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.」 (翻訳)「HTTP 200 OK成功ステータスレスポンスコードは、リクエストが成功したことを示します。200 OKレスポンスはデフォルトでキャッシュ可能です。」 引用箇所へ

Google Search Central — 2xx / 200の扱い

• 「Google passes on whatever it received to the next processing step (which is product specific). For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.」 (翻訳)「Googleは受け取ったものを次の処理段階へ渡します（製品によって異なります）。Google検索では次のシステムがインデックス登録パイプラインです。登録することはありますが、保証されません。」 — GoogleのHTTPステータスコード文書の200項目。 Googleのステータスコード文書

• 「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エラーを表示します。」 — 同じ文書のソフト404への参照。 Googleのステータスコード文書

Patrick Stox — Ahrefs

• 「200 OK – All good. Everything is successful.」 (翻訳)「200 OK — すべて良好。すべて成功です。」 — Ahrefsブログの私のHTTP Status Codesガイド より。 引用箇所へ

• 「Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.」 (翻訳)「この成功コード群の大半はページをインデックス登録可能にします。ただし、本文を返さない応答はソフトな「見つからない」扱いとなり、登録されません。」 — 同じガイドの2xxファミリーの扱いについて。 引用箇所へ

200 OK — クイックリファレンス

概要

200と、混同されやすい兄弟コード

このURLはどのコードを返すべきですか？

• インデックスに必要 → 200と実体のあるコンテンツ。
• 完全に消えた → 404または410（404-not-foundを参照）。
• 新しいURLへ移動 → 301。
• 別URLとの重複 → 200を維持し、優先版へcanonicalタグを追加。
• 意図的に空（API/ビーコン） → 204（204-no-contentを参照）。ページには使わない。

要点

• 200はページをインデックス登録の対象にしますが、登録済みにはしません。Googleは品質、重複、薄いコンテンツ、noindexを別に判断します。
• 実際に消えた、または空のページの200は、Googleからソフト404と見なされます。
• 同じURLでもリクエスト元によってコードが違うことがあります。ブラウザーやcurlだけでなく、GSC URL InspectionやサーバーログでGooglebotが受け取ったものを確認します。
• コードはDevToolsのNetworkタブ、curl -I / curl -IL、GSC/Bing URL Inspection、Screaming Frog、Ahrefs Site Audit/Toolbarで確認できます。

200 OKに関するよくある神話

「A 200 status code means the page is indexed.」 (翻訳)「200ステータスコードはページがインデックス登録されたことを意味する。」 誤りです。200はサーバーがコンテンツを正常に返したことを意味します。インデックス登録は別の下流判断です。Google自身の文書は、インデックス登録システムが「may index the content, but that’s not guaranteed.」 (翻訳)「コンテンツを登録することがあるが、保証されない」と説明しています。品質、重複、薄いコンテンツ、noindexは200の上で別途評価されます。

「If Search Console shows a soft 404, my server has a bug.」 (翻訳)「Search Consoleがソフト404を表示するなら、サーバーにバグがある。」 必ずしもそうではありません。ソフト404はサーバーが送るコードではなく、200ステータスと、エラーまたは空ページのように読めるコンテンツとの不一致に基づいてGoogleが付けるラベルです。サーバーは設定どおり200を送っているだけで、問題はヘッダーではなくコンテンツです。

「200 is always good, full stop.」 (翻訳)「200は常に良い、以上。」 常にではありません。404を返すべきURL、たとえば削除済み商品、期限切れの掲載、空の検索結果ページが200を返すのは積極的に悪い状態です。ソフト404扱いを招き、提供するものがないURLを再訪することでクロールの労力を浪費する可能性があります。

「My browser shows 200, so Google definitely sees 200 too.」 (翻訳)「ブラウザーに200と表示されるから、Googleにも必ず200が見えている。」 保証はありません。ボットブロック、クローキング、地域IPルール、CDN/WAF設定によって、Googlebotには人間のブラウザーと異なるレスポンスが返ることがあります。URL Inspectionまたはサーバーログで確認してください。

「200 and 204 are basically the same — both mean success.」 (翻訳)「200と204はほぼ同じで、どちらも成功を意味する。」 どちらも2xxですが、204は設計上本文が空です。APIやビーコンには問題ありませんが、インデックス登録したいページには不適切です。ページURLの204はソフト404として扱われます（204-no-contentを参照）。

「200 vs 304 — aren’t those the same idea?」 (翻訳)「200と304は同じ考え方ではないか。」 違います。304 Not Modifiedは条件付きリクエスト（If-None-Match / If-Modified-Since）に応答するキャッシュ機構で、クライアントにキャッシュ済みコピーを使わせます。本文を持たず、インデックス登録の判断でもありません。200とは別の概念です。

200 OKページがなお失敗する理由

Search ConsoleがURLをソフト404と呼ぶ場合

症状： URLは200を返しますが、ページのインデックス登録レポートではソフト404と報告されます。

考えられる原因： レスポンス本文が空、壊れている、またはエラーページのように見えます。よくあるのは、有用な商品情報のない販売終了商品、完全なテンプレートの中にある削除済み記事、0件の検索結果ページです。

修正： レスポンスを現実に合わせます。ページが存在すべきなら実体のあるコンテンツを戻し、消えたなら404または410を返し、移動したなら301を使います。URL InspectionのLive Testを再実行し、レスポンスとレンダリング済みコンテンツが一致することを確認します。

ブラウザーは200だがGooglebotはそうでない場合

症状： DevToolsやcurlは200を示すのに、GoogleがURLを取得またはインデックス登録できません。

考えられる原因： CDN、WAF、地域ルール、ボットルール、実験設定がGooglebotに別のレスポンスを返しています。自分のリクエストはGoogleのリクエストの証明ではありません。

修正： 通常のリクエストとGooglebotユーザーエージェントのリクエストを比較し、URL Inspectionとサーバー/CDNログを確認します。エッジルールを修正し、Live Testがユーザーと同じ実体のある本文を伴う200を受け取ることを確認します。

ページは200だがなおインデックス登録されない場合

症状： ステータスコードは健全なのに、URLがインデックスから除外されたままです。

考えられる原因： 200はコンテンツを処理対象にするだけです。noindex、重複/canonicalの競合、価値の低いコンテンツによって、検索対象外になることがあります。

修正： ステータスコードを変えるのをやめます。インデックス登録ディレクティブ、Googleが選んだcanonical、実際のコンテンツを確認してください。HTTPレスポンスの成功は、インデックス登録の判定ではありません。

間違った物語を伝える200レスポンス

これは簡略化した例です。ステータス行は技術的には成功していますが、その成功が正直なものかどうかは本文で決まります。

空の商品シェル：誤解を招く200

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

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

商品が代替品なしで恒久的に消えたなら、404または410を返します。有用な商品ページ（仕様、代替品、サポート、在庫情報）が残っているなら、ページに実際の目的があるため200が適切な場合もあります。

代替ページがある削除済み記事：リダイレクトを使う

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

「article deleted」と表示するテンプレートの200ページはユーザーを取り残し、ソフト404の分類を招きます。関連する代替ページをサーバー側301の転送先にすべきです。

内部検索の0件：有用か空か

ページが検索語の言い換え、カテゴリの閲覧、代替案の発見を助けるなら、200は正直なレスポンスです。一方、「0 results」だけを含む薄いページは、成功コードでもエラーのように見えます。違いを決めるのは本文の有用性であり、200という数字ではありません。

疑わしい200レスポンスをトリアージする

URL、ステータス、タイトル、canonical、インデックス可否、本文テキストの短いサンプルを含むクロール書き出しを貼り付けます。このプロンプトは、HTTPの成功とコンテンツ・インデックス登録の問題を分けます。

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

ページを信用せずレスポンスを確認する

curlで1つのレスポンスを確認する

macOS、Linux、WSLで実行できます。最初のコマンドはレスポンスヘッダーを読み、2つ目は本文もダウンロードするため、200に実体のあるコンテンツが含まれることを確認できます。

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

200のステータス行を探し、page.htmlを開きます。ヘッダーだけではソフト404を見抜けません。

通常のリクエストとGooglebotユーザーエージェントを比較する

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

差があればCDN/WAFルールとログを調べる理由になりますが、Googlebot自身が偽装リクエストのレスポンスを受け取った証明ではありません。URL Inspectionで実際の取得を確認してください。

200以外のレスポンスを一覧で確認する

URLをurls.txtに1行1件で入れます。

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

これは明らかなステータス不一致を見つけます。200の本文が実体のあるものかどうかは判断できないため、疑わしいテンプレートとソフト404の報告を追加で確認してください。

200レスポンスを検証するツール

Patrickの無料ツール

• Bulk HTTP Status Code Checker — 最大500件のURLを貼り付け、ステータスコード、最終到達先、リダイレクトチェーン、レイテンシーを1回の書き出しで収集します。実際には200で終了していないレスポンスを見つけるために使い、その後、ステータスチェッカーではコンテンツの品質やインデックス登録を判断できないため、本文とSearch Consoleでソフトエラーを別々に確認してください。

検索エンジンとサーバーの証拠

• Google Search Console URL Inspection — インデックス登録済みの結果とライブ取得を比較し、Googleが取得できるレンダリング済みコンテンツを確認します。
• Bing Webmaster Tools URL Inspection — Bingbotが受け取ったと報告するレスポンスを確認します。
• サーバーとCDNのログ — 実際のクローラーリクエストが受け取ったステータスコードを確認します。ログはcurlでユーザーエージェント文字列を変えるより強い証拠です。
• ブラウザーDevToolsのNetworkパネル — ブラウザーセッションのdocumentリクエスト、レスポンスヘッダー、本文を確認します。

実力チェック：200 OK

200がSEOにとって何を意味するかを問う5つの簡単な質問です。各回答を選んでから確認してください。

変更履歴