Koşullu İstekler: ETag, If-Modified-Since ve 304 Not Modified

TL;DR — Koşullu istek, Googlebot’un sayfayı yeniden indirmeden önce sunucunuza “Bu sayfa, onu son aldığımdan beri değişti mi?” diye sormasıdır. Yanıt hayırsa sunucunuz, sayfa gövdesi içermeyen küçük bir 304 Not Modified yanıtı gönderir ve tarayıcı elindeki kopyayı yeniden kullanır. Bu, her iki tarafın da iş yükünü azaltır — ancak yalnızca büyük sitelerde anlamlı ölçüde fayda sağlar ve sıralamanızı yükseltmez.

Koşullu istek nedir?

Normalde Googlebot bir sayfayı istediğinde sayfanın tamamını indirir. Koşullu istek daha akıllı çalışır: tarayıcı, “yalnızca son ziyaretimden bu yana gerçekten değiştiyse sayfayı gönder” der.

Bunu, önceki taramadan hatırladığı küçük bir ek bilgiyle yapar:

• Bir tarih — “Bu sayfayı son aldığımda en son şu tarihte değiştirildiğini söylemiştin. Daha yeni bir şey var mı?”
• Bir parmak izi — “Geçen sefer bu sayfaya bir kimlik (bir ETag) vermiştin. Bu kimlik hâlâ aynı mı?”

Hiçbir şey değişmediyse sunucunuz 304 Not Modified yanıtını verir. Bu yanıta bir sayfa eklenmez — yalnızca “öncekiyle aynı” anlamına gelen kısa bir mesajdır. Ardından Googlebot her şeyi yeniden indirmek yerine son sefer kaydettiği kopyayı kullanır.

Bir şey gerçekten değiştiyse sunucunuz her zamanki gibi tam sayfayı (bir 200 OK) gönderir ve tarayıcı yeni kopyayı alır.

Bu neden önemseniyor?

Çoğunlukla hiç değişmeyen bir milyon ürün sayfasına sahip dev bir çevrimiçi mağaza düşünün. Koşullu istekler olmadan Googlebot her dönüşünde bunların tümünü yeniden indirir — geçen haftayla aynı olan sayfalar için muazzam miktarda bant genişliği ve sunucu işi boşa gider. Koşullu isteklerle bu ziyaretlerin çoğu küçük bir “hiçbir şey değişmedi” yanıtı alır; tarayıcı da zamanını gerçekten değişen veya yepyeni sayfalara ayırabilir.

Bütün fayda bundan ibarettir: verimlilik. Bu, tarama bütçenizin — bir arama motorunun sitenizde yapmaya istekli olduğu tarama miktarının — bir parçasıdır.

Dürüst uyarı

Heyecanlanmadan önce bilmeniz gereken iki şey var:

1. Bu, çoğunlukla büyük siteler için önemlidir. Küçük bir sitede tasarruf çok azdır ve genellikle kurulum zahmetine değmez. Daha önce yazdığım gibi, küçük web siteleri için bir 304 yanıtının sunduğu önbellekleme olanağı “not that crucial.”
2. Sıralamalarınızı iyileştirmez. Daha verimli tarama sizi sonuçlarda yukarı taşımaz — yalnızca büyük sitelerin yeni ve değişen sayfalarının biraz daha hızlı taranmasına yardımcı olur.

Tam başlıkları, Google’ın desteklediğini gerçekten söylediği şeyleri, sitelerin bunu fark ettirmeden bozduğu üç yolu ve bunun tarama hızı ile tarama sıklığından nasıl ayrıldığını mı öğrenmek istiyorsunuz? İleri Düzey sekmesine geçin.

TL;DR — Koşullu istekler, Googlebot’un bir sayfayı yeniden indirmek yerine önbellekteki kopyayı doğrulamasını sağlar. If-Modified-Since (Last-Modified başlığınıza göre doğrulanır) ve/veya If-None-Match (ETag değerinize göre doğrulanır) gönderir; hiçbir şey değişmediyse sunucunuz gövdesiz bir 304 Not Modified döndürür ve tarayıcı kopyasını yeniden kullanır — tam bir sayfa için 100 KB+ yerine kabaca ~1 KB. Her ikisi de mevcutsa ETag önceliklidir; Google, tarih biçimlendirme tuzakları bulunmadığı için ETag önerir ancak ikisinin de ayarlanmasını söyler. Google başlıkları her taramada göndermez (kullanım durumuna bağlıdır — AdsBot’un gönderme olasılığı daha yüksektir), koşullu başlık olmadan da proaktif olarak 304 sunabilirsiniz ve bir 304, indeksleme sinyallerini dondurmaz. Üç yanlış yapılandırma bunu etkisiz kılar: her zaman 200 döndürmek, değişken ETag değerleri (zaman damgaları, istek başına belirteçler, CDN düğümleri arasındaki farklılıklar) ve gerçek değişiklikleri izlemeyen bir Last-Modified. Bu, büyük sitelere yönelik bir tarama verimliliği aracıdır — sıralama faktörü değildir; tarama hızından, sıklığından ve bütçesinden farklıdır. Evidence for this claim Google may send If-Modified-Since or If-None-Match, but a site must not assume every crawler request will contain either conditional header. Scope: official protocol/provider documentation and production verification Confidence: high · Verified: 2026-07-18 Troubleshoot Google Search crawling errors

Mekanizmanın tam işleyişi

Tarama hızı Googlebot’un sayfaları ne kadar hızlı getirdiğini, tarama sıklığı ise ne sıklıkta geri döndüğünü ifade eder. Koşullu istekler, her bir yeniden taramaya ne kadar düşük maliyetle yanıt verilebildiğiyle ilgilidir. Tarayıcı ile sunucunuz arasında iki HTTP başlığı çiftine dayanan bir doğrulama el sıkışmasıdır:

Adım adım akış şöyledir:

1. İlk taramada sunucunuz sayfayı 200 OK ile birlikte bir Last-Modified tarihi ve/veya ETag parmak iziyle döndürür.
2. Daha sonraki bir taramada Googlebot, son gördüğü tarihi geri ileten If-Modified-Since ve/veya ETag değerini geri ileten If-None-Match gönderebilir.
3. Sunucunuz bunları denetler. İlgili hiçbir şey değişmediyse yanıt gövdesi olmadan 304 Not Modified döndürür — yalnızca durum ve başlıklar gönderilir.
4. Googlebot son taradığı sürümü yeniden kullanır. İçerik gerçekten değiştiyse sunucunuz tam gövdeyle 200 OK döndürür.

Google bu el sıkışmasını neredeyse kelimesi kelimesine şöyle belgeliyor: “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. 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.” Evidence for this claim Google documents heuristic HTTP caching and support for ETag and Last-Modified validators for crawlers that support caching. Scope: official protocol/provider documentation and production verification Confidence: high · Verified: 2026-07-18 Things to Know about Google web crawling

ETag ve Last-Modified — Google neden ETag’i tercih ediyor?

Her iki doğrulayıcı da desteklenir. Google’ın tarama belgeleri bunu açıkça belirtir: “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.” Evidence for this claim Google documents heuristic HTTP caching and support for ETag and Last-Modified validators for crawlers that support caching. Scope: official protocol/provider documentation and production verification Confidence: high · Verified: 2026-07-18 Things to Know about Google web crawling

Her ikisi de mevcutsa ETag önceliklidir: “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” Bu yalnızca Google’a özgü bir tercih değildir — HTTP şartnamesinin kuralıdır ve Ahrefs glossary entry on 304 Not Modified yazımda açıkladığım öncelik kuralıyla aynıdır: hem If-None-Match hem de If-Modified-Since kullanıldığında If-None-Match önceliklidir.

Neden ETag tercih edilmeli? Çünkü opak bir dizedir — içeriğin parmak izidir — ve bu sayede Last-Modified başlığını etkileyen tarih ayrıştırma tuzaklarını aşar. Google’ın kendi önerisi şöyledir: “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” Last-Modified kullanırsanız tarihin HTTP standardına (Weekday, DD Mon YYYY HH:MM:SS Timezone) göre biçimlendirilmesi gerekir; aksi hâlde Google bunu ayrıştıramayabilir. Google’ın pratik tavsiyesi, yapabiliyorsanız yine de ikisini de ayarlamanızdır — çifte güvence.

Bir ek sinyal daha vardır: Cache-Control: max-age. Google bunun zorunlu olmadığını söyler; ancak tarayıcıların ne zaman yeniden tarama yapacağına karar vermesine yardımcı olmak için içeriğin değişmeden kalmasını beklediğiniz saniye sayısına ayarlayabilirsiniz. Asimetriye dikkat edin — Google’ın tarama altyapısı max-age değerini ipucu olarak dikkate alır ancak diğer Cache-Control direktiflerini bir tarayıcının ele aldığı gibi ele almaz.

304 ne yapar, ne yapmaz?

Ağ üzerindeki kazanç çarpıcıdır. Bir 304 gövde taşımaz; Gary Illyes’in kaba karşılaştırmasına göre tam bir sayfanın 100 KB+ boyutuna karşılık yaklaşık ~1 KB düzeyindedir. Ayrıca üretilmesi (tam görüntüleme veya veritabanı sorgusu yoktur) ve Google’ın işlemesi (gövde yeniden ayrıştırılmaz, görüntülenmez veya tüm indeksleme işlem hattından tekrar geçirilmez) daha ucuzdur.

Ancak bir 304 yanıtının ne yapmadığı konusunda net olun: sıralama sinyallerinizi dondurmaz. Google’ın durum kodu yönergeleri, gövde yeniden getirilmemiş olsa bile 304 durumunda indeksleme işlem hattının URL sinyallerini yeniden hesaplayabileceğini (“may recalculate signals for the URL”) belirtir. Bir 304, içeriğin indirilmesini ve yeniden işlenmesini atlar — sonraki aşamalardaki her değerlendirmeyi değil. Dolayısıyla burada “sıralamalarımı korumak için 304 yanıtları sunayım” gibi bir hile yoktur.

Google her zaman sormaz — bu normaldir

Çoğu yazının atladığı bir ayrıntı var: Googlebot koşullu başlıkları her istekte göndermez. Google’ın tarama hataları belgesinde şöyle denir: “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).”

Bu nedenle günlüklerinizde Googlebot’un nadiren If-None-Match gönderdiğini görmeniz, yapılandırmanızın bozuk olduğu anlamına gelmez — Google o taramada bunu sormamış olabilir. Google ayrıca, her bir tarayıcı ve getiricinin hizmet verdiği ürüne bağlı olarak önbelleği kullanabileceğini veya kullanmayabileceğini belirtir.

Diğer taraftan, gerçekten yeterince kullanılmayan bir uygulama ayrıntısı olarak, hiç koşullu başlık almadan da 304 sunabilirsiniz. Google: “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” Bu ileri düzey bir CDN/uç tekniğidir ve yanlış uygulanırsa tehlikelidir; gerçekten değişen içerik için 304 sunmak tam olarak “doğrulayıcılarınızın gerçeği yansıtmaması” arıza biçimidir. Bunu sahte güncellik yaratmanın kestirme yolu değil, bir uç optimizasyonu olarak değerlendirin.

Tarama bütçesi açısından önemi

Tasarruf, Google’ın tarama bütçesi yönergelerinde zaten öne çıkardığı profilde en çok birikir: nadiren değişen URL’lerin büyük paya sahip olduğu büyük siteler — uzun kuyruklu SKU’lara sahip e-ticaret katalogları, haber ve yayıncı arşivleri, büyük dokümantasyon siteleri. Bu sitelerde tarama bütçesinin önemli bir kısmı, son taramayla bayt bayt aynı olan sayfaları yeniden indirmeye harcanabilir. Bunlara 304 ile yanıt vererek bütçeyi yeni ve değişen sayfalara ayırabilirsiniz.

Dürüst ve biraz heves kırıcı tarafı şu: Google herkesin bunu zaten yaptığını bildirmiyor; burada daha fazla benimsenmesini istiyor. Illyes, Googlebot’un önbelleğe alınabilen getirme işlemlerinin payının web büyümüş olmasına rağmen son on yılda yaklaşık %0,026’dan %0,017’ye düştüğünü belirtti. Başka bir deyişle bu, yeterince kullanılmayan bir araçtır ve “Crawling December” yazısının kendi bölüm başlığı neredeyse doğrudan bir yakarıştır: “Allow us to cache, pretty please.” Çoğu site bunun için yapılandırılmamıştır.

Koşullu istekleri etkisiz kılan yaygın yanlış yapılandırmalar

Bir doğrulayıcı ayarlamak, ondan faydalanmakla aynı şey değildir. Siteler bunu fark ettirmeden üç (daha doğrusu dört) şekilde bozar:

1. Her zaman tam gövdeli 200 döndürmek

En yaygın hata hiçbir şey yapmamaktır — sunucu doğrulayıcıları hiç ayarlamaz veya denetlemez; dolayısıyla bir şeyin değişip değişmediğine bakılmaksızın her tarama tam bir yeniden indirme olur. Bu genellikle hiçbir önbellek katmanı yapılandırılmamış bir CMS/sunucu yığınıdır. Illyes’in insanları çıkarmaya çalıştığı varsayılan durum budur.

2. Her istekte değişen ETag’ler

Bu daha sinsidir çünkü doğru görünür. ETag değeriniz yerleştirilmiş bir zaman damgası, istek veya oturum başına belirteç, istek kimliği ya da derleme zamanını içine alan bir derleme çıktısı gibi değişken bir şeyden hesaplanıyorsa görünür içerik aynı olsa bile her yanıt “yeni” bir ETag alır. If-None-Match hiçbir zaman eşleşmez; dolayısıyla sunucunuzun 304 döndürmesi için dayanak oluşmaz. Çözüm: ETag değerini istek başına değişen herhangi bir şeyden değil, gerçek yanıt gövdesinin karmasından veya kararlı bir içerik sürümü tanımlayıcısından türetin.

3. CDN/küme düğümleri arasındaki farklılıklar

Bunun yakın akrabası, farklı kaynak düğümlerinin aynı içerik için farklı (zayıf) ETag değerleri üretmesidir. Düğümler arasında geçiş yapan bir CDN veya tarayıcı kararlı bir değer göremez ve hiçbir zaman temiz bir 304 alamadan sürekli yeniden doğrulama yapar. Çözüm: ETag değerlerini örnek başına durumdan değil, içerikten belirlenimsel biçimde üretin veya ETag üretimini tüm sunucu filosunda merkezileştirin.

4. Gerçek değişiklikleri yansıtmayan bir Last-Modified

Last-Modified değeriniz her görüntülemede “şimdi” olarak damgalanıyor veya altbilgideki otomatik güncellenen telif hakkı yılı gibi önemsiz bir değişiklikle ilerletiliyorsa ya gereksiz tam yeniden taramaları tetikler (tarih her zaman yeni görünür) ya da eski/manipüle edilmişse Google’ın sinyale olan güvenini aşındırır. Bu, Google’ın site haritasındaki lastmod değerine uyguladığı dürüstlük ilkesiyle aynıdır — yalnızca önemli bir değişikliği doğrulanabilir biçimde yansıtıyorsa kullanın. Tarama sıklığı makalesi bu lastmod mantığını ele alır; aynı disiplin Last-Modified HTTP başlığı için de geçerlidir.

Illyes uç durumu: 304 bozuk bir sayfayı kalıcılaştırdığında

Gerçekten sezgilere aykırı olduğu ve neredeyse hiç kimse değinmediği için ayrıca vurgulanmayı hak ediyor. Illyes, bir 304 yanıtının nasıl “backfire spectacularly” olabileceğini açıklamıştır: Bir sunucu hatası, bozuk ve boş bir sayfayı 200 ile sunar; tarayıcı bunu geçici bir hata olarak değerlendirip doğrulamak üzere yeniden tarama planlar; hâlâ bozuk olan sayfa daha sonra doğru biçimde 304 (“unchanged”) bildirir; tarayıcı da hata durumunun kalıcı, “real” içerik olduğu sonucuna varıp daha seyrek denetlemeye başlar. Numaralandırılmış açıklamasını, tarayıcının “learn[ing] the error is persistable” olduğunu söyleyerek bitirir. Kendi uyarısı şöyledir: Bu olur mu? Evet. Sık mı? Kesinlikle hayır — “but it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” Çıkarılacak ders şudur: Temel içerik üretimi bozuksa koşullu istekler hatayı kalıcılaştırabilir; bu nedenle bunları güvenilmez bir kaynağın üzerine eklemeyin.

Bing bunu nasıl ele alıyor?

Bu yalnızca Google’a özgü bir özellik değildir; Bing’in desteği muhtemelen daha eski ve daha açıktır. Bing, henüz Live Search adını taşırken 2008’de RFC-2616 uyumlu koşullu GET desteğini duyurdu: Son indirme zamanıyla If-Modified-Since, mevcut olduğunda ise ETag ile If-None-Match gönderir ve sayfa son taramadan bu yana değişmedikçe “generally will not download the page unless it has changed since the last time it crawled it.” Bugün Bing bunu adlandırılmış ve izlenebilir bir ölçüte — tarama verimliliğine — dönüştürüyor. Fabrice Canel bunu “how often we crawl and discover new and fresh content per page crawled.” şeklinde tanımlar. Değişmeyen içeriğin gereksiz yere yeniden taranması bu puanı doğrudan düşürür. Dolayısıyla aynı doğrulayıcılar her iki motora da hizmet eder; Bing yalnızca kavrama bir puan tablosu verir. Evidence for this claim Conditional requests use validators such as ETag and Last-Modified with If-None-Match or If-Modified-Since. Scope: Current official or standards documentation. Confidence: high · Verified: 2026-07-14 RFC 9110: Conditional requests

Bu, sıralamaları etkiler mi?

Hayır. Tarama hızı ve tarama bütçesi makalelerindeki aynı disiplini koruyun: koşullu istekler bir sıralama faktörü değil, tarama verimliliği ve kaynak aracıdır. Hiçbir resmî kaynak ETag/If-Modified-Since/304 kullanımını sıralamalara bağlamaz. Dolaylı faydası, büyük veya sık güncellenen sitelerde yeni ve değişen içeriğin daha erken taranıp indekslenebilmesidir — ancak daha verimli taranmak kendi başına sıralama sinyali değildir.

Çalıştığı nasıl doğrulanır?

Kesin bilgi kaynağı sunucu günlüklerinizdir. İki şeye bakın: Googlebot’un If-None-Match/If-Modified-Since istek başlıkları göndermesi ve sunucunuzun ona 304 yanıtları döndürmesi. Gerçek dünya verileri azdır; Dave Smart’ın Tame the Bots sunucu günlüğü çalışmasını değerli kılan da budur. Doğrulanmış Googlebot trafiğini izlerken isteklerin yalnızca yaklaşık %1,3’ünün 304 aldığını — çoğunun 200 olduğunu — ve If-None-Match isteklerinin, bir URL önceki getirme işleminden kısa süre sonra yeniden istendiğinde kümelenme eğilimi gösterdiğini buldu. Vardığı sonuç yönergelerle uyumludur: küçük sitelerde seyrek, yoğun tarananlarda ise potansiyel olarak “significant savings”. Küçük bir sitede yüksek 304 oranı beklemeyin; büyük ölçekte önemli olmasını bekleyin.

Koşullu istekler, hız, sıklık ve bütçe karşılaştırması

Tarama bütçesi ailesindeki kavramları ayırmak için:

• Tarama hızı — Googlebot’un ne kadar hızlı getirme yaptığıdır (arz tarafı, sunucu sağlığına göre sınırlandırılır).
• Tarama sıklığı — bilinen bir URL’nin ne sıklıkta yeniden getirildiğidir (popülerlik + eskime).
• Tarama bütçesi — talep + kapasite zarfıdır: Google’ın tarayabildiği ve taramak istediği URL kümesi.
• Koşullu istekler — her bir yeniden taramaya ne kadar düşük maliyetle yanıt verilebildiğidir. Google’ın ne kadar hızlı veya sık tarama yaptığını değiştirmez; değişmemiş sayfalara yapılan ziyaretleri neredeyse bedelsiz hâle getirerek bütçenin aynı içeriğe harcanmasını önler.

Yapay zekâ özeti

İleri Düzey sürümün kısa özeti:

• Koşullu istekler = “Bu değişti mi?” Googlebot, If-Modified-Since (Last-Modified değerinize göre doğrulanır) ve/veya If-None-Match (ETag değerinize göre doğrulanır) gönderir. Değişmediyse → sunucunuz gövdesiz bir 304 Not Modified döndürür ve tarayıcı kopyasını yeniden kullanır.
• Her ikisi de mevcutsa ETag önceliklidir; Google, tarih biçimi tuzakları olmadığı için ETag önerir, ancak ikisini de ayarlayın der. Cache-Control: max-age, yeniden tarama zamanlamasına ilişkin isteğe bağlı ek bir ipucudur.
• Bir 304, 100 KB+ yerine ~1 KB’tır ve yeniden indirme/işlemeyi atlar — ancak indeksleme sinyallerini dondurmaz (Google bunları yine hesaplayabilir).
• Google başlıkları her zaman göndermez (kullanım durumuna bağlıdır; AdsBot’un gönderme olasılığı daha yüksektir) ve koşullu başlık olmadan da proaktif olarak 304 sunabilirsiniz.
• Üç yanlış yapılandırma bunu etkisiz kılar: tam gövdeli ve her zaman 200; değişken ETag değerleri (zaman damgaları, istek başına belirteçler, CDN düğümleri arasındaki farklılıklar); gerçek değişiklikleri izlemeyen bir Last-Modified (site haritası lastmod değeriyle aynı dürüstlük kuralı).
• Uç durum: bozuk/boş bir sayfa üzerinden sunulan 304, Googlebot’un hatayı kalıcı saymasına yol açabilir (Illyes).
• Bing, 2008’den beri RFC uyumlu koşullu GET’i destekler ve bunu “crawl efficiency” olarak izler.
• Benimsenme düşük ve geriliyor (on yılda önbelleğe alınabilir getirmeler %0,026 → %0,017); bu, büyük siteler için yeterince kullanılmayan bir araçtır ve sıralama faktörü değildir.
• Sunucu günlüklerinden doğrulayın (304 oranı, If-None-Match varlığı). Gerçek veriler (Tame the Bots), küçük sitelerde seyrek; büyük ölçekte anlamlı olduğunu gösterir.

Resmî belgeler

Koşullu istekler ve tarayıcı önbelleklemesi hakkındaki birincil kaynak belgeleri.

Google

• Things to Know about Google’s Web Crawling — güncel HTTP önbellekleme sözleşmesi: ETag/If-None-Match, Last-Modified/If-Modified-Since, ETag önceliği ve Cache-Control: max-age ipucu. (Not: Bu içerik eski /search/docs/... yolundan buraya taşındı; yönergeler aynıdır.)
• Crawling December: HTTP caching — bu belge güncellemesinin arkasındaki Gary Illyes imzalı Aralık 2024 yazısı (“Allow us to cache, pretty please”).
• Troubleshoot Google Search crawling errors — If-Modified-Since/304 mekanizması, AdsBot örneği ve “serve a 304 without a conditional header” izni.
• HTTP status codes, network, and DNS errors — Google’ın bir 304 yanıtını nasıl ele aldığı (sinyaller yine hesaplanabilir; indeksleme üzerinde olumsuz etkisi yoktur).
• Optimize your crawl budget — üst kavram ve bununla gerçekten kimlerin ilgilenmesi gerektiği.
• Build and submit a sitemap — Last-Modified başlığı disiplinini yansıtan lastmod dürüstlük ilkesi.

Bing / Microsoft

• Announcing crawler improvements for Live Search — Bing’in 2008 tarihli ilk RFC-2616 koşullu GET duyurusu (If-Modified-Since + If-None-Match/ETag).
• bingbot Series: Maximizing Crawl Efficiency — Bing’in “crawl efficiency” ölçütü ve değişmemiş içeriğin yeniden taranmasının bunu neden düşürdüğü.
• Bing Webmaster Tools — Crawl Control — koşullu isteklerin tarama başına verimlilik aracı olmasıyla karşılaştırılan hız tarafındaki araç.

Kaynaktan alıntılar

Google ve Bing’in kayda geçmiş açıklamaları. Her bağlantı, kaynak sayfadaki alıntılanan bölüme giden bir derin bağlantıdır.

Google — tam olarak neler destekleniyor?

• “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.” — Google, Things to Know about Google’s Web Crawling. Alıntıya git
• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” Alıntıya git
• “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” Alıntıya git
• “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. 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.” Alıntıya git

Google — başlıkları ne zaman gönderdiği ve proaktif 304 izni

• “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” — Google, Troubleshoot Google Search crawling errors. Alıntıya git
• “If our crawlers send the If-Modified-Since header, the header’s value is the date and time the content was last crawled. Based on that value, the server may choose to return a 304 (Not Modified) HTTP status code with no response body, in which case Google will reuse the content version it crawled the last time.” Alıntıya git
• “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” Alıntıya git

Gary Illyes, Google (LinkedIn — 304’ün ters tepme arıza biçimi)

• “HTTP 304 (not modified) is super useful to signal crawlers that the content they’re accessing hasn’t changed since it was last crawled, but it can also backfire spectacularly.” Gönderiyi okuyun
• Boş sayfadan sonra 304 tuzağının gerçekte ne sıklıkta yaşandığı hakkında: “Does this ever happen? Yes. Often? Absolutely not. But it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” Gönderiyi okuyun

Bing (Live Search), Fabrice Canel (2008 koşullu GET duyurusu)

• “Live Search supports conditional get as defined by RFC 2616 (Section 14.25), and generally will not download the page unless it has changed since the last time it crawled it.” Alıntıya git

Koşullu istekleri uygulamaya değer mi?

Her sitenin buna ihtiyacı yoktur. Sunucu yapılandırmasına dokunmadan önce harcayacağınız zamana değip değmeyeceğini değerlendirin.

SOP: koşullu istekleri doğru uygulama

Büyük bir siteye koşullu istek desteği eklemek (veya mevcut desteği düzeltmek) için tekrarlanabilir bir prosedür. Şu sırayı izleyin: ölçün, uygulayın, doğrulayın.

1. Gerçekten bu sorununuz olduğunu doğrulayın. Sunucu günlüklerinizden doğrulanmış Googlebot trafiğini alın. Değişmemiş URL’lere gelen isteklerin çoğu tam gövdeyle 200 döndürüyor ve çok az If-None-Match / If-Modified-Since başlığı görünüyor veya hiç görünmüyorsa iyileştirme alanınız vardır. Değişmeyen sayfalarda zaten 304 görüyorsanız durun — kazanılacak pek az şey olabilir.

2. Kararlı, içeriğe dayalı bir ETag üretin. ETag değerini gerçek yanıt gövdesinin karmasından veya kararlı bir içerik sürümü tanımlayıcısından hesaplayın. Bunu bir zaman damgası, istek veya oturum başına belirteç, istek kimliği ya da sunucu düğümüne göre değişen herhangi bir şeyden türetmeyin. Aynı değişmemiş URL’yi iki kez isteyerek ETag değerinin iki seferde de (ve CDN/kaynak filonuz genelinde) aynı olduğunu doğrulayın.

3. Gerçeği yansıtan bir Last-Modified ayarlayın. Last-Modified değerini son önemli içerik değişikliğinin tarih/saatine ayarlayın — geçerli görüntüleme zamanına veya yalnızca altbilgi yılı ya da zaman damgası değiştiğinde ilerleyen bir değere değil. HTTP standardına göre biçimlendirin (Weekday, DD Mon YYYY HH:MM:SS Timezone). Yapabiliyorsanız hem ETag hem de Last-Modified ayarlayın; Google ETag değerini tercih eder.

4. 304’ü doğru döndürün. Gelen If-None-Match geçerli ETag değerinizle eşleştiğinde (veya If-Modified-Since, Last-Modified değerinizden eski olmadığında) ve hiçbir şey değişmediğinde, yanıt gövdesi olmadan 304 Not Modified döndürün — yalnızca durum ve başlıklar. Çoğu web sunucusu ve çerçeve bunu otomatik yapabilir; sizinkinin kaynağın önündeki bir proxy veya CDN tarafından kaldırılmadığını doğrulayın.

5. (İsteğe bağlı) Bir Cache-Control max-age ipucu ekleyin. İçeriğin değişmeden kalmasını beklediğiniz saniye sayısına Cache-Control: max-age=<seconds> ayarlayın; bu, yeniden tarama zamanlamasına yönelik ek bir sinyaldir. Bir ipucudur, garanti değildir.

6. Günlüklerde doğrulayın — sonra kendi hâline bırakın. Birkaç hafta sonra günlükleri yeniden denetleyin. Googlebot’un If-None-Match isteklerinin değişmemiş sayfalarda 304, yalnızca içerik gerçekten değiştiğinde ise 200 ile karşılandığını görmek istersiniz. Küçük bir sitede bu yanıtların oranı yüksek olmayabilir; asıl etkisini büyük ölçekte gösterir.

Koruyucu kural: Gerçekten değişmiş bir sayfa için asla 304 sunmayın ve koşullu istekleri güvenilmez bir kaynağın üzerine eklemeyin — bozuk/boş bir sayfa üzerinden sunulan 304, Googlebot’un hatayı kalıcı saymasına yol açabilir.

Kaçınılması gereken mitler ve hatalar

Boşa çabaya veya fark edilmeyen arızalara neden olan yaygın yanılgılar:

• “Googlebot her zaman If-Modified-Since/If-None-Match gönderir; dolayısıyla bunları günlüklerimde görmüyorsam sunucum bozuktur.” Yanlış. Google, başlıkları her taramada göndermediğini açıkça söyler — bu kullanım durumuna bağlıdır ve ana Search tarayıcısı bunları tutarsız biçimde gönderir (AdsBot’un gönderme olasılığının daha yüksek olduğu özellikle belirtilir). Gerçek günlük verilerinde (Tame the Bots), test edilen sitedeki isteklerin %2’sinden çok daha azının 304 aldığı görülmüştür.

• “304, Google’ın sıralamalarımı veya sinyallerimi yeniden değerlendirmeyeceği anlamına gelir.” Yanlış. Google’ın kendi belgeleri, 304 durumunda indeksleme işlem hattının URL sinyallerini yine hesaplayabileceğini belirtir; yalnızca içeriğin indirilmesi ve yeniden işlenmesi atlanır.

• “ETag ayarlamak otomatik olarak 304 yanıtları alacağım anlamına gelir.” ETag değişkense yanlıştır. Zaman damgası, istek başına belirteç veya düğüm başına durumdan oluşturulan bir ETag her istekte değişir; bu nedenle If-None-Match hiçbir zaman eşleşmez. İlk bakışta doğru yapılandırılmış göründüğü için teşhis edilmesi de daha zordur.

• “Last-Modified değerinin bulunması yeterlidir; herhangi bir tarih kullanılabilir.” Yanlış. Gerçek içerik değişikliklerini izlemiyorsa (her görüntülemede “şimdi” ile damgalanıyor veya altbilgideki bir değişiklikle ilerletiliyorsa) ya gereksiz yeniden taramaları tetikler ya da Google’ın sinyale güvenini aşındırır — Google’ın site haritası lastmod değeri için belirttiği ilkeyle aynıdır.

• “304 yalnızca koşullu bir GET isteğine tepki olarak verilebilir.” Yanlış. Google, sunucu içeriğin değişmediğini bağımsız olarak bildiğinde herhangi bir Googlebot isteğine gövdesiz 304 yanıtının proaktif olarak döndürülmesine açıkça izin verir.

• “Koşullu istekleri uygulamak sıralamalarımı yükseltir.” Hiçbir resmî kaynak bunu ortaya koymamıştır. Belgelenen fayda, büyük sitelerin yeni içeriği daha hızlı taratmasına yardımcı olabilen tarama/sunucu verimliliğidir — sıralama faktörü değildir.

• “Bu yalnızca dev kurumsal siteler için önemlidir.” Aciliyet bakımından büyük ölçüde doğrudur — Google bunu nadiren değişen içeriğe sahip büyük sitelere yöneltir — ancak mekanizma ve yanlış yapılandırmalar her site için geçerlidir. Küçük bir sitede yalnızca nadiren kurulum zahmetine değer.

Bir URL’nin önbellek doğrulayıcılarını curl ile denetleme

Sunucunuzun hangi doğrulayıcıları gönderdiğini ve bunları geri ilettiğinizde 304 döndürüp döndürmediğini görün.

1) Yanıt başlıklarını görüntüleyin (ETag ve Last-Modified başlıklarını arayın)

curl -sI https://example.com/some-page | grep -iE 'etag|last-modified|cache-control'
# ETag: "a1b2c3d4e5"
# Last-Modified: Thu, 22 Jan 2026 01:28:49 GMT
# Cache-Control: max-age=94043

2) ETag ile koşullu istekte bulunun — 304 yanıtı almalısınız

curl -sI https://example.com/some-page \
  -H 'If-None-Match: "a1b2c3d4e5"'
# HTTP/2 304        ← correct: server confirms nothing changed, sends no body
# HTTP/2 200        ← if you get this on an unchanged page, your validators aren't working

3) Bunun yerine tarihle koşullu istekte bulunun

curl -sI https://example.com/some-page \
  -H 'If-Modified-Since: Thu, 22 Jan 2026 01:28:49 GMT'
# HTTP/2 304

Değişken bir ETag’i tespit etme

Aynı değişmemiş URL, art arda gelen isteklerde farklı bir ETag döndürüyorsa ETag değeriniz değişkendir (zaman damgası/belirteç tabanlıdır) ve If-None-Match hiçbir zaman eşleşmez:

# Request twice; the two ETag values should be IDENTICAL for an unchanged page
for i in 1 2; do curl -sI https://example.com/some-page | grep -i '^etag:'; done
# ETag: "a1b2c3d4e5"
# ETag: "a1b2c3d4e5"   ← good (stable)
# ETag: "9f8e7d6c5b"   ← BAD if different: your ETag changes every request

Erişim günlüklerinde 304’leri örnekleme

Googlebot’tan gelen gerçek koşullu istek etkinliğini doğrulayın. Alan konumlarını günlük biçiminize göre ayarlayın (bu örnek birleşik günlük tarzı bir durum alanı varsayar):

# Count status codes returned to Googlebot
grep -i 'googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
#   4211 200
#     53 304        ← these are the conditional-request wins
#     12 301

# See which URLs are getting 304s
grep -i 'googlebot' access.log | awk '$9==304 {print $7}' | sort | uniq -c | sort -rn | head

(User-agent dizesine güvenmeden önce ters + ileri DNS denetimiyle isteğin gerçekten Googlebot’tan geldiğini doğrulayın — sahte Googlebot trafiği yaygındır.)

Tarayıcıda hızlı DevTools Console denetimi

Tarayıcının geçerli sayfa için aldığı doğrulayıcıları okumak üzere bunu Chrome DevTools Console’a yapıştırın:

// Reads the ETag / Last-Modified the server sent for THIS page
fetch(location.href, { method: 'HEAD' }).then(r => {
  console.log('ETag:', r.headers.get('etag'));
  console.log('Last-Modified:', r.headers.get('last-modified'));
  console.log('Cache-Control:', r.headers.get('cache-control'));
});

Doğrulayıcı → istek → yanıt çerçevesi

1. Doğrulayıcı: İlk 200 yanıtı bir ETag, Last-Modified veya her ikisini sağlar.
2. İstek: Daha sonraki getirme işlemi bu değeri If-None-Match veya If-Modified-Since içinde geri gönderir.
3. Yanıt: Değişmemiş içerik gövdesiz 304; değişmiş içerik yeni gövde ve doğrulayıcıyla 200 döndürür.
4. Kararlılık denetimi: Doğrulayıcılar, istek başka bir sunucuya ulaştığı veya zaman damgası içerdiği için değil, temsilin içeriği değiştiğinde değişmelidir.

Koşullu istek başlıkları kısa başvuru tablosu

Doğrulayıcıları denetleme araçları

• HTTP Header Checker, ETag, Last-Modified, önbellek başlıkları ve yönlendirmeler arasındaki başlık değişikliklerini gösterir.
• Tarayıcı DevTools’un Network paneli, ilk doğrulayıcıları ve yinelenen bir istekteki koşullu başlıkları incelemenizi sağlar.
• curl, en açık ve tekrarlanabilir testtir: bir doğrulayıcıyı yakalayın, geri gönderin ve değişmemiş yanıtın 304 olduğunu doğrulayın.
• Erişim günlüğü analizi, tarayıcıların koşullu isteklerinin büyük ölçekte gerçekten 304 yanıtı alıp almadığını gösterir.

Koşullu istek sağlığı ölçütleri

Koşullu isabet oranı

Ölçüt: 304 döndüren uygun koşullu istekler. Size ne söyler: Doğrulayıcıların değişmemiş gövde aktarımlarını önleyip önlemediğini. Nasıl elde edilir: If-None-Match veya If-Modified-Since taşıyan erişim günlüğü isteklerini yanıt durumuna göre gruplayın. Karşılaştırma ölçütü / gerçekçi aralık: Şablona ve değişiklik sıklığına göre başlangıç değeri belirleyin; sık güncellenen sayfalar doğal olarak kararlı arşivlerden farklı olmalıdır. Sıklık: Aylık ve önbellek/CDN değişikliklerinden sonra.

304 yanıtlarıyla önlenen baytlar

Ölçüt: Aktarılmayan tahmini yanıt gövdesi baytları. Size ne söyler: Yalnızca yanıt sayıları yerine bant genişliği faydasını. Nasıl elde edilir: Her 304 URL’sini günlüklerdeki veya tarama dışa aktarımındaki en son 200 gövde boyutuyla karşılaştırın. Karşılaştırma ölçütü / gerçekçi aralık: Sitenin önceki dönemiyle karşılaştırın; dürüst bir evrensel hedef yoktur. Sıklık: Aylık.

Doğrulayıcı kararsızlığı

Ölçüt: Denetimler arasında ETag veya Last-Modified değeri değişen, içeriği değişmemiş URL’ler. Size ne söyler: İstek veya düğüm başına farklılığın yeniden doğrulamayı etkisiz kılıp kılmadığını. Nasıl elde edilir: Sabit bir örneğe aynı başlık isteklerini art arda gönderin. Karşılaştırma ölçütü / gerçekçi aralık: Temsil değişmediği sürece doğrulayıcılar kararlı kalmalıdır. Sıklık: Dağıtımlardan, CDN değişikliklerinden veya yük dengeleyici değişikliklerinden sonra.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• What Is 304 Not Modified? (Ahrefs SEO Glossary) — koşullu istek akışının tamamı, If-None-Match önceliği kuralı ve 304 olanağının küçük siteler için neden “not that crucial”, büyük siteler içinse “great opportunity” olduğu üzerine açıklamam.
• When Should You Worry About Crawl Budget? — üst kavram: tarama bütçesinin gerçekte ne olduğu, talep ile kapasite ve koşullu isteklere odaklanmadan önce kimlerin bunu önemsemesi gerektiği.
• What Is Googlebot & How Does It Work? — Googlebot’un neyi ve ne kadar hızlı tarayacağına nasıl karar verdiği ve zamanlayıcıyı çevreleyen bağlam.
• The Beginner’s Guide to Technical SEO — tarama verimliliğinin büyük resimdeki yeri.

Konuşmalarım

• How Search Works (SlideShare) — nelerin yeniden getirileceğini belirleyen tarama talebi etkenleri dâhil olmak üzere tarama, görüntüleme, indeksleme ve sıralama açıklamam. (Her zaman belirttiğim çekince geçerlidir: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Sektörden kaynaklar

• Crawling December: HTTP caching (Google Search Central) — Gary Illyes’in site sahiplerinden önbelleklemeyi etkinleştirmelerini isteyen yazısı ve gerileyen benimsenme istatistiğinin kaynağı.
• Does Googlebot Use Etag Headers? (Dave Smart, Tame the Bots) — Googlebot’un koşullu istek davranışına ilişkin ender gerçek sunucu günlüğü çalışmalarından biri; rakip yazıların çoğu gözlemlenmiş veri içermeyen salt şartname açıklamalarıdır.
• Google clarifies how Google’s crawlers handle cache control headers (Barry Schwartz, Search Engine Land) — temel ETag/Last-Modified alıntılarının kelimesi kelimesine aktarıldığı Aralık 2024 belge güncellemesi haberi.
• Google’s Updated Crawler Guidance Recommends ETags (Roger Montti, Search Engine Journal) — Google’ın neden ETag tercih ettiği ve “individual crawlers may or may not use caching” ayrıntısı.
• Announcing crawler improvements for Live Search (Fabrice Canel, Bing Webmaster Blog) — örnek bir istek/yanıtla Bing’in 2008 tarihli ilk RFC-2616 koşullu GET duyurusu.
• bingbot Series: Maximizing Crawl Efficiency (Bing Webmaster Blog) — değişmemiş içeriğin yeniden taranmasının ölçütü doğrudan düşürdüğü Bing “crawl efficiency” yaklaşımı.
• MDN: HTTP conditional requests (Mozilla) — doğrulayıcılar ve 304 mekanizması için tarafsız, şartname düzeyinde başvuru kaynağı.

Kendinizi sınayın: Koşullu İstekler

ETag, If-Modified-Since ve 304 Not Modified hakkında beş kısa soru. Her biri için bir yanıt seçip kontrol edin.

Değişiklik günlüğü