SEO için Sunucu Log Analizi: Googlebot Rehberi

Search Console sitenizin tarandığını gösterebilir; ancak belirli bir URL’ye belirli bir anda hangi isteğin ulaştığını her zaman açıklamaz. Sunucu erişim kayıtları bu boşluğu doldurabilir. Bu kayıtlar sunucuya gelen istekleri ve çoğu zaman zaman damgası, istemci adresi, istenen yol, yanıt kodu, gönderilen bayt, yönlendiren sayfa ve user agent gibi alanları saklar. Doğru okunduklarında tarama israfını, tekrar eden hataları, yavaş şablonları, beklenmeyen parametre URL’lerini ve önemli sayfalara gerçekten istek gelip gelmediğini incelemeye yardımcı olurlar.

Log analizi istekler hakkında kanıttır; sıralama için kestirme yol değildir. Bir istek, sayfanın indekslendiğini, yararlı bulunduğunu veya bir sorguda gösterildiğini kanıtlamaz. Search Console raporları ve render edilmiş sayfa kontrolleri farklı sorulara cevap verir. Yararlı yöntem, her sinyali cevaplayabildiği soruyla eşleştirmek ve ardından küçük, test edilebilir bir değişiklik yapmaktır. Bu rehber logların nasıl alınacağını, crawler kimliğinin nasıl doğrulanacağını, veri kümesinin nasıl düzenleneceğini, hassas bilgilerin nasıl korunacağını ve bulguların öncelikli teknik işlere nasıl dönüştürüleceğini anlatır.

SEO Sunucu Log Analizi Ne Söyler, Neyi Söylemez?

Erişim logu, bir sunucu veya proxy isteği kaydetmek üzere ayarlandığında oluşur. Altyapıya bağlı olarak bir ziyaret CDN, yük dengeleyici, web sunucusu, uygulama logu veya bunların birkaçında görünebilir. Kayıtlar kendiliğinden eksiksiz bir tablo oluşturmaz. Önbellek isteği kaynağa ulaşmadan yanıtlayabilir. Örnekleme, saklama sınırı, birden fazla hostname, saat dilimi ve eksik alanlar veri kümesini değiştirebilir.

Logların cevaplayabildiği sorular

• Doğrulanmış Google crawler’ları tanımlı dönemde hangi URL yollarına istek gönderdi?
• İstekler ne sıklıkla 2xx, 3xx, 4xx veya 5xx yanıtı aldı?
• Parametreli, kopya veya düşük değerli URL’ler gözlenen isteklerin büyük bir bölümünü tüketiyor mu?
• Belirli şablon veya yollar daha yavaş yanıt ya da tekrar eden hata üretiyor mu?
• Bir dağıtım, istek hacmi veya durum kodu desenindeki değişimle aynı döneme mi denk geldi?
• Önemli sayfalara crawler istekleri geliyor mu, bunları hangi dahili yollar açığa çıkarıyor?

Logların tek başına cevaplayamayacağı sorular

Bir log satırı Google’ın yanıtı indekslediğini veya canonical olarak seçtiğini kanıtlayamaz. Bir backlink’in taramaya sebep olduğunu, sayfanın sıralamayı hak ettiğini ya da istek gelmeyen her URL’nin keşfedilmediğini gösteremez. Logları URL Denetleme, Search Console indeks raporları, site taraması, analitik ve içerik incelemesiyle birleştirin. Google tarama ile indekslemeyi ayrı süreçler olarak tanımlar; Crawl Stats raporu da Googlebot’un toplu tarama geçmişine farklı bir bakış sunar.

Dışa Aktarmadan Önce Doğru Log Kaynağını Seçin

İstek yolunu haritalayın. Tipik bir sitede CDN, reverse proxy, web sunucusu ve uygulama bulunabilir. Barındırma veya platform ekibine hangi katmanın dış crawler isteklerini kaydettiğini, cache isteklerinin dahil olup olmadığını ve dışa aktarımın tam URL mi yalnızca yolu mu içerdiğini sorun. Birden fazla origin, bölge veya alt alan adı kullanıyorsanız hepsini dahil edin ve her dosyanın kaynağını not edin.

Sunucunun varsayılan formatının gereken bütün alanları içerdiğini varsaymayın. Örneğin Nginx, ayarlanmış log formatında seçilen alanları yazar; Apache erişim logu formatları da yapılandırılabilir. Temsilî bir örnek ve format tanımını isteyin. Orijinal dışa aktarımı salt okunur saklayın. Analiz kopyasında saat dilimi, ayraç, kaçış kuralları, sıkıştırma ve her satırın tek istek anlamına gelip gelmediği üzerinde anlaşın.

Kullanışlı ve Güvenli Bir Veri Kümesi Toplayın

İlk incelemede normal davranışı ve bilinen olayı karşılaştırmaya yetecek bir dönem seçin. Sık taranan büyük bir sitede birkaç hafta yeterli olabilir; küçük bir site daha uzun pencere gerektirebilir. Bir dağıtım veya yapılandırma değişikliğini inceliyorsanız mümkünse öncesi ve sonrası dönemleri alın. Dışa aktarımın başlangıç/bitiş saatini, saat dilimini, kaynak katmanı, hostları ve örnekleme veya saklama sınırını kaydedin.

Yararlı alanlar arasında timestamp, istemci IP, method, host, istek yolu ve query string, protokol, yanıt kodu, yanıt boyutu, istek süresi, user agent, referrer, cache durumu ve upstream durumu bulunur. Her platform her alanı sağlamaz. Süre veya cache durumu yoksa, boş değeri sıfır saymak yerine bu sınırlamayı yazın. URL parametrelerini incelemek gerektiğinde query string’i ayrı alanda tutun; oturum numarası, e-posta, arama terimi veya başka hassas veri içerebilir. Dosyaları paylaşmadan önce bu değerleri silin veya maskeleyin.

Kişisel ve operasyonel veriyi koruyun

Erişim logları kişisel veri ve güvenlikle ilgili ayrıntılar içerebilir. Erişimi analizi yapan kişilerle sınırlayın, dosyaları onaylı kanaldan aktarın ve kurumun saklama politikasına uyun. Ham logları herkese açık issue takipçisine, ortak makale taslağına veya korumasız bulut tablosuna koymayın. Çoğu SEO sorusunda doğrulama sonrası yol deseni, tarih, durum kodu ve crawler ailesine göre toplulaştırma yeterlidir. Göreve ve politikaya bağlı olarak IP adresini maskelemek ya da kısaltmak yeterli olabilir.

User Agent’a Güvenmeden Googlebot’u Doğrulayın

User agent filtresi aday kayıtları bulmak için yararlıdır, ancak taklit edilebilir. “Googlebot” yazan bir istek otomatik olarak Google’dan gelmez. Google dokümantasyonu kaynak adresini ters DNS sorgusuyla doğrulamayı veya yayınlanan Google crawler IP aralıklarıyla karşılaştırmayı önerir. İncelediğiniz crawler türü için resmi doğrulama yöntemini kullanın; çünkü Google farklı ürünler için birden fazla crawler ve fetcher çalıştırır.

1. İlgili Google crawler user agent’ına göre çalışma kopyasında filtre uygulayıp aday satırları bulun.
2. Benzersiz kaynak IP adreslerini çıkarın ve Google’ın belgelenmiş reverse DNS veya IP aralığı yöntemiyle kontrol edin.
3. Ters DNS sonucunun izin verilen bir Google alan adına çözüldüğünü doğrulayın ve resmi prosedürde anlatılan ileri DNS kontrolünü de yapın.
4. Yalnız doğrulanmış IP’leri doğrulanmış Google isteği olarak etiketleyin; diğer adayları bilinmeyen grupta tutun.
5. Analiz dönemi veya crawler ailesi değiştiğinde doğrulamayı yenileyin, tek IP adresini kalıcı kabul etmeyin.

Bu adım sahte crawler’ın istek sayılarını bozmasını veya kötü niyetli trafiği gizlemesini önler. Ayrıca AdsBot, GoogleOther, Googlebot-Image ve Search için Googlebot’u birbirinin yerine kullanmamanızı sağlar. Sonucu doğru ürün ve soruyla eşleştirmek için crawler ailesini analizde koruyun.

Sayımlardan Önce Logları Normalize Edin

Zaman damgalarını ortak formata getirin, durum kodlarını sayısal parse edin, yolları dikkatle çözün ve anlamlı ayrımları kaybetmeden hostname’leri standartlaştırın. HTTP isteğinde gönderilmeyen fragment parçalarını çıkarın. Sunucunuzda büyük/küçük harfli yolların farklı olup olmadığına karar verin. Query parametrelerini ayrı alanda tutun; böylece normalize edilmiş yol şablonlarını tam URL’lerle karşılaştırabilirsiniz.

Birden fazla altyapı katmanının aynı isteği kaydettiğine dair kanıt yoksa kayıtları tekilleştirmeyin. Aynı URL’ye farklı zamanlardaki iki istek mükerrer değildir. Tersine, origin dışa aktarımına kopyalanmış aynı edge olayı iki kez görünebilir. Varsa request ID veya belgelenmiş kaynak ilişkisini kullanın. Dönüşümleri tekrar üretilebilir bir sorgu ya da script içinde tutun ki başka bir analist aynı toplamı çıkarabilsin.

Kompakt bir analiz tablosu kurun

Pratik bir tabloya tarih, host, normalize yol, query deseni, doğrulanmış crawler, durum ailesi, tam durum kodu, yanıt byte’ı, istek süresi ve kaynak katmanı eklenebilir. Yolları crawl envanteri veya route haritasıyla ürün, kategori, makale, görsel ve hesap sayfası gibi şablonlara bağlayın. Sınıflandıramadığınız URL’yi tahmin yürütmek yerine bilinmeyen bırakın.

Kapsamı ve Veri Kalitesini Kontrol Edin

SEO teşhisine geçmeden önce veri kümesini inceleyin. Gün başına kaç satır var? Bir kaynak log yazmayı bırakmış mı? Durum kodları boş mu? Diğer hostlar dışarıda kaldığı için tek hostname mi baskın görünüyor? Katmanlardaki toplam isteği karşılaştırın; ani sıfır veya mantıksız artış arayın. Search Console Crawl Stats varsa tarih aralığını ve genel yanıt kategorilerini karşılaştırın; ancak raporlama kapsamının ve sunucu log dışa aktarımının aynı olmadığını unutmayın.

Kısa bir dönemden tarama düşüşü sonucu çıkarmayın. Googlebot istek hacmi site büyüklüğü, içerik kalitesi, tarama talebi, sunucu kapasitesi ve başka etkenlerle değişir. Tam verili gün sayısına göre normalize edin. Site mevsimsel trafik alıyorsa veya sık içerik yayımlıyorsa eşdeğer dönemleri karşılaştırıp değişiklikleri not edin. Veri kapsamı açıklanmayan grafik, log kesintisini SEO sorunu gibi gösterebilir.

Tarama İsrafını ve URL Desenlerini Bulun

Doğrulanmış istekleri URL şablonu ve query parametresine göre gruplayın. Sıralama, facet kombinasyonları, takip parametreleri, yinelenen harf kullanımı, site içi arama, takvim sayfaları, süresi dolmuş kampanya URL’leri ve oturum yollarına giden yüksek payı inceleyin. Yüksek istek payı tek başına israf kanıtı değildir: bazı filtreler değerli landing page üretir, bazı query string’ler uygulama için zorunludur. Karar vermeden önce indekslenebilirlik, canonical, robots, dahili bağlantı ve organik landing page verisini birleştirin.

Örnek: e-ticarette filtre kombinasyonları

Bir perakendecinin 12.000 taranabilir ürün ve kategori URL’si olduğunu, ancak loglarda on binlerce filtre kombinasyonuna tekrar tekrar Googlebot isteği geldiğini varsayalım. Önce bu kombinasyonların dahili bağlantı alıp almadığını, kararlı 200 döndürüp döndürmediğini ve kullanıcıya özgün değer sunup sunmadığını kontrol edin. Ardından canonical hedeflerini, robots yönergelerini, site haritasını ve Search Console indeks durumunu karşılaştırın. Kombinasyonların çoğu temel kategoriyle aynıysa ve arama landing page olması amaçlanmıyorsa, taranabilir yolları sınırlama ve tutarlı canonical veya noindex davranışı belirleme işini mühendislikle planlayın. Sırf parametreli diye değerli bir landing page’i engellemeyin.

URL yapısı sorusunda log kanıtını bilinçli bir URL parametre politikasıyla birleştirin. Karar çerçevesi için e-ticaret filtre URL’leri ve faceted navigation rehberimize; amaçlanan URL’lerle gönderilenleri karşılaştırmak için XML sitemap denetimi rehberimize bakın. Bu içerikler URL ve sitemap kontrollerini, loglar ise gerçekte hangi isteğin yapıldığını açıklar.

Durum Kodlarıyla Teknik Hataları Bulun

Doğrulanmış crawler isteklerini durum koduna göre gruplayıp örnek URL’leri inceleyin. 5xx sunucu veya uygulama kapasitesi sorununa işaret edebilir; tekrar eden 429 rate limit anlamına gelebilir; 404 silinmiş URL, bozuk dahili link veya geçersiz filtre kombinasyonu olabilir. 301 ya da 302 beklenen davranış olabilir, fakat uzun yönlendirme zinciri gereksiz istek ekler ve URL sinyallerinin bakımını zorlaştırır. İlk yönlendirmeyi yeterli saymak yerine son hedefin durumunu da kontrol edin.

Hataları etkilenen URL sayısı, sayfa değeri, tekrar sıklığı ve süresine göre önceliklendirin. Yayın sırasında önemli bir ürün şablonunda tek 503 acil olabilir; dahili bağlantısı ve kullanıcı etkisi olmayan yüzlerce eski 404 daha düşük sırada kalabilir. Bulguları güncel crawl ve sitemap envanteriyle eşleştirin. Kullanıcıya açık kırık hedeflerde ayrı redirect zinciri ve döngü çözümü rehberini izleyin; birbiriyle ilgisiz her silinmiş URL’yi ana sayfaya yönlendirmeyin.

Yanıt Süresini Abartmadan Ölçün

Dışa aktardığınız katmanda bulunan süre alanını kullanın. Edge süresi, upstream süresi ve uygulama süresi farklı aralıkları ölçebilir. Yalnızca ortalamaya bakmak yerine şablon ve duruma göre medyan ve yüksek yüzdelikleri karşılaştırın. İsteklerin çoğu hızlı olsa bile uzun gecikmeler önem taşıyabilir. Mümkünse aynı kaynağı, bölgeyi, cache koşulunu ve dönemi karşılaştırın. Cache hit, origin yanıtından çok hızlı olabileceği için grupları ayırın.

Loglar yavaş sunucu yanıtlarını bulabilir; fakat gerçek kullanıcı Core Web Vitals verisinin yerini tutmaz. Tarayıcı deneyimi render, JavaScript, asset, cihaz ve ağ koşullarına da bağlıdır. Logları aday şablon ve kesintileri bulmak için kullanın, kullanıcı deneyimini saha verisi ve performans araçlarıyla ölçün. Yavaşlık yaygınsa mühendislikle altyapı kapasitesi, veritabanı sorguları, cache davranışı, büyük yanıtlar ve üçüncü taraf bağımlılıklarını inceleyin.

Yalnızca Büyük Sayıları Değil, Önemli URL’leri Önceliklendirin

İstek sayısı iş bağlamında yorumlanmalıdır. Logları canonical URL, indekslenebilirlik, şablon, sitemap üyeliği, dahili link, organik tıklama, dönüşüm ve içerik güncelliğini içeren URL envanterine bağlayın. Yakın zamanda yayımlanmış önemli bir sayfaya az istek gelmesi keşfin zayıf veya teknik engelin mevcut olduğunu düşündürebilir. Kopya parametreli desene yüksek istek gelmesi tarama verimsizliği işareti olabilir. Hiçbiri otomatik sonuç değildir; render edilmiş HTML ve Search Console ile doğrulayın.

Pratik bir puan etkilenen URL sayısı, iş değeri, hata şiddeti, tekrar oranı ve kanıt güvenini birleştirebilir. Bunları görünmez tek bir puana saklamayın. Örneğin sorunun önemli bir landing page’i etkileyip etkilemediğini, günlerce tekrarlanıp tekrarlanmadığını ve ikinci bir kaynağın doğrulayıp doğrulamadığını belirtin. Böylece SEO, ürün ve mühendislik ekipleri backlog’u daha kolay değerlendirir.

Yaygın Analiz Hataları

• Yalnız user agent’a güvenmek: crawler kimliğini Google’ın belgelenmiş yöntemiyle doğrulayın.
• Her isteği indekslenme saymak: fetch, URL’nin indekslendiğini kanıtlamaz.
• Ürünleri karıştırmak: Search crawler’larını diğer Google fetcher’larından ayırın.
• Cache ve katmanları yok saymak: log kaynağını ve cache trafiğinin dahil olup olmadığını yazın.
• Eksik dönemleri karşılaştırmak: hacim kıyaslamadan önce günlük veri kapsamını kontrol edin.
• Yalnız sayıdan yola çıkarak engellemek: değişiklikten önce değer, canonical, dahili link ve indeksleme amacını inceleyin.
• Ham logu yayımlamak: kişisel veya sır niteliğindeki query değerlerini maskeleyin, erişimi sınırlayın.
• Yalnız toplam sayıya bakmak: gerçek istek örneklerini inceleyip sunucu yanıtını doğrulayın.
• Yanıt süresini kullanıcı deneyimi saymak: sunucu ölçümünü saha performans verisiyle birleştirin.

Tekrarlanabilir Aylık İş Akışı

1. Tek soru yazın: örneğin Googlebot istekleri kopya filtrelere mi gidiyor?
2. Gerekli hostları, log katmanlarını, tarihleri ve alanları listeleyin.
3. Sınırlı bir dönem dışa aktarın, orijinali güvenle saklayın ve eksik veya örneklenmiş veriyi belgeleyin.
4. Kayıtları tekrar üretilebilir sorgu veya script ile parse edip normalize edin.
5. Aday crawler isteklerini filtreleyin ve Googlebot etiketi vermeden önce IP’leri doğrulayın.
6. Yol, query deseni, yanıt kodu ve zamana göre gruplayıp Search Console ve URL envanteriyle karşılaştırın.
7. Örnek URL’leri tarayıcıda, URL Denetleme’de ve sunucu ayarlarında inceleyin.
8. Sorumlu, beklenen etki, test URL kümesi ve geri alma planı bulunan aksiyon yazın.
9. Dağıtımdan sonra aynı sorguyu tekrarlayıp eşdeğer dönemleri kıyaslayın.

Çıktıyı kısa tutun: veri kalitesi notu, birkaç bulgu tablosu, örnek URL, kanıt, önerilen değişiklik, risk, sorumlu ve takip tarihi. İnceleme bitince ham IP düzeyindeki veriler yerine kurumun veri işleme politikasına uygun toplulaştırılmış sonuçları saklayın. Tekrar üretilemeyen gösterişli panel yerine tekrarlanabilir süreç daha yararlıdır.

Sık Sorulan Sorular

Sunucu logları Google’ın sayfamı indekslediğini gösterir mi?

Hayır. Loglar doğrulanmış Google crawler’ının URL’yi istediğini ve sunucunun hangi yanıtı verdiğini gösterebilir. İndekslenme ve canonical seçimini incelemek için Search Console ve URL Denetleme’yi kullanın.

Googlebot user agent’ı isteği doğrulamak için yeterli mi?

Hayır. User agent metni taklit edilebilir. İstekleri Googlebot olarak etiketlemeden önce kaynak IP’lerini Google’ın reverse DNS veya yayınlanmış IP aralığı yöntemiyle doğrulayın.

Kaç günlük log incelemeliyim?

Sitenizdeki etkinliği temsil eden ve tam verili bir dönem seçin; olayı kıyaslıyorsanız benzer öncesi/sonrası pencereleri kullanın. Eksik günleri, mevsimselliği ve yayın bağlamını belirtin.

SEO analizi için ham IP adreslerine ihtiyacım var mı?

Genellikle yalnızca crawler doğrulaması sırasında ve geçici olarak gerekir. Doğrulamadan sonra kurumunuzun gizlilik ve saklama kurallarına göre veriyi toplulaştırın veya azaltın.

Yüksek tarama sayısı Google’ın içeriği beğendiği anlamına mı gelir?

Hayır. Bu istekleri sayar; kalite değerlendirmesi veya sıralamayı değil. İndeksleme, içerik, sunucu sağlığı ve organik performansla birlikte yorumlayın.

Google’ın istediği tüm parametreli URL’leri engellemeli miyim?

Hayır. Bazı parametreli sayfalar özgün arama değeri sunabilir. Tarama kuralını değiştirmeden önce kullanıcı amacını, indekslenebilirliği, canonical hedeflerini, dahili linkleri ve sitemap durumunu inceleyin.

Sonuç

Sunucu logları crawler davranışını istek düzeyinde görünür kılar. Değerleri; dikkatli toplama, doğrulanmış crawler kimliği, tutarlı parse ve sonucu önemli URL’lerle eşleştirmeden gelir. Tek soruyla başlayın, hassas veriyi koruyun, log kapsamını kontrol edin ve durum ile süreyi bağlamında okuyun. Sonra doğrulanmış deseni küçük bir teknik düzeltmeye dönüştürüp dağıtım sonrasında aynı analizi tekrarlayın.

Google’ın güncel rehberleri için Googlebot açıklamasını (yeni sekmede açılır), Google isteklerini doğrulama yöntemini (yeni sekmede açılır) ve tarama hatalarını giderme dokümantasyonunu (yeni sekmede açılır) okuyun. Nginx ve Apache yöneticileri resmi erişim logu format belgelerine de başvurmalıdır. Bu kaynaklar crawler ve log davranışını açıklar; dışa aktarılan verinin neyi kanıtlayabileceğini altyapı yapılandırmanız belirler.