Robots.txt tek bir metin dosyasıdır ve çoğu ekip onu kurulumun en basit parçası sayar: birkaç Disallow satırı, bir Sitemap direktifi, bitti. Tek dilli bir sitede bu varsayım genellikle doğru çıkar. Çok dilli bir yapıda ise dosyanın kapsamı, konumu ve içindeki her kural, alt dizin mi yoksa alt domain mi kullandığınıza göre tamamen farklı bir anlam kazanır; aynı satır bir mimaride tüm dil sürümlerini kapsarken diğerinde yalnızca birini kapsar.
Bu fark genellikle proje ilk kurulduğunda değil, ikinci veya üçüncü dil eklendiğinde ortaya çıkar. Tek dilli site için yazılmış robots.txt kopyalanıp yeni dil sürümüne aynen taşınır, çünkü "zaten çalışıyor" varsayımı vardır. Alt domain mimarisinde bu kopyalama işe yaramaz, çünkü her alt domain kendi robots.txt dosyasını kendi köküne ihtiyaç duyar. Alt dizin mimarisinde ise tek dosya yeterlidir, ama dosya içindeki yolların dil öneklerine göre doğru kapsanması gerekir; aksi halde bir dil versiyonu yanlışlıkla engellenir veya hiç engellenmemesi gereken bir yol açık kalır.
Kapsam host'a bağlıdır. Alt dizinde tek dosya bütün dilleri kapsar; alt domain'de her kök kendi dosyasını ister. Disallow satırı bir dilin slug'ına göre yazılmışsa diğer dilin çevrilmiş yolunu kapsamaz. Sitemap bildirimi, bot gecikmesi ve kurulum sonrası test bu farkın üzerine oturur.
Subdirectory ve subdomain yapılarında robots.txt kapsam alanı nasıl değişir?
Robots.txt standardı, dosyanın kapsamını host, protokol ve port üçlüsüne göre tanımlar. Bir tarayıcı https://site.com/tr/urun adresini taramadan önce https://site.com/robots.txt dosyasını kontrol eder; aynı host'un altında olduğu için /en/urun adresi de bu kontrolden geçer. Alt dizin mimarisinde bütün dil versiyonları aynı host altında yaşadığından, tek bir robots.txt dosyası tüm dilleri aynı anda kapsar. Bu, alt dizin ile alt domain arasındaki temel farkın teknik SEO tarafına yansıyan en somut örneklerinden biridir.
Alt domain mimarisinde durum köklü şekilde değişir. tr.site.com ve en.site.com arama motoru gözünde iki farklı host'tur; bir tarama botu en.site.com altında bir sayfaya gitmeden önce tr.site.com/robots.txt dosyasına bakmaz, kendi köküne bakar. Bu yüzden tr.site.com/robots.txt'e yazılan bir Disallow kuralı, en.site.com tarafını hiçbir şekilde etkilemez; iki alt domain birbirinden habersiz iki bağımsız kural setiyle yönetilir.
Bu ayrım küçük bir teknik detay gibi görünse de, kurulum ekibinin zihin modelini doğrudan belirler. Alt dizin ekibi "tek dosya, çok dil" mantığıyla çalışırken, alt domain ekibi "her dil kendi dosyasını yönetir" mantığıyla çalışmak zorundadır. Bu iki mantığın karıştırılması, genellikle ekip bir mimariden diğerine geçtiğinde veya iki mimariyi karma kullandığında (bazı diller alt dizinde, bazıları alt domain'de) ortaya çıkar; karma senaryoda hem tek dosya hem çok dosya mantığı aynı anda geçerli olur ve hangi kuralın nereyi kapsadığını takip etmek zorlaşır.
Her dil versiyonu için ayrı robots.txt mi, tek dosya mı?
Alt domain kullanan bir yapıda bu soru tercih değil, teknik zorunluluktur: her alt domain kök dizininde kendi robots.txt dosyasını barındırmalıdır, çünkü botlar başka bir host'un dosyasını okumaz. Bir alt domain için robots.txt eksikse, o alt domain "kısıtlama yok" varsayımıyla taranır; bu bazen istenen sonuçtur, bazen de fark edilmeden açık bırakılmış bir güvenlik açığıdır, özellikle staging benzeri bir alt domain yanlışlıkla canlıya alınmışsa.
Alt dizin yapısında tek dosya teknik olarak yeterlidir ve genellikle tercih edilen yoldur, çünkü bakım tek noktadan yapılır. Ama "tek dosya" kararı, dosya içindeki kuralların dil bazında ayrışmayacağı anlamına gelmez. Path bazlı Disallow ve Allow kuralları, /tr/ ve /en/ öneklerini ayrı ayrı hedefleyebilir; bu, tek dosyanın içinde çok dilli bir mantık kurmanın standart yoludur. Sorun, bu ayrımın bilinçli kurulmaması ve kuralların yalnızca bir dile göre yazılıp diğer dile sessizce uygulanmamasıdır.
Bazı ekipler alt dizin yapısında bile her dil için ayrı bir robots.txt istekle sunmayı dener; bu, standart dışıdır ve çoğu sunucu yapılandırmasında zaten mümkün değildir, çünkü /robots.txt yolu host başına tek bir statik dosyaya veya tek bir route'a bağlıdır. Bu isteği karşılamaya çalışmak yerine, tek dosya içinde path bazlı kural yazmayı doğru varsayım olarak kabul etmek gerekir. Dil öneklerini satır satır ayırdıktan sonra robots kuralını dosyaya dökmek, bir dile yazılan Disallow'un diğer dilde sessizce açık kalmasını azaltır.
Disallow kurallarının dil öneki ile çakıştığı noktalar
En sık görülen hata, bir dilin URL yapısına göre yazılmış bir kuralın diğer dilde çevrilmiş slug'ları kapsamamasıdır. Bir site sepet sayfasını Türkçe'de /tr/sepet/, İngilizce'de /en/cart/ olarak yapılandırdığında, Disallow: /tr/sepet/ kuralı yalnızca Türkçe sürümü kapsar; İngilizce sepet sayfası, yazan kişinin niyeti aynı olsa da, ayrı bir satırla tanımlanmadığı için açıkta kalır. Bu durum slug çevirisi yapılan her site tipinde (filtre sayfaları, hesap paneli, arama sonucu URL'leri) tekrarlanabilir bir risktir.
İkinci çakışma noktası, joker karakter kullanımıdır. Disallow: /*/admin/ gibi bir kural her dil önekinin ardından gelen admin yolunu kapsamayı hedefler, ama bu sözdizimi tüm arama motorları tarafından aynı şekilde yorumlanmaz; joker karakter desteği motor bazında farklılık gösterir. Dil öneklerini tek tek yazmak (/tr/admin/, /en/admin/, /de/admin/) daha uzun ama daha güvenilir bir yoldur, özellikle dil sayısı sınırlıysa.
Üçüncü nokta, bir dilin URL yapısında var olan ama diğerinde olmayan bir yol segmentidir. Bazı çok dilli kurulumlarda varsayılan dil önek taşımaz (/urun), diğer diller taşır (/en/product); bu asimetri, Disallow: /en/urun/ gibi bir kuralın varsayılan dildeki /urun/ yolunu hiç kapsamamasına yol açar, çünkü kural zaten var olmayan bir öneği hedeflemektedir. Bu tür asimetrik yapılarda her kural, o dilin gerçek URL şablonuna göre ayrı ayrı doğrulanmalıdır; şablonu tek bir dilden diğerine genellemek hatanın kaynağıdır.
Filtre ve arama parametreleri de benzer bir risk taşır. Bir e-ticaret sitesi ?renk=kirmizi parametresini Türkçe sayfada, ?color=red parametresini İngilizce sayfada kullanıyorsa, parametre adına göre yazılmış bir Disallow kuralı yalnızca bir dilde çalışır. Bu senaryonun teknik köküne çok dilli sitede teknik SEO denetim listesini ele alan yazıda daha geniş bir çerçevede yer verilmişti; robots.txt kuralları da bu denetimin bir parçası olarak dil bazında tekrar gözden geçirilmelidir.
Sitemap direktifi çok dilli yapıda nasıl konumlandırılır?
Alt dizin mimarisinde tek robots.txt dosyası tüm dilleri kapsadığı için, Sitemap direktifi de tek dosyada birden fazla satır olarak listelenebilir: her dil için ayrı bir sitemap dosyası varsa, hepsi aynı robots.txt içine Sitemap: satırları halinde eklenir, veya tüm dilleri kapsayan bir sitemap index dosyası tek satırla bildirilir. Uluslararası sitemap hazırlığını ele alan yazıda geçen dil bazlı sitemap ayrımı, robots.txt seviyesinde bu şekilde bir araya toplanır.
Alt domain mimarisinde bu toplama mümkün değildir. tr.site.com/robots.txt içine en.site.com'a ait bir sitemap adresi yazmak teknik olarak geçersiz sayılmaz, ama pratik faydası yoktur; her alt domainin arama motoru tarafından bağımsız bir varlık gibi değerlendirildiği unutulursa, bir botun başka bir host'un robots.txt dosyasında gördüğü sitemap bildirimini nasıl işleyeceği belirsizleşir. Güvenilir yöntem, her alt domainin kendi sitemap'ini kendi robots.txt dosyasında bildirmesidir; çapraz bildirim yerine, dil sayısı kadar tekrarlanan ama her biri kendi kapsamında tutarlı bir yapı kurulur.
Sitemap direktifinin konumu (dosyanın başı veya sonu) motorlar için teknik bir fark yaratmaz, ama okunabilirlik açısından dosyanın en altına, tüm Disallow/Allow kurallarından sonra yazılması yaygın bir kuraldır. Çok dilli bir dosyada satır sayısı arttığında bu düzen, hangi kuralın hangi dile ait olduğunu takip etmeyi kolaylaştırır; kurallar dil önekine göre gruplanıp yorum satırlarıyla ayrılırsa (# Türkçe kuralları, # İngilizce kuralları), dosya büyüdükçe bakım maliyeti düşer.
Bot bazlı kurallar dil versiyonlarını nasıl etkiler?
User-agent bazlı kurallar (belirli bir botu tamamen engellemek) ve crawl-delay direktifi, çok dilli sitelerde dil versiyonları arasında eşit olmayan bir tarama dağılımı yaratabilir. Bir ekip sunucu yükünü azaltmak için Crawl-delay: 10 gibi bir değer eklediğinde, bu değer tüm dosyaya (alt dizin durumunda tüm dillere) uygulanır; tarama bütçesi zaten sınırlı olan az trafikli bir dil versiyonu, popüler bir dil versiyonuyla aynı gecikmeye tabi tutulduğunda, oransal olarak daha büyük bir kayıp yaşar.
Alt domain yapısında bu kural her alt domain için ayrı ayrı verilebildiğinden, dil bazında farklılaştırma teknik olarak daha kolaydır: yüksek trafikli bir dil için gecikme düşük tutulup az trafikli bir dil için daha yüksek bir değer verilebilir. Ama bu esneklik aynı zamanda bir risk taşır; her alt domain için farklı bir kural seti yönetildiğinde, bir ekip üyesi bir alt domaine kural eklerken diğerine eklemeyi unutabilir, bu da dil versiyonları arasında istenmeyen bir tutarsızlık yaratır.
Belirli botları engelleme kararı da dil bazında farklı sonuçlar üretebilir. Bir bölgeye özgü arama motoru botu (örneğin belirli bir pazarda güçlü bir yerel motor) genel bir kuralla yanlışlıkla engellenirse, bu engelleme o botun ağırlıklı olarak taradığı dil versiyonunu diğerlerinden daha çok etkiler. User-agent adlarının doğru ve güncel olup olmadığını kontrol etmek, çok dilli bir sitede tek dilli bir siteye göre daha yüksek önem taşır, çünkü hatanın etkisi tüm sitede eşit dağılmaz.
Yanlış yapılandırmanın belirtileri: hangi dil versiyonu taranmıyor?
Yanlış yapılandırılmış bir robots.txt genellikle sessiz kalır; sunucu hata döndürmez, sayfa erişilebilir görünür, ama tarama gerçekleşmez. Bu sessizlik yüzünden sorun, genellikle Search Console'un kapsam raporunda "robots.txt tarafından engellendi" etiketiyle beklenmedik bir dil versiyonunda görüldüğünde fark edilir; rapor tek bir dile ait sayfaların yoğunlaştığını gösteriyorsa, bu neredeyse her zaman dil öneğiyle çakışan bir kuralın işaretidir.
İkinci belirti, sitemap gönderilmiş ama ilgili dilin sayfaları indekslenmemiş olmasıdır. Sitemap'te listelenen bir URL robots.txt tarafından engellenmişse, Google bu URL'i taramayı reddeder ve indeksleme hiç gerçekleşmez; bu senaryo dışarıdan bakıldığında bir indeksleme sorunuymuş gibi görünür, ama kök neden robots.txt'tedir. Google Search Console'da uluslararası hedeflemeyi ele alan yazıda anlatılan raporlama alışkanlığı, bu ayrımı erken yakalamanın en pratik yoludur.
Alt domain yapısında üçüncü bir belirti ortaya çıkar: bir alt domainin robots.txt dosyası hiç oluşturulmamışsa veya sunucu yapılandırması yanlışsa, o dosyaya yapılan istek 404 döner. Botlar 404 dönen bir robots.txt'i genellikle "kısıtlama yok" olarak yorumlar, ama bazı durumlarda sunucu 404 sayfasını normal bir HTML içerikle döndürür ve bu içerik yanlışlıkla robots.txt gibi işlenmeye çalışılabilir; log dosyalarında bu tür bir isteğin durum kodunu kontrol etmek, dosyanın gerçekten var olup olmadığını doğrulamanın en net yoludur.
Kurulum sonrası doğrulama: robots.txt testi nasıl yapılır?
Doğrulamanın ilk adımı, her dil versiyonunun robots.txt'ini kendi adresinden tek tek açmaktır: alt dizin yapısında bu tek bir dosya olduğu için hızlı bir kontrol yeterlidir, ama alt domain yapısında her alt domainin kendi dosyası ayrı ayrı açılmalı ve dosyanın gerçekten var olduğu, boş veya hatalı dönmediği teyit edilmelidir. Bir dosyanın "genel olarak doğru görünmesi" başka bir alt domainin de doğru olduğu anlamına gelmez.
İkinci adım, Search Console'un robots.txt test aracını her mülk (property) için ayrı ayrı çalıştırmaktır. Alt domain yapısında her alt domain kendi Search Console mülkü olarak tanımlanır; bir mülkte yapılan test diğerini kapsamaz. Belirli bir URL'in taranıp taranamayacağını test etmek, o dile özgü slug ve parametre yapısıyla yapılmalıdır, genel bir örnek URL üzerinden yapılan test diğer dillerin gerçek URL şablonunu yansıtmaz.
Üçüncü adım, robots.txt kurallarının hreflang ve canonical sinyalleriyle çelişip çelişmediğini çapraz kontrol etmektir. Bir sayfa hreflang ile başka bir dil sürümüne işaret ediyorsa ama o sürüm Disallow ile kapatılmışsa Google iki sinyalden birini kendi başına seçer. Kontrol somuttur: her dil önekinden birer URL'yi GSC robots.txt testine verin, hreflang'ın gösterdiği hedef taranabiliyor mu bakın. Locale-adaptive (aynı URL, farklı içerik) bir kurulumdaysanız robots.txt hangi varyantı görünür bıraktığını da aynı testte netleştirin; dosya tek olsa bile davranış host ve path'e göre değişir.
Robots.txt'in çok dilli bir sitede taşıdığı risk, dosyanın karmaşıklığından değil, görünmez oluşundan gelir. Bir kural yanlış yazıldığında sayfa hâlâ tarayıcıda normal görünür, sunucu hata vermez, tek belirti aylar sonra indeksleme raporunda ortaya çıkar. Bu gecikme, hatanın kaynağını geriye dönük olarak bulmayı zorlaştırır; kurulum anında dil bazında tek tek doğrulama yapmak, bu geriye dönük arayışın önüne geçen tek pratik yoldur.
Alt dizin veya alt domain kararı zaten verildikten sonra, robots.txt bu kararın bir sonucu olarak şekillenir, kendi başına bir mimari tercih taşımaz. Asıl emek, mevcut mimarinin gerektirdiği kural sayısını ve kapsamını doğru çıkarmakta ve her dil eklendiğinde bu kapsamı yeniden gözden geçirmekte harcanır.