418 I'm a Teapot

TL;DR — 418 I'm a teapot is the web’s best-loved joke status code. It comes from RFC 2324, an April Fools’ RFC about coffee pots, and never got ordinary HTTP application semantics — but it’s formally reserved, not unassigned, per RFC 9110 and IANA’s registry. Google’s dated 2023 guidance treats it like any other non-429 4xx: the URL doesn’t get indexed. Try it on this site: /coffee answers with a real 418 — check the network tab.

Where 418 comes from

On April 1, 1998, the IETF published RFC 2324: the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — a fully specified, entirely satirical protocol for controlling coffee pots over the web. Among its contributions: the BREW method, the Accept-Additions header (milk, syrup, whisky), and one immortal status code:

418 I’m a teapot — “Any attempt to brew coffee with a teapot should result in the error code ‘418 I’m a teapot’. The resulting entity body MAY be short and stout.”

That’s the whole joke: you asked a teapot for coffee. It can’t. It’s a teapot.

Sixteen years later, RFC 7168 revisited the idea for tea-brewing appliances — another Informational, April Fools’ RFC, this one distinguishing an appliance that’s temporarily out of coffee from one that’s a teapot, permanently. Neither RFC gives 418 ordinary HTTP application semantics; both describe HTCPCP, a satirical protocol, not core HTTP.

Why it never became real HTTP

418 was never assigned ordinary HTTP semantics — but it’s not “unassigned” either. RFC 9110, the current HTTP Semantics specification, formally reserves the code (citing how often it’s been deployed as a joke), and the IANA HTTP Status Code Registry lists 418 as (Unused), referencing RFC 9110 — not available for ordinary reuse. Evidence for this claim RFC 9110 reserves status code 418, citing how often it has been deployed as a joke, and leaves open the possibility of assigning it a different meaning in the future if circumstances require it. Scope: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Confidence: high · Verified: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) In 2017 the IETF’s HTTP working group proposed cleaning it up so the code could be reassigned to something useful. The internet responded with a “Save 418” campaign, and the reservation held — RFC 9110 also leaves the door open to reassigning it later if circumstances ever require it. Evidence for this claim The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Scope: IANA's current registry entry for status code 418. Confidence: high · Verified: 2026-07-16 IANA: HTTP Status Code Registry — 418

That reservation didn’t stop implementers: Go’s net/http and Python’s http module both expose a named 418 constant (StatusTeapot, HTTPStatus.IM_A_TEAPOT), and other frameworks and platforms have followed suit as an easter egg — Google’s own google.com/teapot among them. Evidence for this claim Go's net/http and Python's http module both expose a named 418 status constant, showing implementation recognition without requiring servers to emit 418. Scope: Named constants in two mainstream standard libraries; not evidence of a default response. Confidence: high · Verified: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT A named constant doesn’t mean a framework emits 418 by default; it means the code is recognized, not that it carries assigned HTTP semantics.

What a 418 means for SEO

Nothing special — and that’s the point worth knowing. Google doesn’t parse the joke; a named February 2023 Search Central post says all 4xx responses except 429 get the same treatment in Search: previously indexed URLs get removed over time and the page’s content isn’t used. Evidence for this claim Google's Search Central blog states that all 4xx responses except 429 receive the same treatment for Search: content isn't used and previously indexed URLs are removed over time. Scope: Google Search's dated, named statement on 4xx handling (not 418-specific). Confidence: high · Verified: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting That’s a general 4xx statement, not a teapot-specific rule — Google’s current generic crawler-status page explicitly says exotic statuses like 418 aren’t covered by its table. Evidence for this claim Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Scope: Scope note limiting Google's generic HTTP-status guidance to common codes. Confidence: high · Verified: 2026-07-16 Google: How HTTP status codes affect Google's crawlers In practice, a 418 behaves like another non-429 4xx as far as indexing goes; there’s no teapot-specific ranking rule, deindexing timeline, or recovery guarantee beyond that general statement.

Where this stops being funny: some WAF and bot-protection configurations use 418 as their “blocked request” response, on the theory that it’s distinctive and easy to spot in logs. If such a rule misfires on Googlebot, your real pages start answering 418 — and they’ll be treated exactly like pages that don’t exist.

If you see 418s in server logs or crawl reports on URLs that matter, the status code alone doesn’t tell you which layer generated it — application code, a framework default, a WAF or bot-protection rule, a CDN, or the origin server can all produce it, and a response can pass through several of those on its way to the client. Check configuration, response headers, and request-path logs at each layer to find the actual source, then fix it like any other unwanted 4xx on an indexable URL.

Use this minimum diagnostic sequence:

1. Capture the affected URL’s raw status and response headers.
2. Compare application, WAF, CDN, and origin logs for the same request path and time.
3. Correct the layer emitting 418, then repeat the raw request and crawler test.

The one on this site

In the spirit of the RFC, /coffee on this site returns an actual 418, short and stout, straight from the edge. This page exists so that easter egg has a canonical explanation — and so the http-status-codes cluster covers the one status code people actually smile about.

TL;DR — Treat an unexpected 418 as an ordinary non-429 4xx with an unusual producer. Capture the raw response, identify which application, WAF, CDN, or origin layer emitted it, verify the result with the affected crawler path, and keep monitoring until important URLs consistently return their intended status.

Interpret the signal before changing anything

The status code tells you how the response is classified, not which system chose it. Google’s cited guidance places 418 in the general non-429 4xx behavior: the content is not used for indexing, and a previously indexed URL can be removed over time. It does not define a special teapot recovery process or timeline.

Start with one affected URL and preserve the evidence you will need to compare layers: request time, request path, response status, response headers, and body. Confirm whether the response is stable or depends on user agent, IP, authentication, rate, geography, or another request condition.

Isolate the emitting layer

Work from the public response inward:

1. Reproduce the response with a raw request and record its headers and body.
2. Match the same path and time in CDN, WAF or bot-protection, origin, framework, and application logs.
3. Compare a normal browser request with the affected crawler request without assuming that the visible error-page text identifies the producer.
4. Change only the rule or code path proven to emit 418; a named framework constant is not evidence that the framework sends it by default.

Verify the recovery

Retest the exact URL through the same request path that failed. The expected result is the status the resource actually requires—usually 200 for a live indexable page, or the intentional redirect or removal status for another lifecycle state. Then sample neighboring URLs governed by the same rule so a narrow fix does not leave a pattern-wide block in place.

Keep a log or crawl alert for new 418 responses on indexable URLs. The site’s intentional /coffee response is a useful control: it should remain 418, while production pages should not inherit that behavior.

Tools for finding an unexpected 418

• Bulk HTTP Status Code Checker: scan a URL set for 418 responses and distinguish the intended easter egg from real pages being blocked by a WAF or bot-protection rule.
• HTTP Header Checker: inspect CDN and security headers for clues about which layer generated the response.
• Browser DevTools Network panel: verify the raw status on the request instead of relying on the visible error-page text.
• curl: run curl -i https://example.com/path to capture the status, headers, and any response body without a logged-in browser session.
• CDN/WAF security events: if 418 appears on a page that should be indexable, correlate the request time and URL with the rule that fired before changing it.

• 418 I'm a teapot originates in RFC 2324 (HTCPCP), an April Fools’ RFC from 1998; it signals that a teapot was asked to brew coffee. RFC 7168 revisited it in 2014 for tea-brewing appliances.
• It’s not “unassigned”: RFC 9110 formally reserves 418, and IANA’s registry lists it as (Unused) — a status the internet fought to keep, not one nobody claimed. A 2017 effort to reclaim the code was abandoned after the “Save 418” campaign.
• Go and Python both expose a named 418 constant; other frameworks and platforms implement it as an easter egg (Google has its own at google.com/teapot) — but a constant doesn’t mean a framework emits 418 by default.
• SEO impact: a named February 2023 Google Search Central post treats every non-429 4xx the same in Search — a URL answering 418 isn’t indexed, same as a 404; Google’s current generic crawler-status page doesn’t cover exotic codes like 418 at all.
• Practical risk: an unexpected 418 could come from the app, a framework default, a WAF/bot-protection rule, a CDN, or the origin — check headers and logs at each layer to find the source before fixing it like any other 4xx.
• This site returns a genuine 418 at /coffee.

418 I'm a teapot

A joke HTTP status code from the 1998 April Fools' HTCPCP RFC, meaning a teapot was asked to brew coffee — reserved (not unassigned) by RFC 9110 and listed (Unused) in IANA's registry, widely implemented as an easter egg, and treated by Google like any other non-429 4xx client error.

Related: 404 Not Found, 410 Gone

418 I'm a teapot

HTTP 418 I’m a teapot comes from RFC 2324 — the Hyper Text Coffee Pot Control Protocol (HTCPCP), an April Fools’ RFC published on April 1, 1998. Per the spec, a teapot that receives a request to brew coffee “may return” 418 I'm a teapot, because it is, permanently and definitionally, a teapot.

It never got ordinary HTTP application semantics — but it’s not “unassigned” either. RFC 9110, the current HTTP Semantics spec, formally reserves 418 (citing how often it’s been deployed as a joke), and the IANA HTTP Status Code Registry lists it as (Unused), referencing RFC 9110. A 2017 IETF proposal to reclaim the code triggered a “save 418” campaign and the reservation held — RFC 9110 also leaves the door open to reassigning it later if circumstances require it. Go’s net/http and Python’s http module both expose a named 418 constant; other frameworks and platforms implement it as an easter egg.

For SEO, the treatment is boring in the best way: a named February 2023 Google Search Central post says every 4xx except 429 gets the same treatment in Search, so a URL answering 418 won’t be indexed — same practical effect as a 404 — though Google’s current generic crawler-status page doesn’t cover exotic codes like 418 in its table at all. If a page you care about is somehow returning 418, the status code alone won’t tell you which layer produced it (app, framework, WAF, CDN, or origin); check configuration, headers, and logs to find the source, then fix it like any other 4xx on an indexable URL. Try it live on this site: /coffee answers with a genuine 418.

Related: 404 Not Found, 410 Gone

Changelog