204 No Content（本文なし）

TL;DR — 204 No Content レスポンスは、「your request worked, and I’m deliberately sending back an empty page.」 (翻訳)「リクエストは成功し、意図的に空のページを返している」という意味です。エラーではなく、成功コードです。アプリがバックグラウンドで作業を保存したり、アナリティクストラッカーが動作したりする場合には問題ありませんが、Googleに表示したい実際のウェブページには不適切です。空のボディではGoogleがインデックスするものがないため、ページ上の204をソフト404として扱います。

204とは何か

サーバーが返すすべてのレスポンスにはステータスコードがあります。2xxコードは「success.」 (翻訳)「成功」を意味します。ページで使いたい200 OKは、「これがページです」という意味で、ボディも含まれます。204 No Contentも成功を意味しますが、ひとひねりあります。サーバーは「I did what you asked, and there’s intentionally nothing to show you.」 (翻訳)「要求された処理を実行し、表示するものは意図的に何もない」と伝えているのです。

重要な語は意図的にです。204は読み込みに失敗したページでも、存在しないURLでもありません。空になるよう設計されたレスポンスです。サーバーが「done」 (翻訳)「完了」とうなずきながら、何も返さない状態だと考えてください。

ウェブページでは問題になる理由

Googleはページのコンテンツをインデックスします。URLが204を返すと、読むべきコンテンツがなく、ボディは設計上空です。Google自身のドキュメントは明確に、「wasn’t able to receive any content and therefore can’t process it.」 (翻訳)「コンテンツを受信できなかったため、処理できない」と述べています。そのため、ランキングを狙うページが204を返すと、Googleに処理の材料を渡せず、インデックスされません。実際には、技術的には「成功」していてもインデックスする価値のないページとして、ソフト404と同じようにSearch Consoleで扱われることがよくあります。

したがって、ランキングを狙うページがクロールやSearch Consoleで204として現れたら、放置するものではなく、修正すべきバグです。

204がまったく問題ない場合

目にする204sのほとんどは、そもそもページではありません。

• バックグラウンドでのアプリ保存。 「保存」を押すと、アプリがページを再読み込みせずに作業を保存し、サーバーが204で応答できます。
• アナリティクスとトラッキング。 トラッカーは、何かが起きたことを記録するために小さな「ビーコン」リクエストを送ります。返すページがないため、204がまさに適切です。
• アプリのインターフェース（API）。 あるシステムが別のシステムに何かの削除を指示すると、返すものがないことがよくあります。204は「完了」を意味します。

これらはどれもGoogleに登録する必要がないため、204は誤りではなく、正しい答えです。

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

検索で見つけてほしいURLには、絶対に204を返さないでください。 ページが完全になくなったなら404または410を使います。移転したなら301でリダイレクトします。コンテンツを返すはずなら、空のレスポンスを返している処理を修正します。より詳しい内容――Googleの正確な表現、APIとビーコンのユースケース、誤った204の診断方法――は、Advancedタブに切り替えてください。

TL;DR — 204は仕様に準拠した2xx成功コード（RFC 9110 §15.3.5）で、設計上空のボディを返します。ボディは必ず空でなければならず（Content-Lengthも、0でさえ不可）、コンテンツを含む204をブラウザが拒否する場合があります。エラーではなく、存在について何も示しません。また、RFCは固定されたメソッド一覧に制限していません。正当な用途はほぼすべてドキュメント以外のレスポンスで、REST APIのDELETE/PUTやアナリティクスビーコン（sendBeacon()、GA4のMeasurement Protocol）です。ただし、APIがどの程度204を使うべきかについて実務家の意見は分かれています。SEOへの影響は限定的です。Googleのステータスコード表は、204について「Google wasn’t able to receive any content and therefore can’t process it.」 (翻訳)「Googleはコンテンツを受信できなかったため、処理できない」と明記しています。つまり、そのレスポンスを返す限り、ランキングを狙うページはインデックスされません。実際にはSearch Consoleでソフト404として報告されることがよくありますが、その特定のラベルや削除時期をGoogleが保証しているわけではありません。ページレベルの204が誤っているなら、実体のある200に戻すか、意図に応じて404/410/301を使います。

仕様上の204の意味

RFC 9110（HTTP Semantics）は明確です。204は「the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.」 (翻訳)「サーバーがリクエストを正常に完了し、レスポンスのペイロードボディに送る追加コンテンツがない」ことを示します。これは200 OKと同じ2xxファミリーの成功コードですが、意図的にボディがない点が異なります。

運用上重要なのは3点です。1つ目は、ボディが本当に空でなければならないことです。MDNは204について「must not include any content or the Content-Length header (browsers may reject responses that include content).」 (翻訳)「コンテンツやContent-Lengthヘッダーを含めてはならない（コンテンツを含むレスポンスをブラウザが拒否する場合がある）」と説明しています。これは緩やかな慣例ではなく、実際の禁止事項です。RFC 9110 §8.6は204からContent-Lengthを全面的に禁じているため、「Content-Length: 0を送ればよい」という、私が推奨例で見かけた修正も実際には準拠していません。レスポンスはヘッダーセクションの終わりで完全に終了します。2つ目は、204に含まれるヘッダー（ETagやLast-Modified）は、送信されたボディではなく、処理完了後の選択された表現を説明します。3つ目は、ETagが一部の204に現れることです（MDNの例は、リソースをその場で更新するPUTです）が、RFCはすべての204に含めるよう求めていません。常にあるものとは考えないでください。204は、メソッドや明示的なキャッシュ制御ヘッダーが別の指定をしない限り、デフォルトでヒューリスティックにキャッシュ可能です。

重要なのは、204はURLが存在するかどうかとは無関係だということです。動作するAPIエンドポイントが、いつまでも正しく204を返すこともあります。これは、存在しないことを示す404（not found）や410（gone）との違いです。204は、ペイロードを意図的に持たない成功したリクエストについてのコードです。

Googleは204をどう扱うか

SEOについての話はこれです。ベンダーブログの定型文が思わせるより、範囲は狭いものです。Googleはコンテンツをインデックスします。204にはコンテンツがありません。Google自身のステータスコード文書は、204を具体的で限定された形で取り上げています。一般的な2xxのルールが「Google considers the content for processing,」 (翻訳)「Googleはコンテンツを処理対象とみなす」なのに対して、204専用の行は「Google wasn’t able to receive any content and therefore can’t process it.」 (翻訳)「Googleはコンテンツを受信できなかったため、処理できない」としています。

それが実際の境界です。何を意味し、何を約束しないのかを正確に捉える価値があります。同じページの別の箇所にある2xxの一般的な説明では、空またはエラーに似たコンテンツがソフト404として報告される場合があるとされています。しかし204の行自体は、すべての204がその特定のSearch Consoleラベルに入るとは保証しておらず、Googleは削除時期も公表していません。確実なのは、コンテンツURLの204がGoogleのインデックス処理パイプラインに処理材料を何も渡さないことです。そのため、そのレスポンスからURLがインデックスされないと言うのは妥当な推論ですが、「サイト全体のランキング低下が保証される」とか「クロールバジェットが自動的に回復する」とまで広げる主張ではありません。Google自身の文書は、どちらの約束もしていないからです。実際には、Search Consoleがこれらをソフト404として表示することがよくあります。これは私が見て書いてきたパターンですが、特定のレポートラベルや時期は、文書化された保証ではなく、観察された挙動として扱ってください。

これは私が自分の文章で示してきた立場です。AhrefsブログのHTTPステータスコードとSEOへの影響 ガイドで、Googleが2xxレスポンスをどう扱うかについて、私はこう直接書きました。「Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.」 (翻訳)「ほとんどの2xxsはページのインデックスを許可する。ただし204sはソフト404sとして扱われ、インデックスされない」。これが実務上の読み方だという考えは変わりません。より正確で現在のGoogle自身の文言は、上記の「コンテンツを受信または処理できない」という説明であり、正確な公式の境界として参照すべきものです。

ソフト404は、クロールされ続け、クロールバジェットを浪費することがあると文書化されています。ただし、これはGoogleの一般的なソフト404の説明であり、204に特化した約束ではありません。204を使ったからといって、クロールリソースが自動的に解放されたり振り替えられたりするわけではありません。Google自身の説明では、リソース配分は、どのステータスコードが除外のきっかけになったかではなく、配信上限、サイト品質、在庫などに左右されます。安全な結論は、特定のクロールバジェット上の見返りが得られるからではなく、誤った204によってページがインデックスされなくなるから修正する、ということです。

混同されるステータスコードとの204の違い

204、空の200、404、410は、使えるコンテンツがない場合、GSCでいずれも「ソフト404」と表示されることがあります。しかし、仕様に準拠したクライアントに伝える意図はそれぞれ大きく異なります。410は「これは存在していたが、恒久的になくなった」という意図的なシグナルです。204はその意味のために設計されたものではないため、ページURLに置くべきではありません。

204が正解になる場合（バグではない）

正当な204のほぼすべては、ドキュメントではないレスポンスです。

• REST APIのDELETE/PUT。 クライアントがリソースを削除したり、その場で更新したりして、返す意味のあるものがない場合、204が慣用的な答えです。RFC 9110自体が推奨するパターンでもあります。
• アナリティクスとトラッキングのビーコン。 W3C Beacon仕様はnavigator.sendBeacon()を中心に構成されており、ビーコンエンドポイントが204で応答することを想定しています。Google Analytics 4のMeasurement Protocolエンドポイントは、受け付けたヒットに対して204を返します。注意点として、GA4は不正形式または無効なペイロードにも204を返すため、そこでの204が確認するのは、エンドポイントに到達して構造的に応答したことだけです。ヒットが実際に処理された証拠ではありません。ビーコンの204を成功の証拠と解釈しないでください。
• 「ページを離れずに保存」するUX。 状態を保存し、ユーザーを現在のページに留めるPUTでは、MDN自身の説明どおり、204なら「the client doesn’t need to navigate away from its current page.」 (翻訳)「クライアントは現在のページから移動する必要がない」からです。

一貫しているのは、これらが誰もインデックスさせるべきではないURLだということです。したがって、そこに204を返すのは正しく、期待どおりです。問題は、ランキング対象のドキュメントURLに204が置かれている場合だけです。

関連する注意点があります。RFC 9110は204をDELETE/PUT/ビーコンだけに限定していません。それらは一般的なパターンにすぎません。仕様の定義はメソッドに中立で、重要なのは各メソッドの契約と、表現を返すことが有用かどうかです。これは両方向に働きます。GETリクエストが204を返すのはプロトコル上合法であり、Stack Overflowでも何年も議論されてきました。インデックス可能なページについて本当に問うべきなのは「is 204-on-GET allowed」 (翻訳)「GETで204を返してよいか」ではなく、「does this URL need to hand Google a representation to be findable」 (翻訳)「見つけてもらうために、このURLはGoogleへ表現を渡す必要があるか」です。ランキングを狙うページなら、答えは常にイエスです。つまりSEOのルールは、どのHTTPメソッドかではなく、そのURLがそもそもドキュメントであるべきかに関するものです。

「204 is always right for API responses」 (翻訳)「APIレスポンスには常に204が正しい」という考えが、API設計者の間でも普遍的に合意されているわけではないことも知っておくとよいでしょう。Postman自身の解説は、返すものがないアクションには204を第一選択としています。一方、Brandur Leachは反対の立場を論じています。空の成功レスポンスは、書き込みが成功した後でも表現（更新後の状態、生成されたID、計算済みフィールド）が返ることを期待するAPIクライアントに、軽い害を与える可能性があるという主張です。これはHTTPの正しさの問題ではなく、開発者体験に関するAPI設計上のトレードオフです。どちらの場合も204は仕様に準拠しており、この記事のSEOの問いとは別です。APIの解説で時々雑に扱われる点が1つあります。204に「to be safe」 (翻訳)「安全のため」とContent-Length: 0を付けることです。やめてください。RFC 9110 §8.6は、204レスポンスのContent-Lengthを、ゼロ以外の場合だけでなく、全面的に禁止しています。

ページレベルで誤って204になった場合の診断と修正

コンテンツがあるはずのページで、クローラー（Screaming Frog、Ahrefs Site Audit）やログが204を示している場合：

1. Googlebotが実際に受け取るものを確認する。 Search ConsoleのURL検査を使って、ブラウザに表示されるものではなく、Googleが受け取るステータスとレンダリング済みコンテンツを確認します。CDN、エッジワーカー、WAF、アプリのルートが、ボットに対して、または特定の条件で204を返し、あなたには正常に見えることがあります（余計な403で起こる「ブラウザでは正常に見える」パターンと同じです）。
2. 次に、意図に応じて修正する：
   • コンテンツ付きでページを存在させるべき → 204を返しているサーバー／CDN／アプリのロジックを見つけ、実際のボディを持つ正しい200に戻す。
   • 代替がなく、ページがなくなった → 404または410を返す。
   • ページが移転した → 新しいURLへ301でリダイレクトする。
3. 監視する。 GSCのPage Indexingレポートでソフト404の項目を確認し、ログのクロールステータスコードを監視し、クローラーで204を検出するよう設定します。そうすれば、テンプレートの1箇所の不具合がセクション全体のインデックスを静かに解除することを防げます。

覚えておくべきメンタルモデルは、204が「悪い」わけではないということです。APIやビーコンのエンドポイントには適した、正確なツールであり、ドキュメントには不適切です。失敗モードは、間違った場所で使うことだけです。403、404、410、ソフト404などの兄弟も、それぞれ判断の中で置き場所があります。204の置き場所はページの外です。

AIによる要約

Advanced版の要点をまとめると、次のとおりです。

• 204 No Contentは2xx成功コード（RFC 9110 §15.3.5）で、設計上空のボディを返します。エラーではなく、URLの存在について何も示しません。RFCは固定されたメソッド一覧に制限していません。DELETE/PUT/ビーコンは一般的なパターンですが必須ではなく、GETでの204もプロトコル上合法です。
• ボディは例外なく空でなければなりません。 MDNによれば、204はコンテンツやContent-Lengthヘッダーを含めてはならず、RFC 9110 §8.6もContent-Lengthを全面的に禁止しているため、Content-Length: 0も実際には準拠していません。204に含まれるヘッダーは、転送されたボディではなく、処理後の選択された表現を説明します。204はデフォルトでヒューリスティックにキャッシュ可能ですが、すべての204にETagがあるとは限りません。MDNの例にあるのは特定のPUTケースであり、普遍的なルールではありません。
• SEOへの影響（狭く、正確に限定されます）： Googleのステータスコード文書は、204について「Google wasn’t able to receive any content and therefore can’t process it.」 (翻訳)「Googleはコンテンツを受信できなかったため、処理できない」と明記しています。これは、そのレスポンスからランキングを狙うページがインデックスされないという妥当な推論を支えます。しかしGoogleは、すべての204に特定のソフト404ラベルが付くことや削除時期を保証しておらず、204の使用でクロールバジェットが自動的に回復することや、ランキングへの影響が証明されることもありません。Patrickが自身の文章で述べるとおり、「204s will be treated as soft 404s and won’t be indexed」 (翻訳)「204はソフト404として扱われ、インデックスされない」というのが、彼が見てきた実務上のパターンです。ただし、公式の正確な文言はより狭いものです。
• 正当な用途は主にドキュメント以外です。 REST APIのDELETE/PUTや、アナリティクスビーコン（sendBeacon()、GA4 Measurement Protocol）です。GA4は不正形式のヒットにも204を返すため、ビーコンの204はヒットが処理された証拠にはなりません。ここでも実務家の意見は完全には一致していません。Postmanは返すものがないアクションのデフォルトとして204を扱う一方、Brandur Leachは、空の成功レスポンスが表現を期待するクライアントに軽い害を与えうると論じています。これはHTTPの正しさではなく、APIの使いやすさをめぐる議論です。
• ランキング可能なページに204が適切なことはありません。 代替なく消えた → 404/410、移転した → 301、コンテンツがあるはず → 204を出しているサーバー／CDNを修正して、実体のある200に戻します。Googlebotが受け取るものはURL検査で確認してください。

公式ドキュメント

204とは何か、そしてGoogleが204をどう扱うかについての一次情報です。

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

• RFC 9110 §15.3.5 — 204 No Content — 成功、ペイロードボディなし、トレーラーなし、ヒューリスティックなキャッシュ可能性、処理後の選択された表現をヘッダーが説明することを定義する権威ある仕様です。
• RFC 9110 §8.6 — Content-Length — 204レスポンスでContent-Lengthを（ゼロでない場合に限らず）全面的に禁止するルールです。
• MDN — 204 No Content — 平易な説明、空ボディとContent-Lengthの制約、キャッシュ可能性、特定の例におけるETag、そして「ページを離れずに保存」するユースケースを説明しています。

Google Search Central

• HTTPステータスコードとネットワーク・DNSエラーがGoogle検索に与える影響 — 204を明示的に取り上げるステータスコード表と、ソフト404の定義です。

ビーコンとアナリティクス（正当な204のケース）

• W3C — Beacon — ビーコンエンドポイントが204を返すことを想定するnavigator.sendBeacon()仕様です。
• Google Analytics 4 — Measurement Protocolリファレンス — 受け付けたヒットに204を返すことを含め、GA4の収集エンドポイントのレスポンスを説明しています。

ソースからの引用

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

HTTP仕様

• 「The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.」 (翻訳)「204（No Content）ステータスコードは、サーバーがリクエストを正常に完了し、レスポンスのペイロードボディに送る追加コンテンツがないことを示します。」 — RFC 9110, HTTP Semantics, §15.3.5。 セクションを読む

MDN Web Docs

• 「The HTTP 204 No Content successful response status code indicates that a request has succeeded, but the client doesn’t need to navigate away from its current page. A 204 response is cacheable by default, and an ETag header is included in such cases.」 (翻訳)「HTTPの204 No Content成功レスポンスステータスコードは、リクエストが成功したものの、クライアントが現在のページから移動する必要がないことを示します。204レスポンスはデフォルトでキャッシュ可能で、このような場合はETagヘッダーが含まれます。」 引用へ移動

Google Search Central — 2xx / 204の扱い

• 「Google wasn’t able to receive any content and therefore can’t process it.」 (翻訳)「Googleはコンテンツを受信できなかったため、処理できません。」 — GoogleのHTTPステータスコード文書、2xx表の204行（「Google considers the content for processing.」 (翻訳)「Googleはコンテンツを処理対象とみなす」とする一般的な2xxのルールとの対比）。 Googleのステータスコード文書

Patrick Stox — Ahrefs

• 「Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.」 (翻訳)「ほとんどの2xxsはページのインデックスを許可します。ただし204sはソフト404sとして扱われ、インデックスされません。」 — 私のHTTPステータスコードとSEOへの影響 ガイドより。 引用へ移動

Matt G. Southern — Search Engine Journal

• 「The exception is a 204 status code, which means the page was successfully accessed but no content was found. Google may show a soft 404 in Search Console for pages serving a 204 code.」 (翻訳)「例外は204ステータスコードです。これはページへのアクセスは成功したものの、コンテンツが見つからなかったことを意味します。Googleは204コードを返すページについて、Search Consoleにソフト404を表示することがあります。」 引用へ移動

正当な204sと誤った204s

204がどこに属し、どこではバグになるのかを示す具体例です。

正しい例：REST APIのDELETE

クライアントがリソースを削除するため、返すものがありません。

DELETE /api/items/42 HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content

ボディなし、Content-Lengthなし。これは慣用的な答えであり、検索に表示されると期待するURLになってはいけません。

正しい例：アナリティクスビーコン（sendBeacon）

// Fires a fire-and-forget beacon on page unload
navigator.sendBeacon('/collect', payload);
// Endpoint responds:  HTTP/1.1 204 No Content

エンドポイントには提供するページがないため、204がまさに適切です。GA4のMeasurement Protocolエンドポイントも同じです。ただし、GA4は不正形式のヒットにも204を返すため、204が確認するのはエンドポイントが応答したことだけで、ヒットが処理されたことではない点を覚えておいてください。

誤った例：コンテンツページが204を返す

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content        ← bug: a real page must return 200 + body

Googleは空のボディを受け取り、URLをソフト404のように扱い、インデックスしません。修正方法は意図によって異なります。

• コンテンツ付きで存在するべき → 実際のボディを持つ200 OKを復元する（204を返しているサーバー／CDN／アプリのルートを修正する）。
• 代替なしでなくなった → 404または410。
• 移転した → 新しいURLへ301でリダイレクトする。

経験則： 人間がURLに到達して何かを読む想定なら、ボディ付きの200を返さなければなりません。204は、APIやビーコンのように、表示するものが本当にないマシン間エンドポイントに限定してください。

予期しない204を診断する

ページが空白で、Networkパネルに204が表示される場合

症状： コンテンツを表示するはずのドキュメントURLが204 No Contentを返します。

考えられる原因： アプリケーションのルーティング、CDNルール、エッジワーカー、またはエラーハンドラーが、ページルートでAPI風の成功レスポンスを返しています。

修正： レスポンスを管理するレイヤーを通じてリクエストを追跡します。ページが存在するべきなら、実体のあるボディ付きの200を復元します。新しいヘッダーリクエストと、キャッシュを無効にしたブラウザーの再読み込みで修正を確認してください。

Search Consoleが204 URLをソフト404として報告する場合

症状： 204は成功コードなのに、URLがソフト404として除外されます。

考えられる原因： 分類が見ているのは、コードが2で始まるかどうかではなく、コンテンツがないことです。204は定義上ボディを持ちません。

修正： 意図に応じてレスポンスを選びます。実際のページならコンテンツ付きの200、移転なら301、なくなったページなら404/410です。変更をデプロイしたら、URL検査を再実行してください。

ブラウザーとクローラーでステータスが一致しない場合

症状： ブラウザーではページが正常に見えるのに、クローラーやログには204と表示されます。

考えられる原因： ボット、メソッド、地域、キャッシュ、WAF、またはエッジのロジックによってレスポンスが変化しています。

修正： GETとHEAD、通常のユーザーエージェントとGooglebotユーザーエージェントへのリクエスト、そしてサーバー／CDNログ内の正確なリクエストを比較します。条件付きルールを修正し、両方の経路が同じ意図したレスポンスを返すことを確認してください。

204 URLのセットを意図で分類する

URL、リクエストメソッド、コンテンツタイプ、リファラーまたはルートタイプ、レスポンスコードを含むクロールまたはログのエクスポートを貼り付けます。

Classify each HTTP 204 row I provide as:
- likely legitimate API response,
- likely legitimate beacon/background request,
- accidental document/page response, or
- insufficient evidence.

For every row, cite the supplied evidence, explain why 204 does or does not fit, and give
the next verification step. For accidental page responses, recommend exactly one intended
outcome: 200 with content, 301 to a relevant replacement, or 404/410 if gone.

Do not infer that a 204 analytics response means the event was processed. Do not invent
route behavior, redirect targets, or page content. Return a table followed by a prioritized
manual-check queue.

PASTE ROWS HERE

誤った204レスポンスを見つける

1つのURLとリクエストメソッドを調べる

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

そのURLがコンテンツを表示する想定なら、ドキュメントリクエストは204であってはいけません。誤ったメソッド固有のハンドラーは応答が食い違うことがあるため、GETとHEADをテストします。

デフォルトと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"

一方の経路だけでダウンロードバイト数ゼロの204が出るなら、サーバー、CDN、WAFの条件付きロジックが示唆されます。実際のログとURL検査を使って、Googleが実際に受け取ったものを確認してください。

URLリストから204sを報告する

while IFS= read -r url; do
  code=$(curl -sS -o /dev/null -w "%{http_code}" "$url")
  if [ "$code" = "204" ]; then printf '%s\t%s\n' "$code" "$url"; fi
done < urls.txt

macOS、Linux、またはWSLで、urls.txtに1行1URLを入れて実行します。各結果をルートの意図に沿って確認してください。APIとビーコンの204sはエラーではありません。

正当な204sと誤った204sを切り分けるツール

Patrickの無料ツール

• 一括HTTPステータスコードチェッカー — 最大500件のURLをチェックし、結果を204で絞り込み、該当セットをエクスポートします。ルートとコンテンツの文脈を使って、有効なAPI／ビーコンエンドポイントと、コンテンツを返すべきページURLを切り分けます。

原因を確認する

• Google Search ConsoleのURL検査 — ページURLをライブテストし、レスポンスを変更した後にGoogleが取得できるものを確認します。
• サーバー／CDNログ — 204がメソッド、ユーザーエージェント、ルート、エッジの場所によって変化するかを特定します。
• ブラウザのDevTools Networkパネル — ドキュメントリクエストとバックグラウンドのAPI／ビーコン呼び出しを区別します。ビーコンの204は正しい場合がありますが、ドキュメントの204は正しくありません。
• フルサイトクローラー — 204を返すドキュメントURLを一覧化し、定期監査に組み込んで、テンプレートのリグレッションがセクション全体に影響しないようにします。

確認テスト：204 No Content

204の意味と適切な使い方についての簡単な5問です。それぞれ答えを選んでから、確認してください。

変更履歴