robots.txt Hakkında Yanıldığım Nokta

 (evgeniipendragon.com)
8 puan yazan GN⁺ 2025-07-23 | 1 yorum | WhatsApp'ta paylaş
  • Web sitesindeki tüm tarayıcıları engellemeye yönelik robots.txt yapılandırması denemesinden sonra beklenmedik yan etkiler yaşandı
  • LinkedIn gönderi önizlemesi kayboldu ve paylaşımın erişiminde de azalma görüldü
  • Bunun nedeni, robots.txt dosyasının LinkedInBot’un sayfaya erişimini engelleyerek meta etiketlerin toplanmasını önlemesiydi
  • Open Graph Protocol’ün sosyal medyada önizleme oluştururken kritik bir rol oynadığı yeniden fark edildi
  • robots.txt dosyası kısmi izin verecek şekilde güncellenerek sorun çözüldü; gelecekte işlev değişikliklerinde kapsamlı test yapmanın gerekliliği anlaşıldı

Giriş: robots.txt ayarı ve istenmeyen bir sorun deneyimi

  • Son zamanlarda blogda robots.txt yapılandırmasını öğrenirken kendi içeriğim üzerindeki veri hakları konusu üzerine düşündüm
  • Web sitesindeki tüm tarayıcıları engellemek için robots.txt dosyasını değiştirdim
  • Beklenmedik şekilde, web sitesinde istenmeyen sonuçlar ortaya çıktı

LinkedIn gönderi önizlemesi sorunu

  • robots.txt’yi değiştirdikten sonra, blog bağlantımı LinkedIn’de paylaştığımda önizleme (küçük görsel, özet metin) görünmedi
  • Önceden önizleme normal şekilde gösteriliyordu; ancak değişiklikten sonra görünürlük ve etkileşim keskin biçimde düştü
  • İlk başta bunun geçici bir sorun olduğunu düşündüm ama durum 2 haftadan uzun süre devam etti
  • LinkedIn Post Inspector ile yapılan incelemede, robots.txt’nin LinkedInBot’un erişimini kısıtladığı ve bu yüzden meta bilgilerin toplanamadığı ortaya çıktı
  • Sosyal medya platformlarında bağlantı önizlemesi oluşturmak için sayfanın istenmesi ve meta etiketlerin toplanması zorunludur

Open Graph Protocol’e giriş

  • Open Graph Protocol(OGP), Facebook tarafından oluşturulmuş standart bir protokoldür ve web sayfalarını sosyal grafik nesnesi haline getirir
  • OGP, gerekli olan en temel meta etiketleri tanımlar
    • og:title: gönderi başlığı
    • og:type: nesne türü, örneğin video.movie
    • og:image: küçük görselin URL’si
    • og:url: ilgili nesnenin temsilî URL’si
  • Bu protokol sayesinde içerik, farklı sosyal platformlarda etkili biçimde özetlenebilir ve daha çekici şekilde gösterilebilir

robots.txt’de kısmi izinle çözüm

  • Sorunu çözmek için robots.txt dosyasını yalnızca LinkedInBot’a izin verecek şekilde değiştirdim
  • Eğer diğer sosyal platformlarda da önizleme gerekiyorsa, her bot için ayrıca izin vermek gerekir
  • Şu anda kullanılan yapılandırma örneği: 
    User-agent: LinkedInBot
Allow: /

User-agent: *
Disallow: /

Değerlendirme ve çıkarılan dersler

  • Tüm tarayıcıları koşulsuz engellemek, içeriğin görünürlüğü ve sunumu açısından sorunlara yol açabilir
  • Değişikliğin etkisini yeterince test etmeden harekete geçmenin bir hata olduğunu fark ettim
  • Bu deneyim sayesinde Open Graph Protocol, LinkedIn Post Inspector gibi faydalı araçlar ve web standartları hakkında daha fazla şey öğrendim
  • Yeni özellik eklerken veya değişiklik yaparken, etki alanının tamamını yeterince anlamak ve doğrulamak gerekir
  • Başta OGP ile robots.txt engellemesi arasındaki ilişkiyi kuramamıştım, ancak bu deneyimle bunun önemini kavradım

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-23
Hacker News görüşü

  • Eskiden robots.txt'nin ana amacı, arama motorlarında yinelenen içerik cezasını önlemekti. Yönetmesi zor dinamik siteler işletirken, sorgu parametreleri gibi nedenlerle aynı sayfa birden fazla URL üzerinden görünür olur ve arama motorlarından ceza yenirdi. robots.txt, "resmî URL bu, geri kalanını yok say" demenin bir yoluydu. Ayrıca ‘iyi’ crawler'ların sonsuz bağlantı taramalarında kaybolmamasına da yardımcı olurdu. Elbette ‘kötü’ crawler'lar bunu umursamazdı; bu tür botlar IP engelleme gibi yöntemlerle durdurulurdu. User-Agent tabanlı engellemenin pek anlamı yoktu. Kötü niyetli botların uslu uslu kurallara uyacağını düşünmek saflık olur. DNT (Do Not Track) başlığı da benzer şekilde, işi takip etmek olan şirketlere "lütfen beni takip etmeyin" demek gibidir. Ya da kötü niyetli paketlerin başlığa doğrudan "ben kötüyüm" yazmasını bekleyen RFC Evil Bit fikrine benzer

    • Evil Bit önerisinin 1 Nisan şakası RFC'si olduğunu hatırlamak gerekir RFC 3514'e bakın

    • Sonuçta robots.txt'nin sitemap ile benzer bir rolü olup olmadığını da düşündürüyor ama aslında tam tersi. robots.txt, crawler'lara nereye girmemeleri gerektiğini; sitemap ise neyin indekslenmesini istediğinizi söyler. Yinelenen içerik cezasını yönetme gibi özgün amacını bilmiyordum; bu da SEO kontrolüne bakışa yeni bir bağlam ekliyor

    • Asıl nokta şu: Bir davranışı ‘yasak’ ilan ettiğinizde bunun etkisi ancak dürüst olan ya da yanlışlıkla user agent adını düzgün gizlememiş olan bazı aktörlerde görülür. Bunun ötesinde pek işe yaramaz; sonuçta bir ölçüde sembolik bir önlemdir

    • DNT başlığında olduğu gibi, pratikte uygulanamaz görünen girişimler sık sık eleştirilir; ama DNT fikri aslında hukuki mekanizmalarla birlikte uygulanmak üzere düşünülmüştü. Tam teknik engelleme zor olsa da, büyük ölçekte yasa dışı iş yapıldığında bunun içeriden ifşa ile ortaya çıkabileceğini hesaba katmak gerekir

    • Kural koyunca herkesin uyacağına inanan insanlar var; bunun gerçekten kültürel bir farktan kaynaklanan bir inanç olup olmadığını merak ediyorum

  • 2003'te bizzat bir arama motoru yapıp web'i crawl etmiştim. User-Agent içine iletişim e-posta adresimi koyunca gerçekten çok fazla şikâyet e-postası aldım. Crawler'ımı olabildiğince düzgün ve nazik yapmıştım ama insanların Google dışındakileri istemediğini hissettim. Bu tavır, Google'a rakip çıkmasını engellemenin ta kendisi. Mesele yalnızca LinkedIn önizleme sorunu değil; web'in farklı botlar ve kullanıcılar için açık olması gerektiğini de düşünmek lazım. Elbette kötü niyetli crawler'lar engellenmeli ama tüm botlara varsayılan olarak kötü niyetliymiş gibi yaklaşmak doğru değil

    • Botunu iyi niyetle işleten biri olarak beni en çok sinirlendiren deneyim, birinin benim botumun User-Agent'ını kullanarak kötü amaçlı bir botla saldırması ve sonra şikâyetin bana gelmesiydi

    • Herkes kendi botunu korumak isteyebilir ama gerçekte sorun sadece sizin botunuz değil; aynı botun 9000 kopyasının ortalıkta dolaşıp sunucu kaynaklarını aşırı tüketmesi. Bu botlar gerçekte yönlendirme trafiği de getirmiyor

    • Ben de başta her şeyi engelleyen bir yaklaşım benimsedim ama web'in karşılıklı bağlantılı ve karmaşık yapısını fark ettim. Kendi kaynaklarınız üzerinde söz sahibi olmanın önemli olduğunu düşünüyorum. Ama istediğiniz trafiği izinli mi yasaklı mı yapacağınıza karar verirken kendinize ‘neden’ diye sormalı ve her botun ne yaptığını bilmelisiniz. Bu süreç zaman ve emek istiyor. Yapay zeka şirketlerinin veri eğitimi için kontrolsüzce crawl etme pratiği yüzünden robots.txt ile ilk kez ilgilenmeye başladım. İzin verip vermemeyi kendim seçmek istiyorum. Tüm botlar robots.txt'ye uymuyor ama önemli bir kısmı uyuyor. Bunu doğrudan test etmenin bir yolu, gezinme destekli bir modelden belirli bir bağlantıyı scrape etmesini istemek. Temelde bir botun kötü niyetli olup olmadığında daha önemli olan, şirketin veriyi nasıl kullandığı ve benim buna dair ne hissettiğim

    • “Tüm botlar kötü değildir, o yüzden hepsini otomatik engellemeyin” görüşüne karşılık, güven için bir dayanak olmadan erişime izin vermenin riskli bir strateji olduğunu düşünüyorum

    • Bilinmeyen crawler'lardan şüphe duymak doğaldır. Crawler'ların çoğu kötü niyetlidir ve hangisinin iyi hangisinin kötü olduğunu önceden bilemezsiniz; bu yüzden bilinmeyen botları varsayılan olarak geçici biçimde kötü niyetli saymak mantıklıdır

  • Eleştirel olmamaya çalışıyorum ama bu yazıda şaşırtıcı olan şey, yazarın kendi davranışının sonuçlarını sanki çok derin bir farkındalıkla yeni kavramış gibi sunması. Kişisel gelişim hikâyeleri anlamlı olabilir ama bu yazı içgörüden çok cehalet itirafına benziyor. Sonuçta ilgi çekmek için yazılmış gibi hissettiriyor

    • Yazar, sayfa önizleme fetcher'ını crawler olarak görmemiş ve robots.txt ile engellemeyi düşünmemiş. Çok çarpıcı olmasa da en azından kendi açısından yeni öğrendiği bir şey vardı. Gerçek bir insanın yazdığı blog yazılarının web'in ortalama kalitesini artırabileceğini düşünüyorum

    • Google'da görünmediği için buraya (Hacker News) koymuş

    • Bana da gerçekten yeni gelen noktalar oldu. Open Graph Protocol ve Robots Exclusion Protocol hakkında ek şeyler öğrenmeme vesile oldu. Kendim öğrendiğim ya da ilginç bulduğum şeyleri kaydetmeyi ve paylaşmayı severim. Başkaları için de ilgi çekici olabilir diye paylaşmıştım

    • Bu yazının nasıl ön sayfaya çıktığını merak ediyorum. ‘Suyu kapatırsan iyiler uzak durur, kötüler görmezden gelir’ gibi çok bariz bir fikri fazla uzatarak anlatmış gibi. Sonuçta robots.txt, kibar bir ‘lütfen yapmayın’dır; güvenlik duvarı değil, bu açık

  • robots.txt'nin sorunu, sonuçta crawler'ın amacına değil crawler'ın ‘kimliğine’ göre filtreleme yapması. Yazar da yapay zeka toplamasını engellemek için tüm botları engelledi ama sonra OpenGraph önizleme crawler'larına (LinkedIn vb.) yeniden izin verdi. Peki ya Twitter ya da Mastodon gibi başka platformlarda paylaşılırsa ne olacak? Tüm sosyal medyanın UA'lerini tek tek izinli yapmanız gerekir ve bu da sonunda yalnızca birkaç büyük platforma avantaj sağlayan bir yapı oluşturur. Özünde “yapay zeka eğitimini engelle, ama arama indeksleme, önizleme, arşivleme gibi kullanımlara izin ver” diyebilen bir araca ihtiyaç var. Bunu pratikte uygulatmak için hukuki bir çerçeve de gerekebilir ama o da kolay değil

    • robots.txt'nin temel kullanım amacına dair tartışma hep vardı. Bence başlangıçta da (ve hâlâ) esas olarak çoğu crawler için, yani bağlantıları takip ederek yeni şeyler keşfeden sistemler için tasarlandı. Arama motorları bunun tipik örneği. Ama kullanıcının belirli bir URL'yi doğrudan istemesi durumunda (ör. tarayıcı, iCal aboneliği vb.) robots.txt'ye uyma zorunluluğu olmamalı. Nitekim Google Calendar gibi servislerin robots.txt engeli yüzünden abone olamaması oldu ama bunun hatalı davranış olduğunu düşünüyorum. URL önizlemesi açısından, kullanıcı tek bir bağlantıyı istiyorsa bu crawl etmekten çok belirli bir isteğe benzer. Ama uzun bir mesajda çok sayıda bağlantı varsa, bu da bir bakıma crawl etmeye yaklaşır. Sonuç olarak sosyal medyanın URL önizleme özelliğinin robots.txt'ye uyup uymaması gerektiği hâlâ belirsiz geliyor

    • Common Crawl gibi veriler hem arama motorlarında hem yapay zeka eğitimi gibi alanlarda yeniden kullanılabilir. Kullanım amacını ayırmak kolay değil

    • Bilgiyi in-band yerine out-of-band ayırarak çözebilirsiniz. Open Graph metadata'sını ayrı bir yol/başlık üzerinden verirseniz, o yolu (işe yaramayan veri) izinli bırakıp asıl içerik gövdesini güçlü biçimde reddedebilirsiniz. Hukuki çerçeve mutlaka şart değil

    • İşleve/amaca göre sınıflandırıp izin verip engelleyebilen bir standart oluşturma fikri hoşuma gidiyor. Ama işlev doğrulama ve spoofing'i önleme kritik mesele; sonuçta hukuki tarafla da iç içe. Gerçekte sosyal medya önizlemeleri gibi çeşitli platformlara tekrar izin vermek gerekecek gibi görünüyor ve neye izin verip neyi engelleyeceğini dikkatle seçme sürecinde çok şey öğreniyorum. Böyle farklı görüşler duymak çok faydalı oluyor

  • OP'ye, 1) Yalnızca LinkedIn'i düşünmüş olabilirsiniz ama gerçekte bağlantılarınız Facebook, Bluesky gibi başka sosyal medya platformlarında da paylaşılabilir. Facebook'un ai.robots.txt'sinde bile FB önizleme crawler'larının da birlikte engellenebildiğini gördüm (ai.robots.txt örneği).

  1. Google sıralaması ve robots.txt engeli konusunda, robots.txt ile arama görünürlüğünü kesseniz bile dolaylı bağlantılar gibi başka etkenler olsa da, doğrudan crawl izni vermek Naver/Google SEO açısından temelde çok daha faydalıdır. Engellerseniz arama sonuçlarında küçük resim/açıklama gibi öğeler görünmez ve kalite düşer. Arama motoru trafiği önemliyse robots.txt ile tam engeli iyi düşünmek gerekir

  • Geri bildirim için teşekkürler! 1) Ben de yalnızca LinkedIn ve HN'i düşünmüştüm. Başkalarının blog bağlantımı çeşitli platformlarda paylaşabileceği aklıma gelmemişti. Farklı platformlara erişim iznini yeniden değerlendirmem gerekebilir. 2) Arama motoru eğilimlerinin yapay zeka özetlerine kaydığını gördükçe, gelecekte sitenin kendisine gelen organik trafiğin azalacağını düşünüyorum. Bu yüzden Google arama trafiğinin azalması bana çok da üzücü gelmiyor. İleride fikrim değişebilir ama şu an için HN ve sosyal paylaşımlarla oluşan ağızdan ağıza etkinin blogum için daha anlamlı trafik üreteceğini düşünüyorum. Verdiğim kararın dönüp beni vurup vurmayacağını biraz daha araştıracağım. Farklı görüşler karar vermeme çok yardımcı oluyor

  • robots.txt ile ‘crawl etme’ ve ‘indeksleme’yi karıştırmaktan doğan başka bir yan etki daha var.
    Yeni sayfaların Google indeksine hiç girmemesini sağlamak istiyorsanız robots.txt engeli işe yarar.
    Ama zaten indekslenmiş bir sayfayı kaldırmak için onu sadece robots.txt'ye eklemek hatadır. Google crawl edemediği için metadata olmadan arama sonuçlarında göstermeye devam eder; noindex meta etiketini de göremez, bu yüzden sayfa uzun süre sonuçlarda kalabilir. Google zamanla sayfayı tamamen kaldırır ama bu süreç çok sinir bozucu olabilir

    • Google, robots.txt tarafından engellenen URL'leri harici bağlantılar vb. yollarla keşfedebilir ve bu durumda crawl edemese bile indeks kaydı sonuçlarda kalabilir (uyarıya bakın: Google resmî dokümanı). Arama sonuçlarından tamamen kaldırmak için kod içine mutlaka noindex etiketi koymak gerekir; ancak robots.txt ile engellerseniz Google bu etiketi de okuyamaz, buna dikkat etmek gerekir

    • Benim durumumda Google'ın indeksten kaldırması şart değil. İndeksleme umurumda değil; crawl etme ve scraping ile ilgileniyorum. Terimleri karıştırdığımı kabul ediyorum

  • Bu yazı, asıl söyleyeceğini bir iki cümlede anlatabilecekken gereğinden fazla uzatmış gibi duruyor. Biraz okul yıllarındaki sayfa doldurma hissi veriyor

    • Sorun tek paragrafta anlatılabilirdi. Yazımın amacı deneyimimi, problemi, araştırmayı ve çözüme giden yolculuğu kayda geçirmekti. Teknik olmayan okurların da takip edebilmesi için olabildiğince ayrıntılı yazdım

  • robots.txt'nin temel sınırlaması, sorunun aslında robots.txt'ye uyan botlar değil, uymayanlar olması. robots.txt bugün trafikte sorun yaratan botların çoğunu kontrol edemiyor. Sunucuya en çok zarar veren kötü niyetli botlar robots.txt'yi hiç umursamıyor

    • Bu tür botları yakalamak için ‘honeypot’ faydalı olabilir. robots.txt içinde /honeypot yolunu açıkça yasaklayın ve index.html içine display:none uygulanmış <a href="/honeypot">ban me</a> bağlantısı ekleyin. Bu yola gelen IP'leri anında engelleyebilirsiniz

    • Neden eksilendiğimi anlamıyorum. OpenAI, Anthropic gibi büyük şirketlerin robots.txt'ye ne kadar iyi uyduğuna güvenmek için bir dayanak yok. Bu şirketler trafiği konut tipi ISP IP'leri üzerinden geçirerek tespiti zorlaştırıyor ve ‘üçüncü taraf reklamlar’ yoluyla doğrudan izlemeyi atlatıp sorumluluğu dağıtıyor

  • Beni en çok şaşırtan şey, robots.txt ve meta robots etiketini birlikte yorumlayıp çakışma durumunda hangi izin/engel önceliğinin uygulanacağını düzgünce ele alan parser kütüphanelerinin neredeyse hiç olmaması. Google'ın resmî referans parser'ı C++11 tabanlı, yani istisnai bir durum; popüler Python veya JS kütüphanelerinde geliştiricinin bunları ayrıca ele alması gerekiyor. Üstelik meta robots gibi bilgiler robots.txt dosyasında bile değil, index.html içinde saklı. Bot geliştiricisi etik davranmak istese bile uygulama zorluğu yüzünden iş zorlaşıyor

    • Python standart kütüphanesinde urllib.robotparser var (resmî doküman). Öte yandan rel=nofollow robots.txt'den tamamen farklı bir amaca hizmet eder. Bu öznitelik, arama motoruna ilgili bağlantıya ‘güven’ vermemesini söyler; “bu bağlantıyı takip etme” anlamına gelmez(ayrıntılı açıklama). Asıl amacı, spam topluluklarda insanların kendi sitelerine gelişigüzel bağlantı bırakmasını engellemekti

    • Kaynakları sınırlı olan ‘iyi niyetli’ bot geliştiricileri sunucuları gelişigüzel bombalamadıkları için, kütüphane eksikliği nedeniyle ciddi sıkıntı yaşamaları aslında çok olası değil

    • İyi niyetle düzgün bir bot yapmak istiyorsanız, parser kütüphanesini doğrudan başka dillere açık kaynak olarak aktarıp yayımlamak da gayet mümkün. Zor bir şey değil

  • İlginçtir, Apple bu soruna farklı yaklaşıyor. iMessage'da bağlantı paylaşırken önizlemeyi doğrudan ‘gönderen taraf’ istemcisi çekip oluşturuyor. LinkedIn gibi servislerin bağlantı verisini sunucu tarafında çekmesinin nedenleri olabilir (spam, phishing önleme vb.) ama yine de epey farklı bir yaklaşım

    • Ben de mesaj içindeki bağlantıyı aldıktan sonra istemcinin doğrudan önizleme üretmesinin mantıklı olduğunu düşünmüştüm. Hatta birinin buna değinmesini de bekliyordum. Yine de sunucunun doğrudan scrape etmesinin çeşitli nedenlerini anlıyorum. 1) İleride tüm sayfaları çekip kullanabilme ihtimali; 2) sayfa değiştiğinde, 404 olduğunda ya da istemci veritabanı kaybolduğunda sunucunun önceden çekilmiş önizleme bilgisini sağlayabilmesi; 3) istemcinin önizlemeyi üretmesine gerek kalmadan mesajla birlikte hızlıca gösterilebilmesi. Sonuçta iMessage gibi ‘gönderenin’ önizlemeyi üretmesi modelinde bunlardan yalnızca ‘1’ ve kısmen ‘2’ kalıyor; sunucunun yeniden denemeyi sürdürmesi dayanıklılık açısından daha iyi bir tercih olabilir