418: Ich bin eine Teekanne

TL;DR – 418 I'm a teapot ist der beliebteste scherzhafte Statuscode des Webs. Er stammt aus RFC 2324, einem Aprilscherz-RFC über Kaffeekannen, und erhielt nie eine gewöhnliche HTTP-Anwendungssemantik – ist nach RFC 9110 und dem IANA-Register aber ausdrücklich reserviert und nicht etwa unzugewiesen. Googles datierte Leitlinie von 2023 behandelt ihn wie jeden anderen 4xx-Code außer 429: Die URL wird nicht indexiert. Teste ihn auf dieser Website: /coffee antwortet mit einer echten 418 – prüfe den Netzwerk-Tab.

Woher 418 kommt

Am 1. April 1998 veröffentlichte die IETF RFC 2324: das Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) – ein vollständig spezifiziertes, völlig satirisches Protokoll zur Steuerung von Kaffeekannen über das Web. Dazu gehörten die Methode BREW, der Header Accept-Additions (Milch, Sirup, Whisky) und ein unsterblicher Statuscode:

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.” (Übersetzung) „Jeder Versuch, mit einer Teekanne Kaffee zu brühen, sollte zum Fehlercode ‚418 I’m a teapot‘ führen. Der resultierende Entity-Body DARF kurz und kräftig sein.“

Der ganze Witz besteht darin, dass du eine Teekanne um Kaffee bittest. Das geht nicht – sie ist eine Teekanne.

Sechzehn Jahre später griff RFC 7168 die Idee für Teebrühgeräte wieder auf – ein weiterer informativer Aprilscherz-RFC, der diesmal ein Gerät, dem vorübergehend der Kaffee ausgegangen ist, von einer dauerhaft als Teekanne ungeeigneten Maschine unterscheidet. Keiner der beiden RFCs verleiht 418 eine gewöhnliche HTTP-Anwendungssemantik; beide beschreiben HTCPCP, ein satirisches Protokoll, nicht das HTTP-Kernprotokoll.

Warum 418 nie zu echtem HTTP wurde

418 erhielt nie eine gewöhnliche HTTP-Semantik – ist aber auch nicht „unassigned“. RFC 9110, die aktuelle Spezifikation der HTTP-Semantik, reserviert den Code ausdrücklich (und verweist darauf, wie häufig er als Scherz eingesetzt wurde). Das IANA-Register für HTTP-Statuscodes führt 418 als (Unused) und verweist auf RFC 9110 – für eine gewöhnliche Wiederverwendung steht er nicht zur Verfügung. 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) 2017 schlug die HTTP-Arbeitsgruppe der IETF vor, den Code zu bereinigen, damit er einer nützlichen Bedeutung zugewiesen werden könnte. Das Internet antwortete mit einer „Save 418“-Kampagne (Übersetzung) „Rettet 418“, und die Reservierung blieb bestehen – RFC 9110 lässt eine spätere Neuzuweisung offen, falls die Umstände das erfordern sollten. 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

Die Reservierung hielt Implementierer nicht auf: Gos net/http und Pythons Modul http stellen beide eine benannte 418-Konstante (StatusTeapot, HTTPStatus.IM_A_TEAPOT) bereit, und weitere Frameworks und Plattformen haben sie als Easter Egg übernommen – darunter Googles eigene google.com/teapot. 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 Eine benannte Konstante bedeutet nicht, dass ein Framework 418 standardmäßig ausgibt; sie bedeutet nur, dass der Code erkannt wird, nicht dass ihm eine zugewiesene HTTP-Semantik zukommt.

Was 418 für SEO bedeutet

Nichts Besonderes – und genau das ist der wichtige Punkt. Ein benannter Beitrag von Google Search Central vom Februar 2023 sagt, dass alle 4xx-Antworten außer 429 in der Suche gleich behandelt werden: Zuvor indexierte URLs werden mit der Zeit entfernt, und der Seiteninhalt wird nicht verwendet. 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 Das ist eine allgemeine 4xx-Aussage, keine teekannenspezifische Regel – Googles aktuelle generische Crawler-Statusseite sagt ausdrücklich, dass exotische Statuscodes wie 418 nicht von ihrer Tabelle abgedeckt werden. 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 der Praxis verhält sich 418 bei der Indexierung wie jeder andere 4xx-Code außer 429; es gibt keine eigene Rankingregel, keinen besonderen Zeitplan für die Entfernung aus dem Index und keine darüber hinausgehende Garantie für die Wiederherstellung.

Lustig ist es nur so lange, bis eine WAF- oder Bot-Schutz-Konfiguration 418 als Antwort für blockierte Anfragen verwendet – weil der Code auffällig und in Logs leicht zu erkennen ist. Wenn eine solche Regel Googlebot fälschlich trifft, antworten deine echten Seiten plötzlich mit 418 – und werden genau wie nicht vorhandene Seiten behandelt.

Wenn du 418 in Server-Logs oder Crawl-Berichten für wichtige URLs siehst, sagt der Statuscode allein nicht, welche Ebene ihn erzeugt hat. Anwendungscode, ein Framework-Standard, eine WAF- oder Bot-Schutzregel, ein CDN oder der Origin-Server können ihn jeweils ausgeben, und eine Antwort kann auf dem Weg zum Client mehrere dieser Ebenen durchlaufen. Prüfe Konfiguration, Response-Header und Request-Pfad-Logs auf jeder Ebene, um die tatsächliche Quelle zu finden, und behebe sie wie jeden anderen unerwünschten 4xx-Code auf einer indexierbaren URL.

Verwende diese minimale Diagnosesequenz:

1. Erfasse den unveränderten Status und die Response-Header der betroffenen URL.
2. Vergleiche für denselben Request-Pfad und Zeitpunkt die Logs von Anwendung, WAF, CDN und Origin.
3. Korrigiere die Ebene, die 418 ausgibt, und wiederhole anschließend den unveränderten Request und den Crawler-Test.

Die 418 auf dieser Website

Im Geist des RFC gibt /coffee auf dieser Website eine echte 418 zurück – kurz und kräftig, direkt vom Edge. Diese Seite erklärt das Easter Egg kanonisch und sorgt dafür, dass der Cluster für HTTP-Statuscodes auch den Statuscode abdeckt, über den sich Menschen tatsächlich freuen.

Werkzeuge zum Finden einer unerwarteten 418

• Bulk HTTP Status Code Checker: Scanne eine URL-Menge auf 418-Antworten und unterscheide das beabsichtigte Easter Egg von echten Seiten, die durch eine WAF- oder Bot-Schutzregel blockiert werden.
• HTTP Header Checker: Untersuche CDN- und Sicherheitsheader auf Hinweise darauf, welche Ebene die Antwort erzeugt hat.
• Netzwerk-Panel der Browser-DevTools: Prüfe den unveränderten Status des Requests, statt dich auf den sichtbaren Text der Fehlerseite zu verlassen.
• curl: Führe curl -i https://example.com/path aus, um Status, Header und möglichen Response-Body ohne eine eingeloggte Browsersitzung zu erfassen.
• Sicherheitsereignisse von CDN/WAF: Wenn 418 auf einer indexierbaren Seite erscheint, gleiche Zeitpunkt und URL des Requests mit der ausgelösten Regel ab, bevor du sie änderst.

• 418 I'm a teapot stammt aus RFC 2324 (HTCPCP), einem Aprilscherz-RFC von 1998; er signalisiert, dass eine Teekanne aufgefordert wurde, Kaffee zu brühen. RFC 7168 griff die Idee 2014 für Teebrühgeräte wieder auf.
• Der Code ist nicht „unassigned“: RFC 9110 reserviert 418 ausdrücklich, und das IANA-Register führt ihn als (Unused) – ein Status, dessen Erhalt das Internet erkämpfte, nicht einer, den niemand beansprucht hätte. Ein Versuch von 2017, den Code zurückzugewinnen, wurde nach der „Save 418“-Kampagne aufgegeben.
• Go und Python stellen beide eine benannte 418-Konstante bereit; andere Frameworks und Plattformen setzen sie als Easter Egg um (Google hat mit google.com/teapot ein eigenes) – eine Konstante bedeutet aber nicht, dass ein Framework 418 standardmäßig ausgibt.
• SEO-Auswirkung: Ein benannter Google-Search-Central-Beitrag vom Februar 2023 behandelt jeden 4xx-Code außer 429 in der Suche gleich – eine URL mit 418 wird nicht indexiert, ebenso wie eine mit 404; Googles aktuelle generische Crawler-Statusseite deckt exotische Codes wie 418 überhaupt nicht ab.
• Praktisches Risiko: Eine unerwartete 418 kann aus der Anwendung, einem Framework-Standard, einer WAF-/Bot-Schutzregel, einem CDN oder dem Origin stammen. Prüfe Header und Logs auf jeder Ebene, um die Quelle zu finden, bevor du sie wie jeden anderen 4xx-Code behebst.
• Diese Website liefert unter /coffee eine echte 418 aus.

Änderungsprotokoll