SEO LOG ANALİZİ YAPMAK BOT DAVRANIŞI

Google Search Console size hangi sayfanızın indexlendiğini söyler, ama Googlebot'un sitenizde gerçekte ne yaptığını söylemez. Hangi sayfayı kaç kez ziyaret etti, hangi URL'leri görmezden geldi, hangi sayfada hata aldı — bu bilgiler sunucu log dosyalarında saklı. Çoğu SEO uzmanı bu altın madenini hiç açmadan kariyer yapıyor.
1. Server Log Nedir, Ne İçerir
Web sunucusu her isteği bir log satırına yazar. Botun davranışını yorumlarken Google arama dokümantasyonundaki crawl ve indeksleme açıklamaları sağlam bir zemin sağlar. Tipik bir Apache veya Nginx access log satırı:
66.249.66.1 - - [12/May/2026:08:30:15 +0300] "GET /urun/kahve-makinesi HTTP/1.1" 200 4523 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Bu satırda olanlar:
- 66.249.66.1: İsteği yapan IP adresi (Googlebot'a ait).
- [12/May/2026:08:30:15]: Zaman damgası.
- GET /urun/kahve-makinesi: HTTP metodu ve URL.
- 200: HTTP yanıt kodu.
- 4523: Yanıt boyutu (byte).
- "-": Referer (yok).
- "Mozilla/5.0 ... Googlebot/2.1 ...": User agent — Googlebot olduğunu söylüyor.
Bir gün içinde küçük siteler binlerce, büyük siteler milyonlarca log satırı üretir. Bunları analiz etmek için araç gerekiyor.
2. Googlebot User Agent'larını Tanımak
Google tek bir bot değil; farklı amaçlar için farklı user agent'lar var:
| Bot | Amacı |
|---|---|
| Googlebot Smartphone | Mobile-first indexing — ana indeksleme botu. |
| Googlebot Desktop | Masaüstü versiyonları indexleme. |
| Googlebot Image | Görsel arama indexlemesi. |
| Googlebot Video | Video arama indexlemesi. |
| Googlebot News | Google News için. |
| AdsBot-Google | Reklam landing page kalite kontrolü. |
| Mediapartners-Google | AdSense reklam yerleşimi. |
| Google-InspectionTool | Search Console URL Inspect aracı. |
Önemli: Bazı kötü niyetli bot'lar Googlebot kimliğine bürünür. Doğrulama için ters DNS lookup yapılır: IP'nin googlebot.com veya google.com'a çözümlenip çözümlenmediği kontrol edilir.

3. Crawl Budget — Sınırlı Kaynak
Google sınırsız bot kaynağına sahip değil. Her site için bir "crawl budget" ayrılır: belirli bir zaman içinde kaç URL crawl edileceği. Crawl budget belirlenirken:
- Site otoritesi (PageRank)
- Sunucu hızı (Googlebot yorulmuyor)
- İçerik güncelleme sıklığı
- Önceki crawl'larda alınan hata oranı
Küçük site (1000 sayfa) için crawl budget hiç sorun değil; tüm site rahatlıkla taranır. Büyük site (1 milyon sayfa) için crawl budget kritik; Google önemli sayfaları taramadan önemsizleri taramayı tercih edebilir.
Crawl Budget İsrafı Belirtileri
Crawl budget israfı belirtileri:
- Eski/silinmiş sayfalara hâlâ crawl request
- Filtreli URL'lere yüksek crawl trafiği
- Parameter'lı duplicate URL'lere crawl
- 404 sayfalara tekrar tekrar request
- Önemli yeni içerik geç indexleniyor
4. Log Analiz Araçları
Manuel olarak gigabyte'lık log dosyalarını incelemek mümkün değil. Tipik araçlar:
- Screaming Frog Log Analyser: Standalone; orta-büyük site için yeterli. Bot identification, response code, URL analysis.
- OnCrawl: Enterprise log analizi + crawl analizi birlikte. Görsel raporlama güçlü.
- Sitebulb Log Analysis: Sitebulb'in modülü; pratik SEO insights.
- JetOctopus: Enterprise log + crawl.
- Botify Log Analyzer: Enterprise; çok büyük siteler için.
- Custom (BigQuery / Athena): Çok büyük site için cloud çözümler. SQL ile analiz.
Küçük-orta ölçek için Screaming Frog Log Analyser pratik başlangıç; lisans bir defalık, devam eden bedel yok.
5. Temel Sorular ve Cevapları
Log analizinden çıkarılacak temel sorular:
1. Hangi URL'ler crawl ediliyor, hangileri görmezden geliniyor?
Top 100 en çok crawl edilen URL'lere bak. Şaşırtıcı sayfalar mı görüyorsun (eski filtre URL'leri, silinmesi gerekenler)? Tersine, önemli stratejik sayfaların listede yok mu?
2. Hangi response code'lar veriliyor?
| Kod | Anlamı | Dikkat Edilecek |
|---|---|---|
| 200 | Başarılı | İdeal. |
| 301 | Permanent redirect | Zincir varsa kötü. |
| 302 | Temporary redirect | Kalıcı içeriklerde yanlış. |
| 304 | Not modified | Cache verimli, iyi. |
| 404 | Not found | Az kabul edilebilir; yüksek ise sorun. |
| 410 | Gone | Silinmiş içerik için doğru. |
| 500 | Server error | Acil müdahale. |
| 503 | Service unavailable | Acil; sunucu sorun. |
404 oranı %5'ten düşük olmalı; %10 üstü ciddi sorun. 500 ve 503 minimal olmalı; düzenli oluşuyorsa server sorunu var.
3. Crawl frekansı nasıl dağılıyor?
Bir sayfa kaç günde bir crawl ediliyor? Ana sayfa muhtemelen günlük, derin sayfalar haftalık veya aylık. Çok önemli bir sayfa nadir crawl ediliyorsa o sayfa Google için "düşük öncelikli" sinyali var demektir.
4. Crawl bütçesi nereye gidiyor?
Toplam crawl request'lerinin yüzde kaçı:
- Gerçek içerik sayfalarına?
- JavaScript, CSS, görsel dosyalarına?
- Filtreli/parametreli URL'lere?
- 404 hatalarına?
- Redirect zincirlerine?
İdeal dağılım %60-70 gerçek içerik, %20-30 asset, geri kalan minimum. Eğer crawl'ın %40'ı 404'lere gidiyorsa ciddi temizlik gerekiyor.

5. Hangi bölümler crawl edilmiyor?
Sitenin belirli klasörü (örn. /blog/) hiç crawl edilmiyorsa robots.txt'te yanlış disallow var veya iç linkleme yetersiz. Önemli alanlar haftalarca crawl görmüyorsa indexleme problem yaşar.
6. Crawl Budget Optimizasyonu
Log analizi sonucu crawl budget verimsiz kullanılıyorsa müdahale yöntemleri:
- Robots.txt ile bloklama: Filtreli URL'ler, ürün parametreleri, search sonuç sayfaları gibi index edilmemesi gereken bölümleri Disallow et.
- Meta robots noindex: Robots.txt'te bloklamayıp sayfayı index'ten çıkarmak istiyorsan noindex etiketi.
- Canonical: Duplicate URL'leri tek bir canonical'a yönlendir; Google diğerlerini öncelik vermez.
- XML sitemap: Önemli sayfaları sitemap'e ekle; Google önceliklendirir.
- Internal linking: Önemli sayfalara çok link, önemsizlere az link. Crawl önceliği iç link sayısına bağlı.
- URL parametre yönetimi: Search Console'da artık yok (kapatıldı) ama canonical ve robots.txt ile pratik yönetim.
- 404 temizliği: Eski silinen URL'lerin 410 dönmesi; Google daha hızlı unutur.
7. Bot Sıklığı vs Bot Karması
İki farklı metrik:
- Crawl frequency: Bir URL ne sıklıkta crawl ediliyor.
- Crawl rate: Saatte/gündeki toplam request sayısı.
Site karakter taşıyıcı (yüksek otorite + sık güncellenen içerik) ise Google sık crawl eder. Düşük otoriteli, az güncellenen site için crawl seyrek.
Crawl Rate'i Dolaylı Artırma
Crawl rate'i artırmak için doğrudan müdahale yok; ama dolaylı yollar:
- Yeni içerik düzenli yayınla (blog, ürün, kategori)
- Sitemap'i otomatik güncel tut
- İç linkleme kuvvetlendir
- Sunucu hızı iyi (Googlebot yavaş sunucudan kaçınır)
8. Sunucu Performansı ile Bot İlişkisi
Google sunucu yavaşsa crawl rate'i düşürür. Bunun belirtileri:
- Server response time yüksek (örn. 2 saniye+)
- 500 ve 503 hatalarının artışı
- Crawl rate görece azaldı
Log analiziyle TTFB (Time To First Byte) ölçülebilir. Yavaş sayfalar tespit edilir; optimizasyon önceliği belirlenir.
Sunucu Hızı Çözümleri
Çözüm:
- caching
- CDN
- database optimizasyonu
- kod profiling
Server hızı sadece kullanıcı deneyimi için değil; SEO için de doğrudan faktör.
9. Mobile Crawl Önceliği
Google mobile-first indexing yapıyor. Log dosyasında Googlebot Smartphone request'leri Googlebot Desktop'tan çok daha fazla olmalı. Eğer tersini görüyorsan:
- Site mobile-friendly olmayabilir
- Mobile versiyonda teknik sorun olabilir
- Robots.txt mobile user agent'ı yanlış bloklayabilir
Bu kontrol log analizinin standart bir adımı.
10. JavaScript Rendering
Google iki aşamalı crawl yapar:
- İlk crawl: HTML çekilir, parse edilir. Sayfaya JavaScript bağımlıysa kısmi index.
- Render queue: Daha sonra (saatler, günler içinde) Googlebot Chromium ile sayfayı render eder; JavaScript-generated içerik index'e girer.
JavaScript-heavy site (React, Vue SPA) için bu gecikme dezavantaj. Log analizinde Googlebot request'lerinden hangilerinin JS asset'i, hangilerinin HTML çağırdığı izlenir. JS asset oranı çok yüksekse server-side rendering veya prerendering gerekli.
11. Diğer Botların Yönetimi
Log dosyası sadece Google değil; tüm bot trafiğini gösterir. Diğer önemli botlar:
- Bingbot: Microsoft Bing.
- YandexBot: Rusya pazarında Yandex.
- Baiduspider: Çin pazarı için Baidu.
- DuckDuckBot: DuckDuckGo.
- FacebookExternalHit: Facebook link önizlemesi için.
- TwitterBot: Twitter card.
- LinkedInBot: LinkedIn.
- AhrefsBot, SemrushBot, MozBot: Üçüncü taraf SEO araçları.
SEO araç bot'ları gerekiyor mu? Sen Ahrefs veya Semrush kullanıyorsan onların botu sitende dolaşmalı (rakip verisi için). Kullanmıyorsan robots.txt ile bloklamak server kaynağını korur ama nadiren büyük fark yaratır.
Kötü Niyetli Bot Yönetimi
Spam/kötü niyetli bot'lar (örn. ContentKing'i taklit edenler, content scraper'lar) tespit edildiğinde firewall veya robots.txt seviyesinde bloklanır. Doyurucu bir SEO öğrenme kaynağı log analizi ve crawl optimizasyonunu pratik örneklerle ele alır.
12. Aylık Log Analiz Disiplini
Log analizi tek seferlik değil; sürekli disipline ait:
- Aylık: Bot dağılımı, response code yüzdeleri, top crawl edilen URL'ler.
- Aylık: Crawl budget verim metriği — gerçek içerik / toplam request.
- Üç aylık: Crawl frequency analizi; hangi sayfalar nadir taranıyor.
- Yarı yıllık: Bot sahteliği kontrolü; reverse DNS doğrulaması ile fake bot'lar bloklanır.
- Yılda 1-2 kez: Robots.txt ve sitemap revizesi log verilerine göre.
Bu disiplini olan ekipler teknik SEO'da bir adım önde. Search Console verisi yetersiz kalır; log verisi gerçeği gösterir. Üretim ortamında sürdürülen log analiz disiplini, ciddi SEO problemleri ortaya çıkmadan çözmeyi sağlar; reaktif değil proaktif yaklaşım.
13. Yaygın Bulgular
Log analizinde sık karşılaşılan sürpriz bulgular:
- Site genelinde önemli oranda 404 trafiği — eski yapı kalıntıları.
- Bir bölüm hiç crawl görmüyor — robots.txt veya iç linkleme problemi.
- Filtre kombinasyonlu URL'ler crawl bütçesini yutuyor.
- Eski mobil subdomain (m.example.com) hâlâ crawl ediliyor — temizlenmemiş.
- Mediapartners-Google daha fazla geliyor — AdSense alıyor ama Search değil.
- Sitemap'te olmayan sayfalar crawl ediliyor — sitemap eksik.
- Sitemap'te olan sayfalar crawl edilmiyor — sayfa güvensiz veya sinyali zayıf.
Her bir bulgu somut SEO görevi anlamına gelir. Log analizi yapan SEO ekibi, sadece Search Console'a güvenen ekipten birkaç adım önde.
Sıkça Sorulan Sorular
Log analizi her site için gerekli mi?
Boyutuna ve karmaşıklığına göre. 100 sayfalı küçük blog için Search Console verisi yeterli. 1000+ sayfalı e-ticaret veya kompleks site için log analizi ciddi katma değer. Enterprise (10K+ URL) için zorunlu kabul edilebilir; teknik SEO'nun temel disiplini.
Sahte Googlebot'ları nasıl tespit ederim?
Reverse DNS lookup yap. Gerçek Googlebot IP'leri googlebot.com veya google.com'a çözümlenir. Sahte bot'lar başka domain'e veya çözümlenememeye. Bu kontrolü otomatik yapan SEO log <strong>analiz araçları</strong> var. Manuel kontrol için "nslookup" veya "host" komutu.
Log dosyaları ne kadar süre saklanmalı?
Asgari 3 ay; ideal 12 ay. Aylık karşılaştırma için 3 ay yeter; trend analizi için yıllık veri gerekli. Log dosyaları büyük olduğu için sıkıştırılmış arşiv (gzip) tutmak alan tasarrufu sağlar. Cloud (S3, GCS) glacier tarzı arşiv katmanı maliyet etkin.
Robots.txt değişikliği log'da kaç günde görünür?
Genelde 1-3 gün. Googlebot robots.txt'i her crawl seansında tekrar okur (24 saatlik cache). Büyük değişiklikler bazen 1 hafta sürebilir; Google bu süreyi opaque tutar. Search Console URL Inspect ile sayfa bazlı yeniden test yapılabilir.
Crawl budget artırmak için ne yapılabilir?
Doğrudan müdahale yok ama dolaylı: (1) sunucu hızını artır, Google yavaş sunucudan kaçar; (2) içerik düzenli güncellense Google sık crawl eder; (3) iç linkleme önemli sayfalara çekir; (4) XML sitemap güncel; (5) gereksiz bot trafiği (filtreli URL, 404) temizle, bu boşalan kaynak gerçek içeriğe yansır.
Mobile-first indexing ile mobile crawl arasındaki fark nedir?
Mobile-first indexing = Google'ın artık mobil versiyonu birincil indexleme kaynağı olarak kullanması. <strong>Mobile crawl</strong> = Googlebot Smartphone user agent'ının yaptığı request'ler. Mobile-first'ten sonra log'da Smartphone bot'unun Desktop'tan çok daha fazla olması beklenir.
Log analiz aracı yerine BigQuery kullanabilir miyim?
Evet ve büyük siteler için tercih edilen yöntem. Log dosyaları (örn. günlük 10GB+) cloud storage'a yüklenir, BigQuery veya Athena ile SQL sorgular çalıştırılır. Custom dashboard'lar yaratılır. Pahalı ama esnek ve ölçekli; data engineer'ın olduğu ekipler için ideal.


