418 Saya Teko

TL;DR — 418 I'm a teapot adalah kode status lelucon yang paling disukai di web. Kode ini berasal dari RFC 2324, RFC April Mop tentang teko kopi, dan tidak pernah memiliki semantik aplikasi HTTP biasa — tetapi secara resmi reserved, bukan unassigned, menurut RFC 9110 dan registri IANA. Panduan Google tahun 2023 yang bertanggal memperlakukannya seperti 4xx non-429 lainnya: URL tersebut tidak diindeks. Coba di situs ini: /coffee menjawab dengan 418 sungguhan — periksa tab jaringan.

Dari mana 418 berasal

Pada 1 April 1998, IETF menerbitkan RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) — protokol satir yang sepenuhnya ditentukan untuk mengendalikan teko kopi melalui web. Kontribusinya antara lain metode BREW, header Accept-Additions (susu, sirop, wiski), dan satu kode status yang abadi:

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.” (terjemahan) “Setiap upaya menyeduh kopi dengan teko harus menghasilkan kode galat ‘418 I’m a teapot’. Isi entitas yang dihasilkan BOLEH pendek dan kekar.”

Itulah seluruh leluconnya: Anda meminta teko membuat kopi. Teko tidak bisa. Ia adalah teko.

Enam belas tahun kemudian, RFC 7168 meninjau kembali gagasan perangkat penyeduh teh — RFC Informasional April Mop lainnya, yang membedakan perangkat yang kehabisan kopi untuk sementara dari perangkat yang memang teko. Tidak satu pun RFC memberikan semantik aplikasi HTTP biasa kepada 418; keduanya mendeskripsikan HTCPCP, protokol satir, bukan HTTP inti.

Mengapa kode ini tidak pernah menjadi HTTP sungguhan

418 tidak pernah diberi semantik HTTP biasa — tetapi juga bukan “unassigned” (terjemahan) “tidak ditetapkan”. RFC 9110, spesifikasi Semantik HTTP saat ini, secara resmi mencadangkan kode tersebut (dengan menyebut bahwa kode ini sering dipakai sebagai lelucon), dan IANA HTTP Status Code Registry mencantumkan 418 sebagai (Unused), dengan rujukan ke RFC 9110 — tidak tersedia untuk penggunaan ulang biasa. Bukti untuk klaim ini 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. Cakupan: Current HTTP Semantics reservation; RFC 9110 does not make 418 a normal production status, but does not permanently foreclose future reassignment. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-16 IETF: RFC 9110 §15.5.19 — 418 (Unused) Pada 2017, kelompok kerja HTTP IETF mengusulkan agar kode itu dibersihkan supaya dapat ditetapkan ulang untuk hal yang berguna. Internet menjawab dengan kampanye “Save 418” (terjemahan) “Selamatkan 418”, dan reservasi itu dipertahankan — RFC 9110 juga masih membuka kemungkinan penetapan ulang jika keadaan kelak memerlukannya.

Reservasi itu tidak menghentikan implementasi: modul net/http milik Go dan modul http milik Python sama-sama mengekspos konstanta 418 bernama (StatusTeapot, HTTPStatus.IM_A_TEAPOT), dan framework serta platform lain mengikutinya sebagai easter egg — termasuk google.com/teapot milik Google. Bukti untuk klaim ini 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. Cakupan: Named constants in two mainstream standard libraries; not evidence of a default response. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-16 Go: net/http status constants (StatusTeapot) Python docs: http.HTTPStatus.IM_A_TEAPOT Konstanta bernama tidak berarti framework memancarkan 418 secara bawaan; artinya kode tersebut dikenali, bukan memiliki semantik HTTP yang ditetapkan.

Arti 418 bagi SEO

Tidak ada yang istimewa — dan itulah poin pentingnya. Google tidak menafsirkan leluconnya; sebuah posting Search Central Februari 2023 yang berjudul menyatakan bahwa semua respons 4xx kecuali 429 mendapat perlakuan yang sama di Search: URL yang sebelumnya diindeks akan dihapus seiring waktu dan kontennya tidak digunakan. Bukti untuk klaim ini 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. Cakupan: Google Search's dated, named statement on 4xx handling (not 418-specific). Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-16 Google Search Central Blog (Feb 2023): Don't use 403s or 404s for rate limiting Itu pernyataan umum tentang 4xx, bukan aturan khusus teko — halaman status crawler generik Google saat ini secara eksplisit menyatakan bahwa status eksotis seperti 418 tidak tercakup dalam tabelnya. Bukti untuk klaim ini Google's current generic crawler-status-code page states that exotic statuses such as 418 are not covered by its table. Cakupan: Scope note limiting Google's generic HTTP-status guidance to common codes. Tingkat keyakinan: tinggi · Diverifikasi: 2026-07-16 Google: How HTTP status codes affect Google's crawlers Dalam praktik, 418 berperilaku seperti 4xx non-429 lainnya dalam hal pengindeksan; tidak ada aturan peringkat khusus teko, jadwal deindeksasi, atau jaminan pemulihan selain pernyataan umum tersebut.

Di sinilah hal tersebut berhenti menjadi lucu: beberapa konfigurasi WAF dan perlindungan bot memakai 418 sebagai respons “blocked request” (terjemahan) “permintaan diblokir” karena dianggap khas dan mudah terlihat di log. Jika aturan seperti itu salah menerapkan pengecualian pada Googlebot, halaman nyata Anda akan mulai menjawab 418 — dan diperlakukan persis seperti halaman yang tidak ada.

Jika Anda melihat respons tersebut di log server atau laporan crawl pada URL penting, kode status saja tidak memberi tahu lapisan mana yang membuatnya — kode aplikasi, bawaan framework, aturan WAF atau perlindungan bot, CDN, maupun server asal semuanya dapat menghasilkan respons itu, dan respons dapat melewati beberapa lapisan sebelum sampai ke klien. Periksa konfigurasi, header respons, dan log jalur permintaan di setiap lapisan untuk menemukan sumber sebenarnya, lalu perbaiki seperti galat 4xx tak diinginkan lainnya pada URL yang dapat diindeks.

Gunakan rangkaian diagnosis minimum berikut:

Ambil status mentah dan header respons URL yang terdampak.
Bandingkan log aplikasi, WAF, CDN, dan origin untuk jalur permintaan serta waktu yang sama.
Perbaiki lapisan yang mengeluarkan 418, lalu ulangi permintaan mentah dan pengujian crawler.

Satu-satunya di situs ini

Sesuai semangat RFC, /coffee di situs ini mengembalikan 418 sungguhan, pendek dan kekar, langsung dari edge. Halaman ini ada agar easter egg tersebut memiliki penjelasan kanonis — dan agar cluster http-status-codes mencakup satu kode status yang benar-benar membuat orang tersenyum.

TL;DR — Perlakukan 418 yang tidak terduga sebagai 4xx non-429 biasa dari produsen yang tidak biasa. Simpan respons mentah, tentukan lapisan aplikasi, WAF, CDN, atau origin yang mengirimnya, lalu uji jalur crawler yang sama hingga URL penting kembali ke status yang dimaksud.

Pahami sinyal sebelum mengubah apa pun

Kode status mengklasifikasikan respons, bukan sistem yang memilihnya. Panduan Google yang dirujuk menempatkan 418 dalam perilaku umum 4xx non-429: konten tidak dipakai untuk pengindeksan dan URL yang sudah terindeks dapat dihapus seiring waktu; tidak ada jalur pemulihan khusus teapot.

Mulai dari satu URL dan simpan waktu, path, status, header, serta body. Periksa apakah hasil bergantung pada user-agent, IP, autentikasi, rate, atau lokasi.

Isolasi lapisan penerbit

Kerjakan dari respons publik ke dalam:

Reproduksi dengan request mentah dan catat header serta body.
Cocokkan path dan waktu pada log CDN, WAF, origin, framework, dan aplikasi.
Bandingkan browser dengan crawler; teks halaman error tidak membuktikan sumbernya.
Ubah hanya rule atau kode yang terbukti; konstanta bernama tidak berarti framework mengirim 418 secara default.

Verifikasi pemulihan

Uji ulang URL melalui jalur yang gagal. Hasilnya harus berupa status yang benar-benar dibutuhkan resource, biasanya 200 untuk halaman live yang dapat diindeks. Sampel juga URL tetangga di bawah rule yang sama.

Pantau 418 baru pada URL yang dapat diindeks. /coffee harus tetap menjadi kontrol 418 yang disengaja; halaman produksi tidak boleh mewarisinya.

Alat untuk menemukan 418 yang tidak terduga

Bulk HTTP Status Code Checker: pindai sekumpulan URL untuk respons 418 dan bedakan easter egg yang disengaja dari halaman nyata yang diblokir WAF atau aturan perlindungan bot.
HTTP Header Checker: periksa header CDN dan keamanan untuk petunjuk lapisan mana yang menghasilkan respons.
Panel Network DevTools browser: verifikasi status mentah pada permintaan, bukan mengandalkan teks halaman galat yang terlihat.
curl: jalankan curl -i https://example.com/path untuk mengambil status, header, dan isi respons apa pun tanpa sesi browser yang sudah login.
Peristiwa keamanan CDN/WAF: jika 418 muncul pada halaman yang seharusnya dapat diindeks, cocokkan waktu dan URL permintaan dengan aturan yang terpicu sebelum mengubahnya.

418 I'm a teapot berasal dari RFC 2324 (HTCPCP), RFC April Mop 1998; kode ini menandakan teko diminta menyeduh kopi. RFC 7168 meninjaunya kembali pada 2014 untuk perangkat penyeduh teh.
Kode ini bukan “unassigned” (terjemahan) “tidak ditetapkan”: RFC 9110 secara resmi mencadangkan 418, dan registri IANA mencantumkannya sebagai (Unused) — status yang dipertahankan setelah perjuangan internet, bukan status yang tak pernah diklaim. Upaya mengambilnya kembali pada 2017 ditinggalkan setelah kampanye “Save 418” (terjemahan) “Selamatkan 418”.
Go dan Python sama-sama mengekspos konstanta 418 bernama; framework dan platform lain mengimplementasikannya sebagai easter egg (Google memiliki google.com/teapot) — tetapi konstanta tidak berarti framework mengeluarkan 418 secara bawaan.
Dampak SEO: sebuah posting Google Search Central Februari 2023 yang berjudul memperlakukan setiap 4xx non-429 sama di Search — URL yang menjawab 418 tidak diindeks, sama seperti 404; halaman status crawler generik Google saat ini sama sekali tidak mencakup kode eksotis seperti 418.
Risiko praktis: 418 yang tidak terduga dapat berasal dari aplikasi, bawaan framework, aturan WAF/perlindungan bot, CDN, atau origin — periksa header dan log di setiap lapisan untuk menemukan sumbernya sebelum memperbaikinya seperti 4xx lainnya.
Situs ini mengembalikan 418 sungguhan di /coffee.