CDN ve SEO

TL;DR — CDN (içerik dağıtım ağı), sayfalarınızın kopyalarını tutan ve bunları her ziyaretçiye yakın bir konumdan sunan, dünyanın dört bir yanına yayılmış bir sunucu ağıdır. Bu, sitenizi daha hızlı ve güvenilir hâle getirir. CDN, sıralamanızı doğrudan yükseltmez; ancak daha hızlı ve güvenilir bir site, Google’ın ölçtüğü unsurlara katkıda bulunur. Dolayısıyla genellikle yararlıdır. CDN’nin SEO’ya zarar vermesinin başlıca yolu, arama motoru botlarını yanlışlıkla engellemesidir ve bu düzeltilebilir.

CDN nedir?

Normalde sitenizin her ziyaretçisi, fiziksel olarak nerede bulunursa bulunsun tek bir sunucuya, yani origin sunucunuza bağlanır. Dünyanın diğer tarafındaki biri, verinin daha uzun bir yol katetmesi gerektiğinden her istekte daha uzun süre bekler.

CDN, içeriğinizin kopyalarını farklı konumlardaki çok sayıda sunucuya (edge servers olarak adlandırılır) yerleştirerek bunu çözer. Bir ziyaretçi geldiğinde içerik, origin sunucunuz yerine en yakın sunucudan sunulur. Bu, ziyaretçi için daha hızlıdır ve kendi sunucunuzun yükünü azaltır. Cloudflare, Fastly, Akamai, Amazon CloudFront ve Bunny yaygın örneklerdir.

CDN SEO’ya yardımcı olur mu?

Kısa yanıt: CDN tek başına bir sıralama faktörü değildir, ancak sıralama faktörü olan unsurlara yardımcı olur. Google, “CDN kullandığınız” için sıralamanızı yükseltmez. CDN şunları yapar:

• Sayfaların daha hızlı yüklenmesini sağlar — Bu, Google’ın değerlendirdiği sayfa deneyimi metrikleri olan Core Web Vitals değerlerinizi iyileştirir.
• Sitenizi erişilebilir tutar — CDN’ler trafik artışları veya kısa kesintiler sırasında önbelleğe alınmış sayfaları sunmaya devam edebilir ve saldırıları karşılayabilir.
• Arama motorlarının sitenizi biraz daha hızlı taramasını sağlar — Google, bir sitenin arkasında CDN bulunduğunu algıladığında uygulamaya hazır olduğu tarama hızını artırır.

Dolayısıyla dürüst ifade şudur: CDN, SEO’yu destekleyen yararlı bir araçtır; sihirli bir sıralama düğmesi değildir.

CDN’nin SEO’ya zarar verebilmesinin başlıca yolu

CDN’ler, yoğun kötü trafiği engelleyen bot korumasıyla birlikte gelir. Bu koruma bazen iyi botları da yakalar ve Googlebot veya Bingbot, geçemeyecekleri bir “insan olduğunuzu kanıtlayın” doğrulamasının arkasında kalır. Böyle bir durumda Google sayfanızı göremez ve sıralamanız zarar görebilir.

İyi haber: Bu sorun düzeltilebilir. URL Inspection tool ile Google Search Console’da kontrol edebilirsiniz; araç, sayfayı Google’ın gördüğü biçimde gösterir. Google içeriğiniz yerine boş bir sayfa, hata veya bot doğrulaması görüyorsa CDN’niz erişimi engelliyordur; siz veya CDN sağlayıcınız güvenlik duvarı kuralını düzeltmelisiniz.

İnsanların endişelendiği, ancak çoğunlukla sorun oluşturmayan birkaç konu daha vardır:

• Paylaşılan CDN IP adresi (başka birçok site tarafından da kullanılır) sorun değildir — Google’dan John Mueller, kendi IP bloğunuzu satın almanız gerekmediğini söylemiştir.
• CDN kaynaklı “yinelenen içerik cezaları” gerçekte yoktur — En kötü durumda yanlış bir yapılandırma, Google’ın bir URL’nin yanlış sürümünü seçmesine yol açar. Bunu cezadan korkarak değil, canonical etiketleriyle düzeltirsiniz.

Tarama bütçesi ve cold cache’ler, hard ve soft bot engelleri, Google’ın Aralık 2024 rehberliği, HTTPS tuzakları ve edge üzerinden canonicalization konularını içeren ayrıntılı sürümü mü istiyorsunuz? Advanced sekmesine geçin.

TL;DR — CDN, içeriğinizi istekte bulunan kişiye yakın edge servers üzerinde önbelleğe alıp sunarak TTFB’yi düşürür ve Core Web Vitals değerlerini iyileştirir; çalışma süresi/yoğun trafik koruması sağlar ve Google’ın daha hızlı tarama yapmasına olanak tanır (Google, sunumu yapan IP’den çıkarımda bulunarak CDN-backed siteler için tarama hızı eşiklerini yükseltir). CDN tek başına bir sıralama faktörü değildir. Risklerin tamamı operasyoneldir: cold cache nedeniyle origin, her yeni URL’yi yine en az bir kez sunmalıdır (büyük lansmanlarda tarama bütçesi maliyeti); CDN’nin WAF veya bot doğrulama ara sayfaları tarayıcıları sessizce engelleyebilir — gerçek dünyadaki en büyük CDN/SEO arıza biçimi budur; canonical etiketleri ile HTTPS yapılandırması edge’den sağlam geçmelidir. Ayrıca Google, Aralık 2024’te kritik JS/CSS dosyalarını bir CDN subdomain’ine dağıtma konusundaki görüşünü bir haftadan kısa sürede değiştirdi (artık kritik kaynaklar için önerilmiyor, video gibi büyük ve kritik olmayan varlıklar için hâlâ uygundur). Yetkili kaynak, Google’ın “Crawling December: CDNs and crawling” yazısıdır.

CDN gerçekte ne yapar?

CDN; origin sunucunuz ile URL’lerinizi isteyen ziyaretçiler ve tarayıcılar arasında bir aracıdır. Google’ın Aralık 2024 tarihli “Crawling December” yazısı bunu açıkça anlatır: CDN’ler, bazı dosyaları sizin adınıza sunan origin sunucunuz ile son kullanıcı arasındaki bir aracıdır. Tarihsel olarak en büyük odakları önbelleğe almadır: Bir URL istendiğinde CDN, sunucunuzun aynı dosyayı tekrar sunmasına gerek kalmaması için içeriğini bir süre saklar. Google bütün amacı web sitenizin gecikmesini azaltmak olarak tanımlar: Yoğun trafik altında bile içeriğinizin hızla sunulması.

Martin Splitt ve Gary Illyes imzalı bu yazı, arama motorlarının CDN’ler ve SEO hakkında yayımladığı en yetkili ve güncel kaynaktır; rakip makalelerin çoğu bundan yararlanmaz. Aşağıdaki bilgilerin neredeyse tamamı bu kaynağa dayanır.

Terim gevşek kullanıldığı için CDN’nin ne olduğu konusunda kesin olmak gerekir: CDN, özellikle dağıtılmış edge-server topolojisidir; origin ile istekte bulunanlar arasında yer alan önbelleğe alma/sunma düğümleri ağıdır. Genel web hosting veya HTTP caching ile eş anlamlı değildir (herhangi bir sunucu ya da proxy bir yanıtı önbelleğe alabilir). Web Application Firewall koruması ve TLS termination da temel CDN işlevinin parçası değildir. Çoğu CDN sağlayıcısı bunları paketine eklediğinden terimler birbirine karışır; ancak bunlar edge delivery üzerine eklenen ayrı yeteneklerdir.

CDN SEO’ya yardımcı olur mu? Dürüst yanıt

CDN bir sıralama faktörü değildir. Google’ın değerlendirdiği çeşitli unsurları etkileyen bir performans ve güvenilirlik aracıdır. Bunlardan üçü önemlidir:

Daha hızlı TTFB ve Core Web Vitals

Yakındaki bir edge cache’den sunum yapmak gidiş-dönüş süresini kısaltır ve time to first byte değerini düşürür. TTFB ise Core Web Vitals metriklerinin en büyüğü olan LCP’nin başlangıç kısmıdır. Google’a göre medya, JavaScript, CSS ve hatta HTML’nin CDN cache’lerine aktarılması sunucu yükünü azaltır ve sayfaların kullanıcıların tarayıcılarında daha hızlı yüklenmesini sağlar; bu da daha iyi dönüşümlerle ilişkilidir. Bu, CDN lehindeki en açık ve savunulabilir SEO argümanıdır ve bu kümedeki caching, resource hints ve web performance tools konularının tamamıyla örtüşür. CDN, kötü bir CWV veya PageSpeed puanını düzeltmek için kullanabileceğiniz en güçlü araçlardan biridir.

Ancak bu fayda koşulludur. Gidiş-dönüş süresini azaltan, istekte bulunana yakın bir cache hit durumudur; miss, önbelleğe alınmamış kişiselleştirilmiş yanıt veya kötü konumlanmış bir edge node, TTFB’yi değiştirmeyebilir, hatta ek yük getirebilir. CDN her bölgede ve her istekte daha düşük TTFB garanti etmez; bunu yalnızca edge gerçekten yanıtı sunabildiğinde garanti eder.

CDN-backed siteler için daha yüksek tarama hızı eşikleri

Bu, yeterince değer görmeyen avantajdır. Google, URL’lerinizi sunan IP’den sunucu kapasitesi hakkında çıkarım yapar ve tarama altyapısını açıkça CDN tarafından desteklenen sitelerde daha yüksek tarama hızlarına izin verecek biçimde tasarlar. Google’ın tarama altyapısı sitenizin CDN-backed olduğunu algıladığında yavaşlatma eşiği çok daha yüksektir, çünkü sunucunun daha fazla eşzamanlı isteği karşılayabileceği varsayılır. Büyük veya sık güncellenen sitelerde bu gerçek ve belgelenmiş bir avantajdır: Daha fazla sayfanız daha hızlı taranabilir. Ancak garanti edilen şeyi doğru ifade etmek gerekir: Bu, çıkarımla belirlenen bir kapasite eşiğidir; garanti edilmiş tarama bütçesi, dizine ekleme veya sıralama artışı değildir. Google, bu yüksek tavanın ne kadarını kullanacağına kendi tarama talebi sinyallerine göre karar verir. (Tam kullanılsa bile yalnızca tarama bütçesi verimliliği sağlar, sıralama sinyali değildir; daha fazla taranmak daha iyi sıralanmak anlamına gelmez.)

Güvenilirlik, çalışma süresi ve yoğun trafik koruması

Google iki fayda daha belirtir. Trafik yoğunluğu koruması: CDN’ler aşırı veya kötü amaçlı trafiği belirleyip engelleme konusunda başarılıdır ve hatalı davranan botlar aşırı yük oluştursa bile sitenizi kullanılabilir tutar. Güvenilirlik: Bazı CDN’ler siteniz kapalı olsa bile sitenizi kullanıcılara sunabilir — en azından statik içeriği; bu, ziyaretçilerin ayrılmasını önlemeye yetebilir. Ölçek gerçektir: CDN’ler, korumasız bir origin sunucusunu saniyeler içinde devre dışı bırakacak multi-terabit DDoS saldırılarını bağımsız olarak algılayıp hafifletmiştir. Çalışma süresi sessizce bir SEO meselesidir; Googlebot’a sürekli hata döndüren uzun kesintiler zamanla dizindeki yerinize mal olur.

Tarama bütçesi riski: Yeni URL’lerde cold cache

Neredeyse tüm rakip makalelerin atladığı ayrıntı şudur: CDN, kaynak sunucunuzu yepyeni URL’leri sunmaktan muaf tutmaz. Bir URL’ye yönelik ilk istekte CDN önbelleği soğuktur; henüz kimse URL’yi istemediği için içerik önbelleğe alınmamıştır ve önbelleği ısıtmak üzere kaynak sunucunuz URL’yi yine en az bir kez sunmalıdır. Google’ın örneği, bir milyondan fazla URL yayımlayan bir web mağazasıdır: CDN arkasında bile sunucunuzun bu 1 000 007 URL’yi en az bir kez sunması gerekir. CDN ancak bundan sonra yardımcı olabilir. Bu, tarama bütçesine gerçek bir yüktür ve Google, tarama hızının birkaç gün boyunca büyük olasılıkla artacağı konusunda uyarır.

Pratik sonuç: Aynı anda çok sayıda URL yayımlıyorsanız — yeni bir site bölümü, taşıma veya dev bir ürün kataloğu — origin sunucunuzu ilk taramayı karşılayacak şekilde planlayın. CDN sizi ısınma sırasında değil, sonrasında korur. Bu, site migrations konusunda da karşımıza çıkan “yük gerçekte nereye biniyor?” düşüncesidir.

Statik varlıklar bir CDN subdomain’inde mi bulunmalı?

Tekrarlanan bir mimari soru şudur: CSS/JS/images dosyalarını cdn.example.com gibi ayrı bir hostname’de mi barındırmalısınız, yoksa ana hostname’inizi CDN ile mi desteklemelisiniz? Google, ikisinin de çalıştığını ve tarama altyapısının her iki seçeneği de sorunsuz desteklediğini söyler. Kaynakları ayrı bir hostname’e bölmek Web Rendering Service’in daha verimli render etmesini sağlayabilir; ancak Google şu çekinceyi de belirtir: Bu, farklı bir hostname’e bağlanma ek yükü nedeniyle sayfa performansını olumsuz etkileyebilir.

Google bu konuda bir haftadan kısa sürede kamuya açık biçimde görüş değiştirdi. 3 Aralık 2024 tarihli eşlik eden yazısı, tarama bütçesi kaygılarını kaynak sunucusuna aktarmak için önce kaynakların farklı bir hostname’de barındırılmasını önerdi. Üç gün sonra şu düzeltmeyi ekledi: Bu yaklaşım farklı bir hostname’e bağlanmanın ek yükü nedeniyle sayfa performansını yavaşlatabileceğinden, Google artık JavaScript veya CSS gibi kritik render kaynakları için bunu önermiyor; video veya indirmeler gibi büyük ve kritik olmayan varlıklar için yine değerlendirilebilir. Ana host’unuzu zaten CDN ile destekliyorsanız bu ödünleşimi aşarsınız: Sorgulanacak tek hostname ve CDN cache’inden sunulan kritik kaynaklar. Ayrıca WRS, HTTP cache headers değerlerinizden bağımsız olarak JS/CSS dosyalarını 30 güne kadar önbelleğe alır; dolayısıyla kaynak değişiklikleri gecikebilir.

CDN’ler SEO’ya ne zaman zarar verir? Bot engelleme (en büyük gerçek risk)

Gerçek dünyadaki bir numaralı CDN/SEO sorunu yinelenen içerik değil, CDN’nin tarayıcıları sessizce dışarıda tutmasıdır. Google bunu açıkça söyler: Yoğun trafik koruması nedeniyle sitenizde bulunmasını istediğiniz botlar CDN’nizin blocklist’ine girebilir. Bu genellikle Web Application Firewall (WAF) içinde olur ve sitenizin aramada hiç görünmemesine yol açabilir. Google, arıza biçimlerini hard blocks ve soft blocks olarak ayırır.

Hard blocks — Döndürdüğünüz durum kodu son derece önemlidir

• HTTP 503 / 429 — Geçici bir engeli bildirmenin doğru yoludur. Herhangi bir içerik dizinden kaldırılmadan müdahale etmek için zaman kazandırır. Bunu tercih edin.
• Ağ zaman aşımları — Kötüdür. Google bunları nihai, “kesin” hatalar olarak değerlendirir. Kesin sonuç — dizinden kaldırılma, tarama hızının düşürülmesi veya her ikisi — Google’ın güncel HTTP status codes, and network and DNS errors belgesine göre durum/ağ hatası sınıfına, hatanın ne kadar sürdüğüne ve tekrarlanıp tekrarlanmadığına bağlıdır; tek ve münferit bir zaman aşımı, süreklilik gösteren bir örüntüden çok daha küçük bir risktir.
• 200 durumuyla sunulan rastgele bir hata mesajı (“soft error”) — En kötü durumdur. Google bunu kesin hata olarak yorumlarsa URL’yi kaldırır; yorumlayamazsa aynı hata gövdesini paylaşan tüm sayfalar yinelenen içerik olarak elenebilir.

Bu sonuç sıralaması, konunun tamamındaki en uygulanabilir bilgidir: Temiz bir 503, “teknik olarak açık” olan bir 200 hata sayfasından daha iyidir.

Soft blocks — Bot doğrulama ara sayfaları

CDN bir “insan mısınız?” doğrulaması gösterdiğinde tarayıcının gördüğü tek şey bu ara sayfadır; asıl sayfanızı göremez. Google’ın çözümü açıktır: Bu bot doğrulama ara sayfalarında otomatik istemcilere 503 HTTP durum kodu biçiminde açık bir sinyal gönderilmesini şiddetle önerir; böylece içerik otomatik olarak dizinden çıkarılmaz.

Sorun nasıl ayıklanır?

Google’ın hard ve soft blocks için iş akışı şöyledir: Search Console’daki URL Inspection tool ile render edilmiş ekran görüntüsüne bakın. Sayfanızı görüyorsanız sorun yoktur; boş sayfa, hata veya bot doğrulaması görüyorsanız CDN sağlayıcınızla görüşün. Ardından tarayıcıyı yayımlanmış IP aralıklarıyla doğrulayın ve uygunsa engellenen IP’leri WAF kurallarından çıkarın veya allowlist’e ekleyin. Google, IP’lerin haberiniz olmadan otomatik olarak blocklist’e girebileceği uyarısında bulunduğundan WAF blocklist’lerini düzenli kontrol etmek yararlıdır. Google tam da bu amaçla Googlebot’un IP aralıklarını yayımlar; Bing de eşdeğerini yayımlar (aşağıdaki Bing bölümüne bakın).

Bu, tüm teknoloji yığını boyunca sorunların çıktığını gördüğüm yerlerden biridir. SMX Advanced 2018 “Solving Complex SEO Problems” sunumumda mantığın bulunabileceği DNS, CDN, middleware, server, HTTP header ve locale gibi katmanları gösteriyorum; CDN edge de bunlardan biridir. Bir yönlendirme veya engel tarayıcıda farklı, Googlebot için farklı davranıyorsa sürpriz çoğu zaman edge’de gizlenir.

CDN üzerinden cache headers ve canonicalization

CDN kaynaklı yinelenen içerik bir ceza değil, yönetilebilir bir risktir. Gerçekte şu biçimlerde sorun çıkar:

• CDN, origin’in canonical etiketini veya header’ını yansıtmadan içeriği kendi domain’inden sunar; böylece edge URL gerçek URL ile rekabet eder.
• Multi-region düğümleri, doğru hreflang olmadan coğrafyaya göre değişen içerik sunarak sayfayı bölgesel varyantlara böler.
• Query-string veya cache-key işleme biçimi, parametre tabanlı yinelenen içerikler üretir.

Çözüm, canonicalization ve duplicate content makalelerinde anlatılan disiplinle aynıdır: Canonical etiketlerinizin ve headers değerlerinizin edge’den bozulmadan geçtiğinden emin olun ve bunları CDN deploy işleminden önce değil, sonra doğrulayın. Canonicalization sinyallerin birleştirilmesidir; canonical değerinizi kaldıran veya geçersiz kılan CDN, yanlış yöne çeken bir sinyal daha oluşturur.

Burada bir miti daha ortadan kaldıralım: Vary header, SEO sinyali değil, önbelleğe alma doğruluğuyla ilgili bir konudur. CDN değişken yanıtları önbelleğe almayı reddederse Vary: User-Agent CDN’nin cache hit rate değerini mahvedebilir; ancak Google Vary değerini mobil/masaüstü dizine ekleme sinyali olarak kullanmaz. Bu bir operasyon sorunudur, sıralama sorunu değil.

CDN üzerinden HTTPS/TLS

CDN, şifrelemenize ikinci bir bağlantı ekler: origin↔edge ve edge↔client. İkisinin de HTTPS olması gerekir. Klasik yanlış yapılandırma, ziyaretçinin HTTPS gördüğü ancak CDN’nin origin ile düz HTTP üzerinden konuştuğu “Flexible SSL” modudur; CDN yapılandırmasına gömülü yalnızca HTTP kullanan asset URL’leri de mixed-content uyarıları üretir. HSTS ve CSP gibi security headers değerlerinin de edge’den geçtiğinden emin olun. HTTPS kendi başına hafif bir sıralama sinyalidir ve CDN, bunu yanlışlıkla bozmanın en kolay olduğu yerlerden biridir. URL’lerinizi değiştirmeden CDN kuruyor veya değiştiriyorsanız bunu hosting değişikliği gibi ele alın; Google’ın changing your web hosting rehberliği “no URL change” site taşıma durumunu kapsar.

Paylaşılan IP’ler ve önemli olmayan konular

• Paylaşılan CDN IP adresi sıralamalar açısından sorun değildir. Google’dan John Mueller, site sahiplerinin yapay biçimde IP adresi blokları satın alması gerekmediğini; başka şirketlerle paylaşılan bir CDN IP’sinde bulunmanın beklenen ve normal bir durum olduğunu söylemiştir.
• İçerik taranabilir olduğu sürece cdn.example.com ile üçüncü taraf CDN domain’i arasındaki seçim, SEO değil, teknik/performans kararıdır. Bu sonuç, Google’ın iki hostname kurulumunu da desteklemesinden doğrudan çıkar.

Bing’in yaklaşımı

Bing’in Google’ınki kadar ayrıntılı tek bir “CDN and SEO” açıklaması yoktur; ancak aynı sorunlar ve çözümler geçerlidir. Google’ın WAF rehberliğinin doğrudan karşılığı olarak Bing, CDN veya bot-management katmanı arkasındaki site sahiplerinin allowlist ya da deny-list’e eklemeden önce bir tarayıcının gerçekten Bingbot olduğunu doğrulayabilmesi için resmî Bingbot IP aralıklarını ve bir doğrulama aracını yayımlar: Verify Bingbot ve Verify Bingbot tool. Microsoft ayrıca Google gibi Bingbot IP adresleri listesini JSON dosyası olarak yayımladı. Bing’in genel rehberliği site hızını optimizasyon konuları arasında sayar ve yükleme sürelerini iyileştirme yöntemlerinden biri olarak CDN kullanımını belirtir. Bing’den Fabrice Canel de üst düzeyde, CDN’lerde önbelleğe alınan ve bulutta barındırılan içeriğin ölçüm ile platformlar arası içerik yönetiminde yeni zorluklar oluşturduğunu anlatmıştır. Bu bir sıralama iddiası olmasa da operasyonel gerçekliği adil biçimde tanımlar.

Bu konu diğer alanlarla nasıl bağlantılı?

CDN kararları web performance kümesindeki caching, resource hints, Core Web Vitals ve TTFB dâhil neredeyse her şeye dokunur; çünkü CDN bunların tamamındaki en güçlü araçlardan biridir. Tarama (crawl budget, cold caches), dizine ekleme (canonicalization, yinelenen içerik işleme), HTTPS ve site migrations konularına da uzanır. Tekrarlanan tema şudur: Canonical etiketlerinizi, HTTPS yapılandırmanızı ve tarayıcı erişimini edge boyunca sağlam tutarsanız CDN, önemli sinyaller açısından açık bir kazançtır; tutmazsanız “içeriksiz dizine ekleme” sorununun başlıca nedenlerinden biri olur.

AI özeti

Advanced sürümünün kısa özeti:

• CDN bir sıralama faktörü değildir — Google ve Bing’in kullandığı TTFB → LCP / Core Web Vitals, çalışma süresi, HTTPS sunumu ve tarama verimliliği gibi unsurları etkileyen bir performans/güvenilirlik aracıdır.
• Google, CDN-backed siteler için tarama hızı eşiklerini yükseltir; bu çıkarımı sunumu yapan IP’den yapar. Büyük/sık güncellenen siteler için belgelenmiş bir avantajdır; ancak garanti edilen tarama bütçesi, dizine ekleme veya sıralama kazancı değil, çıkarımla belirlenen kapasite tavanıdır.
• Cold-cache riski: CDN, origin’i her yeni URL’yi cache’i ısıtmak için en az bir kez sunmaktan kurtarmaz. Büyük lansmanlar/taşımalar birkaç gün boyunca tarama bütçesine yine ağır yük bindirir.
• Kritik JS/CSS dosyalarının ayrı CDN subdomain’ine dağıtılması artık önerilmiyor — Google, ek hostname bağlantı yükü nedeniyle Aralık 2024’te bir hafta içinde tavsiyesini değiştirdi; büyük ve kritik olmayan varlıklar (video/indirmeler) için hâlâ uygundur.
• Gerçek dünyadaki en büyük arıza bot engellemedir, yinelenen içerik değil. Hard blocks: 503/429 = iyi ve kurtarılabilir; network timeouts = sonucu (kaldırma, tarama hızının düşmesi veya ikisi) süre ve sıklıkla büyüyen nihai hatalar; 200 “soft error” sayfası = en kötü durum (tekilleştirme/kaldırma). Soft blocks (CAPTCHA ara sayfaları) → tarayıcılara 503 döndürerek düzeltin.
• Sorun ayıklama: URL Inspection’ın render edilmiş ekran görüntüsünü kullanın, tarayıcıyı Google ve Bing’in yayımladığı IP aralıklarıyla doğrulayın ve WAF blocklist’inizi düzenli inceleyin.
• Canonicalization/yinelenen içerikler yönetilebilir risktir; canonical etiketleri/headers edge’den geçmeli, query strings ve multi-region içerik izlenmelidir. Vary SEO sinyali değil, caching konusudur.
• HTTPS için origin↔edge ve edge↔client bağlantılarının ikisi de şifrelenmelidir; “Flexible SSL” mixed content sorunlarından kaçının. Paylaşılan CDN IP’leri sıralamalar için sorun değildir (Mueller).

Resmî belgeler

Arama motorlarının birincil kaynak belgeleri.

Google

• Crawling December: CDNs and crawling (Splitt & Illyes, Aralık 2024) — önbellekleme, yoğun trafik koruması, daha yüksek tarama hızları, soğuk önbellekler, katı ve yumuşak engeller ile URL Denetimi hata ayıklama iş akışını kapsayan yetkili CDN/SEO yazısı.
• Crawling December: The how and why of Googlebot crawling (3 Aralık 2024, 6 Aralık 2024’te güncellendi) — kaynakları ayrı ana bilgisayar adlarına dağıtma, kritik JS/CSS hakkındaki 6 Aralık düzeltmesi ve WRS’nin 30 günlük kaynak önbelleği.
• HTTP status codes, and network and DNS errors — katı engel, zaman aşımı veya yumuşak hata sonrasında tam olarak ne zaman ne olacağına ilişkin güncel belge.
• Optimize your crawl budget — tarama kapasitesi sınırı ve CDN yazısında atıfta bulunulan yavaşlatma modeli.
• Changing your web hosting — CDN ekleme veya değiştirmenin karşılığı olan “URL değişikliği yok” site taşıma durumu.
• Googlebot IP ranges (googlebot.json) — Googlebot’u doğrulamak ve hatalı WAF engellerini kaldırmak için yayımlanmış IP’ler.

Bing / Microsoft

• Verify Bingbot (yardım belgesi) — Bir tarayıcıyı CDN WAF içinde allowlist/deny-list’e eklemeden önce gerçekten Bingbot olduğunu doğrulayın.
• Verify Bingbot (araç) — herkese açık doğrulama aracı.
• Bing Webmaster Guidelines — site hızı konuları dâhil genel rehberlik.

Kaynaktan alıntılar

Google’ın kayda geçmiş açıklamaları. Her bağlantı, kaynak sayfadaki alıntılanan bölüme götüren derin bağlantıdır. (Bing ve John Mueller’ın görüşleri alıntılanmak yerine Advanced sekmesinde özetlenmiştir; aşağıdaki açıklamaya bakın.)

Google — CDN ne yapar ve neden yardımcı olur?

• “Content delivery networks (CDNs) are particularly well suited for decreasing latency of your website and in general keeping web traffic-related headaches away. This is their primary purpose after all: speedy delivery of your content even if your site is getting loads of traffic.” — Martin Splitt & Gary Illyes, Google Search Central Blog, Aralık 2024. Alıntıya git
• “CDNs are basically an intermediary between your origin server (where your website lives) and the end user, and serves (some) files for them.” Alıntıya git
• “Traffic flood protection: CDNs are particularly good at identifying and blocking excessive or malicious traffic, letting your users visit your site even when misbehaving bots or no-good-doers would overload your servers.” Alıntıya git
• “Reliability: Some CDNs can serve your site to users even if your site is down. This of course might only work for static content, but that might already be enough to ensure they don’t take their business somewhere else.” Alıntıya git

Google — tarama hızı ve cold-cache maliyeti

• “Our crawling infrastructure is designed to allow higher crawl rates on sites that are backed by a CDN, which is inferred from the IP address of the service that’s serving the URLs our crawlers are accessing.” Alıntıya git
• “In short, even if your webshop is backed by a CDN, your server will need to serve those 1,000,007 URLs at least once.” Alıntıya git

Google — bot engelleme (gerçek dünyadaki en büyük risk)

• “Due to the CDNs’ flood protection and how crawlers, well, crawl, occasionally the bots that you do want on your site may end up in your CDN’s blocklist, typically in their Web Application Firewall (WAF).” Alıntıya git
• “In case of these bot-verification interstitials, we strongly recommend sending a clear signal in the form of a 503 HTTP status code to automated clients like crawlers that the content is temporarily unavailable.” Alıntıya git
• “Remember that the IPs may end up on a blocklist automatically, without you knowing, so checking in on the blocklists every now and then is a good idea for your site’s success in search and beyond.” Alıntıya git

Google — hostname sharding ve 6 Aralık’taki yön değişikliği

• “Splitting out resources to their own hostname or a CDN hostname (cdn.example.com) may allow our Web Rendering Service (WRS) to render your pages more efficiently. This comes with a caveat though: this practice may negatively affect page performance due to the overhead of a connection to a different hostname.” Alıntıya git
• “Update on December 6, 2024: This can result in slower page performance due to the overhead of connection to a different hostname, so we don’t recommend this strategy for critical resources (such as JavaScript or CSS) that are needed for rendering a page.” Alıntıya git

CDN ve SEO denetimi — kontrol listesi

CDN’nin SEO’nuza sessizce zarar vermek yerine yardımcı olduğunu doğrulamak için kontrol listesi:

• Tarayıcı erişimi: GSC’deki URL Inspection’ın render edilmiş ekran görüntüsü boş sayfa, hata veya bot doğrulaması yerine gerçek sayfanızı gösteriyor.
• WAF blocklist’i, yanlışlıkla engellenmiş Googlebot/Bingbot IP’leri için incelendi; Google’ın googlebot.json ve Bing’in yayımlanmış aralıklarıyla doğrulandı.
• Geçici engeller 503/429 döndürüyor; network timeout veya 200 hata sayfası değil.
• Bot doğrulama ara sayfaları otomatik istemcilere 503 döndürüyor, böylece içerik otomatik olarak dizinden çıkarılmıyor.
• Canonical etiketleri/headers edge’den sağlam geçiyor; CDN deploy işleminden önce değil, sonra doğrulandı.
• İki bağlantıda da HTTPS var (origin↔edge ve edge↔client); “Flexible SSL” mixed content yok; HSTS/CSP headers geçiyor.
• CDN domain’i, multi-region içerik veya query-string/cache-key işleme nedeniyle yanlışlıkla yinelenen URL oluşmuyor; içeriğin bölgeye göre değiştiği yerlerde hreflang doğru.
• Büyük lansmanlar cold cache’lere göre planlandı; origin her yeni URL’nin ilk sunumunu karşılayabiliyor.
• Kritik JS/CSS ayrı CDN subdomain’ine dağıtılmıyor (Google’ın Aralık 2024 düzeltmesine göre); büyük ve kritik olmayan varlıkların subdomain’de bulunması uygundur.
• Cache headers, tarayıcılara yanlışlıkla eski veya yanlış içerik sunmuyor; Vary, cache hit rate değerini düşürmüyor.

Zihinsel modeller

1. CDN bir sinyal değil, olanak sağlayıcıdır. “CDN beni daha üst sıraya taşır mı?” diye sormayı bırakıp “Hangi sinyalleri etkiler?” diye sorun: TTFB/CWV, çalışma süresi, HTTPS ve tarama verimliliği. Bunları optimize edin; CDN bir araçtır.

2. Edge, mantığın bulunduğu başka bir katmandır. DNS, CDN, middleware, server, HTTP headers, locale — yönlendirme, engel veya header rewrite bunların herhangi birinde gerçekleşebilir. Bir şey Googlebot için tarayıcınızdakinden farklı davranıyorsa edge’den şüphelenin.

3. Warm cache ve cold cache. CDN sizi ilk istek sırasında değil, sonrasında korur. Yeni URL’lerdeki cold cache, origin kapasitesini ve tarama bütçesini yine tüketir; lansmanları ve taşımaları ısınma dönemine göre planlayın.

4. Sessizce değil, açık ve kurtarılabilir biçimde başarısız olun. Edge bir tarayıcıyı geri çevirmek zorundaysa temiz bir 503/429, timeout veya 200 hata sayfasından daha iyidir. Açık ve geçici hata kurtarılabilir; sessiz ve sahte hata dizinden çıkarılmanıza yol açar.

5. Sinyaller edge’den sağlam geçmelidir. Canonical etiketleri, HTTPS, security headers ve tarayıcı erişiminin tamamı CDN’den geçer. “Bu, CDN’den sonra hâlâ çalışıyor mu?” sorusunu varsayım değil, zorunlu doğrulama adımı sayın.

CDN ve SEO kısa başvuru kılavuzu

CDN bir tarayıcıyı geri çevirmek zorunda kaldığında doğru yanıtı seçin

CDN’nin SEO için yaptıkları ve yapmadıkları

Kısa bilgiler

• Yetkili kaynak: Google’ın Crawling December: CDNs and crawling yazısı (Aralık 2024).
• Bot engellerini URL Inspection aracının render edilmiş ekran görüntüsüyle ayıklayın.
• Tarayıcıları googlebot.json ve Bing’in yayımlanmış IP aralıklarıyla doğrulayın.
• HTTPS iki bağlantıda da bulunmalıdır (origin↔edge ve edge↔client).

Mitler, hatalar ve çözümleri

Bunların her biri CDN’ler ve SEO hakkında yaygın bir inanıştır; neden yanlış oldukları ve yerine ne yapılması gerektiği aşağıda açıklanır.

Mit: “CDN sıralamamı doğrudan yükseltir.” Neden yanlış: Google, “CDN kullandığınız” için ödül vermez. CDN bir sıralama faktörü değil, performans ve güvenilirlik sinyallerini geliştiren bir araçtır. Yerine şunu yapın: CDN’yi TTFB/Core Web Vitals, çalışma süresi ve tarama verimliliğini iyileştirmek için kullanın ve bunları ölçün.

Mit: “CDN kullanmak otomatik olarak yinelenen içerik cezasına yol açar.” Neden yanlış: Yinelenen içerik cezası yoktur. En kötü durumda CDN ile origin arasındaki yanlış canonical yapılandırması, Google’ın beklenmeyen bir canonical URL seçmesine yol açar. Yerine şunu yapın: Canonical etiketlerinin/headers değerlerinin edge’den sağlam geçtiğinden emin olun ve her CDN deploy işleminden sonra doğrulayın. Bu bir ceza riski değil, canonicalization hijyeni görevidir.

Mit: “Düşük kaliteli sitelerin de kullandığı paylaşılan CDN IP adresi sıralamamı aşağı çeker.” Neden yanlış: Google’dan John Mueller, CDN IP bloğunu başka şirketlerle paylaşmanın beklenen ve normal bir durum olduğunu; bunun cezası bulunmadığını söylemiştir. Yerine şunu yapın: SEO gerekçesiyle dedicated IP blokları satın alarak para harcamayın.

Mit: “Statik varlıkları cdn.example.com subdomain’ine koymak tarama bütçesi için her zaman daha iyidir.” Neden yanlış: Google Aralık 2024’te bir hafta içinde bu tavsiyeyi değiştirdi. Kritik render-blocking JS/CSS için ek hostname bağlantı yükü, tarama bütçesi tasarrufuna ağır basar. Yerine şunu yapın: Kritik kaynakları ana (CDN-backed) host’unuzda tutun; ayrı hostname’i video ve indirmeler gibi büyük ve kritik olmayan varlıklar için kullanın.

Mit: “CDN’m 200 durumuyla tuhaf bir hata sayfası döndürüyorsa site teknik olarak açık olduğundan bu zararsızdır.” Neden yanlış: Google buna soft error der ve en kötü durum olarak değerlendirir; URL’yi kaldırabilir veya aynı hata gövdesini paylaşan tüm sayfaları yinelenen içerik olarak eleyebilir. Yerine şunu yapın: Geçici engeller için temiz bir 503/429 döndürün; asla 200 hata sayfası döndürmeyin.

Mit: “CDN’ler SEO ile ilgisi olmayan bir dev/ops konusudur.” Neden yanlış: Yanlış CDN yapılandırması; “içeriksiz dizine ekleme”, tarayıcı engelleme ve sayfa deneyimi gerilemelerinin gerçek dünyadaki başlıca nedenlerinden biridir. Yerine şunu yapın: CDN değişikliklerini SEO açısından önemli sayın; tarama ve dizine ekleme sorumlularını sürece dâhil edin ve her değişiklikten sonra tarayıcı erişimini, canonical değerlerini ve HTTPS’yi yeniden doğrulayın.

Bir tarayıcının CDN’niz üzerinden gerçekte ne aldığını kontrol edin

Bir isteği Googlebot olarak gönderin ve normal istekle karşılaştırın. CDN botlara doğrulama uygulıyor veya botları engelliyorsa ikisi farklı olacaktır: durum kodu, doğrulama gövdesi veya ara sayfaya yönlendirme.

macOS / Linux

# Fetch as Googlebot — watch the status line and headers
curl -sSI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/some-page/

# Compare against a normal browser UA
curl -sSI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  https://example.com/some-page/

Windows / PowerShell

$gb = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/some-page/" -UserAgent $gb -Method Head |
  Select-Object StatusCode, Headers

Yalnızca bot UA’ya sunulan bir 403, doğrulama sayfası veya şüpheli ölçüde küçük gövdeli 200, CDN’nizin WAF/bot management katmanının engel olduğu anlamına gelir.

Bir botu allowlist/deny-list’e eklemeden önce gerçekten Googlebot olduğunu doğrulayın

Bir WAF kaydını yalnızca user-agent dizesine dayanarak asla allowlist’e eklemeyin; bu dize kolayca taklit edilebilir. Reverse + forward DNS kontrolü yapın.

macOS / Linux

# Reverse-DNS the IP from your logs — should end in googlebot.com or google.com
host 66.249.66.1
# Forward-DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Reverse lookup bir Google domain’iyle bitmiyorsa veya forward lookup özgün IP ile eşleşmiyorsa bu Googlebot değildir. Google’ın yayımlanmış aralıklarıyla da eşleştirebilirsiniz (googlebot.json); aynısı Bing’in yayımlanmış Bingbot IP listesi için de geçerlidir.

CDN yapılandırmasına gömülü mixed content’i belirleyin (DevTools Console)

Düz HTTP üzerinden yüklenen varlıkları listelemek için kodu Chrome DevTools Console’a yapıştırın; bu, yaygın bir “Flexible SSL” belirtisidir:

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure:', u));

Günlüğe yazılan her şey HTTP üzerinden istenmektedir ve HTTPS CDN’nizin arkasında mixed-content uyarılarını tetikler.

Aylık CDN tarayıcı erişimi kontrolü

1. Kritik şablonlardan örnek alın. En az bir ana sayfa, kategori, makale ve dönüşüm URL’si seçin; mümkünse her birini en az iki region/PoP ve cache durumunda (hit, miss, stale) kontrol edin. Örnek her CDN cache veya WAF kural kümesini kapsadığında adım tamamlanır.
2. Her URL’yi Google olarak inceleyin. URL Inspection live test’i çalıştırıp render edilmiş sayfayı inceleyin. Google hata veya doğrulama yerine sayfayı aldığında adım tamamlanır.
3. WAF olaylarını inceleyin. Ayın engellerini doğrulanmış arama tarayıcıları için filtreleyin; kimlikleri yayımlanmış Googlebot veya Bingbot aralıklarıyla doğrulayın. Meşru tarayıcıların hiçbiri engelli kalmadığında adım tamamlanır.
4. Edge headers değerlerini karşılaştırın. Edge sonrasında status, canonical, Cache-Control, HTTPS, HSTS ve CSP’yi kontrol edin. CDN bunları kaldırmadığında veya yeniden yazmadığında tamamlanır.
5. İstisnaları ve sorumluları kaydedin. Etkilenen kuralı, URL örüntüsünü, çözümü ve sonraki inceleme tarihini kaydedin. Her istisnanın sorumlusu ve sona erme tarihi olduğunda tamamlanır.

Googlebot aniden CDN doğrulaması alıyor

1. Olayı URL Inspection’da doğrulayın. Live render edilmiş sayfa normalse sorunun belirli bir region veya URL örüntüsüyle sınırlı olup olmadığını kontrol edin; değilse devam edin.
2. Edge yanıtını belirleyin. 403, timeout, doğrulama gövdesi veya sahte 200, WAF ya da bot-management katmanını işaret eder. Origin aynı sonucu döndürüyorsa olayı origin sorumlusuna aktarın.
3. Hatayı kurtarılabilir hâle getirin. Geçici otomatik engel için 503 veya 429 döndürün. Tanılama sırasında timeout’u veya 200 döndüren doğrulama sayfasını bırakmayın.
4. Tarayıcıyı doğrulayın. Allowlist’i değiştirmeden önce kaynak IP’yi reverse-and-forward DNS veya arama motorunun yayımlanmış aralıklarıyla doğrulayın.
5. Kural değişikliğini daraltın. Hatalı engeli kaldırın veya doğrulanmış tarayıcıyı muaf tutun; ardından URL Inspection’ı yineleyin. Gerçek sayfa render edilirse WAF olaylarını ve tarama hatalarını izleyin; edilmezse istek zincirindeki sonraki edge kuralını inceleyin.
6. Tekrarlanmasını önleyin. Tetikleyici kuralı belgeleyin ve aylık tarayıcı erişimi kontrolüne ekleyin.

Google sayfa yerine doğrulama görüyor

Belirti: URL Inspection bir ara sayfa, boş sayfa veya WAF mesajı render ediyor. Olası neden: CDN’de bot doğrulama ya da otomatik engel. Çözüm: Tarayıcıyı doğrulayın, ilgili WAF kuralını ayarlayın ve engel geçiciyken 503 döndürün. Çözümü yeni bir live inspection ile doğrulayın.

CDN deploy işleminden sonra canonical değerleri farklı

Belirti: Edge yanıtındaki canonical, origin’dekine göre eksik veya farklı. Olası neden: HTML dönüşümü, header rewrite veya eski önbelleğe alınmış belge. Çözüm: Etkilenen cache key’i temizleyin, rewrite işlemini kaldırın ve origin ile herkese açık yanıtları yeniden karşılaştırın.

HTTPS herkese açık olarak çalışıyor ancak mixed content görünüyor

Belirti: Sayfa URL’si HTTPS olmasına rağmen tarayıcı güvenli olmayan varlıklar bildiriyor. Olası neden: CDN origin ile HTTP üzerinden konuşuyor veya asset URL’lerini yeniden yazıyor. Çözüm: İki bağlantıda da HTTPS zorunlu kılın, asset URL’lerini düzeltin, cache’i temizleyin ve Scripts sekmesindeki Console kontrolünü yeniden çalıştırın.

Büyük bir lansman origin’i aşırı yüklüyor

Belirti: Google çok sayıda yeni URL keşfederken origin gecikmesi veya hataları hızla artıyor. Olası neden: Cold edge cache, her yeni URL için yine bir origin yanıtı gerektiriyor. Çözüm: Origin kapasitesini geri kazandırın, gerekirse kurtarılabilir geçici durum kodları kullanın ve gelecekteki lansmanları varsayılan CDN korumasına değil, cache warm-up sürecine göre planlayın.

Geçici bot engeli: Hatalı yanıt ile kurtarılabilir yanıt

HTTP/2 200
content-type: text/html

<h1>Verify you are human</h1>

200, hatayı gizler ve birçok URL’nin yinelenen doğrulama sayfası gibi görünmesine yol açabilir. Geçici bir engel kendisini açıkça tanımlamalıdır:

HTTP/2 503
retry-after: 300
content-type: text/html

CDN cache key: Yanlışlıkla yinelenen içerik ile tek canonical yanıt

HTML’yi ilgisiz izleme parametrelerine göre değiştiren bir cache key, /product?utm_source=a ve /product?utm_source=b için ayrı edge nesneleri oluşturabilir. Daha temiz bir kurulum, önbelleğe alma sırasında bu parametreleri yok sayar ve iki yanıtta da aynı canonical URL’yi korur. Bu, basitleştirilmiş bir yapılandırma örneğidir; tam kural söz dizimi CDN’ye göre değişir.

CDN davranışını denetlemeye yönelik araçlar

• Google Search Console URL Inspection — Live test çalıştırın ve bot doğrulamalarını, boş sayfaları ve edge hatalarını yakalamak için render edilmiş sayfayı inceleyin.
• Googlebot IP ranges — WAF erişimini değiştirmeden önce kaynağı Google’ın yayımladığı googlebot.json ile doğrulayın.
• Bing Verify Bingbot — Bingbot kimliklerini resmî doğrulama aracıyla doğrulayın.
• curl veya PowerShell Invoke-WebRequest — Doğrudan erişimin güvenli olduğu durumlarda browser user agent, crawler user agent ve origin arasındaki status ile headers değerlerini karşılaştırın.
• Chrome DevTools — Edge yapılandırması değiştikten sonra status/cache headers için Network’ü, mixed content için Console’u kullanın.

CDN değişikliğinin arama açısından güvenli olduğunu kanıtlayın

Tarayıcı erişimi testi

Çalıştırılacak test: Değiştirilen her şablonda URL Inspection live test’i kullanın. Beklenen sonuç: Render edilmiş ekran görüntüsü gerçek sayfayı içerir ve amaçlanan status değerini döndürür. Hata yorumu: WAF, bot doğrulaması veya edge kuralı Google’ı engelliyordur. İzleme aralığı: Hemen ve ardından kurallar yayıldıktan sonra tekrar. Rollback tetikleyicisi: Google’ın doğrulama, boş yanıt veya hard block alması.

Edge-header eşlik testi

Çalıştırılacak test: Herkese açık yanıt ile origin yanıtının status, canonical, Cache-Control ve security headers değerlerini karşılaştırın. Beklenen sonuç: İzin verilen CDN dönüşümlerinden sonra amaçlanan sinyaller eşleşir. Hata yorumu: Rewrite veya stale cache yanıtı değiştirmiştir. İzleme aralığı: Deploy ve purge sonrasında hemen. Rollback tetikleyicisi: Canonical, HTTPS veya tarayıcıya dönük status değerinin onaylanmış origin’den farklı olması.

Warm-cache performans testi

Çalıştırılacak test: Aynı URL’yi iki kez isteyin; CDN’nin cache-status header değerini ve TTFB’yi karşılaştırın. Beklenen sonuç: Uygun ikinci istek cache’den sunulur ve cold istekten daha yavaş değildir. Hata yorumu: Yanıt önbelleğe alınamıyor, cache key beklenmedik biçimde değişiyor veya edge atlanıyordur. İzleme aralığı: Yapılandırma yayıldıktan sonra. Rollback tetikleyicisi: Değişikliğin hataları artırması veya temsilî sayfalarda TTFB’yi sürekli kötüleştirmesi.

Bölge ve cache durumu doğrulama testi

Çalıştırılacak test: Aynı URL’nin render edilmiş çıktısını ve headers değerlerini birden fazla region/PoP ve cache durumunda (hit, miss, stale), normal user agent ile doğrulanmış crawler user agent için karşılaştırın; kişiselleştirilmiş veya cookie taşıyan varyantları da ekleyin. Beklenen sonuç: Bilinçli ve belgelenmiş bir fark (gerçekten bölgeye özgü içerik) bulunmadıkça status, canonical, robots yönergeleri ve render edilmiş içerik; bölge, cache durumu ve isteyen türünden bağımsız olarak amaçlanan çıktıyla eşleşir. Hata yorumu: İstenmeyen region-, cache-state- veya requester-dependent fark, cache-key, Vary veya edge-config sapmasına işaret eder. İzleme aralığı: Deploy’dan hemen sonra ve ilk tarama/log inceleme döngüsünde. Rollback tetikleyicisi: Test edilen herhangi bir boyutta status, canonical veya tarayıcıya dönük içerikte istenmeyen fark.

Önemli CDN sağlık metrikleri

Edge cache-hit oranı

Metrik: Edge cache’den sunulan uygun istekler. Size ne anlatır: CDN’nin tekrar eden istekleri gerçekten origin’den alıp almadığını. Nasıl alınır: Önbelleğe alınabilir içerik türüne göre bölümlenmiş CDN analytics panelinden. Benchmark / gerçekçi aralık: Şablon ve asset sınıfı başına temel değer belirleyin; kişiselleştirilmiş HTML ile immutable assets aynı hedefi paylaşmamalıdır. Sıklık: Haftalık ve cache-rule değişikliklerinden sonra.

Origin hata oranı ve TTFB

Metrik: Cache misses için origin 5xx oranı ve yanıt süresi. Size ne anlatır: Cold cache veya trafik artışlarının origin kapasitesini aşıp aşmadığını. Nasıl alınır: CDN origin analytics ve server logs. Benchmark / gerçekçi aralık: URL sınıfına göre sitenin kendi normal aralığını kullanın; sürekli gerilemeyi araştırın. Sıklık: Sürekli uyarılar ve haftalık eğilim incelemesi.

Doğrulanmış tarayıcı engelleri

Metrik: Doğrulanmış Googlebot ve Bingbot isteklerinin WAF tarafından engellenmesi. Size ne anlatır: Bot korumasının istenen tarayıcıları dışlayıp dışlamadığını. Nasıl alınır: Resmî aralıklar veya DNS ile doğrulanmış WAF olaylarından. Benchmark / gerçekçi aralık: İstenmeyen sıfır engel. Sıklık: Hemen uyarı verin ve aylık inceleyin.

Kendinizi test edin: CDN ve SEO

CDN’lerin tarama, hız ve dizine eklemeyi nasıl etkilediği hakkında beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Google PageSpeed Insights For SEOs & Developers — Sayfa hızı araçları hakkında; CDN, kötü bir PageSpeed / Core Web Vitals puanını düzeltmek için kullanılabilecek en güçlü araçlardan biridir.
• The Beginner’s Guide to Technical SEO — performans ve taramanın genel çerçevedeki yeri.

Konuşmalarım

• SMX Advanced 2018: Solving Complex SEO Problems (SlideShare) — CDN edge dâhil mantığın bulunabileceği katmanları ve bunların tarama/yönlendirme sürprizlerine nasıl yol açtığını gösterdiğim sunum.
• Fine-Tune your Technical SEO, Page Speed, and Security (Marketing Speak, bölüm 109) — teknik SEO, sayfa hızı ve güvenlik; CDN ile ilişkili alanlar.

Resmî

• Google — Crawling December: CDNs and crawling ve The how and why of Googlebot crawling.
• Bing — Verify Bingbot ve Verify Bingbot tool.

Sektörden

• Can A Content Delivery Network Boost Website SEO? (DebugBear) — Core Web Vitals ile bağlantılı pratik CDN kurulum rehberi.
• Technical SEO Checklist (DebugBear) — CDN/performans maddelerinin daha geniş bir denetimdeki yeri.
• Best SEO for Your CDN (KeyCDN) — edge’deki canonical headers ve robots.txt hakkında sağlayıcı görüşü.
• How Content Delivery Networks (CDNs) Can Impact SEO (Search Engine Journal) — genel CDN/SEO incelemesi (Google’ın Aralık 2024 rehberliğinden öncedir).
• Microsoft list of Bingbot IP addresses released (Search Engine Land) — Google’ın yayımlanmış tarayıcı IP’lerinin Bing karşılığı.
• Microsoft Bing Lists All Of BingBot’s IP Addresses In JSON File (Search Engine Roundtable) — aynı JSON IP listesini ele alan haber.

Değişiklik günlüğü