Log dosyası analizi ile Googlebot tarama davranışı nasıl yorumlanır?

Log dosyası nedir ve Googlebot tarama verisi nasıl elde edilir?

Sunucu log dosyaları, web sunucunuzun aldığı her HTTP isteğinin ham ve filtresiz kaydıdır. Google Search Console’dan farklı olarak örnekleme yapmaz; Googlebot dahil tüm botların hangi URL’leri ne zaman, hangi HTTP durum koduyla istediğini satır satır yansıtır. Crawl budget israfını, ihmal edilen sayfaları ve sahte bot trafiğini tespit etmenin yegâne güvenilir kaynağıdır.

Apache sunucularda log dosyasına SSH üzerinden tail -f /var/log/apache2/access.log komutuyla, Nginx’te /var/log/nginx/access.log yoluyla erişilir. cPanel kullanan hosting hesaplarında Raw Access Logs menüsünden .gz formatında indirme yapılır; Plesk’te ise Logs sekmesinden tarih aralığı seçilerek dosya elde edilir. Cloudflare veya Fastly kullanan sitelerde ham log verisi CDN log API’si veya log push hizmetinden alınır.

Sıkıştırılmış log dosyaları gzip -d access.log.gz komutuyla açılır. 1 GB üzerindeki büyük dosyalarda tüm dosyayı açmak yerine doğrudan grep ile filtreleme yapılması önerilir. Analiz etmek istediğiniz tarih aralığını belirlemek için head -1 ve tail -1 komutlarıyla ilk ve son satır tarihlerini kontrol edin.

Log satırının anatomisi şu alanlardan oluşur: IP adresi, kimlik doğrulama bilgileri, tarih-saat, HTTP metodu ve URL, durum kodu, yanıt boyutu ve user-agent. Bu kavramların SEO açısından ne anlama geldiğini kavramak için teknik SEO terimler sözlüğündeki crawl budget ve log analizi maddelerine başvurabilirsiniz.

Log satırlarını okuma: Googlebot user-agent filtreleme ve IP doğrulama

Googlebot tek bir user-agent string kullanmaz; tarama amacına göre farklı varyantlar gönderir. Log analizinin ilk adımı bu varyantların tamamını doğru biçimde filtrelemektir:

• Googlebot (Smartphone): Mobil öncelikli indeksleme için kullanılır; Android Nexus emülasyonu içeren user-agent string’iyle gelir.
• Googlebot (Desktop): Klasik masaüstü tarayıcısı; Googlebot/2.1 string’ini içerir.
• AdsBot-Google: Reklam açılış sayfalarını kalite değerlendirmesi için tarar; genel crawl budget hesabına dahildir.
• Feedfetcher-Google: RSS ve Atom feed’lerini okur; crawl budget hesabına dahil edilmez.

Tüm Googlebot varyantlarını filtrelemek için grep -iE ‘googlebot|adsbot-google|feedfetcher-google’ access.log komutunu kullanın; çıktıyı ayrı bir dosyaya yönlendirerek sonraki analiz adımlarını hızlandırın.

Sahte Googlebot tespiti: Log’da Googlebot user-agent’ını taklit eden sahte botlar mevcuttur. Google Search Central belgelerine göre gerçek Googlebot’u doğrulamanın tek yöntemi ters DNS (rDNS) ve ileri DNS (fDNS) çift kontrolüdür. Önce host [IP_ADRESI] komutuyla ters DNS sorgusu yapılır; dönen hostname googlebot.com veya google.com ile bitmiyorsa bu istek gerçek Googlebot değildir. Ardından dönen hostname üzerinden ileri DNS sorgusuyla elde edilen IP’nin orijinal IP ile eşleştiği teyit edilir.

Büyük log dosyalarında her satır için tek tek rDNS kontrolü yapmak yerine awk ‘{print $1}’ googlebot_filtered.log | sort -u komutuyla tekil IP listesi çıkarın ve bu liste üzerinde toplu doğrulama yapın. Sahte IP’leri temizlenmiş log’dan elemek, crawl budget hesaplamalarının güvenilirliğini doğrudan artırır.

HTTP durum kodları log’da ne anlatır? Tarama bütçesine etkisi

Log’daki HTTP durum kodları, Googlebot’un zamanını nereye harcadığını ve hangi URL’lerin indeksleme değeri taşıdığını doğrudan gösterir. Google, Aralık 2024 Crawling December blog serisiyle crawl capacity limit parametrelerini güncelledi; büyük siteler için sunucu yanıt hızının tarama sıklığını doğrudan etkilediği bu belgelerle resmiyet kazandı.

• 200 (OK): Hedef sonuç; ancak içerik boş veya anlamsızsa soft-404 riski taşır — log bunu tek başına ayırt edemez.
• 301 (Kalıcı Yönlendirme): Tek adımlı yönlendirme tarama bütçesini minimum düzeyde etkiler. Zincirleme 301’ler her geçiş için ek istek oluşturarak bütçeyi tüketir.
• 302 (Geçici Yönlendirme): Google geçici olarak kabul eder; orijinal URL indekslemeye devam edebilir ve kalıcı yönlendirmelerden daha fazla crawl bütçesi harcar.
• 404 (Bulunamadı): Googlebot tekrar tekrar 404 URL’e istek gönderirse bütçe israf edilir. 410 (Gone) kodu kullanmak Googlebot’un bu URL’yi çok daha hızlı erişilemez olarak işaretlemesini sağlar.
• 500 (Sunucu Hatası): Art arda gelen 5xx hataları Googlebot’un tarama hızını otomatik düşürür; uzun süreli 500 hataları crawl capacity limit’i ciddi ölçüde zorlar.

Log’daki durum kodu dağılımını hızla görmek için awk ‘{print $9}’ googlebot_filtered.log | sort | uniq -c | sort -rn komutunu kullanın. Bu çıktı hangi durum kodunun kaç kez döndüğünü büyükten küçüğe sıralar; 4xx ve 5xx oranları tarama sağlığının birincil göstergesidir.

Soft-404 uyarısı: Sunucu 200 döndürse de sayfa içeriği anlamsızsa — silinmiş ürün, boş kategori — log bu durumu tek başına tespit edemez. Google Search Console Kapsam raporu ile çapraz kontrol zorunludur; başka sayfayla yinelenen uyarısı taşıyan URL’lerin log’daki 200 satırlarıyla eşleştirilmesi gerekir.

Gerçek e-ticaret denetimi: parametre URL’ler crawl budget’ın %40’ını nasıl tüketti?

Üç aylık bir e-ticaret sitesi teknik SEO denetiminde Google Search Console Crawl Stats ile ham access.log verisi yan yana karşılaştırıldığında kritik bir açık ortaya çıktı: GSC günlük yaklaşık 1.200 URL tarandığını gösterirken, aynı dönemin log dosyası 1.800’ün üzerinde tekil URL isteği içeriyordu. Bu farkın kaynağı GSC’nin raporlamadığı filtre parametre URL’leriydi; renk, beden ve sıralama parametrelerinin kombinasyonundan oluşan bu URL’ler toplam Googlebot isteğinin yaklaşık %40’ını oluşturuyordu. Oysa bu sayfaların hiçbiri arama sonuçlarında organik değer üretmiyordu.

robots.txt’e uygun Disallow kuralı eklenmesi ve stratejik parametreler için canonical etiketi uygulanmasının ardından ürün ve kategori sayfalarına ayrılan tarama bütçesi iki haftada belirgin biçimde arttı. Optimizasyon öncesinde kategori sayfaları günlük Googlebot isteğinin yalnızca %20’sini alırken, müdahale sonrasında bu pay %35’e yükseldi; benzer iyileşme ürün sayfalarında da gözlemlendi.

Orphan page tespiti: Log’da hiç görünmeyen veya ayda yalnızca birkaç kez taranan kategori sayfaları, Googlebot’un düşük değerli ya da erişilemez bulduğu içeriklerin işaretidir. Bu sayfaların internal link profilini güçlendirmek ve XML sitemap’e eklemek tarama önceliğini artırmanın en doğrudan yoludur. GSC Crawl Stats ile log verisi arasındaki uçurumu sistematik biçimde kapatmak için site sağlığı denetimi aracını teknik SEO iş akışınıza entegre edebilirsiniz.

Log analizi araçları karşılaştırması: Screaming Frog, GoAccess ve ELK Stack

Log analizi için araç seçimi site büyüklüğüne, teknik altyapıya ve bütçeye göre değişir. 2026 itibarıyla üç araç öne çıkmaktadır; ayrıntılı karşılaştırmayı aşağıdaki tabloda bulabilirsiniz.

Screaming Frog Log Analyser GUI tabanlı, kurulumu dakikalar içinde tamamlanan bir araçtır. Googlebot ve diğer botları görsel olarak filtreleyip raporlar; teknik SEO bilgisi sınırlı ekipler için uygun bir başlangıç noktasıdır. Sınırlılıkları: 1 GB üzeri log dosyalarında performans düşer ve yıllık lisans maliyeti orta büyüklükteki ekipler için göz önünde bulundurulmalıdır.

GoAccess ücretsiz ve açık kaynaklıdır. Terminal tabanlı çalışmasına rağmen tek komutla interaktif HTML dashboard oluşturabilir; 1 GB üzeri log dosyalarında belirgin performans avantajı sunar. Sunucu başında çalışan teknik ekipler için ideal seçenektir.

ELK Stack (Elasticsearch-Logstash-Kibana) çok sunuculu ve kurumsal ölçekteki log yönetimi için uygundur. Logstash pipeline konfigürasyonu ve Elasticsearch cluster yönetimi deneyim gerektirir; öğrenme eğrisi ve altyapı maliyeti yalnızca büyük ölçekli operasyonlarda anlamlı bir yatırıma dönüşür.

SEOYEN site sağlığı denetimi aracı bu araçları tamamlar: kırık bağlantılar, yavaş sayfalar, canonical hataları ve indeksleme sorunları tek Türkçe arayüzden, TL bazlı fiyatlandırmayla takip edilebilir. Ham crawl verisini log araçlarıyla sunucu tarafında analiz ederken, teknik SEO durumunu SEOYEN ile eş zamanlı izlemek en bütünleşik yaklaşımı oluşturur.

AI botlarını (GPTBot, ClaudeBot, PerplexityBot) Googlebot’tan ayırt etme ve 2026 tarama önceliği planı

Cloudflare’ın 66 milyar bot isteğine dayalı 2025 analizine göre AI tarayıcılarının web trafiğindeki payı dramatik biçimde artmıştır; GPT-5’in piyasaya çıkmasının ardından OpenAI tarama aktivitesi yaklaşık 3 katına çıktı. Bu gelişme, büyük sitelerin crawl budget planlamasında AI botlarını Googlebot’tan ayrıştırmayı zorunlu bir adım hâline getirmiştir. Search Engine Land’in 2025 analizine göre bu trafiği yönetemeyen siteler hem crawl budget israfıyla hem de robots.txt ihlalleriyle karşı karşıyadır.

2026 itibarıyla izlenmesi gereken temel AI bot user-agent string’leri şunlardır:

• GPTBot/1.0 — OpenAI’nin içerik toplama tarayıcısı
• ClaudeBot/1.0 — Anthropic’in web tarayıcısı
• PerplexityBot/1.0 — Perplexity AI arama motoru tarayıcısı
• Google-Extended — Google’ın AI model eğitimi için kullandığı ayrı bot kimliği
• CCBot/2.0 — Common Crawl; LLM eğitim verisi toplayan açık havuz

Log’da AI botlarını Googlebot’tan ayrıştırmak için grep -iE ‘gptbot|claudebot|perplexitybot|google-extended’ access.log komutuyla ayrı bir filtreleme yapın. Ardından her iki log’daki günlük istek sayısını karşılaştırarak AI bot trafik payını hesaplayın; bu oran zaman içinde izlendiğinde GPT-5 sonrası dönemin crawl budget üzerindeki etkisi net biçimde görülür.

robots.txt’e Disallow kuralı eklediğiniz URL’lerin AI botlar tarafından gerçekten ziyaret edilip edilmediğini yalnızca log analizi doğrulayabilir. CCBot gibi bazı tarayıcılar robots.txt kurallarına uymayabilir; bu durumda sunucu tarafı IP engeli veya WAF kuralı gerekebilir. Yapay zeka görünürlük analizi aracıyla LLM botlarının sitenizi nasıl gördüğünü ve hangi içeriğinizin AI özetlerine yansıdığını takip edebilirsiniz.

Log verisinden tarama önceliği planı oluşturmak için URL gruplarını segmentleyin: kritik ürün ve kategori sayfaları günde birden az taranıyorsa internal link yapısını güçlendirin ve XML sitemap’i güncelleyin; parametre URL’leri ve session ID’leri robots.txt veya canonical ile sınırlandırın. Sıralama takibi verileriyle crawl budget optimizasyonunuzu ilişkilendirerek hangi URL gruplarının tarama artışından organik kazanım sağladığını doğrudan ölçebilirsiniz.

Adım Adım: Log Dosyası Analizi ile Googlebot Tarama Davranışını Yorumlama

1. Log dosyasını edinin ve hazırlayın: SSH veya cPanel üzerinden Apache ya da Nginx access.log dosyasını indirin; gzip sıkıştırılmışsa açın ve head -1 ile tail -1 komutlarıyla tarih aralığını belirleyin.
2. Googlebot satırlarını user-agent ile filtreleyin: grep -iE komutuyla Googlebot, AdsBot-Google ve Feedfetcher-Google varyantlarını kapsayan pattern uygulayın; çıktıyı ayrı bir dosyaya kaydedin.
3. IP adreslerini rDNS ve fDNS ile doğrulayın: Her Googlebot IP’si için ters DNS sorgusu yapın; dönen hostname googlebot.com veya google.com ile bitmiyorsa sahte bot olarak işaretleyin.
4. HTTP durum kodlarını gruplandırın ve sayın: awk komutuyla 200, 301, 404 ve 500 kodlarının dağılımını çıkarın; yüksek 4xx ve 5xx oranlarını öncelikli müdahale listesine alın.
5. Tarama bütçesi kullanımını URL gruplarına göre hesaplayın: Günlük toplam Googlebot isteği sayısını bulun; kategori, ürün ve parametre URL’lerinin crawl budget’tan aldığı payı hesaplayın.
6. Crawl budget israfı kaynaklarını tespit edin: Parametre URL’leri, yönlendirme zincirleri ve tekrarlanan içeriklerin payını belirleyin; robots.txt veya canonical ile müdahale gereken URL gruplarını listeleyin.
7. AI bot trafiğini Googlebot’tan ayrıştırın: GPTBot, ClaudeBot ve PerplexityBot string’lerini ayrı filtrelerle çekin; robots.txt kurallarının bu botlar tarafından uygulandığını doğrulayın.
8. Aksiyon planı oluşturun ve önceliklendirin: Tespit edilen sorunları etki büyüklüğüne göre sıralayın; robots.txt, canonical ve internal link aksiyonlarını uygulayın; iki hafta sonra log analizi tekrarlayarak iyileşmeyi ölçün.

Sıkça Sorulan Sorular