Sunucu Loglarıyla Googlebot Tarama Analizi ve Tarama Bütçesi

Search Console size Google’ın siteniz hakkında ne düşündüğünü gösterir; sunucu logu ise Googlebot’un gerçekte ne yaptığını. Hangi URL’lerin ne sıklıkla tarandığı, botun hangi yönlendirme zincirinde ve hangi 404’lerde vakit harcadığı, yeni yayımlanan sayfaya ne zaman geldiği yalnız logda tam olarak görünür. Log yalan söylemez. Bu rehber, erişim loglarını SEO tarama analizine hazırlamayı, sahte Googlebot’ları ayıklamayı ve komut satırından hızlı bulgu çıkarmayı anlatır.

Log analizinin Search Console’dan farkı

Soru	Search Console	Sunucu logu
Hangi URL’ler tarandı?	Örneklenmiş liste	Her istek, tam liste
Kendi dizin gruplarıma göre dağılım	Sınırlı	İstediğiniz kırılımda
Sitemap’te olup hiç taranmayan URL	Dolaylı	Doğrudan karşılaştırma
Parametreli URL israfı	Görülmesi zor	Parametre bazında sayım
Google’ın içerik değerlendirmesi	Var (dizin durumu)	Yok

İki kaynak birbirini tamamlar. Search Console’daki Tarama İstatistikleri raporu (Ayarlar altında) toplam istek, ortalama yanıt süresi, yanıt kodu, dosya türü ve Googlebot türü dağılımını verir; URL düzeyinde yalnız örnek bir liste gösterir. Raporda anormal bir eğilim gördüğünüzde nedenini URL düzeyinde logda ararsınız.

Tarama bütçesine de doğru ölçekte bakın. Google’ın büyük siteler için tarama bütçesi rehberi, konunun ağırlıklı olarak çok büyük (yaklaşık bir milyonun üzerinde tekil sayfa) ya da içeriği çok hızlı değişen (on binlerce sayfası günlük güncellenen) siteleri ilgilendirdiğini belirtir. Birkaç yüz sayfalık bir kurumsal sitede bütçe sorun değildir. Asıl kazanç teşhistir: hata, zincir ve keşif gecikmesi.

Log formatı ve gerekli alanlar

Nginx ve Apache’nin varsayılan combined formatı temel analiz için yeterlidir:

66.249.66.1 - - [10/Nov/2026:10:15:32 +0300] "GET /rehberler/ornek/ HTTP/1.1" 200 15342 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Boşlukla bölündüğünde $1 istemci IP’si, $4 zaman, $7 istek yolu, $9 durum kodu, $10 yanıt boyutudur; çift tırnakla bölündüğünde $6 kullanıcı aracısıdır. Yanıt süresi ve sanal alan adı da loglanırsa analiz derinleşir. Nginx için örnek format:

log_format seo '$remote_addr - $remote_user [$time_local] "$request" '
               '$status $body_bytes_sent "$http_referer" '
               '"$http_user_agent" $request_time $host';
access_log /var/log/nginx/example.com.access.log seo;

Yeni alanları satırın sonuna ekleyin; böylece mevcut awk alan numaraları bozulmaz. Ortaya eklenen tek alan, eski betiklerin hepsini sessizce yanlış sonuç üretir hale getirir. Logların saklanması, rotasyonu ve merkezi toplanması ayrı bir operasyon konusudur; burada odak, logun SEO açısından yorumlanmasıdır. Toplama tarafı için web sunucusu log yönetimi yazısına bakın.

CDN arkasında gerçek IP

Site Cloudflare gibi bir CDN arkasındaysa sunucu logunda istemci olarak CDN’in IP’leri görünür ve Googlebot doğrulaması yapılamaz. Konsolda ilk bakılacak yer burasıdır: logdaki IP’lerin hepsi birkaç aralıktan geliyorsa realip yapılandırması eksiktir. Nginx’te ngx_http_realip_module ile çözülür:

# Cloudflare'ın yayımladığı IPv4/IPv6 aralıklarının her biri için:
set_real_ip_from 173.245.48.0/20;
# ... diğer aralıklar ...
real_ip_header CF-Connecting-IP;

Aralık listesini Cloudflare günceller; elle kopyalanan liste zamanla eskir, otomatik güncelleyin. Başlığa yalnız bu aralıklardan gelen isteklerde güvenmek gerekir; aksi halde herkes kendi IP’sini başlıkla sahteleyebilir. Ayrıca CDN önbelleğinden yanıtlanan istekler kaynak sunucuya hiç ulaşmaz; tam tablo için CDN tarafındaki logları da hesaba katın. Önbellek katmanlarının birlikte nasıl çalıştığı Cloudflare, WP Rocket ve Redis yazısında.

Gerçek Googlebot’u doğrulamak

Kullanıcı aracısı dizesi taklit edilebilir; tarayıcılar, SEO araçları ve kötü niyetli botlar sık sık “Googlebot” beyan eder. Google’ın doğrulama yöntemi iki adımlıdır: IP’nin ters DNS kaydı googlebot.com veya google.com ile bitmeli, bu ada yapılan ileri DNS sorgusu da aynı IP’yi döndürmelidir. Alternatif olarak Google’ın yayımladığı IP aralığı JSON dosyalarıyla karşılaştırma yapılabilir; çok sayıda IP’de bu yöntem daha hızlıdır.

# 1) Googlebot beyan eden tekil IP'ler
grep -i 'googlebot' access.log | awk '{print $1}' | sort -u > gb_ips.txt

# 2) Ters + ileri DNS doğrulaması
while read -r ip; do
  ptr=$(host "$ip" | awk '/domain name pointer/ {print $NF}' | sed 's/\.$//')
  case "$ptr" in
    *.googlebot.com|*.google.com)
      if host "$ptr" | grep -qwF "$ip"; then echo "OK $ip $ptr"; else echo "FAKE $ip $ptr"; fi ;;
    *) echo "FAKE $ip ${ptr:-ptr-yok}" ;;
  esac
done < gb_ips.txt > gb_verify.txt

# 3) Yalnız doğrulanmış IP'lerin isteklerini ayır
awk '$1=="OK"{print $2}' gb_verify.txt > gb_ok.txt
awk 'NR==FNR{ok[$1];next} ($1 in ok)' gb_ok.txt access.log > googlebot.log

Döngü her IP için DNS sorgusu yaptığından binlerce IP’de yavaştır; sonuçları önbelleğe alın veya IP aralığı yöntemine geçin. IPv6 adreslerinde log ve host çıktısındaki yazım biçimi farklı olabilir; eşleşmeyenleri elle kontrol edin. googleusercontent.com ile biten adresler kullanıcı tetiklemeli Google araçlarına aittir ve tarama analizine dahil edilmez.

Komut satırı ile hızlı analiz

Doğrulanmış googlebot.log dosyası üzerinde ilk tablo birkaç satırla çıkar. Sıra önemli: önce durum kodu dağılımı, sonra dizin kırılımı, en son tek tek URL’ler.

# Durum kodu dağılımı
awk '{print $9}' googlebot.log | sort | uniq -c | sort -rn

# Günlük istek sayısı (log kronolojik sırada olmalı)
awk '{print substr($4,2,11)}' googlebot.log | uniq -c

# Birinci düzey dizine göre dağılım
awk '{split($7,a,"?"); split(a[1],p,"/"); print (p[2]=="" ? "/" : "/" p[2] "/")}' googlebot.log \
  | sort | uniq -c | sort -rn | head -20

# En çok taranan parametre adları
awk '$7 ~ /\?/ {split($7,a,"?"); print a[2]}' googlebot.log \
  | tr '&' '\n' | cut -d= -f1 | sort | uniq -c | sort -rn | head

# Mobil / masaüstü Googlebot oranı
awk -F'"' '{print ($6 ~ /Mobile/) ? "smartphone" : "desktop"}' googlebot.log | sort | uniq -c

# 3xx ve 4xx dönen en çok taranan URL'ler
awk '$9 ~ /^[34]/ {print $9, $7}' googlebot.log | sort | uniq -c | sort -rn | head -30

Döngüsel log dosyaları sıkıştırılmışsa zcat -f access.log* çıktısını aynı komutlara verebilirsiniz. Birkaç gigabaytı aşan veride aynı sorguları SQL ile çalıştırmak için logları bir veritabanına (örneğin DuckDB veya ClickHouse) aktarmak pratiktir. Araç değişir. Yöntem değişmez.

Sitemap ile karşılaştırma

Tek başına en çok bilgi veren analiz, sitemap’teki URL’lerle taranan URL’leri karşılaştırmaktır:

# Sitemap'teki yollar
curl -s https://www.example.com/page-sitemap.xml https://www.example.com/post-sitemap.xml \
  | grep -o '<loc>[^<]*' | sed -E 's#<loc>https?://[^/]+##' | sort -u > sitemap_paths.txt

# Taranan yollar (parametresiz, yalnız 200)
awk '$9==200 {split($7,a,"?"); print a[1]}' googlebot.log | sort -u > crawled_paths.txt

comm -23 sitemap_paths.txt crawled_paths.txt > sitemapte_var_taranmamis.txt
comm -13 sitemap_paths.txt crawled_paths.txt > taranmis_sitemapte_yok.txt

İlk liste, analiz döneminde hiç ziyaret edilmemiş önemli sayfaları; ikinci liste ise sitemap dışında kalıp tarama kaynağı tüketen URL’leri gösterir. Analiz penceresi en az birkaç hafta olmalıdır; birkaç günlük logda seyrek taranan sayfalar yanlışlıkla “taranmamış” görünür ve boşuna alarm verirsiniz.

Tarama dağılımı ve israf alanları

Bulguları yorumlarken sahada tekrar tekrar karşılaştığımız şu kalıplara bakın:

• Parametre patlaması: Filtre, sıralama veya takvim parametreleri toplam isteklerin önemli bir kısmını oluşturuyorsa sonsuz URL alanı vardır.
• Yönlendirme zincirleri: Aynı eski URL’ler sürekli 301 alıyorsa iç bağlantılar ve sitemap hâlâ eski adresleri gösteriyordur.
• Kalıcı 404’ler: Silinen sayfalara sürekli istek geliyorsa kaynağını (iç bağlantı, dış bağlantı, eski sitemap) bulun; karşılığı olan içerik varsa yönlendirin.
• 5xx ve yavaş yanıtlar: Google, sunucu hata verdiğinde veya yavaşladığında tarama hızını düşürür. $request_time alanı loglanıyorsa yavaş URL’leri ayrı listeleyin.
• Yönetim ve teknik yollar: /wp-json/, /feed/, ?replytocom= gibi yollara yoğun istek, sinyallerin gözden geçirilmesi gerektiğini gösterir.
• Keşif gecikmesi: Yeni yazının yayın zamanı ile ilk Googlebot isteği arasındaki süreyi ölçün; uzun süreler iç bağlantı ve sitemap sorunlarına işaret eder.

Bulgulara göre aksiyon tablosu

Bulgu	Olası neden	Aksiyon
Parametreli URL’ler çok taranıyor	Filtre bağlantıları taranabilir	Canonical, gerekiyorsa robots.txt ile daralt
Çok sayıda 301	İç bağlantılar eski URL’de	Bağlantıları ve sitemap’i nihai URL’ye güncelle
Sürekli 404	Silinmiş içerik, kırık bağlantı	Karşılık varsa 301, yoksa 404/410 bırak, iç bağlantıyı düzelt
5xx veya yüksek yanıt süresi	Kaynak yetersizliği, ağır sorgu	Sunucu/önbellek iyileştirme, yavaş URL’leri profille
Sitemap URL’si taranmıyor	Zayıf iç bağlantı, derin konum	İlgili sayfalardan bağlantı ver, menü/kategori yapısını gözden geçir
Sahte Googlebot trafiği yüksek	Kazıyıcı botlar	WAF/hız sınırlama kuralları (doğrulanmış Googlebot hariç)

Aksiyonların çoğu indeksleme sinyallerine dokunur; robots.txt, canonical ve noindex arasındaki seçim için indeksleme sinyalleri rehberine bakın. Değişiklikten sonra aynı komutları birkaç hafta arayla yeniden çalıştırın ve dağılımın beklenen yöne kaydığını doğrulayın. Ölçmeden düzeltildi saymayın.

Log formatı, gerçek IP yapılandırması ve önbellek katmanları sunucu tarafında kurulur; biz bu yapıyı Nginx web sunucusu ve reverse proxy çalışmalarında, bulguların yorumlanmasını ise teknik SEO ve site mimarisi kapsamında ele alıyoruz.

Sık sorulan sorular

Küçük bir kurumsal sitede log analizi yapmaya değer mi?

Google’a göre tarama bütçesi çoğunlukla çok büyük veya çok sık değişen sitelerde kısıt yaratır. Küçük sitede log analizinin değeri bütçeden çok teşhistir: Googlebot’un yeni sayfaları ne kadar sürede bulduğunu, 404 ve yönlendirme zincirlerine ne kadar istek harcadığını ve sunucu hatası alıp almadığını gösterir.

Kullanıcı aracısında Googlebot yazan her istek gerçek Google mıdır?

Hayır. Kullanıcı aracısı istemcinin beyanıdır ve kolayca taklit edilir. Gerçek Googlebot, IP adresinin ters DNS kaydının googlebot.com veya google.com ile bitmesi ve bu ada yapılan ileri sorgunun aynı IP’yi döndürmesiyle ya da Google’ın yayımladığı IP aralıklarıyla doğrulanır.

Cloudflare arkasındaki sitede loglarda neden hep Cloudflare IP’leri görünüyor?

Web sunucusu bağlantıyı doğrudan Cloudflare’dan aldığı için uzak adres Cloudflare’ın IP’sidir. Nginx’te realip modülüyle veya Apache’de mod_remoteip ile CF-Connecting-IP başlığını yalnız Cloudflare IP aralıklarından gelen isteklerde güvenilir kabul edip gerçek istemci IP’sini loglamak gerekir.

Search Console Tarama İstatistikleri raporu log analizinin yerini tutar mı?

Kısmen. Rapor toplam istek, yanıt kodu, dosya türü ve Googlebot türü dağılımını verir; URL düzeyinde yalnız örnek bir liste gösterir. URL bazında tam liste, kendi dizin gruplarınıza göre kırılım ve sitemap karşılaştırması için ham log gerekir. İkisi birlikte kullanıldığında birbirini doğrular.