robots.txt dosyası crawl budget tarafında tek bir iş yapıyor: var olmaya devam edecek ama taranmasına gerek olmayan URL'leri crawling dışında tutuyor. Bunun dışındaki işlerde, yani kopya yönetiminde, kalıcı silmede ve indeksten çıkarmada, dosyanın kendi maliyeti devreye giriyor ve çoğu zaman sorunu çözmek yerine erteliyor.
Sahada bu dosyanın bir kazanç aracı gibi kullanıldığını görüyoruz. Bir yol listesi çıkarılıyor, hepsi Disallow satırına yazılıyor ve tarama isteklerinin düşmesi başarı sayılıyor. Oysa engellenen URL kuyruktan çıkmıyor, Google engellediği sayfanın içindeki sinyalleri okuyamıyor ve dosyanın mekaniği çoğu sitede sessizce yanlış çalışıyor.
Google'ın Araç Sırasında robots.txt İkinci Sırada
Google'ın crawl budget dokümanı tarama talebini belirleyen sinyallerden yalnızca birini site sahibinin kontrolünde sayıyor: Google'ın sitede bildiği URL kümesi. Popülerliği ve içeriğin bayatlamasını siz ayarlayamazsınız, envanteri ayarlayabilirsiniz. Crawl budget yönetimi pratikte bu kümeyi yönetme işi.
Google'ın Saydığı Altı Araç
Aynı doküman araçları belli bir sırayla veriyor ve sıra tesadüf değil:
- Kopya içeriği konsolide edin, benzersiz URL yerine benzersiz içeriğe odaklanın.
- Konsolide edilemeyen önemsiz sayfaları robots.txt ile crawling dışında tutun.
- Kalıcı olarak silinen sayfalarda 404 veya 410 döndürün.
- Soft 404'leri temizleyin, çünkü taranmaya devam ediyorlar.
- Sitemap'i güncel tutun ve değişen içerikte lastmod kullanın.
- Uzun redirect zincirlerinden kaçının.
Konsolidasyon engellemeden önce geliyor, çünkü engelleme Google'ın konsolidasyon sinyallerini görmesini de kapatıyor. Engelleme burada bir başlangıç adımı olarak değil, konsolide edilemeyen sayfalar için ikinci tercih olarak duruyor.
Engellemenin Meşru Olduğu Yapılar
Engelin gerçekten doğru araç olduğu yer dar ama net: kullanıcı için anlamlı, crawler için neredeyse sonsuz sayıda URL üreten yapılar. Faceted navigation bunun tipik örneği, çünkü fiyat, renk ve beden filtreleri birleştiğinde kombinasyon sayısı çarpımsal büyüyor. Takvim şablonları ve kötü kurgulanmış pagination da aynı sınıfa giriyor.
Bu URL'lerin ortak yanı, silinmemeleri ve silinemeyecek olmaları. Kullanıcı onları kullanmaya devam ediyor, yani 404 döndürmek yanlış. Aynı zamanda konsolide edilemeyecek kadar çoklar. Geriye robots.txt kalıyor ve burada doğru araç gerçekten o.
robots.txt Disallow Satırı Neyi Durdurur
Bir Disallow satırı crawling'i durduruyor ve indexing'i durdurmuyor. Üç direktifin işi ayrı, karıştırıldıklarında da yanlış araç seçiliyor. Taramak ile indekslemenin iki ayrı karar olduğunu ayrı bir yazıda ele almıştık; direktif seçimi o ayrımın doğrudan sonucu.
| Direktif | Crawling'i durdurur mu | Indexing'i durdurur mu |
|---|---|---|
| robots.txt disallow | Evet | Hayır, engelli URL indekslenebilir |
| noindex | Hayır | Evet |
| 404 / 410 | Zamanla, güçlü sinyal | Evet |
Tablonun ikinci satırı sık yapılan bir hatayı kapatıyor. noindex direktifi sayfanın HTML'inde ya da HTTP başlığında duruyor, Googlebot onu okuyabilmek için sayfayı çekmek zorunda. Yani noindex işaretli her sayfa tarama isteği tüketmeye devam ediyor ve crawl budget tarafında hiçbir tasarruf sağlamıyor.
Engellenen URL Crawl Queue'da Kalmaya Devam Eder
Kuyruk davranışı sezgiye aykırı çalışıyor. Google'ın crawl budget dokümanına göre robots.txt ile engellenen URL'ler crawl queue'da çok daha uzun süre kalıyor ve engel kaldırıldığı anda yeniden taranıyor.
Aynı dokümana göre 404 ise Google'ın bildiği bir URL'yi unutturmuyor ama o URL'yi yeniden taramamak için güçlü bir sinyal taşıyor. Kalıcı olarak sildiğiniz bir sayfayı robots.txt'e yazmak, doğru durum kodunu döndürmekten daha zayıf bir crawl budget kararı oluyor.
Indexed, though blocked by robots.txt Uyarısı
Search Console'un Page indexing raporundaki bu satır hata listesinde durmuyor, uyarı olarak duruyor ve teşhiste bu ayrım işe yarıyor. Dokümanın tanımı üç şeyi aynı anda söylüyor: Google engele uyuyor ve URL'yi istemiyor, URL yine de indekslenebiliyor, aramada görünen kayıt ise zayıf kalıyor. Google engellenen sayfaya link veren sayfadan aldığı bilgiyle indeksliyor ve snippet muhtemelen çok sınırlı oluyor.
Dokümanın verdiği çıkış yolu ikiye ayrılıyor ve seçim niyete bağlı. Sayfa gerçekten aramada olmayacaksa engeli kaldırıp noindex koyuyorsunuz. Sayfa aramada olacaksa engeli kaldırıyorsunuz. İki yolun da ilk adımı aynı: engeli kaldırmak.
Engellemenin Görünmeyen Maliyeti
Engellenen bir URL'de Google yalnızca içeriği kaybetmiyor, o sayfanın taşıdığı bütün sinyalleri kaybediyor. robots.txt engelleme kararı verilirken genelde tek bir kazanç hesaplanıyor, taranmayan istek sayısı. Aynı satırdan çıkan üç kayıp ise hiçbir raporda ayrı bir satır olarak görünmüyor.
Canonical Etiketi Okunamaz
Google'ın canonicalization dokümanı kendi "best practices" listesinde robots.txt'i canonicalization için kullanmamanızı söylüyor. Maddenin gerekçesi mekanizmayı da veriyor, çünkü Google robots.txt ile engellenen URL'leri içerikleri olmadan yine indeksleyebiliyor. Engellenen URL indeksten çıkmıyor, yalnızca içeriksiz indeksleniyor.
Parametreli kopyaları canonical ile ana sürüme bağlamak konsolidasyon sağlıyor. Aynı URL'leri robots.txt ile engellemek konsolidasyonu imkânsız hale getiriyor, çünkü Google sayfayı çekemediği için içindeki canonical etiketini de göremiyor. Kopyayı engellemek kopya problemini çözmüyor, donduruyor.
Gömülü Varlıklar ve Render Kaynakları
Engelin kapsamı yazdığınız yoldan geniş. Google'ın robots.txt giriş dokümanı engelli bir sayfaya gömülü görsellerin, videoların ve PDF'lerin de crawling dışında kaldığını söylüyor. Tek istisna, aynı varlığa taranabilir başka bir sayfadan referans verilmesi. Görsel aramadan trafik alan bir sitede bu, HTML tarafında hiç görünmeyen ikinci bir kayıp.
Aynı mantık rendering tarafında da çalışıyor. Google'ın JavaScript dokümanı engellenen dosyalardaki JavaScript'in çalıştırılmadığını yazıyor, yani sayfa taranabilir olsa bile ihtiyaç duyduğu script engelliyse render çıktısı boş kalıyor. Framework'ün script klasörünü engellemenin somut bedeli bu; Google'ın render sürecini ayrı bir yazıda adım adım anlatmıştık.
Google'ın kendi spesifikasyon dokümanının açılış örneği de aynı yerden yazılmış. Örnek, .css ve .js dosyalarının durduğu klasörü bütün crawler'lara kapatıyor, Googlebot'a Allow ile açıyor ve gerekçeyi yorum satırına koyuyor: "Google needs them for rendering."
Dosyayı Yazarken Üç Sessiz Hata
Buraya kadarki her şey kararla ilgiliydi. Karar doğru verildiğinde bile dosyanın kendisi beklediğiniz gibi okunmayabiliyor, çünkü Google'ın robots.txt spesifikasyon dokümanı yaygın varsayımların üçünü birden çürütüyor. Üçünün ortak yanı sessiz başarısızlık: dosya geçerli, kural çalışıyor, kaybedilen şey görünmüyor.
Googlebot Tek Bir User-agent Grubunu Okur
Doküman bu noktada açık konuşuyor ve bir crawler için yalnızca tek bir grubun geçerli olduğunu, diğer grupların yok sayıldığını yazıyor. Devamı ayrımı kapatıyor, çünkü user-agent'a özel gruplar ile global * grubu birleştirilmiyor. Googlebot için ayrı bir grup yazdıysanız, Googlebot yalnızca o grubu okuyor.
Buradan çıkan tuzak yaygın. Şu yapıyı yazdığınızda /_next/ Googlebot için engelli kalmıyor, çünkü Googlebot'un grubunda o satır yok:
User-agent: *
Disallow: /_next/
Disallow: /api/
User-agent: Googlebot
Disallow: /admin/
Disallow: /api/Bingbot, Applebot ve her AI crawler'ı ise * grubunu okuyor ve /_next/ onlar için engelli kalıyor. Dosyayı yazan kişinin niyeti ile sonucu taban tabana zıt: kural "herkese kapat, Googlebot'a aç" gibi okunuyor, fiilen "Googlebot'a aç, diğer herkese kapat" oluyor. Google tarafında zarar görünmediği için hata aylarca fark edilmiyor.
Rule Precedence Yol Uzunluğuna Bakar
İkinci yaygın varsayım, dosyanın yukarıdan aşağı okunduğu ve son eşleşen kuralın kazandığı. Google çakışan kurallar arasında dosyadaki sıraya bakmıyor. Spesifikasyona göre crawler'lar yol uzunluğuna göre en spesifik kuralı uyguluyor, wildcard içerenler dahil kurallar çakıştığında ise Google en az kısıtlayıcı olanı seçiyor.
Pratikteki sonucu rahatlatıcı. Bir dizini kapatıp altındaki bir alt dizini açmak için kuralları belirli bir sıraya dizmeniz gerekmiyor, çünkü Disallow: /_next/ yanına Allow: /_next/static/ yazmak yetiyor. İkinci yolun karakter sayısı daha uzun olduğu için o kazanıyor. Aynı mekanizma ters yönde de çalışıyor: geniş bir Disallow yazıp istisnasını unutmak, hiçbir uyarı üretmeyen bir hata.
Path Matching'de Regex Yok
Google yol değerlerinde yalnızca iki wildcard destekliyor: * sıfır veya daha fazla karakter, $ ise URL'in sonu. Karakter sınıfı, aralık ve tekrar operatörü gibi düzenli ifade yapıları desteklenen sözdizimi arasında yok. Ayrıştırıcı onları hata olarak işaretlemiyor, yolun bir parçası sayıp harfi harfine eşleştiriyor.
Somut hâli, derin sayfalamayı kapatmak için sık yazılan şu kural:
Disallow: /*?page=[2-9]*Yazan kişi ikiden dokuza kadar sayfaların engellendiğini sanıyor. Kuralın fiilen aradığı şey, yolunda birebir ?page=[2-9] dizisini taşıyan bir URL. Böyle bir URL üretilmediği için satır hiçbir şeyi engellemiyor ve ?page=2 taranmaya devam ediyor. Aynı yolu gerçekten kapatmak Disallow: /*?page= ile oluyor; birinci sayfayı ayırmak istiyorsanız o ayrımı robots.txt yapamıyor.
crawl-delay Satırı Googlebot İçin Yok Sayılır
Google'ın ayrıştırıcısı dört alan tanıyor: user-agent, allow, disallow ve sitemap. Doküman crawl-delay dahil diğer alanların desteklenmediğini açıkça yazıyor. crawl-delay: 10 satırı Googlebot'u yavaşlatmıyor, crawl-delay: 0 satırı da hızlandırmıyor.
Satır tamamen anlamsız sayılmaz, çünkü AhrefsBot ve SemrushBot gibi crawler'lar onu okuyor. Yalnızca Google için anlamsız ve bu ayrım yazılmadığında dosyayı okuyan kişi Googlebot davranışını yanlış modelliyor. Yok sayılan alanın ikinci bir yan etkisi daha tehlikeli. Ayrıştırıcı tanımadığı satırı grup ayırıcı saymıyor, yani araya giren bir satır iki user-agent bloğunu tek gruba çevirebiliyor.
robots.txt Crawl Budget İçin Ne Zaman Doğru Araç
Doğru araç olduğu durum dar ve tarif edilebilir. Engelleme kararını vermeden önce size iki soru öneriyoruz, çünkü ikisi de karardan sonra sorulduğunda geri alınması zor bir kayıp üretiyor.
Karardan Önce Sorulacak İki Soru
Birinci soru URL'nin geleceğiyle ilgili: bu adres var olmaya devam edecek mi? Kalıcı olarak silindiyse doğru araç 404 ya da 410, çünkü engelleme o URL'yi kuyrukta tutuyor. Aynı içeriğin kopyasıysa doğru araç canonical, çünkü engelleme Google'ın kopyayı ana sürüme bağlamasını imkânsız hale getiriyor.
İkinci soru kapsamla ilgili: bu yolu kapatınca hangi varlıkları kaybederiz? Kapanan yolun altında kalan görseller, PDF'ler ve script dosyaları da crawling dışında kalıyor. Birinci soru genelde soruluyor, ikincisi genelde sorulmuyor ve fark size iki üç ay sonra görsel aramada ya da render çıktısında geri dönüyor.
Dosyanın Kendisi Erişilebilir Kalmalı
Son kontrol dosyanın kendi yanıtıyla ilgili ve iki durum sürekli karıştırılıyor. Search Console'un Crawl Stats dokümanına göre robots.txt'in bulunamaması, yani 404 dönmesi, iyi bir yanıt: site robots.txt kullanmıyor sayılıyor ve her şey taranabilir kabul ediliyor. Boş dosya da geçerli bir yanıt.
Erişilememesi ise tam tersi. Google dosyayı okuyamadığında hangi kuralın geçerli olduğunu bilemiyor ve muhafazakâr davranıyor, yani taramayı yavaşlatıyor. Dosya bir gün boyunca erişilemez kalırsa, kabul edilebilir bir yanıt alana kadar taramayı bir süre durduruyor. Sizin tarafınızda bot koruma katmanının Googlebot'a farklı bir robots.txt ya da challenge sayfası döndürmesi de aynı maddeye giriyor.
Sıkça Sorulan Sorular
robots.txt crawl budget kazandırır mı?
Dar bir durumda kazandırır: var olmaya devam edecek ama taranmasına gerek olmayan URL'ler crawling dışında kalır. Google'ın kendi araç sırasında engelleme ikinci sırada duruyor ve ilk sıradaki iş kopyaları konsolide etmek.
robots.txt ile engellenen sayfa indekslenir mi?
Evet, indekslenebilir. Google engele uyup sayfayı istemiyor, ama ona link veren sayfalardan gelen bilgiyle URL'yi indeksleyebiliyor. Search Console bunu "Indexed, though blocked by robots.txt" uyarısıyla gösteriyor ve aramada görünen snippet çok sınırlı kalıyor.
robots.txt mi noindex mi kullanmalı?
İkisi ayrı iş yapıyor. noindex indekslemeyi durduruyor ve taramayı durdurmuyor, çünkü Googlebot direktifi görebilmek için sayfayı çekmek zorunda. Sayfa aramada hiç görünmeyecekse noindex, taranmasına gerek yoksa robots.txt doğru araç.
crawl-delay Google'da çalışır mı?
Çalışmıyor. Google'ın ayrıştırıcısı yalnızca user-agent, allow, disallow ve sitemap alanlarını tanıyor ve crawl-delay dahil diğer alanları yok sayıyor. AhrefsBot ve SemrushBot gibi crawler'lar satırı okuyor, yani dosyadan çıkarmak da gerekmiyor.
Kaynaklar ve Referanslar
- Google Search Central, "Crawl Budget Management | Google Crawling Infrastructure", https://developers.google.com/crawling/docs/crawl-budget (erişim 11 Ağustos 2026)
- Google Search Central, "How Google interprets the robots.txt specification", https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt (erişim 9 Eylül 2026)
- Google Search Central, "Introduction to robots.txt", https://developers.google.com/search/docs/crawling-indexing/robots/intro (erişim 9 Eylül 2026)
- Google Search Central, "How to specify a canonical URL with rel='canonical' and other methods", https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls (erişim 9 Eylül 2026)
- Google Search Central, "Understand the JavaScript SEO basics", https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics (son güncelleme 4 Mart 2026; erişim 9 Eylül 2026)
- Google Search Console Yardım, "Page indexing report", https://support.google.com/webmasters/answer/7440203 (erişim 9 Eylül 2026)
- Google Search Console Yardım, "Crawl Stats report", https://support.google.com/webmasters/answer/9679690 (erişim 21 Ağustos 2026)