Bir e-ticaret sitesinin Türkçe versiyonunda arama kutusuna yazılan her sorgu kendi URL'sini üretiyor, İngilizce versiyonunda da aynı mekanizma çalışıyor, ve altı ay sonra log dosyalarına bakıldığında Googlebot'un günlük tarama bütçesinin büyük bir kısmının bu iki dil sürümünün arama sonucu sayfalarına gittiği görülüyor. Site sahibi bu URL'lerin var olduğunu bile bilmiyor; onları kimse sitemap'e eklemedi, kimse iç linkten bağlamadı, ama bot bulmuş ve düzenli olarak ziyaret ediyor.
İç arama sonuçları sayfası, kullanıcı arama kutusuna bir kelime yazdığında sunucunun ürettiği dinamik bir sayfadır ve URL'sinde genellikle bir sorgu parametresi taşır. Tek dilli bir sitede bu zaten dikkatli yönetilmesi gereken bir alan; çok dilli bir sitede aynı sorgu mantığı her dil sürümünde tekrarlandığı için üretilen URL sayısı dil sayısıyla çarpılıyor. Bu çarpım, faceted navigation'ın çok dilli sitede ürettiği ölçek problemine yakın bir doğa taşıyor, ama arama sonuçları sayfalarının kendine özgü bir farkı var: kullanıcı hangi kelimeyi yazacağını önceden bilemediğiniz için üretilebilecek URL kümesi teorik olarak sınırsız.
Bu sınırsızlık diğer URL üretim sorunlarından ayrıştıran kritik özelliktir. Faceted navigation'da kombinasyon sayısı öngörülebilir, büyük ama sonlu; iç arama sonuçları sayfaları kullanıcı davranışına bağlı olduğu için günden güne büyür ve hangi dil sürümünde ne kadar hızla büyüdüğünü önceden kestirmek mümkün değildir.
İç arama sonucu sayfası teknik olarak nedir, Google neden temkinli yaklaşır
Bir arama sonucu sayfası, sitenin kendi içeriğinden derlenmiş bir listeleme sunar ama kendi başına özgün bir içerik üretmez; sayfa başlığı genellikle sorgu kelimesini tekrarlar, gövde içeriği ise mevcut ürün veya makale özetlerinin yeniden düzenlenmiş halidir. Google bu tip sayfaları "arama sonucu sayfası döndüren arama sonucu sayfası" riski taşıdığı için özellikle hassas değerlendiriyor; kullanıcı Google'da arama yapıp sitenize geldiğinde, orada bir başka arama sonucu sayfasıyla karşılaşmasını istemiyor.
Sorgu kelimesi popülerse ve sonuç listesi zenginse (örneğin bir e-ticaret sitesinde "kırmızı ayakkabı" araması onlarca ürün döndürüyorsa) bu sayfa kategori sayfasına yakın bir değer taşıyabilir. Sorgu az kullanılıyorsa veya sonuç listesi boşsa (sıfır sonuç sayfaları) sayfa hiçbir katma değer üretmez ve indekste yer almasının hiçbir gerekçesi kalmaz. Bu iki uç arasındaki geniş orta bölge, kararın otomatik bir kural yerine sayfa bazlı bir değerlendirme gerektirdiği yerdir.
Google'ın bu sayfaları değerlendirirken baktığı sinyaller somuttur: başlık etiketinde sorgu parametresi değeri ham haliyle tekrarlanıyor mu, sayfa içeriği her sorguda tamamen değişiyor mu, sıfır sonuç durumu sistematik olarak işleniyor mu? Başlıkta ?q=kırmızı+ayakkabı değerinin doğrudan göründüğü bir sayfa kalite eşiğinin oldukça altında başlıyor; şablonu düzeltmek, her dil sürümünde ayrı ayrı yapılması gereken ama sık atlanan bir adımdır.
Çok dilli yapı bu sorunu nasıl çarpıyor
Tek dilli bir sitede yüz farklı sorgu, yüz potansiyel URL üretir. On dilli bir sitede aynı yüz kavramsal sorgu, her dilde farklı kelimelerle arandığı için bin URL'e çıkar, üstelik her dil sürümünün kendi sıfır sonuç oranı, kendi popüler sorgu dağılımı ve kendi teknik yapılandırması olur. Bir dil sürümünde arama motoru düzgün noindex uyguluyorken, yeni eklenen bir dil sürümünde bu yapılandırma unutulmuşsa, o dil sürümü tek başına yüzlerce zayıf sayfayı indekse açık bırakabilir.
Bu risk özellikle yeni dil eklenirken gözden kaçıyor; ekip URL yapısını, hreflang kümesini ve şablonu yeni dile taşırken, arama sonucu sayfası gibi ikincil bir bileşenin teknik ayarlarını kopyalamayı atlıyor. Sonuç, en eski ve en iyi optimize edilmiş dil sürümü temiz görünürken, en yeni dil sürümünün arama sonucu sayfaları kontrolsüz şekilde büyüyor. Dil bazlı indeks durumunu düzenli izlemek, bu asimetriyi erken yakalamanın en pratik yolu; hangi dil versiyonunun indekslendiğini görme yöntemleri burada arama sonucu sayfalarını da kapsayacak şekilde genişletilmeli.
Platform seçimi bu riski büyütür ya da küçültür. Bazı CMS'ler yeni dil ekleme sihirbazında arama ayarlarını ayrıca sormaz; geliştirici varsayılan kurulum tamamlandı sanarak devam eder ve aylar sonra log verisinde sorun fark edilir. Çok kiracılı yapılarda ise bir müşteri ortamına yapılan yapılandırma değişikliği diğerini etkileyemez; bu durumda arama sonucu sayfası davranışı her dil sürümü için tek tek denetlenmelidir, merkezi bir ayar "hepsine geçerli" değildir.
Noindex kararı ne zaman otomatik, ne zaman tartışmalı
Varsayılan kural basit: sorgu parametresi taşıyan arama sonucu URL'leri noindex olmalı, çünkü bu sayfaların sonsuz kombinasyonu tarama bütçesini tüketir ve içerik kalitesi tutarsızdır. Sıfır sonuç döndüren sorgular için bu karar tartışmasız; boş bir sayfanın indekste yer alması hiçbir kullanıcıya fayda sağlamaz ve genellikle kötü kullanıcı deneyimi sinyali üretir.
Tartışma, yüksek hacimli ve zengin sonuç döndüren sorgularda başlıyor. Bazı siteler bu sorguları statik bir kategori veya landing sayfasına dönüştürüp indekslenebilir hale getiriyor; bu, arama sonucu sayfasını olduğu gibi indekslemekten farklı bir karar, çünkü URL yapısı, başlık ve iç link mimarisi ayrı bir sayfa gibi kurgulanıyor. Çok dilli bir sitede bu dönüşüm kararı her dil için ayrı ayrı verilmeli; bir dilde yüksek hacimli olan bir sorgu diğer dilde nadiren aranıyor olabilir, ve otomatik bir kuralı tüm dillere aynı eşikle uygulamak bazı dillerde gereksiz sayfa üretimine, bazılarında ise değerli bir fırsatın atlanmasına yol açar.
Eşiği belirlemek için pratik bir başlangıç noktası var. GSC'de o sorgunun organik trafik getirip getirmediğine bakın; trafik geliyorsa ve sonuç listesi en az sekiz ile on ürün ya da makale içeriyorsa, o sorguya özel bir landing sayfası açmak değerlendirilmeye değer. Trafik yoksa veya sonuç listesi inceyse, noindex hem daha hızlı hem daha güvenli bir karardır. Bu değerlendirmeyi dil sürümleri arasında bağımsız yapmak, tek bir merkezi karardan her zaman daha doğru bir tablo verir.
Crawl bütçesi: botlar bu URL'leri nasıl keşfediyor
Arama sonucu sayfaları çoğunlukla ana navigasyondan link almaz, bu yüzden site sahipleri onları "gizli" sanır. Ama Googlebot bu URL'leri en az dört farklı yoldan öğrenir: otomatik tamamlama önerilerinin ürettiği ara sayfalar, "önerilen aramalar" veya "popüler aramalar" widget'ları üzerinden verilen doğrudan linkler, kullanıcı tarafından paylaşılan ve başka sitelerden gelen backlink'ler, ve yanlışlıkla sitemap'e dahil edilmiş dinamik URL'ler. Çok dilli bir sitede bu dört kanal da dil sayısıyla çoğalır.
Log dosyası analizi, bu keşif kanallarının hangisinin gerçekten aktif olduğunu gösteren en güvenilir kaynak; log analizi ile Googlebot davranışını izleme yöntemi burada özellikle işe yarıyor, çünkü GSC raporu genellikle bu URL'leri toplu bir kategori altında gösterir ve hangi dil sürümünün hangi oranda tarama bütçesi tükettiğini ayrıştırmaz. Bir dil sürümünde arama sonucu sayfalarının toplam tarama isteklerinin üçte birini aldığı görülürse, bu genellikle o dil sürümünde eksik bir noindex kuralı veya yanlışlıkla açılmış bir iç link kaynağı olduğunun işaretidir.
Kanalları sırayla kapatmak işe yarar. Önce sitemap'i kontrol edin: dinamik veya parametrik URL'ler dahil edilmiş mi? Ardından şablon koduna bakın: "popüler aramalar" veya "önerilen aramalar" modülü bu URL'lere doğrudan ve takip edilebilir link veriyor mu? Son olarak, botun sitemap dışı kaynaklardan bu URL'leri öğrenip öğrenmediğini log verisiyle kontrol edin. Üç kanaldan beslenen bir sorun, yalnızca noindex etiketi ekleyerek çözülmez; zaten indekste olan URL'lerin temizlenmesi için noindex etiketinin taranması gerekir ve bu birkaç haftalık ayrı bir süreçtir.
Dil bazlı arama parametresi ve teknik uygulama kararları
Sorgu parametresinin adı çoğu zaman tüm dil sürümlerinde aynı kalır (?q= veya ?search= gibi), bu teknik açıdan doğru bir tercih çünkü backend tarafında tek bir işleme mantığı kurmayı kolaylaştırır. Ama parametre değeri her dilde farklı karakter setleri taşıyabilir; Arapça veya Rusça sorgular URL kodlamasında çok daha uzun karakter dizilerine dönüşür, ve bu durum bazı eski CMS'lerde URL uzunluk sınırını aşarak beklenmedik hatalara yol açabilir.
Noindex uygulamasının kendisi üç katmanda kurulabilir: sayfa başına robots meta etiketi, HTTP header üzerinden X-Robots-Tag, veya robots.txt üzerinden parametre bazlı engelleme. Üçü arasında en güvenilir olanı meta etiketi, çünkü sayfa gerçekten taranıp indekslenmemesi gerektiğini açık şekilde bildirir; robots.txt engellemesi ise sayfanın taranmasını durdurur ama zaten indekste olan bir URL'nin kaldırılmasını garanti etmez, üstelik taranmayan bir sayfanın noindex etiketi de görülemez hale gelir. Çok dilli bir sitede bu üç katmanın hangisinin kullanıldığı dil sürümleri arasında tutarlı olmalı; robots.txt yapılandırmasının dil versiyonları arasında nasıl kurulduğu burada arama sonucu sayfaları için de aynı mantıkla genişletilmeli, tek bir dilde robots.txt üzerinden engelleme yapılıp diğerlerinde meta etikete güvenilmesi karışık ve denetlenmesi güç bir yapı üretir.
Katman seçimi çoğunlukla mimarinin kısıtlarından çıkar. JavaScript ağırlıklı render kullanan ve meta etiketi güvenilir şekilde oluşturamayan bir yapıda X-Robots-Tag seçeneği devreye girer; ama bu durumda CDN katmanının header'ı bozup bozmadığını ayrıca doğrulamak gerekir. Header sıyrılırsa noindex kaybolur ve sayfa hiçbir uyarı vermeden indekse açık kalır. Hangi yöntemi seçerseniz seçin, dil sürümleri arasındaki tutarsızlık tek başına risk kaynağıdır.
Sık yapılan hatalar ve karışan sinyaller
En sık görülen hata, arama sonucu sayfasına canonical etiketi eklerken onu ana arama sayfasına (boş sorgu haline) işaret ettirmek; bu, farklı sorguların farklı sonuçlarını aynı URL'e yığar ve Google'ın gözünde neredeyse tüm sorgu sayfalarını birbirine karıştırır. Doğru yaklaşım, arama sonucu sayfalarına self-canonical vermek veya doğrudan noindex uygulayıp canonical'ı hiç devreye sokmamak; ikisini aynı sayfada karıştırmak, filtre URL'lerinde görülen benzer canonical karmaşasıyla aynı kökten geliyor.
İkinci hata, arama kutusunun otomatik tamamlama özelliğinin her harf girişinde bir URL değişikliği tetiklemesi; kullanıcı daha sorguyu tamamlamadan tarayıcı geçmişine ve bazen sitemap'e onlarca ara durum kaydediliyor. Üçüncü hata, çok dilli sitelerde arama kutusunun placeholder metninin veya sonuç sayfası başlığının çevrilmemesi; sorgu parametresi Türkçe karakterler taşırken sayfa başlığı İngilizce şablondan kalan bir metin gösteriyorsa, bu hem kullanıcı deneyimini hem de o sayfanın nadiren de olsa indekslenme ihtimalindeki kalite sinyalini zayıflatıyor. Dördüncü ve en kalıcı hata, bu kararın bir kere alınıp bir daha kontrol edilmemesi; site büyüdükçe yeni arama widget'ları, yeni öneri modülleri eklendikçe, eski noindex kuralının kapsamadığı yeni bir URL deseni ortaya çıkabiliyor ve bu genellikle aylar sonra log verisinde fark ediliyor.
Beşinci hata daha sessiz gelişir. Bazı CMS'ler tüm dinamik sayfaları şablon düzeyinde işlediği için, arama sonucu URL'leri de hreflang alan sayfalar arasına giriyor ve noindex kararıyla çelişen bir sinyal üretiyor. Noindex ile hreflang aynı sayfada bulunduğunda Google hreflang'ı yok sayar; ama bu çelişkiyi temizlemek dil sürümleri arasında tutarsız bir hreflang kümesi bırakır ve ayrı bir inceleme gerektirir. Şablon düzeyinde hreflang üretimi devreye giriyorsa, arama sonucu URL pattern'larının bu üretimden açıkça hariç tutulduğunu doğrulamak gerekir.
İç arama sonucu sayfalarını yönetmek, tek seferlik bir teknik ayar değil, sitenin arama davranışı değiştikçe yeniden gözden geçirilmesi gereken bir alan. Çok dilli bir yapıda bu gözden geçirme her dil sürümü için ayrı yapılmalı, çünkü bir dilin arama alışkanlığı diğerine hiç benzemeyebilir. Kararın kendisi basit bir açma kapama anahtarı değil; hangi sorgunun gerçek değer taşıdığını, hangisinin sadece tarama bütçesini tükettiğini ayırt eden, dil sürümü bazında yürütülen sürekli bir değerlendirme sürecidir.
Pratik bir kontrol takvimi bu süreci yönetilebilir kılar. Her yeni dil eklenmesinden sonra arama sonucu sayfası yapılandırması ayrıca doğrulanmalı; yeni bir arama widget'ı veya öneri modülü devreye alındığında tekrar kontrol edilmeli; altı ayda bir log verisi üzerinden dil bazında tarama dağılımı incelenmeli. Bu üç tetikleyici, sorunun aylar sonra fark edilmek yerine kaynak noktasında yakalanmasını sağlar. Yeni dil ekleme sürecinde yapılandırma kontrol listesi bu adımı baştan kapsayacak şekilde genişletilirse, her seferinde ayrı bir denetim yapmak gerekmez.