Tarama Talebi

TL;DR — Crawl budget’ın iki yönü vardır: bir arama motorunun sayfalarınızı ne kadar hızlı getirebildiği (crawl rate) ve onları taramayı ne kadar istediği (crawl demand). Crawl demand, “istemek” yönüdür. Google; popüler olduğunda (çok sayıda bağlantı aldığında), sık değiştiğinde ve siteyi harcadığı zamana değer gördüğünde bir sayfayı daha fazla taramak ister. Talebi artırmak için basabileceğiniz bir düğme yoktur — bunu bağlantılarla, gerçek güncellikle ve iyi sayfalarınızı bir yığın değersiz URL’nin altına gömmeyerek kazanırsınız.

Crawl demand nedir

İnsanlar “crawl budget” dediğinde aslında birbirine sıkıştırılmış iki ayrı şeyden söz eder. Biri, sunucunuzun taranmayı kaldırabilmesi — ne kadar hızlı ve aynı anda kaç sayfa. Buna crawl rate denir ve kendi sayfasında ele alınır. Diğeri, arama motorunun başta sizi ne kadar taramak istediğidir. Buna crawl demand denir — bu sayfanın konusu.

Bunu arz ve talep gibi düşünün. Crawl rate arz tarafıdır: sitenizin destekleyebileceği tarama miktarı. Crawl demand ise talep tarafıdır: Google’ın ne kadar tarama yapmak istediği. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Google’ın bir sayfayı taramak istemesini sağlayan şeyler

Google, tek ve eksiksiz bir kontrol listesi yerine birkaç önemli faktöre işaret eder. En ayrıntılı açıkladığı üçü şunlardır:

• Popülerlik. Kendilerine daha fazla bağlantı verilen sayfalar daha sık taranır; böylece Google kopyasını güncel tutar.
• Eskilik / güncellik. Bir sayfa çok değişiyorsa Google onu daha sık kontrol etmek ister. Hiç değişmiyorsa daha seyrek kontrol etmeyi öğrenir.
• Google’ın sahip olduğunuzu düşündüğü URL sayısı. Siteniz değersiz, yinelenen veya düşük değerli URL’lerle doluysa Google gerçek sayfalarınız yerine taramasını bunlarda harcar. En çok kontrol edebileceğiniz faktör budur. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Google bu üçüne ek olarak talebi şekillendiren birkaç site düzeyi faktörü de adlandırır: sitenizin büyüklüğü, ne sıklıkta güncellediğiniz, sayfa kalitesi ve benzer konuları ele alan diğer sitelerle karşılaştırıldığında sitenizin durumu. “Popülerlik, eskilik, algılanan envanter”i eksiksiz bir formül olarak görmeyin — bunlar en büyük ve en uygulanabilir kaldıraçlardır, listenin tamamı değildir.

Geçici bir faktör de vardır: sitenizi yeni bir alana taşırsanız Google, içeriği yeni URL’ler altında işlemek için her şeyi yeniden taramak zorunda kalır; bu nedenle talep bir süreliğine yükselir.

Crawl demand’ı neden öylece “artıramazsınız”

Bunun bir ayarı yoktur; tıpkı Google’ın daha hızlı taramasını sağlayacak bir düğme olmadığı gibi. Kimse bağlantı vermiyorsa ve gerçekten yararlı değillerse günde on yazı yayımlamak işe yaramaz. Gerçekten işe yarayan yöntemler yavaş ilerler ve somuttur: bağlantılar kazanın, içeriği gerçekten güncel tutun ve Google’ın tarama etkinliğinin önemli sayfalara ulaşması için değersiz URL’leri temizleyin.

Ve sürpriz şu: daha çok tarama hedef bile değildir. Çok taranmak daha yüksek sıralama sağlamaz. İstediğiniz şey daha fazla talep değil — sahip olduğunuz talebin doğru sayfalara yönelmesidir.

Talep ile sunucu kapasitenizin nasıl etkileştiğini, site kalitesinin tarama zamanlayıcısını nasıl etkilediğini ve talep problemiyle kapasite problemini nasıl ayırt edeceğinizi anlatan daha ayrıntılı sürümü mü istiyorsunuz? Advanced sekmesine geçin.

TL;DR — Crawl demand, crawl budget’ın istemek tarafıdır; crawl rate/capacity ise yapabilmek tarafıdır. Google, önemli genel talep faktörleri olarak popülerliği (bağlantılar / PageRank), eskiliği (sayfanın ne sıklıkta değiştiği) ve algılanan envanteri (Google’ın var olduğunu düşündüğü URL sayısı — değersizler dahil; “en olumlu biçimde kontrol edebileceğiniz faktör”) adlandırır — bunlar kapalı bir formül değildir; site büyüklüğü, güncelleme sıklığı, sayfa kalitesi ve karşılaştırmalı ilgi de rol oynar. Site taşımaları talebi geçici olarak yükseltir. Bunları birleştiren sentezim şu: talep URL’lerin öncelik sırasını belirler; host yükü kapasitesi Googlebot’un kuyrukta ne kadar aşağıya inebileceğine karar verir — Google bunu gerçek bir algoritma olarak belgelememiştir, ancak kanıtlara uyan model budur. Sağlıklı bir sunucu talep üretmez; yüksek talep yine de kapasiteyle sınırlanabilir. Talebi doğrudan ayarlayamazsınız — tek kaldıraçlar girdileridir ve dizine ekleme kalite sinyalleri iyileştiğinde zamanlayıcı talebi artırır. Bu sırada Google, talebi daha isabetli yönlendirirken daha az taramaya çalışıyor; dolayısıyla gerçek hedef hiçbir zaman hacim değil, doğru önceliklendirmeydi. Çoğu sitenin bunların hiçbirini yönetmesi gerekmez.

Crawl demand “istemek”, crawl rate “yapabilmek” tarafıdır

Google, crawl budget’ın iki yarısı olduğunu açıkça belirtir: Google’ın bir siteyi taramaya ayırdığı zaman ve kaynak miktarı “is determined by two main elements: crawl capacity limit and crawl demand.” Ben bunu Ahrefs crawl-budget rehberimde şöyle çerçeveliyorum: crawl budget, “made up crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” Talep istemektir; rate ise yapabilmektir. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Bu sayfa yalnızca istemek tarafını ele alır. Yapabilmek tarafı — crawl capacity limit, Ocak 2024’te kaldırılan GSC rate kaydırıcısı, 5xx/429 yanıtlarının Googlebot’u nasıl yavaşlattığı ve Bing’in manuel Crawl Control ızgarası — bütünüyle crawl rate sayfasında ele alınır. Bunları burada yeniden açıklamayacağım; iki tarafın etkileştiği yerlerde ilgili sayfaya bağlantı vereceğim.

Talebin üç girdisi

Google’ın güncel rehberine göre algılanan envanter, popülerlik ve eskilik, ne kadar taramak istediğini belirleyen önemli genel faktörlerdir — bunları eksiksiz ve kapalı bir formül olarak sunmaz. Aynı rehber, Googlebot’un değerlendirdiği faktörler arasında site büyüklüğünü, güncelleme sıklığını, sayfa kalitesini ve sitenin benzer sitelerle karşılaştırılmasını da sayar. Aşağıdaki üçü Google’ın en ayrıntılı açıkladığı ve doğrudan üzerinde çalışabileceğiniz girdilerdir. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Popülerlik

“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” Daha fazla bağlantı ve bir URL’ye yönelen daha fazla PageRank bir talep sinyalidir — ana sayfanızın sürekli taranıp derinlerde, hiçbir bağlantı verilmeyen bir sayfanın neredeyse hiç taranmamasının nedeni budur. Crawl-budget rehberimde şöyle ifade ediyorum: “Popular pages, or those with more links and PageRank, will generally receive priority over other pages.” Dahili bağlantılar da burada sayılır: hiçbir sayfanın bağlantı vermediği bir sayfanın (yetim sayfanın) arkasında neredeyse hiç talep yoktur.

Eskilik

“Our systems want to recrawl documents frequently enough to pick up any changes.” Google her sayfanın ritmini öğrenir. Sürekli değişen bir sayfa sık yeniden taranmayı hak eder; hiç değişmeyen bir sayfa giderek daha seyrek kontrol edilir. Crawl-budget rehberimde Google’ın statik bir sayfaya uyguladığı geri çekilmeyi şöyle anlatıyorum: “if they crawl a page and see no changes after a day, they may wait three days before crawling again, ten days the next time, 30 days, 100 days, etc.” URL başına bu yeniden tarama sıklığı aslında bir crawl frequency sorusudur — mekanizmasını orada ele alıyorum — ancak alttaki güç taleptir ve özellikle eskiliktir.

Algılanan envanter (en çok kontrol ettiğiniz faktör)

Bu, başlıca kaldıraçtır. Google şöyle der: “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.”

İnce nokta, bunun yalnızca kapasiteyi değil talebi de nasıl etkilediğidir. Değersiz URL’leri “crawl budget’ı boşa harcamak” olarak düşünmek kolaydır: tarama istekleri yeni içerik yerine kopyalara harcanır. Bu doğrudur. Ancak talep tarafında da bir etki vardır: keşfedilebilir envanteri çoğunlukla düşük değerli kopyalardan ve kontrolsüz parametre URL’lerinden oluşan bir site, Google’a taranmaya daha az değer bir site gibi görünür. Algılanan envanteri azaltmak yalnızca kapasiteyi serbest bırakmaz; zaman içinde talebi bunu hak eden URL’lerde yoğunlaştırır. Faceted navigation, session ID’leri, sonsuz takvim alanları ve diğer spider traps, envanteri şişiren ve talebi baskılayan klasik örneklerdir.

Site taşımaları ve diğer talep sıçramaları

Tek tek URL’lerle ilgili olmayan bir talep etkeni de vardır: “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” Alan adı geçişi veya büyük bir platform değişikliği yaptıktan sonra Googlebot’un birkaç hafta boyunca sitenizi normalden çok daha yoğun taradığını görürseniz bu beklenen bir durumdur — Google’ın her şeyi yeni adreslerden yeniden getirmesi ve işlemesi gerekir. Bu, yeni bir temel düzey değil, geçici bir sıçramadır. Google’ın kendi belgelerinde kelimesi kelimesine yer almasına rağmen rakip rehberlerin neredeyse hiç söz etmediği bir talep olayıdır. Evidence for this claim Google says site-wide events such as site moves may temporarily increase crawl demand so content can be reprocessed under new URLs. Scope: large or rapidly changing websites Confidence: high · Verified: 2026-07-16 Optimize your crawl budget

Talep ve host yükü nasıl etkileşir: kuyruk sırası ile kapasite kapısı

Konunun tamamını yerine oturtan bir zihinsel model var — bunun Google’ın birebir bir algoritma olarak belgelediği bir şey değil, benim sentezim olduğunu baştan açıkça belirtmek isterim. Model, burada Search Engine Roundtable’ın haberi üzerinden aktarılan bir Gary Illyes soru-cevap oturumuna dayanır: host load “sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” Aynı soru-cevap oturumuna göre host load, sahip olduğunuz ham URL sayısını veya taranmasını istediğiniz URL sayısını değil, sayfalarınızın önemini dikkate alır. İlgili sayfa otomatik getirmeyi engellediği için bu incelemede ifadeyi canlı kaynak üzerinden yeniden doğrulayamadım — bunu birincil kaynaktan kelimesi kelimesine yapılmış bir alıntı değil, güçlü biçimde doğrulanmış bir açıklama olarak değerlendirin.

Bunu dikkatle okuyunca bir ilişki ortaya çıkıyor — yine de bu, Google’ın baştan sona açıkladığı bir mekanizma değil; parçaları nasıl birbirine bağladığımdır:

• Talep sırayı belirler. “bucket of URLs in importance order”, crawl demand’ın kendisidir — hangi URL’lerin kuyruğun başında yer alacağını popülerlik ve eskilik belirler.
• Kapasite, Google’ın ne kadar ilerleyebileceğini belirler. Host load / crawl rate, Googlebot’un belirli bir günde bu sıralanmış URL kümesinde ne kadar ilerleyebileceğini belirler. “If your server can handle it, it crawls the whole bucket; if not, it stops.”

Dolayısıyla ikisi yalnızca birbiriyle çarpılmaz — farklı roller oynarlar. Sağlıklı ve hızlı bir sunucu talep üretmez (yalnızca mevcut talebinizin ne kadarının gerçekleşeceği tavanını yükseltir) ve yüksek talep yine kapasiteyle sınırlanabilir (yavaş veya hataya açık bir sunucu, Googlebot ne kadar taramak isterse istesin kuyruğun ortasında durmasına neden olur). Bu yüzden “daha hızlı bir sunucu aldım ama Google yeni sayfalarımı hâlâ taramıyor” çok yaygın ve sinir bozucu bir sonuçtur: kısıt kapasite değildi, talepti.

Talebi doğrudan ayarlayamazsınız — ama zamanlayıcı dinler

Kısa cevap: talebi doğrudan ayarlayamazsınız. Talebi, dizine ekleme sinyallerine yansıyan gerçek bağlantılar ve gerçek kalite iyileştirmeleri yoluyla dolaylı olarak kazanırsınız — başka hiçbir şey talebi değiştirmez.

Rate için olmadığı gibi talep için de bir “daha çok tara” isteği yoktur. Ancak talep dinamiktir ve Google, talebin nasıl değiştiği konusunda alışılmadık ölçüde açık konuşmuştur. Gary Illyes: “If you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” Geri bildirim döngüsü de neredeyse gerçek zamanlıdır: “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” Bunun tersi de geçerlidir: “If search demand goes down, then that also correlates to the crawl limit going down.” (Bu incelemede üç ifadeyi de Search Engine Journal’ın haberiyle yeniden karşılaştırdım ve kelimesi kelimesine eşleştiklerini gördüm. Yine de bunları birincil kaynaktan doğrulamak için Google’ın kendi podcast kaydına veya transkriptine ulaşamadım; bu nedenle güçlü biçimde doğrulanmış ikincil kaynak alıntıları olarak değerlendirin.)

Bu, “crawl demand’ı nasıl artırırım” sorusunu hilelerden uzaklaştırır. Sahte lastmod zaman damgaları, site haritası ping’leri ve yayımlama hacmi zamanlayıcıyı ikna etmez. İşe yarayan iki şey, zor olan iki şeydir: gerçek popülerlik (bağlantılar) ve dizine ekleme sinyallerinde görünen, zamanlayıcıya geri beslenen gerçek kalite iyileştirmeleri. Geri kalan her şey gösteriştir.

Google daha çok değil, daha az taramaya çalışıyor

Buradaki en yeni ve eski rehberlerin tamamen kaçırdığı açı şudur: Google’ın açıkladığı hedef, toplam tarama hacmini büyütmek değil azaltmaktır. Illyes Nisan 2024’teki bir LinkedIn gönderisinde şöyle yazdı: “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” Google’ın taramayı azaltmış olduğu fikrine karşı çıktı: “we’re crawling roughly as much as before, however scheduling got more intelligent” ve hedefi ortak bir kazanım olarak çerçeveledi: “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” İşaret ettiği mekanizmalar “sitemi daha çok tara” değil, daha iyi önbellekleme, kullanıcı aracıları arasında önbellek paylaşımı ve aktarılan baytların azaltılmasıydı.

Sonuç şu: crawl demand hiçbir zaman en üst düzeye çıkarılacak bir şey değildi. Google, daha az toplam taramayı eşit veya daha iyi tarama kalitesiyle hedefliyor ve sahip olduğu talebi bunu hak etme olasılığı daha yüksek URL’lere yönlendiriyor. Hedefiniz daha fazla talep değil — kazandığınız talebin doğru önceliklendirilmesidir.

Gerçekten bir talep probleminiz var mı?

Çoğu sitede böyle bir problem yoktur ve bu sitelerin konuya bir dakika bile ayırması gerekmez. Google’ın kendi yönlendirmesi talep için de doğrudan geçerlidir: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” John Mueller da ölçek konusunda benzer ölçüde nettir — Search Engine Roundtable’ın tweet’i aktaran haberine göre 100k URL, üç aylık dönemde dakikada bir taramadan çok daha azına karşılık geldiği için genellikle crawl budget’ı etkilemeye yetmez.

Site bu konuyu önemseyecek kadar büyükse, talep problemini kapasite probleminden ayırmaya yardımcı olacak inceleme şöyledir — ancak baştan belirtelim: sonuç bir test edilecek hipotezdir, teşhis değildir. GSC’nin Crawl Stats raporunu ve sunucu günlüklerinizi açın. Host durumu sağlıklı ve ortalama yanıt süresi normalken bir URL kümesi neredeyse hiç taranmıyor ve “Discovered – currently not indexed” durumunda takılı kalıyorsa bu örüntü, talebin düşük olduğuna işaret eden kanıttır; bunu kesin olarak kanıtlamaz. Crawl Stats bir talep skoru değil, tarama etkinliği gösterir ve kapasite tarafına ilişkin bir görünüm sunar. Herkese açık, site bazında bir “crawl demand score” yoktur; bu nedenle talebi hiçbir zaman doğrudan bir panelden okuyamaz, etkinlik ile dizine ekleme durumunu birlikte değerlendirerek çıkarım yaparsınız.

“Bu bir talep problemidir” sonucuyla harekete geçmeden önce, sunucu sağlıklı olduğu hâlde sayfaların taranmamasıyla aynı belirtiyi oluşturan diğer nedenleri eleyin: Google URL’leri henüz keşfetmemiş olabilir (URL’lere giden bir yol veya site haritası girdisi yoktur), rendering Googlebot’un görmesi gereken içeriği gizliyor olabilir, canonicalization Google’ı tamamen başka bir yere yönlendiriyor olabilir, gerçek kalite sorunları (ince, yinelenen veya düşük değerli içerik) bir sayfanın tarandığı hâlde bilinçli olarak dizinin dışında bırakılmasına yol açabilir ve Google’ın kendi indexing selection süreci, hem tarama hem de kalite açısından sorun bulunmayan bir sayfayı bile dışarıda bırakabilir. Ancak bunlar kontrol edilip hiçbirinin durumu açıklamadığı görüldükten sonra “düşük talep” çalışma hipotezi hâline gelir — o zaman bile doğrulanmış bir neden değil, eldeki kanıtlarla en iyi desteklenen hipotez olarak değerlendirilmelidir. Daha hızlı donanım gerçek bir talep problemini çözmez; çözüm talep girdilerindedir: bu sayfalara verilen bağlantılar, sayfaların yeniden taranması için gerçek nedenler ve onları gölgede bırakan değersiz envanterin azaltılması.

URL bazında gerçeği yansıtan tarama verileri için çözüm günlük analizidir. Tools sekmesinde, doğrudan deneyimime dayanarak değerlendirebileceğim güncel bir aracı belirteceğim.

Crawl demand ile rate, budget ve frequency arasındaki fark

Bu kavramları birbirinden ayırın:

• Crawl demand — Google’ın ne kadar taramak istediği (popülerlik + eskilik + algılanan envanter). Bu sayfa.
• Crawl rate — ne kadar hızlı yapabildiği (kapasite / host load). Kendi sayfası.
• Crawl budget — ikisinin toplamı: “the number of URLs Googlebot can and wants to crawl.”
• Crawl frequency — belirli bir URL’nin ne sıklıkta yeniden tarandığı; talebin bir çıktısıdır (çoğunlukla eskilik).

Bing “crawl demand” terimini kullanmaz — bütün konuyu crawl efficiency olarak yeniden çerçeveler: Fabrice Canel bunu “how often we crawl and discover new and fresh content per page crawled” şeklinde tanımlar; Bing’in felsefesi de algılanan envanterin talep tarafındaki karşılığı olan önce-envanter-azaltmadır. IndexNow, zamanlayıcının eskiliği çıkarsamasını beklemek yerine talep açısından anlamlı değişiklik olaylarını Bing’e bildirme yoludur — ancak Google IndexNow kullanmaz, dolayısıyla Google’ın talebini değiştirmez.

AI özeti

Advanced sürümün kısaltılmış özeti:

• Crawl demand, crawl budget’ın “istemek” tarafıdır; crawl rate/capacity ise “yapabilmek” tarafıdır. Budget, “the number of URLs Googlebot can and wants to crawl” ifadesidir.
• Önemli talep faktörleri — kapalı bir formül değildir: popülerlik (bağlantılar / PageRank), eskilik (sayfanın ne sıklıkta değiştiği) ve algılanan envanter (Google’ın var olduğunu düşündüğü URL sayısı — değersizler dahil; “en olumlu biçimde kontrol edebileceğiniz faktör”), ayrıca site büyüklüğü, güncelleme sıklığı, sayfa kalitesi ve karşılaştırmalı ilgi.
• Site taşımaları, Google içeriği yeni URL’ler altında yeniden işlerken talebi geçici olarak yükseltir.
• Talep ve kapasite modeli (benim sentezim, belgelenmiş bir Google algoritması değil): talep URL’lerin öncelik sırasını belirler; host yükü kapasitesi Googlebot’un kuyrukta ne kadar aşağıya ineceğine karar verir. Hızlı bir sunucu talep oluşturmaz; yüksek talep yine de kapasiteyle sınırlanabilir.
• Talebi doğrudan ayarlayamazsınız. Dizinleme kalite sinyalleri iyileştiğinde zamanlayıcı “talebi artırır” — dolayısıyla tek gerçek kaldıraç bağlantı kazanmak ve gerçek kalite/güncellik iyileştirmeleri yapmaktır. Sahte lastmod, site haritası ping’leri ve yayımlama hacmi bunu değiştirmez.
• Google daha çok değil, daha az taramaya çalışıyor (Illyes: “crawl even less… fewer bytes on wire”); talebi daha isabetli yönlendiriyor. Hedef hacim değil, doğru önceliklendirmedir.
• Talep ve kapasiteyi teşhis edin: sağlıklı host durumu + düşük tarama hacmi + “Discovered – currently not indexed” durumunda takılı kalmak talep hipotezidir, kanıt değildir — önce keşif, oluşturma, kanonikleştirme ve dizinleme seçimi nedenlerini eleyin. Herkese açık bir “crawl demand score” yoktur.
• Bing konuyu crawl efficiency olarak çerçeveler; IndexNow değişiklikleri Bing’e bildirir, Google’a değil. Çoğu sitenin bunu yönetmesi gerekmez.

Resmî belgeler

Arama motorlarının birincil kaynak belgeleri.

Google

• Optimize your crawl budget — crawl demand’i, üç girdisini (popülerlik, eskilik, algılanan envanter) ve site taşımalarının yol açtığı talep sıçramalarını tanımlayan kaynak.
• Crawl Budget Management — kapasite/talep ayrımı ve talebin karşılaştığı tarama kapasitesi mekanikleri.
• What crawl budget means for Googlebot (2017) — Gary Illyes’in crawl budget’ı Googlebot’un “can and wants to crawl” ifadesiyle tanımladığı özgün yazısı ve etkili talebi baskılayan düşük değerli URL kategorileri.
• Myths and facts about crawling — crawl rate’in bir sıralama sinyali olmadığını ve kapasite tavanını isteğin değil, sunucu sağlığının belirlediğini doğrular.
• Crawling December series (2024) — Googlebot, HTTP önbellekleme, faceted navigation ve daha az taramanın ardındaki verimlilik yaklaşımı.

Bing / Microsoft

• bingbot Series: Maximizing Crawl Efficiency — Bing’in “crawl efficiency” çerçevesi, bunun talep tarafındaki karşılığı.
• bingbot Series: Optimizing Crawl Frequency — içeriğin ne sıklıkta değiştiğiyle yönlenen yeniden tarama ritmi üzerine Bing’in yaklaşımı (eskilik karşılığı).
• IndexNow / indexnow.org — çıkarıma dayalı eskiliği beklemek yerine değişen URL’leri Bing’e ve diğerlerine bildirin (Google’a değil).

Kaynaktan alıntılar

Google ve Bing’den kayda geçmiş ifadeler. Her bağlantı, kaynak sayfadaki alıntı bölümüne atlayan bir derin bağlantıdır.

Google — talep tanımı ve girdileri

• “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” — Large Site Owner’s Guide to Managing Crawl Budget. Alıntıya git
• “Each crawler has its own ‘demand’ when it comes to crawling the web.” Alıntıya git
• “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (popülerlik) Alıntıya git
• “Our systems want to recrawl documents frequently enough to pick up any changes.” (eskilik) Alıntıya git

Google — algılanan envanter ve site taşımaları

• “If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” Alıntıya git
• “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” Alıntıya git
• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” Alıntıya git

Gary Illyes, Google — talep gerçekte nasıl hareket ediyor (Search Engine Journal’ın podcast görünümünü kapsayan yazısı aracılığıyla)

• “If you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” Kapsamı oku
• “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” Kapsamı oku
• “If search demand goes down, then that also correlates to the crawl limit going down.” Kapsamı oku

Gary Illyes, Google — “daha da az tara” görevi (LinkedIn, Nisan 2024 — birincil kaynak, kelimesi kelimesine doğrulandı)

• “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” Gönderiye git
• “we’re crawling roughly as much as before, however scheduling got more intelligent” ve “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” Gönderiye git

Bing / Microsoft — crawl efficiency (talep tarafı karşılığı)

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” — Fabrice Canel. Alıntıya git

Bu bir crawl-demand problemi mi — ve önemsemeli misiniz?

Yukarıdan aşağıya ilerleyin. Çoğu site, daha ilk aşamada “olduğu gibi bırakın” sonucuna ulaşır.

Crawl demand mitleri ve hataları

İnsanları yanlış yola yönelten kavram karışıklıkları.

“Crawl demand ve crawl budget aynı şeydir.” Neden yanlış: Talep iki bileşenden biridir; budget, kapasite × talebin birleşimidir — “the number of URLs Googlebot can and wants to crawl.” Bunun yerine: Terimleri doğru kullanın. Budget sonuçtur; talep ve kapasite iki girdisidir. Bir budget problemi her zaman gerçekten bir talep problemi, kapasite problemi veya ikisidir.

“Daha hızlı bir sunucu crawl demand’ı artırır.” Neden yanlış: Sunucu hızı yalnızca kapasite tavanını yükseltir. Google’ın zaten sahip olduğunuz talebin daha fazlasını gerçekleştirmesini sağlar; Google’ın daha çok taramak istemesine yol açmaz. Talep; popülerlik, eskilik ve algılanan envanter tarafından belirlenir — donanımınız bunların hiçbirine dokunmaz. Bunun yerine: Sağlıklı bir sunucu yine de sayfalarınızı taratmıyorsa donanım satın almayı bırakın ve talep girdileri üzerinde çalışın (bağlantılar, güncellik, daha az değersiz envanter).

“Daha sık yayımlamak talebi artırır.” Neden yanlış: Gerçek önem veya değişiklik olmadan yayımlama hacmi zamanlayıcıyı ikna etmez. Kimsenin bağlantı vermediği günde on ince yazı hiçbir şeyi değiştirmez. Bunun yerine: Bağlantı kazanan ve gerçekten değişen/iyileşen şeyler yayımlayın — zamanlayıcının dinlediği kalite sinyallerini besleyen budur. (Bu aynı zamanda bir crawl frequency noktasıdır; ayrıntısı oradadır.)

“Değersiz URL’leri robots.txt içinde engellemek bu talebi anında iyi sayfalarıma yönlendirir.” Neden yanlış: Algılanan envanteri azaltmak, Google siteyi yeniden değerlendirdikçe talebin zamanla yoğunlaşmasına yardım eder — ancak bu anında yeniden dağıtım değildir. Google, değersizleri engellediğiniz anda boşalan taramayı otomatik olarak iyi sayfalarınıza dökmez. Bunun yerine: Uzun vadeli yoğunlaşma yararı için değersiz envanteri azaltın ve sabırlı olun. Bu bir eğilimdir, düğme değil.

“Search Console’da kontrol edebileceğim bir crawl-demand skoru var.” Neden yanlış: Her site için herkese açık bir talep skoru yoktur. Crawl Stats, talep metriğini değil tarama etkinliğini — kapasite tarafı raporunu — gösterir. Bunun yerine: Talebi etkinlik ve dizine ekleme durumundan çıkarın (ör. sağlıklı host + düşük tarama hacmi + “Discovered – currently not indexed” = talep sinyali). URL başına gerçek durum için günlük verilerini kullanın.

“IndexNow veya site haritası ping’leri Google’ın crawl demand’ını artırır.” Neden yanlış: Google IndexNow kullanmaz ve site haritalarındaki changefreq/priority değerlerini yok sayar. Google’a ping atmak onun sizi daha çok taramak istemesini sağlamaz. Bunun yerine: IndexNow’u Bing ve katılan diğer motorlar için kullanın. Google için doğru lastmod zamanlamaya yardımcı olur; ancak talep kaldıraçları bağlantılar, güncellik ve envanter olmaya devam eder.

“Daha çok tarama her zaman daha iyidir — benim için de Google için de.” Neden yanlış: Daha çok taranmak sıralamaları yükseltmez; Google’ın kendisi de talebi daha isabetli yönlendirirken daha az taramaya çalışıyor (“My mission this year is to figure out how to crawl even less, and have fewer bytes on wire”). Bunun yerine: Ham hacmi değil doğru önceliklendirmeyi hedefleyin. Amaç, sahip olduğunuz talebin doğru URL’lere ulaşmasıdır.

Uygulama adımları: “Google önemli sayfalarımı taramıyor ve sunucumda sorun yok”

Talep probleminden şüphelenen büyük bir site sahibi için doğrusal yol. Bir adım sorunu çözer çözmez durun.

1. Konuyu önemseyecek kadar büyük olduğunuzu doğrulayın. Sayfalar genellikle yayımlandıkları gün taranıyorsa veya site normal boyuttaysa durun — crawl-demand probleminiz yoktur. Bu uygulama adımları 1M+ sayfalı, hızlı değişen ya da büyük bir “Discovered – currently not indexed” yığını bulunan siteler içindir.

2. Önce kapasiteyi eleyin. GSC Crawl Stats’i açın. Son 90 gündeki host durumunu ve ortalama yanıt süresini kontrol edin. 5xx/zaman aşımı sıçramaları veya yükselen yanıt süreleri görüyorsanız bu bir kapasite problemidir — sunucu sağlığını düzeltin (crawl rate sayfasına bakın) ve ardından bu çalışma kitabını yeniden çalıştırın. Sunucu sağlıklı görünüyorsa devam edin.

3. URL bazındaki gerçek durumu günlüklerden alın. Etkilenen URL kümesinin sunucu günlüklerini (veya bir bot analytics akışını) edinin. Örüntüyü doğrulayın: gerçek Googlebot istekleri önemsediğiniz sayfalarda seyrek veya hiç yokken değersiz/parametreli URL’ler istekleri tüketiyor. Sağlıklı bir sunucudaki sayfaların seyrek taranması henüz doğrulanmış bir neden değil, talep hipotezidir. “Talep” sonucuna varmadan önce benzer belirtiler oluşturan nedenleri eleyin: Google’ın URL’yi keşfetmemiş olması, içeriği gizleyen bir rendering hatası, sayfanın başka bir URL’sini işaret eden canonicalization, gerçek kalite/yinelenme sorunları ve Google’ın kendi indexing-selection tercihleri. Her URL için Search Console’daki URL Inspection aracını ve render edilmiş HTML görünümünü kontrol edin.

4. Algılanan envanterdeki şişmeyi kontrol edin. Google’ın keşfedebileceği düşük değerli URL’leri sayın: faceted-navigation kombinasyonları, session ID’leri, sıralama/filtre parametreleri, takvim/sonsuz alanlar ve site içindeki kopyalar. Bunların sayısı gerçek sayfalarınızın çok üzerindeyse talep, değersiz URL’lere dağılıyor olabilir.

5. Değersiz envanteri kesin. Düşük değerli URL alanını kaynağında azaltın (parametre yönetimi, sonsuz alanlar için robots.txt engeli, spider trap’leri düzeltme ve yinelenenleri kanonikleştirmeyle birleştirme). Anında yeniden dağıtım değil, zaman içinde yoğunlaşma bekleyin.

6. Popülerlik girdisi üzerinde çalışın. Güçlü sayfalardan az taranan sayfalara internal link’ler ekleyin (yetim sayfaları ortadan kaldırın) ve external link’ler kazanmaya çalışın. Popülerlik, talebin başlıca etkenlerinden biridir.

7. Kalite/güncellik girdisi üzerinde çalışın. Sayfaları gerçekten iyileştirin ve güncelleyin; böylece dizine eklemeden dönen sinyaller zamanlayıcıya “talebi artırmasını” söylesin. Doğru lastmod Google’ın zamanlamasına yardımcı olur; sahte güncellik olmaz.

8. Zaman tanıyın, sonra yeniden ölçün. Google’ın yeniden değerlendirmesi için zaman geçtikten sonra Crawl Stats’i ve günlükleri tekrar kontrol edin. Talep değişimleri yavaştır. Sayfalar artık taranıyor ve dizine ekleniyorsa iş bitmiştir. Değilse sayfaların gerçekten taranmaya değer olup olmadığını yeniden düşünün — bazen dürüst cevap değerli olmadıklarıdır ve ince sayfalar dizine zorla sokulmamalıdır.

Crawl-demand kontrol listesi

Teşhis: talep mi, kapasite mi?

• Sitenin gerçekten önemsemeye değecek kadar büyük veya hızlı değişen bir site olduğunu doğruladım (değilse durun).
• GSC Crawl Stats: host durumu sağlıklı, ortalama yanıt süresi istikrarlı, 5xx/zaman aşımı sıçramaları yok.
• Sunucu günlükleri (veya bot analitiği), URL başına gerçek Googlebot istekleri açısından incelendi.
• Örüntü belirlendi: sağlıklı sunucu + iyi sayfalarda düşük tarama hacmi + “Discovered – currently not indexed” = bir talep hipotezi, kanıt değil — ayrıca bir kapasite sorunu da değil.
• Talebi sorumlu tutmadan önce benzer belirtiler oluşturan nedenleri eledim: keşif, oluşturma, kanonikleştirme, kalite/yinelenme ve dizinleme seçimi sorunları.

Talep girdileri üzerinde çalışın (doğrudan ayar yok)

• Popülerlik: önemli sayfalara dahili bağlantılar yöneliyor (yetim yok); önemli yerlerde dış bağlantı çalışması sürüyor.
• Eskilik/güncellik: sık yeniden taranması gereken sayfalar gerçekten güncelleniyor; lastmod doğru (sahte değil).
• Algılanan envanter: faceted-nav, parametre, oturum kimliği ve sonsuz URL alanları kontrol altında; spider trap’ler düzeltildi; yinelenenler birleştirildi.

Gerçeklik kontrolleri

• Daha hızlı bir sunucunun talebi artırmasını beklemiyorum (yalnızca kapasite tavanını artırır).
• Değersizleri robots.txt ile engellemenin talebi iyi sayfalara anında yönlendirmesini beklemiyorum (zamanla yoğunlaştırır).
• IndexNow/site haritası ping’lerinin Google’ın talebini değiştireceğine güvenmiyorum (Google IndexNow’u ve changefreq/priority değerlerini yok sayar).
• Site taşınmasından sonra geçici tarama sıçramasını sorun değil, beklenen bir durum olarak görüyorum.
• Daha çok taramanın hedef olmadığını — doğru önceliklendirme olduğunu — ve tarama hacminin sıralama faktörü olmadığını hatırlıyorum.

Crawl demand — hızlı başvuru

Crawl budget’ın iki tarafı

Üzerinde en kolay çalışılabilen üç talep girdisi (Google; bunların yanı sıra site büyüklüğünü, güncelleme sıklığını, sayfa kalitesini ve karşılaştırmalı ilgiyi de önemli genel faktörler arasında sayar — bu, kapalı bir formül değildir)

Hızlı bilgiler

• Crawl budget = “the number of URLs Googlebot can and wants to crawl.”
• Algılanan envanter, “the factor you can positively control the most” ifadesidir.
• Site taşımaları talebi geçici olarak yükseltir (yeni URL’ler altında yeniden işleme).
• Talep öncelik sırasını belirler; host yükü kapasitesi Google’ın ne kadar derine tarayacağına karar verir — sağlıklı bir sunucu talep oluşturmaz.
• Dizinleme kalite sinyalleri iyileştiğinde zamanlayıcı “talebi artırır” — bağlantılara ek olarak tek gerçek kaldıraç budur.
• Google’ın hedefi daha fazla değil, genel olarak daha az taramaktır (Illyes, 2024). Tarama hacmi sıralama faktörü değildir.
• Herkese açık bir “crawl demand score” yoktur — Crawl Stats etkinliği (kapasite tarafını) gösterir.
• Bing “crawl demand” terimine sahip değildir — buna crawl efficiency der; IndexNow değişikliği Bing’e, Google’a değil, bildirir.

Crawl demand teşhis araçları

Bir “talep ölçeri” yoktur; bu nedenle talebi teşhis etmek, tarama etkinliğini okumak ve bunu sayfalar hakkında bildiklerinizle karşılaştırmak anlamına gelir.

• Google Search Console — Crawl Stats raporu — zaman içindeki toplam tarama istekleri, host durumu, ortalama yanıt süresi ve yanıt kodu, dosya türü, amaç ve Googlebot türüne göre dökümler. Bunu bir kapasite görünümü olarak okuyun: sağlıklı host durumu + iyi sayfalarda düşük tarama hacmi, talep göstergeniz.
• GSC — Sayfa dizine ekleme raporu — “Discovered – currently not indexed” kovası, talep eksikliğinin klasik izidir (Google URL’leri biliyor ama henüz tarayacak kadar önemsemiyor).
• URL Inspection (GSC) — belirli bir URL’nin en son ne zaman tarandığını ve dizine eklenip eklenmediğini kontrol edin; tek bir sayfanın talep hikâyesini doğrulamak için yararlıdır.
• Sunucu günlük dosyası analizi — gerçek, URL başına Googlebot isteklerinin doğrusu: botların hangi URL’leri gerçekten getirdiği, ne sıklıkta getirdiği ve taramanın değersiz envanterde nerede boşa harcandığı. (log file analysis bölümüne bakın.)
• Ahrefs Bot Analytics — ilk elden konuşabileceğim bir araç. Lansmanında şöyle anlatmıştım: “Have y’all checked out Bot Analytics in Ahrefs yet? We released a new tool that shows how bots crawl your website. Bot Analytics collects data server-side via Cloudflare integration.” Sitenizi tarayan her botu ve 12 kategori boyunca ulaştıkları sayfaları gösterir — Google’ın “algılanan envanter” ve “popülerlik” hikâyesini gerçekle karşılaştırmak için gereken, URL ve bot başına gerçek durum budur. Ahrefs’in çözdüğü problemi kendi çerçevelemesiyle: “uncontrolled bot traffic wastes crawl budget — bots crawling 404 pages or low-value URLs aren’t crawling the pages you need indexed,” ve tüm tarayıcı trafiğinin yarısından fazlasının boşa harcanan çaba olduğu tahminine atıfta bulunur: over half of all crawler traffic is wasted effort.
• Ahrefs Site Audit / Screaming Frog SEO Spider — algılanan envanteri şişiren ve talebi bastıran parametre karmaşasını, yinelenenleri ve tuzak benzeri örüntüleri ortaya çıkarmak için taramayı simüle eder.

Önem × değişim × envanter çerçevesi

Crawl demand’daki değişiklikleri açıklamak için şu üç soruyu kullanın:

1. Önem: Dahili veya harici sinyaller URL’yi daha mı önemli, daha mı önemsiz yaptı?
2. Değişim: Sayfa anlamlı biçimde değişti mi ve doğru site haritası sinyalleri bunu iletti mi?
3. Envanter: Tarayıcının bildiği yinelenen, parametreli veya düşük değerli URL kümesi büyüdü mü?

Host sağlığı dördüncü bir talep girdisi değil, tavandır. Günlükler hata veya zaman aşımı gösteriyorsa crawl capacity’yi ayrı teşhis edin. Sunucu sağlıklı olduğu hâlde değerli URL’ler tarama payını kaybediyorsa önem, değişim ve envanter başlıklarını bu sırayla inceleyin.

Dizin bazında tarama payını karşılaştırın

Bu kabuk işlem hattı, yaygın bir erişim günlüğündeki doğrulanmış tarayıcı isteklerini ilk URL-yolu dizinine göre özetler:

awk 'BEGIN{IGNORECASE=1} /Googlebot/ {split($7,p,"/"); print "/" p[2] "/"}' access.log | sort | uniq -c | sort -nr

PowerShell’de:

Select-String .\access.log -Pattern 'Googlebot' | ForEach-Object { if ($_.Line -match '"(?:GET|HEAD)\s+https?://[^/]+/([^/?\s]*)|"(?:GET|HEAD)\s+/([^/?\s]*)') { '/' + (($Matches[1],$Matches[2] | Where-Object { $_ })[0]) + '/' } } | Group-Object | Sort-Object Count -Descending

Değişiklikten önceki ve sonraki aynı uzunluktaki pencereleri karşılaştırın. Pay kazanan bir dizin, zamanlayıcı dağılımı hakkında ipucudur; daha yüksek kalite veya sıralama kanıtı değildir.

Crawl demand metrikleri

Değerli şablonların tarama payı

Metrik: önemli şablonlara gelen tarayıcı isteklerinin doğrulanmış tarayıcı isteklerine oranı. Size ne söyler: talebin önemsediğiniz envantere ulaşıp ulaşmadığını. Nasıl elde edilir: erişim günlüğündeki URL’leri şablonlarına göre sınıflandırın. Kıyaslama / gerçekçi aralık: hedef karışımı kendi değerli envanterinize ve güncelleme sıklığınıza göre belirleyin; evrensel bir yüzde yoktur. Ölçüm sıklığı: büyük ve değişken sitelerde haftalık, diğerlerinde aylık.

Anlamlı değişikliklerden sonra yeniden tarama gecikmesi

Metrik: gerçek bir sayfa güncellemesi ile doğrulanmış bir sonraki tarayıcı isteği arasında geçen süre. Size ne söyler: zamanlayıcının sayfanın önemini ve değişim örüntüsünü tanıyıp tanımadığını. Nasıl elde edilir: dağıtım veya içerik zaman damgalarını erişim günlükleriyle birleştirin. Kıyaslama / gerçekçi aralık: her şablon için ayrı bir temel değer belirleyin; haber sayfalarıyla değişmeyen referans sayfaları aynı hedefi paylaşmamalıdır. Ölçüm sıklığı: aylık.

Düşük değerli envanter payı

Metrik: bilinen ve taranan parametreli, yinelenen, boş veya soft-404 URL’lerin yararlı URL’lere oranı. Size ne söyler: algılanan envanterin dikkati dağıtıp dağıtmadığını. Nasıl elde edilir: tarama dışa aktarımlarını, site haritalarını, indexability kurallarını ve günlükleri birleştirin. Kıyaslama / gerçekçi aralık: gerekli kaynakları engellemeden, sitenin temel değerine göre düşüş eğilimi hedefleyin. Ölçüm sıklığı: aylık ve faceted-navigation veya platform değişikliklerinden sonra.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• When Should You Worry About Crawl Budget? — crawl budget’ı talep (“how many pages a search engine wants to crawl”) ile rate’in birleşimi olarak çerçevelediğim; popülerliği, eskilik nedeniyle uygulanan geri çekilmeyi ve kimlerin bu konuyu gerçekten önemsemesi gerektiğini ele aldığım yazı.
• What Is Googlebot & How Does It Work? — Googlebot’un neyi ve ne kadar tarayacağına nasıl karar verdiği.
• The Beginner’s Guide to Technical SEO — tarama ve crawl budget’ın büyük resimdeki yeri.

Konuşmalarım

• How Search Works (SlideShare) — tarama anlatımım; talep faktörleri (PageRank, güncellik, son taramadan bu yana geçen süre, büyük site değişiklikleri) ve ayrı kapasite/host-load slaytı dahil. (Sürekli geçerli uyarı: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Sektörün çeşitli yerlerinden

• Google’s Crawling Priorities: Insights From Gary Illyes (Search Engine Journal) — talebin nasıl hareket ettiğine dair “convince search your stuff is worth fetching”, “turning up demand” ve “search demand goes down” alıntıları.
• Gary Illyes on crawling even less (LinkedIn, Nisan 2024) — “crawl even less… fewer bytes on wire” ve “scheduling got more intelligent” için birincil kaynak.
• Google Has Two Types Of Crawling: Discovery & Refresh (Search Engine Journal) — John Mueller’ın keşif ile yenileme taramaları hakkındaki açıklaması; yenileme ritmi saf bir talep çıktısıdır.
• Google’s Gary Illyes On Crawl Budget, Scheduling & Host Load (Search Engine Roundtable) — host-load için “bucket of URLs in importance order” çerçevesi (bu makalede açıklama olarak verilmiştir; sayfa otomatik getirmeyi engeller — canlı sayfaya göre doğrulayın).
• Google: 100k URLs Won’t Impact Crawl Budget (Search Engine Roundtable) — John Mueller’ın ölçek içgüdüsel kontrolü (burada açıklanmıştır; canlı sayfaya göre doğrulayın).
• What Is Crawl Budget? How It Works + Optimization Tips (Search Engine Land) — üç talep faktörü hakkında yararlı arka plan veren kapsamlı crawl-budget rehberi.
• Ahrefs Bot Analytics — gerçek bot verileriyle talep ve kapasiteyi teşhis etmedeki “uncontrolled bot traffic wastes crawl budget” ve “over half… wasted effort” çerçevelerini içeren ürün sayfası.

Kendinizi sınayın: Crawl Demand

Crawl budget’ın “istemek” tarafıyla ilgili beş hızlı soru. Her biri için bir cevap seçin, sonra kontrol edin.

Değişiklik günlüğü