Crawl Bütçesi Yönetimi

Crawl Bütçesi Yönetimi, arama motoru botlarının sitenizde belirli bir zaman aralığında tarayabileceği sayfa sayısını, sunucu kaynaklarınızı ve içerik önceliklerinizi dengeleyerek yönettiğiniz bir süreçtir. Kısaca cevap: Botların gereksiz sayfaları tarayıp önemli içerikleri atlamasını engellemek için tarama önceliğini ve erişilebilirliği bilinçli biçimde ayarlamanız gerekir. Bu denge kurulmadığında, yeni yayınlanan ürün veya hizmet sayfaları dizine geç girebilir; buna karşılık filtre parametreleri, oturum bağlantıları ve tekrarlı listeleme sayfaları botun zamanını tüketebilir. Google, tarama bütçesini sitenin genel sağlığı, sunucu yanıt süreleri ve içerik güncelleme sıklığı gibi sinyallere göre kendisi belirler; bu bütçeyi doğrudan bir düğmeyle artıramazsınız. Yapabileceğiniz şey, botun işini kolaylaştırmak: yanıt sürelerini kısaltmak, gereksiz URL’leri engellemek ve site haritasını güncel tutmak. Bu üç adım, tarama davranışını dolaylı olarak iyileştirir. Yazı boyunca crawl bütçesinin nasıl ölçüldüğünü, hangi durumlarda tükendiğini, robots.txt ve site haritası ayarlarının nasıl kurgulanacağını ve sonuçların hangi araçlarla takip edileceğini adım adım ele alacağım.

500 bin URL’lik katalogda bot neyi tarıyor

Crawl Bütçesi Yönetimi, arama motoru botlarının bir siteye ayırdığı tarama kapasitesini, en değerli sayfalara yönlendirme işidir. Katalog sitelerinde bu yönetim, binlerce ürün sayfası arasında botun hangi URL’yi ne sıklıkta ziyaret edeceğini belirlediği için doğrudan görünürlüğü etkiler. Google, tarama kapasitesini site otoritesi ve sunucu yanıt süresi gibi sinyallere göre belirler; bu yaklaşımı Search Central belgelerinde açıklar. Yani botun bir günde tarayacağı URL sayısı sabit değildir, sitenin davranışına göre daralıp genişler.

Yeni ürünün keşfedilme gecikmesi

Kataloğa yeni bir ürün eklendiğinde, ürün sayfası bot tarafından saatler içinde değil, günler sonra görülebilir. Bu gecikme, crawl bütçesinin filtre ve parametre URL’leri gibi düşük değerli sayfalara harcanmasından kaynaklanır. Somut senaryo: 500 bin URL’lik bir katalogda günlük tarama kapasitesi kısıtlıysa, yeni eklenen 200 ürünün sıraya girmesi günler alabilir. Ürün bu süre boyunca aramada görünmez, stok ve fiyat bilgisi de güncellenmez.

• Yeni ürün URL’lerini XML site haritasına ekleyip lastmod değerini güncel tutun.
• Ürün listeleme sayfalarından yeni sayfalara iç bağlantı verin.
• Filtre ve sıralama parametrelerini robots.txt veya noindex ile sınırlayın.

Stok değişiminin taranma sıklığı

Fiyat ve stok bilgisi hızla değişir, bu yüzden bu sayfaların daha sık taranması gerekir. Ancak filtre URL’leri aynı bütçeyi tükettiğinde, gerçek ürün sayfaları seyrek ziyaret edilir. Bir ürün tükendiğinde sayfa hâlâ “stokta” görünüyorsa, kullanıcı hayal kırıklığı yaşar; arama motoru da güncel olmayan içeriği değerlendirir. Crawl bütçesi yönetimi, bu tür tutarsızlıkları azaltmak için kritik hale gelir. Kritik kural: Filtre ve parametre URL’leri taranabilir kaldıkça, gerçek ürün sayfalarının tarama sıklığı düşer. Bütçeyi korumak için bu URL’leri ayıklamak gerekir.

Tarama israfının indeksleme gecikmesine etkisi

Botun gereksiz URL’leri taraması, indeksleme sürecini yavaşlatır. Taranan sayfa sayısı artsa da indekse giren değerli sayfa sayısı aynı oranda artmaz. Aşağıdaki tablo, bütçenin nereye harcandığını ve beklenen etkiyi özetler.

Tarama israfı azaldığında, aynı bütçeyle daha fazla ürün sayfası taranır ve indeksleme gecikmesi kısalır. Bu etki, katalog büyüdükçe daha belirgin hale gelir.

Yanlış varsayım: sitemap büyürse tarama artar

Crawl bütçesi yönetimi açısından en yaygın yanlış varsayım, sitemap’e eklenen her URL’nin tarama sıklığını artıracağıdır. Sitemap bir keşif sinyalidir; tarama garantisi vermez. Google, sitemap’i botun yeni ve güncellenen sayfaları bulmasına yardımcı olan bir liste olarak değerlendirir, ancak hangi URL’yi ne zaman tarayacağını kendi kaynak kısıtlarına göre belirler. Bu ayrımı bilmeyen bir katalog yöneticisi, 500 bin URL’yi tek dosyaya yığarak tarama hızının artmasını bekler; sonuç genelde hayal kırıklığıdır.

Sitemap’in işlevi ve sınırı

Sitemap, arama motoruna “şu adresler var” der; “bunları hemen tara” demez. Google Search Central’ın sitemap dokümanı bunu açıkça belirtir: sitemap, tarama sürecini hızlandırabilir ama URL’lerin taranacağını veya dizine ekleneceğini taahhüt etmez. Sitemap’in gerçek sınırları şunlardır:

• Tek dosya en fazla 50.000 URL ve 50 MB sıkıştırılmamış boyut taşıyabilir; üstü için sitemap index gerekir.
• Sitemap yalnızca keşfi kolaylaştırır; sunucu yanıt süresi, içerik kalitesi ve iç bağlantı yapısı taramayı belirleyen asıl etkenlerdir.
• Bot, sitemap’teki her URL’yi aynı sıklıkta ziyaret etmez; gereksiz URL’ler bütçeyi tüketir.

Katalog sitesinde doğru yaklaşım, sitemap’i “tüm ürünlerin listesi” değil, “öncelikli ve güncel sayfaların listesi” olarak kullanmaktır. Böylece crawl bütçesi yönetimi gerçekçi bir zemine oturur.

robots.txt ile sitemap çelişkisi

robots.txt’te engellenen bir URL’nin sitemap’te yer alması, bot için doğrudan bir çelişki yaratır. Google, robots.txt ile engellenen sayfaları taramaz; sitemap’te görmesi bu kuralı değiştirmez. Sonuç: sitemap şişer, gerçek taranabilir URL’lerin sinyali zayıflar. Google Search Central’ın robots.txt dokümanı, engellenen kaynakların taranmayacağını ve dizine eklenemeyeceğini belirtir. Uygulamada şu kontrolü yapın:

1. robots.txt’teki her Disallow satırını listeleyin.
2. Sitemap dosyalarındaki URL’lerle karşılaştırın.
3. Çakışan URL’leri sitemap’ten çıkarın veya robots kuralını gözden geçirin.

Bu temizlik, crawl bütçesi yönetimi için en hızlı kazançlardan biridir; çünkü bot, sitemap’te gördüğü ama tarayamadığı URL’ler için kaynak harcamaz.

Öncelik etiketi beklentisi

Sitemap’teki riority etiketi, botların tarama sırasını belirlemez. Google bu etiketi yıllar önce yok saydığını duyurdu; dolayısıyla “0.9 verdim, daha sık taranır” beklentisi gerçek dışıdır. Aynı durum changefreq için de geçerlidir. Bunun yerine tarama önceliğini etkileyen gerçek sinyallere odaklanın:

• Sayfa içi bağlantı derinliği: ana sayfadan birkaç tıkla ulaşılan ürünler daha sık taranır.
• Son güncelleme tarihi (lastmod): doğru ve tutarlı verilirse bot için anlamlı bir sinyaldir.
• Sunucu yanıt süresi ve hata oranı: yavaş veya 5xx dönen sayfalar taramayı yavaşlatır.

Bu üç madde, sitemap’i şişirmekten daha çok işe yarar. Crawl bütçesi yönetimi burada ölçümle başlar: Search Console’daki “Taranan sayfalar” raporu ve sunucu logları birlikte okunmalıdır.

Parametre ve faceted URL karşılaştırma tablosu

Crawl bütçesi yönetimi, hangi URL tipinin taranmaya değer olduğunu ayırt etmekle başlar. Arama motoru botu bir URL’yi taramadan önce onu keşfeder, sonra sıraya alır. Sıradaki her gereksiz adres, gerçek içeriğin taranmasını geciktirir. Bu yüzden karar, URL tipine göre verilir, sayfa sayısına göre değil.

Hangi URL tipi taranmalı?

Ürün sayfası ve kategori sayfası taranmalıdır. İkisi de kullanıcının aradığı bilgiyi taşır, kendi başlığına ve metnine sahiptir. Bu sayfaların kanonik durumu kendine işaret etmeli, yani rel=canonical etiketi sayfanın kendi adresini göstermelidir. Sıralama parametresi tek başına taranmamalı. ?sirala=fiyat-artan gibi bir adres, aynı ürün listesini farklı sırada gösterir. Bu adreslerde canonical, parametresiz kategori URL’sine yönlendirilmelidir. Böylece bot aynı içeriği onlarca kez taramaz.

Hangi URL tipi elenmeli?

Oturum kimliği taşıyan adresler elenir. ?oturum=abc123 gibi bir parametre her ziyaretçide farklı URL üretir. Bu adresler noindex etiketiyle veya robots.txt kuralıyla taranmadan çıkarılmalıdır. Filtre kombinasyonları seçici biçimde ele alınır. Tek filtre anlamlı içerik üretiyorsa taranabilir, örneğin “kadın spor ayakkabı 38 numara” gibi bir arama karşılığı varsa. Rastgele birleşen üç dört filtre ise sonsuz URL uzayı yaratır. Bu kombinasyonlarda noindex ya da canonical ile tek bir temsilci adres işaretlenir.

Karar ölçütleri

Dört ölçüt kararı belirler: arama değeri, ayrışan içerik, değişim sıklığı ve canonical durumu. Aşağıdaki tablo bu ölçütleri URL tipine göre karşılaştırır.

rel=canonical, tarama bütçesini doğrudan azaltmaz; botu doğru adrese yönlendirir. noindex ise sayfayı dizinden çıkarır ama taranmasını engellemez. Bu yüzden crawl bütçesi yönetimi için robots.txt ile noindex birlikte düşünülmeli, tek başına noindex yeterli sayılmamalıdır.

Sunucu loglarından bütçe dağılımını okumak

Crawl bütçesi yönetimi, bot isteklerinin hangi URL tiplerine dağıldığını sunucu loglarından haftalık olarak ölçmekle başlar. Ölçüm yapılmadan alınan karar tahmine dayanır; oysa log satırları gerçek dağılımı gösterir.

Log dosyasında hangi alanlar

Standart erişim logunda üç alan kritiktir: user-agent, istek URL’si ve yanıt durumu. Bot isteğini insan trafiğinden ayırmak için user-agent doğrulaması gerekir; Googlebot için ters DNS kontrolü yapılabilir.

• user-agent: hangi botun geldiğini gösterir, sahte olabileceği için doğrulanmalı.
• istek URL’si: ürün, kategori, filtre veya arama sayfası ayrımını ortaya çıkarır.
• durum kodu: 200, 301, 404 ve 5xx dağılımı taranan ama değer üretmeyen yolları gösterir.
• yanıt süresi: sunucunun bot isteğini ne kadar sürede yanıtladığını verir.

Bu alanları URL tipiyle eşleştirmek, Crawl Bütçesi Yönetimi kararlarının temelini oluşturur. Örneğin katalog sayfalarına giden isteklerin payı ile filtre URL’lerine gidenlerin payı ayrı okunmalı.

Bot trafiğini ayıklama

Log analizinde önce insan ve bot isteklerini ayırın, sonra bot isteklerini kendi içinde türlere bölün. Googlebot dışındaki tarayıcılar da kaynak tüketir; toplam istek sayısı tek başına anlamlı değildir. Search Console’daki Tarama İstatistikleri raporu, Googlebot tarafındaki istek ve yanıt süresi eğilimini özetler. Log ile bu raporu yan yana koymak, sunucu tarafındaki gerçek yükü doğrular. Yanıt süresi ile tarama sıklığı arasında ilişki vardır: sunucu yavaşladıkça bot istekleri seyrekleşebilir. Google, tarama bütçesi belgelerinde sunucu yanıt hızının taramayı etkilediğini belirtir. Ölçüm yapmadan robots.txt değiştirmek körlemesine müdahaledir. Önce log dağılımını okuyun, sonra kural ekleyin.

Haftalık ölçüm ritmi

Haftalık ritim, değişikliğin etkisini görmek için yeterli aralıktır. Her hafta aynı metrikleri aynı araçla toplayın; ölçüm yöntemini değiştirmek karşılaştırmayı bozar.

Tablo, Crawl Bütçesi Yönetimi için takip edilecek üç temel metriği sabitler. Her hafta aynı üç satırı doldurmak, eğilimi görmeyi kolaylaştırır.

İlk 30 günde ne değişir: 300 ürünlü mağaza vakası

300 ürünlü, 40 kategorili ve çoklu filtre kullanan bir e-ticaret sitesinde Crawl Bütçesi Yönetimi ilk 30 günde ölçülebilir hale gelir. Çünkü katalog küçük görünse de filtre kombinasyonları URL sayısını ürün sayısının birkaç katına çıkarır. Aşağıdaki adımlar takvim sırasıyla ilerler.

1. hafta: envanter ve log

İlk iş, taranabilir tüm URL’leri tek listede toplamaktır. Ürün, kategori, filtre, arama sonucu ve sayfalama adresleri ayrı ayrı işaretlenir. Ardından sunucu loglarından bot istekleri çekilir.

• Log satırlarını bot adına, durum koduna ve URL tipine göre ayırın.
• Ürün, kategori, filtre ve parametreli adreslerin istek payını hesaplayın.
• 200, 301, 404 ve 5xx dağılımını ayrı sütunlarda tutun.

Bu haftanın çıktısı bir tablo: hangi URL tipi ne kadar istek alıyor. Tahmin değil, log kanıtı gerekir. Google’ın crawl bütçesi rehberi de kararları bu tür veriye dayandırmayı önerir.

2-3. hafta: kural ve kanonik

Log okunduktan sonra müdahale sırası netleşir. Filtre parametreleri robots.txt ile engellenir, sayfalama ve sıralama adresleri kanonik etiketle tek sürüme bağlanır. Sitemap yalnızca indekslenmesi gereken ürün ve kategori URL’lerini içerir.

1. Filtre ve sıralama parametrelerini engelleyin, ürün ve kategori yollarını açık bırakın.
2. Her ürün ve kategori sayfasına kendine işaret eden kanonik ekleyin.
3. Sitemap’ten filtre, arama ve oturum adreslerini çıkarın.
4. 404 veren eski ürünleri 301 ile ilgili kategoriye yönlendirin.

Kural değişikliklerinin etkisi hemen görünmez. Botlar yeni sinyali birkaç tarama turunda işler, bu yüzden 2-3 hafta beklemek gerekir. Crawl Bütçesi Yönetimi burada sabır ister.

4. hafta: ölçüm ve düzeltme

Dördüncü haftada ilk logla yeni log yan yana konur. Beklenen çıktı, ürün sayfalarına giden bot isteği payının artması ve indeksleme gecikmesinin kısalmasıdır. Sayısal hedef vermek yerine yön ve eğilim izlenir. Ölçüm için üç metrik yeterli: URL tipine göre istek payı, ortalama keşiften indekslemeye geçen süre, 5xx ve 404 oranı. Haftalık log dosyasıyla takip edin. Pixenon’un AI Trafik ve Dönüşüm Analizi, bot isteği dağılımını dönüşüm hunisiyle birlikte ölçtüğü için hangi ürün grubunun taranıp dönüşmediğini tek raporda gösterir.

Bu vaka bir şablon, garanti değil. Sonuçlar sitenin yapısına, sunucu yanıt süresine ve botların tarama sıklığına göre değişir.

Uygulama kontrol listesi: 12 madde

Crawl bütçesi yönetimi, tarama davranışını ölçüp müdahaleyi sırayla uygulamayı gerektirir. Aşağıdaki 12 madde, katalog ve hizmet sitelerinde tekrar eden tarama israfını azaltmak için sıralı bir çerçeve sunar.

Teknik kontroller

Önce erişim katmanını sabitleyin. robots.txt yalnızca gerçekten taranmasını istemediğiniz dizinleri kapatmalı; arama sonuç sayfaları ve sepet gibi sonsuz parametre üreten yollar buraya girer. Meta robots ve canonical etiketleri çakışmamalı, aynı URL için tek bir tercih bırakılmalı.

• robots.txt: Parametreli listeleme ve filtre yollarını kapatın, ürün ve kategori dizinlerini açık bırakın.
• Meta robots: Filtre ve sıralama sayfalarına noindex, follow verin; iç bağlantı akışı sürsün.
• Canonical: Sayfalama ve oturum parametreli URL’lerde tek kanonik adres tanımlayın.
• Oturum parametresi: Kullanıcı kimliği taşıyan parametreleri URL’den çıkarın veya canonical ile birleştirin.
• Sitemap: Yalnızca kanonik, 200 dönen URL’leri ekleyin; süresi geçmiş ürünleri çıkarın.
• Sayfalama: rel next/prev yerine net iç bağlantı ve kanonik yapı kurun, her sayfa kendi URL’sinde kalsın.

İçerik ve yapı kontrolleri

Tarama bütçesi yönetimi yalnızca teknik engelle ilerlemez; iç bağlantı mimarisi botun hangi sayfaya öncelik vereceğini belirler. Menü ve alt bilgi bağlantılarını sabit tutun, yeni sayfaları ilgili kategori sayfasından bağlayın. Hizmet sayfalarında Tüm Hizmetler ve Buca SEO gibi sabit bağlantılar, tarama derinliğini düşürür ve önemli URL’leri üst katmana taşır.

• İç bağlantı: Her yeni sayfa en az bir üst kategori sayfasından bağlansın.
• Yapı: Kategori, alt kategori ve ürün katmanlarını üç seviyede sınırlayın.

Doğrulama adımları

Değişikliğin işe yarayıp yaramadığını iki kaynaktan doğrulayın: Google Search Console tarama istatistikleri ve sunucu logları. Search Console’da “Tarama istatistikleri” raporundaki yanıt kodları ile log dosyasındaki bot isteklerini karşılaştırın. Ölçümü haftalık yapın, tek günlük veriyle karar vermeyin.

Son adım: değişiklik öncesi ve sonrası 30 günlük log kesitini yan yana koyun. Bot isteklerinin önemli URL’lere kayıp kaymadığını bu karşılaştırma gösterir.

Sınırlar ve riskler: kimler için uygun değil

Crawl bütçesi yönetimi, tarama talebinin sunucu kapasitesini aştığı ya da gereksiz URL’lerin gerçek içeriği gölgelediği sitelerde anlamlıdır. Sayfa sayısı sınırlı, yapısı düz ve içerik değişimi seyrek bir sitede bu çalışmanın ölçülebilir etkisi düşük kalır. Kaynak ayırmadan önce sitenin gerçekten bir tarama sorunu yaşayıp yaşamadığını kontrol etmek gerekir.

Küçük kataloglarda gereksiz müdahale

50 ile 100 sayfa aralığındaki bir sitede botların çoğu URL’yi birkaç turda keşfeder. Bu ölçekte robots.txt kuralı yazmak, parametre eleme yapılandırmak veya tarama hızını sınırlamak çoğu kez sorunu çözmez, yeni bir sorun üretir. Gereksiz müdahalenin tipik sonucu şudur: yeni yayımlanan bir sayfa, eklenen kural yüzünden dizine daha geç girer. Küçük katalogda öncelik, iç bağlantı yapısını düzeltmek ve sitemap’i güncel tutmaktır. Crawl bütçesi yönetimi burada ikinci planda kalır. Tarama sorunu belirtisi yoksa kural eklemeyin. Önce sunucu loglarında tekrar eden, düşük değerli URL kalıbı arayın.

Yanlış engellemenin maliyeti

robots.txt’ye yazılan tek satır, fark edilmeden kategori veya filtre sayfalarını kapatabilir. Botlar engellenen URL’yi taramaz, zamanla dizinden çıkarır. Trafik kaybı anında görünmez, haftalar sonra raporlarda ortaya çıkar.

• Kuralı yayına almadan önce arama konsolu üzerinden etkilenen URL sayısını doğrulayın.
• Değişikliği küçük bir dizin altında test edin, tüm siteye aynı anda uygulamayın.
• Engelleme sonrası ilk hafta organik girişleri ve dizin sayısını izleyin.

Geri dönüş çoğu durumda hızlı olmaz. Kaldırılan kural sonrası botların sayfayı yeniden keşfetmesi ve sıralamanın toparlanması zaman alabilir.

Ölçüm olmadan kural yazmak

Log dosyalarına bakmadan yazılan kural, tahmine dayanır. Hangi botun hangi dizini ne sıklıkla taradığını bilmeden bütçe dağıtmak, körlemesine ayar yapmakla aynı şeydir. Log dosyalarında IP adresi kişisel veri sayılabilir. KVKK kapsamında saklama süresi ve anonimleştirme planlanmalı. IP’yi maskeleyip yalnızca bot adı ve istek sayısını tutmak, hem ölçümü hem uyumu kolaylaştırır. Ölçüm yöntemi net olmalı: hangi metrik, hangi araç, hangi sıklık. Ölçüt tanımlanmadan crawl bütçesi yönetimi yapılmaz, yapılan ayarın işe yarayıp yaramadığı anlaşılmaz. Bu içerik bilgilendirme amaçlıdır, uzman görüşü yerine geçmez.

İlgili hizmetler ve kaynaklar

• Tüm Hizmetler
• AI Trafik ve Dönüşüm Analizi
• Marka Stratejisi ve Yol Haritası Hizmeti

Pixenon, yapay zeka görünürlük analizini 8 kategori ve 300 kanıtlı kriter üzerinden yürütüyor. Pixenon raporu, bu yazıdaki ölçütlerin hangi başlıkta ne kadar karşılandığını gösteriyor. Teknik ayrıntı için Google Search Central faydalı içerik rehberine, ölçüm notları için web.dev belgelerine ve yapay zeka tarayıcıları için llms.txt standardına bakabilirsiniz.

Crawl Bütçesi Yönetimi, arama motoru botlarının sitenizde belirli bir zaman aralığında tarayabileceği sayfa sayısını, sunucu kaynaklarınızı ve içerik önceliklerinizi dengeleyerek yönettiğiniz bir süreç demektir. Google AI destekli arama sonuçlarında ve ChatGPT, Gemini, Perplexity gibi yapay zeka araçlarının beslediği dizinlerde görünürlük, botun önemli sayfaları zamanında taramasına bağlıdır. Bu denge kurulmadığında filtre parametreleri ve tekrarlı listeleme sayfaları botun zamanını tüketir; yeni ürün sayfaları ise dizine geç girer. Bu yazıda crawl bütçesinin nasıl ölçüldüğünü ve robots.txt ile site haritası ayarlarının nasıl kurgulanacağını ele alıyorum.

Otomotiv kataloğunda bot önce hangi sayfaları taramalı?

Otomotiv kataloğunda öncelik, stokta olan araç ve yedek parça sayfalarına verilmelidir. Model, motor ve donanım bazlı ürün sayfaları bot için ilk sırada yer alır. Buna karşılık stokta olmayan, sezonu geçmiş veya birleştirilmiş araç sayfaları tarama bütçesini tüketmemelidir. Kategori ve filtre sayfaları yalnızca gerçek kullanıcıya değer sunuyorsa açık kalmalıdır. Bu öncelik sırası, yeni yayınlanan araç ve parça sayfalarının dizine daha erken girmesine yardımcı olur.

Tarama önceliği nasıl belirlenir?

• Stokta olan araç ve yedek parça sayfalarını öne alın
• Stokta olmayan veya birleştirilmiş sayfaları yönlendirin
• Filtre ve parametre sayfalarını yalnızca değer sunuyorsa açık tutun

Otomotiv sitesinde parametre ve faceted URL bütçeyi nasıl etkiler?

Araç listeleme sayfalarında marka, model, yıl, yakıt tipi ve vites gibi filtreler kolayca çoğalan URL üretir. Her kombinasyon ayrı adres olarak açıldığında bot aynı içeriği farklı adreslerde taramaya başlar. Bu durum crawl bütçesi yönetimi açısından gereksiz yük oluşturur. Filtre kombinasyonlarını sınırlamak, gereksiz olanları robots kuralları veya canonical ile yönetmek dengeyi korur. Böylece botun zamanı gerçek ürün ve hizmet sayfalarına ayrılır.

anlamak için kullanılır.

Kontrol listesi

Aşağıdaki 4 madde, bu yazıdaki yaklaşımın uygulanıp uygulanmadığını tek tek gösterir. Her madde kendi başına yanıtlanabilir.

Sık sorulan sorular

Crawl bütçesi nasıl artırılır?

Crawl bütçesini artırmak, arama motorunun siteye ayırdığı tarama kapasitesini sunucu ve içerik sinyalleriyle büyütmektir; doğrudan bir düğmeyle çoğaltılamaz. Sunucu yanıt sürelerini kısaltmak, 5xx hatalarını gidermek ve düşük değerli URL’leri ayıklamak kapasiteyi dolaylı büyütür. Site otoritesi ve güncel içerik hacmi de tarama sıklığını etkiler; artış kademeli olur.

Crawl bütçesi yönetimi için hangi araçlar kullanılır?

Crawl bütçesi yönetimi, tarama davranışını izleyip sunucu kayıtlarıyla karşılaştıran araçlarla yapılır. Google Search Console’un Crawl Stats raporu istek sayısını, yanıt kodlarını ve dosya türlerini gösterir. Sunucu erişim logları, Screaming Frog gibi tarayıcılar ve robots.txt test araçları birlikte kullanılır. Ölçüm haftalık yapılırsa değişim daha net görülür.

Filtre URL’leri robots.txt ile engellenmeli mi?

Filtre URL’lerini robots.txt ile engellemek, tarama isteğini azaltır ama sayfaların dizinden çıkmasını garanti etmez. Engellenen URL’ler taranamadığı için noindex etiketi okunamaz; bu da adresin dizinde kalmasına yol açabilir. Sonuç sayfalarında canonical ve noindex kullanmak daha tutarlı sonuç verir. Karar, filtrenin arama sonuçlarında görünmesinin istenip istenmediğine bağlıdır.

Crawl bütçesi ne kadar sürede düzelir?

Crawl bütçesindeki düzelme, yapılan değişikliğin türüne göre günler ile birkaç hafta arasında görünür; sabit bir süre yoktur. Sunucu hızı ve hata düzeltmeleri daha hızlı yansır, robots.txt ve site mimarisi değişiklikleri daha yavaş işler. Search Console’daki Crawl Stats verisini haftalık izlemek eğilimi gösterir. Sonuçlar sitenin boyutuna ve tarama geçmişine göre değişir.

Hangi durumda crawl bütçesi müdahalesi gereksizdir?

Crawl bütçesi müdahalesi, tarama istekleri sayfa sayısıyla dengeliyse ve önemli URL’ler düzenli taranıyorsa gereksizdir. Küçük sitelerde tarama kapasitesi zaten yeterli olduğu için ek kısıtlama fayda sağlamaz. Yeni içerikler birkaç gün içinde taranıyorsa sorun yok demektir. Bu durumda robots.txt veya noindex eklemek, taranması gereken sayfaları da engelleyebilir.