304 Değiştirilmedi

TL;DR — 304 Not Modified yanıtı, sunucunun “bunu zaten elinizde bulunduruyorsunuz — kopyanız hâlâ geçerli, tekrar indirmeyin” deme yoludur. Hata değildir ve 3xx “yönlendirme” ailesinde yer almasına rağmen kimseyi yeni bir URL’ye göndermez. Yalnızca istemci (tarayıcı veya tarayıcı) önce “son gelişimden beri değişti mi?” diye koşullu bir istek gönderdiğinde oluşur. SEO açısından sıralamanızı değiştirmez; ancak büyük sitelerde arama motorlarının kaynaklarını daha verimli kullanmasına yardımcı olabilir. “has this changed since last time?” (Türkçe çeviri) Bu ifade, makaledeki karar ağacının dayandığı resmi açıklamayı taşıyor.

304 aslında nedir

Sunucunuzun gönderdiği her yanıt üç haneli bir durum koduyla başlar. 200 OK, “gövdesiyle birlikte işte sayfa” demektir. 304 Not Modified daha özel bir anlama gelir: istemci koşullu bir istek yapmıştır — “bu sayfayı ver, ama yalnızca değiştiyse” demiştir — ve sunucu sayfanın değişmediğine karar vermiştir. Bu yüzden aksi halde göndereceği 200 yerine hiç gövde olmadan 304 yanıtı verir. Gerçek kural budur: 304 yalnızca koşulu yanlış sonuçlanan koşullu bir GET/HEAD isteğinin yanıtıdır.

“here’s the page, body and all.” (Türkçe çeviri) Bu ifade, istek yöntemi ve gövdesinin nasıl korunacağını vurgular. “give me this page, but only if it changed” (Türkçe çeviri) Bu kaynak cümlesi, kontrol listesindeki teknik gerekçeyi destekliyor.

Bunun tipik yolu ikinci ziyarettir ve zihinde canlandırmak için yararlıdır: tarayıcı veya tarayıcı bir sayfayı ilk kez getirdiğinde tam içerikle birlikte normal bir 200 ve birkaç küçük “parmak izi” başlığı alır. Sonraki ziyarette istemci bu parmak izini sunucuya gösterip “hâlâ aynı mı?” diye sorar. Hiçbir şey değişmediyse sunucu 304 döndürür, sayfa gövdesi göndermez ve istemci elindeki kopyayı kullanır. Ancak “ikinci ziyaret” örnektir, protokol kuralı değildir; 304’ü gerçekten tetikleyen şey, nasıl gelirse gelsin, koşullu isteğin kendisidir.

“Yönlendirme” ailesinde olup yönlendirme olmamasının nedeni

304, HTTP’nin yönlendirmeler için kullandığı sınıf olan 3 ile başlar. Bu, insanları sürekli yanıltır. Ancak 304’ün Location başlığı yoktur ve sizi farklı bir adrese göndermez; kimse hiçbir yere gitmez. Yalnızca istemciyi kendi kayıtlı kopyasına yöneltir. Dolayısıyla “yönlendirme ailesi” bir numaralandırma ayrıntısıdır, yaptığı iş değil.

304 sorun mudur?

Hayır. Tarayıcının ağ sekmesinde veya tarama raporunda 304 görmek önbelleğin çalıştığını gösterir; istediğiniz sonuç tam olarak budur. İnternetteki “304 hatası nasıl düzeltilir?” tavsiyelerinin çoğu bunu sizin tarafınızda bozuk bir şeymiş gibi ele alır. Bozuk değildir. İyi çalışan önbelleğin doğru, amaçlanan sonucudur.

SEO’ya yardımcı olur mu

Doğrudan sıralamanıza yardımcı olmaz. Google, sayfayı son taradığında içeriğinizi zaten almıştır; 304 yalnızca içeriğin değişmediğini doğrular ve Google elinde sakladığını kullanmaya devam eder (Search yine de bir URL’nin sinyallerini yeniden hesaplayabilir, ancak 304 tek başına sıralama veya dizine ekleme bonusu değildir). Yardım ettiği yer kaynak verimliliğidir: bir arama motorunun değişmemiş sayfaları yeniden indirmesi gerekmiyorsa iki taraf da bant genişliği ve işlem gücü tasarrufu sağlar; Google bunun taramanın dolaylı olarak daha verimli çalışmasına yardımcı olabileceğini söyler. Ancak tasarruf edilen çabanın yeni veya güncellenmiş sayfalarınıza otomatik olarak yönlendirileceği garanti edilmez. Bu, çok sayıda nadiren değişen sayfası olan büyük sitelerde en önemlidir.

Gerçek mekanizmayı — ETag’leri, If-None-Match’i, güçlü ve zayıf doğrulayıcıları, uygulama yöntemini ve Google’ın gerçekte ne söylediğini — istiyorsanız Advanced sekmesine geçin.

Kısa özet — 304, koşulu false olarak değerlendirilen ve aksi halde 200 alacak koşullu GET/HEAD isteğinin yanıtıdır (RFC 9110 §15.4.5). 3xx sınıfındadır ama yönlendirme değildir: Location yoktur, yeni URL yoktur ve normatif olarak gövde yoktur (“it cannot contain content or trailers” (çeviri) “içerik veya trailer barındıramaz”). Koşul, ETag ile karşılaştırılan If-None-Match ve/veya Last-Modified ile karşılaştırılan If-Modified-Since başlıklarıyla taşınır. Doğrulayıcı hâlâ eşleşiyorsa sunucu 304 döndürür, istemci önbelleğini yeniden kullanır. SEO etkisi: doğrudan sıralama etkisi yoktur; Google içerik elindeyken Search URL sinyallerini yine de yeniden hesaplayabilir. Büyük sitelerde kaynak tasarrufu sağlar (Google bunun tarama verimliliğini dolaylı artırabileceğini söyler; tarama bütçesinin başka URL’lere otomatik aktarılacağını vaat etmez). Google’ın tarama altyapısı iki doğrulayıcıyı da destekler ve tarih biçimi tuzağı olmadığı için öncelikle ETag önerir. URL’yi taşıyan 301/302/307/308 ve gerçekten gönderilecek hiçbir şey olmadığı için gövdesiz olan 204 ile karıştırmayın.

Spesifikasyonda 304’ün anlamı

RFC 9110 (HTTP Semantics) §15.4.5 kesin tanımı verir: “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.” (çeviri) “304 (Not Modified) durum kodu, koşullu GET veya HEAD isteğinin alındığını ve koşul false olarak değerlendirilmeseydi 200 (OK) yanıtıyla sonuçlanacağını belirtir.” Normatif tetikleyici budur: koşulu false olan ve aksi halde 200 alacak koşullu GET/HEAD. Basitçe istemci “bu sayfayı yalnızca değiştiyse ver” diye sorar; sunucu değişmediğini belirler ve gövdeyi göndermeyi atlar. “İkinci ziyaret”, istemcinin önceki yanıttan sakladığı doğrulayıcıyı eklemesiyle isteğin nasıl koşullu hale geldiğini anlatan günlük örnektir; kuralın kendisi değildir. Spesifikasyon önceki ziyareti değil, yalnızca koşullu isteği gerektirir. 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

Spesifikasyon bu bölümde “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” (çeviri) “sunucu bu nedenle istemciyi, saklanan temsili 200 (OK) yanıtının içeriğiymiş gibi kullanmaya yöneltir” ifadesini bile kullanır. Ancak dikkatle okuyun: istemciyi başka URL’ye değil, kendi önbelleğine geri yöneltir. Location başlığı ve yeni adres yoktur. 304’ün “yönlendirme olup olmadığı” karışıklığının çoğu bu cümleden doğar. HTTP anlamında yönlendirme değildir.

İki normatif nokta daha önemlidir:

• Asla gövde yoktur. RFC 9110: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (çeviri) “304 yanıtı başlık bölümünün sonunda biter; içerik veya trailer barındıramaz.” Gövde taşıyan 304 spesifikasyon ihlalidir ve bazı istemciler bunu yanlış işler. Bu katı kuraldır, biçem tercihi değil.
• 200’ün taşıyacağı meta veriyi taşır. Sunucu, aynı isteğe verilecek 200 (OK) yanıtında bulunacak şu başlıkları üretmek ZORUNDADIR: Content-Location, Date, ETag ve Vary; gerektiğinde Cache-Control ile Expires da eklenir. Yani 304, yükü çıkarılmış 200 başlıklarıdır.

304 gerçekte nasıl çalışır: koşullu istekler

Sunucu 304’ü kendiliğinden göndermez. Her zaman koşullu bir isteğe — istemcinin önceki yanıttan kaydettiği bir doğrulayıcıyı ekleyerek koşullu hale getirdiği isteğe — yanıt verir. İki doğrulayıcı vardır.

ETag ve If-None-Match

ETag (entity tag), sunucunun bir 200 yanıtına eklediği opak bir belirteçtir; bunu URL’nin tam o temsilinin sürüm parmak izi gibi düşünün. İstemci bu URL için sonraki istekte kaydettiği değeri If-None-Match başlığında geri gönderir. Sunucu karşılaştırır: mevcut ETag hâlâ eşleşiyorsa hiçbir şey değişmemiştir ve 304 döndürür; farklıysa yeni içerik ve yeni bir 200 ile yeni bir ETag gönderir.

Last-Modified ve If-Modified-Since

Tarih tabanlı alternatifte sunucu Last-Modified yanıtında 200 zaman damgasını gönderir. İstemci sonraki istekte bu değeri If-Modified-Since başlığıyla geri yollar; kaynak o zamandan beri değişmediyse sunucu 304 döndürür. Bu yöntem daha basit ama daha kabadır, çünkü hassasiyeti zaman damgasıyla sınırlıdır ve doğru HTTP-date biçimine duyarlıdır. İki doğrulayıcı da mevcutsa If-None-Match önceliklidir; bu durumda If-Modified-Since kararın belirleyicisi değildir.

Güçlü ve zayıf ETag’ler

Bu kontrol noktası, durum kodu yanıtı için yanıtın ne anlattığını ve ne anlatmadığını açıklar. ETag W/ ETag: W/"abc123" “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (Türkçe çeviri) Kaynak cümlesi, bu durum kodunun hangi koşulda kullanıldığını netleştiriyor. “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.” (Türkçe çeviri) Alıntı, yanıtın kapsamını ve beklenen istemci davranışını birlikte gösteriyor.

Tam el sıkışmanın aşamaları

1. İlk istek → sunucu içerikle birlikte 200 OK ve ETag ve/veya Last-Modified döndürür.
2. İstemci depolar: içeriği ve bu doğrulayıcıları.
3. Sonraki istek → istemci, saklanan değerlerle birlikte If-None-Match ve/veya If-Modified-Since gönderir.
4. Sunucu karar verir: değişmemiş → 304 Not Modified, gövde yok, istemci önbelleğini kullanır; değişmiş → yeni gövde ve yeni doğrulayıcılarla 200 OK.

Önbelleğe alma ve doğrulayıcıların tarama verimliliği kaldıracı olarak daha derin ele alınmasını — koşullu isteklerin tamamını ve tarama bütçesiyle bağlantısını — istiyorsanız bu eşlik eden bir konudur; bu makale durum kodu odaklı bakıştır.

304 ve SEO: sıralama etkisi yok, gerçek tarama verimliliği etkisi var

SEO hikâyesinin tamamı düşündüğünüzden dardır. 304’ün doğrudan sıralama etkisi yoktur. Google’ın durum kodlarının tarama ve dizine eklemeyi nasıl etkilediğine dair rehberi, dizine ekleme etkisini de sınırlar: Search URL sinyallerini yeniden hesaplayabilir, ancak bunun dışında 304 sayfanın dizine eklenme biçimini değiştirmez. Google önceki taramadan içeriğe zaten sahiptir; 304 hiçbir şeyin değişmediğini doğrular ve Google elindekini kullanmayı sürdürür. 304 döndürmenin sıralama bonusu yoktur.

304’ün sağladığı şey, tarama verimliliğini dolaylı artırabilecek kaynak tasarrufudur. Gary Illyes, Google’ın Aralık 2024 tarihli HTTP önbellekleme yazısında bunu şöyle anlattı: “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.” (çeviri) “Özellikle ayrı URL’ler altında nadiren değişen içeriğe sahip büyük bir siteniz varsa yerel önbelleğe izin vermek sitenizin daha verimli taranmasına yardımcı olabilir. Google’ın tarama altyapısı HTTP önbellekleme standardındaki sezgisel önbelleği; özellikle ETag yanıt/If-None-Match istek başlığı ve Last-Modified yanıt/If-Modified-Since istek başlığı üzerinden destekler.”

Bu uygulama notu, 304 yanıtı için uygulama sırasında izlenecek sinyalleri bir araya getirir. “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body,” (Türkçe çeviri) Bu alıntı, kodun geçici veya koşullu kullanım bağlamını açıklar. “your server doesn’t have to spend compute resources on actually generating content” (Türkçe çeviri) Bu kaynak cümlesi, kontrol listesindeki teknik gerekçeyi destekliyor. “doesn’t have to transfer the HTTP body” (Türkçe çeviri) Bu ifade, istek yöntemi ve gövdesinin nasıl korunacağını vurgular.

Büyük sitelerde neden daha önemlidir

Birkaç yüz sayfanız varsa bu büyük ölçüde teoriktir; Google sitenizin tamamını zaten rahatça tarar. Kazanç boyutla birlikte artar: yüz binlerce veya milyonlarca URL’si olan ve bunların çoğu nadiren değişen bir site, tarayıcılar değişmemiş olanların tümünü yeniden getirmeyi atlayabildiğinde maddi fayda görür. Google’ın yazısının hedeflediği kitle budur; dürüst çerçeveyi koruyun ve 304’ü küçük site taktiği olarak abartmayın.

ETag mi Last-Modified mi, “değişti” sayılan nedir

Google birincil doğrulayıcı olarak ETag önerir: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (çeviri) “Last-Modified değerinin aksine yapılandırılmış olmadığından hatalara daha az açık olduğu için ETag kullanmanızı önemle öneririz.” İkisini birlikte ayarlamak uygundur ve teşvik edilir. Last-Modified kullanırsanız tarih “must be formatted according to the HTTP standard” (çeviri) “HTTP standardına göre biçimlendirilmelidir”. Google “Weekday, DD Mon YYYY HH:MM:SS Timezone,” biçimini (ör. “Fri, 4 Sep 1998 19:15:56 GMT”) önerir; aksi halde başlık sessizce yok sayılabilir. Google, tarayıcıların ne zaman yeniden tarayacağına karar vermesine yardımcı olmak için Cache-Control başlığının max-age alanını ayarlamayı da önerir.

Bu açıklama, durum kodu yanıtı için okurun ilgili durumu güvenle doğrulamasına yardımcı olur. “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.” (Türkçe çeviri) Cümle, ilgili HTTP davranışının sınırlarını pratik bir dille özetliyor.

Googlebot ve Bingbot bunu gerçekte nasıl kullanır

Her tarayıcı isteği koşullu değildir. Google’ın tarayıcı dokümantasyonu, farklı Google tarayıcılarının ve getiricilerinin sundukları ürüne göre önbellek desteğinin değiştiğini belirtir — Googlebot Search için URL’leri yeniden tararken önbelleğe almayı desteklerken bazı diğer Google getiricileri bunu yalnızca belirli koşullarda destekler. Bu yüzden başlıklar doğru yapılandırılmış olsa bile isteklerin %100’ünde If-None-Match/If-Modified-Since bulunmasını beklemeyin. Bing açısından koşullu istekler yalnızca Google’a özgü değildir. Bing’in tarayıcısı, en azından 2008 tarihli Live Search blog yazısından beri koşullu GET’i ( If-Modified-Since ve mevcutsa If-None-Match göndererek, içerik değişmediğinde 304’ü kabul ederek) desteklemektedir; ancak Bing, Google’ın 2024 yazısına eşdeğer güncel bir yazı yayımlamamıştır. Mekanizmayı her iki motora da uygulanan genel HTTP davranışı olarak değerlendirin.

304 desteği nasıl uygulanır

1. 200 yanıtında doğrulayıcı gönderin. Sunucunuzu, CDN’inizi veya uygulamanızı normal 200 yanıtlarına ETag (önerilir) ve/veya doğru biçimlendirilmiş Last-Modified başlığı ekleyecek biçimde yapılandırın. Birçok sunucu ve framework statik dosyalarda ETag’i otomatik üretir; dinamik yanıtlarda çoğunlukla bunu açmanız gerekir.
2. Geri gelen koşullu başlıkları uygulayın. İstek If-None-Match/If-Modified-Since ile geldiğinde güncel doğrulayıcıyla karşılaştırın; eşleşiyorsa gövdesiz 304, eşleşmiyorsa yeni 200 döndürün. Statik dosya sunucuları bunu çoğunlukla yapar; uygulama rotaları ve edge worker’ları siz bağlamadıkça yapmayabilir.
3. “Değişti” tanımını belirleyin ve gerçekten değişmeyen içerikte ETag’i sabit tutun; yeniden sıkıştırma veya sunucular arası farkın gereksiz değişiklik yaratmasına izin vermeyin.
4. Klasik yanlış yapılandırmaları izleyin:
   • Her zaman 200 — doğrulayıcı hiç gönderilmez; istek koşullu olmaz ve verimlilik kazanılmaz.
   • Kararsız ETag’ler — içerik değişmediği halde değer değişir (yük dengeleyici, yeniden sıkıştırma) ve sürekli yeniden getirmeyi zorlar.
   • Bayat 304’ler — tehlikeli olan budur: içerik gerçekten değiştikten sonra da 304 (veya değişmemiş ETag) döndüren sunucu, tarayıcıların ve önbelleklerin güncellemeyi almasını engeller. Bu 304’ün özünde değil, günlük analizinde yakalanması gereken hatadır.

304 ve diğer durum kodları

304 ile 301 / 302 / 307 / 308

Bunlar gerçek yönlendirmelerdir. (Kalıcı) 301/308 veya (geçici) 302/307 bir Location başlığı taşır ve istemciyi farklı bir URL’ye götürür; ayrıca 301/308 canonicalization sinyali de aktarır. 304’ün Location’ı yoktur, kimseyi taşımaz ve hiçbir sıralama sinyali aktarmaz. Numarası aynı 3xx ailesinde olsa da işi tamamen farklıdır. Her kodun yönlendirme ayrıntıları kendi makalelerinde bulunur (301 yönlendirmesi yazısı ve yönlendirmeler alt merkezi).

304 ile 204 No Content

İkisi de gövdesizdir, ancak nedenleri tamamen farklıdır. 204 No Content, sunucunun gerçekten gönderecek hiçbir şeyi olmadığı için bilinçli olarak boş gövde taşıyan 2xx başarı yanıtıdır; başarılı API DELETE/PUT isteği veya analiz işareti buna örnektir. 304 de gövde göndermez, ancak gönderilecek şey olmadığı için değil; “zaten elinizde ve hâlâ geçerli” olduğu için. Karıştırmayın: sayfa URL’sindeki 204 dizine eklenebilir içerik olmadığı için soft 404 gibi ele alınabilir; 304 ise Google’ın zaten sahip olduğu içerik için geçerlilik onayıdır. 204 No Content makalesi bu kodu ayrıntılı ele alır.

304 hakkında yaygın efsaneler

1. “304 yönlendirmedir.” Location başlığı yoktur, kimse başka yere gitmez. İstemci kendi önbelleğini kullanır. RFC 9110’daki “redirecting the client to make use of that stored representation” (çeviri) “istemciyi saklanan temsili kullanmaya yöneltme” ifadesi başka URL’yi değil önbelleği işaret eder.
2. “304 düzeltmem gereken hatadır.” Çalışan koşullu istek düzeninin doğru, amaçlanan sonucudur. Tarama veya DevTools’ta 304 görmek önbelleğin çalıştığını gösterir; SERP’teki en yaygın yanlış anlamadır.
3. “304 sıralamaya yardımcı olur.” Doğrudan sıralama etkisi yoktur. Google dizine ekleme etkisini de sınırlar: Search URL sinyallerini yeniden hesaplayabilir, ancak 304 bunun dışında dizine eklemeyi değiştirmez. Google bunun büyük sitelerde tarama verimliliğini dolaylı artırabileceğini söyler; bu sıralama sinyali değildir ve tasarrufun başka URL’lere aktarılacağını garanti etmez.
4. “If my server returns 304, Google will use stale content forever.” (çeviri) “Sunucum 304 döndürürse Google bayat içeriği sonsuza dek kullanır.” 304 yalnızca doğrulayıcı eşleşirken döner. İçerik değiştiği anda doğru yapılandırılmış sunucu yeni doğrulayıcılarla 200 döndürür. Gerçek risk, içerik değiştikten sonra da 304 veren yanlış yapılandırılmış sunucudur; bu 304’ün özelliği değil, hatadır. 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 ile Last-Modified birbirinin aynıdır.” İkisi de doğrulayıcıdır; ancak Last-Modified tarih biçimine duyarlıdır ve zaman damgası kadar ayrıntılıdır. ETag saydam olmayan kesin bir değerdir; dikkatsiz uygulanırsa sunucular veya yeniden sıkıştırma arasında farklılaşabilir. Google ETag’i birincil, mümkünse ikisini birlikte önerir.

SSS

HTTP 304 bir hata mıdır? Hayır — önbelleğe almanın çalıştığını gösteren bir başarı sinyalidir. İstemcinin önbelleğe alınmış kopyasının hâlâ geçerli olduğu anlamına gelir.

304 Not Modified bir yönlendirme midir? Hayır. Numaralandırma bakımından 3xx sınıfındadır; ancak Location başlığı yoktur ve istemciyi yeni bir URL’ye taşımaz.

304 SEO’ya veya sıralamaya yardımcı olur mu? Doğrudan sıralama etkisi yoktur ve Google’ın bir URL’nin sinyallerini yeniden hesaplaması dışında dizine ekleme etkisi yoktur. Tarayıcıların değişmemiş sayfaları atlamasını sağlayarak bant genişliği ve işlem gücü tasarrufu yapar; Google bunun büyük sitelerde tarama verimliliğini dolaylı olarak iyileştirebileceğini söyler.

ETag ile Last-Modified arasındaki fark nedir? ETag, If-None-Match üzerinden eşleştirilen opak bir sürüm parmak izidir; Last-Modified, If-Modified-Since üzerinden eşleştirilen bir zaman damgasıdır. Google, hataya daha az yatkın olduğu için ETag’i önerir.

Zayıf ve güçlü ETag arasındaki fark nedir? Güçlü ETag baytları aynı olan içeriği ifade eder; W/ önekli zayıf ETag, sıkıştırma veya alt bilgi tarihindeki değişiklik gibi önemsiz farklara tolerans göstererek anlamsal eşdeğerliği ifade eder.

Bu kontrol noktası, durum kodu yanıtı için protokol ayrımını gerçek bir kullanım kararıyla ilişkilendirir.

Sunucumu 304’ü doğru döndürecek şekilde nasıl yapılandırırım? ETag yanıtında Last-Modified/200 gönderin; sonraki istekte If-None-Match/If-Modified-Since başlıklarını dikkate alın ve doğrulayıcı hâlâ eşleşiyorsa gövdesiz 304 döndürün.

304 ile 204 arasındaki fark nedir? İkisi de gövdesizdir; 204 gönderilecek hiçbir şey olmadığı için, 304 ise zaten hâlâ geçerli bir kopyaya sahip olduğunuz için gövdesizdir.

Googlebot her istekte koşullu başlıklar gönderir mi? Hayır — önbellek desteği tarayıcıya göre değişir; bu nedenle başlıklar yapılandırılmış olsa bile her istek koşullu olmaz.

304 yanıtının gövdesi olabilir mi? Hayır. RFC 9110’a göre “it cannot contain content or trailers.” (çeviri) “İçerik veya trailer barındıramaz.” Gövdeli 304 spesifikasyon ihlalidir.

Yapay zekâ özeti

Advanced sürümün kısa özeti:

• 304 Not Modified, koşulu false olarak değerlendirilen ve aksi halde 200 alacak koşullu GET/HEAD isteğinin yanıtıdır (RFC 9110 §15.4.5). 3xx sınıfındadır ama yönlendirme DEĞİLDİR: Location başlığı, yeni URL ve normatif olarak gövde yoktur: “it cannot contain content or trailers” (çeviri) “içerik veya trailer barındıramaz”. İkinci ziyaret, isteğin nasıl koşullu hale geldiğine tipik örnektir; protokol kuralı değildir.
• Koşullu isteğin yanıtıdır. ETag ile karşılaştırılan If-None-Match ve/veya Last-Modified ile karşılaştırılan If-Modified-Since taşıyan GET/HEAD. Doğrulayıcı eşleşiyorsa sunucu 304 döndürür ve istemci önbelleğini kullanır.
• Spesifikasyondaki “redirecting” sözcüğü mecazdır: istemciyi başka URL’ye değil kendi önbelleğine yöneltir. “304 yönlendirme mi?” karışıklığının çoğu bu cümleden doğar.
• ETag ile Last-Modified: ETag, If-None-Match ile eşleşen saydam olmayan sürüm belirtecidir; Last-Modified, If-Modified-Since ile eşleşen tarihtir ve tam HTTP tarih biçimi gerektirir. İkisi varsa If-None-Match önceliklidir. Güçlü ETag bayt düzeyinde aynı; zayıf ETag (W/ öneki) anlamsal eşdeğer demektir.
• Doğrudan sıralama etkisi yoktur; Google’ın URL sinyallerini yeniden hesaplayabilmesi dışında dizine ekleme etkisi de yoktur. Google içeriğe sahiptir; 304 değişmediğini doğrular. Gary Illyes’in ifadesiyle önbellekleme “may help your site be crawled more efficiently” (çeviri) “sitenizin daha verimli taranmasına yardımcı olabilir”. Büyük sitelerde tarama verimliliğini dolaylı artırabilecek kaynak tasarrufudur; tarama bütçesinin kesin aktarımı veya sıralama sinyali değildir.
• Google öncelikle ETag önerir (“less prone to errors and mistakes” (çeviri) “hata ve yanlışlara daha az açıktır”); ikisini birlikte kullanabilirsiniz. Last-Modified, “Weekday, DD Mon YYYY HH:MM:SS Timezone,” biçiminde olmalıdır. Önbelleği yalnızca önemli içerik değişikliklerinde geçersiz kılın; altbilgideki telif tarihinde değil.
• Önbellek desteği tarayıcıya göre değişir: her Googlebot isteği koşullu değildir. Bing, 2008 tarihli Live Search yazısından beri koşullu GET destekler; bu genel HTTP davranışıdır.
• 301/302/307/308 ile karıştırmayın: bunlar URL’yi taşıyan gerçek yönlendirmelerdir. 204 No Content da gövdesizdir, ancak gerçekten gönderilecek hiçbir şey olmadığı için.
• Gerçek risk 304 değil, yanlış yapılandırmadır: içerik değiştikten sonra 304 döndüren sunucuyu günlük analizinde yakalayın. Geçerli 304, hiçbir şey yanlış olmadığı halde bazı istemci kütüphanelerinde veya platform önbelleğinde hata gibi görünebilir.

Resmî dokümantasyon

304’ün ne olduğu ve arama motorlarının onu nasıl kullandığına dair birincil kaynaklar.

HTTP spesifikasyonu ve tarayıcı referansı

• RFC 9110 §15.4.5 — 304 Değiştirilmedi — belirleyici tanım: koşullu istek, gövde yok, zorunlu başlıklar.
• MDN — 304 Değiştirilmedi — sade anlatım, If-None-Match/If-Modified-Since tetikleyicisi ve 304’ün taşıması gereken başlıklar.
• MDN — HTTP koşullu istekleri — güçlü ve zayıf doğrulama açıklaması.
• MDN — ETag — zayıf (W/) ve güçlü söz dizimi dahil ETag başlığı.

Google Search Central

• Crawling December: HTTP caching — Gary Illyes’in 9 Aralık 2024 yazısı: ETag/If-None-Match ile Last-Modified/If-Modified-Since başlıklarının 304’ü nasıl ürettiği ve tarama verimliliğine katkısı.
• Google tarayıcılarına (User Agent) genel bakış — önbelleği destekleyen Google tarayıcıları ve ETag’in Last-Modified’a tercih edilmesi.
• HTTP durum kodları Google tarayıcılarını nasıl etkiler? — Search’ün URL sinyallerini yeniden hesaplayabilmesine rağmen 304’ün başka dizine ekleme etkisi olmadığını belirten güncel satır.
• Google Arama tarama hatalarını giderme — koşullu isteklerin kaynak tasarrufunun tarama verimliliğini “may indirectly” (çeviri) “dolaylı olarak artırabileceği” ve Google’ın her taramada koşullu başlık göndermediği ifadelerinin kaynağı.

Bing

• Live Search için tarayıcı iyileştirmelerinin duyurulması — koşullu GET desteğini (If-Modified-Since/If-None-Match → 304) 2008’den beri doğrulayan eski Bing/Live Search yazısı.

Kaynaktan alıntılar

Kayıt altına alınmış açıklamalar. Her bağlantı, kaynağın desteklediği alıntılanan bölüme atlayan bir derin bağlantıdır.

HTTP spesifikasyonu

• “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.” (çeviri) “304 (Not Modified) durum kodu, koşullu GET veya HEAD isteğinin alındığını ve koşul false olmasaydı 200 (OK) yanıtı doğuracağını belirtir.” — RFC 9110, HTTP Semantics, §15.4.5. Bölümü oku
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (çeviri) “304 yanıtı başlık bölümünün sonunda biter; içerik veya trailer barındıramaz.” — RFC 9110, §15.4.5 (normatif “asla gövde yok” kuralı). Bölümü oku

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (çeviri) “HTTP 304 Not Modified yönlendirme yanıtı durum kodu, istenen kaynakları yeniden aktarmaya gerek olmadığını belirtir.” Alıntıya git
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (çeviri) “Güçlü doğrulama, kaynağın karşılaştırıldığı kaynakla bayt düzeyinde aynı olduğunu garanti eder.” — MDN, “HTTP conditional requests”. Rehberi oku

Gary Illyes, Google — “Crawling December: HTTP caching” (9 Aralık 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.” (çeviri) “Özellikle ayrı URL’ler altında nadiren değişen içeriğe sahip büyük siteniz varsa yerel önbelleğe izin vermek sitenizin daha verimli taranmasına yardımcı olabilir. Google’ın tarama altyapısı, özellikle ETag yanıt/If-None-Match istek başlığı ve Last-Modified yanıt/If-Modified-Since istek başlığıyla HTTP standardındaki sezgisel önbelleği destekler.” Yazıyı oku
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (çeviri) “Last-Modified değerinin aksine yapılandırılmış olmadığından hatalara daha az açık olduğu için ETag kullanmanızı önemle öneririz.” Yazıyı oku
• “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.” (çeviri) “Tarayıcının gönderdiği ETag değeri sunucunun ürettiği güncel değerle eşleşirse sunucunuz HTTP gövdesi olmadan HTTP 304 (Not modified) durum kodu döndürmelidir.” Yazıyı oku
• “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.” (çeviri) “Önerimiz, içeriğinizdeki önemli değişikliklerde önbellek yenilemesi istemenizdir; yalnızca sayfanın altındaki telif tarihini güncellediyseniz bu muhtemelen önemli değildir.” Yazıyı oku

Ahrefs’ten Patrick Stox

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (çeviri) “304 Not Modified — sayfanın değiştirilmediğini söyler. Genellikle önbellekleme için kullanılır.” — HTTP Durum Kodları ve SEO Etkileri rehberimden (bu makale, o kısa girdinin ayrıntılı incelemesidir). Alıntıya git

304 bağlamında: karıştırıldığı gövdesiz ve 3xx kodları

304 ve benzer görünen kodlar

Tuzak şudur: 304 ve 204 ikisi de gövdesizdir; 304/301/302/307/308 ise 3xx’tir. Ancak 304 her iki eksende de istisnadır. Kimseyi taşımayan tek 3xx’tir ve “gönderilecek hiçbir şey yok” değil, “buna zaten sahipsiniz” anlamına gelen tek gövdesiz koddur. “you already have it” (Türkçe çeviri) Bu kaynak ifadesi, operasyonel kontrolün hangi sinyalle yapılacağını vurguluyor. “there’s nothing to send.” (Türkçe çeviri) Alıntı, koşullu yanıtın veya hata durumunun doğru yorumunu koruyor.

İki doğrulayıcı

İkisi de mevcut olduğunda If-None-Match, If-Modified-Since’a göre önceliklidir.

Hızlı bilgiler

• 304’ün asla gövdesi yoktur — RFC 9110 bunu normatif kılar.
• 304 bir 3xx kodudur ama yönlendirme değildir (Location yoktur, yeni URL yoktur).
• Doğrudan sıralama etkisi yoktur ve Google’ın bir URL’nin sinyallerini yeniden hesaplaması dışında dizine ekleme etkisi yoktur; fayda büyük sitelerde tarama verimliliğine dolaylı olarak yardımcı olabilecek kaynak tasarrufudur.
• Google birincil olarak ETag’i önerir; ETag ve Last-Modified’ın ikisini de ayarlamak uygundur.
• Last-Modified, “Weekday, DD Mon YYYY HH:MM:SS Timezone” biçimini kullanmalıdır; aksi halde yok sayılabilir.
• Önbelleği alt bilgideki telif hakkı yılı gibi değil, esaslı içerik değişikliklerinde geçersiz kılın.
• Her tarayıcı isteği koşullu değildir — önbellek desteği tarayıcıya göre değişir.
• Bing, koşullu GET → 304’ü 2008’den beri desteklemektedir; bu genel HTTP davranışıdır.
• Asıl risk bayat 304’tür (içerik değiştikten sonra sunucunun 304 döndürmesi); bunu günlük analizinde yakalayın.

Ham HTTP’de koşullu istek el sıkışması

304’ün nasıl oluştuğunu gösteren somut istek/yanıt zincirleri. (Başlık değerleri örnektir.)

ETag / If-None-Match — ilk getirme (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>

İstemci gövdeyi ve ETag değerini saklar.

ETag / If-None-Match — sonraki getirme, içerik değişmedi (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

Gövde yoktur. ETag eşleştiği için sunucu sayfayı oluşturma işleminden ve gönderme bant genişliğinden tasarruf etti. İstemci önbelleğe alınmış kopyasını kullanır.

Last-Modified / If-Modified-Since — tarih tabanlı eşdeğer

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

Tam HTTP-date biçimine dikkat edin — “Weekday, DD Mon YYYY HH:MM:SS Timezone” — Google, ayrıştırma sorunlarından kaçınmak için bunu önerir.

İçerik DEĞİŞTİĞİNDE — 304 değil, yeni 200

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>

Saklanan ETag artık eşleşmez; bu nedenle sunucu yeni içeriği ve yeni bir doğrulayıcıyı gönderir. Önbellek güncellenir. Doğru uygulanmış 304’ün tarayıcıyı bayat içeriğe “hapsedememesinin” nedeni tam olarak budur: içerik değiştiği anda doğrulayıcı değişir ve sonraki istek gerçek bir 200 alır.

Zayıf ve güçlü ETag

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

Pratik kural: Çok sayıda ve seyrek değişen URL’si olan büyük bir site işletiyorsanız, ETag yanıtlarında kararlı bir If-None-Match göndermek ve 200 değerini kabul etmek, tarayıcıların ucuz ve gövdesiz bir 304 ile “hâlâ aynı” doğrulaması yapmasını sağlar. Google, bunun sitenin geri kalanının taranma verimliliğini dolaylı olarak artırabilecek bant genişliği ve işlem tasarrufu sağlayabileceğini söyler. ETag her yeniden sıkıştırmada veya yük dengelemeli sunucular arasında değişirse bu avantaj kaybolur.

Koşullu önbelleğe almayı bozan 304 hataları

Temsil değişmediğinde ETag’i değiştirmek

Bir sunucu örneğine, sıkıştırma geçişine veya istek zaman damgasına bağlı ETag doğrulayıcıyı bozar: değişmemiş içerik tam bir 200 döndürmeye devam eder. Temsilden sabit bir doğrulayıcı üretin veya bayt düzeyindeki farklar anlamlı değilse bilerek zayıf ETag kullanın.

İçerik değiştikten sonra 304 döndürmek

Bayat bir doğrulayıcı gerçek bir güncellemeyi istemcilerden ve tarayıcılardan gizleyebilir. Temsil değiştiğinde ETag’i geçersiz kılın veya Last-Modified değerini ilerletin; ardından eski koşullu isteğin yeni bir 200 ve gövde aldığını doğrulayın.

Eşleşen koşullu istek olmadan 304 göndermek

Sunucu, istemcinin önbelleğe alınmış bir kopyası olduğunu varsaymamalıdır. 304 veya If-None-Match değerlendirildikten sonra If-Modified-Since döndürülür; sıradan ilk istek ise tam bir yanıt gerektirir.

304’ü yönlendirme veya boş sayfa gibi ele almak

304’ün Location başlığı ve yanıt gövdesi yoktur. Onu yönlendirme mantığından geçirmeyin ve gerçek bir boş kaynağı 304 ile değiştirmeyin; gerçek yanıtı açıklayan durumu kullanın.

Yaygın 304 sorunları

Sunucu her zaman 200 döndürüyor

Belirti: hiçbir şey değişmese bile yinelenen istekler tam gövdeyi indiriyor. Olası neden: ilk yanıtta doğrulayıcı yok veya uygulama koşullu istek başlıklarını yok sayıyor. Düzeltme: ETag ve/veya geçerli bir Last-Modified gönderin, ardından eşleşen If-None-Match veya If-Modified-Since kontrolünü uygulayın. Değişmemiş bir isteğin gövdesiz 304 döndürdüğünü doğrulayın.

Farklı kaynak sunucuları farklı ETag’ler üretiyor

Belirti: aynı değişmemiş URL, yük dengeleyicinin arkasında 200 ve 304 arasında gidip geliyor. Olası neden: her düğüm kendi doğrulayıcısını üretiyor. Düzeltme: ETag’i hizmet veren düğümden değil, paylaşılan içerik durumundan türetin ve aynı koşullu isteği çeşitli yanıtlar üzerinde tekrarlayın.

Güncellenen içerik hâlâ 304 döndürüyor

Belirti: bir tarayıcı veya tarayıcı dağıtımdan sonra eski temsili kullanmaya devam ediyor. Olası neden: doğrulayıcı içerikle birlikte geçersiz kılınmadı. Düzeltme: önbellek anahtarını veya dağıtım mantığını düzeltin, gerektiğinde etkilenen önbelleği temizleyin ve eski ETag’in artık yeni doğrulayıcıyla 200 aldığını kanıtlayın.

Last-Modified yok sayılıyor gibi görünüyor

Belirti: If-Modified-Since hiç 304 üretmiyor. Olası neden: geçersiz HTTP-date, yetersiz zaman damgası hassasiyeti veya ETag’in öncelikli olması. Düzeltme: ham başlıkları inceleyin, tarih biçimini düzeltin ve doğrulayıcıları bağımsız biçimde sınayın.

Bir 304 uygulama kodunda hata gibi görünüyor

Belirti: gerçekte 304 alan bir istekte betik veya uygulama istisna fırlatır ya da “hata” kaydeder. Olası neden: bazı HTTP istemci kütüphaneleri, yönlendirmeleri izleyecek veya not-modified yanıtlarına izin verecek biçimde açıkça yapılandırılmadıkça geçerli 304 dahil 200 dışındaki her durumu istisna gibi ele alır. Bu protokol veya sunucu sorunu değil, istemci kütüphanesi özelliğidir. Çözüm: yalnızca 4xx/5xx hata işlemesini değil, kütüphanenin 304’ü özel olarak nasıl ele aldığını kontrol edin ve sunucuyu suçlamadan önce ham HTTP yanıtının doğru, gövdesiz 304 olduğunu doğrulayın.

Bir platform önbellekleme katmanı (ör. IIS çıktı önbelleklemesi) resmi bulanıklaştırıyor

Belirti: kaynak uygulama doğru görünüyor, ancak 304 davranışı hâlâ yanlış görünüyor. Olası neden: IIS çıktı önbelleklemesi gibi barındırma platformuna özgü bir önbellekleme katmanı, uygulama ile istemci arasında durur ve 304 yanıtlarını kendi başına üretebilir veya yakalayabilir. Düzeltme: bunu varsayılan şüpheli değil, çeşitli katmanlardan (kaynak uygulama, CDN, yük dengeleyici, platform önbelleği) biri olarak ele alın; hangi katmanın sorumlu olduğu sonucuna varmadan önce her katmandaki doğrulayıcıyı kontrollü bir testte sırayla değiştirerek izole edin.

İstemci koşullu istek izini denetleme komutu

İlk getirmeden ve tekrarlanan getirmeden gelen istek ve yanıt başlıklarını yapıştırın.

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]

ETag uygulamasını inceleme komutu

İlgili uygulama, CDN veya sunucu yapılandırmasını yapıştırın.

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: ETag’i koşullu istek olarak yeniden oynatma

Bunu macOS/Linux terminalinde çalıştırın. Tırnak işaretleri dahil ETag’i aynen kopyalayın.

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"

İlk yanıt doğrulayıcıyı göstermelidir. İkinci yanıt, temsil değişmemişse 304, yapıştırılan ETag bayatsa 200 döndürmelidir.

PowerShell: Last-Modified’ı test etme

URL’yi ve zaman damgasını değiştirdikten sonra bunu PowerShell’de çalıştırın.

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

DevTools Console: sayfa kaynak doğrulayıcılarını listeleme

Bunu tarayıcının Console’unda çalıştırın. Kaynak zamanlama girdilerini raporlar; gerçek ETag, Last-Modified ve durum başlıklarını incelemek için Network panelini kullanın.

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

304 davranışını inceleme araçları

• HTTP Header Checker: doğrulayıcıyı yeniden oynatmadan önce normal yanıtta ETag, Last-Modified, Cache-Control, Vary ve CDN/edge parmak izlerini inceleyin.
• Tarayıcı DevTools Network paneli: “Disable cache” seçeneğini kapatın, yeniden yükleyin ve istek/yanıt başlıklarını karşılaştırın. DevTools ayrıca HSTS ve yerel önbellek davranışını görünür kılar; tarayıcı davranışını kaynağın gönderdiğinden ayırın.
• curl: tarayıcının önbellek durumu araya girmeden tam bir If-None-Match veya If-Modified-Since başlığı gönderin.
• Erişim günlükleri: hangi tarayıcı isteklerinin koşullu olduğunu ve 304 veya tam 200 ile sonuçlanıp sonuçlanmadığını ölçün.

Değişiklikten sonra koşullu yanıtların çalıştığını kanıtlayın

Değişmemiş temsil testi

Çalıştırılacak test: URL’yi getirin, ETag’ini kopyalayın, ardından curl -I -H 'If-None-Match: "VALUE"' URL ile tekrarlayın. Beklenen sonuç: 304, eşleşen doğrulayıcı ve gövde veya Location yok. Başarısızlık yorumu: sunucu koşulu yok saydı veya kararsız bir doğrulayıcı üretti. İzleme penceresi: hemen. Geri alma tetikleyicisi: önbellekleme değişikliği sıradan isteklerin eksiksiz 200 yanıtını kaybetmesine neden olur.

Değişmiş temsil testi

Çalıştırılacak test: gerçek bir içerik değişikliği dağıtın, ardından eski ETag’i yeniden oynatın. Beklenen sonuç: güncel gövde ve yeni doğrulayıcıyla 200. Başarısızlık yorumu: önbellek geçersiz kılma işlemi bayat. İzleme penceresi: dağıtım her kaynağa ulaştıktan hemen sonra. Geri alma tetikleyicisi: dağıtım tamamlandığı hâlde herhangi bir kaynak eski doğrulayıcı için hâlâ 304 döndürür.

Çoklu kaynak kararlılığı testi

Çalıştırılacak test: hizmet havuzuna ulaşacak kadar aynı normal ve koşullu istekleri tekrarlayın; ETag’i ve durumu kaydedin. Beklenen sonuç: değişmemiş temsiller uyumlu doğrulayıcılar kullanır ve tutarlı biçimde 304 üretir. Başarısızlık yorumu: eşleşen bir Vary stratejisi olmadan doğrulayıcılar düğüme veya kodlamaya göre değişir. İzleme penceresi: dağıtılan havuz genelinde hemen. Geri alma tetikleyicisi: yeni doğrulayıcı mantığı bayat içerik sunar veya istemciler arasında temsilleri karıştırır.

Koşullu önbellek sağlığını ölçün

Koşullu yeniden doğrulama başarı oranı

Metrik: tam 304 ile karşılaştırıldığında 200 ile sonuçlanan koşullu istekler. Size söylediği: değişmemiş kaynakların gereksiz aktarımlardan kaçınıp kaçınmadığı. Nasıl alınır: If-None-Match veya If-Modified-Since taşıyan erişim günlüğü isteklerini yanıt durumu ve URL sınıfına göre gruplayın. Karşılaştırma / gerçekçi aralık: içerik türüne göre temel durum belirleyin; sık değişen sayfalar statik varlıkların oranına zorlanmamalıdır. Sıklık: dağıtım sırasında haftalık, sonra aylık.

Değişmemiş getirmelerde önlenen baytlar

Metrik: geçerli 304 yanıtları için aktarılmayan tahmini yanıt gövdesi baytları. Size söylediği: tarama verimliliği faydasının bant genişliği tarafı. Nasıl alınır: 304 günlük sayılarını aynı URL sınıfı için en son eksiksiz yanıt boyutuyla birleştirin. Karşılaştırma / gerçekçi aralık: sitenin kendi değişiklik öncesi temel durumuyla karşılaştırın; her içerik karışımı için evrensel hedef yoktur. Sıklık: aylık.

Bayat doğrulayıcı hataları

Metrik: eski bir doğrulayıcıyı hâlâ kabul eden değişmiş URL’ler. Size söylediği: verimliliğin güncellik pahasına gelip gelmediği. Nasıl alınır: dağıtım öncesi ETag’leri yeniden oynatan küçük bir dağıtım sonrası örneği çalıştırın. Karşılaştırma / gerçekçi aralık: doğrulanmış her bayat yanıt araştırma gerektirir. Sıklık: önbellekleme veya doğrulayıcı üretimini değiştiren her dağıtım.

Kendinizi sınayın: 304 Not Modified

304’ün ne anlama geldiği ve nasıl çalıştığı hakkında beş kısa soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Değişiklik günlüğü