Blog details

HTTP Cache Başlıkları Hız ve SEO’yu Nasıl Etkiler

HTTP Cache Başlıkları Hız ve SEO'yu Nasıl Etkiler

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.

A sleek silver laptop rests on a dark minimalist desk, illuminated by a focused spotlight against a deep shadow. Intricate code lines are subtly visible on the screen during nighttime.

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:

DirektifAnlamıTipik kullanım
publicYanıt tarayıcıda ve paylaşımlı önbelleklerde tutulabilirSürümlenmiş CSS, JS, görsel, font
privateYanıt yalnızca kullanıcı tarayıcısında tutulmalıOturumlu panel, kişisel sayfalar
max-age=3600Yanıt 1 saat boyunca taze kabul edilirSık değişmeyen içerikler
s-maxage=600Paylaşımlı önbellek için 10 dakikalık ayrı süre tanımlarCDN üstündeki HTML veya API yanıtı
no-cacheSaklanabilir, ama kullanmadan önce yeniden doğrulama isterSık güncellenen HTML
no-storeHiçbir yerde saklanmamalıÖdeme, bankacılık, tek kullanımlık hassas veriler
immutableTaze süresi içinde tekrar doğrulama yapmaDosya adı sürümlenmiş statik varlıklar
stale-while-revalidate=86400Eski kopyayı kısa süre sun, arka planda yenileTrafiğ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.

Glowing blue and golden lines interconnect at bright nodes against a dark backdrop. This intricate graphic illustrates complex digital pathways, representing dynamic server responses and efficient browser caching processes within modern architecture.

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ıkNasıl çalışırGüçlü yanıDikkat edilmesi gereken
ETagKaynağ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-ModifiedSon değişim zamanı gönderilir, tarayıcı If-Modified-Since ile sorarBasit ve hafiftirZaman 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.

A dark themed digital dashboard displays a structured technical checklist with highlighted status indicators. Sleek, high-contrast UI elements glow softly against the background, emphasizing precision for professional performance and data management.

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-maxage ekleyin.
  • ETag, Last-Modified, Age ve Cache-Control baş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 Modified yanı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-store verip tekrar ziyaret performansını bozmak.
  • HTML belgelerine bir yıl max-age tanı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 public kullanmak.
  • no-cache ile no-store kavramları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.