304 Tidak Diubah

TL;DR — Respons 304 Tidak Diubah adalah cara server mengatakan “salinan ini sudah Anda miliki dan masih valid, jadi tidak perlu mengunduhnya lagi”. Respons ini bukan error. Walaupun berada dalam keluarga 3xx, respons ini tidak mengarahkan siapa pun ke URL baru. Respons ini muncul ketika klien (browser atau crawler) lebih dulu mengirim permintaan bersyarat dengan pertanyaan “apakah sudah berubah sejak terakhir kali?”. Untuk SEO, respons ini tidak mengubah peringkat, tetapi pada situs besar dapat membantu mesin pencari memakai sumber daya secara lebih efisien.

Apa sebenarnya arti 304

Setiap respons server dimulai dengan kode status tiga digit. 200 OK berarti “ini halamannya, lengkap dengan isi”. 304 Tidak Diubah lebih spesifik: klien mengirim permintaan bersyarat—“kirim halaman ini hanya jika sudah berubah”—dan server menentukan bahwa halaman belum berubah. Alih-alih 200 yang seharusnya dikirim, server menjawab 304 tanpa body. Inilah aturannya: 304 hanya menjadi jawaban atas GET/HEAD bersyarat yang kondisinya bernilai false.

Kunjungan kedua adalah contoh yang paling umum dan mudah dibayangkan: pada kunjungan pertama, browser atau crawler mengambil halaman dengan 200 normal, lengkap dengan beberapa header “sidik jari”. Pada kunjungan berikutnya, klien mengirimkan sidik jari itu dan bertanya, “masih sama?”. Jika tidak ada perubahan, server menjawab 304 tanpa body halaman, lalu klien memakai salinan yang sudah tersimpan. Namun “kunjungan kedua” hanyalah contoh; aturan protokolnya adalah permintaan bersyarat, dari mana pun permintaan itu berasal. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

Mengapa kode ini masuk keluarga “redirect”, tetapi bukan redirect

Angka 304 diawali 3, yaitu kelas yang dipakai HTTP untuk redirect, sehingga sering membingungkan. Namun 304 tidak memiliki header Location dan tidak mengirim klien ke alamat lain—tidak ada yang berpindah. Respons ini hanya meminta klien memakai salinan yang tersimpan di cache-nya sendiri. Jadi “keluarga redirect” hanyalah keanehan penomoran, bukan perilakunya.

Apakah 304 merupakan masalah?

Tidak. Melihat 304 di tab jaringan browser atau laporan crawl menandakan cache bekerja, persis seperti yang diharapkan. Banyak panduan “304 error, bagaimana memperbaikinya” menganggapnya sebagai kerusakan di sisi Anda, padahal bukan. Ini adalah hasil yang benar dan memang dirancang dari cache yang berjalan baik.

Apakah respons ini membantu SEO?

Bukan secara langsung pada peringkat. Google sudah memiliki konten dari crawl sebelumnya—304 hanya mengonfirmasi bahwa konten belum berubah, sehingga Google tetap memakai yang tersimpan (Search masih dapat menghitung ulang sinyal URL, tetapi 304 sendiri bukan bonus peringkat atau pengindeksan). Manfaatnya adalah efisiensi sumber daya: mesin pencari tidak perlu mengunduh ulang halaman yang belum berubah, sehingga bandwidth dan komputasi di kedua sisi dihemat. Google mengatakan hal ini dapat secara tidak langsung membuat crawling lebih efisien, tetapi bukan jaminan bahwa penghematan itu otomatis dialihkan ke halaman baru atau yang diperbarui. Dampaknya paling berarti pada situs besar dengan banyak halaman yang jarang berubah.

Ingin memahami mekanismenya—ETag, If-None-Match, validator kuat dan lemah, cara menerapkannya, serta pernyataan Google? Beralihlah ke tab Advanced.

TL;DR — 304 adalah respons atas GET/HEAD bersyarat yang kondisinya bernilai false dan seharusnya menghasilkan 200 (RFC 9110 §15.4.5). Respons ini berada di kelas 3xx, tetapi bukan redirect: tidak ada Location, URL baru, atau—secara normatif—body (“it cannot contain content or trailers” (terjemahan) “tidak boleh memuat konten atau trailer”). Kondisi dibawa oleh If-None-Match (dibandingkan dengan ETag) dan/atau If-Modified-Since (dibandingkan dengan Last-Modified). Jika validator masih cocok, server mengembalikan 304 dan klien memakai cache-nya. Dampak SEO: tidak ada efek peringkat langsung—Google sudah memiliki konten, meski Search masih dapat menghitung ulang sinyal URL—serta ada penghematan sumber daya pada situs besar. Google menyebutnya dapat secara tidak langsung meningkatkan efisiensi crawl, bukan menjanjikan pengalokasian ulang anggaran crawl. Infrastruktur crawling Google mendukung kedua validator dan merekomendasikan ETag sebagai yang utama. Bandingkan dengan 301/302/307/308 (yang memindahkan URL) dan 204 (juga tanpa body, tetapi karena memang tidak ada yang dikirim).

Arti 304 menurut spesifikasi

RFC 9110 (HTTP Semantics) §15.4.5 mendefinisikannya secara tepat: “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (terjemahan) “Kode status 304 (Not Modified) menunjukkan bahwa permintaan GET atau HEAD bersyarat telah diterima dan akan menghasilkan respons 200 (OK) jika kondisinya tidak bernilai false.” Itulah pemicu normatifnya: GET/HEAD bersyarat yang kondisinya false dan seharusnya menghasilkan 200. Dengan kata sederhana, klien meminta halaman hanya jika berubah, server melihat belum berubah, lalu tidak mengirim body. “Kunjungan kedua” adalah contoh sehari-hari saat permintaan menjadi bersyarat karena klien melampirkan validator dari respons sebelumnya, bukan aturan protokol; spesifikasi tidak mengharuskan kunjungan sebelumnya. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

Spesifikasi bahkan memakai kata “redirecting”: “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (terjemahan) “server mengarahkan klien untuk memakai representasi tersimpan seolah-olah itu isi respons 200 (OK)”. Bacalah dengan saksama: klien diarahkan kembali ke cache miliknya sendiri, bukan ke URL lain. Tidak ada header Location dan tidak ada alamat baru. Kalimat inilah yang paling sering menimbulkan pertanyaan apakah 304 adalah redirect. Dalam pengertian HTTP, bukan.

Dua poin normatif lain juga penting:

• Tidak pernah ada body. RFC 9110 menyatakan: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (terjemahan) “Respons 304 berakhir pada akhir bagian header; respons ini tidak boleh memuat konten atau trailer.” 304 yang mengirim body melanggar spesifikasi dan dapat disalahartikan oleh sebagian klien. Ini aturan keras, bukan pilihan gaya.
• Metadata-nya sama seperti yang akan dibawa 200. Server “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary,” (terjemahan) “WAJIB menghasilkan field header yang akan dikirim pada respons 200 (OK) untuk permintaan yang sama: Content-Location, Date, ETag, dan Vary,” ditambah Cache-Control dan Expires jika berlaku. Jadi 304 membawa header 200 tanpa payload.

Cara kerja 304: permintaan bersyarat

Server tidak pernah mengirim 304 tanpa alasan. Respons ini selalu merupakan jawaban atas permintaan bersyarat—permintaan yang dibuat bersyarat oleh klien dengan melampirkan validator yang disimpan dari respons sebelumnya. Ada dua validator.

ETag dan If-None-Match

ETag (entity tag) adalah token buram yang ditempelkan server pada respons 200—anggap sebagai sidik jari versi untuk representasi URL tersebut. Pada permintaan berikutnya ke URL itu, klien mengirim kembali nilai yang disimpan dalam header If-None-Match. Server membandingkan: jika ETag saat ini masih cocok, tidak ada perubahan dan server mengembalikan 304; jika berbeda, server mengembalikan 200 baru dengan konten dan ETag baru.

Last-Modified dan If-Modified-Since

Alternatif berbasis tanggal: server mengirim timestamp Last-Modified pada 200. Pada permintaan berikutnya, klien mengirimkannya kembali dalam header If-Modified-Since dan server membandingkan tanggal. Jika sumber daya belum berubah sejak timestamp itu, jawabannya 304. Cara ini lebih sederhana tetapi lebih kasar (ketelitiannya hanya setara timestamp) dan sensitif terhadap format HTTP-date yang tepat, sumber bug yang umum. Jika kedua validator ada, If-None-Match (ETag) memiliki prioritas atas If-Modified-Since.

ETag kuat dan lemah

ETag dapat kuat atau lemah, dan perbedaannya penting. Menurut panduan conditional request MDN, “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (terjemahan) “validasi kuat menjamin bahwa sumber daya identik byte demi byte dengan pembandingnya.” ETag lemah diawali W/ (misalnya ETag: W/"abc123") dan hanya menyatakan kesetaraan semantik—contoh MDN: “a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation.” (terjemahan) “halaman yang hanya berbeda tanggal footer atau iklannya akan dianggap identik pada validasi lemah.” ETag kuat (tanpa awalan) diperlukan untuk permintaan rentang yang membutuhkan kecocokan byte; ETag lemah berguna ketika kompresi, spasi, atau perbedaan kecil tidak substantif seharusnya tidak memicu pengambilan ulang. Jebakan praktisnya: ETag yang berubah setiap kali gzip/Brotli dikompresi ulang atau berbeda antarserver seimbang-beban akan memicu crawl ulang yang tidak perlu. Pilih kuat atau lemah dengan sengaja dan pertahankan nilainya untuk konten yang benar-benar tidak berubah.

Jabat tangan lengkap, langkah demi langkah

1. Permintaan pertama → server mengembalikan 200 OK dengan konten serta ETag dan/atau Last-Modified.
2. Klien menyimpan konten dan validator tersebut.
3. Permintaan berikutnya → klien mengirim If-None-Match dan/atau If-Modified-Since bersama nilai yang tersimpan.
4. Server memutuskan: tidak berubah → 304 Not Modified tanpa body dan klien memakai cache; berubah → 200 OK dengan body serta validator baru. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Jika ingin membahas caching dan validator lebih dalam sebagai pengungkit efisiensi crawl—seluruh mekanisme permintaan bersyarat dan kaitannya dengan anggaran crawl—itu merupakan topik pendamping; artikel ini berfokus pada kode status.

304 dan SEO: tanpa efek peringkat, tetapi nyata untuk efisiensi crawl

Inilah keseluruhan cerita SEO-nya, dan lebih sempit daripada klaim blog yang sering diulang. 304 tidak memiliki efek peringkat langsung, dan panduan Google tentang pengaruh kode status terhadap crawling dan indexing juga membatasi efek pengindeksannya: Search masih dapat menghitung ulang sinyal URL, tetapi selain itu 304 tidak mengubah cara halaman diindeks. Google sudah memiliki konten dari crawl sebelumnya; 304 hanya mengonfirmasi bahwa tidak ada perubahan sehingga Google tetap memakai konten yang ada. Tidak ada bonus peringkat karena mengembalikan 304.

Yang diberikan 304 adalah penghematan sumber daya yang dapat secara tidak langsung meningkatkan efisiensi crawl. Dalam tulisan Google Search Central Desember 2024 tentang HTTP caching, Gary Illyes menjelaskannya: “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (terjemahan) “Khususnya jika situs Anda besar dan konten pada URL individual jarang berubah, caching lokal dapat membantu situs di-crawl lebih efisien. Infrastruktur crawling Google mendukung HTTP caching heuristik sesuai standar HTTP caching, khususnya melalui header respons ETag dan header permintaan If-None-Match, serta header respons Last-Modified dan header permintaan If-Modified-Since.”

Tulisan yang sama menjelaskan mekanisme 304 secara eksplisit: jika ETag yang dikirim crawler “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body,” (terjemahan) “cocok dengan nilai terbaru yang dibuat server, server seharusnya mengembalikan kode status HTTP 304 (Not modified) tanpa body HTTP”. Bagian “no HTTP body” penting karena “your server doesn’t have to spend compute resources on actually generating content” (terjemahan) “server tidak perlu menghabiskan sumber daya komputasi untuk membuat konten” dan “doesn’t have to transfer the HTTP body” (terjemahan) “tidak perlu mentransfer body HTTP”. Anda menghemat komputasi dan bandwidth di kedua sisi. Google menyebut manfaat akhirnya secara bersyarat: penghematan ini dapat secara tidak langsung meningkatkan efisiensi crawl. Itu bukan janji bahwa upaya yang dihemat otomatis dialihkan ke URL baru atau yang diperbarui; anggap sebagai mekanisme penghematan dengan efek limpahan yang masuk akal, bukan kepastian.

Mengapa lebih penting pada situs besar

Jika hanya memiliki beberapa ratus halaman, hal ini sebagian besar bersifat akademis—Google dapat merayapi seluruh situs dengan nyaman. Manfaat meningkat seiring ukuran: situs dengan ratusan ribu atau jutaan URL, banyak di antaranya jarang berubah, memperoleh manfaat nyata ketika crawler melewati pengambilan ulang halaman yang tidak berubah. Itulah sasaran tulisan Google, jadi pertahankan pembingkaian yang jujur; jangan menjual 304 sebagai taktik khusus situs kecil.

ETag atau Last-Modified, dan apa yang dianggap “berubah”

Google merekomendasikan ETag sebagai validator utama: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (terjemahan) “Kami sangat merekomendasikan ETag karena lebih kecil kemungkinannya menimbulkan error dan kesalahan (nilainya tidak terstruktur seperti Last-Modified).” Memasang keduanya boleh dan dianjurkan. Jika memakai Last-Modified, tanggal “must be formatted according to the HTTP standard” (terjemahan) “harus diformat sesuai standar HTTP”—Google merekomendasikan format “Weekday, DD Mon YYYY HH:MM:SS Timezone,” (terjemahan) “Weekday, DD Mon YYYY HH:MM:SS Timezone,” misalnya “Fri, 4 Sep 1998 19:15:56 GMT” (terjemahan) “Fri, 4 Sep 1998 19:15:56 GMT”—atau tanggal dapat diabaikan diam-diam. Google juga menyarankan field max-age pada Cache-Control agar crawler dapat menentukan kapan harus crawl ulang.

Anda yang menentukan perubahan apa yang layak membatalkan cache. Saran Google adalah menyimpan invalidasi untuk perubahan substantif: “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (terjemahan) “Kami menyarankan refresh cache diwajibkan untuk perubahan signifikan pada konten; jika hanya tanggal hak cipta di bagian bawah halaman yang diperbarui, kemungkinan itu tidak signifikan.”

Perilaku Googlebot dan Bingbot

Tidak setiap permintaan crawler bersyarat. Dokumentasi crawler Google mencatat bahwa dukungan caching berbeda antara crawler dan fetcher sesuai produk yang dilayani—Googlebot mendukung caching ketika melakukan crawl ulang URL untuk Search, sedangkan sebagian fetcher Google hanya mendukungnya dalam kondisi tertentu. Jadi, meski header dikonfigurasi benar, jangan mengharapkan 100% permintaan membawa If-None-Match/If-Modified-Since. Untuk Bing, permintaan bersyarat bukan fitur khusus Google. Crawler Bing telah mendukung GET bersyarat (mengirim If-Modified-Since dan, jika tersedia, If-None-Match serta menerima 304 ketika konten tidak berubah) setidaknya sejak tulisan blog Live Search tahun 2008, meski Bing belum menerbitkan tulisan modern yang setara dengan artikel Google 2024. Perlakukan mekanismenya sebagai perilaku HTTP generik yang berlaku bagi kedua mesin.

Cara menerapkan dukungan 304

1. Kirim validator pada 200. Konfigurasikan server, CDN, atau aplikasi agar menambahkan header ETag (disarankan) dan/atau Last-Modified yang diformat benar pada respons 200 biasa. Banyak server dan framework membuat ETag otomatis untuk file statis; respons dinamis biasanya memerlukan opt-in.
2. Hormati header bersyarat saat diterima. Ketika permintaan datang dengan If-None-Match/If-Modified-Since, bandingkan dengan validator saat ini dan kembalikan 304 (tanpa body) jika masih cocok, atau 200 baru jika tidak. Server file statis sering menangani ini otomatis; route aplikasi dan edge worker sering memerlukan konfigurasi tambahan.
3. Tentukan arti “berubah” dan pertahankan ETag stabil untuk konten yang benar-benar tidak berubah—jangan biarkan kompresi ulang atau variasi antarserver mengubahnya tanpa alasan.
4. Waspadai salah konfigurasi umum:
   • Selalu-200—tidak pernah mengirim validator, sehingga tidak ada permintaan yang menjadi bersyarat dan manfaat efisiensi hilang.
   • ETag tidak stabil—nilai berubah walau konten tidak (load balancer atau kompresi ulang), memaksa pengambilan ulang terus-menerus.
   • 304 basi—yang paling berbahaya: server terus mengembalikan 304 (atau ETag tidak berubah) setelah konten benar-benar berubah, sehingga crawler dan cache tidak pernah mengambil pembaruan. Ini bug yang harus ditemukan lewat analisis log, bukan kelemahan bawaan 304.

304 dibandingkan kode status lain

304 dibandingkan dengan 301 / 302 / 307 / 308

Kode-kode itulah redirect yang sebenarnya. 301/308 (permanen) atau 302/307 (sementara) membawa header Location dan memindahkan klien ke URL berbeda—301/308 juga meneruskan sinyal kanonik. 304 tidak memiliki Location, tidak memindahkan siapa pun, dan tidak meneruskan sinyal peringkat. Kelas 3xx-nya sama menurut angka, tetapi tugasnya sepenuhnya berbeda. Detail setiap kode redirect ada di artikel masing-masing (lihat artikel 301 redirect dan hub redirect).

304 dibandingkan dengan 204 No Content

Keduanya tanpa body, tetapi alasannya sepenuhnya berbeda. 204 No Content adalah keberhasilan 2xx dengan body sengaja kosong karena server memang tidak memiliki apa pun untuk dikirim—misalnya DELETE/PUT API yang berhasil atau beacon analitik. 304 juga tidak mengirim body, tetapi bukan karena tidak ada yang dikirim; alasannya adalah “salinan itu sudah Anda miliki dan masih valid”. Jangan campuradukkan: 204 pada URL halaman dapat dianggap soft 404 karena tidak ada konten yang bisa diindeks, sedangkan 304 mengonfirmasi validitas konten yang sudah dimiliki Google. Artikel 204 No Content membahas kode itu secara lengkap.

Mitos umum tentang 304

1. “304 adalah redirect.” Tidak ada header Location dan tidak ada yang berpindah. Klien memakai salinan cache miliknya. Frasa RFC 9110 “redirecting the client to make use of that stored representation” (terjemahan) “mengarahkan klien untuk memakai representasi tersimpan” berarti kembali ke cache, bukan ke URL lain.
2. “304 adalah error yang harus diperbaiki.” Ini hasil yang benar dari konfigurasi permintaan bersyarat yang berfungsi. Melihat 304 dalam crawl atau DevTools menandakan caching bekerja—salah satu miskonsepsi paling umum di SERP.
3. “304 membantu peringkat.” Tidak ada efek peringkat langsung, dan efek pengindeksannya juga terbatas—Search dapat menghitung ulang sinyal URL, tetapi 304 tidak mengubah indexing. Manfaatnya adalah penghematan sumber daya yang menurut Google dapat secara tidak langsung meningkatkan efisiensi crawl pada situs sangat besar; ini bukan sinyal peringkat atau jaminan pengalihan usaha ke URL lain.
4. “If my server returns 304, Google will use stale content forever.” (terjemahan) “Jika server saya mengembalikan 304, Google akan selamanya memakai konten basi.” 304 hanya muncul selama validator masih cocok. Begitu konten benar-benar berubah, server yang benar mengembalikan 200 baru dengan validator baru. Risikonya adalah server salah konfigurasi yang tetap mengembalikan 304 setelah perubahan—itu bug, bukan sifat 304. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. “ETag dan Last-Modified dapat dipertukarkan.” Keduanya validator, tetapi Last-Modified sensitif terhadap format tanggal dan ketelitiannya hanya sebesar timestamp, sedangkan ETag buram dan presisi (meski dapat berbeda antarserver atau setelah kompresi ulang jika diterapkan ceroboh). Google merekomendasikan ETag sebagai utama; gunakan keduanya bila bisa.

FAQ

Apakah HTTP 304 merupakan error? Tidak—ini sinyal keberhasilan bahwa caching bekerja. Artinya salinan yang tersimpan di klien masih valid.

Apakah 304 Not Modified adalah redirect? Tidak. Secara penomoran ia berada di kelas 3xx, tetapi tidak memiliki header Location dan tidak memindahkan klien ke URL baru.

Apakah 304 membantu SEO atau peringkat? Tidak ada efek peringkat langsung dan tidak ada efek indexing selain kemungkinan Google menghitung ulang sinyal URL. Respons ini menghemat bandwidth dan komputasi dengan membiarkan crawler melewati halaman yang tidak berubah; Google menyebutnya dapat secara tidak langsung meningkatkan efisiensi crawl pada situs besar.

Apa perbedaan ETag dan Last-Modified? ETag adalah sidik jari versi buram yang dicocokkan melalui If-None-Match; Last-Modified adalah timestamp yang dicocokkan melalui If-Modified-Since. Google merekomendasikan ETag karena lebih kecil kemungkinan salah.

Apa perbedaan ETag lemah dan kuat? ETag kuat menyatakan konten identik byte demi byte; ETag lemah (diawali W/) menyatakan kesetaraan semantik dan menoleransi perbedaan kecil seperti kompresi atau tanggal footer.

Mengapa saya melihat respons Not Modified di log atau laporan crawl? Karena klien mengirim permintaan bersyarat dan server dengan benar mengonfirmasi bahwa konten belum berubah. Itu wajar dan baik.

Bagaimana membuat server mengembalikan 304 dengan benar? Kirim ETag/Last-Modified pada 200, lalu hormati If-None-Match/If-Modified-Since pada permintaan berikutnya dengan mengembalikan 304 tanpa body ketika validator masih cocok.

Apa perbedaan 304 dan 204? Keduanya tanpa body; 204 karena memang tidak ada yang dikirim, sedangkan 304 karena klien sudah memiliki salinan yang masih valid.

Apakah Googlebot mengirim header bersyarat pada setiap permintaan? Tidak—dukungan caching berbeda menurut crawler, sehingga tidak setiap permintaan bersyarat meskipun header sudah dikonfigurasi.

Bolehkah respons 304 memiliki body? Tidak. RFC 9110 menyatakan “it cannot contain content or trailers.” (terjemahan) “respons ini tidak boleh memuat konten atau trailer.” 304 yang memiliki body melanggar spesifikasi.

Ringkasan AI

Ringkasan singkat versi Advanced:

• 304 Tidak Diubah adalah respons atas GET/HEAD bersyarat yang kondisinya bernilai false dan seharusnya menghasilkan 200 (RFC 9110 §15.4.5). Respons ini berada di kelas 3xx tetapi BUKAN redirect: tidak ada Location, URL baru, dan—secara normatif—tidak ada body: “it cannot contain content or trailers.” (terjemahan) “tidak boleh memuat konten atau trailer.” Kunjungan kedua adalah contoh permintaan menjadi bersyarat, bukan aturan protokol.
• Ini adalah jawaban atas permintaan bersyarat. GET/HEAD membawa If-None-Match (dicocokkan dengan ETag) dan/atau If-Modified-Since (dicocokkan dengan Last-Modified). Jika validator masih cocok, server mengembalikan 304 dan klien memakai cache.
• Kata “redirecting” (terjemahan) “mengarahkan” dalam spesifikasi bersifat kiasan—klien diarahkan ke cache miliknya sendiri, bukan URL lain. Kalimat ini menyebabkan sebagian besar kebingungan “apakah 304 redirect?”.
• ETag vs. Last-Modified: ETag adalah token versi buram (dicocokkan melalui If-None-Match); Last-Modified adalah tanggal (dicocokkan melalui If-Modified-Since, dengan format HTTP-date yang harus tepat). Jika keduanya ada, If-None-Match diprioritaskan. ETag kuat = identik byte; ETag lemah (awalan W/) = setara secara semantik.
• Tidak ada efek peringkat langsung dan tidak ada efek indexing selain kemungkinan Google menghitung ulang sinyal URL. Google sudah memiliki konten; 304 hanya mengonfirmasi tidak ada perubahan. Gary Illyes mengatakan caching “may help your site be crawled more efficiently” (terjemahan) “dapat membantu situs di-crawl lebih efisien”—manfaatnya penghematan sumber daya yang dapat secara tidak langsung meningkatkan efisiensi crawl pada situs besar, bukan alokasi ulang anggaran crawl yang dijamin dan bukan sinyal peringkat.
• Google merekomendasikan ETag sebagai yang utama (“less prone to errors and mistakes” (terjemahan) “lebih kecil kemungkinan menimbulkan error dan kesalahan”); memasang keduanya boleh. Last-Modified harus memakai format “Weekday, DD Mon YYYY HH:MM:SS Timezone”; batalkan cache hanya untuk perubahan signifikan, bukan tanggal hak cipta footer.
• Dukungan caching berbeda menurut crawler—tidak setiap permintaan Googlebot bersyarat. Bing telah mendukung GET bersyarat sejak tulisan Live Search tahun 2008; ini perilaku HTTP generik.
• Jangan samakan dengan 301/302/307/308 (redirect nyata yang memindahkan URL) atau 204 No Content (juga tanpa body karena memang tidak ada yang dikirim).
• Risiko sebenarnya bukan 304, melainkan server salah konfigurasi yang mengembalikan 304 setelah konten berubah—temukan lewat analisis log. 304 yang valid juga dapat tampak seperti error pada sebagian library klien atau lapisan caching platform walau tidak ada yang salah.

Dokumentasi resmi

Referensi sumber utama tentang arti 304 dan cara mesin pencari memakainya.

Spesifikasi HTTP dan referensi browser

• RFC 9110 §15.4.5 — 304 Tidak Diubah — definisi otoritatif: permintaan bersyarat, tanpa body, dan header wajib.
• MDN — 304 Tidak Diubah — penjelasan sederhana, pemicu If-None-Match/If-Modified-Since, serta daftar header yang harus dibawa 304.
• MDN — Permintaan HTTP bersyarat — penjelasan validasi kuat dan lemah.
• MDN — ETag — header ETag, termasuk sintaks lemah (W/) dan kuat.

Google Search Central

• Crawling December: HTTP caching — tulisan Gary Illyes, 9 Desember 2024, tentang cara ETag/If-None-Match dan Last-Modified/If-Modified-Since memicu 304 serta manfaatnya untuk efisiensi crawl.
• Ikhtisar Google Crawler (User Agent) — crawler Google mana yang mendukung caching dan rekomendasi ETag dibandingkan Last-Modified.
• Dampak kode status HTTP pada crawler Google — baris 304 saat ini, termasuk kualifikasi bahwa Search masih dapat menghitung ulang sinyal URL meskipun 304 tidak mengubah indexing.
• Memecahkan masalah error crawling Google Search — sumber pernyataan bersyarat Google bahwa penghematan sumber daya dari permintaan bersyarat “may indirectly” (terjemahan) “dapat secara tidak langsung” meningkatkan efisiensi crawl, serta bahwa Google tidak mengirim header bersyarat pada setiap percobaan crawl.

Bing

• Pengumuman peningkatan crawler Live Search — tulisan Bing/Live Search lama yang mengonfirmasi dukungan GET bersyarat (If-Modified-Since/If-None-Match → 304) sejak 2008.

Kutipan dari sumber

Pernyataan yang tercatat. Setiap tautan adalah deep link yang melompat ke bagian sumber tempat kutipan didukung.

Spesifikasi HTTP

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (terjemahan) “Kode status 304 (Not Modified) menunjukkan bahwa permintaan GET atau HEAD bersyarat telah diterima dan akan menghasilkan respons 200 (OK) jika kondisinya tidak bernilai false.” — RFC 9110, HTTP Semantics, §15.4.5. Baca bagian ini
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (terjemahan) “Respons 304 berakhir pada akhir bagian header; respons ini tidak boleh memuat konten atau trailer.” — RFC 9110, §15.4.5 (aturan normatif “no body, ever” (terjemahan) “tidak pernah ada body”). Baca bagian ini

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (terjemahan) “Kode status respons redirection HTTP 304 Not Modified menunjukkan bahwa sumber daya yang diminta tidak perlu dikirim ulang.” Lompat ke kutipan
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (terjemahan) “Validasi kuat menjamin bahwa sumber daya identik byte demi byte dengan pembandingnya.” — MDN, “HTTP conditional requests”. Baca panduan

Gary Illyes, Google — “Crawling December: HTTP caching” (9 Desember 2024)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (terjemahan) “Khususnya jika situs Anda besar dengan konten yang jarang berubah pada URL individual, caching lokal dapat membantu situs di-crawl lebih efisien. Infrastruktur crawling Google mendukung HTTP caching heuristik sesuai standar, khususnya melalui header respons ETag dan header permintaan If-None-Match, serta header respons Last-Modified dan header permintaan If-Modified-Since.” Baca tulisannya
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (terjemahan) “Kami sangat merekomendasikan ETag karena lebih kecil kemungkinan error dan kesalahan (nilainya tidak terstruktur seperti Last-Modified).” Baca tulisannya
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (terjemahan) “Jika nilai ETag yang dikirim crawler cocok dengan nilai terbaru yang dibuat server, server Anda seharusnya mengembalikan kode status HTTP 304 (Not modified) tanpa body HTTP.” Baca tulisannya
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (terjemahan) “Kami menyarankan refresh cache diwajibkan untuk perubahan signifikan pada konten; memperbarui tanggal hak cipta di bawah halaman saja kemungkinan tidak signifikan.” Baca tulisannya

Ahrefs — Patrick Stox

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (terjemahan) “304 Not Modified—menyatakan halaman belum diubah. Biasanya digunakan untuk caching.” — dari panduan saya Kode Status HTTP dan Dampak SEO-nya (artikel ini adalah pembahasan mendalam yang tidak dimiliki entri tersebut). Lompat ke kutipan

304 dalam konteks: kode tanpa body dan kode 3xx yang sering tertukar

304 dibandingkan kode yang mirip

Jebakannya: 304 dan 204 sama-sama tanpa body, sedangkan 304/301/302/307/308 semuanya 3xx—tetapi 304 berbeda pada kedua sumbu. Ini satu-satunya 3xx yang tidak memindahkan siapa pun, dan satu-satunya kode tanpa body yang berarti “salinan sudah Anda miliki”, bukan “tidak ada yang dikirim”.

Dua validator

Jika keduanya ada, If-None-Match memiliki prioritas atas If-Modified-Since.

Fakta singkat

• 304 tidak pernah memiliki body—RFC 9110 menjadikannya aturan normatif.
• 304 adalah kode 3xx tetapi bukan redirect (tidak ada Location dan URL baru).
• Tidak ada efek peringkat langsung, dan tidak ada efek indexing selain kemungkinan Google menghitung ulang sinyal URL; manfaatnya adalah penghematan sumber daya yang dapat secara tidak langsung membantu efisiensi crawl pada situs besar.
• Google merekomendasikan ETag sebagai validator utama; memasang ETag dan Last-Modified sekaligus boleh.
• Last-Modified harus memakai format “Weekday, DD Mon YYYY HH:MM:SS Timezone” atau dapat diabaikan.
• Batalkan cache pada perubahan konten yang signifikan, bukan tahun hak cipta footer.
• Tidak setiap permintaan crawler bersyarat—dukungan caching berbeda menurut crawler.
• Bing telah mendukung GET bersyarat → 304 sejak 2008; ini perilaku HTTP generik.
• Risiko sebenarnya adalah 304 basi (server mengembalikan 304 setelah konten berubah)—temukan lewat analisis log.

Jabat tangan permintaan bersyarat dalam HTTP mentah

Rangkaian permintaan dan respons konkret yang menunjukkan bagaimana 304 terjadi. (Nilai header hanya contoh.)

ETag / If-None-Match — pengambilan pertama (200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

Klien menyimpan body dan nilai ETag.

ETag / If-None-Match — pengambilan berikutnya, konten tidak berubah (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Tidak ada body. ETag cocok, sehingga server menghemat komputasi untuk membuat halaman dan bandwidth untuk mengirimkannya. Klien memakai salinan yang tersimpan.

Last-Modified / If-Modified-Since — padanan berbasis tanggal

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

Perhatikan format HTTP-date yang tepat—“Weekday, DD Mon YYYY HH:MM:SS Timezone”—yang direkomendasikan Google untuk menghindari masalah parsing.

Ketika konten SUDAH berubah—200 baru, bukan 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

ETag yang tersimpan tidak lagi cocok, sehingga server mengirim konten baru dan validator baru. Cache diperbarui. Inilah alasan 304 yang diterapkan dengan benar tidak dapat “menjebak” crawler pada konten basi: saat konten berubah, validator berubah dan permintaan berikutnya memperoleh 200 nyata.

ETag lemah vs. kuat

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

Aturan praktis: jika menjalankan situs besar dengan banyak URL yang jarang berubah, kirim ETag stabil dan hormati If-None-Match pada respons 200 agar crawler dapat mengonfirmasi “masih sama” lewat 304 yang murah dan tanpa body. Google mengatakan penghematan bandwidth dan komputasi ini dapat secara tidak langsung meningkatkan efisiensi crawl bagian situs lainnya. Jika ETag berubah pada setiap kompresi ulang atau berbeda antarserver load-balanced, manfaatnya hilang.

Kesalahan 304 yang merusak caching bersyarat

Mengubah ETag saat representasi tidak berubah

ETag yang terikat pada instance server, proses kompresi, atau timestamp permintaan menggagalkan validator: konten tidak berubah tetapi terus mengembalikan 200 penuh. Buat validator stabil dari representasi, atau gunakan ETag lemah dengan sengaja ketika perbedaan byte tidak bermakna.

Mengembalikan 304 setelah konten berubah

Validator basi dapat menyembunyikan pembaruan nyata dari klien dan crawler. Batalkan ETag atau majukan Last-Modified setiap kali representasi berubah, lalu pastikan permintaan bersyarat lama menerima 200 baru beserta body.

Mengirim 304 tanpa permintaan bersyarat yang cocok

Server tidak boleh menebak bahwa klien memiliki salinan cache. Kembalikan 304 hanya setelah mengevaluasi If-None-Match atau If-Modified-Since; permintaan pertama biasa membutuhkan respons lengkap.

Menganggap 304 sebagai redirect atau halaman kosong

304 tidak memiliki header Location dan tidak memiliki body respons. Jangan memasukkannya ke logika redirect, dan jangan mengganti sumber daya kosong yang sebenarnya dengan 304; gunakan status yang menggambarkan respons sesungguhnya.

Masalah umum 304

Server selalu mengembalikan 200

Gejala: permintaan berulang mengunduh body penuh meskipun tidak ada perubahan. Kemungkinan penyebab: respons awal tidak memiliki validator, atau aplikasi mengabaikan header permintaan bersyarat. Perbaikan: kirim ETag dan/atau Last-Modified yang valid, lalu terapkan pemeriksaan If-None-Match atau If-Modified-Since. Pastikan permintaan tanpa perubahan mengembalikan 304 tanpa body.

Server asal berbeda menghasilkan ETag berbeda

Gejala: URL yang sama berganti-ganti antara 200 dan 304 di balik load balancer. Kemungkinan penyebab: setiap node membuat validator sendiri. Perbaikan: turunkan ETag dari state konten bersama, bukan dari node yang melayani, lalu ulangi permintaan bersyarat yang sama pada beberapa respons.

Konten yang diperbarui masih mengembalikan 304

Gejala: browser atau crawler terus melihat representasi lama setelah deployment. Kemungkinan penyebab: validator tidak dibatalkan bersama perubahan konten. Perbaikan: benahi logika cache-key atau deployment, purge cache yang terdampak bila perlu, dan buktikan bahwa ETag lama kini menerima 200 dengan validator baru.

Last-Modified tampaknya diabaikan

Gejala: If-Modified-Since tidak pernah menghasilkan 304. Kemungkinan penyebab: HTTP-date tidak valid, ketelitian timestamp kurang, atau ETag mengambil prioritas. Perbaikan: periksa header mentah, benahi format tanggal, dan uji setiap validator secara terpisah.

304 tampak seperti error dalam kode aplikasi

Gejala: skrip atau aplikasi melempar exception atau mencatat “error” pada permintaan yang sebenarnya mendapat 304. Kemungkinan penyebab: sebagian library HTTP memperlakukan status selain 200—termasuk 304 yang valid—seperti kondisi exception kecuali Anda mengonfigurasinya untuk mengikuti redirect atau mengizinkan respons not-modified; ini keanehan library klien, bukan masalah protokol atau server. Perbaikan: periksa penanganan 304 secara khusus pada library (bukan hanya error 4xx/5xx), lalu pastikan respons HTTP mentah adalah 304 tanpa body yang benar sebelum menyalahkan server.

Lapisan caching platform (misalnya output caching IIS) mengaburkan masalah

Gejala: aplikasi origin terlihat benar, tetapi perilaku 304 tetap tampak salah. Kemungkinan penyebab: lapisan caching spesifik platform—output caching IIS adalah salah satu contoh terdokumentasi—berada di antara aplikasi dan klien lalu membuat atau mencegat respons 304. Perbaikan: anggap ini salah satu dari beberapa lapisan (aplikasi origin, CDN, load balancer, cache platform), bukan tersangka default; pisahkan dengan pengujian terkontrol yang mengubah validator pada tiap lapisan satu per satu sebelum menyimpulkan sumber masalah.

Prompt: audit jejak permintaan bersyarat

Tempelkan header permintaan dan respons dari pengambilan awal serta pengambilan ulang.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

Prompt: tinjau implementasi ETag

Tempelkan konfigurasi aplikasi, CDN, atau server yang relevan.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell: ulangi ETag sebagai permintaan bersyarat

Jalankan ini di terminal macOS/Linux. Salin ETag persis, termasuk tanda kutip.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

Respons pertama seharusnya menampilkan validator. Respons kedua seharusnya mengembalikan 304 ketika representasi tidak berubah dan 200 ketika ETag yang ditempel sudah basi.

PowerShell: uji Last-Modified

Jalankan di PowerShell setelah mengganti URL dan timestamp.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

Konsol DevTools: daftar validator sumber daya halaman

Jalankan di Console browser. Ini melaporkan entri resource timing; gunakan panel Network untuk memeriksa header ETag, Last-Modified, dan status yang sebenarnya.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

Alat untuk memeriksa perilaku 304

• HTTP Header Checker: periksa ETag, Last-Modified, Cache-Control, Vary, serta sidik jari CDN/edge pada respons normal sebelum mengulang validator.
• Panel Network DevTools browser: nonaktifkan “Disable cache”, muat ulang, lalu bandingkan header permintaan dan respons. DevTools juga memperlihatkan perilaku HSTS dan cache lokal, jadi bedakan perilaku browser dari yang dikirim origin.
• curl: kirim header If-None-Match atau If-Modified-Since secara persis tanpa dipengaruhi state cache browser.
• Log akses: ukur permintaan crawler mana yang bersyarat dan apakah berakhir dengan 304 atau 200 penuh.

Buktikan respons bersyarat bekerja setelah perubahan

Uji representasi yang tidak berubah

Pengujian: ambil URL, salin ETag, lalu ulangi dengan curl -I -H 'If-None-Match: "VALUE"' URL. Hasil yang diharapkan: 304, validator yang cocok, dan tanpa body atau Location. Interpretasi kegagalan: server mengabaikan kondisi atau membuat validator tidak stabil. Jendela pemantauan: segera. Pemicu rollback: perubahan caching membuat permintaan biasa kehilangan respons 200 lengkap.

Uji representasi yang berubah

Pengujian: deploy perubahan konten nyata, lalu ulangi ETag lama. Hasil yang diharapkan: 200 dengan body terbaru dan validator baru. Interpretasi kegagalan: invalidasi cache basi. Jendela pemantauan: segera setelah deployment sampai ke setiap origin. Pemicu rollback: origin mana pun masih mengembalikan 304 untuk validator lama setelah rollout selesai.

Uji stabilitas multi-origin

Pengujian: ulangi permintaan normal dan bersyarat cukup sering untuk mencapai pool server, lalu catat ETag dan statusnya. Hasil yang diharapkan: representasi yang tidak berubah memakai validator yang kompatibel dan konsisten menghasilkan 304. Interpretasi kegagalan: validator berbeda menurut node atau encoding tanpa strategi Vary yang sesuai. Jendela pemantauan: segera, di seluruh pool yang dideploy. Pemicu rollback: logika validator baru menyajikan konten basi atau mencampur representasi antar-klien.

Ukur kesehatan cache bersyarat

Tingkat keberhasilan validasi ulang bersyarat

Metrik: permintaan bersyarat yang berakhir pada 304 dibandingkan dengan 200 penuh. Makna: apakah sumber daya yang tidak berubah menghindari transfer yang tidak perlu. Cara mengambil: kelompokkan permintaan log akses yang membawa If-None-Match atau If-Modified-Since berdasarkan status respons dan kelas URL. Benchmark/rentang realistis: buat baseline berdasarkan tipe konten; halaman yang sering berubah tidak boleh dipaksa mengikuti tingkat aset statis. Frekuensi: mingguan selama rollout, lalu bulanan.

Byte yang dihemat pada pengambilan tanpa perubahan

Metrik: perkiraan byte body respons yang tidak ditransfer untuk respons 304 yang valid. Makna: sisi bandwidth dari manfaat efisiensi crawl. Cara mengambil: gabungkan jumlah 304 dengan ukuran respons lengkap terbaru untuk kelas URL yang sama. Benchmark/rentang realistis: bandingkan dengan baseline situs sendiri sebelum perubahan; tidak ada target universal yang cocok untuk semua campuran konten. Frekuensi: bulanan.

Kegagalan validator basi

Metrik: URL yang berubah tetapi masih menerima validator lama. Makna: apakah efisiensi dibayar dengan hilangnya kesegaran. Cara mengambil: lakukan sampel kecil pascadeployment dengan mengulang ETag sebelum deployment. Benchmark/rentang realistis: setiap respons basi yang terkonfirmasi perlu diselidiki. Frekuensi: pada setiap deployment yang mengubah caching atau pembuatan validator.

Uji diri: 304 Tidak Diubah

Lima pertanyaan singkat tentang arti 304 dan cara kerjanya. Pilih jawaban untuk masing-masing, lalu periksa hasilnya.

Log perubahan