SEO log analizi nedir ve neden önemlidir?
SEO log analizi, arama motoru botlarının sitenizde gerçekte ne yaptığını sunucu kayıtları üzerinden inceleme yöntemidir. Bu yaklaşım yalnızca toplam bot trafiğini ölçmez; hangi URL’lerin tarandığını, hangi sayfaların gözden kaçtığını, kaynakların hangi URL kümelerinde tüketildiğini ve teknik sorunların tarama verimliliğini nasıl etkilediğini ortaya koymaya yardımcı olur.
Crawl budget, Google’ın bir site için tarayabildiği ve taramak istediği URL kümesini ifade eder. Bu kavram crawl capacity limit ve crawl demand olmak üzere iki temel bileşenden oluşur.
Küçük ve orta ölçekli sitelerde analize önce indeksleme durumu, robots.txt, sitemap, iç bağlantılar ve sunucu hataları kontrol edilerek başlanabilir. Crawl budget konusu özellikle çok büyük, sık değişen veya çok sayıda URL üreten sitelerde daha kritik hale gelir.
Crawl budget: kapasite ve talep arasındaki denge
Crawl kapasitesi; sunucu yanıt hızından, gecikmelerden, 5xx hatalarından ve 429 yanıtlarından etkilenebilir. Bu sinyaller kötüleştiğinde Google tarama hızını düşürebilir.
Crawl demand ise URL’nin popülerliği, güncelliği ve Google’ın algıladığı içerik değeri gibi unsurlarla ilişkilidir. Bu nedenle hedef, her URL’nin daha fazla taranmasını beklemekten çok mevcut tarama kaynaklarını değerli sayfalara yönlendirmektir.
Crawl budget, özellikle çok büyük, hızlı değişen veya Search Console’da yüksek oranda keşfedilmiş ancak indekslenmemiş URL bulunan sitelerde daha önemli hale gelir. Bu tür URL eşikleri yaklaşık sınıflandırmalardır; evrensel ve kesin sınırlar olarak değerlendirilmemelidir.
Analiz için hangi log verilerini toplamalısınız?
Pratik bir başlangıç olarak 7 ila 30 günlük access log penceresi kullanılabilir. Ancak bu süre sabit bir Google standardı değildir; yayın sıklığı, trafik hacmi ve sitenin güncellenme ritmine göre uyarlanmalıdır.
Minimum veri setinde zaman damgası, istenen URL, HTTP yöntemi, durum kodu, User-Agent, kaynak IP, referer, yanıt süresi, indirilen byte miktarı ve mümkünse host ile path alanlarını tutun. Bu alanlar, bot trafiğini URL ve performans boyutlarıyla birlikte incelemeyi kolaylaştırır.
Log alanları Apache, Nginx, CDN, load balancer ve uygulama altyapısına göre değişebilir. Bazı kurulumlarda kaynak IP, referer, byte miktarı veya ayrıntılı gecikme bilgisi bulunmayabilir.
Ham sunucu erişim logları, belirli URL’lerin Googlebot tarafından gerçekten istenip istenmediğini incelemek için en ayrıntılı veri kaynaklarından biridir.
Gerçek Googlebot trafiği nasıl doğrulanır?
Googlebot trafiği yalnızca User-Agent bilgisine göre doğrulanmamalıdır. Doğrulama için reverse DNS ve forward DNS kontrolleri veya Google’ın yayımladığı IP aralıkları kullanılabilir.
Uygulamada önce User-Agent alanıyla aday istekleri filtreleyin, ardından kaynak IP’yi doğrulayın. Reverse DNS sonucundaki hostname’in Googlebot alanına ait olması ve forward DNS çözümünde aynı IP’ye dönmesi, doğrulama akışının temel adımlarındandır.
Googlebot’un mobil ve masaüstü crawler türleri vardır. Loglarda crawler türü, User-Agent ve doğrulanmış IP ayrı boyutlar olarak tutulabilir.
Kısa dönemli istek pikleri tek başına anormal crawl veya saldırı kanıtı değildir. Bot doğrulaması, daha uzun zaman aralıkları ve sunucu üzerindeki gerçek etki birlikte değerlendirilmelidir.
URL’leri normalize edin ve anlamlı segmentlere ayırın
Ham loglarda aynı kaynağın farklı biçimlerde görünmesini önlemek için URL’leri normalize edin. Path, query parametresi, durum kodu, crawler türü ve zaman aralığına göre gruplar oluşturun; ardından 2xx, 3xx, 4xx, 5xx, 429 ve soft error kümelerini ayrı izleyin.
Sitemap URL’leri, iç linklerden çıkarılan URL envanteri ve iş açısından önemli sayfalar ayrı referans kümeleri olarak hazırlanabilir. Bu kümeleri doğrulanmış Googlebot loglarıyla eşleştirerek taranan, yakın dönemde taranmayan ve hiç taranmayan URL segmentlerini görünür hale getirin.
Taranma ile indekslenme farklı süreçlerdir. Bir URL’nin Googlebot tarafından istenmesi, indeksleneceği veya arama sonuçlarında görüneceği anlamına gelmez.
Bu ayrım raporlamanın temelidir: Loglarda bulunmayan bir URL’yi otomatik olarak indekslenmemiş kabul etmeyin. İndeksleme durumunu ayrı Search Console raporları ve URL Inspection gibi kaynaklarla kontrol edin.
Taranmayan önemli sayfaları nasıl bulabilirsiniz?
Önce iş açısından kritik URL listesini hazırlayın. Organik trafik getiren sayfalar, dönüşüm sağlayan kategoriler, güncel ürün veya hizmet sayfaları ve güçlü iç bağlantı alanları bu listenin parçası olabilir. Daha sonra bu URL’lerin sitemap ve iç link envanterindeki durumunu, doğrulanmış Googlebot istekleriyle karşılaştırın.
Önceliklendirmede ilk sıraya önemli olduğu halde hiç taranmayan URL’leri koyun. Ardından önemli URL’lerdeki sunucu hataları ve yüksek gecikmeleri, yüksek hacimli gereksiz URL kümelerini ve düşük değerli kaynakların aşırı taranmasını inceleyin. Bu sıra, resmî bir Google puanlama modeli değil, kaynaklardaki ilkelerden türetilmiş pratik bir analitik çerçevedir.
Raporunuzda en azından URL sınıfı, Googlebot istek sayısı, benzersiz URL sayısı, son crawl zamanı, durum kodu, ortalama ve p95 yanıt süresi, sitemap durumu, SEO önemi, önerilen aksiyon ve öncelik alanlarını gösterin.
Gereksiz URL ve parametreleri tespit edin
Faceted navigation, session identifier’lar, duplicate URL’ler, soft error sayfaları, sonsuz URL alanları ve düşük kaliteli içerikler düşük değerli veya gereksiz crawl kümeleri oluşturabilir.
Faceted navigation, çok sayıda filtre kombinasyonu üreterek overcrawling’e neden olabilir ve değerli yeni URL’lerin keşfini yavaşlatabilir.
Query string ve path desenlerini filtre kombinasyonları, duplicate varyantlar, oturum parametreleri ve sonuç üretmeyen URL’ler açısından gruplayın. Her küme için istek payını, benzersiz URL sayısını, durum kodlarını ve önemli URL’lere kıyasla tüketilen crawl kaynaklarını ölçün.
Duplicate URL’leri yönetmek için redirect, rel=canonical ve sitemap sinyalleri kullanılabilir. Robots.txt, canonicalization amacıyla kullanılmamalıdır.
Sitemap, iç linkler ve robots.txt ilişkisini yönetin
Sitemap, Google’a keşif ve tercih edilen URL kümesi hakkında sinyal verir. Aynı içerik birden fazla URL’de erişilebiliyorsa sitemap’te tercih edilen URL’nin yer alması önerilir.
Duplicate varyantların crawl hacmi yüksekse iç bağlantıları tercih edilen URL’lere yönlendirin, sitemap’te yalnızca tercih edilen URL’leri tutun ve uygun durumlarda redirect veya canonical düzenlemelerini değerlendirin.
Robots.txt ile taramayı engellemek, bir URL’nin arama sonuçlarında görünmesini kesin olarak engellemez. İndeksleme kontrolü için noindex gibi farklı sinyaller gerekir.
Bu nedenle robots.txt’yi her SEO sorununa yönelik tek çözüm olarak kullanmayın. Önce URL’nin arama sonuçlarında bulunmasını mı, yoksa yalnızca gereksiz taranmasını mı kontrol etmek istediğinizi netleştirin; ardından uygun sinyali teknik bağlam içinde değerlendirin.
Tarama hatalarını ve performans kayıplarını inceleyin
Uzun redirect zincirleri, yüksek yanıt veya oluşturma süreleri ve büyük gömülü kaynaklar crawl verimliliğini olumsuz etkileyebilir.
Hata analizini yalnızca toplam hata oranıyla sınırlamayın. Zaman serisini, URL kümelerini, yanıt süresi dağılımını, Googlebot yoğunluğunu, redirect zincirlerini ve 304 oranını birlikte inceleyin.
İçerik değişmediğinde 304 Not Modified yanıtları, önbelleğe alınan sürümün kullanılmasına yardımcı olarak bant genişliği ve sunucu kaynak tüketimini azaltabilir.
Crawl kapasitesini değerlendirirken yalnızca hata sayılarına değil, hataların hangi önemli URL’lerde oluştuğuna da bakın. Birkaç kritik sayfadaki yüksek gecikme, çok sayıda düşük önem dereceli hatadan daha acil bir teknik sorun olabilir.
Search Console verilerini loglarla birlikte okuyun
Search Console Crawl Stats raporu toplam istek, yanıt kodu, dosya türü, crawl amacı, Googlebot türü, indirilen veri ve ortalama yanıt süresi gibi toplu eğilimleri gösterir.
Crawl Stats raporunu site genelindeki eğilimleri görmek için kullanın; URL veya path bazında ayrıntılı tarama geçmişi gerektiğinde ham loglarla birlikte değerlendirin. Böylece toplu sinyalleri belirli URL kümeleri ve sunucu yanıtlarıyla ilişkilendirebilirsiniz.
Loglarda taranmayan bir URL’yi doğrudan indeksleme sorunu olarak yorumlamayın. Tarama davranışı, indeksleme durumu ve arama görünürlüğü farklı kontroller gerektirir.
Uygulanabilir bir SEO log analizi akışı
Tekrarlanabilir bir çalışma akışı şu şekilde kurulabilir: logları alın, veri alanlarını kontrol edin, gerçek Googlebot isteklerini doğrulayın, URL’leri normalize edin, durum kodu ve path bazında segmentlere ayırın, sitemap ve önemli URL kümeleriyle eşleştirin, gereksiz parametreleri ve hataları analiz edin, ardından aksiyonları etki ve uygulama maliyetine göre sıralayın.
İlk raporda yalnızca toplam Googlebot isteğini vermek yerine her URL sınıfının kaynak tüketimini ve SEO önemini birlikte gösterin. Böylece ekip, hangi sorunun daha çok istek ürettiğini değil, hangi sorunun değerli sayfaları daha fazla etkilediğini de görebilir.
7 ila 30 günlük log penceresi, p95 gecikme, crawl payı ve öncelik matrisi Google tarafından tanımlanmış evrensel eşikler değildir. Bunları Promogo’nun pratik metodolojisi olarak etiketleyin ve sitenin yayın sıklığı ile altyapısına göre uyarlayın.
En etkili başlangıç genellikle önemli fakat hiç taranmayan URL’leri belirlemek, önemli sayfalardaki sunucu hatalarını düzeltmek ve yüksek hacimli gereksiz URL kümelerini azaltmaktır. Bu yaklaşım, daha fazla taramayı garanti etmeye çalışmak yerine mevcut crawl kaynaklarının verimli kullanılmasına odaklanır.
Kaynaklar
- developers.google.com — crawl budget
- developers.google.com — crawling december resources
- developers.google.com — what crawl budget means for googlebot
- developers.google.com — troubleshoot crawling errors
- developers.google.com — search console crawl stats report
- developers.google.com — how to verify googlebot
- developers.google.com — googlebot
- developers.google.com — faceted navigation
- developers.google.com — crawling december faceted nav
- developers.google.com — crawling managing faceted navigation
- developers.google.com — build sitemap
- developers.google.com — crawling indexing
- developers.google.com — google analytics search console
- developers.google.com — canonicalization
- developers.google.com — consolidate duplicate urls
- developers.google.com — site move with url changes
