Google bir sayfayı arama sonuçlarında gösterebilmek için önce onu taramak, yani Googlebot ile sunucunuzdan çekmek zorunda ve bunu hiçbir sitede sınırsız yapmıyor. Bir sitede tarayabildiği ve taramak istediği URL'lerin toplamına crawl budget diyor. Tarayabildiği kısmı sunucunuzun kaldırabildiği yük sınırlıyor; Google buna 2017'de crawl rate limit diyordu, bugünkü dokümanında adı crawl capacity limit. Taramak istediği kısmın adı crawl demand ve dokümana göre her site aynı temkinli (conservative) kapasiteyle başlıyor, bu kapasite de ancak talep varsa zamanla yükseliyor.
Sektörde yaygın tanım ise crawl budget'ı belirli sürede taranan sayfa sayısına indiriyor, yani iki sınırın işleyişi yerine sonucunu ölçüyor. Google'ın Temmuz 2026'da güncellediği dokümanı aktaran üçüncü taraf yazılardan biri de iki sınırı "hangisi düşükse bütçe odur" formülüyle anlatıyor. Oysa dokümanda böyle bir formül yok ve bu kısaltma, kapasitenin talebe bağlı olarak yükseldiğini gözden kaçırıyor.
Bu ayrımın sahada ne değiştirdiğini görmek için yönettiğimiz ve rapor hazırladığımız altı sitenin, kendi sitemiz dahil, Search Console tarama verisine baktık. Altyapısını taşıdığımız bir sitede ortalama yanıt süresi 2.339 ms'den 416 ms'ye inince Google günde yaklaşık 3,6 kat daha fazla istek gönderdi. Yaklaşık %20 hızlanan başka bir sitede ise günlük tarama yerinde saydı çünkü orada sınırlayan taraf büyük olasılıkla talepti. Bu yüzden emeğinizi sunucuya mı içeriğe mi vereceğinize karar vermeden önce iki sınırdan hangisinin sizi bağladığını ayırmanızı öneriyoruz.
İki Sınır İki Ayrı Soruya Cevap Veriyor: Tarayabilir mi, İstiyor mu
Google'ın crawl budget dokümanı bir sitenin crawl budget'ını iki parçadan kuruyor ve tanımın özü 2017'den beri aynı: Google'ın o sitede tarayabildiği ve taramak istediği URL'ler. İlk parça sunucunun ne kadar kaldırabildiğini, ikincisi Google'ın o siteye ne kadar ilgi duyduğunu ölçüyor. Hesap hostname başına yapılıyor, bu yüzden aynı alan adının iki alt alanı Google için iki ayrı site ve iki ayrı bütçe demek.
Crawl Rate Limit Bugün Crawl Capacity Limit Adını Taşıyor
Terimi 2017'de tanıtan Google yazısı crawl rate limit'i Googlebot'un aynı anda açabildiği paralel bağlantı sayısı ve iki istek arasında beklediği süre olarak tanımlıyordu. Güncel doküman aynı mekanizmaya crawl capacity limit diyor ve Search Console'daki adını da veriyor: hostload. Ölçtüğü şey sunucunuzun Google için bağlantı açık tuttuğu toplam süre. Crawl rate limit'i "belirli sürede taranan en fazla sayfa sayısı" diye okumak bu yüzden yanıltıcı, çünkü tavanın birimi zaman ve sayfa sayısı yalnızca sonucu gösteriyor.
Limit crawl health ile iki yönde hareket ediyor. Sunucu tutarlı yanıt veriyor ve Time to First Byte (TTFB) sabit kalıyor ya da iyileşiyorsa limit yükseliyor. Yanıtlar uzarsa, 5xx hataları ya da 429 gelirse düşüyor. Doküman ikinci bir tavanı da yazıyor: Google'ın kendi kaynakları da sonlu.
Kapasite Bütün Google Crawler'larında Ortak, Crawl Demand Her Crawler'a Ayrı
Talep tarafı crawler başına ayrışıyor. Google'ın örneğinde AdsBot dinamik reklam hedefleri çalışan bir sitede, Google Shopping ise merchant feed'inizdeki ürünlerde daha yüksek talep gösteriyor. 22 Temmuz 2026 güncellemesiyle dokümana eklenen bir not bunun karşı yarısını söylüyor. Talep crawler'a göre değişse de kapasite bütün crawler'lar arasında ortak, yani bir crawler'ın yüksek talebi diğerlerine kalan kapasiteyi azaltabiliyor.
Googlebot için talep sitenin büyüklüğüne, güncelleme sıklığına, sayfa kalitesine ve diğer sitelere göre alakasına bağlı. Sizin etkileyebildiğiniz küme ise daha dar: algılanan envanter (perceived inventory), popülerlik ve bayatlama (staleness). Google algılanan envanteri, yani sitenizde bildiği URL kümesini, en çok kontrol edebileceğiniz faktör olarak işaretliyor.
Tavanı Talep Yükseltiyor
Google'ın dokümanı iki sınırı birbirine bağlıyor ve bu bağ, sitenizde hangi tarafa emek vereceğinizi doğrudan belirliyor.
Her Site Aynı Conservative Varsayılanla Başlıyor
Dokümana göre her site aynı, conservative bir crawl capacity limit ile başlıyor. Limitin nasıl yükseldiğini anlatan cümle koşulunu da taşıyor: taranacak daha fazla şey için talep varsa ve site sağlıklı kalırsa Google'ın sistemleri limiti zamanla kendisi ayarlıyor. Bu iki koşulu birlikte okuduğumuzda sağlıklı bir sunucu tavanın yükselmesine izin veriyor, yükselmeyi tetikleyen ise talep oluyor.
Aynı dokümanın özet cümlesi ters yönü kapatıyor: kapasite limitine varılmasa bile talep düşükse Google sitenizi daha az tarıyor. Tarayabilmek ile istemek aynı anda gerçekleşmedikçe tarama hacmi artmıyor.
Kapasiteye Varılmayan Sitede Boşalan Zaman Başka Sayfaya Kaymıyor
Bağın en pratik sonucu robots.txt tarafında ortaya çıkıyor. Dokümanın bir uyarı kutusu, bütçeyi geçici olarak başka sayfalara aktarmak için robots.txt kullanmamanızı söylüyor. Gerekçesi açık: Google boşalan bütçeyi ancak siteniz zaten kapasite limitine dayanıyorsa başka sayfalara kaydırıyor. Tavana varmayan bir sitede bir URL grubunu engellemek o zamanı önemli sayfalarınıza aktarmıyor ve zaman kullanılmadan kalıyor.
robots.txt'nin crawl budget tarafında gerçekten hangi işe yaradığını robots.txt ile crawl budget yönetimi yazımızda ayrıca inceledik. Aynı mantık robots.txt'nin ötesinde de geçerli: sınırlayan taraf talep olduğunda kapasiteyi rahatlatan hiçbir hamle taramayı kendiliğinden artırmıyor.
Site Sahibinin Elindeki Kontroller Yalnızca Aşağı Yönde Çalışıyor
Googlebot tarama hızı üzerinde site sahibinin elindeki her kontrol yalnızca yavaşlatmaya yarıyor. Search Console'daki Crawl Rate Limiter aracı on yıldan uzun süre açık kaldı ve 8 Ocak 2024'te kaldırıldı. 2017 yazısı bu ayarla yalnızca taramayı azaltabildiğinizi, daha yüksek bir limitin taramayı kendiliğinden artırmadığını zaten yazıyordu.
robots.txt'deki standart dışı crawl-delay kuralını Googlebot hiç işlemiyor. Satır okunmadığı için crawl-delay: 0 yazmak da Googlebot'u hızlandırmıyor.
Acil durumda en hızlı fren sunucu yanıtları. Google'ın tarama hızını düşürme rehberi, taramayı birkaç saat ya da 1–2 gün azaltmak için 200 yerine 500, 503 ya da 429 döndürmenizi öneriyor. Yavaşlama yalnızca hata dönen URL'lerde kalmıyor, bütün hostname'e yayılıyor. Crawl Stats yardım sayfasına göre bu kodları iki üç günden uzun döndürmek, Google'a sitenizi uzun vadede daha seyrek taramasını söyleyebiliyor. Hata döndüremeyen altyapılar için bir bildirim formu var, ama rehber tarama hızında artış talep edemeyeceğinizi açıkça yazıyor.
Yukarı yönde Google'ın saydığı iki yol kalıyor. Site gerçekten sunucu kapasitesi yüzünden taranamıyorsa sunucu kaynağı eklemek, her durumda da hedeflediğiniz Google ürünü için içerik kalitesini yükseltmek. Google Search için bu kalite popülerliği, kullanıcı değerini, içeriğin benzersizliğini ve sunum kapasitesini kapsıyor. Google'dan daha fazla tarama istemek bu yüzden baştan kapalı bir yol.
Altı Sitenin Verisinde İki Sınır da Görünüyor
Dokümanın söylediğini kendi verimizde görmek için yönettiğimiz ve rapor hazırladığımız altı sitenin, kendi sitemiz dahil, Search Console Crawl Stats dışa aktarımlarına baktık. Siteleri A'dan F'ye harflerle anıyoruz: A ve C rapor hazırladığımız, B, D ve F yönettiğimiz siteler, E ise kendi sitemiz. Dönem her site için 88–89 gün ve Mayıs sonu ile Eylül 2026 arasına düşüyor. Boyutlarını yuvarlanmış günlük medyan istek sayısıyla veriyoruz: A 13.395, B 185, C 102, D 31, E 6, F 272.
Altyapısını Taşıdığımız Sitede Tarama 3,6 Katına Çıktı
Yönettiğimiz Site F'nin altyapısını 21 Temmuz 2026'da yeni bir sunucu ve platforma taşıdık. Geçişten önceki 26 günde (24 Haziran–19 Temmuz) ortalama yanıt süresi 2.339 ms, günlük ortalama tarama isteği 99'du. Geçişten sonraki 60 günde (22 Temmuz–20 Eylül) yanıt süresi 416 ms'ye indi ve günlük istek ortalaması 356'ya çıktı. Yani site yaklaşık 5,6 kat hızlandı ve Google yaklaşık 3,6 kat daha fazla istek gönderdi.
Geçiş günlerinde istek sayısı 20 Temmuz'da 125, 21 Temmuz'da 232, 22 Temmuz'da 283 oldu; yanıt süresi aynı günlerde 1.685, 717 ve 488 ms'ye indi. Dönemin en yüksek günü 621 istekle 6 Ağustos oldu. Site F'de yanıt süresi ile günlük istek sayısı arasındaki aynı gün korelasyonu −0,75 ve altı sitenin en güçlüsü. Kapasitenin bağladığı bir sitede beklediğimiz tablo bu: sunucunun tavanı yükselince tarama da yükseldi.
Artışın tamamını hıza bağlamıyoruz, çünkü bir altyapı geçişi hızdan fazlasını değiştiriyor. İstek başına indirme boyutu 68 KB'den 133 KB'ye çıktı, dönem boyunca yanıtların %18'i 302, %12'si 404; artışın bir kısmı değişen URL'lerin yeniden çekilmesinden gelebilir. Taramanın %96'sı Refresh, yalnızca %4'ü Discovery olduğu için artışın büyük ölçüde yeni keşfedilen URL'lerden çok yeniden taramadan geldiğini düşünüyoruz. Sunucu logları olmadan bu iki etkiyi tam olarak ayıramıyoruz.
Yaklaşık Yüzde 20 Hızlanan Site Aynı Hacimde Taranmaya Devam Etti
Rapor hazırladığımız Site C'de tablo tersine dönüyor. Sitenin 88 günlük dönemini ikiye böldüğümüzde ilk yarıda günde ortalama yaklaşık 115 istek ve 1.310 ms yanıt süresi görüyoruz. İkinci yarıda ortalama yanıt süresi 1.049 ms'ye indi, yani yaklaşık %20 iyileşti. Günlük istek ortalaması ise 113'te kaldı.
Bu sonuç, Google'ın 2017'de yazdığı ve güncel dokümanın da doğruladığı "hızlı site tarama oranını artırır" ilkesiyle çelişmiyor. Hız tavanı yükseltiyor, ama talep tavana varmıyorsa yükselen tavan kullanılmıyor. Site C'de kapasite yönündeki bir engel azaldı ve tarama yerinde saydı; tek bir sitenin gözlemi olsa da bu tablo, darboğazın talep tarafında durmasıyla uyumlu.
Site F ile yan yana okuduğumuzda aynı hamlenin, yani sunucuyu hızlandırmanın, bir sitede taramayı katlarken öbüründe hacmi yerinde bıraktığını görüyoruz. Aradaki fark hızın kendisinden gelmiyor, iki sitede bağlayan sınırın farklı olmasından geliyor.
Öbür Sitelerde Kapasite İzi Zayıf, Talep İzi Yayın Günlerinde
Kapasite bağladığında yanıt süresi ile istek sayısı arasında ters bir ilişki görmeyi bekliyoruz, çünkü sunucu yavaşladıkça Google istekleri kısıyor. Günde en az 20 istek alınan günlerde aynı gün korelasyonu Site F'de −0,75 çıktı. Öbür beş sitede zayıf kaldı: A −0,22, B −0,16, C −0,12, D −0,01, E 0,22. Bu beş değerin hiçbiri net bir kapasite tepkisi göstermiyor.
Talebin izini en net biçimde kendi sitemizde, Site E'de gördük: toplu yayın yaptığımız günlerde tarama sıçradı. Dönemin en yüksek günü, 243 istekle dokuz yazıyı birlikte yayınladığımız 17 Eylül; 73 isteklik bir başka yüksek gün de dört yazı yayınladığımız 21 Ağustos. 151 istekle ikinci sırada gelen 29 Ağustos'un sebebini ise bu veride göremiyoruz. Yeni içerik Google'ın algılanan envanterini büyütüyor, bu yüzden talebin tam bu günlerde yükselmesi dokümanın talep tarifine oturuyor. Yine de gördüğümüz şey bir korelasyon ve nedenselliği tek başına kanıtlamıyor.
Değişmemiş Sayfalar İçin 304 Döndürmek Kapasiteye Yer Açıyor
Kapasitenin nereye harcandığına bakmak, onun bağlamadığı sitelerde de kazanım alanı gösteriyor. Rapor hazırladığımız Site A'da bulduğumuz en net alan buydu: isteklerin %91,2'si bilinen sayfaların yeniden taranması (refresh), buna karşılık yanıtların yalnızca %0,01'i 304 Not Modified. Google'a göre değişmemiş bir sayfa için gövdesiz 304 döndürmek bant genişliği ve sunucu kaynağı kazandırıyor. Kapasite ortak olduğu için bu kazanç bütün Google crawler'larına kalabiliyor.
Aynı sitede isteklerin %59,1'i Crawl Stats'in Page resource load kategorisinde, yani Googlebot'un sayfayı render etmek için çektiği CSS ve JavaScript gibi kaynaklarda. Bu payı görünce kaynakları engellemek cazip gelebilir. Render adımının neden atlanamadığını JavaScript render süreci yazımızda, aynı kaynakları robots.txt ile kapatmanın bedelini de Next.js robots.txt engelleme yazımızda anlattık.
Bu verinin sınırları da belli. Crawl Stats günlük çözünürlükte ve saatlik bir kapasite tepkisi bu ölçekte görünmeyebilir. Veriyi sunucu erişim loglarıyla karşılaştıramadık ve altı site bir örneklem sayılmaz. Bulguyu bu yüzden bu altı siteyle sınırlı okuyoruz.
Sitenizde Hangi Sınırın Bağladığını Okumak
İki sınır Search Console'da farklı izler bırakıyor. Hangisinin sizi bağladığını önce ayırmak emeğin yanlış tarafa gitmesini önlüyor: kapasite bağlıyorsa iş sunucu ekibinde, talep bağlıyorsa envanterde ve içerikte başlıyor.
Kapasitenin Sınırladığını Gösteren İşaretler
En doğrudan işaret, URL Inspection aracında görünen Hostload exceeded uyarısı. Google bu uyarıyı sunucu kapasitesi yüzünden taranamayan sitenin örneği olarak veriyor ve işiniz için mantıklıysa sunucu kaynağı eklemenizi öneriyor. İkinci işaret Crawl Stats'teki host status. Son bir hafta içinde kayda değer bir erişim sorunu görünüyorsa yardım sayfası bunun tekrar edip etmediğine bakmanızı istiyor.
Üçüncü işaret bir örüntü: yanıt süresi ve 5xx ya da 429 payı birlikte yükselirken isteklerin düşmesi. Google yavaş yanıt veren ya da hata oranı artan bir sunucuda istekleri kısıyor ve bu düşüş o tepkinin izi. Bu tabloda kaldıraç sunucu tarafında duruyor: kaynak eklemek, yanıt süresini düşürmek ve değişmemiş sayfalar için 304 döndürmek.
Tarama Talebinin Sınırladığını Gösteren İşaretler
Host status temiz, yanıt süresi kararlı ve istekler haftalar boyunca düz seyrederken yeni sayfalarınız geç taranıyorsa, sınırlayan taraf büyük olasılıkla talep. Google'ın dokümanı kendi rehberinin kimin için olduğunu anlatırken URL'lerinin büyük bölümü Discovered - currently not indexed durumunda bekleyen siteleri ayrıca sayıyor. Bu durum, Google'ın URL'yi bildiğini ama henüz taramadığını gösteriyor.
Talep tarafında kaldıraç envanter ve kalite. Kopya içeriği konsolide etmek, kalıcı olarak kaldırılan sayfalarda 404 ya da 410 döndürmek ve sitemap'i güncel tutmak, algılanan envanteri gerçekten taranmasını istediğiniz sayfalara yaklaştırıyor. Uzun vadede talebi taşıyan ise içeriğin kalitesi ve benzersizliği. Sitenizde bu ayrımı veriyle yapmak isterseniz, hangi sınırın bağladığını gösteren bir teknik SEO denetimiyle başlayabiliriz.
Talebi Büyütmek Bir Sıralama Vaadi Taşımıyor
Talep tarafında çalışırken beklentiyi doğru kurmanızı öneriyoruz. Google 2017'de artan tarama oranının daha iyi bir konumu kendiliğinden getirmediğini yazdı: tarama sonuçlarda yer almak için gerekli, ama bir sıralama sinyali olarak işlemiyor. Güncel doküman taranan her sayfanın indekslenmediğini de ekliyor; taramadan indekslemeye geçişi crawl ve indexing farkı yazımızda anlattık. Talebi büyütmenin getirisi yeni sayfalarınızın daha erken görülmesi, sıralamayı ise başka sinyaller belirliyor.
Sıkça Sorulan Sorular
Crawl rate limit Search Console'dan ayarlanabilir mi?
Artık ayarlanamıyor. Search Console'daki Crawl Rate Limiter aracı 8 Ocak 2024'te kaldırıldı ve zaten yalnızca taramayı azaltmaya yarıyordu. Bugün taramayı yavaşlatmanın yolu sunucu yanıtları ya da Google'ın bildirim formu.
crawl-delay Googlebot'u yavaşlatır mı?
Yavaşlatmıyor, çünkü Googlebot standart dışı crawl-delay kuralını işlemiyor. Kısa süreli bir frene ihtiyacınız varsa Google 500, 503 ya da 429 döndürmenizi öneriyor.
Siteyi hızlandırmak crawl budget'ı artırır mı?
Sunucu kapasitesi taramayı sınırlıyorsa artırıyor, sınırlayan taraf talepse artırmıyor. Altyapısını taşıdığımız bir sitede ortalama yanıt süresi 2.339 ms'den 416 ms'ye indikten sonra günlük tarama yaklaşık 3,6 katına çıktı. Talebin bağladığı görünen başka bir sitede ise yaklaşık %20 hızlanma günlük istek sayısını değiştirmedi.
AI botları Googlebot'un kapasitesini paylaşır mı?
Google'ın dokümanındaki ortak kapasite yalnızca Google'ın kendi crawler'larını kapsıyor ve üçüncü taraf AI botlarını bu havuzun parçası olarak anmıyor. Dolaylı bir etki yine de mümkün: yoğun bot trafiği sunucunuzu yavaşlatırsa Google yavaşlayan sunucuda crawl capacity limit'i düşürüyor.
Hostload exceeded ne anlama geliyor?
URL Inspection aracındaki bu uyarı, sitenin sunucu kapasitesi yüzünden taranamadığını gösteriyor. Hostload, Google'ın crawl capacity limit için kullandığı öbür ad ve Google bu durumda işiniz için mantıklıysa sunucu kaynağı eklemenizi öneriyor.
Kaynaklar ve Referanslar
- Google Search Central, "Crawl Budget Management | Google Crawling Infrastructure", https://developers.google.com/crawling/docs/crawl-budget (son güncelleme 22 Temmuz 2026; erişim 22 Eylül 2026)
- Gary Illyes, "What Crawl Budget Means for Googlebot", Google Search Central Blog, 16 Ocak 2017, https://developers.google.com/search/blog/2017/01/what-crawl-budget-means-for-googlebot (erişim 21 Eylül 2026)
- Gary Illyes ve Nir Kalush, "Upcoming deprecation of Crawl Rate Limiter Tool in Search Console", Google Search Central Blog, 24 Kasım 2023, https://developers.google.com/search/blog/2023/11/sc-crawl-limiter-byebye (erişim 21 Eylül 2026)
- Google Crawling Infrastructure, "Reduce the Google crawl rate", https://developers.google.com/crawling/docs/crawlers-fetchers/reduce-crawl-rate (son güncelleme 18 Aralık 2025; erişim 21 Eylül 2026)
- Google Crawling Infrastructure, "How HTTP status codes affect Google's crawlers", https://developers.google.com/crawling/docs/troubleshooting/http-status-codes (son güncelleme 4 Şubat 2026; erişim 21 Eylül 2026)
- Google Search Console Yardım, "Crawl Stats report", https://support.google.com/webmasters/answer/9679690 (erişim 21 Ağustos 2026)