Sunucu Log Analizi Tarama Bütçesi İsrafını Nasıl Ortaya Çıkarır?

Tarama Bütçesi Nedir ve Neden Yalnızca Log Dosyası Gerçeği Ortaya Koyar?

Tarama bütçesi terimini sözlüğümüzde tanımladığımız gibi, crawl budget, Google’ın belirli bir zaman diliminde bir siteye tahsis ettiği tarama kapasitesidir. Bu kapasite iki bileşen tarafından şekillenir: sitenin PageRank dağılımından kaynaklanan crawl demand ve sunucu yanıt hızıyla doğrudan bağlantılı crawl capacity limit. Otorite düşük, sunucu yavaş ya da hata oranı yüksekse Google bu siteye daha az tarama kapasitesi ayırır; büyük sitelerde bu durum kritik sayfaların günlerce indeks dışı kalmasına yol açar.

Büyük e-ticaret siteleri ve haber portalları bu sorunu en ağır biçimde yaşar. Yüz binlerce URL’ye sahip bir e-ticaret sitesinde Googlebot’un kısıtlı bütçesini parametreli filtre URL’leri harcıyorsa, yeni ürün sayfaları haftalarca arama sonuçlarında görünmeyebilir. Google Search Console (GSC) Crawl Stats raporu 2025’te daha ayrıntılı bot segmentasyonu sunacak şekilde güncellendi; ancak temel kısıtlaması değişmedi: GSC veriyi örnekleyerek gösterir. Sunucu log dosyası ise Googlebot’un her isteğini ham formatta, örnekleme yapmadan kaydeder. Bu yapısal fark, tarama bütçesi sorunlarının gerçek boyutunu yalnızca log dosyasının ortaya çıkarabileceği anlamına gelir.

2026 itibarıyla tabloya yeni bir değişken eklendi: GPTBot, Claude-Web ve PerplexityBot gibi AI crawler’lar artık sunucu loglarında düzenli olarak görünüyor. Bu botların tarama faaliyeti hem sunucu kapasitesini Googlebot ile paylaşıyor hem de AI görünürlük analizine etkileri açısından ayrıca izlenmesi gereken bağımsız bir boyut oluşturuyor. Güncel bir log analizi artık yalnızca Googlebot’u değil, tüm kritik crawler’ları kapsamalıdır.

Log Dosyasına Nasıl Erişilir: Apache, Nginx ve CDN (Cloudflare, Fastly) Adım Adım

Sunucu log dosyasına erişim yöntemi, altyapı türüne göre farklılık gösterir. Apache kullanan sunucularda access log varsayılan olarak /var/log/apache2/access.log (Debian/Ubuntu) veya /var/log/httpd/access_log (CentOS/RHEL) dizininde bulunur. Combined log formatı aktifse her satır IP adresi, zaman damgası, HTTP metodu, istek URL’si, durum kodu, yanıt byte boyutu, referrer ve user-agent bilgisini içerir. Son 30 günlük veriyi scp ya da wget komutuyla yerel ortama indirmek analiz hızını artırır.

Nginx için log formatı nginx.conf dosyasındaki log_format direktifiyle belirlenir. Günlük rotasyon sonucu oluşan access.log.1 ve access.log.2.gz gibi dosyalar birleştirilmelidir. Gzip arşivleri zcat komutuyla açılarak tek bir combined log dosyasında toplanabilir.

CDN kullanan siteler için süreç farklıdır. Cloudflare Enterprise planı, Log Push özelliğiyle logları Amazon S3 veya Google Cloud Storage gibi bir hedefe aktarır. Fastly ise Real-Time Log Streaming ile anlık log akışı sunar. Her iki çözümde de loglar periyodik olarak depolanır; analiz aracına yüklenmeden önce birleştirilmesi gerekir.

Boyut yönetimi kritik bir pratik sorundur: orta ölçekli bir sitede 30 günlük log dosyası kolayca 5-20 GB’a ulaşır. Belirli bir tarih aralığına odaklanmak için awk komutuyla yalnızca ilgili günlere ait satırlar çekilebilir. Analizi doğrudan sunucuda veya yeterli RAM’e sahip bir makinede yapmak gereksiz veri aktarımını önler.

Googlebot’u Log’dan Filtreleyerek Okuma: User-Agent, HTTP Kodu ve Timestamp Analizi

Log dosyasından Googlebot aktivitesini ayıklamak için temel komut grep -i "Googlebot" access.log şeklindedir. Ancak sahte Googlebot IP’leri analiz güvenilirliğini tehdit eder. Gerçek Googlebot’u doğrulamak için DNS ters çözümü (host [IP_adresi]) yapın; sonucun googlebot.com ya da google.com ile bitmesi ve aynı IP’ye geri çözümlenmesi gerekir. Screaming Frog’un resmi Log File Analyser dokümantasyonuna göre bu doğrulama adımı analiz güvenilirliğini doğrudan etkiler.

Log satırının alanlarını doğru yorumlamak analiz kalitesini belirler. Combined log formatındaki standart alan sırası: birinci alan IP adresi, dördüncü alan [DD/Mon/YYYY:HH:MM:SS +zone] formatında zaman damgası, yedinci alan istek URL’si, dokuzuncu alan HTTP durum kodu ve onuncu alan yanıt byte boyutu. Googlebot-Desktop ile Googlebot-Mobile’ı ayrı ayrı analiz etmek, mobil öncelikli indeksleme ortamında hangi sayfaların hangi bot versiyonuyla tarandığını netleştirir.

HTTP durum kodları tarama bütçesini üç farklı mekanizmayla etkiler:

• 3xx yönlendirme zincirleri: Googlebot her hop için ayrı bir istek yapar. İki veya daha fazla hoplı zincirler bütçeyi katlar; üç ya da daha uzun zincirlerde Googlebot nihai URL’ye hiç ulaşamayabilir.
• 4xx hataları (crawl drain): 404 ve 410 gibi hata kodları Googlebot’un mevcut olmayan URL’leri tekrar tekrar ziyaret etmesine yol açar; bu etki düşük otorite siteler için orantısız biçimde büyür.
• 5xx sunucu hataları (crawl back-off): Google tekrarlayan sunucu hatalarında tarama sıklığını otomatik olarak azaltır. Sorun giderildikten sonra eski tarama frekansına dönmek haftalar alabilir; bu nedenle 5xx hataları log’da görülür görülmez öncelikli müdahale gerektirir.

Robots.txt ile Disallow edilen URL’lerin log’da Googlebot tarafından ziyaret edilmeye devam ettiği görülür. Bu, Googlebot’un tasarım gereği davranışıdır: bot URL’yi tarar ancak içeriği dizine eklemez. Yine de bu ziyaretler tarama bütçesinden pay alır; disallow listesindeki URL’lerin gerçekten düşük değerli olduğundan emin olmak bu nedenle önemlidir.

3 Sektörden Gerçek Veri: Hangi URL Kategorisi Tarama Bütçenizin Kaçını Tüketiyor?

Farklı sektörlerdeki teknik SEO projelerinden derlenen bulgular, URL kategorisi bazındaki crawl waste dağılımını somutlaştırıyor. Medyatics’in crawl budget optimizasyonu rehberinde ve Stratejik SEO’nun log analizi kaynağında da bağımsız olarak doğrulanan bu örüntüler sektöre göre farklılaşır; ancak temel israf kaynakları ortaktır.

E-ticaret sitelerinde filtre ve facet URL’leri en büyük crawl waste kaynağıdır. Renk, beden, fiyat aralığı ve sıralama parametrelerinin kombinasyonu, aynı ürün grubu için yüzlerce varyant URL oluşturur. Log analizinde bu URL’lerin toplam Googlebot isteklerinin %35-50’sini oluşturduğu gözlemleniyor. Robots.txt ve canonical optimizasyonu sonrasında aynı bütçeyle ulaşılan ürün ve kategori sayfası sayısında belirgin artış ölçülüyor; bu iyileşme indeksleme oranına doğrudan yansıyor.

Haber sitelerinde yıllık arşiv URL’leri ve derin pagination zincirleri Googlebot’un günlük tarama kapasitesinin önemli bir bölümünü tüketir. Yüzlerce sayfalık arşiv dizinleri için noindex direktifi uygulandıktan sonra güncel haber sayfalarının tarama frekansında belirgin iyileşme gözlemleniyor; bu etki büyük haber portallarında daha belirgindir.

Kurumsal sitelerde oturum ID’li URL’ler ve UTM parametreli iç linkler Googlebot’a aynı içeriğin yüzlerce farklı versiyonu olarak görünür. Her bir varyasyon ayrı bir URL olarak taranır ve değerli sayfalar için harcanması gereken bütçeyi eritir. Kapsamlı bir canonical stratejisi bu israfı önemli ölçüde keser.

Tüm sektörlerde ortak sorun olan yetim sayfalar (orphan pages), log’da ya çok seyrek ya da hiç görünmez. İç link almayan bu sayfalar, Googlebot’un organik tarama yoluyla ulaşamadığı değerli içerikler barındırabilir. 301/302 yönlendirme zincirleri de tüm sektörlerde süregelen bir sorun oluşturuyor: her ek hop Googlebot’a ekstra istek maliyeti yükler ve nihai URL’ye ulaşmayı geciktirir ya da tamamen engeller.

Log Analizi Araçları Karşılaştırması: Screaming Frog, JetOctopus, Botify ve SEOYEN

Screaming Frog Log File Analyser, küçük ve orta ölçekli log dosyaları için sektörün yaygın masaüstü aracıdır. Log dosyasını sürükle-bırak yöntemiyle yükledikten sonra User Agents filtresinden Googlebot’u seçin; URL grup dağılımı, HTTP durum kodu grafiği ve tarama sıklığı raporu otomatik olarak oluşur. Googlebot-Desktop ile Googlebot-Mobile ayrımı, mobil öncelikli indeksleme bağlamında kritik bir analiz boyutu sunar. Araç GBP bazlı yıllık fiyatlandırmasıyla Türkiye pazarında döviz kuru etkisine açıktır.

JetOctopus ve Botify, 2025 itibarıyla AI destekli anomali tespiti özellikleri ekledi. Milyonlarca satırlık log dosyalarını otomatik segmentlere ayıran ve beklenmedik tarama artışlarını anlık tespit eden bu araçlar, kurumsal ölçekteki operasyonlar için güçlü bir seçenek oluşturuyor. Dolar bazlı fiyatlandırmaları ve İngilizce arayüzleri, Türkiye pazarındaki KOBİ’ler ve serbest çalışan SEO uzmanları için hem maliyet hem de öğrenme eğrisi açısından ek yük anlamına geliyor.

Ücretsiz alternatifler arasında GoAccess, terminal üzerinde saniyeler içinde özet rapor üretir. Python/pandas kombinasyonu ise regex tabanlı URL segmentasyonu ve özelleştirilmiş crawl waste hesaplamaları için esneklik sağlar; küçük log dosyalarında bu araçlar çoğunlukla yeterlidir.

Teknik SEO sürecinizde crawl sorunlarını sistematik biçimde takip etmek için site sağlığı aracıyla tarama sorunlarını tespit edebilirsiniz. SEOYEN, Türkçe arayüzü, TL bazlı fiyatlandırması ve Türkçe yerel desteğiyle dolar ya da sterlin kuru baskısı olmadan teknik SEO sürecinizi yönetmek isteyen ekiplere anlamlı bir seçenek sunuyor. SEOYEN fiyat ve abonelik seçenekleri için fiyatlandırma sayfasını inceleyebilirsiniz.

Bulgulardan Aksiyon Planı: Robots.txt, Noindex ve İç Link ile Bütçeyi Kurtarma

Log analizi verisi aksiyona dönüştürülmediğinde değer üretmez. Bulgulardan elde edilen israf kategorileri aşağıdaki öncelik matrisine göre sıralanır; her biri için farklı bir müdahale yöntemi uygulanır:

1. 3xx yönlendirme zincirlerini kısaltın: Tüm ara yönlendirmeleri kaldırarak kaynak URL’yi doğrudan nihai hedefe yönlendirin. Her ek hop Googlebot’a gereksiz istek maliyeti yükler.
2. 4xx hataları için seçici aksiyon alın: Geri bağlantı alan 404 URL’lerini 301 ile çalışan bir sayfaya yönlendirin. Bağlantısız 404’ler için robots.txt erişim kısıtlaması yeterlidir.
3. Parametreli URL’ler ve filtre sayfaları: Robots.txt’e Disallow: /*?sessionid= gibi şablonlar ekleyin. Canonical etiketini parametre içeren URL’lerden temiz versiyona yönlendirin.
4. Noindex ile bütçe boşaltın: Arşiv, pagination ve etiket sayfaları için noindex direktifi Googlebot kapasitesini değerli içeriklere serbest bırakır; canonical etiketiyle birlikte daha etkili sonuç verir.
5. İç linklemeyle yetim sayfaları kurtarın: Pillar page ve kategori sayfalarından kritik yetim sayfalara link ekleyin; böylece Googlebot bu sayfalara düzenli olarak ulaşır.

Sıralama takibini log analiziyle birlikte yürütmek, optimizasyon sonrasındaki etkiyi SERP’te somut biçimde ölçmenizi sağlar. Robots.txt ve noindex değişikliklerinin indeksleme üzerindeki etkisi genellikle 4-6 haftada netleşir; bu sürenin ardından yeni log dönemi çekilerek Googlebot’un URL dağılımındaki iyileşme doğrulanmalıdır.

Stratejik SEO’nun Googlebot tarama optimizasyonu araştırmasına göre aylık rutin log analizi, sorunların erken tespiti için yeterli bir frekanstır. Ancak Google core update, büyük yapısal site değişikliği veya organik trafik düşüşü yaşandığında acil analiz protokolü devreye alınmalı; bu senaryolarda birkaç günlük log verisi bile sorunun kaynağını işaret eder.

Sıkça Sorulan Sorular