Crawler davranışını anlamanın en doğrudan yolu sunucu log dosyalarıdır. Ama çoğu SEO denetiminde bu dosya hiç açılmaz; bunun yerine Google Search Console verileri, üçüncü taraf tarama araçları ya da sıralama raporlarına başvurulur. Bu araçların her biri işe yarar, ancak hiçbiri Googlebot'un bir URL'yi ziyaret edip etmediğini, ne sıklıkta geldiğini ve sunucunun o ziyarete nasıl yanıt verdiğini log dosyası kadar doğrudan göstermez.
Log analizi yalnızca "kaç kez tarandım" sorusunu yanıtlamaz. Hangi URL türlerinin orantısız tarama bütçesi tükettiğini, hangilerinin hiç ziyaret almadığını ve sunucunun bazı isteklere yavaş yanıt verip vermediğini de ortaya koyar. Taranabilirlik ve indeksleme sorunları zaman zaman yalnızca log verisiyle görünür hale gelir; GSC ile tarama araçları bu resmi eksik sunabilir.
Aşağıdaki bölümler log dosyasının içerdiği veriyi, Googlebot davranışını bu veriden nasıl okunacağını ve bulguların teknik SEO kararlarına nasıl aktarılabileceğini ele alıyor.
Log dosyası hangi bilgileri barındırır
Bir web sunucusu (Apache, Nginx veya IIS fark etmeksizin) gelen her HTTP isteğini bir log satırına dönüştürür. Apache'nin yaygın Combined Log Format'ında tipik bir satır şu yapıya sahiptir:
66.249.66.1 - - [14/Feb/2026:09:22:35 +0000] "GET /teknik-seo-analizi-nasil-yapilir.html HTTP/1.1" 200 14823 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Bu satırda birkaç kritik bilgi bir arada bulunur: isteği yapan IP adresi, tarih ve saat damgası, istenen URL ile HTTP yöntemi, durum kodu (200), yanıt boyutu (14.823 bayt), referrer ve user agent. User agent alanı, isteğin kim tarafından yapıldığını söyler. Googlebot kendini "Googlebot/2.1" olarak tanımlar; AdsBot-Google, Storebot-Google ve Google-InspectionTool ise farklı user agent dizeleriyle kayıtlara girer ve bunların ana tarama robotu ile karıştırılmaması gerekir.
HTTP durum kodları log analizinde özellikle bilgi vericidir. 200 başarılı bir yanıtı, 301 kalıcı yönlendirmeyi, 404 bulunamayan sayfayı, 500 ise sunucu taraflı hatayı temsil eder. Googlebot'un tekrar tekrar 301 zinciriyle karşılaştığı URL'ler (A'dan B'ye, B'den C'ye, C'den D'ye uzanan üç adımlı yollar) hem tarama bütçesini tüketir hem de otorite aktarımını zayıflatabilir. Yanıt boyutu alanı ise beklenenin çok altında kalan veya sıfır bayt dönen yanıtları işaret etmekte yararlıdır; bu durumlar çoğunlukla boş sayfaları ya da sunucu taraflı hataları gösterir.
Nginx varsayılan olarak farklı bir format kullanır, IIS ise W3C Extended Log Format'ı tercih eder. Hangi sunucuyla çalışıldığını ve log formatını bilmeden analiz yapmak tutarsız sonuçlar verir; araç seçmeden önce bu bilgiyi netleştirmek gerekir.
Googlebot davranışını log satırından okumak
Log dosyasında Googlebot'a ait satırları ayıklamak, analizin ilk adımıdır. Bunun için user agent alanı "Googlebot" içeren satırlar filtrelenir. Ham bir log dosyasında bu işlem grep -i "googlebot" access.log > googlebot.log komutuyla yapılabilir; ya da Screaming Frog Log Analyzer gibi bir araçla görsel arayüzden gerçekleştirilebilir.
Ayıklandıktan sonra bu satırlar üzerinden birkaç temel soru yanıtlanabilir. Hangi URL'ler en sık ziyaret edilmiş? Ziyaretler belirli bir zaman dilimine mi yoğunlaşmış, yoksa gün içine düzgün dağılmış mı? Aynı URL için birden fazla Googlebot ziyareti varsa, aradaki süre ne kadar? Yüksek sıklıkla taranan URL'ler çoğunlukla ya çok bağlantı alan önemli sayfalar ya da yanlışlıkla arama motoruna sunulan dinamik parametre varyantlarıdır.
Tarama sıklığı dağılımı önemli bir sinyal sunar. Sitedeki 500 URL'den yalnızca 80'inin son 30 günde Googlebot tarafından ziyaret edildiği bir durumda, geri kalan 420 URL'nin neden taranmadığını araştırmak gerekir. Bu URL'ler robots.txt ile bloklanmış olabilir, iç link yapısından kopuk olabilir ya da crawl bütçesinin dışında kalmış olabilir. Log verisi bu ayrımı gösterir; Search Console'un Kapsam raporu ise yalnızca sonucu bildirir, nedeni değil.
Yanıt süresi de kayda değer bir ölçüttür. Nginx'te $request_time değişkeni bunu barındırır. Googlebot'a yönelik yanıtların ortalamanın belirgin biçimde üstüne çıktığı URL'ler (diğerleri 180 ms yanıt alırken bazı kategori sayfaları 2,4 saniye bekliyorsa) performans sorunlarını doğrudan işaret eder. Bu tür sayfalar, site hızı analizi kapsamında öncelikli ele alınmalıdır.
Az taranan ya da hiç taranmayan URL'leri belirlemek
Log analizinin pratik açıdan en değerli çıktısı, taranan URL'ler ile taranması beklenen URL'ler arasındaki farkı ortaya koymaktır. Bunun için iki liste karşılaştırılır: sitemap.xml'deki URL'ler ve log dosyasında Googlebot tarafından ziyaret edilenler. Sitemap'te olup logda hiç görünmeyenler, birinci öncelikli inceleme grubunu oluşturur.
Bu URL'lerin neden taranmadığına dair birkaç olası açıklama vardır. Sayfanın iç link yapısından kopuk olması, crawl bütçesinin değersiz URL'lere harcanması nedeniyle tarama sırası gelemiyor olması ya da sayfanın yinelenen içerik sinyalleri nedeniyle düşük öncelikli görülmesi bunların başında gelir. İndeks şişmesi olan sitelerde Googlebot genellikle düşük kaliteli veya tekrarlayan URL'lere kaynak harcadığı için önemli sayfalara yeterince ulaşamaz.
Öte yandan logda sıkça görünen ama sitemap'te olmayan URL'ler de dikkat ister. Parametre içeren URL'ler (örneğin /urunler?renk=mavi&boyut=XL), oturum tanımlayıcıları içeren yollar veya pagination varyantları bu gruba düşebilir. Googlebot bunları ziyaret ediyorsa teknik SEO analizi kapsamında ele alınmaları, gereksiz URL'lerin canonicalization veya robots.txt kurallarıyla kapsam dışı bırakılması gerekir.
Pratik bir eşik olarak şu yaklaşım kullanılabilir: son 30 günde hiç taranmamış ve son güncelleme tarihinden bu yana 60 günden fazla geçmiş URL'ler, iç link veya içerik güçlendirme gerektiren adaylar olarak işaretlenir. Sayfa sayısı büyüdükçe bu listeyi manuel incelemek yerine bir spreadsheet veya Python scriptiyle işlemek çok daha verimlidir.
Anormallik sinyallerini ayırt etmek
Log dosyası, olağan tarama trafiğinin yanı sıra dikkat gerektiren anormallikleri de barındırır. Bunları gözden kaçırmamak için birkaç kategoriye ayrılmış düzensizliklere bakmak gerekir.
5xx hataları ilk kontrol noktasıdır. Googlebot'un 500, 503 veya 504 aldığı URL'ler, o sayfaları geçici olarak tarama dışında bırakmasına yol açabilir. Aynı URL'nin logda tekrar tekrar 500 aldığı görülüyorsa sunucu taraflı bir sorun olduğu neredeyse kesindir. Kısa süreli bir 503 (örneğin planlı bir bakım penceresi) çoğunlukla sorunsuz atlatılır; ancak 503'ün saatlerce sürdüğü ve Googlebot'un bu sürede aynı sunucuya 40–50 istek gönderdiği durumlar endişe yaratır.
Tarama hızındaki ani artışlar da kayda değer bir sinyaldir. Googlebot saatte genellikle birkaç yüz istek yapar; büyük sitelerde bu rakam 2.000–3.000'e çıkabilir. Aniden günde 15.000'i aşan Googlebot istekleri varsa bu, büyük bir içerik değişikliğinden, yoğun iç bağlantı güncellemesinden veya yeni keşfedilen bir URL kümesinden kaynaklanıyor olabilir. Bu ani yoğunluğun sunucu kaynaklarını etkileyip etkilemediğini kontrol etmek gerekir.
Redirect zincirlerini logdan tespit etmek de önemlidir. Bir URL'nin logda hem 301 hem de hedef URL olarak ardışık şekilde birden fazla kez görünmesi, botun zinciri takip ettiğini gösterir. Googlebot redirect zincirlerini çoğunlukla izler; ama üç veya dört adım içeren bir zincir hem bütçe harcar hem de PageRank aktarımını azaltabilir. SEO sorunlarını tespit etmek için bu zincirlerin belirlenmesi ve doğrudan yönlendirmeye indirgenmesi öncelikli bir adımdır.
Log analizinde kullanılan araçlar ve iş akışı
Log dosyaları büyük ölçekli sitelerde günde birkaç GB'a ulaşabilir. Bu nedenle analizi ham dosya üzerinden manuel yapmak çoğunlukla pratik değildir. Birkaç farklı yaklaşım yaygın biçimde kullanılır.
GoAccess, açık kaynaklı ve terminal tabanlı bir log analiz aracıdır. Gerçek zamanlı analiz yapabilir, büyük dosyaları hızlı işler ve HTML raporu üretir. Erişim loglarına hızlı göz atmak için iyi bir başlangıç noktasıdır. Screaming Frog Log Analyzer ise Googlebot filtrelemesi, URL gruplandırması ve durum kodu dağılımı gibi SEO'ya özgü görünümler sunar; arayüzü SEO analistlerine daha tanıdık gelir.
Daha büyük hacimlerde Python ile pandas kullanmak esneklik sağlar. Log dosyasını DataFrame'e aktarmak, user agent filtrelemek, URL'leri gruplamak ve günlük istek sayısını hesaplamak 30–50 satır kodla mümkündür. Bu yaklaşım, sitemap karşılaştırması veya yanıt süresi dağılımı gibi özel analizler için özellikle uygundur.
İş akışı genellikle şu sırayı izler: log dosyasını sunucudan indirip yerel ortama aktarın; Googlebot satırlarını filtreleyin; URL başına istek sayısı, durum kodu ve tarih gibi temel metrikleri hesaplayın; sitemap URL listesiyle karşılaştırın; son olarak düzensizlikleri ve boşlukları belgeleyin. Büyük sitelerde bu süreci otomatikleştirmek ve haftalık çalışacak şekilde zamanlamak, sürekli izleme imkânı sağlar.
Log analizinin genel SEO analizi sürecine entegrasyonu için ideal döngü aylık veya üç aylıktır. Ancak sitede yapısal bir değişiklik (yeni URL şeması, büyük çaplı içerik kaldırımı, sunucu migrasyonu) yapıldığında değişiklikten hemen sonra log incelemesi yapmak önerilir.
Log verisi olmadan tarama davranışını tahmin etmenin sınırları
Log dosyasına erişim her zaman mümkün olmayabilir. Paylaşımlı hostinglerde bu dosyalar zaman zaman kısıtlıdır; CDN mimarilerinde ise gerçek sunucu logları yerine CDN edge loglarına ulaşmak gerekir ve bunlar Googlebot davranışını eksik yansıtabilir.
Bu koşullarda GSC'nin URL Denetimi ve Kapsam raporları birincil veri kaynağına dönüşür. Ancak GSC yalnızca indeksleme sonuçlarını gösterir; tarama sırasındaki davranışı değil. Bir URL'nin "İndekslendi" görünmesi, o sayfanın son 30 günde kaç kez tarandığını ya da sunucunun tarama sırasında nasıl yanıt verdiğini söylemez.
Screaming Frog veya Sitebulb gibi araçlarla yapılan site taramalarının Googlebot davranışıyla karıştırılmaması gerekir. Bu araçlar kendi botlarıyla siteyi tararlar; Googlebot'un o siteyi nasıl gördüğünü değil, bir botun sitede nelere erişebildiğini gösterirler. Organik trafik düşüşlerinde log analizi olmadan yalnızca bu araçlara dayanmak, gerçek nedeni gözden kaçırma riskini artırır.
Log erişimi kısıtlıysa barındırma sağlayıcısından veya sunucu yöneticisinden periyodik log dışa aktarımı talep etmek bir çözüm yoludur. Alternatif olarak, sunucu yapılandırmasına müdahale edilebildiği durumlarda Googlebot'a özel bir loglama kuralı tanımlamak (yalnızca bu botun isteklerini ayrı bir dosyaya yazmak) uzun vadede çok daha temiz bir iş akışı sağlar.
Log analizi, bir SEO denetiminin olmazsa olmaz bileşeni olmak zorunda değildir; ancak belirli soruları yanıtlamak için başvurulabilecek en güvenilir kaynak olmaya devam eder. Hangi URL'lerin tarandığını, hangilerinin atlandığını ve sunucunun bota nasıl davrandığını bilmeden yapılan teknik bir denetim, önemli bir veri katmanını görmezden gelmiş olur. Log dosyasını açmak zahmetli görünebilir; ama içerdiği bilgi, çok sayıda araçtan derlenen dolaylı sinyallerin yerine doğrudan geçer.