Cloudflare Workers edge katmanında çalışır ve gelen isteğin IP adresine, cf-ipcountry başlığına veya Accept-Language değerine bakarak hangi dil sürümünün döndürüleceğine karar verebilir. Bu kurulumda tarayıcıya giden HTML, aynı URL üzerinde ziyaretçinin konumuna göre değişir; adres çubuğunda hiçbir fark görünmez, yönlendirme yoktur, gecikme minimumdur. Teknik olarak sorunsuz çalışır. Google'ın bakış açısından ise bu davranış farklı bir kategoriye girer: aynı URL, isteğe bağlı olarak farklı içerik.
Googlebot'un tarama trafiği büyük ölçüde ABD merkezli IP aralıklarından gelir. Worker'ın geo-lookup mantığı bu isteği genellikle İngilizce veya varsayılan sürüme yönlendirir. Gerçek bir kullanıcı ise bulunduğu ülkeye göre Türkçe, Almanca veya Fransızca içerik alır. Bu ayrışma kasıtlı bir manipülasyon amacı taşımasa da Google'ın cloaking tanımına teknik olarak yaklaşır: arama motoruna gösterilen içerik ile insan ziyaretçiye gösterilen içerik sistematik olarak farklıdır.
Bu kurulumu inceleyen bir teknik denetim önce riskin gerçek mi yoksa teorik mi olduğunu ayırt etmeli, ardından hangi katmanın (worker mantığı, CDN cache, hreflang seti) sorunu büyüttüğünü tespit etmelidir. Aşağıdaki sıra bu ayrımı adım adım kurar.
Edge Worker IP'ye göre içerik değiştirince Google hangi sürümü görür?
URL İnceleme aracındaki Canlı Test, Google'ın sunucularından giden bir istek üretir; bu istek de ABD merkezli IP aralığından gelir. Worker mantığı bu isteği kendi geo-lookup tablosunda değerlendirir ve genellikle varsayılan veya İngilizce sürümü döndürür. Sonuç: bir Türk e-ticaret sitesinin ana sayfası Google'a İngilizce olarak görünürken gerçek ziyaretçilerin büyük çoğunluğu Türkçe sürümü görüyor olabilir.
Bu uyumsuzluk doğrudan bir ceza üretmez, ama indekslenen başlık, açıklama ve içerik gövdesi ile SERP'te göründükten sonra kullanıcının karşılaştığı sayfa arasında bir kopukluk oluşturur. Kullanıcı Türkçe bir başlık bekleyip İngilizce içerikle (ya da tam tersi) karşılaşırsa hemen çıkma oranı yükselir; bu da dolaylı bir kalite sinyali olarak geri döner.
Cloaking sınırı nerede çiziliyor: aynı URL, farklı içerik her zaman risk değildir
Google'ın cloaking politikası niyeti hedef alır, mekanizmayı değil. Para birimi gösterimi, teslimat tahmini veya bölgesel promosyon banner'ı gibi kişiselleştirmeler, altındaki sayfanın konusu ve amacı aynı kaldığı sürece cloaking sayılmaz. Buna karşılık, aynı URL'nin tamamen farklı bir dilde, farklı bir konuyla veya sıralama amacıyla farklı anahtar kelime kümesine hizmet eden bir sürüm sunması, arama motorunu yanıltma niyeti taşıyıp taşımadığına bakılmaksızın risk taşır.
Ayrım noktası şudur: kullanıcı deneyimini iyileştirmek için yapılan geçici, geri dönülebilir bir uyarlama ile arama motoruna gösterilenin kalıcı ve tek yönlü olarak farklılaştığı bir yapı arasındaki fark. Worker tabanlı dil değişimi, kullanıcıya dil seçme imkanı vermeden ve seçimi hatırlamadan otomatik ve sessiz çalışıyorsa, ikinci kategoriye kayar.
Googlebot'un IP aralığını özel olarak ele almak neden daha büyük bir hata
Bu sorunu fark eden bazı geliştiriciler, worker koduna userAgent.includes('Googlebot') gibi bir kontrol ekleyip botun "doğru" (yani gerçek ziyaretçinin göreceği) sürümü almasını sağlamaya çalışır. Bu düzeltme, çözdüğünü sandığı sorundan daha ağırdır. Google'ın Arama Merkezi dokümantasyonu, User-Agent veya IP adresine bakarak özellikle Googlebot'a farklı içerik sunmayı doğrudan cloaking olarak tanımlar; niyet iyi olsa bile ihlal budur.
Doğru yaklaşım botu özel olarak tanımak değil, tüm ziyaretçiler (bot dahil) için aynı varsayılan davranışı kurmaktır. Worker geo-lookup her istek için aynı kurallarla çalışmalı, Googlebot'un IP aralığına yakalanan isteğe de tam olarak ABD'den gelen sıradan bir kullanıcıya gösterilecek sürüm gitmelidir. Sorun buradaysa çözüm worker'ı botla özel olarak konuşturmak değil, geo-lookup'ın varsayılan davranışını ve x-default kararını yeniden düşünmektir.
Cache key ve Vary header: Worker çıktısı CDN katmanında nasıl karışıyor
Cloudflare'in edge cache'i varsayılan olarak cache key'e ülke veya dil bilgisini dahil etmez. Worker isteğin geldiği ülkeye göre farklı HTML üretse de, cache katmanı bu iki çıktıyı aynı anahtar altında saklıyorsa ilk gelen istek hangi sürümü tetiklediyse sonraki tüm ziyaretçiler (gerçek konumları ne olursa olsun) o sürümü alır. Bu senaryoda Almanya'dan gelen ilk ziyaretçi Almanca içeriği cache'e yazdırır, ardından Türkiye'den gelen on kullanıcı da aynı cache girdisinden Almanca sayfa görür.
Cache Rules üzerinden cache key'e cf-ipcountry veya özel bir Worker başlığını dahil etmek bu karışmayı önler, ama her ülke için ayrı bir cache girdisi oluşturduğundan cache hit oranını da düşürür; ölçek büyüdükçe bu maliyet gözden kaçırılmamalı. HTTP yanıtında Vary başlığının doğru ayarlanmadığı durumlarda ise tarayıcı önbelleği de benzer bir çapraz kirlenme yaratabilir; kullanıcı sayfayı yeniden ziyaret ettiğinde tarayıcısında hâlâ önceki oturumdan kalan yanlış dilde bir sürüm görebilir.
Hreflang ile Worker tabanlı içerik değişimi çakıştığında hangi sinyal kazanır
Bir site hem her dil için ayrı URL'ler tanımlayıp hreflang seti kuruyorsa hem de aynı zamanda tek bir URL üzerinde worker ile IP'ye göre içerik değiştiriyorsa, bu iki mekanizma birbirine karşı çalışır. Hreflang seti Google'a "bu URL'ler birbirinin dil alternatifleridir" der; worker davranışı ise tek bir URL'in kendi içinde birden fazla dile hizmet ettiğini gösterir. Google bu çakışmayı gördüğünde hangi sinyale güveneceğine kendi karar verir, genellikle de gözlemlediği fiili davranışı (tarama sırasında gördüğü sürümü) esas alır ve hreflang setini güvenilmez bulur.
Net bir mimari seçim gerekir: ya diller tamamen ayrı URL'lerde yaşar ve hreflang bu ayrımı taşır, worker ise sadece kullanıcıyı doğru URL'e yönlendirmek için bir öneri (banner veya 302 ile açık yönlendirme) üretir; ya da tek URL üzerinde adaptif içerik sunulur ve bu durumda hreflang zaten anlamsız hale gelir çünkü ayırt edilecek ayrı bir URL kümesi yoktur. İkisini aynı anda kurmak, önceki bir yazıda ele alınan locale-adaptive sayfa riskinin worker'la güçlendirilmiş bir versiyonudur.
Güvenli kullanım sınırı: Worker SEO riski yaratmadan nasıl kullanılır
Worker'ı SEO riskine dönüştürmeyen kullanım kalıpları sınırlıdır ama nettir:
- Worker içerik değiştirmez, sadece kullanıcıya doğru dil URL'ini öneren bir banner render eder; kullanıcı tıklamadıkça URL ve içerik aynı kalır.
- Worker geo tespiti yapar ama sonucu kalıcı bir 301 yönlendirmesiyle ayrı bir URL'e taşır; bu durumda hedef URL kendi hreflang setine sahip olur ve çakışma oluşmaz.
- Worker yalnızca içerik dışı öğeleri (para birimi, teslimat tahmini, stok durumu) kişiselleştirir; başlık, gövde metni ve meta alanları tüm ziyaretçiler için sabit kalır.
- Dil tercihi bir çerezde veya oturumda saklanır, otomatik ve sessiz değişim yerine kullanıcının açık seçimine dayanır; ilk ziyarette varsayılan sürüm herkese (bot dahil) aynı şekilde sunulur.
Bu kalıpların ortak noktası, aynı URL'nin arama motoruna ve ilk kez gelen her ziyaretçiye tutarlı bir varsayılan sürüm sunması, farklılaşmanın ise açık bir kullanıcı eylemine veya URL değişimine bağlı olmasıdır. Worker sessizce ve otomatik olarak tam sayfa içeriğini IP'ye göre değiştirdiği anda bu tutarlılık bozulur.
Debug protokolü: Worker kaynaklı SEO sorunlarını teşhis etme sırası
Mevcut bir worker kurulumunun risk taşıyıp taşımadığını değerlendirmek için sıralı bir kontrol gerekir:
- URL İnceleme aracında Canlı Test çalıştırıp Google'ın gerçekte hangi HTML'i aldığını görün; bu, worker'ın Googlebot'un IP aralığına ne döndürdüğünün doğrudan kanıtıdır.
- Farklı ülkelerden VPN üzerinden aynı URL'e erişip gerçek kullanıcıların gördüğü sürümleri karşılaştırın; Google'ın gördüğü ile kullanıcının gördüğü arasındaki farkı somutlaştırın.
cf-cache-statusvevaryyanıt başlıklarını inceleyerek cache key'in dil veya ülke bilgisini içerip içermediğini doğrulayın.- Worker kodunu okuyup
userAgentveya bot imzasına dayalı özel bir dallanma olup olmadığını kontrol edin; varsa bu tek başına en yüksek öncelikli düzeltmedir. - Site hreflang kullanıyorsa, hreflang setindeki URL'lerin worker'ın ürettiği fiili içerikle örtüşüp örtüşmediğini tarayıcı geliştirici araçlarıyla teyit edin.
- Search Console'da dil bazlı indeks raporunu ve URL örneklerinin gösterilen başlık/açıklamasını kontrol ederek indekslenen sürümün beklenen dille eşleşip eşleşmediğini görün.
Bu altı adım bir defalık bir denetim değil, worker kodu her güncellendiğinde tekrarlanması gereken bir doğrulama döngüsüdür. Edge katmanındaki bir değişiklik dağıtım anında hiçbir hata üretmez; sorun haftalar sonra indeks raporlarında veya dil bazlı trafik dağılımında sessizce ortaya çıkar, kaynağı da genellikle worker koduna değil hreflang setine veya CDN yapılandırmasına atfedilir.
Worker'ın kendisi bir risk kaynağı değildir; edge'de mantık çalıştırmak başlı başına cloaking değildir. Risk, aynı URL'in kime göre farklı içerik döndürdüğü belirsizleştiğinde ve bu belirsizlik hreflang gibi başka bir sinyal katmanıyla çakıştığında ortaya çıkar. Kurulumu gözden geçirirken sorulacak soru "worker ne yapıyor" değil, "Google'ın gördüğü ile kullanıcının gördüğü arasındaki fark, siteye kim baksa aynı şekilde açıklanabilir mi" olmalıdır.