418 Sou um bule

TL;DR — 418 I'm a teapot é o código de status engraçado mais querido da web. Ele vem da RFC 2324, uma RFC de primeiro de abril sobre bules de café, e nunca recebeu semântica comum de aplicação HTTP — mas é formalmente reservado, e não está sem atribuição, segundo a RFC 9110 e o registro da IANA. A orientação do Google, publicada em 2023 e hoje datada, trata-o como qualquer outro 4xx diferente de 429: a URL não é indexada. Experimente neste site: /coffee responde com um 418 real — confira a aba de rede.

De onde vem o 418

Em 1º de abril de 1998, a IETF publicou a RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — um protocolo totalmente especificado e inteiramente satírico para controlar bules de café pela web. Entre suas contribuições estão o método BREW, o cabeçalho Accept-Additions (leite, xarope, uísque) e um código de status imortal:

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.” (tradução) «Qualquer tentativa de preparar café com um bule deve resultar no código de erro “418 Sou um bule”. O corpo da entidade resultante pode ser curto e encorpado.»

Essa é toda a piada: você pediu café a um bule. Ele não pode fazer isso. É um bule.

Dezesseis anos depois, a RFC 7168 revisitou a ideia para aparelhos que preparam chá — outra RFC Informativa de primeiro de abril, desta vez distinguindo um aparelho que está temporariamente sem café de um que é um bule, permanentemente. Nenhuma das duas RFCs dá semântica comum de aplicação HTTP ao 418; ambas descrevem o HTCPCP, um protocolo satírico, não o HTTP principal.

Por que ele nunca virou HTTP de verdade

O 418 nunca recebeu semântica comum de HTTP — mas também não é “não atribuído”. A RFC 9110, a especificação atual de Semântica HTTP, reserva formalmente o código (observando com que frequência ele foi implantado como piada), e o IANA HTTP Status Code Registry lista o 418 como (Unused), fazendo referência à RFC 9110 — não disponível para reutilização comum. Evidência desta afirmação 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. Escopo: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Confiança: alta · Verificado: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) Em 2017, o grupo de trabalho de HTTP da IETF propôs eliminá-lo para que o código pudesse ser reatribuído a algo útil. A internet respondeu com uma campanha “Save 418”, e a reserva permaneceu — a RFC 9110 também deixa aberta a possibilidade de reatribuí-lo mais tarde, se as circunstâncias exigirem. Evidência desta afirmação The IANA HTTP Status Code Registry lists 418 as "(Unused)" and references RFC 9110; it is not an unassigned number available for ordinary reuse. Escopo: IANA's current registry entry for status code 418. Confiança: alta · Verificado: 2026-07-16 IANA: HTTP Status Code Registry — 418

Isso não impediu os implementadores: o módulo net/http do Go e o módulo http do Python expõem uma constante nomeada de 418 (StatusTeapot, HTTPStatus.IM_A_TEAPOT), e outros frameworks e plataformas fizeram o mesmo como easter egg — inclusive o google.com/teapot do Google. Evidência desta afirmação 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. Escopo: Named constants in two mainstream standard libraries; not evidence of a default response. Confiança: alta · Verificado: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Uma constante nomeada não significa que um framework emita 418 por padrão; significa que o código é reconhecido, não que tenha semântica HTTP atribuída.

O que um 418 significa para SEO

Nada de especial — e esse é o ponto importante. O Google não interpreta a piada; uma publicação identificada do Search Central de fevereiro de 2023 diz que todas as respostas 4xx, exceto 429, recebem o mesmo tratamento na Busca: URLs antes indexadas são removidas com o tempo, e o conteúdo da página não é usado. Evidência desta afirmação 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. Escopo: Google Search's dated, named statement on 4xx handling (not 418-specific). Confiança: alta · Verificado: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting Essa é uma declaração geral sobre 4xx, não uma regra específica para bules — a página genérica atual do Google sobre status de rastreadores diz explicitamente que status exóticos como 418 não estão cobertos pela tabela. Evidência desta afirmação Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Escopo: Scope note limiting Google's generic HTTP-status guidance to common codes. Confiança: alta · Verificado: 2026-07-16 Google: How HTTP status codes affect Google's crawlers Na prática, um 418 se comporta como outro 4xx diferente de 429 para fins de indexação; não há regra de ranqueamento específica para bules, prazo de desindexação ou garantia de recuperação além dessa declaração geral.

É aqui que a graça acaba: algumas configurações de WAF e proteção contra bots usam 418 como resposta para uma “solicitação bloqueada”, sob a teoria de que ele é distinto e fácil de encontrar nos logs. Se essa regra disparar por engano para o Googlebot, suas páginas reais começarão a responder 418 — e serão tratadas exatamente como páginas que não existem.

Se você vir 418s nos logs do servidor ou nos relatórios de rastreamento em URLs importantes, o código de status, sozinho, não diz qual camada o gerou — código da aplicação, padrão de um framework, regra de WAF ou de proteção contra bots, CDN ou servidor de origem podem produzi-lo, e uma resposta pode passar por várias dessas camadas a caminho do cliente. Verifique a configuração, os cabeçalhos de resposta e os logs do caminho da solicitação em cada camada para encontrar a origem real; depois corrija-o como qualquer outro 4xx indesejado em uma URL indexável.

Use esta sequência diagnóstica mínima:

1. Capture o status bruto e os cabeçalhos de resposta da URL afetada.
2. Compare os logs da aplicação, do WAF, da CDN e da origem para o mesmo caminho de solicitação e horário.
3. Corrija a camada que está emitindo 418 e repita a solicitação bruta e o teste do rastreador.

O 418 deste site

No espírito da RFC, /coffee neste site retorna um 418 real, curto e encorpado, diretamente da borda. Esta página existe para que esse easter egg tenha uma explicação canônica — e para que o cluster de códigos de status HTTP cubra o único código de status que realmente faz as pessoas sorrirem.

TL;DR — Trate um 418 inesperado como um 4xx comum diferente de 429, emitido por uma camada incomum. Preserve a resposta bruta, identifique se veio da aplicação, WAF, CDN ou origem e repita o caminho do crawler até as URLs importantes voltarem ao estado pretendido.

Interprete o sinal antes de alterar

O código classifica a resposta, mas não identifica o sistema que o escolheu. A orientação citada do Google trata 418 como os demais 4xx diferentes de 429: o conteúdo não é usado para indexação e uma URL já indexada pode ser removida com o tempo; não há recuperação especial por ser um teapot.

Comece com uma URL e preserve horário, caminho, status, cabeçalhos e corpo. Verifique se o resultado depende de user-agent, IP, autenticação, frequência ou localização.

Isole a camada emissora

Trabalhe da resposta pública para dentro:

1. Reproduza com uma requisição bruta e registre cabeçalhos e corpo.
2. Correlacione caminho e horário nos logs de CDN, WAF, origem, framework e aplicação.
3. Compare navegador e crawler; o texto da página de erro não comprova a origem.
4. Altere somente a regra ou o código comprovado; uma constante nomeada não significa que o framework envie 418 por padrão.

Verifique a recuperação

Teste novamente a mesma URL pelo caminho que falhou. Ela deve retornar o estado realmente necessário, normalmente 200 para uma página ativa e indexável. Verifique também URLs vizinhas sujeitas à mesma regra.

Monitore novos 418 em URLs indexáveis. /coffee deve permanecer como controle 418 intencional; páginas de produção não podem herdar esse comportamento.

Ferramentas para encontrar um 418 inesperado

• Bulk HTTP Status Code Checker: examine um conjunto de URLs em busca de respostas 418 e diferencie o easter egg intencional de páginas reais bloqueadas por uma regra de WAF ou proteção contra bots.
• HTTP Header Checker: inspecione os cabeçalhos de CDN e de segurança em busca de pistas sobre qual camada gerou a resposta.
• Painel Network das DevTools do navegador: verifique o status bruto da solicitação em vez de confiar no texto visível da página de erro.
• curl: execute curl -i https://example.com/path para capturar o status, os cabeçalhos e qualquer corpo de resposta sem uma sessão de navegador autenticada.
• Eventos de segurança da CDN/WAF: se 418 aparecer em uma página que deveria ser indexável, correlacione o horário da solicitação e a URL com a regra que disparou antes de alterá-la.

• 418 I'm a teapot tem origem na RFC 2324 (HTCPCP), uma RFC de primeiro de abril de 1998; ele indica que pediram a um bule que preparasse café. A RFC 7168 o revisitou em 2014 para aparelhos que preparam chá.
• Ele não é “não atribuído”: a RFC 9110 reserva formalmente o 418, e o registro da IANA o lista como (Unused) — um status que a internet lutou para manter, não um que ninguém reivindicou. Uma tentativa de reaver o código em 2017 foi abandonada após a campanha “Save 418”.
• Go e Python expõem uma constante nomeada de 418; outros frameworks e plataformas o implementam como easter egg (o Google tem o seu em google.com/teapot) — mas uma constante não significa que um framework emita 418 por padrão.
• Impacto em SEO: uma publicação identificada do Google Search Central de fevereiro de 2023 trata todos os 4xx diferentes de 429 da mesma forma na Busca — uma URL que responde 418 não é indexada, assim como uma 404; a página genérica atual do Google sobre status de rastreadores nem sequer cobre códigos exóticos como 418.
• Risco prático: um 418 inesperado pode vir da aplicação, do padrão de um framework, de uma regra de WAF/proteção contra bots, de uma CDN ou da origem — verifique cabeçalhos e logs em cada camada para encontrar a origem antes de corrigi-lo como qualquer outro 4xx.
• Este site retorna um 418 genuíno em /coffee.

Registro de alterações