SEO için Önbellekleme

TL;DR — Önbellekleme, bir sayfanın veya dosyanın kopyasını kaydetmek anlamına gelir; böylece sıfırdan yeniden oluşturulup gönderilmesi gerekmez. Bu, sitenizi insanlar ve arama botları için hızlandırır ve botların değişmemiş sayfaları yeniden indirmesini atlamasını sağlar. Önbellekleme tek başına sizi daha üst sıralara taşımaz — ancak sağladığı hız ve etkinleştirdiği tarama verimliliği dolaylı olarak yardımcı olur.

Önbellekleme nedir

Birisi bir sayfayı her açtığında sunucu iş yapmak zorundadır: HTML’i oluşturmak, görselleri göndermek, CSS ve JavaScript’i iletmek. Önbellekleme, bu şeylerin hazır bir kopyasını saklar; böylece bir sonraki ziyaret tüm bu işi yeniden yapmak yerine onu yeniden kullanabilir.

SEO açısından önemli olan üç önbellekleme konumu vardır:

1. Tarayıcı önbelleği — dosyalar ziyaretçinin kendi cihazına kaydedilir; böylece ikinci sayfa görüntülemesi veya siteye dönüş ziyareti neredeyse anında yüklenir.
2. CDN (uç) önbelleği — kopyalar dünyanın dört bir yanına dağılmış sunucularda saklanır; böylece dosya, tek kaynak sunucunuz yerine kullanıcıya (veya bota) fiziksel olarak yakın bir konumdan sunulur.
3. Tarama botunun kendi önbelleği — Googlebot ve Bingbot, bir sayfanın son ziyaretten bu yana değişip değişmediğini hatırlar ve değişmediyse sayfayı yeniden indirmez.

SEO için neden önemlidir

İki neden var ve bunları ayrı tutmakta fayda var:

• Hız. Daha hızlı sunum, Core Web Vitals değerlerinizi iyileştirir — özellikle sunucunun yanıt verme süresini (TTFB) ve ana içeriğin görüntülenme hızını (LCP). Hız, Google’ın sayfa deneyimi sinyallerinden biridir.
• Tarama verimliliği. Bir bot sayfanın değişmediğini anlayabildiğinde, onu gereksiz yere yeniden indirmez. Büyük bir sitede bu, botun zamanını yeni ve güncellenmiş sayfalara ayırmasını sağlar.

Anlaşılması gereken tek şey

“Google’ın önbelleği” ile “HTTP önbelleklemesi” iki farklı şeydir. Eski cache: arama operatörü — “Google’ın bu sayfa için kaydettiği kopyayı görüntüle” özelliği — 2024’te kullanımdan kaldırıldı. Bunun, bu makalede ele alınan önbelleklemeyle hiçbir ilgisi yoktur. Cache-Control ve ETag başlıkları hâlâ kullanımdadır ve önemlidir. Sayfanızın Google’da “önbelleğe alınmış bir sürümünün” bulunmaması, önbellekleme yapılandırmanızın doğru olup olmadığı hakkında hiçbir şey söylemez.

Gerçekte ne yapmalı

• Statik dosyalarınızı (görseller, CSS, JavaScript, yazı tipleri) uzun süre önbelleğe alın.
• Gerektiğinde anında güncelleyebilmek için sürümlendirilmiş veya karma içeren dosya adları kullanın.
• Dosyaların kullanıcılarınıza yakın konumlardan yüklenmesi için bir CDN kullanın.
• Eski veya paylaşılan bir önbelleğin botlara yanlış içerik sunmasına istemeden izin vermeyin (tehlikeli hata senaryosu — Gelişmiş ve Anti-desenler sekmelerine bakın).

Başlık düzeyindeki ayrıntıları — Cache-Control yönergelerini, ETag ile Last-Modified karşılaştırmasını, CDN’lerin tarama hızına etkisini ve taramayı bozan önbellekleme hatalarını — öğrenmek mi istiyorsunuz? Gelişmiş sekmesine geçin.

TL;DR — Önbellekleme, SEO açısından önemli üç katmanda çalışır: tarayıcı, CDN ucu ve tarama botunun kendi koşullu istek önbelleği. Doğrudan bir sıralama faktörü değildir; ancak sayfa hızını (TTFB/LCP ve — bfcache aracılığıyla — tekrarlanan gezinmelerdeki Core Web Vitals değerlerini) ve tarama verimliliğini etkiler. Google’ın tarama botu Last-Modified yerine ETag’i tercih eder, max-age değerini yalnızca yeniden tarama ipucu olarak okur ve — kendi belgelerindeki ifadeyle — “other HTTP caching directives aren’t supported.” CDN’lere daha yüksek bir tarama hızı kotası tanınır, ancak bu yalnızca önbellekleri ısındıktan sonra geçerlidir; asıl riskler soğuk önbellekle yapılan lansmanlar ve botları tamamen engelleyen CDN/WAF yanlış yapılandırmalarıdır.

Önbelleklemenin üç katmanı

SEO açısından önbellekleme tek bir mekanizmadan ibaret değildir — biraz farklı biçimlerde denetlenen üç mekanizma vardır:

1. Tarayıcı önbelleği — ziyaretçinin cihazı dosyaları saklar; böylece tekrarlanan görüntülemelerde ağdan indirme yapılmaz. PageSpeed Insights’ın “Serve static assets with an efficient cache policy.” uyarısıyla işaret ettiği konu budur.
2. CDN / uç önbelleği — bir içerik dağıtım ağı, kopyaları dünya genelindeki uç düğümlerde saklar (konunun tamamı için CDN ve SEO derinlemesine incelemesine bakın). Google’ın açıklamasına göre CDN’ler, kaynak sunucunuz ile kullanıcı arasında aracılık eder ve geçmişten beri en çok önbelleklemeye odaklanırlar — bir URL’nin içeriğini saklayarak sunucunuzun o dosyayı bir süre boyunca yeniden sunmak zorunda kalmamasını sağlarlar.
3. Tarama botu tarafındaki önbellek — Googlebot ve Bingbot, koşullu istekler kullanarak içeriğin değişip değişmediğine ilişkin kendi kayıtlarını tutar. Tarama bütçesini etkileyen mekanizma budur; ayrıntıları koşullu istekler derinlemesine incelemesine aittir, burada yalnızca özetleyeceğim.

Yukarıdaki “tarayıcı önbelleği” ifadesi birden fazla mekanizmayı kapsayan bir kısaltmadır. MDN’nin HTTP önbellekleme kılavuzuna göre şu mekanizmaları birbirinden ayırmak önemlidir: özel HTTP önbelleği (her tarayıcıya özgüdür, isteğe göre anahtarlanır ve modern tarayıcılarda siteler arası izlemeyi sınırlamak için üst düzey siteye göre bölümlenir), geçerli oturumda kullanılan bellek içi önbellek, aşağıda ele alınan bfcache ve — bunlardan ayrı olarak — sitenin kendi JavaScript kodunun denetlediği ve Cache-Control başlıklarının doğrudan yönetmediği service worker Cache Storage alanı. “Tarayıcı önbelleğini kontrol edin” ifadesi, gerçekte hangi mekanizmanın sorun çıkardığına bağlı olarak dört farklı hata ayıklama adımı anlamına gelebilir.

Önbellekleme Core Web Vitals’ı neden etkiler?

Kaynakları ağ üzerinden getirmek yavaş ve maliyetlidir. Önbellekleme, değişmemiş kaynaklar için ağ gecikmesini ve veri aktarımı maliyetini ortadan kaldırır. Bu durum, Core Web Vitals ile yakından ilişkili iki ölçümü doğrudan etkiler: TTFB (önbelleğe alınmış yanıt, kaynak sunucuda yeniden oluşturma işlemini atlar) ve LCP (önbelleğe alınmış görseller/CSS/yazı tipleri daha erken işlenir).

Önemli Cache-Control yönergeleri

Cache-Control temel başlıktır. Bilmeniz gereken yönergeler şunlardır:

• max-age=<seconds> — yeni bir kopyanın ne kadar süre taze kalacağını belirtir. Chrome’un Lighthouse belgeleri, değişmez ve sürümlendirilmiş varlıkların bir yıl veya daha uzun süreyle önbelleğe alınmasını önerir — ör. Cache-Control: max-age=31536000.
• no-cache — “önbelleğe alma” anlamına gelmez. “Sakla, ancak yeniden kullanmadan önce sunucuyla yeniden doğrula” anlamına gelir. Hafif 304 akışının kullanılmasına yine de olanak tanır.
• no-store — hiçbir kopyanın hiçbir yerde bir HTTP önbelleğinde saklanmamasını gerçekten isteyen yönergedir. Genel amaçlı bir gizlilik anahtarı değil, bir önbellekleme yönergesidir — RFC 9111’e göre tarayıcı geçmişini silmenin güvenilir bir yolu değildir ve bir service worker’ın kendi Cache Storage alanı hakkında hiçbir şey söylemez.
• public / private — yanıtın paylaşılan önbellekler (CDN gibi) tarafından mı, yoksa yalnızca son kullanıcının tarayıcısı tarafından mı saklanabileceğini belirtir.
• immutable — yanıt hâlâ tazeyken yeniden doğrulamayı tamamen atlar. “Asla eskimez” anlamına gelmez — max-age sona erdiğinde normal tazelik kuralları yeniden uygulanır.
• must-revalidate — zaman çizelgesinin diğer ucunda yer alır: yalnızca yanıt eskidikten sonra önem kazanır ve önbelleğe, eski kopyayı sunmak yerine kaynak sunucuyla yeniden doğrulama yapması gerektiğini bildirir.
• s-maxage, stale-while-revalidate, stale-if-error — çoğunlukla CDN’ler ve diğer paylaşılan önbellekler için daha ayrıntılı denetimlerdir (sırasıyla paylaşılan önbelleklere özel ayrı bir tazelik süresi, arka planda getirme işlemi sürerken eski kopyanın sınırlı biçimde yeniden kullanılması ve kaynak sunucu hatasında eski kopyanın sınırlı biçimde yeniden kullanılması). Destek tarayıcıya/CDN’ye göre değiştiğinden, bunlara güvenmeden önce güncel desteği kontrol edin — ayrıca ileride göreceğimiz üzere Google’ın tarama botu bu ek yönergelerin hiçbirini dikkate almaz.

Sürümlendirilmiş dosya adlarıyla önbelleği geçersiz kılma

Yoğun biçimde önbellekleme yaparken aynı zamanda anında güncelleme yapmanızı sağlayan yöntem şudur: dosya adına bir içerik karması ekleyin — style.x234dff.css. Önbellek anahtarı URL olduğu için dosya değiştirildiğinde URL de değişir; böylece önbellekler yeni sürümü hemen getirirken eski sürümler istediğiniz süre boyunca önbellekte kalabilir. Hem Google’ın web.dev HTTP cache guide belgesi hem de Bing’in kendi ön uç mühendisliği yazısı aynı kalıbı açıklar — Bing, dosya içeriklerini URL’ye karma olarak ekler; böylece “the URL acts as the cache key,” önbellekler tutarlı kalır ve uzun sona erme süreleri kullanılabilir.

bfcache tuzağı — no-store CWV’yi sessizce nasıl zedeler

İşte pek ele alınmayan bir konu. Geri/ileri önbelleği (bfcache), “geri” düğmesine basıldığında sayfanın anında geri yüklenmesini sağlar. bfcache’den yapılan bir geri yükleme LCP/CLS/INP ölçümünü tamamen atladığından, CrUX saha verileriniz açısından tamamen avantajlıdır. Ancak Google’ın bfcache kılavuzuna göre, sayfa belgesinin kendisinde Cache-Control: no-store kullanılması geçmişte tarayıcıların o sayfayı bfcache’de saklamayı reddetmesine neden olmuştur. Bir HTML belgesinin güncel kalması gerekiyorsa ancak geri/ileri önbelleğine uygunluğunu kaybetmesini istemiyorsanız, no-store yerine no-cache veya max-age=0 kullanın.

Bir önbellek “yeterince taze” olup olmadığına nasıl karar verir

Herhangi bir doğrulayıcı devreye girmeden önce önbellek tazeliği kontrol eder: saklanan yanıtın yaşı, Cache-Control tarafından belirlenen tazelik süresini geçti mi (veya açık bir süre belirtilmemişse, önbelleğin tahmin etmesine izin verilen sezgisel süreyi geçti mi)? Age yanıt başlığı, paylaşılan bir önbelleğin yanıtı ne kadar süredir tuttuğunu bildirir; böylece DevTools’ta veya bir CDN günlüğünde tazelik süresinin ne kadarının kaldığını görebilirsiniz. Taze bir yanıt, önbelleğin hiçbir istek göndermeden onu hemen yeniden kullanabileceği anlamına gelir. Eski bir yanıt ise yeniden kullanılmadan önce doğrulanmalıdır; ETag/If-None-Match ve Last-Modified/If-Modified-Since tam bu noktada işe yarar. Bu genel HTTP mekanizmasının Googlebot tarafından kullanılan daha dar kapsamlı biçimi bir sonraki bölümde açıklanmaktadır.

Googlebot önbelleklemeyi nasıl kullanır? (tarama verimliliği açısından)

Google, Aralık 2024 tarihli Crawling December: HTTP caching yazısında alışılmadık ölçüde doğrudan bir çağrı yaptı: tarama botlarının değişmemiş sayfaları yeniden indirmeden geçebilmesi için önbelleklemeyi etkinleştirin. Yazıdaki çarpıcı veri, önbellekten karşılanabilen getirme işlemlerinin azalıyor olmasıdır — 10 yıl önce toplam getirme işlemlerinin yaklaşık 0,026% kadarı önbellekten karşılanabilirken bugün bu oran 0,017%. Oranlar küçük, ancak Google bunların açıkça ters yönde ilerlemesini istiyor.

ETag ve Last-Modified — Google hangisini tercih ediyor?

Google’ın tarama altyapısı iki standart doğrulayıcıyı destekler: ETag (If-None-Match ile) ve Last-Modified (If-Modified-Since ile). Google, ETag değerinin yapılandırılmamış olması ve bu nedenle tarih dizelerinin yol açabileceği ayrıştırma hatalarına daha az açık olması nedeniyle ETag kullanılmasını önemle önerir. İkisi de mevcutsa tarama botları, HTTP standardının gerektirdiği üzere ETag değerini kullanır. Google, CMS’ler gibi diğer uygulamalar bunları kullandığı için yine de her ikisinin ayarlanmasını önerir. Last-Modified kullanıyorsanız tarih HTTP biçimine uymalıdır (örneğin Fri, 4 Sep 1998 19:15:56 GMT); aksi takdirde ayrıştırılamaz.

Tarama botunun sakladığı doğrulayıcı hâlâ eşleşiyorsa sunucunuz gövdesiz bir 304 Not Modified yanıtı döndürür — zaten bütün amaç budur. Google’ın belirttiği gibi, gövdenin olmaması sunucunuzun içerik oluşturmak için işlem gücü veya içeriği aktarmak için bant genişliği harcamaması demektir. (Bu 304 mekanizması, koşullu istekler makalesinde ayrıntılı biçimde ele alınan tarama bütçesi mekanizmasıdır; burada var olduğunu ve her iki açıdan da maliyet tasarrufu sağladığını bilmek yeterlidir.)

Neredeyse herkesin gözden kaçırdığı incelik

Google’ın tarama botu, Cache-Control yönergelerinin tamamını bir tarayıcı veya CDN gibi uygulamaz. Resmî tarama botu genel bakışına göre ETag/Last-Modified dışında “other HTTP caching directives aren’t supported.” Bunun kısmi bir istisnası vardır: Google, bir URL’nin ne zaman yeniden taranacağını belirlemelerine yardımcı olmak için tarama botlarına yönelik olarak isteğe bağlı biçimde max-age ayarlayabileceğinizi söyler — bu kesin bir kilit değil, yeniden tarama ipucudur. Dolayısıyla no-cache, s-maxage, stale-while-revalidate ve benzerleri tarayıcı ile CDN davranışını şekillendirmeye devam eder, ancak Googlebot’un önbellekleme biçimini değiştirmez. Google’ın önbelleğin ne zaman geçersiz kılınacağına ilişkin önerisi de mantıklıdır: önemli değişikliklerde önbelleğin yenilenmesini zorunlu kılın — yalnızca altbilgideki telif hakkı tarihini güncellemek önemli bir değişiklik değildir.

CDN’ler ve tarama

CDN yalnızca hız kazandırmaz. Google’ın tarama altyapısı, URL’leri sunan IP adresinden CDN kullanımını çıkararak CDN destekli sitelere daha yüksek tarama hızları tanıyacak biçimde tasarlanmıştır — CDN destekli bir kaynak sunucunun aynı anda daha fazla isteği karşılayabileceği varsayılır.

Ancak planlama sırasında dikkate alınması gereken bir nokta vardır: soğuk önbellek. Bir URL’ye ilk kez erişildiğinde CDN’nin önbelleği “soğuktur” — URL henüz hiç istenmemiştir; dolayısıyla önbelleğin ısınması için kaynak sunucunuz içeriği en az bir kez sunmalıdır. Google bu nedenle çok sayıda URL’yi aynı anda yayına almanın tarama bütçesine ciddi yük bindirdiği ve tarama hızını birkaç gün boyunca yüksek tuttuğu konusunda uyarır. Büyük bir lansman veya site geçişi yapıyorsanız CDN yardımcı olmaya başlamadan önce kaynak sunucunun her URL için tam yükü üstleneceğini hesaba katın.

CDN yanlış yapılandırması bir tarama riskidir

Önbelleklemeyle bağlantılı en korkutucu sorunlar, önbellek sürelerinin kısa olması değil; botları engelleyen CDN ve WAF yapılandırmalarıdır. Google’ın CDN yazısı, geçici engelleri bildirmek için 503/429 göndermenin tercih edilen yöntem olduğunu açıkça belirtir. Ağ zaman aşımı ise URL’lerin dizinden kaldırılmasına yol açabilecek nihai, “hard” bir hata olarak değerlendirilir. Daha sinsi olanı soft block, yani bot doğrulama ara sayfasıdır. Tarama botu sitenizi değil, yalnızca doğrulama sayfasını görür — bu nedenle Google bunun yerine otomatik istemcilere 503 döndürülmesini önemle önerir. Bir CDN’nin Google’ı sessizce engelleyip engellemediğini kontrol etmenin en kolay yolu, Search Console’daki URL İnceleme aracıdır — oluşturulan görsele bakın; bot doğrulaması veya boş bir sayfa gösteriyorsa CDN sağlayıcınızla görüşün.

Yönlendirmeleri CDN’e devretmek sevdiğim bir tekniktir. Marketing Speak podcast’inde bunu şöyle açıkladım: “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (Alıntıya atla)

Taramayı ve dizine eklemeyi bozan önbellek tuzakları

Çoğu “SEO için önbellekleme” makalesinin atladığı nokta budur. Önbellek yalnızca işlemleri hızlandırmaz — yanlış yapılandırılmış bir önbellek bota yanlış baytları sunarak taramayı veya dizine eklemeyi bozabilir.

Gerçek bir örnek: engelleyici bir robots.txt sunan paylaşılan önbellek. Test ortamı ile canlı site arasında paylaşılan bir CDN önbelleğinden kaynaklandığı anlaşılan, Googlebot’un aralıklı olarak engellendiği bir vakayı araştırdım. Indexed, though blocked by robots.txt yazımda belirttiğim gibi: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” Çözüm, önbelleği ayırmak veya test ortamındaki .txt dosyalarını önbelleğin dışında bırakmaktı. Bir önbellek yanlış yapılandırması doğrudan tarama hatasına neden olmuştu; gerçekten sorun çıkaran risk türü budur.

Aynı ailedeki diğer tuzaklar:

• Botlara güncelliğini yitirmiş içerik sunan eski CDN önbelleği. Uç önbelleğiniz, bir değişikliği yayımlamanızdan uzun süre sonra bile eski sürümü tutuyorsa botlar eski sürümü görmeye devam eder. Yayın sırasında önbelleği temizleyin veya önbellek ömrünü sayfanın gerçekte ne sıklıkta değiştiğine göre belirleyin.
• Vary / User-Agent kaynaklı önbellek parçalanması. Paylaşılan bir önbelleğin anahtarı normalde yalnızca URL’dir; Vary, farklı varyantların ayrı ayrı saklanması için bu anahtara istek başlıklarını (User-Agent veya Accept-Language gibi) ekler. Yanıtı gerçekten değiştiren bir başlık eksik bırakılırsa bir istekte bulunan kişi başka birinin varyantını alabilir — örneğin mobil/masaüstü veya bot/insan içerikleri karışabilir. Vary içine çok fazla başlık eklerseniz önbelleği o kadar çok, birbirine çok yakın anahtara bölersiniz ki isabet oranı neredeyse hiç iyileşmez. Modern tarayıcılar ayrıca gizlilik amacıyla kendi önbelleklerini üst düzey siteye göre bölümler; bu nedenle bir sitede gömülü olarak önbelleğe alınan kaynak, başka bir sitede gömüldüğünde genellikle yeniden kullanılmaz. Bu, Vary mekanizmasından farklıdır; “bu neden önbelleğe alınmıyor?” sorununu araştırırken ikisini birbirine karıştırmamak gerekir.

Süreyle ilgili genel yaklaşımım LCP çalışmasından gelir. Ahrefs’in Largest Contentful Paint kılavuzunda belirttiğim gibi, “Your cache time should be as long as you are comfortable with” — ayrıca “An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” Uzun süreli önbellek, anında temizleme. Hem hızlı hem de güncel kalmanızı sağlayan birleşim budur.

Önbelleğe alma bir sıralama faktörü müdür?

Hayır — doğrudan değil. ETag ayarlamak veya iyi bir Cache-Control politikası için bir sıralama sinyali yoktur. Önbelleğe almanın yaptığı şey, görünürlük için önemli olan iki şeyi beslemektir: sayfa hızı / Core Web Vitals (açık bir sayfa deneyimi girdisi) ve tarama verimliliği (yeni ve güncellenmiş içeriğin ne kadar hızlı keşfedilip yenilendiğini yönetir, dolaylı olarak tazelik hassasiyeti olan sonuçları etkiler). Bunu, sitenizi hızlı ve taranması kolay hale getirdiği için kurun — doğrudan bir sıralama artışı beklediğiniz için değil.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• Önbellekleme = SEO için üç katman: tarayıcı önbelleği, CDN/uç önbelleği ve tarama botunun kendi koşullu istek önbelleği. Her biri biraz farklı biçimde denetlenir.
• Doğrudan bir sıralama faktörü değildir — ancak önemli iki şeyi etkiler: sayfa hızı (TTFB/LCP ve bfcache aracılığıyla tekrarlanan gezinmelerdeki metrikler) ve tarama verimliliği.
• Cache-Control temelleri: max-age tazelik süresini belirler (değişmez, sürümlendirilmiş varlıklar için bir yıl veya daha uzun); no-cache = “sakla ancak yeniden doğrula” (“önbelleğe alma” değildir); no-store = hiçbir biçimde saklama; public/private paylaşılan/CDN önbelleklerinin yanıtı saklayıp saklayamayacağını belirler.
• Önbelleği geçersiz kılma: yoğun biçimde önbellekleme yaparken anında güncelleme yapabilmek için dosya adına bir içerik karması ekleyin (hem Google hem de Bing bu kalıbı kullanır).
• bfcache tuzağı: HTML belgesindeki Cache-Control: no-store, sayfanın geri/ileri önbelleğine uygunluğunu kaybetmesine ve CrUX metriklerinin sessizce kötüleşmesine neden olabilir. Bunun yerine no-cache veya max-age=0 kullanın.
• Googlebot yalnızca ETag ve Last-Modified’ı dikkate alır (ETag’i tercih eder; max-age değerini yeniden tarama ipucu olarak okur). Google’ın ifadesiyle, “other HTTP caching directives aren’t supported.” Eşleşen bir doğrulayıcı, gövdesiz bir 304 Not Modified yanıtı döndürerek işlem gücünden ve bant genişliğinden tasarruf sağlar.
• CDN kullanan sitelere daha yüksek tarama hızları tanınır — ancak bu avantaj yalnızca önbellek ısındıktan sonra geçerlidir. Soğuk önbellekle yapılan lansmanlarda kaynak sunucu yine de her URL’yi en az bir kez sunar; büyük lansmanlar ve geçişler sırasında bunu planlayın.
• En büyük risk yavaş önbellekleme değil, botları engelleyen CDN/WAF yanlış yapılandırmalarıdır (geçici engeller için 503/429 döndürün; soft block ara sayfalarına dikkat edin) ve yanlış içerik sunan eski/paylaşılan önbelleklerdir (ör. engelleyici bir robots.txt).

Resmi dokümantasyon

Arama motorlarından ve araç ekiplerinden birincil kaynak dokümantasyon.

Google

• Crawling December: HTTP caching — Gary Illyes’in Aralık 2024 tarihli yazısı: ETag ile Last-Modified karşılaştırması, 304 mekanizması, azalan önbellekten karşılanabilir getirme istatistiği ve max-age yeniden tarama ipucu.
• Google Crawler (User Agent) Overview — HTTP Caching section — güncel başvuru kaynağı: ETag’in öncelik kuralı ve “other HTTP caching directives aren’t supported” ifadesi.
• Crawling December: CDNs and crawling — Splitt ve Illyes’in CDN önbelleklemesi, daha yüksek tarama hızı kotası, soğuk önbellekle yapılan lansmanlar ve hard block ile soft block arasındaki fark hakkındaki yazısı.
• Serve static assets with an efficient cache policy — Lighthouse/PageSpeed denetimi ve değişmez varlıklar için “a year or longer” önerisi.
• Prevent unnecessary network requests with the HTTP Cache — yönerge başvuru kaynağı ve karma içeren dosya adlarıyla önbelleği geçersiz kılma kalıbı.
• Back/forward cache (bfcache) — HTML belgesindeki no-store yönergesinin neden bfcache uygunluğuna mal olabileceği.
• Crawling December series index — 2024 serisinin tamamı: Googlebot, HTTP önbelleklemesi, çok yönlü gezinme ve CDN’ler.

Bing / Microsoft

• Fast Front-End Performance for Microsoft Bing — Bing mühendislik ekibinin önbellek tutarlılığı ve uzun sona erme süreleri için dosya içeriğini URL’lere karma olarak ekleme yöntemi ile CDN’nin statik varlıkların sunumunu hızlandırmadaki rolü hakkındaki yazısı.
• bingbot Series: Maximizing Crawl Efficiency — önbelleklemenin desteklediği tarama tazeliği mantığı (içerik değişmediğinde daha seyrek tarama).
• Bing Webmaster Guidelines — Bing’in CDN ve performans yönergelerinin bulunduğu merkez.

Kaynaktan alıntılar

Google’ın ve benim yazılarımdaki kamuya açık beyanlar. Her bağlantı, kaynak sayfadaki alıntılanan bölüme doğrudan gider.

Google — Crawling December: HTTP caching

• “While Google’s crawling infrastructure supports heuristic caching mechanisms, in fact always had, the number of requests that can be returned from local caches has decreased: 10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%.” Alıntıya git
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). And, if you have the option, set them both: the internet will thank you. Maybe.” Alıntıya git
• “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.” Alıntıya git

Google — Crawler overview (HTTP Caching section)

• “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
• “Other HTTP caching directives aren’t supported.” Alıntıya git

Google — Crawling December: CDNs and crawling

• “Historically, CDNs’ biggest focus is caching, meaning that once a user requested a URL from your site, CDNs will store the contents of that URL in their caches for a time so your server doesn’t have to serve that file again for a while.” Alıntıya git

Patrick Stox — önbellekleme ve CDN’ler üzerine

• “Your cache time should be as long as you are comfortable with.” — Largest Contentful Paint hakkındaki Ahrefs kılavuzunda bana ait ifade. Alıntıya git
• “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” — paylaşılan bir önbellekten kaynaklandığı belirlenen gerçek bir tarama hatası hakkında bana ait ifade. Alıntıya git
• “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” — Marketing Speak podcast’inde bana ait ifade. Alıntıya git

SEO için önbellekleme — kısa başvuru kılavuzu

Açıklamalarıyla Cache-Control yönergeleri

Googlebot’un gerçekte dikkate aldığı değerler

• ✅ ETag + If-None-Match (Google’ın tercih ettiği doğrulayıcı)
• ✅ Last-Modified + If-Modified-Since (tarihi HTTP’ye göre biçimlendirin: Fri, 4 Sep 1998 19:15:56 GMT)
• ✅ max-age — ancak kural olarak değil, yalnızca yeniden tarama zamanlamasına ilişkin bir ipucu olarak
• ❌ Diğer her şey — “other HTTP caching directives aren’t supported”

Kısa bilgiler

• Google ETag’i tercih eder; ikisi de ayarlanmışsa ETag önceliklidir. Yine de ikisini de ayarlayın (CMS’ler bunları kullanır).
• Eşleşen doğrulayıcı → 304 Not Modified, gövde yok → işlem gücünden ve bant genişliğinden tasarruf.
• Chrome/Lighthouse: değişmez varlıkları bir yıl veya daha uzun süreyle önbelleğe alın.
• CDN’lere daha yüksek tarama hızı kotası tanınır — ancak bu yalnızca önbellek ısındıktan sonra geçerlidir.
• Geçici engelleme mi var? 503/429 döndürün; hiçbir zaman hata içeren sessiz bir 200 yanıtı veya bot ara sayfası sunmayın.
• HTML belgesindeki no-store, sayfanın bfcache uygunluğunu kaybetmesine neden olabilir → no-cache/max-age=0 kullanın.
• “Google önbelleği” (cache: operatörü) 2024’te kullanımdan kaldırıldı — HTTP önbelleklemesiyle ilgisi yoktur.

Önbellekleme mitleri ve hataları

Her biri: neden yanlış olduğu ve bunun yerine ne yapılması gerektiği.

Mit: “Sayfamı önbelleğe almak sıralamamı artırır.” Neden yanlış: Önbellekleme yapılandırması için bir sıralama sinyali yoktur. Google’ın Arama İlişkileri ekibi, önbelleklemenin bir sıralama faktörü olmadığını açıkça belirtti. Bunun yerine: Önbelleği gerçek kazanımlar için kurun — sayfa hızı / Core Web Vitals ve tarama verimliliği — bunların her ikisi de görünürlüğü dolaylı olarak etkiler. Doğrudan bir artış beklemeyin.

Mit: “Google’ın önbelleği ile HTTP önbelleği aynı şeydir.” Neden yanlış: cache: arama operatörü ve önbelleğe alınmış sayfa görüntüleyici, 2024’te tamamen kullanımdan kaldırılan kullanıcıya yönelik bir anlık görüntü özelliğiydi. HTTP önbelleği (Cache-Control/ETag) ilgisiz bir altyapıdır. Bunun yerine: Eksik “önbelleğe alınmış sürümü” yok sayın — bu, önbellek kurulumunuz hakkında hiçbir şey söylemez. Önbelleğinizi başlıklara ve tarama/performans davranışına göre değerlendirin.

Mit: “no-cache, ‘önbelleğe alma’ anlamına gelir.” Neden yanlış: no-cache, “sakla, ancak kullanmadan önce sunucuyla yeniden doğrula” anlamına gelir. 304 yeniden doğrulama akışına yine de olanak tanır. Saklamayı gerçekten engelleyen yönerge no-store’dur. Bunun yerine: Yeniden doğrulama yoluyla güncellik istediğinizde no-cache kullanın; no-store yönergesini hiçbir zaman saklanmaması gereken gerçekten hassas yanıtlar için ayırın.

Mit: “Uzun bir önbellek süresi, Google’ın içeriği sonsuza dek eski görmesini sağlar.” Neden yanlış: Google’ın tarayıcısı, max-age değerinizden bağımsız olarak yeniden taramada ETag/Last-Modified aracılığıyla doğrular; max-age bir yeniden tarama ipucudur, Google’ın yeniden getirmesini durduran bir kilit değildir. Bunun yerine: Uzun süre önbelleğe alın, ancak önemli içerik değişikliklerinde gerçek bir önbellek kırıcı (yeni ETag/Last-Modified veya URL) tetikleyin — tam olarak Google’ın kendi önerisi.

Mit: “Bir CDN, tarama bütçesi sorunlarını otomatik olarak çözer.” Neden yanlış: Bir CDN yalnızca önbelleği sıcakken yardımcı olur; kaynak sunucu yine de her URL’ye en az bir kez hizmet verir (soğuk önbellek sorunu) ve yanlış yapılandırılmış bir CDN tarayıcıları engelleyebilir ve işleri daha da kötüleştirebilir. Bunun yerine: Büyük lansmanlarda/geçişlerde kaynak yükünü planlayın ve CDN’in botları engellemediğini doğrulayın (URL İnceleme ve geçici engeller için 503/429 döndürün).

Mit: “Ayarladığım her Cache-Control yönergesi Googlebot’un tarama biçimini değiştirir.” Neden yanlış: Google’ın belgelerine göre tarama botu, ETag/Last-Modified (ve isteğe bağlı max-age ipucu) dışında “other HTTP caching directives aren’t supported” ilkesini uygular. Bunun yerine: Tarayıcı ve CDN davranışını ayarlamak için stale-while-revalidate, s-maxage, no-cache vb. kullanın — ancak Googlebot’un önbelleklemesini etkilemek için ETag/Last-Modified’a güvenin.

Önbellekleme yapılandırmalarının öncesi ve sonrası

1. Önbellek politikası olmayan statik varlık → PageSpeed uyarısı gider

• Öncesi: style.css Cache-Control olmadan sunulur; Lighthouse “Statik varlıkları verimli bir önbellek politikasıyla sunun” uyarısı verir, tekrarlanan ziyaretlerde yeniden indirilir.
• Sonrası: style.a1b2c3.css olarak yeniden adlandırın ve Cache-Control: public, max-age=31536000, immutable sunun. Tekrarlanan ziyaretler indirmeyi atlar; bir içerik değişikliği yeni bir dosya adı anlamına gelir ve anında geçersiz kılınır.

2. İstediğiniz “taze” HTML belgesi → bfcache kaybı

• Önce: HTML’de Cache-Control: no-store kullanarak tazeliği zorluyorsunuz. Yan etkisi: sayfa bfcache için uygunluğunu kaybeder, bu yüzden “geri” gezinmeleri LCP/CLS/INP’yi yeniden ölçer ve CrUX saha verilerinizi olumsuz etkiler.
• Sonra: no-cache (veya max-age=0) kullanın — hâlâ tazelik için yeniden doğrulama yaparsınız, ancak sayfa bfcache uygunluğunu korur ve tekrarlanan gezinmeler anında geri yüklenir.

3. Hazırlık ve üretim ortamları arasında paylaşılan önbellek → Googlebot’un aralıklı olarak engellenmesi

• Öncesi: Test ve canlı ortamlar aynı CDN önbelleğini paylaşır. Test sürümü etkin olduğunda önbelleğe alınmış robots.txt engelleyici bir yönerge içerir; bu nedenle Googlebot aralıklı olarak görmemesi gereken bir disallow yönergesi görür.
• Sonrası: Önbelleği ortamlar arasında ayırın — veya .txt dosyalarını test ortamının önbelleğinden hariç tutun — böylece canlı robots.txt hiçbir zaman hazırlık ortamı önbelleğinden sunulmaz. (Bu, Indexed, though blocked by robots.txt yazımda ele aldığım gerçek bir vakadır.)

4. CDN arkasında büyük lansman → beklenmeyen tarama artışı

• Öncesi: CDN’nin yükü karşılayacağını varsayarak 50 000 yeni URL’yi aynı anda yayımlarsınız. Her URL soğuk önbellek ıskası olduğundan kaynak sunucu her birini en az bir kez sunar ve tarama hızı günlerce yüksek kalır.
• Sonrası: Lansmandan önce önbelleği ısıtın (veya yayını aşamalı gerçekleştirin); CDN koruma sağlamaya başlamadan önce kaynak sunucunun her URL için tam yükü üstleneceğini öngörün ve buna yetecek kaynak ayırın.

HTTP önbellekleme kurulum kontrol listesi

• Statik varlıklarda (görseller, CSS, JS, yazı tipleri) uzun bir max-age bulunur (değişmez/sürümlendirilmiş dosyalar için bir yıl+).
• Yoğun biçimde önbellekleme yaparken anında geçersiz kılabilmek için sürümlendirilmiş/karma içeren dosya adları kullanılır.
• ETag ayarlanmıştır (Google’ın tercih ettiği doğrulayıcı); Last-Modified da doğru biçimlendirilmiş bir HTTP tarihiyle ayarlanmıştır.
• Bir doğrulayıcı hâlâ eşleştiğinde sunucunuz gövdesiz bir 304 Not Modified yanıtı döndürür.
• Güncel kalması gereken HTML belgeleri no-store değil, no-cache/max-age=0 kullanır (bfcache uygunluğunu korumak için).
• Önemli bir içerik değişikliği, yalnızca altbilgi tarihinin değiştirilmesini değil, gerçek bir önbellek geçersiz kılma işlemini (yeni ETag/Last-Modified/URL) tetikler.
• Kaynak sunucunun önünde bir CDN vardır; paylaşılan önbelleklerin paylaşılması gereken yanıtları saklayabilmesi için public/s-maxage ayarlanmıştır.
• Botların eski içerik almaması için yayın sırasında önbellek temizlenir.
• Hazırlık ve üretim ortamları, robots.txt veya diğer denetim dosyaları için aynı önbelleği paylaşmaz.
• Geçici engellemeler, hata içeren sessiz 200 sayfaları veya bot ara sayfaları yerine 503/429 döndürür.
• Search Console’daki URL İnceleme aracı gerçek sayfanızı (bir doğrulama sayfasını veya boş sayfayı değil) gösterir — bu, CDN/WAF’ın Googlebot’u engellemediğini doğrular.

Güncellenen dosyalar dağıtımdan sonra bayat kalıyor

Belirti: Ziyaretçiler eski bir CSS, JavaScript veya görsel dosyasını almaya devam eder. Olası neden: Uzun ömürlü önbellek, baytları değişmiş dosya için aynı URL’yi kullanır. Çözüm: Değişmez varlıkları içerik karması içeren dosya adlarıyla yayımlayın ve HTML referansını güncelleyin; eski uç nesnesini yalnızca URL’nin kendisi yeniden kullanılmışsa temizleyin. Yeni URL’nin yüklendiğini doğrulayın.

Googlebot değişmeyen sayfaları yeniden indiriyor

Belirti: Günlükler, değişmemiş HTML için tekrar tekrar tam 200 yanıtları gösterir. Olası neden: ETag/Last-Modified doğrulayıcıları eksik veya kararsızdır. Çözüm: Kararlı ve içeriği doğru yansıtan bir doğrulayıcı gönderin, ardından koşullu bir isteği test edin. Doğru çalışan yeniden doğrulama, temsil değişmemişse 304 döndürür.

Farklı kullanıcılar yanlış önbellek varyantını alıyor

Belirti: Dil, cihaz, oturum durumu veya kişiselleştirilmiş içerik kullanıcılar arasında sızar. Olası neden: Paylaşılan önbellek anahtarı, yanıtı değiştiren boyutu içermiyordur veya özel içerik public olarak işaretlenmiştir. Çözüm: Önbellek anahtarını ve Vary davranışını düzeltin, özel yanıtları uygun biçimde işaretleyin, kirlenmiş nesneleri temizleyin ve birden fazla varyantı yeniden test edin.

CDN önbelleği asla isabet bildirmiyor

Belirti: Önbelleğe alınmaya uygun tekrarlanan istekler kaynak sunucuya ulaşmaya devam eder. Olası neden: no-store/private, çerezler, aşırı parçalanmış bir önbellek anahtarı veya uç katmanı atlama kuralı. Çözüm: Yanıt başlıklarını ve CDN önbellek durumu başlıklarını inceleyin, yalnızca ilgili içerik sınıfı için güvenli kuralları değiştirin ve ardından bir isabeti doğrulamak için aynı önbellek anahtarını iki kez isteyin.

Önbelleği yalnızca dosya uzantısına göre değil, temsil riskine göre sınıflandırın

Politika atamadan önce her yanıtı sınıflandırın:

1. Değişmez genel varlık: içerik karmalı CSS, JS, yazı tipleri veya görseller uzun bir ömür kullanabilir çünkü değişen baytlar yeni bir URL alır.
2. Genel ancak değişen belge: HTML kısa süre saklanabilir veya ETag/Last-Modified ile yeniden doğrulanabilir; tazelik ve hızlı düzeltme, maksimum TTL’den daha önemlidir.
3. Kullanıcıya özel yanıt: kişiselleştirme temsilden kaldırılmadıkça veya önbellek anahtarında doğru şekilde ayrılmadıkça paylaşılan önbelleğe alma güvenli değildir.
4. Hassas yanıt: içeriği ifşa etmek yerine performans ödünleşimini kabul ederek verinin gerektirdiği sıkı politikayı kullanın.

Yararlı soru “Bu türü ne kadar süre önbelleğe alabilirim?” değildir. Sorulması gereken şudur: “Bu değişiklikten sonra bu temsilin aynısı bu istekte bulunan kişi için yeniden kullanılırsa ne yanlış olabilir?”

Tazelik, doğruluk, verimlilik

Bir önbelleğe alma politikası üç testi geçmelidir: tazelik (değişiklikler vaat edildiğinde görünür), doğruluk (doğru istekçi doğru varyantı alır) ve verimlilik (değişmeyen baytlar gereksiz yere yeniden üretilmez veya aktarılmaz). Yüksek bir isabet oranı, yanlış yanıtı sunuyorsa bir başarı değildir.

HTTP önbelleklemesini inceleme araçları

• Tarayıcı DevTools Network paneli — Cache-Control, ETag, Last-Modified, Age, Vary değerlerini ve yanıtın bellekten, diskten veya ağdan gelip gelmediğini inceleyin.
• curl — tarayıcı önbelleğinin oluşturduğu belirsizlik olmadan HEAD ve koşullu istekler gönderin; ilk doğrulayıcıyı If-None-Match veya If-Modified-Since ile karşılaştırın.
• PageSpeed Insights / Lighthouse — verimsiz önbellek politikalarına sahip statik varlıkları bulun; makalede resmî Lighthouse cache-policy guidance belgesine bağlantı verilmektedir.
• CDN analizleri ve günlükleri — herkese açık yanıtı gerçekten sunan katmanda isabet/ıska/atlama durumunu, önbellek anahtarlarını, kaynak sunucu isteklerini ve temizleme işlemlerini inceleyin.
• Sunucu günlükleri — Googlebot’un değişmemiş sayfalar için tam gövdeler yerine 304 yeniden doğrulama yanıtları aldığını doğrulayın.

Bir önbellek değişikliğinin çalıştığını kanıtlayın

Koşullu istek testi

Çalıştırılacak test: yanıtı getirin, ETag değerini kopyalayın, ardından If-None-Match ile isteyin. Beklenen sonuç: değişmeyen bir temsil, yanıt gövdesi olmadan 304 döndürür. Başarısızlık yorumu: doğrulayıcı eksik, kararsız veya yok sayılıyor. İzleme penceresi: anında. Geri alma tetikleyicisi: değişen içerik yanlışlıkla 304 ile yanıtlanıyor veya doğrulayıcı varyantlar arasında çakışıyor.

Sürümlü varlık testi

Çalıştırılacak test: değişen baytları yeni bir içerik karmalı URL altında dağıtın ve ona başvuran bir sayfayı yeniden yükleyin. Beklenen sonuç: yeni URL yeni varlığı döndürürken eski URL önbellekte kalabilir. Başarısızlık yorumu: HTML hâlâ eski varlığa başvuruyor veya derleme karmayı değiştirmedi. İzleme penceresi: HTML/CDN yayılımından hemen sonra. Geri alma tetikleyicisi: yeni varlıkta bozuk stil veya komut dosyası hataları.

Paylaşılan önbellek varyant testi

Çalıştırılacak test: Anlamlı her varyantı CDN üzerinden isteyin, her isteği tekrarlayın ve gövdeyi, önbellek anahtarını/durumunu ve Vary değerini karşılaştırın. Beklenen sonuç: İstekte bulunan herkes doğru temsili alır ve yalnızca güvenli varyantlar yeniden kullanılır. Başarısızlık yorumu: Önbellek anahtarında bir boyut eksiktir veya özel içerik paylaşılmaktadır. İzleme penceresi: Hemen ve ardından üretim günlüklerinin incelenmesi. Geri alma tetikleyicisi: Bir kullanıcının başka bir kullanıcıya ait kişiselleştirilmiş veya dile özel yanıtı alması.

Kendinizi test edin: SEO için önbellekleme

HTTP önbelleğe alma, CDN’ler ve tarama hakkında beş hızlı soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü