Sunucu günlük dosyalarında Googlebot’un en çok taradığı URL’ler

Sunucu günlük dosyalarında Googlebot verisini doğrulayıp hazırlama

Sunucu günlük dosyalarında Googlebot’un en çok hangi sayfaları taradığını nasıl tespit ederim? sorusunun en güvenilir cevabı ham access log içindedir. Search Console yararlı bir özet verir, üçüncü taraf araçlar analiz katmanı ekler; ancak gerçek isteğin hangi saniyede, hangi URL’ye, hangi durum koduyla geldiğini doğrudan log gösterir. Bu yüzden işe NGINX, Apache ya da CDN/proxy katmanında tutulan kaynaktan başlamalısınız. İlk kontrolde host, request URI, query string, status, response byte, referer ve user-agent alanlarının eksiksiz kaydedildiğinden emin olun.

NGINX’in resmi log modülü ve Apache 2.4 log dokümantasyonu, bu alanların format içinde nasıl tutulduğunu açıkça tanımlar. Özellikle birden fazla alan adı, alt alan adı veya CDN katmanı kullanıyorsanız host alanı kritik hale gelir; aksi halde Googlebot’un blog, ürün, görsel ya da yardım merkezi tarafında hangi kümeye yük bindiğini ayıramazsınız. Terimlerin teknik tarafını ekip içinde ortaklaştırmak için gerektiğinde SEO terimleri sözlüğü sayfasını referans noktası gibi kullanmak pratik olur.

Önce hangi alanları okuyun?

• Host: Tarama yükünün hangi alan adı veya alt alan adına aktığını gösterir.
• Request URI: En çok taranan URL ve dizinleri çıkarır.
• Status: 200, 301, 404 ve 5xx kırılımlarını verir.
• User-Agent: Googlebot varyasyonlarını ilk elemede ayırır.
• Bytes ve zaman damgası: Ağır yanıtları ve frekans pencerelerini yorumlamayı kolaylaştırır.

Buradaki kritik nokta, user-agent alanını nihai kanıt gibi görmemektir. Google’ın 3 Şubat 2026’da güncellediği What Is Googlebot dokümanı ve 20 Mart 2026’da güncellediği Verify Requests from Google Crawlers and Fetchers sayfası, user-agent başlığının kolayca taklit edilebildiğini açıkça vurgular. Bu nedenle ilk filtrelemede “Googlebot” geçen istekleri ayıklasanız bile ikinci aşamada reverse DNS ve mümkünse Google’ın yayımladığı crawler IP aralıklarıyla eşleştirme yapmanız gerekir. Böylece sahte botları, uptime kontrollerini veya güvenlik tarayıcılarını Googlebot sanıp yanlış karar vermezsiniz.

Pratikte en temiz hazırlık akışı şöyledir: önce tüm logları aynı zaman dilimine çevirin, sonra CDN ve origin loglarını ayrı tutun, ardından sadece doğrulanmış Googlebot isteklerinden oluşan bir çalışma seti oluşturun. Bu küçük hazırlık adımı atlanırsa sonraki sayımlar çok hızlı biçimde çarpılır; özellikle mobil Googlebot, görsel bot ve asset istekleri tek havuza karıştığında yanlış “en çok taranan sayfalar” listesi elde edilir.

Log satırlarından en çok taranan sayfaları çıkarma

Hazırlık tamamlandığında amaç basittir: doğrulanmış Googlebot isteklerini URL bazında sayıp azalan sıraya koymak. Bunu ister komut satırında grep ve awk ile, ister BigQuery benzeri bir ortamda SQL mantığıyla yapabilirsiniz. Mantık değişmez: önce Googlebot adaylarını filtrele, sonra doğrulanmış IP veya reverse DNS sonucuyla temizle, ardından request URI alanını grupla. Bu aşamada aynı URL’nin parametreli ve parametresiz sürümlerini ayrı mı birlikte mi sayacağınıza bilinçli karar verin.

Komut satırı yaklaşımında çoğu ekip şu akışla ilerler: önce user-agent içinde Googlebot geçen satırları ayıklar, sonra request URI sütununu çıkarır, en son da tekrar eden URL’leri sayıp sıralar. SQL tarafında ise tarih aralığı, host ve status filtrelerini aynı sorguda kullanmak daha kontrollüdür. Burada asıl hedef ham sayıyı görmek değil, hangi URL grubunun tarama yükünü çektiğini netleştirmektir. Sadece tekil URL listesi yetmez; kategori, blog, ürün, filtre ve arama sonuçları gibi kümeleri de ayrıca toplamanız gerekir.

HTML sayfalar ile asset isteklerini ayırın

İkinci büyük hata, görsel, JavaScript, CSS, font, feed ve benzeri asset isteklerini sayfa istekleriyle aynı raporda tutmaktır. Googlebot’un bir sayfayı oluşturmak için çektiği kaynaklar, özellikle modern frontend yapılarında yüksek hacim yaratabilir. Bu yüzden .css, .js, .jpg, .png, .webp, .svg, .xml, .txt ve feed uçlarını ayrı segmentlerde değerlendirin. Sizin asıl sorunuz “en çok taranan gerçek sayfalar hangileri” ise HTML benzeri URL’leri ayrı raporlamak çok daha anlamlıdır.

Birden fazla host veya alt alan adı kullanan yapılarda kırılımı daha da genişletin. Örneğin www ile blog alt alanını, mobil alt alanı varsa onu ve medya alanını ayrı sayın. Ardından zamanı 24 saat, 7 gün ve 30 gün pencerelerinde inceleyin. Böylece bir lansman, sitemap güncellemesi, yönlendirme dağıtımı veya hatalı iç link değişikliği sonrası Googlebot’un hangi kümeye yüklendiğini anlarsınız. Özellikle son 30 gün görünümü, ani tarama artışını kalıcı davranıştan ayırmak için daha sağlıklı bir taban verir.

Bu bölümün sonunda elinizde şu üç liste olmalı: en çok taranan HTML URL’ler, en çok taranan dizinler ve en çok taranan hostlar. Bu üçlü birlikte okunmadan yapılan yorumlar eksik kalır. Çünkü bazen sorun tek bir URL değildir; /arama/, /etiket/, /filtre/ veya /kampanya/ gibi tüm bir klasör gereksiz tarama yükü çekiyor olabilir.

Durum kodu, parametre ve dosya türüne göre tarama israfını bulma

En çok taranan sayfaları bulmak işin ilk yarısıdır; asıl değer, bu taramanın ne kadarının işe yarar olduğunu yorumlayabilmektir. Bunun için URL sayımını mutlaka status koduyla birleştirin. 200 yanıtlar normaldir, ancak 301 kümeleri, 404 kümeleri ve tekrarlayan 5xx satırları tarama verimliliğini aşağı çeker. Google’ın 19 Aralık 2025’te güncellediği Crawl Budget Management rehberi, yönlendirme zincirleri, hata kümeleri ve düşük değerli URL patlamalarının crawl budget üzerinde gerçek maliyet yarattığını açıkça anlatır.

• 301 yoğunluğu: Eski URL’lerden yeni URL’lere taşınmış ama iç linkleri temizlenmemiş alanlara işaret eder.
• 404 kümeleri: Eski filtre sayfaları, silinmiş ürünler veya hatalı iç link akışını gösterir.
• 5xx tekrarları: Tarama isteği var ama sunucu tutarsız yanıt veriyor demektir.
• Asset şişmesi: HTML yerine çok sayıda statik dosyanın tarandığını gösterir.

Parametreli URL’ler bu analizin en kritik katmanıdır. Özellikle faceted navigation, sıralama seçenekleri, dahili arama sonuçları, kampanya etiketleri ve oturum parametreleri aynı içeriğin yüzlerce varyasyonunu üretebilir. Burada önce parametreyi koruyun, sonra hangi parametrelerin en fazla istek aldığını sayın. Eğer aynı temel URL’nin onlarca parametreli sürümü gereksiz 200 veya 301 üretiyorsa, crawl budget’ın anlamlı sayfalara değil varyasyonlara dağıldığını söyleyebilirsiniz.

Dosya türü bazında bakmak da karar kalitesini artırır. Örneğin ürün görsellerinin yoğun taranması başlı başına kötü değildir; fakat HTML sayfaların büyük kısmı 301 veya 404 verirken botun zamanını filtre kombinasyonları ve asset dosyaları harcıyorsa öncelik değişir. Bu nedenle raporunuzda URL, status, dosya türü ve host aynı tabloda okunmalıdır. O zaman hangi kümeye robots.txt, hangi kümeye canonical, hangi kümeye iç link temizliği gerektiği çok daha net görünür.

30 günlük mini vaka: ham log, Search Console ve Screaming Frog neden farklı sayı verir?

Uygulamada en sık kafa karıştıran nokta, aynı 30 günlük dönemde üç veri kaynağının farklı sayılar üretmesidir. Ham log, Search Console Tarama İstatistikleri ve Screaming Frog Log File Analyser aynı şeyi göstermiyor gibi görünür; aslında her biri farklı soyutlama seviyesinde çalışır. Kendi denetim akışımızda ilk baktığımız şey, zaman aralığı ve saat diliminin birebir eşleşip eşleşmediğidir. Bu iki ayar tutmazsa farklılık teknik bir sorun değil, ölçüm çerçevesi farkı olur.

Ham log birincil kaynaktır; çünkü her isteği satır bazında görürsünüz. Search Console Tarama İstatistikleri raporu ise Google’ın kendi özet görünümüdür. Yardım dokümanında da anlatıldığı gibi bu rapor trend, yanıt, ana bilgisayar durumu ve örnek URL mantığıyla çalışır; tam URL sıralaması vermez. Bu nedenle Search Console’da gördüğünüz örnek URL sayısı ile logta saydığınız toplam URL adedi arasında doğal fark oluşur. Ham log size tam yoğunluğu verir, Search Console ise yorumu hızlandıran bir özet katmanı sunar.

Screaming Frog Log File Analyser ise ham logu okunabilir hale getiren güçlü bir ara katmandır. Resmi ürün sayfasında da vurgulandığı gibi araç, Apache, W3C Extended, NGINX ve bazı load balancer log formatlarını işleyebilir; ayrıca bot doğrulama, en sık taranan URL’ler ve response code kırılımları sunar. Fark burada genellikle içe aktarılan dosya kapsamından çıkar: tüm origin logları yüklenmemiş olabilir, CDN satırları hariç kalmış olabilir veya bot doğrulama kuralları ham elemeden daha sıkı uygulanmış olabilir. Yani araç farkı çoğu zaman veri kaynağı farkıdır.

Bu mini vakada dikkat edilmesi gereken üç tip ayrışma vardır: parametreli URL’lerin gruplanma biçimi, yönlendirme zincirlerinin tekil mi çoklu mu sayıldığı ve statik asset taramalarının rapora dahil edilip edilmediği. Aynı 30 günlük pencereyi yan yana açtığınızda, karar verirken önce ham loga, sonra Search Console özetine, en son da Screaming Frog’un filtreleme kolaylığına yaslanmak en temiz yaklaşımdır. Ekibinize görsel anlatım gerekiyorsa, Google Search Central’ın crawl budget içeriği veya Screaming Frog’un log analiz demosu bu bölüme iyi eşlik eder.

Adım Adım: Googlebot’un en çok taradığı sayfaları log dosyasından bulma

Bu akışı ilk kez kuruyorsanız karmaşık görünmesine gerek yok. Aşağıdaki sıra, küçük işletme sitelerinden büyük katalog yapılara kadar aynı mantıkla çalışır. Buradaki amaç tek seferlik rapor almak değil, her ay tekrar edilebilir bir teknik SEO kontrolü oluşturmaktır.

1. Log kaynağını ve alanları doğrula. NGINX, Apache veya CDN logunda URL, host, status ve user-agent alanlarının eksiksiz kaydedildiğini teyit edin.
2. Googlebot user-agent filtresini çıkar. İlk taramada Googlebot geçen satırları ayırın; masaüstü, mobil ve diğer crawler varyasyonlarını mümkünse ayrı saklayın.
3. Gerçek Googlebot’u doğrula. Reverse DNS sonucu ve Google crawler IP aralıklarıyla sahte botları eleyin; user-agent tek başına karar vermesin.
4. URL ve status bazında grupla. İstekleri URL, status kodu, host ve dosya türüne göre sayın; en çok taranan HTML sayfaları ayrıca sıralayın.
5. Tarama israfını aksiyona dönüştür. 301 zincirleri, 404 kümeleri, parametreli URL’ler ve düşük değerli sayfalar için teknik aksiyon listesi oluşturun.

Bu adımlar tamamlandığında artık yalnızca “Googlebot geliyor mu” sorusunu değil, “Googlebot zamanını nerede harcıyor” sorusunu da yanıtlamış olursunuz. Teknik SEO tarafında fark yaratan nokta tam olarak budur; sorun görünürlüğü, URL düzeyinde ve tekrarlanabilir biçimde ortaya çıkar.

Bulguları aksiyona çevirme: robots.txt, canonical ve SEOYEN ile önceliklendirme

Log analizi tek başına değerli değildir; çıkan bulguları doğru aksiyona bağlamadığınızda sadece rapor üretmiş olursunuz. Eğer düşük değerli filtre sayfaları yoğun taranıyorsa robots.txt bir adaydır. Aynı içeriğin çok sayıda varyasyonu taranıyorsa canonical veya iç link sadeleştirmesi öne çıkar. Eski URL’ler 301 ile hâlâ yüksek hacim çekiyorsa menü, breadcrumb, sitemap ve iç link kaynaklarını temizlemek gerekir. 404 kümelerinde ise önce neden oluştuğunu çözün; silinmiş ürün akışı mı, hatalı yönlendirme mi, yoksa bozuk dahili link mi?

• Robots.txt: Taransın istemediğiniz düşük değerli URL kümelerini sınırlamak için.
• Canonical: Aynı niyete hizmet eden varyasyonları tek URL etrafında toplamak için.
• Noindex: İndekslenmesini istemediğiniz ama erişim gerektiren sayfalarda dikkatli kullanım için.
• İç link ve yönlendirme temizliği: 301 ve 404 israfını kaynağında azaltmak için.

Burada SEOYEN’in farkı, logtan çıkan teknik bulguları operasyonel sıraya koymayı kolaylaştırmasıdır. Hangi klasör veya URL kümesinin önce ele alınacağını site sağlığı raporu ile yan yana okuyabilir, yapılan düzeltmelerin görünür etkisini sıralama takibi ile etkiyi izleme akışında takip edebilirsiniz. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer gibi platformlar tahmin, görünürlük ve rakip verisi tarafında değerlidir; ancak en çok taranan URL tespitinde ham log kadar birincil değildir. SEOYEN bu analizi Türkiye pazarına daha yakın, Türkçe arayüzlü ve tek platform akışında konumlandırır.

Rakipleri karşılaştırırken doğru çerçeve şu olmalı: Ahrefs ve SEMrush size dış veriyle güçlü bağlam verir; SEOYEN ise bunu yerel ekiplerin daha hızlı kullanacağı biçimde, Türkçe arayüz, TL bazlı yaklaşım ve yerel destek avantajıyla tamamlar. Bu farkın detaylarını ilgili Ahrefs farkları ve SEMrush kıyası sayfalarında inceleyebilirsiniz. Paket yapısını veya güncel planları kontrol etmek isterseniz sabit rakam yerine fiyatlandırma sayfası üzerinden ilerlemek daha doğrudur.

Özetle, log dosyasından çıkan en çok taranan URL listesi bir rapor değil, bir öncelik motorudur. En çok taranan ama değeri düşük kümeleri daralttığınızda Googlebot daha temiz bir mimariye yönelir. Bu da hem crawl budget tarafında verimlilik sağlar hem de teknik SEO bakımını sezgisel olmaktan çıkarıp ölçülebilir hale getirir.

Sıkça Sorulan Sorular