Python betiği, sunucuların robots.txt'ye izin verdiği AI crawler'ları gerçekten servis edip etmediğini kontrol ediyor

dev.to'da yazan bir geliştirici, AI crawler yönetimindeki sessiz bir sorunları hedef alan kompakt bir Python aracı paylaştı: robots.txt bir sitenin neye izin verdiğini belirtir ama sunucunun gerçekte ne teslim ettiği hakkında hiçbir şey söylemez. Bir firewall veya CDN bot kuralı, robots.txt'nin açıkça hoş karşıladığı bir crawler'a 403 döndürebilir ve dosyadaki hiçbir şey bunu ortaya çıkaramaz.

Tek geçişte iki kontrol

Yazıya göre betik bir base URL ve isteğe bağlı bir path alıyor, ardından dört AI crawler'ı değerlendiriyor: OpenAI'nin GPTBot'u, OpenAI'nin OAI-SearchBot'u, Anthropic'in ClaudeBot'u ve Perplexity'nin PerplexityBot'u. Her bot için iki şey yapıyor: sitenin robots.txt'sini protego kütüphanesiyle ayrıştırarak o botun path'i çekip çekemeyeceğini belirliyor ve botun gerçek user agent dizesini taşıyan canlı bir istek göndererek HTTP durum kodunu ve yanıt boyutunu kaydediyor.

Çıktı, robots.txt botun izin verdiği halde yanıt 200 olmadığında ya da bot tamamen yasaklandığında işaretlenen satırlardan oluşan bir tablo. Herhangi bir şey işaretlendiğinde süreç 1 durum koduyla çıkıyor, bu da onu bir CI adımı olarak kullanılabilir kılıyor.

Yazar, robots.txt'de her şeye izin veren ama OAI-SearchBot user agent'ını kullanan her isteği reddeden yerel bir sunucuda doğrulama yaptı; katı bir WAF kuralının ürettiği türden bir davranış bu. Dört satırın tümü robots tarafında allow olarak okunmasına rağmen OAI-SearchBot 403 aldı. İki katman arasındaki bu çelişki, aracın ortaya çıkarmak için tasarlandığı şey.

Nedenli bir ayrıştırma tercihi

Beti, Python'ın yerleşik urllib.robotparser modülü yerine protego'ya yaslanıyor. Yazı nedenini açıklıyor: standart kütüphane modülü yönergeleri sırayla değerlendirip ilk eşleşmede duruyor, dolayısıyla erken gelen kapsamlı bir Allow: /, sonraki daha spesifik bir yasağı maskeleyebiliyor. Protego, RFC 9309'nun en uzun eşleşme anlambilimini uyguluyor; yazar bunu gerçek crawler'ların dosyayı yorumlama biçimine daha yakın buluyor.

Sonucun kanıtladığı ve kanıtlamadığı şeyler

Yazı sınırlar hakkında açık sözlü. İstekler kendi IP'nizden geliyor ve birçok CDN gerçek botları IP aralığı ya da ters DNS ile doğruladığından, bu testten gelen bir 200 gerçek crawler'ın da 200 aldığını doğrulamaz; buna karşılık bir 403 anlamlı bir uyarı olarak değerlendiriliyor. Bir 200 ayrıca okunabilir içerik garantisi de değil: makale metni yalnızca JavaScript çalıştıktan sonra görünüyorsa, JavaScript çalıştırmayan bir crawler içeriği tamamen kaçırır ve bayt sayısı normal bir tarayıcı isteğiyle karşılaştırılmalıdır. Kesin kayıt, yazarın da belirttiği gibi, user agent ve durum koduna göre filtrelenmiş sunucu loglarındadır.

İşaretli bir satırın ele alınması

Yazı, işaretli satırlar için önce WAF veya CDN bot yönetimi kurallarında user agent token'ının aranmasını, ardından tüm trafiğe yönelik kuralları gevşetmek yerine istediğiniz crawler'ları doğrulanmış IP aralıkları ya da sağlayıcının doğrulanmış bot kategorisi üzerinden kabul etmenizi öneriyor. Sonrasında betiği yeniden çalıştırın ve gerçek bir crawl gerçekleştiğinde loglardan doğrulayın. Bir detay daha: robots.txt birden fazla adlandırılmış grup içerdiğinde, engellenen her path her grupta tekrarlanmalıdır; çünkü bir crawler yalnızca kendi adıyla eşleşen grubu okur ve joker karakterli grubu yok sayar.

Neden önemli

Birçok yayıncı, AI tarafından üretilen yanıtlarda ve arama ürünlerinde görünür kalabilmek için robots.txt'yi bilinçli olarak AI crawler'lara açıyor. Bu yazı, iznin tek başına hiçbir şey garanti etmediğini gösteriyor: origin'in önündeki zorlama katmanı sessizce onu geçersiz kılabilir. Bot başına kısa bir kontrol, belirsiz bir hata ayıklama pratiğini her deploy'da bir pipeline'ın doğrulayabileceği bir şeye dönüştürüyor ve akılda tutulmaya değer daha geniş bir noktaya değiniyor: robots.txt tavsiye niteliğindedir, WAF ise zorlamayı yapar ve ikisi, hiçbiri hata bildirmeden anlaşamaz hale gelebilir.