Sunucu log analizi SEO için neyi gösterir?

Sunucu erişim günlüğü, bir botun veya kullanıcının hangi URL'yi ne zaman istediğini ve sunucunun hangi HTTP yanıtını verdiğini kaydeder. SEO açısından bu kayıtlar, Googlebot'un gerçekten ziyaret ettiği adresleri gösterir; yalnızca site haritasında bulunan ya da taranmasını beklediğiniz URL'leri değil. Böylece yeni içeriklerin keşfedilip keşfedilmediği, eski adreslerin hâlâ istek alıp almadığı, yönlendirme zincirleri ve 5xx hataları gibi durumlar gerçek sunucu trafiği üzerinden incelenebilir.

Log analizi sıralama raporu değildir. Bir URL'nin sık taranması onun iyi sıralanacağını, az taranması da mutlaka teknik hata bulunduğunu kanıtlamaz. Google tarama sıklığını algoritmik olarak belirler ve her keşfedilen URL'nin taranması veya indekslenmesi garanti edilmez. Bu nedenle amaç, botu yapay biçimde daha çok çağırmak değil; önemli ve güncel URL'lerin erişilebilir olmasını, gereksiz adreslerin sistemi tüketmemesini ve sunucunun kararlı yanıt vermesini sağlamaktır.

Tarama bütçesi her site için aynı önemde mi?

Tarama bütçesi, Google'ın bir sitede taramak istediği URL miktarı ile sunucunun güvenli biçimde karşılayabildiği istek düzeyinin birleşimi olarak düşünülebilir. Büyük e-ticaret siteleri, çok sayıda filtre URL'si üreten platformlar, sık güncellenen yayınlar ve yüz binlerce sayfalı arşivler için bu konu operasyonel önem taşır. Buna karşılık küçük, iyi bağlantılanmış ve az sayıda URL barındıran sitelerde asıl sorun çoğu zaman tarama bütçesi değil; zayıf dahili bağlantı, hatalı canonical, noindex, robots kuralı veya yetersiz içerik kalitesidir.

Google Search Console yardım belgesi, Tarama İstatistikleri raporunun ileri düzey kullanıcıları hedeflediğini ve bin sayfadan küçük sitelerin genellikle bu ayrıntı düzeyine ihtiyaç duymayabileceğini belirtir. Bu eşik kesin bir SEO kuralı değildir; pratik bir önceliklendirme işaretidir. Küçük bir sitede log analizi yine taşıma, bot doğrulama veya beklenmeyen hata araştırması için değerlidir, ancak sırf günlük istek sayısını artırmak amacıyla yapılmamalıdır.

Gerçek Googlebot istekleri nasıl doğrulanır?

Log dosyasındaki user-agent alanında Googlebot yazması tek başına yeterli değildir; bu değer başka tarayıcılar tarafından taklit edilebilir. Google'ın resmî belgesi iki doğrulama yolu önerir: Kaynak IP için ters DNS ve ardından ileri DNS kontrolü yapmak veya IP adresini Google'ın yayımladığı tarayıcı IP aralıklarıyla karşılaştırmak. Güvenlik duvarı, hız sınırı veya erişim izni kararı vermeden önce isteğin gerçekten Google altyapısından geldiği doğrulanmalıdır.

Analiz dosyası hazırlanırken ham IP adresleri, kullanıcı tanımlayıcıları, sorgu dizelerinde taşınmış kişisel veriler ve çerezler gereksiz yere çoğaltılmamalıdır. Yalnızca inceleme için gerekli alanları alın: zaman, doğrulanmış bot türü, istek yöntemi, URL yolu, durum kodu, yanıt boyutu ve süre. Veriyi sınırlı erişimli ortamda saklayın ve kurumun gizlilik ile saklama politikasına göre silin. SEO ölçümü, ziyaretçi gizliliğini ihlal etmek için gerekçe oluşturmaz.

Analize başlamadan önce veri nasıl hazırlanır?

Önce ölçüm dönemini seçin. Normal işleyişi görmek için birkaç haftalık dönem, site taşıma veya büyük yayın gibi olaylarda ise değişiklik öncesi ve sonrası karşılaştırma daha anlamlıdır. Saat dilimini tek standarda dönüştürün; aynı isteğin CDN, yük dengeleyici ve kaynak sunucuda yinelenip yinelenmediğini kontrol edin. Statik dosya, HTML, API, görsel ve feed isteklerini dosya türü veya yol deseniyle ayırın. Ardından URL'leri tek tek değil, işlevsel gruplar hâlinde sınıflandırın.

Yararlı gruplar; ana hizmet sayfaları, blog yazıları, ürün veya ilan sayfaları, filtre-parametre URL'leri, yönlendirmeler, 404'ler, 5xx hataları, robots.txt, sitemap ve render kaynakları olabilir. Her grup için istek sayısı, benzersiz URL, son tarama zamanı, ortalama yanıt süresi ve durum kodu dağılımını çıkarın. Yüzdelere ek olarak gerçek adetleri de saklayın; düşük trafikli bir grupta tek hata yüzdesel olarak büyük görünebilir, yüksek trafikli grupta küçük yüzde ise çok sayıda başarısız isteği gizleyebilir.

Search Console ile sunucu logları nasıl birlikte okunur?

Search Console Tarama İstatistikleri raporu; toplam istek, indirilen veri, ortalama yanıt süresi, host durumu, yanıt türü, dosya türü, tarama amacı ve Googlebot türü gibi toplu göstergeler sunar. Rapor kök düzeyindeki alan adı veya kök URL öneki mülklerinde kullanılabilir. Buradaki örnek URL listeleri kapsamlı değildir; bir adresin örneklerde bulunmaması hiç taranmadığı anlamına gelmez. Sunucu logu bu noktada daha ayrıntılı rota analizi sağlar.

İki veri kaynağının sayıları bire bir eşleşmeyebilir. Search Console bazı istekleri saymayabilir; ayrıca robots.txt erişilemediği için düşünülen fakat yapılmayan taramalar rapor toplamlarına sınırlı ayrıntıyla girebilir. Yönlendirme zincirindeki her sunucu tarafı adımın ayrı istek sayılması da fark yaratır. Sağlıklı karşılaştırma, mutlak eşitlik aramak yerine aynı tarihlerdeki eğilimi inceler: yanıt süresi yükseldi mi, 5xx arttı mı, keşif ve yenileme dağılımı değişti mi, belirli dizinler beklenmedik yoğunluk aldı mı?

Hangi sorunlar tarama verimliliğini düşürür?

Sınırsız filtre ve sıralama parametreleri, takvim sayfaları, oturum kimlikleri, yinelenen arama sonuçları ve boş kombinasyonlar çok sayıda düşük değerli URL üretebilir. Aynı içeriğe giden uzun yönlendirme zincirleri her adımda ek istek oluşturur. Soft 404 sayfaları, hatalı canonical kümeleri, sürekli değişen URL'ler ve site haritasında yönlendiren veya noindex olan adresler de envanteri belirsizleştirir. Önce bu URL'lerin kullanıcı için gerçek bir işlevi olup olmadığını belirleyin; sonra bağlantı, canonical, yönlendirme, parametre üretimi ve site haritası kararlarını birlikte düzeltin.

Sunucu tarafında uzun yanıt süreleri, sık 429 veya 5xx, DNS sorunları ve robots.txt erişim hataları taramayı doğrudan etkileyebilir. Google, sunucu yavaşladığında ya da hata oranı yükseldiğinde siteyi aşırı yüklememek için isteklerini azaltabilir. Geçici bakımda doğru durum kodu kullanmak önemlidir; fakat 503 veya 429 yanıtlarını günlerce sürdürmek uzun vadede tarama sıklığını düşürebilir. Loglarda hata zamanını dağıtım, kapasite, CDN ve uygulama olaylarıyla eşleştirmek kök nedeni bulmayı kolaylaştırır.

Tarama bütçesi nasıl güvenli biçimde iyileştirilir?

İlk öncelik sunucu kararlılığıdır: Önemli sayfalar hızlı ve tutarlı 200 yanıtı vermeli; kalıcı taşınmalar tek adımlı 301 veya 308 ile doğru eşdeğere gitmelidir. Kaldırılmış, karşılığı olmayan URL'ler gerçek 404 veya 410 döndürmelidir. Sitemap yalnızca indekslenebilir, canonical ve nihai URL'leri içermeli; lastmod değeri yalnızca anlamlı içerik değişikliğinde güncellenmelidir. Önemli sayfalar ana navigasyon veya bağlamsal dahili bağlantılarla erişilebilir olmalıdır.

Robots.txt, sunucuyu gereksiz taramadan korumaya yardımcı olabilir; ancak bir sayfayı arama sonuçlarından çıkarmanın yöntemi değildir. Geniş bir robots kuralı, Google'ın noindex etiketini veya sayfayı anlamak için gereken kaynakları görmesini de engelleyebilir. Önce URL üretimini kaynağında sınırlamak, dahili bağlantıları temizlemek ve gereksiz adresleri sitemap dışında tutmak genellikle daha kontrollü bir çözümdür. Her değişikliği küçük kapsamda uygulayın, loglar ve Search Console üzerinden etkisini izleyin.

Aylık tarama analizi raporu nasıl kurulmalı?

Tek seferlik tablo yerine tekrarlanabilir bir rapor oluşturun. Raporda doğrulanmış Googlebot isteklerinin toplamı, önemli URL gruplarının payı, 200/3xx/4xx/5xx dağılımı, ortalama ve yüksek yüzdelik yanıt süreleri, en çok taranan gereksiz kalıplar, uzun süredir taranmayan önemli URL'ler ve sitemap-log farkları bulunsun. Her bulgu için kanıt, olası neden, sorumlu ekip, önerilen düzeltme ve yeniden kontrol tarihi yazın. Böylece log analizi teknik bir dosya yığını olmaktan çıkar ve ölçülebilir iş listesine dönüşür.

Başarıyı yalnızca daha fazla tarama isteğiyle ölçmeyin. Daha az gereksiz URL, daha düşük hata oranı, kararlı yanıt süresi ve önemli sayfaların düzenli yenilenmesi daha anlamlı göstergelerdir. İndeksleme ve görünürlük ayrıca içerik kalitesi, bağlantılar, canonical sinyalleri ve arama sistemlerinin değerlendirmesine bağlıdır; kesin sıralama veya indekslenme süresi vaat edilemez. Fırat Averbek'in yaklaşımı, tarama verisini bir garanti aracı değil, teknik kararları kanıtla önceliklendiren bir gözlem sistemi olarak kullanır. — Fırat Averbek

İlgili Fırat Averbek kaynakları

İleri düzey SEO hizmeti: Sunucu logları, taranabilirlik, indeksleme sinyalleri ve içerik mimarisini tek teknik denetim planında değerlendirin.

JavaScript SEO ve indeksleme rehberi: Googlebot'un ilk HTML, render kaynakları ve metadata sinyallerine nasıl ulaştığını kontrol edin.

Site taşıma ve URL değişikliği SEO rehberi: Taşıma sonrasında eski URL isteklerini, yönlendirmeleri ve beklenmeyen 404'leri sistemli biçimde izleyin.

Resmî kaynaklar

Bu rehber hazırlanırken aşağıdaki resmî ve birincil kaynaklar makalenin yayın veya son güncelleme tarihinde kontrol edilmiştir.

Sık sorulan sorular

Bu rehber hangi standarda göre hazırlanmıştır?

Metin; doğrulanabilir kaynak, açık yöntem, insan editoryal incelemesi ve yanıltıcı sonuç garantilerinden kaçınma ilkeleriyle hazırlanmıştır.

Bilgiler uygulama kararı için tek başına yeterli mi?

Hayır. Teknik, hukuki veya ticari kararlar güncel koşullar ve yetkili uzman görüşüyle doğrulanmalıdır.