Cookie consent banner'ı genelde hukuk ve tasarım ekiplerinin sorumluluğunda görülür; SEO ekibi bu bileşene çoğunlukla sadece "banner sayfayı kapatıyor mu" sorusuyla bakar. Çok dilli bir sitede bu bakış açısı yetersiz kalır, çünkü banner'ın kendisi de bir dil versiyonudur ve dil versiyonu olan her bileşen gibi yanlış kurulduğunda tarama ile indekslemeye sızabilir. Banner metni yanlış dilde çıktığında bu sadece bir UX kusuru değildir; kullanıcının hangi hreflang hedefine düştüğünü de sorgulatan bir sinyaldir.
Asıl risk, banner'ın render edilme yönteminde saklıdır. Sayfa içeriği statik HTML olarak sunulurken banner genelde ayrı bir JavaScript katmanıyla enjekte edilir; bu katman dil tespitini kendi mantığıyla yapar ve sayfanın zaten belirlediği dil sinyaliyle çakışabilir. Banner'ın dil tespiti, render zamanlaması ve crawl davranışı arasındaki üç ayrı kesişim noktası aşağıda ele alınıyor.
Banner dilini kim belirliyor: sayfa mı, tarayıcı mı?
Çoğu consent management platformu (CMP), banner metninin dilini iki kaynaktan birinden alır: sayfanın lang özniteliğinden veya tarayıcının Accept-Language başlığından. Bu iki kaynak aynı sonucu vermeyebilir. Türkçe hreflang kümesine giren bir sayfa lang="tr" ile işaretlenmiş olsa bile, tarayıcı ayarı İngilizce olan bir ziyaretçi CMP tarafından İngilizce banner görebilir; bu kullanıcı deneyimi açısından sorun değildir, çünkü ziyaretçi zaten İngilizce tercih etmiştir.
Sorun, CMP'nin tarayıcı diline göre yönlendirme yapmaya kalkıştığı senaryolarda başlar. Bazı platformlar banner'a "diğer dil sürümüne geç" bağlantısı ekler ve bu bağlantı, ziyaretçinin tarayıcı dilini okuyup otomatik bir hedef URL üretir. Bu üretim mantığı sitenin gerçek hreflang kümesinden bağımsız çalışıyorsa, kullanıcıyı artık var olmayan bir slug'a veya kaldırılmış bir dil versiyonuna yönlendirebilir. Banner kurulumunda ilk kontrol noktası, bu dil geçiş bağlantısının kaynağının CMP'nin kendi tahmini mi yoksa sitenin hreflang listesi mi olduğunu doğrulamaktır.
Crawl bütçesi banner scriptini nasıl görüyor?
Googlebot render kuyruğuna girdiğinde, CMP script'i genellikle sayfanın gerçek içeriğinden önce veya onunla eşzamanlı çalışır. Script büyük ve senkron yükleniyorsa, render kuyruğu banner'ın kendi ağ isteklerini de beklemek zorunda kalır; bu, JavaScript ile render edilen çok dilli içeriğin Googlebot tarafından işlenme hızını etkileyen ayrı bir gecikme katmanı ekler. Çok dilli bir sitede bu gecikme dil versiyonları arasında eşit dağılmaz; CMP genellikle tek bir merkezi script olduğu için, en yüksek trafikli dil versiyonu değil, en çok CMP isteği tetikleyen versiyon önceliklenir.
İçerik kaybolmaz, sadece görünmez olur. Bazı CMP kurulumları banner kapatılana kadar sayfanın ana içerik bloğunu display:none veya boş bir konteynerle tuttuğu için insan ziyaretçi yalnızca birkaç yüz milisaniyelik bir gecikme yaşar, ama Googlebot bazı durumlarda ilk render anlık görüntüsünü baz alır. Sayfa içeriği banner kapanana kadar DOM'da görünmüyorsa, o dil versiyonu için taranmış içerik gerçek sayfadan daha ince görünebilir. Bu davranış, banner kütüphanesi seçilirken SEO ekibinin gözden geçirmesi gereken teknik bir kriterdir; tasarım tercihi değildir.
Reddet / kabul et durumu URL parametresine sızıyor mı?
Bazı CMP entegrasyonları, kullanıcının onay durumunu URL'e bir sorgu parametresi olarak ekler (?consent=accepted gibi) ki bu genellikle analitik ölçüm veya A/B test amacıyla yapılır. Bu parametre canonical etiketten hariç tutulmazsa, aynı sayfanın onaylı ve onaysız hallerinin ayrı URL'ler olarak taranmasına yol açabilir. Çok dilli bir sitede bu durum katlanarak büyür: her dil versiyonu için hem parametre içeren hem içermeyen URL varyantı oluşur ve hreflang kümesi hangi varyantı işaret edeceğini karıştırır.
Doğru kurulum, consent parametresinin canonical URL'de hiçbir zaman görünmemesini ve hreflang etiketlerinin her zaman parametresiz temel URL'e işaret etmesini garanti eder. Bu genellikle sunucu tarafında bir normalizasyon kuralıyla sağlanır; CMP'nin kendi varsayılan davranışına bırakılırsa, parametre sızıntısı fark edilmeden aylarca sürebilir. GSC'de aynı başlığa sahip fazladan URL'lerin birikmesi, bu sızıntının en erken görülebilir belirtisidir.
Banner metni çevrilmemişse hangi dil versiyonu etkilenir?
Yeni bir dil versiyonu eklendiğinde, sayfa içeriği yerelleştirme sürecinden geçse de banner metni bu sürecin dışında kalabilir; çünkü banner genelde CMS'in değil, üçüncü parti CMP panelinin içinde yönetilir. Sonuç, Almanca sayfada Türkçe veya İngilizce banner metninin göründüğü karma bir deneyimdir. Bu durum doğrudan bir indeksleme hatası üretmez, ama kullanıcı sinyalleri üzerinden dolaylı bir etki taşır: banner'ı anlamayan ziyaretçi genellikle ya hiçbir seçim yapmadan sayfadan ayrılır ya da rastgele bir butona basıp beklenmedik bir onay durumuna girer.
Bu boşluk özellikle yeni bir dil eklenirken atlanan teknik adımlar listesine girmeyi hak eder, çünkü banner metni genellikle sayfa şablonundan ayrı bir yönetim panelinde saklanır ve yerelleştirme kontrol listesinden kolayca dışarıda kalır. Pratik önlem, yeni dil yayına alınmadan önce banner panelindeki dil eşleşmesini ayrı bir kalem olarak doğrulamaktır; şablon çevirisi bitti diye banner'ın da otomatik olarak çevrildiğini varsaymamak gerekir.
KVKK / GDPR metni dil versiyonuna göre değişmeli mi?
Banner'ın arkasındaki hukuki metin (hangi çerezlerin kullanıldığı, hangi yasal dayanağa göre işlendiği) dil versiyonuna göre içerik olarak farklılaşabilir, çünkü KVKK ve GDPR aynı çerez kategorisi için farklı onay eşiği isteyebilir. Türkçe versiyon KVKK'ya göre "aydınlatma + açık rıza" modelini uygularken, Almanca versiyon GDPR'ın "opt-in öncesi hiçbir çerezin tetiklenmemesi" kuralına tabi olabilir. Bu ayrım KVKK kapsamındaki çok dilli gizlilik sayfası yönetiminin banner düzeyindeki karşılığıdır; gizlilik sayfası metni değişse bile banner davranışı aynı kalıyorsa uyumsuzluk gizlilik sayfasında değil, banner'ın kendi mantığında oluşur.
SEO açısından asıl soru şudur: banner'ın tetiklediği script yükleme kararı dil versiyonuna göre farklılaşıyor mu? GDPR'a tabi bir dil versiyonunda analytics script'i onay öncesi hiç yüklenmiyorsa, o dil versiyonunun ilk yükleme performansı ile diğer versiyonların performansı arasında ölçülebilir bir fark oluşur; bu fark Core Web Vitals raporlarında dil bazlı bir tutarsızlık olarak görünebilir ve yanlışlıkla performans sorunu olarak araştırılabilir, halbuki kaynağı hukuki bir kural farkıdır.
Farklı CMP sağlayıcıları dil davranışında nerede ayrışır?
Piyasada yaygın kullanılan consent yönetim araçları, dil desteğini üç farklı seviyede sunar ve bu seviye farkı kurulum sırasında genellikle fark edilmez. Bazı araçlar dil paketini sabit bir liste olarak sağlar; sitenin desteklediği dil bu listede yoksa banner otomatik olarak İngilizce'ye veya panelde tanımlı bir varsayılana düşer. Bu davranış, örneğin Arapça veya Urduca gibi RTL bir dil eklendiğinde özellikle görünür hale gelir, çünkü RTL dillerin tarama ve indekslemeye etkisini ele alırken de değinildiği gibi, hazır bileşen kütüphaneleri RTL yön desteğini genellikle geç ekler; banner de bu kütüphanelerin bir parçasıdır ve dil metni doğru çıksa bile buton sırası ve okuma yönü ters kalabilir.
Bazı araçlar ise dil tespitini tamamen geliştiriciye bırakır: panelde bir JSON obje olarak dil-metin eşleşmesi tanımlanır ve hangi dilin hangi sayfada gösterileceği bir fonksiyon aracılığıyla sağlanır. Bu model daha fazla kontrol sağlar ama aynı zamanda daha fazla insan hatasına açıktır; yeni bir dil eklendiğinde bu fonksiyonun güncellenmesi unutulursa, banner sessizce eski dil listesine göre çalışmayı sürdürür. Üçüncü grup araç, sayfanın lang özniteliğini doğrudan okuyup kendi içindeki dil paketiyle eşleştirir; bu en az bakım gerektiren modeldir, çünkü şablon HTML'i zaten doğru lang değerini taşıyorsa banner otomatik olarak senkron kalır. CMP seçimi yapılırken bu üç modelden hangisinin kullanıldığını sormak, ileride tek tek dil versiyonu kontrolü yapmaktan daha ucuza gelir.
Banner kaynaklı sorunları tespit etmenin pratik yolu
Bu sorunları tespit etmenin en doğrudan yolu, her dil versiyonunu JavaScript'i devre dışı bırakılmış bir tarayıcı görünümünde açıp banner'ın DOM'a ne şekilde eklendiğini incelemektir; JavaScript ile eklenen katman Googlebot'un ilk HTML'inde yoksa tarama ile kullanıcı farklı şey görür. Ana içerik banner render edilmeden görünüyorsa risk düşüktür; ana içerik banner'a bağımlıysa, bu bağımlılığın gerekçesi sorgulanmalıdır. İkinci kontrol, her dil versiyonunda sayfa kaynağını görüntüleyip URL'de consent parametresi olup olmadığını ve canonical etiketin bu parametreden bağımsız kalıp kalmadığını doğrulamaktır.
Üçüncü ve en kolay atlanan kontrol, banner metninin fiilen doğru dilde çıkıp çıkmadığını her dil versiyonunda tek tek gezerek görmektir; bu kontrol otomatik araçlarla değil, gözle yapılan bir gezinti ile yapılır, çünkü CMP panelinin kendi dil ayarı dashboard'da doğru görünse de canlı sayfada farklı davranabilir. Bu üç kontrolü yayın öncesi, yeni dil ekleme süreçlerinde ve düzenli aralıklarla tekrarlamak, banner'ı SEO denetim listesinin dışında bırakmanın maliyetini önler.