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. Nachweis für diese Aussage 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. Geltungsbereich: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Vertrauensniveau: hoch · Verifiziert: 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. Nachweis für diese Aussage The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Geltungsbereich: IANA's current registry entry for status code 418. Vertrauensniveau: hoch · Verifiziert: 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. Nachweis für diese Aussage 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. Geltungsbereich: Named constants in two mainstream standard libraries; not evidence of a default response. Vertrauensniveau: hoch · Verifiziert: 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. Nachweis für diese Aussage 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. Geltungsbereich: Google Search's dated, named statement on 4xx handling (not 418-specific). Vertrauensniveau: hoch · Verifiziert: 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. Nachweis für diese Aussage Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Geltungsbereich: Scope note limiting Google's generic HTTP-status guidance to common codes. Vertrauensniveau: hoch · Verifiziert: 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.

Kurzfassung — Behandle ein unerwartetes 418 wie einen gewöhnlichen Nicht-429-4xx mit einem ungewöhnlichen Auslöser. Erfasse die Rohantwort, bestimme die ausgebende Anwendungs-, WAF-, CDN- oder Origin-Schicht und prüfe denselben Crawler-Pfad bis wichtige URLs wieder zuverlässig den vorgesehenen Status liefern.

Das Signal vor jeder Änderung einordnen

Der Code klassifiziert die Antwort, nennt aber nicht das System, das ihn gewählt hat. Googles zitierte Hinweise behandeln 418 wie andere Nicht-429-4xx: Der Inhalt wird nicht indexiert und eine bereits indexierte URL kann mit der Zeit entfernt werden. Einen besonderen Teapot-Wiederherstellungsweg gibt es nicht.

Beginne mit einer URL und sichere Zeitpunkt, Pfad, Status, Header und Body. Prüfe, ob das Ergebnis stabil ist oder von User-Agent, IP, Anmeldung, Rate oder Standort abhängt.

Die ausgebende Schicht isolieren

Arbeite von außen nach innen:

1. Reproduziere die Antwort mit einer Rohabfrage und protokolliere Header und Body.
2. Ordne Pfad und Zeitpunkt den CDN-, WAF-, Origin-, Framework- und Anwendungslogs zu.
3. Vergleiche Browser- und Crawler-Anfrage; der Text der Fehlerseite beweist den Auslöser nicht.
4. Ändere nur die nachgewiesene Regel oder Code-Stelle; eine benannte Framework-Konstante bedeutet nicht, dass das Framework standardmäßig 418 sendet.

Die Wiederherstellung verifizieren

Teste dieselbe URL über den zuvor fehlgeschlagenen Pfad. Erwartet wird der tatsächlich vorgesehene Status, meist 200 für eine indexierbare Live-Seite. Prüfe außerdem benachbarte URLs unter derselben Regel.

Überwache neue 418 auf indexierbaren URLs. /coffee bleibt die beabsichtigte 418-Kontrolle; Produktionsseiten dürfen dieses Verhalten nicht übernehmen.

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