Bir sayfa ilk ziyarette ağır, ikinci ziyarette akıcı açılıyorsa farkın büyük kısmı HTTP cache başlıklarından gelir. Bu başlıklar tek başına bir sıralama faktörü değildir, ama hız, sunucu yükü ve kullanıcı deneyimi üzerinde doğrudan etki yaratır.
Yanlış ayarlar güncel olmayan içerik, boşa giden istekler ve gereksiz maliyet üretir. Doğru ayarlar ise tekrar ziyaretleri hızlandırır, altyapıyı rahatlatır ve teknik SEO tarafını daha sağlıklı hale getirir. Önce temel mantığı netleştirelim.
HTTP önbellekleme neden performans ve SEO için önemlidir?
Tarayıcı, daha önce aldığı bir dosyayı tekrar kullanabiliyorsa sunucuya yeniden gitmez ya da en azından daha hafif bir doğrulama yapar. Bu yüzden CSS, JavaScript, görseller ve fontlar daha hızlı yüklenir. Sayfa açılışı kısalır, ağ trafiği azalır.
SEO tarafında etki daha dolaylıdır. HTTP cache başlıkları Google’da tek başına sizi yukarı taşımaz. Ancak daha hızlı tekrar ziyaretler, daha stabil yanıt süreleri ve daha düşük sunucu baskısı üretir. Bu da kullanıcı memnuniyetine, Core Web Vitals ölçümlerine ve yoğun sitelerde taranabilirliğe yardım eder. Teknik altyapıyı bu açıdan ele almak isteyen ekipler için performans odaklı teknik SEO uygulamaları çoğu zaman ilk adımdır.
Googlebot, gerçek bir kullanıcı tarayıcısıyla bire bir aynı davranmaz. Yani “cache ayarladım, crawl budget anında arttı” demek doğru olmaz. Yine de sunucunun daha az yorulması, ani trafiklerde daha tutarlı yanıt vermesi ve kaynakların daha verimli sunulması teknik açıdan önemli bir avantajdır.
Ayrıca HTTP cache ile tarayıcının geri-ileri önbelleği aynı şey değildir. Yine de ikisi de algılanan hızı etkiler. Tarayıcıdaki bu ayrı katmanı görmek isterseniz geri-ileri önbellek açıklaması iyi bir başlangıçtır.

Cache-Control direktifleri ne anlatır?
Cache-Control, bir yanıtın kim tarafından, ne kadar süreyle ve hangi şartla önbellekte tutulacağını söyler. Asıl güç buradadır, çünkü aynı kuralı tüm içeriklere vermek çoğu zaman hatalıdır. Ana sayfa, ürün resmi, oturumlu hesap sayfası ve JSON API aynı mantıkla önbelleğe alınmamalıdır.
Aşağıdaki tablo, en sık kullanılan direktifleri pratik karşılığıyla özetliyor:
| Direktif | Anlamı | Tipik kullanım |
|---|---|---|
public | Yanıt tarayıcıda ve paylaşımlı önbelleklerde tutulabilir | Sürümlenmiş CSS, JS, görsel, font |
private | Yanıt yalnızca kullanıcı tarayıcısında tutulmalı | Oturumlu panel, kişisel sayfalar |
max-age=3600 | Yanıt 1 saat boyunca taze kabul edilir | Sık değişmeyen içerikler |
s-maxage=600 | Paylaşımlı önbellek için 10 dakikalık ayrı süre tanımlar | CDN üstündeki HTML veya API yanıtı |
no-cache | Saklanabilir, ama kullanmadan önce yeniden doğrulama ister | Sık güncellenen HTML |
no-store | Hiçbir yerde saklanmamalı | Ödeme, bankacılık, tek kullanımlık hassas veriler |
immutable | Taze süresi içinde tekrar doğrulama yapma | Dosya adı sürümlenmiş statik varlıklar |
stale-while-revalidate=86400 | Eski kopyayı kısa süre sun, arka planda yenile | Trafiği yüksek ama anlık kritik olmayan içerik |
Tablodaki en sık karıştırılan iki ifade no-cache ve no-store olur. İlki “saklama” demez, “kullanmadan önce sor” der. İkincisi ise gerçekten saklamayı kapatır.
no-cache, önbelleği yasaklamaz. Yeniden doğrulama zorunluluğu getirir.
Pratik örnek daha net anlatır. Dosya adı değişen bir stil dosyasında public, max-age=31536000, immutable oldukça iyi çalışır. Çünkü app.4f92.css değiştiğinde zaten URL de değişir. Buna karşılık haber ana sayfası gibi sık güncellenen bir HTML belgesi için no-cache ya da kısa bir max-age daha güvenlidir.
private ile s-maxage birlikte düşünülmelidir. Tarayıcı önbelleği ile CDN aynı şey değildir. Örneğin kullanıcıya özel bir sayfa tarayıcıda kısa süre tutulabilir, ama paylaşımlı önbelleğe asla düşmemelidir. Buna karşılık anonim kullanıcılara açık bir kategori sayfası tarayıcıda 60 saniye, CDN katmanında 10 dakika saklanabilir.
no-store konusunda da ölçülü davranmak gerekir. Tüm siteye körlemesine uygulanırsa tekrar ziyaretler yavaşlar. Hatta bazı durumlarda geri-ileri önbellek davranışını da etkileyebilir. Chrome ekibinin no-store ve bfcache notları bu noktayı açık biçimde anlatıyor.

ETag ve Last-Modified karşılaştırması
Cache-Control tazelik süresini yönetir. ETag ve Last-Modified ise yeniden doğrulama anında devreye girer. Tarayıcı, elindeki kopyayı hemen indirmek yerine “Bendeki sürüm hâlâ geçerli mi?” diye sorar. Sunucu da değişiklik yoksa 304 Not Modified döner. Böylece gövde verisi yeniden taşınmaz.
Kısa karşılaştırma aşağıda:
| Başlık | Nasıl çalışır | Güçlü yanı | Dikkat edilmesi gereken |
|---|---|---|---|
ETag | Kaynağa bir kimlik verilir, tarayıcı If-None-Match ile sorar | İçerik değişimini daha hassas yakalar | Çoklu sunucuda tutarsız üretim 304 avantajını bozabilir |
Last-Modified | Son değişim zamanı gönderilir, tarayıcı If-Modified-Since ile sorar | Basit ve hafiftir | Zaman damgası kaba kalabilir, küçük değişimleri kaçırabilir |
Özet basit. Dosya veya yanıt küçük farklarla değişiyorsa ETag daha isabetli olabilir. Statik dosyalarda ve klasik içerik sunumunda Last-Modified çoğu zaman yeterlidir. Birçok sistem ikisini birlikte gönderir ve bu gayet normaldir.
Buradaki kritik nokta tutarlılıktır. Bir kümede çalışan sunucular aynı dosya için farklı ETag üretirse istemci her istekte yeniden indirme eğiliminde olur. Benzer şekilde yanlış saat ayarı olan bir sunucu, Last-Modified değerini anlamsız hale getirebilir.
Nginx, Apache ve CDN tarafında doğru yaklaşım
Kullandığınız sunucu yazılımı ne olursa olsun mantık değişmez. Kurallar içerik türüne göre ayrılmalı, sonra origin ve CDN katmanında uyumlu çalışmalıdır. Bu kararlar yayın akışı, indeksleme ve performans hedefleriyle birleştiği için çoğu ekip bunu daha geniş bir kapsamlı SEO strateji danışmanlığı içinde ele alır.
En temiz kurgu genelde şöyledir. Sürümlenmiş statik dosyalar uzun süre önbellekte tutulur. HTML belgeleri kısa süre saklanır ya da her kullanım öncesi doğrulanır. Oturumlu ve kişisel alanlar private kalır, hassas işlemler gerekirse no-store alır.
CDN kullanıyorsanız s-maxage büyük fark yaratır. Tarayıcıya kısa bir süre verirken paylaşımlı önbelleğe daha uzun süre tanıyabilirsiniz. Buna stale-while-revalidate eklendiğinde, çok istek alan sayfalarda kullanıcı eski ama kabul edilebilir bir kopyayı anında görür, CDN de arka planda yenisini çeker.
Kural yazarken tek kaynaklı bir belge tutmak da önemlidir. Nginx ayrı, Apache ayrı, CDN ayrı davranırsa hata ayıklamak zorlaşır. Aynı URL için hangi başlığın son sözü söylediği net olmalıdır.
Önbellek optimizasyonu için kontrol listesi ve sık hatalar
Ayarların kağıt üstünde doğru görünmesi yetmez. Tarayıcı ağı, tekrar ziyaret ve CDN yanıtı birlikte test edilmelidir.

Uygulanabilir kontrol listesi
- HTML, statik dosya, API ve kişisel sayfaları ayrı önbellek sınıflarına ayırın.
- Uzun süreli önbellek vereceğiniz statik dosyalarda dosya adı sürümlemesi kullanın.
- Tarayıcı politikası ile paylaşımlı önbellek politikasını ayrı düşünün, gerekirse
s-maxageekleyin. ETag,Last-Modified,AgeveCache-Controlbaşlıklarını tekrar ziyaret testlerinde kontrol edin.- Aynı URL’yi anonim kullanıcı, giriş yapmış kullanıcı ve mobil tarayıcı ile ayrı test edin.
304 Not Modifiedyanıtlarının gerçekten geldiğini doğrulayın.- CDN varsa origin başlıklarını devralıp devralmadığını açık biçimde belgeleyin.
Sık yapılan hatalar
- Tüm siteye
no-storeverip tekrar ziyaret performansını bozmak. - HTML belgelerine bir yıl
max-agetanımlayıp güncel içeriğin geç gelmesine yol açmak. - Sürümsüz CSS ve JS dosyalarına uzun TTL vermek.
- Kişiye özel sayfalarda
publickullanmak. no-cacheileno-storekavramlarını karıştırmak.- Çoklu sunucuda tutarsız
ETagüretmek. - CDN ve origin katmanında çakışan kurallar bırakmak.
Kısa bir temel çerçeve görmek isterseniz HTTP başlıklarının önemi ve önbellekleme türleri özeti faydalı kaynaklardır.
Sonuç
İlk ve ikinci ziyaret arasındaki hız farkı çoğu zaman sunucu gücünden değil, doğru cache politikasından gelir. Bu yüzden HTTP cache başlıklarını yalnızca performans ayarı gibi görmek eksik kalır.
Doğru kurgu, tekrar ziyaretleri hızlandırır, altyapıyı rahatlatır ve teknik SEO tarafında daha temiz bir yapı kurar. En iyi sonuç da tek bir sihirli başlıktan değil, içerik türüne göre verilmiş tutarlı kararlardan çıkar.
This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.