204 No Content

TL;DR — A 204 No ContentHTTP 204 No Content is a 2xx success status meaning the server fulfilled the request but is intentionally sending back no message body. It's correct for APIs and beacons — but on a page meant to be indexed, Google treats it like a soft 404. response means “your request worked, and I’m deliberately sending back an empty page.” It’s a success code, not an error. That’s perfectly fine for things like an app saving your work in the background or an analytics tracker — but it’s wrong for a real web page you want in Google. An empty body gives Google nothing to indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., so it treats a 204 on a page like a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing..

What a 204 actually is

Every response your server sends comes with a status code. The 2xx codes mean “success.” 200 OK — the one you want on your pages — means “here’s the page,” body and all. 204 No Content also means success, but with a twist: the server is saying “I did what you asked, and there’s intentionally nothing to show you.”

The key word is intentionally. A 204 isn’t a page that failed to load or a URL that doesn’t exist — it’s a response that was designed to be empty. Think of it as the server nodding “done” without handing anything back.

Why that’s a problem for a web page

Google indexes the content of a page. If a URL returns a 204, there’s no content to read — the body is empty by design. Google’s own documentation says it plainly: it “wasn’t able to receive any content and therefore can’t process it.” So a page you want ranking that returns a 204 isn’t giving Google anything to work with, which means it won’t get indexed — and in practice, Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. commonly flags these the same way it flags a soft 404: a page that technically “succeeded” but has nothing worth indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..

So when a page you want ranking shows up as a 204 in a crawl or in Search Console, that’s a bug to fix, not something to leave alone.

When a 204 is completely fine

Most 204s you’ll ever see aren’t pages at all:

• Apps saving in the background. You hit “save” and the app stores your work without reloading the page — the server can answer with a 204.
• Analytics and tracking. Trackers fire tiny “beacon” requests to record that something happened. There’s no page to return, so a 204 is exactly right.
• App interfaces (APIs). When one system tells another to delete something, there’s often nothing to send back — a 204 says “done.”

None of those need to be in Google, so a 204 there is the correct answer, not a mistake.

The one rule to remember

Never return a 204 for a URL you want people to find in search. If a page is gone for good, use a 404 or 410. If it moved, redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. it (301). If it’s supposed to have content, fix whatever’s serving an empty response. Want the deeper version — Google’s exact wording, the API and beacon use cases, and how to diagnose an accidental 204 — switch to the Advanced tab.

TL;DR — 204 is a spec-compliant 2xx success code (RFC 9110 §15.3.5) that returns an empty body by design — the body must be empty (no Content-Length either, not even 0), and browsers may reject a 204 that ships content. It’s not an error and says nothing about existence, and the RFC doesn’t restrict it to any fixed method list. Legitimate uses are almost all non-document responses: REST API DELETE/PUT, and analytics beacons (sendBeacon(), GA4’s Measurement Protocol) — though practitioners disagree on how often APIs should reach for it. The SEO consequence is narrow: Google’s status-code table says plainly that for a 204, “Google wasn’t able to receive any content and therefore can’t process it” — which means a page you want ranking won’t get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. from that response, and in practice these commonly get flagged as soft 404sA soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results., though Google doesn’t guarantee that specific label or a removal timetable. Fix an accidental page-level 204 by restoring a real 200, or by using 404/410/301 as the intent warrants.

What 204 means in the spec

RFC 9110 (HTTP Semantics) is unambiguous: a 204 indicates “the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” It’s a success code — same 2xx family as 200 OK — with the deliberate difference that there’s no body.

Three operational details matter. First, the body genuinely has to be empty: MDN notes a 204 “must not include any content or the Content-Length header (browsers may reject responses that include content).” That’s a real prohibition, not a loose convention — RFC 9110 §8.6 bars Content-Length from a 204 outright, so “just send Content-Length: 0” (a fix I’ve seen recommended) isn’t actually compliant either; the response ends at the header section, full stop. Second, any headers a 204 does carry — an ETag, a Last-Modified — describe the selected representation after your action completed, not a body that got sent. Third, an ETag shows up on some 204s (MDN’s example is a PUT that updates a resource in place) but the RFC doesn’t require every 204 to include one — don’t expect it as a given. A 204 is heuristically cacheable by default unless the method or explicit cache-controlCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. headers say otherwise.

Crucially, 204 has nothing to do with whether a URL exists. A working API endpoint can correctly return 204 forever. That’s the difference from a 404 (not foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.) or a 410 (gone) — those are about absence; 204 is about a successful request that deliberately carries no payload.

How Google treats a 204

Here’s the whole SEO story, and it’s narrower than the vendor-blog boilerplate makes it sound. Google indexes content. A 204 has no content. Google’s own status-code doc singles 204 out with a specific, bounded statement: where the general 2xx rule is that “Google considers the content for processing,” the dedicated 204 row says instead that “Google wasn’t able to receive any content and therefore can’t process it.”

That’s the actual boundary, and it’s worth being precise about what it does and doesn’t promise. The general 2xx guidance elsewhere on that page says empty or error-like content may get reported as a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. — but the 204 row itself doesn’t guarantee every 204 lands under that specific Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. label, and Google doesn’t publish a removal timetable for it. What’s solid: a 204 on a content URL supplies Google’s indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. pipeline with nothing to work with, so saying the URL won’t get indexed from that response is a reasonable inference — not a claim I’d extend into “guaranteed site-wide ranking loss” or “automatic crawl-budget recovery,” because Google’s own documentation doesn’t make either promise. In practice, Search Console commonly does surface these as soft 404s — that’s the pattern I’ve seen and written about — but treat the specific report label and timing as observed behavior, not a documented guarantee.

This is the position I’ve held in my own writing. In my HTTP Status Codes & Their SEO Impact guide on the Ahrefs blog, under how Google handles 2xx responses, I put it directly: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” I stand by that as the practical read; the more precise, current wording from Google’s own doc is the “can’t receive or process content” framing above, which is what I’d point you to for the exact official boundary.

Soft 404s are documented as continuing to get crawled and wasting crawl budgetThe number of URLs an engine will crawl in a timeframe. — but that’s Google’s general soft-404 guidance, not a 204-specific promise. Using 204 doesn’t automatically free up or redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. crawl resources; Google’s own qualification is that resource allocation depends on serving limits, site quality, and inventory, not on which status code triggered the exclusion. The safe takeaway: fix an accidental 204 because it keeps a page from being indexed, not because you’re owed a specific crawl-budget dividend for doing so.

204 vs. the codes it’s confused with

The trap is that 204, empty-200, 404, and 410 can all end up “soft 404” in GSC when there’s no usable content — but they signal very different intents to a spec-compliant client. 410 is the deliberate “this existed and is permanently gone” signal; 204 was never designed for that meaning and shouldn’t sit on page URLs at all.

When 204 is exactly right (not a bug)

Almost every legitimate 204 is a non-document response:

• REST API DELETE / PUT. When a client deletes a resource or updates one in place and there’s nothing meaningful to return, 204 is the idiomatic answer — it’s RFC 9110’s own recommended pattern.
• Analytics and tracking beacons. The W3C Beacon spec built around navigator.sendBeacon() expects beacon endpoints to answer with 204. Google Analytics 4’s Measurement Protocol endpoint returns 204 for hits it accepts. Worth flagging: GA4 returns 204 even for malformed or invalid payloads, so a 204 there confirms only that the endpoint was reachable and structurally responded — not that your hit was actually processed. Don’t read a beacon’s 204 as proof of success.
• “Save without navigating away” UX. A PUT that saves state in place and leaves the user on the current page — MDN’s own framing is that with a 204 “the client doesn’t need to navigate away from its current page.”

The through-line: these aren’t URLs anyone should be indexing, so a 204 is correct and expected. The problem is only a 204 sitting on a document URL that’s supposed to rank.

A related nuance worth flagging: RFC 9110 doesn’t restrict 204 to DELETE/PUT/ beacons specifically — those are just the common patterns. The spec’s definition is method-neutral; what actually matters is the method’s own contract and whether returning a representation would be useful. That cuts both ways. A GET request returning 204 is protocol-legal — practitioners on Stack Overflow have hashed this out for years — the real question for an indexable page isn’t “is 204-on-GET allowed,” it’s “does this URL need to hand Google a representation to be findable,” and for a page you want ranking, the answer is always yes. So the SEO rule isn’t about which HTTP method is in play; it’s about whether the URL is meant to be a document at all.

It’s also worth knowing that “204 is always right for API responses” isn’t universally agreed on even among API designers. Postman’s own writeup lists 204 as the go-to for actions with nothing to return; Brandur Leach has argued the opposite case — that an empty success response can be mildly harmful to API clients that expect a representation back (updated state, a generated ID, a computed field) even after a successful write. That’s a legitimate API-design tradeoff about developer ergonomics, not a matter of HTTP correctness — 204 remains spec-compliant either way — and it’s separate from the SEO question this article is about. One place API writeups sometimes get sloppy: sending Content-Length: 0 on a 204 “to be safe.” Don’t do that — RFC 9110 §8.6 prohibits Content-Length in a 204 response entirely, not just a nonzero one.

Diagnosing and fixing an accidental page-level 204

If a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (Screaming Frog, Ahrefs Site Audit) or your logs show a 204 on a page that should have content:

1. Confirm what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. actually gets. Use URL Inspection in Search Console to see the status and rendered content Google receives — not just what your browser sees. A CDN, edge worker, WAF, or app route can return 204 to bots or under specific conditions while looking fine to you (the same “looks fine in my browser” pattern you get with a stray 403).
2. Then fix by intent:
   • Page should exist with content → find the server/CDN/app logic emitting 204 and restore a proper 200 with the real body.
   • Page is gone with no replacement → return 404 or 410.
   • Page moved → 301 to the new URL.
3. Monitor. Watch the GSC Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. for soft-404 entries, keep an eye on crawl status codes in your logs, and set your crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. to flag 204s so an accidental one on a template doesn’t silently deindex a whole section.

The mental model to keep: 204 is not “bad.” It’s a precise tool that’s correct for API and beacon endpoints and wrong for documents. The failure mode is only ever using it in the wrong place. Siblings like 403, 404, 410, and soft 404 each have their own place in that decision — 204’s place is off the page.

AI summary

A condensed take on the Advanced version:

• 204 No ContentHTTP 204 No Content is a 2xx success status meaning the server fulfilled the request but is intentionally sending back no message body. It's correct for APIs and beacons — but on a page meant to be indexed, Google treats it like a soft 404. is a 2xx success code (RFC 9110 §15.3.5) that returns an empty body by design. It is not an error and says nothing about whether a URL exists. The RFC doesn’t restrict it to a fixed method list — DELETE/PUT/ beacons are common patterns, not a requirement, and 204 on a GET is protocol-legal.
• The body must be empty, with no exceptions. Per MDN, a 204 must not include content or a Content-Length header — and RFC 9110 §8.6 prohibits Content-Length outright, so Content-Length: 0 isn’t actually compliant either. Any headers a 204 does carry describe the selected representation after the action, not a transferred body. A 204 is heuristically cacheable by default, but an ETag is not guaranteed on every 204 — MDN’s example includes one for a specific PUT case, not as a universal rule.
• SEO consequence (narrow, precisely bounded): Google’s status-code doc says plainly that for a 204, “Google wasn’t able to receive any content and therefore can’t process it.” That supports a reasonable inference — a page you want ranking won’t get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. from that response — but Google doesn’t guarantee every 204 gets a specific soft-404 label or a removal timetable, and using 204 doesn’t automatically recover crawl budgetThe number of URLs an engine will crawl in a timeframe. or prove a ranking effect. As Patrick puts it in his own writing: “204s will be treated as soft 404sA soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. and won’t be indexed” — the practical pattern he’s seen, even though the precise official wording is narrower.
• Legitimate uses are mostly non-documents: REST API DELETE/PUT, and analytics beacons (sendBeacon(), GA4 Measurement Protocol). GA4 returns 204 even for malformed hits, so a beacon 204 doesn’t prove the hit was processed. Practitioners don’t fully agree here either — Postman treats 204 as the default for actions with nothing to return, while Brandur Leach argues an empty success can be mildly harmful to clients expecting a representation back; that’s an API-ergonomics debate, not an HTTP-correctness question.
• 204 is never right for a rankable page. Gone with no replacement → 404/ 410; moved → 301; should have content → fix the server/CDN emitting 204 and restore a real 200. Confirm what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. receives with URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version..

Official documentation

Primary-source references for what 204 is and how Google handles it.

HTTP spec & browser reference

• RFC 9110 §15.3.5 — 204 No Content — the authoritative definition: success, no payload body, no trailers, heuristically cacheable, and headers describe the selected representation after the action.
• RFC 9110 §8.6 — Content-Length — the rule that prohibits Content-Length in a 204 response entirely (not just when nonzero).
• MDN — 204 No Content — plain-language framing, the empty-body / Content-Length constraint, cacheability and an example-specific ETag, and the “save without navigating away” use case.

Google Search Central

• How HTTP status codes, and network and DNS errors affect Google Search — the status-code table that calls out 204 by name, and Google’s soft-404 definition.

Beacons & analytics (the legitimate 204 cases)

• W3C — Beacon — the navigator.sendBeacon() spec that expects a 204 from beacon endpoints.
• Google Analytics 4 — Measurement Protocol reference — the GA4 collection endpoint whose responses (including a 204 for accepted hits) are documented here.

Quotes from the source

On-the-record statements. Each link is a deep link that jumps to the quoted passage on the source page.

The HTTP spec

• “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.” — RFC 9110, HTTP Semantics, §15.3.5. Read the section

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.” Jump to quote

Google Search Central — 2xx / 204 handling

• “Google wasn’t able to receive any content and therefore can’t process it.” — Google’s HTTP status codesAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. doc, the 204 row of the 2xx table (contrast the general 2xx rule, where “Google considers the content for processing”). Google’s status-code doc

Patrick Stox — Ahrefs

• “Most 2xxs will allow pages to be indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. However, 204s will be treated as soft 404sA soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. and won’t be indexed.” — from my HTTP Status Codes & Their SEO Impact guide. Jump to quote

Matt G. Southern — Search Engine Journal

• “The exception is a 204 status code, which means the page was successfully accessed but no content was foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.. Google may show a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. for pages serving a 204 code.” Jump to quote

Legitimate 204s vs. accidental ones

Concrete cases for where a 204 belongs — and where it’s a bug.

Correct: REST API DELETE

A client deletes a resource; there’s nothing to return.

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

HTTP/1.1 204 No Content

No body, no Content-Length. This is the idiomatic answer, and it should never be a URL you expect in search.

Correct: analytics beacon (sendBeacon)

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

The endpoint has no page to serve, so 204 is exactly right. Same for GA4’s Measurement Protocol endpoint — just remember GA4 returns 204 even for malformed hits, so a 204 confirms the endpoint responded, not that your hit was processed.

Wrong: a content page returning 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 gets an empty body, treats the URL like a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing., and won’t indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. it. The fix depends on intent:

• Should exist with content → restore 200 OK with the real body (fix the server/CDN/app route emitting 204).
• Gone with no replacement → 404 or 410.
• Moved → 301 to the new URL.

Rule of thumb: if a human is meant to land on the URL and read something, it must return 200 with a body. Reserve 204 for machine-to-machine endpoints — APIs and beacons — where there’s genuinely nothing to show.

Diagnose an unexpected 204

A page is blank and the Network panel shows 204

Symptom: A document URL that should render content returns 204 No Content.

Likely cause: Application routing, a CDN rule, an edge worker, or an error handler is emitting the API-style success response on a page route.

Fix: Trace the request through the layer that owns the response. If the page should exist, restore a 200 with a real body. Confirm the fix with a fresh header request and a browser reload with cache disabled.

Search Console reports a soft 404 for a 204 URL

Symptom: The URL is excluded as a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. even though 204 is a success code.

Likely cause: The classification is about missing content, not whether the code begins with 2. A 204 has no body by definition.

Fix: Choose the response by intent: 200 with content for a real page, 301 for a move, or 404/410 for a gone page. Re-run URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. after deploying the change.

Your browser and crawler disagree about the status

Symptom: The page looks normal in a browser, but a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. or log entry shows 204.

Likely cause: Bot, method, geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO., cache, WAF, or edge logic is varying the response.

Fix: Compare GET and HEAD, normal and GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.-user-agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. requests, and the exact request in server/CDN logs. Fix the conditional rule, then verify both paths return the same intended response.

Classify a set of 204 URLs by intent

Paste a crawl or log export that includes URL, request method, content type, referrer or route type, and response code.

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

Find accidental 204 responses

Inspect one URL and request method

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

The document request should not be 204 if the URL is supposed to render content. Test GET and HEAD because faulty method-specific handlers can disagree.

Compare the default and Googlebot-user-agent response

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"

A 204 with zero downloaded bytes on only one path points to conditional server, CDN, or WAF logic. Use real logs and URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. to confirm what Google actually received.

Report 204s from a URL list

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

Run this in macOS, Linux, or WSL with one URL per line in urls.txt. Review each result by route intent; API and beacon 204s are not errors.

Tools for separating legitimate and accidental 204s

Patrick’s free tool

• Bulk HTTP Status Code Checker — check up to 500 URLs, filter the results to 204, and export the affected set. Use the route and content context to separate valid API/beacon endpoints from page URLs that should return content.

Confirm the cause

• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. — live-test a page URL to see what Google can fetch after you change the response.
• Server/CDN logs — identify whether 204 varies by method, user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target., route, or edge location.
• Browser DevTools Network panel — distinguish the document request from background API and beacon calls; a 204 on a beacon can be correct while a 204 on the document is not.
• A full-site crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. — inventory document URLs returning 204 and keep the check in recurring audits so a template regression does not affect an entire section.

Test yourself: 204 No Content

Five quick questions on what a 204 means and when it’s right. Pick an answer for each, then check.

204 No Content

HTTP 204 No Content is a 2xx success status meaning the server fulfilled the request but is intentionally sending back no message body. It's correct for APIs and beacons — but on a page meant to be indexed, Google treats it like a soft 404.

Related: Soft 404, Not found (404)

204 No Content

HTTP 204 No Content is a success-class (2xx) status code. It means the server successfully fulfilled the request and is deliberately returning no message body — per RFC 9110 §15.3.5, “there is no additional content to send in the response payload body.” The body must be empty; browsers may reject a 204 that ships content or a Content-Length header.

204 is not an error, and it has nothing to do with whether a URL exists. It’s the correct, spec-compliant response for things like a REST API DELETE/PUT that has nothing to return, and for analytics beacons (navigator.sendBeacon(), GA4’s Measurement Protocol).

The SEO catch is narrow but important: Google’s own documentation says a 204 gives it no content it can process, so on a URL meant to be a crawlable, rankable page, that response won’t get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — and in practice these commonly get flagged as soft 404sA soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results., though Google doesn’t guarantee that specific label or a removal timetable. If a page is genuinely gone, use 404 or 410; if it moved, use a 301. Save 204 for API and beacon endpoints, not documents.

Related: Soft 404, Not found (404)

Changelog