Google Tarama Bütçesi (Crawl Budget) Optimizasyonu

Hızlı Özet (TL;DR)

Tarama Bütçesi (Crawl Budget); Googlebot ve diğer arama motoru örümceklerinin belirli bir zaman diliminde web sitenizde keşfetmeye ve taramaya ayırdığı maksimum URL sayısı ile sunucu kaynak limitinin birleşimidir. Yüzlerce endüstriyel ürün sayfası, teknik şartname, çok dilli katalog veya derin bir mühendislik blog arşivi barındıran kurumsal web sitelerinde tarama bütçesi bilinçsizce harcanırsa; Googlebot yeni eklenen veya güncellenen kritik hizmet sayfalarınıza ulaşamadan sitenizden ayrılır. Düşük sunucu yanıt süresi (50 ms altı TTFB), disiplinli bir robots.txt kurgusu, yönlendirme zincirlerinin temizlenmesi ve parametreli URL tuzaklarının (Spider Traps) kapatılması sayesinde tarama bütçesi %100 verimle ana gelir sayfalarına yönlendirilir.

Google Tarama Bütçesi (Crawl Budget) Matematiği: Kapasite Sınırı ve Tarama Talebi

Google arama motoru mühendisliği dokümantasyonuna göre bir web sitesine tahsis edilen tarama bütçesi, iki temel değişkenin kesişimiyle dinamik olarak hesaplanır: Tarama Kapasitesi Sınırı (Crawl Capacity Limit) ve Tarama Talebi (Crawl Demand).

1. Tarama Kapasitesi Sınırı (Crawl Capacity Limit)

Googlebot, taradığı bir web sitesinin sunucusunu aşırı yükleyip gerçek ziyaretçilere hizmet veremez hale getirmemek için bir “tarama sağlığı” algoritması çalıştırır. Kapasite sınırını belirleyen faktörler şunlardır:

• Sunucu Yanıt Hızı (TTFB): Sunucunuz her HTTP isteğine 800 ms yerine 25 ms içinde yanıt veriyorsa, Googlebot eşzamanlı bağlantı sayısını (parallel connections) otomatik olarak artırır ve aynı sürede 10 kat daha fazla sayfa tarar.
• Sunucu Hataları (5xx ve Zaman Aşımları): Tarama sırasında 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable veya bağlantı zaman aşımı (Timeout) hataları artarsa Googlebot sunucunun zorlandığını varsayarak tarama hızını anında kısar.

2. Tarama Talebi (Crawl Demand)

Sunucunuz çok hızlı olsa bile Googlebot’un sitenizi ne kadar sık ziyaret etmek isteyeceği tarama talebine bağlıdır:

• Algılanan Önem ve Otorite (Popülerlik): İç ve dış bağlantılarla (Internal & External Links) güçlü şekilde beslenen URL’ler, yetim (orphan) sayfalara göre çok daha sık taranır.
• Bayatlama (Staleness) ve Güncellenme Sıklığı: Düzenli olarak teknik içerik üretilen ve gerçekten güncellenen sayfalar, yıllarca hiç değişmeyen sayfalara kıyasla öncelikli tarama kuyruğuna alınır.

Tarama Bütçesini Tüketen 7 Kritik Hata ve Mühendislik Çözümleri

Kurumsal web sitelerinde yapılan teknik SEO denetimlerinde tarama bütçesini sessizce eriten başlıca mimari hatalar ve bunların kalıcı çözüm yöntemleri aşağıdaki tabloda özetlenmiştir:

İsraf Nedeni	Nasıl Oluşur?	Arama Motoru Üzerindeki Etkisi	Kalıcı Mühendislik Çözümü
Yavaş Sunucu Yanıtı (TTFB)	Ağır PHP eklentileri ve optimize edilmemiş MySQL sorguları	Googlebot paralel bağlantı limitini düşürür, tarama hızı çakılır	Astro SSG (Statik Site Üretimi) ile TTFB süresini 50 ms altına indirmek
Yönlendirme Zincirleri (Redirect Chains)	A -> B -> C -> D şeklinde peş peşe eklenen 301/302 kuralları	Her sıçrama ayrı bir tarama isteği harcar; 5 sıçramadan sonra bot vazgeçer	.htaccess üzerinde tüm zincirleri tek adımlı (A -> D) doğrudan hedefe bağlamak
Faceted / Parametreli URL Çöplüğü	?renk=mavi&sira=fiyat&sayfa=2 gibi sonsuz filtre kombinasyonları	Binlerce kopya URL oluşur (Spider Trap); gerçek sayfalar taranamaz	Filtre parametrelerini robots.txt ile kapatmak veya History API kullanmak
Soft 404 (Yumuşak 404) Sayfaları	Bulunamayan ürün sayfasının 200 OK koduyla “Ürün yok” demesi	Bot sayfayı geçerli sanıp tekrar tekrar taramaya devam eder	Gerçekten var olmayan içeriklerde kesinlikle 404 veya 410 Gone döndürmek
Kırık İç Linkler (404 Hataları)	Silinen veya adresi değişen sayfaların menü ve yazılarda unutulması	Tarama bütçesi ölü uçlarda harcanır ve iç PageRank akışı kesilir	Derleme anında otomatik link denetimi (denetim.mjs) ile kırık linkleri sıfırlamak
Kopya ve Zayıf İçerikler (Thin Content)	Etiket (Tag) arşivleri, yazar arşivleri ve 50 kelimelik boş sayfalar	Dizin kalitesi düşer, önemli hizmet sayfalarının taranma sıklığı azalır	Etiket/arşiv çöplüğünü kaldırmak, içerikleri birleştirip derinleştirmek
Kırpılmamış CSS/JS ve Harici Kaynaklar	Taramayı engelleyen bozuk scriptler ve ağır medya dosyaları	Google Web Rendering Service (WRS) aşamasında kuyruk tıkanıklığı yaşanır	Sıfır gereksiz JS mimarisi ve optimize edilmiş statik varlık sunumu

robots.txt, Meta Noindex ve Canonical Etiketlerinin Doğru Kullanımı

Saha uygulamalarında en sık karıştırılan konuların başında robots.txt engellemesi ile <meta name="robots" content="noindex"> ve <link rel="canonical"> etiketlerinin tarama bütçesine etkisi gelir. Bu üç mekanizma tamamen farklı katmanlarda çalışır:

1. Profesyonel robots.txt Yapılandırması (Tarama Öncesi Kapı)

robots.txt dosyası, Googlebot bir URL’ye hiç istek atmadan önce kontrol ettiği ilk kural setidir. Dolayısıyla tarama bütçesini doğrudan koruyan asıl araç robots.txt dosyasıdır. Arama motoru örümceklerine sitenizin taranmaması gereken yönetim panellerini, iç arama sonuçlarını ve geçici API uç noktalarını net bir şekilde bildirmelisiniz:

User-agent: *
Disallow: /api/
Disallow: /yonetim/
Disallow: /arama?*
Disallow: /*?utm_*
Disallow: /*?fbclid=*
Disallow: /*&siralama=*

Sitemap: https://www.maysayazilim.com/sitemap-index.xml

Kritik Uyarı: CSS ve JavaScript dosyalarınızı (/assets/, /_astro/, /styles/) asla robots.txt içinde Disallow etmeyin. Googlebot, sayfanın mobil uyumluluğunu ve düzenini anlamak için CSS/JS dosyalarını okuyabilmelidir.

2. Neden “Noindex” Tarama Bütçesini Tek Başına Kurtarmaz?

Bir sayfaya noindex etiketi koyduğunuzda, Googlebot o etiketi okuyabilmek için sayfayı önce indirmek ve taramak zorundadır. Eğer sitenizde 50.000 adet parametreli filtre sayfası varsa ve bunlara sadece noindex koyduysanız, Googlebot yine de bu 50.000 sayfayı tarayarak bütçenizi tüketir. Bu nedenle zaten dizinde (indekste) olmayan sonsuz parametre kombinasyonları robots.txt ile engellenmeli; yanlışlıkla dizine girmiş sayfalar ise önce noindex ile dizinden düşürülüp ardından robots.txt ile kapatılmalıdır.

HTTP Durum Kodları, ETag / 304 Not Modified ve XML Site Haritası Mühendisliği

Sunucu seviyesinde yapılan HTTP başlık (Header) optimizasyonları, Googlebot’un bant genişliğini ve tarama kapasitesini doğrudan rahatlatır:

• HTTP 304 Not Modified Desteği: Sunucunuzda ETag ve Last-Modified yanıt başlıkları doğru yapılandırıldığında, Googlebot daha önce taradığı bir sayfayı tekrar ziyaret ederken If-Modified-Since başlığı gönderir. Sayfa içeriği değişmemişse sunucu gövdeyi tekrar göndermek yerine 304 Not Modified döner; böylece tarama bütçesi harcanmadan bir sonraki sayfaya geçilir.
• HTTP 410 Gone Kullanımı: Kalıcı olarak kaldırılan ve yerine muadili gelmeyecek eski kampanya veya üretimden kalkmış ürün sayfalarında 404 yerine 410 Gone durum kodu döndürmek, Googlebot’a “Bu URL kalıcı olarak silindi, bir daha kontrol etme” mesajını verir ve URL’nin tarama kuyruğundan çok daha hızlı düşmesini sağlar.
• XML Sitemap Disiplini: sitemap.xml dosyanızda yalnızca 200 OK döndüren, kanonik (canonical) ve dizine eklenebilir temiz URL’ler yer almalıdır. Site haritasının içinde 301 yönlendirmeli, 404 hatalı veya noindex etiketli URL’lerin bulunması Google’ın site haritanıza olan güvenini sarsar.

Sunucu Erişim Logları (Access Logs) Analizi ile Gerçek Zamanlı Googlebot Takibi

Google Search Console içindeki “Tarama İstatistikleri” (Crawl Stats) raporu yararlı bir özet sunsa da örnekleme yapar ve birkaç gün geriden gelebilir. Büyük ölçekli projelerde ve Özel Yazılım Geliştirme altyapılarında Googlebot’un sitenizdeki gerçek davranışını milisaniye bazında görmek için web sunucusu erişim logları (Apache/Nginx Access Logs) doğrudan analiz edilmelidir:

1. Sahte Googlebot Tespiti (Reverse DNS Doğrulaması): Kendini User-Agent: Googlebot olarak tanıtan kazıyıcı botları (scrapers) gerçek Googlebot’tan ayırmak için IP adresine ters DNS sorgusu (host <IP>) yapılır, dönen alan adının .googlebot.com veya .google.com ile bittiği ve ileri DNS sorgusunda aynı IP’ye çözüldüğü doğrulanır.
2. Yetim (Orphan) ve Az Taranan Sayfaların Keşfi: Site haritasındaki tüm URL listesi ile son 30 günlük Googlebot logları karşılaştırılır (Cross-check). Son 30 günde hiç Googlebot ziyareti almamış hizmet veya ürün sayfaları tespit edilerek yüksek otoriteli ana sayfalardan bağlamsal iç linklerle beslenir.
3. Altyapı ve Yedekleme Entegrasyonu: Log dosyalarının güvenli bir şekilde saklanması, hem SEO analizi hem de Ortak Dosya Sunucusu ve Yedekleme ile sistem izleme standartları açısından kritik veri sağlar. Aynı şekilde üretim verilerini web kataloglarına aktaran Özel ERP & CRM ve İmalat Çözümleri entegrasyonlarında da temiz URL üretimi bu loglarla denetlenir.

Arama motorlarının kurumsal web sitenizi saniyeler içinde sıfır hatayla taraması, tüm hizmet sayfalarınızın hızla dizine eklenmesi ve rakiplerinizin önüne geçmesi için Kurumsal Web Tasarım ve SEO Çözümleri sayfamızdan mühendislik ekibimizle iletişime geçebilirsiniz.

Sıkça Sorulan Sorular

Küçük ve orta ölçekli kurumsal web sitelerinde de tarama bütçesi (Crawl Budget) önemli midir?

Google resmi olarak birkaç bin URL’nin altındaki sitelerin genellikle tarama bütçesi sorunu yaşamayacağını belirtse de, yanlış yapılandırılmış bir CMS veya filtreleme sistemi 50 sayfalık bir kurumsal sitede bile on binlerce parametreli kopya URL (?replytocom=, ?s=, takvim arşivleri, kırık yönlendirme döngüleri) üretebilir. Ayrıca yavaş sunucu yanıt süresi (yüksek TTFB) küçük sitelerde dahi yeni yayınlanan bir blog yazısının veya hizmet sayfasının günlerce dizine eklenmemesine (Keşfedildi - şu anda dizine eklenmedi hatasına) yol açar.

Google Search Console’da “Tarandı - şu anda dizine eklenmedi” uyarısı nasıl çözülür?

Bu uyarı, Googlebot’un sayfayı taradığını ancak sayfanın içerik derinliğini, özgünlüğünü veya site içi otoritesini dizine eklemeye değer bulmadığını gösterir. Çözüm için sayfadaki zayıf içerik (thin content) kapsamlı teknik bilgiler, tablolar ve sıkça sorulan sorularla zenginleştirilmeli; benzer konudaki yüksek trafikli sayfalardan bu sayfaya açıklayıcı çapa metinleriyle (anchor text) gövde içi linkler verilmeli ve sayfanın kanonik adresinin doğru olduğu doğrulanmalıdır.

Site haritasındaki (sitemap.xml) tüm sayfaların lastmod tarihini her gün bugünün tarihi yapmak doğru mudur?

Hayır, bu işlem kesinlikle yapılmamalıdır. Sayfa içeriğinde gerçek ve anlamlı bir değişiklik olmadığı halde lastmod tarihini yapay olarak sürekli güncelleyen siteler Google algoritması tarafından kısa sürede fark edilir ve arama motoru o sitenin lastmod sinyallerini tamamen yok saymaya başlar. lastmod alanı yalnızca sayfa metni, teknik verileri veya şeması gerçekten güncellendiğinde değiştirilmelidir.