Error 418 I'm a Teapot

En resumen: 418 I'm a teapot es el código de estado de broma más querido de la web. Procede del RFC 2324, un RFC del Día de los Inocentes sobre cafeteras, y nunca adquirió semántica de aplicación HTTP ordinaria, pero está reservado, no sin asignar, según el RFC 9110 y el registro de IANA. La orientación de Google de 2023, fechada, lo trata como cualquier otro 4xx distinto de 429: la URL no se indexa. Pruébalo en este sitio: /coffee responde con un 418 auténtico; compruébalo en el panel de red.

De dónde viene el 418

El 1 de abril de 1998, el IETF publicó el RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): un protocolo completamente especificado y enteramente satírico para controlar cafeteras a través de la web. Entre sus aportaciones están el método BREW, la cabecera Accept-Additions (leche, sirope, whisky) y un código de estado inmortal:

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.” (traducción) «Cualquier intento de preparar café con una tetera debería producir el código de error ‘418 I’m a teapot’. El cuerpo de entidad resultante PUEDE ser bajo y rechoncho.»

Ese es todo el chiste: le pediste café a una tetera. No puede prepararlo. Es una tetera.

Dieciséis años después, el RFC 7168 retomó la idea para aparatos que preparan té: otro RFC informativo del Día de los Inocentes, esta vez distinguiendo entre un aparato que está temporalmente sin café y uno que es una tetera de forma permanente. Ninguno de los dos RFC otorga a 418 una semántica de aplicación HTTP ordinaria; ambos describen HTCPCP, un protocolo satírico, no el HTTP básico.

Por qué nunca se convirtió en HTTP real

418 nunca recibió una semántica HTTP ordinaria, pero tampoco está “unassigned” (traducción) «sin asignar». El RFC 9110, la especificación actual de la semántica HTTP, reserva formalmente el código (y cita la frecuencia con que se ha desplegado como broma), y el registro de códigos de estado HTTP de IANA incluye 418 como (Unused), haciendo referencia al RFC 9110; no está disponible para una reutilización ordinaria. Evidencia de esta afirmación 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. Alcance: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Confianza: alta · Verificado: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) En 2017, el grupo de trabajo HTTP del IETF propuso limpiarlo para poder reasignar el código a algo útil. Internet respondió con una campaña “Save 418” (traducción) «Salven al 418», y la reserva se mantuvo; el RFC 9110 también deja abierta la posibilidad de reasignarlo más adelante si las circunstancias lo requieren. Evidencia de esta afirmación The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Alcance: IANA's current registry entry for status code 418. Confianza: alta · Verificado: 2026-07-16 IANA: HTTP Status Code Registry — 418

La reserva no impidió que los implementadores lo adoptaran: net/http de Go y el módulo http de Python exponen una constante 418 con nombre (StatusTeapot, HTTPStatus.IM_A_TEAPOT), y otros frameworks y plataformas han seguido su ejemplo como huevo de Pascua, incluido el google.com/teapot de Google. Evidencia de esta afirmación 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. Alcance: Named constants in two mainstream standard libraries; not evidence of a default response. Confianza: alta · Verificado: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Una constante con nombre no significa que un framework emita 418 de forma predeterminada; significa que reconoce el código, no que este tenga semántica HTTP asignada.

Qué significa un 418 para el SEO

Nada especial; y ese es el dato importante. Una publicación de Search Central de Google, identificada con fecha de febrero de 2023, dice que todas las respuestas 4xx excepto 429 reciben el mismo tratamiento en Search: las URL indexadas anteriormente se eliminan con el tiempo y el contenido de la página no se utiliza. Evidencia de esta afirmación 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. Alcance: Google Search's dated, named statement on 4xx handling (not 418-specific). Confianza: alta · Verificado: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting Es una afirmación general sobre los 4xx, no una regla específica para teteras: la página genérica actual de Google sobre estados de los rastreadores dice explícitamente que no cubre estados exóticos como 418. Evidencia de esta afirmación Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Alcance: Scope note limiting Google's generic HTTP-status guidance to common codes. Confianza: alta · Verificado: 2026-07-16 Google: How HTTP status codes affect Google's crawlers En la práctica, un 418 se comporta como cualquier otro 4xx distinto de 429 respecto a la indexación; no hay una regla de posicionamiento específica para teteras, un plazo de desindexación ni una garantía de recuperación más allá de esa afirmación general.

Aquí deja de ser gracioso: algunas configuraciones de WAF y protección contra bots usan 418 como respuesta de «blocked request» (traducción) «solicitud bloqueada», porque es distintiva y fácil de detectar en los registros. Si una regla así se activa por error con Googlebot, tus páginas reales empezarán a responder con 418 y recibirán exactamente el mismo tratamiento que las páginas que no existen.

Si ves respuestas 418 en los registros del servidor o en informes de rastreo para URL importantes, el código de estado por sí solo no te dice qué capa lo generó: pueden producirlo el código de la aplicación, el valor predeterminado de un framework, una regla WAF o de protección contra bots, una CDN o el servidor de origen, y una respuesta puede atravesar varias de esas capas antes de llegar al cliente. Comprueba la configuración, las cabeceras de respuesta y los registros de la ruta de solicitud en cada capa para encontrar el origen real; después, corrígelo como cualquier otro 4xx no deseado en una URL indexable.

Usa esta secuencia diagnóstica mínima:

Captura el estado sin procesar y las cabeceras de respuesta de la URL afectada.
Compara los registros de la aplicación, el WAF, la CDN y el origen para la misma ruta de solicitud y hora.
Corrige la capa que emite 418 y repite la solicitud sin procesar y la prueba del rastreador.

El 418 de este sitio

Siguiendo el espíritu del RFC, /coffee en este sitio devuelve un 418 real, bajo y rechoncho, directamente desde el edge. Esta página existe para que ese huevo de Pascua tenga una explicación canónica y para que el clúster de http-status-codes cubra el único código de estado que consigue hacer sonreír a la gente.

TL;DR — Trata un 418 inesperado como un 4xx normal distinto de 429 con un emisor poco habitual. Captura la respuesta sin procesar, identifica si procede de la aplicación, el WAF, la CDN o el origen, repite la ruta del rastreador afectado y monitoriza hasta que las URL importantes devuelvan de forma estable el estado previsto.

Interpreta la señal antes de cambiar nada

El código clasifica la respuesta, pero no identifica qué sistema lo eligió. La guía citada de Google sitúa 418 en el comportamiento general de los 4xx distintos de 429: el contenido no se usa para indexar y una URL indexada puede desaparecer con el tiempo. No existe un proceso especial de recuperación por ser un teapot.

Empieza por una URL y conserva hora, ruta, estado, cabeceras y cuerpo. Comprueba si el resultado es estable o depende del user-agent, IP, autenticación, frecuencia o ubicación.

Aísla la capa emisora

Trabaja desde la respuesta pública hacia dentro:

Reproduce la respuesta con una petición directa y registra cabeceras y cuerpo.
Cruza ruta y hora en los registros de CDN, WAF, origen, framework y aplicación.
Compara navegador y rastreador; el texto visible de error no demuestra qué capa respondió.
Cambia solo la regla o código demostrado; una constante con nombre no significa que el framework emita 418 por defecto.

Verifica la recuperación

Repite la URL por la misma ruta que falló. Debe devolver el estado que realmente necesita el recurso, normalmente 200 para una página viva e indexable. Muestrea también URL vecinas sujetas a la misma regla.

Crea una alerta para nuevos 418 en URL indexables. /coffee debe seguir siendo el control intencional con 418; las páginas de producción no deben heredarlo.

Herramientas para encontrar un 418 inesperado

Bulk HTTP Status Code Checker: analiza un conjunto de URL para encontrar respuestas 418 y distingue el huevo de Pascua intencional de las páginas reales bloqueadas por un WAF o una regla de protección contra bots.
HTTP Header Checker: inspecciona las cabeceras de la CDN y de seguridad en busca de pistas sobre qué capa generó la respuesta.
Panel Network de las DevTools del navegador: comprueba el estado sin procesar de la solicitud en lugar de confiar en el texto visible de la página de error.
curl: ejecuta curl -i https://example.com/path para capturar el estado, las cabeceras y cualquier cuerpo de respuesta sin una sesión de navegador iniciada.
Eventos de seguridad de la CDN o el WAF: si aparece 418 en una página que debería ser indexable, relaciona la hora y la URL de la solicitud con la regla que se activó antes de cambiarla.

418 I'm a teapot se origina en el RFC 2324 (HTCPCP), un RFC del Día de los Inocentes de 1998; indica que se pidió a una tetera que preparara café. El RFC 7168 lo retomó en 2014 para aparatos que preparan té.
No está “unassigned” (traducción) «sin asignar»: el RFC 9110 reserva formalmente 418 y el registro de IANA lo incluye como (Unused), un estado que internet defendió, no uno que nadie reclamó. Un intento de recuperar el código en 2017 se abandonó después de la campaña «Save 418».
Go y Python exponen una constante 418 con nombre; otros frameworks y plataformas lo implementan como huevo de Pascua (Google tiene su propio google.com/teapot), pero una constante no significa que un framework emita 418 de forma predeterminada.
Impacto en SEO: una publicación de Google Search Central de febrero de 2023 trata todos los 4xx distintos de 429 por igual en Search: una URL que responde con 418 no se indexa, igual que una 404; la página genérica actual de Google sobre estados de los rastreadores no cubre los códigos exóticos como 418.
Riesgo práctico: un 418 inesperado puede proceder de la aplicación, el valor predeterminado de un framework, una regla WAF o de protección contra bots, una CDN o el origen; comprueba las cabeceras y los registros de cada capa para encontrar el origen antes de corregirlo como cualquier otro 4xx.
Este sitio devuelve un 418 auténtico en /coffee.