Allow yönergesi, robots.txt dosyalarında en sık yanlış anlaşılan direktiflerden biridir. Yaygın yanılgı şu: sanki arama motorlarına "şu sayfayı tara" diye açık bir izin veriyormuş gibi algılanıyor. Oysa Allow, tek başına hiçbir şey yapmaz. Anlam kazandığı tek bağlam, üst düzey bir Disallow kuralının geçerli olduğu bir klasör içindeki istisnalardır.
Başka bir deyişle, Disallow olmayan yerde Allow yazmak botlar için işlevsiz bir satırdır. Bu ayrımı kavramadan yazılan robots.txt yapılandırmaları hem gereksiz kurallarla şişer hem de gerçek ihtiyacı karşılamaz. Pek çok sitede Allow satırları yanlış konumlanmış, teknik bir etkisi olmayan süslemeler olarak durmaktadır.
Disallow olmadan Allow çalışmaz
Robots.txt varsayılan davranışı izin vericidir; bir URL Disallow ile engellenmediği sürece tüm botlar o URL'e erişebilir. Bu nedenle /hakkinda.html sayfası için Allow: /hakkinda.html yazmak teknik bir anlam taşımaz. Zaten erişime açık olan bir şeye izin veriyorsunuz.
Allow'un gerçek işlevi, Disallow ile kapatılmış bir alanın içindeki belirli bir alt yolu geri açmaktır. Klasik örnek:
User-agent: *
Disallow: /ozel/
Allow: /ozel/paylasilabilir.htmlBu yapılandırmada Googlebot /ozel/ altındaki tüm URL'leri atlıyor; yalnızca /ozel/paylasilabilir.html açık kalıyor. Bunu tersine çevirin: sadece Allow: /ozel/paylasilabilir.html yazıp Disallow'u kaldırırsanız, bot /ozel/ dizinini zaten tamamen tarayabilir ve Allow satırını okumaz bile. İşlevsiz bir kural olur.
Googlebot bir URL'i taramadan önce kök dizindeki robots.txt dosyasını çeker ve kendi User-agent değerine uyan blokları okur. User-agent: * ile yazılmış kurallar tüm botları kapsarken, User-agent: Googlebot gibi özelleştirilmiş bloklar yalnızca o botu etkiler. Bir bot, kendine özel bir blok bulamazsa * bloğuna bakar. Bu sıralama Allow kurallarını yazarken de geçerlidir: bir Allow, yalnızca aynı User-agent bloğu içindeki Disallow'a karşı çalışır; farklı bir blokta tanımlı Disallow ile etkileşmez.
Çakışan kurallarda hangi yönerge kazanır?
Allow ve Disallow aynı URL'i eşlediğinde Google, prefix uzunluğuna bakarak karar verir: daha uzun prefix kazanır.
Disallow: /urunler/
Allow: /urunler/indirim//urunler/indirim/yaz-koleksiyonu.html için /urunler/indirim/ prefix'i daha uzun olduğundan Allow kuralı geçerli olur, Googlebot sayfayı tarar. Sıra fark etmez. Bazı kaynaklar "önce gelen kural kazanır" der; bu yanlıştır. Google her zaman prefix uzunluğunu esas alır, robots.txt dosyasındaki Allow ve Disallow satırlarının sırası belirleyici değildir.
Peki eşit uzunlukta iki kural çakışırsa? Google bu durumda Allow'a öncelik verir. Yandex farklı davranır; Allow'un varlığında bile Disallow'u baskın kabul edebilir. Bing ise Google ile benzer prefix uzunluğu mantığını izler; ancak wildcard yorumlamasında ince farklar çıkabilir. Çok motorlu yapılarda eşit uzunluk çakışmasından kaçınmak için kuralları ayrıştırmak, her motor için beklenen davranışı netleştirmek açısından daha güvenlidir.
Birden fazla User-agent bloğu olan dosyalarda ek bir karmaşıklık devreye girer. Googlebot hem User-agent: * bloğundan hem de User-agent: Googlebot bloğundan etkilenebileceğini düşünenler yanılıyor. Googlebot, kendine özel bir blok varsa yalnızca onu okur; * bloğunu yok sayar. Bu nedenle iki ayrı blokta farklı Allow/Disallow kombinasyonları yazıldığında beklenmedik davranışlar ortaya çıkabilir. Aynı yönergeyi iki bloğa dağıtmak yerine, ilgili bota yönelik kuralları tek blokta toplamak yönetimi kolaylaştırır.
Wildcard ile Allow kombinasyonu: * ve $ farkı
* karakteri Allow ve Disallow kurallarında "herhangi bir dizi" anlamına gelir. $ ise URL'in tam burada bitmesi gerektiğini belirtir. İkisi birbirinden çok farklı davranır ve yanlış tercih sessizce işlevsiz kurallara yol açar.
Disallow: /api/
Allow: /api/dokuman*Bu kural /api/dokuman-v1.html, /api/dokumantasyon/ ve /api/dokuman gibi tüm URL'lere erişim açar; /api/ altındaki geri kalan her şey kapalı kalır. $ karakteriyle yazılmış bir Allow ise yalnızca tam olarak o URL'e eşleşir:
Allow: /api/durum$Bu kural sadece /api/durum'u açar; /api/durum/ (sonda eğik çizgiyle) veya /api/durum?v=2 eşleşmez. Query string taşıyan URL'leri bloke edip temiz kökü açık tutmak istediğinizde $ işe yarar. Filtrelenmiş liste sayfaları veya oturum parametresi eklenmiş URL'ler gibi bot için değersiz ama varlığı kaçınılmaz URL'leri kapamak için şu kombinasyon sık kullanılır:
Disallow: /arama?*
Allow: /arama$Bu yapı /arama?q=test, /arama?sayfa=2 gibi parametre içeren URL'leri engeller; yalnızca /arama kökünü açık bırakır. Sonsuz tarama bütçesi tüketen facet URL'leri veya sıralama parametreleri için benzer mantık uygulanabilir.
Sık yapılan hata ise wildcard kullanmadan Allow: /api/dokuman yazmak. Bu kural yalnızca tam olarak /api/dokuman URL'ine eşleşir; /api/dokuman/ veya /api/dokuman?v=2 eşleşmez. Aynı kelimeyle başlayan alt URL'leri açmak istiyorsanız Allow: /api/dokuman* yazmanız gerekir.
Allow'u gerçekten kullanan senaryolar
WordPress kurulumlarında en bilinen örnek: /wp-admin/ tamamen Disallow ile kapatılıyor, ama admin-ajax.php bazı ön yüz işlevleri (sonsuz kaydırma, AJAX arama, live chat widget) için botların erişmesi gerekiyor.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpBu yapılandırma olmazsa Googlebot admin-ajax.php üzerinden yüklenen içeriği göremez. İçerik JavaScript ile render edilip AJAX çağrısına bağlıysa tarama sırasında eksik görünür. Küçük bir istisna, ciddi bir indeksleme farkı yaratabilir.
Görsel botları ayrıca yönetmek de geçerli bir senaryo. Googlebot-Image görsel içeriği indekslemek için ayrı taramalar yapar; User-agent: * ile kapatılmış bir dizini görsel bota açık tutmak istiyorsanız ayrı bir blok tanımlanması gerekir:
User-agent: Googlebot-Image
Allow: /ozel/gorseller/
Disallow: /Benzer bir ihtiyaç staging ortamlarında çıkar: parola korumalı bir test alanında yalnızca teknik denetim için bir URL'i açık bırakmak, geri kalanı kapalı tutmak. Ya da /private/ klasöründe müşteri belgelerinin tamamı gizlenmiş ama bir demo PDF erişime açık bırakılmak isteniyorsa Allow tek doğru yaklaşımdır.
E-ticaret platformlarında /sepet/, /odeme/ ve /hesabim/ genellikle Disallow ile kapatılır. Ödeme akışının bir parçası olan yönlendirme URL'lerinin açık kalması gerektiğinde Allow'u noktasal kullanmak mümkün. Bu tür robots.txt yapılandırmalarını hazırlarken Allow ve Disallow kurallarını görsel arayüzde sıralayıp çakışmaları doğrudan görmek için oluşturucu aracı kullanabilirsiniz.
Allow'un çözmediği şeyler
Allow yalnızca taramayı etkiler; indekslemeyi ve içeriğin görünürlüğünü kontrol etmez. Bir sayfaya Allow verseniz bile sayfada <meta name="robots" content="noindex"> varsa Googlebot sayfayı tarar, ama indekslemez. İkisi birbirinden bağımsız katmanlardır; bu fark, Disallow ile noindex arasındaki temel ayrımda da belirleyicidir.
Bunun tersi de beklenmedik sonuç üretir: Disallow verilen bir URL'i ziyaret eden bot sayfayı tarayamaz, dolayısıyla noindex etiketini de göremez. Başka sitelerden o URL'e bağlantı varsa, URL arama sonuçlarında içeriksiz biçimde görünmeye devam edebilir. Bir sayfayı hem taramadan hem indekslenmekten korumak istiyorsanız Disallow yeterli değildir; sayfanın botlara erişilebilir olması ve noindex taşıması gerekir.
Sunucu katmanı da Allow'u ezer. Robots.txt izni 401'in önüne geçmez. .htaccess düzeyinde IP kısıtı veya temel kimlik doğrulaması (HTTP Basic Auth) olan bir URL'ye Allow yazmak işlevsizdir. Bot URL'e geldiğinde 401 veya 403 döner, içeriğe ulaşamaz. Belirli botlara sunucu düzeyinde erişim tanımlamak gerektiğinde bu farklı bir yapılandırma katmanını ilgilendirir.
Sitemap ile ilişkisi de gözden kaçan bir nokta: XML sitemap oluştururken eklediğiniz URL'lerin robots.txt tarafından engellenmemiş olması gerekir. Sitemap'te yer alıp Disallow kuralına takılan URL'ler Search Console'da "engellendi ama sitemap'te" uyarısı üretir. Allow ile geri açmayı planladığınız URL'leri sitemap'e eklemeden önce prefix eşleşmesinin doğru çalıştığını doğrulayın. Search Console'daki robots.txt test aracı bu eşleşmeyi URL bazında görsel olarak gösterir; büyük yapılandırmalarda elle takip etmeye çalışmak hata üretir.
Allow kuralını minimal yazın: tam olarak geri açmak istediğiniz path neyse, o kadar. Aşırı geniş wildcard beklediğinizden fazla URL'i açabilir; hiç yazmamak ise Disallow'un kapattığı işlevsel bir sayfayı karanlıkta bırakabilir. Her Allow satırı, neden yazıldığını ve hangi Disallow'a karşı çalıştığını anlatan bir yorum satırıyla belgelenirse ilerideki yapılandırma değişikliklerinde yanlış silme riski azalır.
CDN veya reverse proxy arkasındaki yapılarda Allow davranışı bazen beklenenden farklı çıkar. Cloudflare gibi bir CDN, botlara farklı bir robots.txt sunabilir ya da orijin sunucuya yönlendirme yaparken URL'i değiştirebilir. Böyle ortamlarda Allow kurallarını canlıda test etmek, geliştirme ortamındaki gözlemlerden daha güvenilir sonuç verir. Google Search Console URL Inspection aracı, Googlebot'un belirli bir URL için hangi robots.txt kuralıyla eşleştiğini ve bu eşleşmenin taramaya izin verip vermediğini doğrudan gösterir; prefix uzunluğu hesabını elle yapmak yerine bu araçtan yararlanmak daha hızlı ve hata payı daha düşük bir doğrulama yöntemidir.
Yapılandırmanın büyüdüğü sitelerde Allow kurallarının periyodik gözden geçirilmesi de önem taşır. Zamanla kaldırılan klasörler veya yeniden yapılandırılan URL şemaları, artık hedef almadığı bir Disallow'a karşı duran Allow satırları bırakabilir. İşlevsiz bir Allow zararlı değildir; ama temiz tutulmamış bir robots.txt dosyasını yorumlamak güçleşir ve gerçek kuralların nerede çalıştığını anlamak için daha fazla zaman harcarsınız. Kullandığınız kuralların listesi kısaldıkça hata ayıklama hızlanır.