CDN Nedir? Cache Hit/Miss ve SEO İçin Teknik Kontrol Rehberi

Bir CDN’i etkinleştirmek, sitenin her yanıtını otomatik olarak önbelleğe almaz; önbellekteki kopyanın güncel veya Googlebot’a erişilebilir olduğunu da tek başına kanıtlamaz. SEO incelemesinde asıl soru, hangi URL’nin hangi yanıt başlıklarıyla hangi cache katmanından döndüğüdür.

Bu rehber CDN’in ne yaptığını kısa bir modelle açıklar; ardından HTML, görsel ve sürümlenmiş statik dosyalar için ayrı önbellek kararlarını, HIT/MISS yanıtlarını ve CDN kaynaklı tarama sorunlarını nasıl test edeceğinizi gösterir. Sağlayıcı paneli erişiminiz yoksa da, herkese açık URL’lerde curl ile gözlemleyebileceğiniz sinyalleri ve bunların sınırlarını bulabilirsiniz.

CDN nedir, ne değildir?

CDN (Content Delivery Network / içerik dağıtım ağı), origin adı verilen asıl sunucuyla ziyaretçi arasına yerleştirilen dağıtık bir katmandır. İsteği uygun edge noktasına yönlendirebilir; yapılandırma uygunsa yanıtı orada tutup sonraki istekte yeniden kullanabilir. Bazı CDN’ler ayrıca WAF, bot yönetimi ve trafik azaltma özellikleri sunar. Bunlar sağlayıcıya ve seçilen kurallara bağlıdır; her CDN her HTML sayfasını önbelleğe almaz.

CDN bir web hosting hizmetinin yerine otomatik olarak geçmez. Origin içeriğin asıl kaynağı olmaya devam eder. CDN’in öne eklenmesi de sunucu kodunu, veritabanı sorgularını veya tarayıcıdaki JavaScript işini kendiliğinden hızlandırmaz. Gerçek etki; isteğin doğru cache key ile eşleşmesine, cache hit oranına, yanıtın boyutuna, kullanıcının konumuna ve origin’in yanıt süresine bağlıdır.

Sağlayıcı ve barındırma seçimi için domain ve hosting rehberine bakın; burada CDN’in istek/yanıt ve arama taraması tarafını inceliyoruz. Genel sayfa performansı için ayrıca sayfa yüklenme hızı optimizasyonu rehberi var.

Bir istekte cache miss’ten hit’e ne olur?

Bir ziyaretçi veya bot URL istediğinde CDN önce isteği ve cache key’i değerlendirir. İçerik uygun ve anahtarla eşleşen taze bir yanıt varsa edge kopyayı döndürür: bu genellikle cache hit olarak adlandırılır. Uygun yanıt henüz o cache katmanında yoksa CDN origin’e gider, yanıtı alır ve kurallar izin veriyorsa saklar: bu ilk istek cache miss olabilir. Daha sonraki istekler aynı edge/kural ve anahtara denk gelirse hit görebilir.

İlk miss normaldir. Google, CDN arkasında ilk kez istenen URL’nin önbelleğinin soğuk olabileceğini ve origin’in o yanıtı en az bir kez sunması gerektiğini özellikle açıklıyor. Bu nedenle binlerce yeni URL’yi aynı anda açmak, CDN kullanılıyor diye origin yükünü ortadan kaldırmaz. Google’ın CDN ve tarama yazısı cache soğukluğunun yanı sıra WAF kaynaklı sert engel ve bot doğrulama ekranlarını da ele alıyor.

HTML, görsel ve sürümlenmiş varlıklar için tek cache kuralı kullanmayın

Önbellek politikası içerik türüne ve yanıtın kişiye özel olup olmadığına göre belirlenmelidir. Aşağıdaki tablo başlangıç çerçevesidir; doğrudan sunucuya kopyalanacak evrensel bir konfigürasyon değildir.

Yanıt	İncelenecek durum	Uygun test sorusu
Parmak izli CSS/JS (app.a1b2c3.js)	URL içerik değişince yeni hash alıyor mu? Cache-Control uzun tazelik süresiyle immutable kullanmaya elverişli mi?	İki istekten sonra aynı sürüm ve beklenen cache davranışı geliyor mu?
Sık değişebilen görsel veya font	Dosya URL’si değişiklikte sürümleniyor mu? Dönüştürme/WebP varyantı ve Vary başlığı doğru mu?	Content-Type, URL, boyut ve varyant birbiriyle uyumlu mu?
Genel HTML	CDN bu route’u cache’liyor mu; kısa TTL, yeniden doğrulama veya bypass mı seçilmiş? Yayın sonrası yeni HTML hangi yolla görünür?	HTML’deki canonical, robots ve kaynak bağlantıları eski bir edge kopyasında kalıyor mu?
Giriş, sepet veya kullanıcıya göre değişen yanıt	Cookie/Authorization, cache key ve private/no-store davranışı nasıl?	Kullanıcıya özel içerik başka oturuma veya paylaşılan cache’e sızabilir mi?
Parametreli URL	CDN tüm parametreleri key’e katıyor mu, seçili parametreleri mi yok sayıyor?	Filtre/sıralama parametresi doğru içeriği veriyor ve gereksiz cache parçalanması yaratmıyor mu?

Dosya adına hash eklemek, içeriği değiştiğinde yeni URL sunmaya yarar. Bu örüntü uzun süreli statik varlık cache’ini daha güvenli kılar; URL aynı kalırken dosyayı değiştirmek eski kopyanın kullanıcıda kalmasına yol açabilir. MDN’in HTTP caching rehberi ve Cache-Control referansı no-cache, no-store, private, max-age ve immutable direktiflerinin aynı anlama gelmediğini gösterir. Özellikle no-cache, saklamayı yasaklamaz; yeniden kullanmadan önce doğrulama ister. Hassas oturum yanıtlarında güvenlik gereksinimini ayrıca değerlendirin.

HTML için public, max-age=31536000 gibi uzun bir kuralı genelleyip kullanıcıya özel sayfalara uygulamayın. Öte yandan tüm siteyi düşünmeden no-store ile işaretlemek de tarayıcı geri/ileri önbelleği gibi davranışları etkileyebilir. Paylaşılan cache ile tarayıcı cache’inin ihtiyaçlarını ayırın; CDN kuralı, origin başlığı ve uygulama cache key’i birlikte incelensin.

HIT, MISS ve Age başlığını nasıl yorumlarsınız?

Önce herkese açık, oturum açma gerektirmeyen bir HTML URL’sini ve hash içeren bir statik dosyayı seçin. HEAD yerine mümkünse gerçek GET yanıtını iki kez alın; bazı origin/CDN kuralları yöntemlere göre farklı davranabilir. Linux/macOS/Git Bash örneği:

curl -sS -D - -o /dev/null https://www.example.com/
curl -sS -D - -o /dev/null https://www.example.com/
curl -sS -D - -o /dev/null https://www.example.com/assets/app.a1b2c3.js

Windows PowerShell’de curl takma adı yerine curl.exe kullanın ve çıktı hedefini NUL verin:

curl.exe -sS -D - -o NUL https://www.example.com/
curl.exe -sS -D - -o NUL https://www.example.com/
curl.exe -sS -D - -o NUL https://www.example.com/assets/app.a1b2c3.js

Her yanıtta HTTP durumunu, Content-Type, Cache-Control, Age, ETag, Vary, Server-Timing ve varsa X-Cache veya sağlayıcıya özgü cache başlığını kaydedin. Cloudflare kullanılıyorsa CF-Cache-Status değerleri Cloudflare’ın kendi yanıt kararını belirtir; diğer sağlayıcılarda başka başlıklar ve kurallar olabilir. Cloudflare belgelerine göre HIT cache’te bulunan yanıtı, MISS cache’e uygun olup ilgili istekte bulunmayan yanıtı gösterir; DYNAMIC ve BYPASS ise farklı aşamalarda cache kullanılmamasını anlatır. Age her yanıt durumunda bulunmaz ve varsa kaynağını kontrol etmek gerekir. Cloudflare cache yanıtları ve önbelleğe alınmayan yanıt incelemesi sağlayıcıya özgü ayrıntıları açıklar.

HIT tek başına sayfanın hızlı olduğunu, güncel kaldığını veya sıralama kazandığını kanıtlamaz. MISS de tek başına hata değildir: soğuk cache, farklı edge noktası, yakın tarihli purge, cache key farkı veya o içerik için bilinçli bypass bunu açıklayabilir. Aynı testte URL, yöntem, cookie durumu, parametreler, yanıt başlıkları ve ölçüm anını kaydedin. Kişisel token, çerez veya Authorization başlığı içeren gerçek istekleri rapora kopyalamayın.

Yerel, sentetik cache laboratuvarı

Komut dosyası kavramı güvenli biçimde göstermek için yalnızca kendi bilgisayarınızın 127.0.0.1 adresinde sahte bir origin ve cache katmanı açar. Harici bir siteye istek göndermez ve Cloudflare/AWS/Fastly davranışını taklit ettiği iddiasında bulunmaz:

node public/examples/cdn-cache-lab.mjs

Çıktıda hash’li JavaScript dosyası için ilk MISS, tekrarında HIT; genel HTML ve oturumlu HTML için BYPASS; görsel için ayrı Content-Type; sorgu parametresi değişince ayrı fixture cache key’i görülür. x-local-lab-cache sadece bu laboratuvarın kendi başlığını ifade eder. Bu ölçüm Seobify veya başka bir canlı CDN hakkında bulgu değildir; gerçek siteyi değerlendirmek için yukarıdaki curl adımlarını o sitenin sahibinin yetkili olduğu URL’lerde çalıştırın.

CDN Googlebot’u veya arama kaynaklarını engelliyor mu?

Bir WAF/bot kuralı normal tarayıcı yanıtını verirken Google’ın tarayıcısını 403, zaman aşımı ya da CAPTCHA/JavaScript doğrulama ekranıyla karşılayabilir. Tersine, doğrulama sayfası hatalı biçimde 200 dönerse bot gerçek içerik yerine bu gövdeyi görebilir. Google, CDN kaynaklı engel ihtimalinde Search Console URL Denetimi’ndeki canlı test ve oluşturulan sayfa görünümünü kontrol etmeyi öneriyor; CDN arkasında olmak Googlebot’un her URL’yi taradığı anlamına gelmiyor.

İnceleme sırası:

1. Google Search Console URL Denetimi’nde canlı testi çalıştırın; tarama izni ile Google’ın aldığı HTML/görüntüyü inceleyin.
2. Sunucu/CDN loglarında aynı URL, zaman aralığı ve HTTP durumunu bulun. Sadece User-Agent metnine güvenmeyin; Google crawler kimliğini doğrulamak için Google’ın yayımladığı yöntemleri kullanın.
3. WAF olay kaydında hangi kuralın devreye girdiğini, challenge ekranı üretip üretmediğini ve yanıtın gerçek içerik olup olmadığını belirleyin.
4. Gerçek aşırı yük varsa geçici davranışı HTTP durumu ve süreyle açıkça belirtin. Google, yük altındaki crawl isteklerinde geçici 429 veya 503 kullanımını anlatıyor; 403/404’ü hız sınırlama yerine kullanmayın. Uygulama ve CDN sağlayıcısının kuralını onaylı test ortamında doğrulayın.

Google’ın CDN/crawl rehberi, bot challenge’ı, ağ zaman aşımını, hata durumlarını ve crawl loglarını; tarama hatalarını giderme belgesi aşırı yük ve geçici HTTP durumlarını açıklar. Bir testte bot User-Agent’ını taklit etmek tek başına Googlebot’un gerçekte ne aldığını kanıtlamaz.

CDN veya hosting değişikliğinde SEO kabulü

Kullanıcının gördüğü URL’ler aynı kalıyorsa bu, URL taşıması değil hosting/CDN değişimidir; yine de yeni edge/origin yapılandırması ayrı bir kabul gerektirir. Google’ın URL’ler değişmeden hosting değiştirme kılavuzu yeni altyapıyı önceden test etmeyi, sayfa/görsel/form indirmelerini gözden geçirmeyi, Search Console doğrulamasını korumayı ve canlı geçişten sonra trafik ile taramayı izlemeyi önerir. URL, sahiplik, CMS veya sunum mimarisi de değişiyorsa ayrı SEO migration kabul listesini kullanın.

Yayın öncesi aynı URL’lerde şu matrisi karşılaştırın: anonim HTML, varsa oturumlu sayfa, bir CSS/JS dosyası, bir görsel, 404 sayfası, sitemap ve robots.txt. Her biri için durum kodu, canonical/robots içeriği, önemli başlıklar, redirect zinciri ve origin/edge kaydını saklayın. Geçici staging host’unu indekslenebilir bırakmayın. DNS veya WAF değişikliği yapma yetkiniz yoksa bulguyu sağlayıcı/altyapı sahibine yönlendirin; rastgele cache temizleme, geniş bot allowlist’i veya toplu public kuralı uygulamayın.

CDN SEO kontrol listesi

• Test URL’si, tarih/saat, istek yöntemi ve anonim/oturumlu durum kaydedildi.
• HTML ve hash’li varlık için Cache-Control politikası ayrı incelendi.
• İki ardışık GET ile hit/miss veya sağlayıcıya özgü karşılık gözlendi; Age’in kaynağı varsayılmadı.
• Cookie, Authorization ve sorgu parametrelerinin cache key/bypass etkisi doğrulandı.
• Cache’ten dönen HTML’nin canonical, robots, dil alternatifi ve görünür içerikleri güncel.
• Google’ın canlı URL testi ve ilgili edge/WAF logu birlikte kontrol edildi.
• 403/429/503, challenge ve timeout örnekleri URL ile zamana bağlandı; üretim kuralı değiştirilmeden önce sahip/onay belirlendi.
• Hosting/CDN geçişinde aynı URL, sitemap, robots.txt, Search Console erişimi ve geri alma adımları sınandı.
• Sonuç, alan verisi veya sıralama etkisi gibi değil; başlık/log/test kanıtının sınırıyla raporlandı.

İçerik ve teknik uygulama önceliklerini birlikte belirlemek için SEO danışmanlığı kapsamını inceleyin. Performansın tek nedeni CDN değildir; önce kullanıcının hangi yanıtı aldığı, ardından hangi katmanda geciktiği ölçülmelidir.