Google Search Console'un kapsama raporu, hangi sayfaların dizine alındığını gösteriyor. Ama Googlebot'un sitenizi nasıl gezdiğini — hangi URL'leri ne sıklıkla ziyaret ettiğini, hangi dil sürümlerine ne kadar dikkat ayırdığını, hangi bölümleri atlayıp geçtiğini — göstermiyor. Bu bilgi yalnızca server log dosyalarında var. Log analizi, Googlebot davranışını doğrudan, filtresiz ve örneklemesiz biçimde ortaya koyuyor; GSC gibi araçların ürettiği yorumlanmış veri değil, ham iz kaydı.
Çok dilli sitede bu ayrım özellikle belirginleşiyor. Beş dil sürümü kurulu bir sitenin GSC raporları dizinlenmiş sayfa sayısını gösteriyor. Ama her dil sürümü Googlebot tarafından eşit dikkatle mi taraniyor? Ana dil sürümü günde on kez ziyaret edilirken diğer dörde haftada bir mi gidiliyor? Hreflang etiketleri doğru kurulu görünse de Google'ın bu etiketleri okuduğu sayfalar gerçekte taranıyor mu? Bu soruların yanıtı log dosyalarında.
Log analizi zaman alan, teknik altyapı gerektiren ve ham veriden anlam çıkarmayı gerektiren bir süreç. Tek dilli sitede yüklü bir fayda sunuyor. Çok dilli yapıda bu fayda katlanıyor — çünkü dil sürümleri arası tarama dengesizlikleri, hreflang erişim sorunları ve pek çok teknik SEO hatası yalnızca log verisinde kendini gösteriyor.
Log verisi ile GSC verisi aynı soruya farklı yanıt veriyor
Google Search Console verisi, Google'ın siteniz hakkında size sunmayı seçtiği özetlenmiş bilgi. Örneklemeli, gecikeli ve belirli bir bakış açısıyla filtrelenmiş. Buna karşın log dosyaları, sunucunuza gelen her isteği zaman damgasıyla, kaynak IP'siyle, HTTP durum koduyla ve kullanıcı ajanıyla birlikte kaydediyor. Hiçbir örnekleme yok, hiçbir gecikme yok.
Pratik fark şu: GSC bir sayfanın "keşfedildi ama dizine alınmadı" statüsünde göründüğünü söylüyor. Log verisi ise o sayfanın son üç ayda kaç kez ziyaret edildiğini, her ziyarette hangi HTTP kodu döndüğünü ve bu ziyaretlerin hangi günlere yoğunlaştığını gösteriyor. Sorun tanımı değil, sorun kaynağı bu ikinci veri katmanında ortaya çıkıyor.
Çok dilli sitede bu fark daha da kritik. GSC'nin uluslararası hedefleme raporları hreflang hatalarını tespit ediyor ama Googlebot'un hangi dil sürümüne ne sıklıkla gittiğini, hangi URL pattern'larını tercih ettiğini ya da bazı dil sürümü sayfalarını hiç ziyaret etmediğini göstermiyor. Log verisi bu boşluğu dolduruyor. Türkçe sürüm günde otuz ziyaret alırken Arapça sürüm haftada üç ziyaret alıyorsa, bu eşitsizlik log dosyasında görünüyor — GSC'de değil.
Dil sürümleri arası tarama dağılımını okumak
Log analizinde çok dilli siteler için ilk yapılacak iş: Googlebot isteklerini URL yapısına göre segmentlere ayırmak. /tr/, /de/, /fr/ gibi dil dizinleri ya da tr.example.com gibi alt domainler kullanılıyorsa, her segmentin toplam Googlebot isteği içindeki payını hesaplamak mümkün. Bu pay, içerik büyüklüğüyle orantılı olmalı — eğer Türkçe sürüm sitenin %30'unu oluşturuyorsa ve Googlebot'un %80 zamanını orada geçiriyorsa, bu dengesizlik bir sorun işareti.
Daha ince bir sinyal tarama sıklığı. Aynı sayfa haftada kaç kez ziyaret ediliyor? Statik içerikli bir kategori sayfası günde birden fazla taranıyorsa Googlebot gereksiz kaynak harcıyor. Tersine, sık güncellenen bir blog sayfası ayda yalnızca bir kez taranıyorsa Google güncel içeriği gecikmeli alıyor. Bu oran dil sürümlerine göre ayrıştırıldığında ilginç örüntüler çıkıyor: çoğunlukla ana dil sürümü orantısız biçimde fazla taranırken diğer sürümler ihmal ediliyor.
HTTP durum kodları bu analizin ikinci katmanı. Googlebot ziyaretlerinde 200 kodu bekleniyor. Ama log'da aynı URL için tekrar eden 301 yanıtları redirect zinciri olduğunu gösteriyor. 404 yanıtları silinmiş ya da taşınmış içeriğe hâlâ gidildiğini. 500 ve benzeri sunucu hataları ise Googlebot'un tam olarak alamadığı sayfaları işaretliyor — ve bu sayfalar GSC'de bazen hiç görünmüyor. Teknik SEO denetim listesinde hata kodu takibi önemli bir madde; log verisi bu takibi gerçek zamanlı yapmanın tek yolu.
Çok dilli sitelerde özellikle dikkat edilmesi gereken bir durum: dil geçiş mekanizmasının Googlebot için sorun yaratması. Kullanıcı ajanı tespitine dayalı dil yönlendirmesi kurulmuşsa, Googlebot'un kullanıcı ajanına göre farklı içerik sunuluyor ya da farklı URL'ye yönlendiriliyor olabilir. Bu log'da anında görünüyor: aynı URL için hem 200 hem 302 yanıtları, farklı kullanıcı ajanlarından gelen isteklere farklı yanıtlar. Bu durum doğrudan Accept-Language tabanlı yönlendirme sorunlarıyla örtüşüyor.
Hreflang sayfaları gerçekten taraniyor mu?
Hreflang etiketi doğru yazılmış olabilir. Ama etiketin işaret ettiği sayfa Googlebot tarafından taranalmazsa, o etiket hiçbir işlev göremiyor. Google hreflang kümesini değerlendirmek için işaret edilen her sayfayı taraması gerekiyor. Sayfalardan biri taranamıyorsa — robots.txt tarafından engellenmişse, 5xx hatası dönüyorsa ya da çok seyrek taranıyorsa — hreflang sinyali eksik kalıyor.
Log analizi bu durumu doğrudan test etmeye olanak tanıyor. Hreflang setindeki tüm URL'leri bir listeye alın, bu URL'lerin Googlebot ziyaretlerini log dosyasında filtreleyin. Eğer bir dil sürümüne ait sayfalar hiç ziyaret edilmemişse ya da çok seyrek ziyaret ediliyorsa, hreflang sinyali o sürüm için pratikte işlemiyor demek. Bu bilgi GSC'nin hreflang hata raporundan ayrı — GSC hreflang sözdizimine bakıyor, log verisi ise Googlebot'un o sayfaya gerçekten ulaşıp ulaşmadığını gösteriyor.
Bu kontrolü sistematik yapmak için iki veri seti karşılaştırılıyor: mevcut hreflang setindeki URL listesi (sitemap'ten ya da sayfalardan çekilmiş) ile log'daki Googlebot ziyaret listesi. İki liste arasındaki fark — log'da görünmeyen ama hreflang setinde yer alan URL'ler — hem tarama bütçesi sorunu hem de olası robots.txt veya canonical çatışması işareti olabiliyor. Hreflang testi için kullanılan araçlar bu doğrulamayı teknik sözdizimi düzeyinde yapıyor; log analizi ise tarama düzeyinde yapıyor. İkisi birbirini tamamlıyor.
Tarama bütçesi: çok dilli yapıda kayıp nerede oluyor?
Tarama bütçesi — Googlebot'un belirli bir sürede sitenize ayırdığı tarama kapasitesi — çok dilli yapıda hızla tükeniyor. Her dil sürümü, her dil sürümündeki her sayfa ayrı bir URL anlamına geldiğinden, dört dil sürümü olan bir site tek dilli siteye kıyasla dört kat daha fazla URL yönetiyor. Bu URL'lerin hepsinin eşit değer taşımaması, tarama bütçesinin bir kısmının düşük öncelikli içeriğe harcanması demek.
Log analizinde tarama bütçesi kaybının en yaygın kaynakları şunlar: parametre içeren URL'ler (oturum kimlikleri, sıralama parametreleri, filtre kombinasyonları), redirect zincirleri, çok sayıda dahili arama sonucu sayfası ve noindex kararı verilmiş sayfalar. Noindex sayfası robotlar tarafından dizine alınmaması gerektiğini belirtiyor ama Googlebot bu sayfayı hâlâ tarayabiliyor — çünkü taramak ile dizine almak farklı işlemler. Log'da çok sayıda noindex sayfası taranıyorsa bu tarama bütçesi kayıp anlamına geliyor.
Çok dilli sitede buna ek olarak dil sürümü parametrelerinin yol açtığı URL varyasyonları eklenebiliyor. Örneğin ?lang=tr parametresi kullanan bir yapıda her sayfanın hem parametresiz hem parametreli versiyonu Googlebot tarafından ziyaret ediliyorsa, tarama kapasitesi ikiye bölünüyor. Bu sorun URL yapısı tasarımında kökte çözülüyor — ama kurulu bir sistemde log analizi bu kaybı tespit eden ve önceliklendiren araç.
Tarama bütçesi kaybını ölçmek için basit bir hesap: son 30 günde Googlebot tarafından ziyaret edilen URL'lerin toplam sayısı ile bu URL'ler arasında indekslenmiş olanların oranı. Eğer Googlebot on bin URL tarıyorsa ama yalnızca dört bin URL dizine girmişse, altı bini boşa harcanan kapasite. Bu oran dil sürümlerine ayrıştırıldığında hangi sürümlerin daha verimsiz tarandığı görünüyor. Uluslararası sitemap yapısını buna göre güncellemenin ve düşük öncelikli URL'leri sitemap'ten çıkarmanın etkisi log verisinde birkaç hafta içinde izlenebiliyor.
Log analizini kurmak: araç seçimi ve pratik sınırlar
Log analizi kurulumu üç bileşen gerektiriyor: log dosyalarına erişim, bir ayrıştırma mekanizması ve görselleştirme ya da sorgulama arayüzü.
Log dosyalarına erişim çoğunlukla hosting veya CDN tarafından sağlanıyor. Paylaşımlı hostinglerde bu erişim kısıtlı olabiliyor; sanal sunucu veya bulut altyapısında ise genellikle tam erişim mümkün. CDN kullanan sitelerde dikkat edilmesi gereken nokta: CDN'nin kendi log'u ile origin sunucunun log'u farklı bilgi içeriyor. CDN log'u Googlebot'un CDN'ye gelen isteklerini gösteriyor; ama CDN önbellekten yanıt veriyorsa origin sunucuya hiç istek gelmemiş olabiliyor. Bu iki log'u birlikte değerlendirmek gerekiyor.
Ayrıştırma mekanizması için yaygın seçenekler arasında özel log analiz araçları, sunucu tarafında çalışan log işleyiciler ve log verilerini bir veritabanına veya analitik platforma aktaran pipeline'lar sayılabilir. Küçük siteler için günlük log dosyalarını betikle filtrelemek yeterli olabiliyor. Büyük sitelerde — günde milyonlarca satır log üreten yapılarda — log'ları gerçek zamanlı işleyen bir altyapı kaçınılmaz hale geliyor.
Görselleştirme tarafında log verisini doğrudan anlayışlı biçimde sunan araçlar var. Ama bu araçların büyük bölümü çok dilli yapıyı otomatik olarak segmentlere ayırmıyor; dil sürümü bazında raporlar için özel filtreleme ve gruplamaları kendiniz kurmanız gerekiyor. Bu kurulum bir kez yapıldığında ilerleyen aylarda bakımı basit; ama başlangıçta teknik kaynak gerekiyor.
Pratik sınır: log analizi anlık değil geriye dönük veri sunuyor. Log saklama politikası bir haftaysa yalnızca son yedi günü görebiliyorsunuz. Uzun vadeli trend takibi için log saklama süresini en az 90 güne uzatmak, gerçek bir davranış değişikliğini gürültüden ayırt etmeye olanak tanıyor. Çok dilli sitede mevsimsel arama örüntüsü veya yeni dil sürümü lansmanının tarama davranışını nasıl değiştirdiğini anlamak için bu süre kritik.
Googlebot kullanıcı ajanı doğrulaması
Log dosyalarında Googlebot olarak görünen tüm istekler gerçek Google botuna ait olmayabilir. Kullanıcı ajanı taklit edilerek gelen tarayıcılar da "Googlebot" olarak kayıtlara geçiyor. Gerçek Googlebot'u doğrulamak için kaynak IP'nin Google'ın yayımladığı IP aralıklarıyla eşleştirilmesi gerekiyor. Bu adım atlanırsa analizde gürültü oluşuyor.
Log analizi, uluslararası SEO metriklerini yorumlarken başvurulan dolaylı göstergelerin ötesine geçiyor. GSC verisi, sıralama raporları ve trafik analitiği neyin çalışıp çalışmadığını gösteriyor; log verisi ise neden çalışıp çalışmadığını. Bu "neden" sorusu çok dilli yapıda özellikle değerli — çünkü altı dil sürümünden birindeki tarama sorunu organik performansı sessizce kötüleştiriyor; fark edildiğinde sorun aylarca sürmüş oluyor.
Her çok dilli sitenin log analizine ihtiyacı yok. Küçük katalog, az dil sürümü, stabil teknik altyapı — bu koşullarda GSC ve düzenli teknik denetim yeterli. Ama büyük e-ticaret katalogları, sık değişen içerik ve beşten fazla dil sürümüyle çalışan siteler için log analizi periyodik bir kontrol noktası olmaktan çıkıp sürekli izleme altyapısına dönüşmesi gereken bir araç. Kurulumu bir kez yapılmış ve dil segmentlerine göre yapılandırılmış log analizi, tarama kalitesini ölçmek için başka hiçbir aracın dolduramadığı boşluğu kapatıyor.