SEO İÇİN LOG ANALİZİ YAPMAK VE BOT DAVRANIŞINI ÇÖZMEK
Bir web sitesinde “neden indekslenmiyor?” sorusuna çoğu zaman tahminle yanıt verilir: “Sitemap güncel değil”, “iç link zayıf”, “site yavaş”... Oysa arama motorlarının gerçekte ne yaptığını gösteren en güçlü kanıt, sunucu loglarıdır. Loglar, botların hangi URL’lere geldiğini, hangi yanıtları aldığını ve hangi sıklıkla tarama yaptığını çıplak biçimde ortaya koyar.
Search Console değerli bir pencere sunar, fakat sınırlıdır. Log analizi ise doğrudan “bot davranışı” verisidir: tarama bütçesi nereye gidiyor, hangi şablonlar ihmal ediliyor, 3xx zincirleri botu oyalıyor mu, 5xx hataları tarama hızını düşürüyor mu? Bu soruların yanıtı logların içinde saklıdır.
Bu rehberde SEO için log analizi yapmayı uçtan uca ele alacağız: veriyi toplamak, temizlemek, botları doğrulamak, şablon bazında segmentlemek, KPI üretmek ve aksiyona dönüştürmek. Hedef; ölçülebilir bir süreç kurup bot davranışını düzenli izlemektir.
Log analiziyle bot davranışını görünür kılmak
Log analizi, web sunucusuna gelen her isteğin kayıtlarını inceler. Bu kayıtlar genellikle zaman damgası, IP, user-agent, istenen URL, yanıt kodu, yanıt süresi ve referrer gibi alanları içerir. SEO açısından en önemli kazanım, botların siteyi “nasıl deneyimlediğini” gerçek veriye dayanarak görmektir.
Log verisinin SEO’ya kattığı temel faydayı anlamak
Loglar sayesinde, botların taradığı URL’ler ile sizin taranmasını istediğiniz URL’ler arasındaki fark netleşir. Örneğin botlar parametreli URL’lere takılıyorsa tarama bütçesi boşa gider. Ayrıca botların sık ziyaret ettiği sayfalar, iç link ve otorite akışını da dolaylı biçimde yansıtır.
Search Console verisiyle log verisini birlikte kullanmak
Search Console “özet” sunar; loglar ise “ham gerçek”tir. Bir sayfanın tarandığını Search Console’da görmek ile o sayfanın son 30 günde kaç kez tarandığını, hangi yanıt kodlarını aldığını ve botun hangi saatlerde yoğunlaştığını loglardan görmek farklıdır. En iyi yaklaşım, iki kaynağı çapraz doğrulamaktır.
Log verisini toplamak ve analiz için hazırlamak
İyi bir analiz, iyi hazırlanmış veriyle başlar. Log formatı (Nginx, Apache, CDN logları), saklama süresi ve veri erişimi analizin kalitesini belirler. Burada amaç, düzenli ve tekrar edilebilir bir veri hattı kurmaktır.
Hangi log kaynaklarını dahil edeceğinizi belirlemek
Web sunucu logları temel kaynaktır; ancak CDN, WAF ve load balancer logları da değerli olabilir. Özellikle bot trafiği CDN üzerinden geçiyorsa yalnızca origin loglarına bakmak eksik resim verebilir. “Botlar nereden geçiyor?” sorusunu yanıtlayacak kaynakları seçmek gerekir.
Alanları standardize edip tek şemaya dönüştürmek
Farklı kaynaklardan gelen loglar farklı alan adlarıyla gelebilir. Analiz kolaylığı için ortak bir şema oluşturun: timestamp, ip, user_agent, method, url, status, bytes, response_time, referer gibi. Bu standardizasyon, segmentleme ve raporlamayı hızlandırır.
# Örnek Nginx log formatına benzeyen satır
# 2026-02-12T10:41:21Z 66.249.66.1 "GET /kategori/ayakkabi?renk=siyah HTTP/2" 200 53210 0.214 "Googlebot"
Bot doğrulaması yapıp sahte trafikten ayrıştırmak
Log analizi sırasında en kritik adımlardan biri, gerçek botları sahte user-agent kullanan trafikten ayırmaktır. Çünkü “Googlebot” yazan herkes Googlebot değildir. Yanlış ayrıştırma, yanlış kararlar doğurur.
User-agent ile ilk filtreyi uygulamak
İlk aşamada user-agent üzerinden kaba bir filtre yapılabilir: Googlebot, Bingbot, YandexBot gibi. Ancak bu yalnızca bir ön elemedir. Çünkü kötü niyetli botlar user-agent taklit edebilir. Bu nedenle ikinci aşamada IP doğrulaması veya reverse DNS kontrolü planlanmalıdır.
IP ve reverse DNS doğrulaması planlamak
Güvenilir doğrulama, botun IP’sinin ilgili arama motoruna ait olup olmadığını kontrol etmektir. Bu işlem otomasyona bağlanabilir. Her istek için doğrulama yapmak ağır olabilir; örnekleme veya günlük toplu doğrulama yaklaşımı tercih edilebilir.
// Node.js ile basit user-agent filtresi örneği (ham doğrulama değildir)
const isSearchBot = (ua) => /Googlebot|bingbot|YandexBot|DuckDuckBot/i.test(ua);
const rows = [
{ url: "/urun/123", status: 200, ua: "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" },
{ url: "/arama?q=telefon", status: 200, ua: "FakeGooglebot/1.0" }
];
console.log(rows.filter(r => isSearchBot(r.ua)));
Şablon bazında segmentleyip tarama önceliğini ölçmek
“Botlar günde 200 bin istek yaptı” bilgisi tek başına bir şey söylemez. Asıl içgörü, bu isteklerin hangi şablonlara dağıldığıdır. Ürün sayfaları mı daha çok taranıyor, kategori sayfaları mı, yoksa parametreli sayfalar mı botu oyalıyor?
URL pattern’larıyla şablon sınıflandırması yapmak
Basit regex veya route mantığıyla URL’leri gruplamak iyi bir başlangıçtır: /urun/, /kategori/, /blog/, /etiket/, /arama, parametreli URL’ler gibi. Ardından her grup için tarama sayısı, benzersiz URL sayısı ve hata oranı hesaplanabilir. Bu sayede tarama bütçesinin nereye aktığı netleşir.
Önemsiz tarama alanlarını tespit edip azaltmak
Parametreli URL’ler, filtre kombinasyonları, sayfalama (pagination) varyasyonları ve dahili arama sayfaları genellikle tarama bütçesini tüketir. Bu alanlar için canonical stratejisi, robots.txt kuralları, noindex (gereken yerde) ve iç link düzenlemesi birlikte düşünülmelidir.
Durum kodları ve hız verisiyle teknik riskleri bulmak
Loglar, yalnızca “ne tarandı” değil, “nasıl karşılandı” sorusunu da yanıtlar. Yanıt kodları ve yanıt süreleri; tarama hızının neden düştüğünü, botun hangi hatalara takıldığını ve hangi sayfaların sorun ürettiğini gösterir.
3xx zincirlerini ve döngülerini yakalamak
Yönlendirmeler kaçınılmaz olabilir; ancak zincirler botu yorar. 301/302 dizileri tarama bütçesini tüketir ve gecikme yaratır. Loglarda aynı URL’nin farklı saatlerde farklı hedeflere yönlenmesi gibi tutarsızlıklar da kontrol edilmelidir.
4xx ve 5xx artışlarını trend olarak izlemek
404’ler her zaman felaket değildir; fakat önemli sayfalar 404’e düşmüşse veya iç linkler kırılıyorsa risk büyüktür. 5xx hataları ise tarama hızını düşürerek keşfi yavaşlatır. Loglarda günlük/haftalık trend çizmek, “bugün ne değişti?” sorusuna hızlı yanıt verir.
Yanıt süresini eşiklerle izleyip darboğazı bulmak
response_time dağılımı, performans sorunlarını ortaya çıkarır. Örneğin botların en çok taradığı şablonda ortalama yanıt süresi yükselmişse, tarama hızının düşmesi beklenir. Bu yüzden “p95 response_time” gibi yüzdelik metrikler, ortalamadan daha anlamlıdır.
İndeksleme ve keşif sorunlarını loglarla çözmek
Bir sayfa indekslenmiyorsa, bot onu ya hiç görmüyordur ya da gördüğünde “değerli” bulmuyordur. Loglar, ilk ihtimali netleştirir: bot geldi mi, ne kadar sık geldi, hangi yanıtı aldı? Bu veriyi iç link, sitemap ve canonical sinyalleriyle birleştirdiğinizde net aksiyonlar çıkar.
Sitemap’te olan ama taranmayan URL’leri bulmak
Sitemap’te listelenen URL’lerin belirli bir kısmı hiç taranmıyorsa, sitemap kalitesi, sunucu performansı veya iç link eksikliği devrede olabilir. Loglarda sitemap URL listesiyle kesişim alarak “sitemap coverage” metriği üretmek faydalıdır.
Kritik sayfaların tarama sıklığını artırmak
Yeni ürünler, güncellenen kategoriler veya yüksek dönüşüm getiren landing sayfaları daha sık taranmalıdır. Bunu artırmak için iç linkleri güçlendirmek, gereksiz URL alanlarını azaltmak ve sunucu hatalarını düşürmek gerekir. Burada hedef, botun “öncelik” algısını değiştirmektir.
Bu süreçleri ekip içinde standart hale getirip herkesin aynı metriklerle konuşmasını sağlamak için uygulamalı bir SEO eğitimi, log analizi ve teknik SEO kararlarını daha hızlı olgunlaştırır.
Raporlama ve izleme rutinini kurmak
Log analizi bir proje değil, rutin haline geldiğinde değer üretir. Haftalık veya iki haftalık periyotlarla tarama bütçesi dağılımı, hata oranları ve kritik şablonların tarama sıklığı izlenmelidir. Böylece release sonrası oluşan sızıntılar erken yakalanır.
Temel KPI seti oluşturup düzenli takip etmek
Minimum KPI seti şu sorulara yanıt vermelidir: Botlar en çok hangi şablonları tarıyor? Parametreli URL payı nedir? 3xx/4xx/5xx oranları nasıl? En yavaş yanıt veren şablon hangisi? Sitemap’teki URL’lerin kaçı son 7 günde tarandı? Bu metrikler, kararların ölçülebilir olmasını sağlar.
Aksiyonları doğrulayıp kapanış yapmak
Her teknik değişiklik sonrası “öncesi/sonrası” karşılaştırması yapılmalıdır. Örneğin robots kuralı eklediyseniz parametreli URL taraması düşmeli; yönlendirme zincirini kısalttıysanız 3xx hop sayısı azalmalı; sunucu iyileştirdiyse response_time yüzdelikleri gerilemelidir. Böylece iyileştirme gerçekten gerçekleşmiş olur.
Sonuç olarak, SEO için log analizi yapmak; bot davranışını tahminden çıkarıp veriye dayalı hale getirir. Doğru veri hazırlığı, bot doğrulaması, şablon segmentasyonu ve düzenli izleme ile tarama bütçesi daha verimli kullanılır, kritik sayfalar daha hızlı keşfedilir ve teknik riskler daha erken çözülür.
