Sunucu Log Analizi Nasıl Yapılır? Googlebot'u Gerçek Veriyle İzleme Rehberi

Googlebot sitenize her gün uğrar, ama hangi sayfalara gittiğini, hangilerini atladığını ve nerede hata aldığını yalnız sunucunuz bilir. Sunucu log analizi bu kaydı okuyup tahmini veriye dönüştürür. Bu rehberde Talha Aslan ve ekibi olarak sahada izlediğimiz yöntemi adım adım anlatıyoruz: Googlebot isteklerini ayırmak, sahte Googlebot trafiğini elemek, en çok ve hiç taranmayan adresleri bulmak, durum kodlarını yorumlamak ve sonucu Search Console verisiyle karşılaştırmak.

Peki bunu neden önemsiyoruz? Çünkü dış tarama araçları sitenizi kendi gözleriyle gezer; Googlebot ise kendi önceliklerine göre gezer. İki davranış çoğu zaman aynı değildir. Örneğin bir tarama aracı tüm ürün sayfalarına ulaşabilir, ama loglar Googlebot'un aylardır o sayfaların yarısına hiç gitmediğini gösterebilir. Ayrıca loglar, filtre parametreleri gibi gereksiz adreslerin tarama kapasitesini nasıl tükettiğini de ortaya çıkarır.

Kısacası log verisi, teknik SEO kararlarının kanıt katmanıdır. Bir robots.txt değişikliğinin, bir yönlendirme temizliğinin ya da iç link düzenlemesinin taramaya etkisini ancak bu kayıtla doğrudan görürsünüz. Bu yüzden büyük ve sık değişen sitelerde log incelemesini tek seferlik bir iş değil, düzenli bir kontrol olarak ele alıyoruz.

Erişim logu hangi bilgileri tutar?

Erişim logu (access log), sunucuya gelen her isteği tek satırda saklayan düz metin dosyasıdır. Biçim sunucu yazılımına göre değişir, ama SEO açısından ihtiyaç duyduğunuz alanları hemen hemen her kurulumda görürsünüz. Satırı okumayı öğrendiğinizde analizin yarısını tamamlamış olursunuz.

• İstemci IP adresi: isteği gönderen makinenin adresi; Googlebot doğrulamasının temeli budur.
• Tarih ve saat: isteğin zamanı; tarama sıklığını ve yoğun saatleri buradan çıkarırsınız.
• İstek satırı: yöntem (GET, HEAD gibi) ve istenen URL yolu, sorgu parametreleri dahil.
• Durum kodu: sunucunun verdiği yanıt; 200, 301, 404, 503 gibi.
• Yanıt boyutu: gönderilen bayt miktarı; boş ya da şüpheli derecede küçük yanıtları gösterir.
• Yönlendiren (referrer): isteğin hangi sayfadan geldiği; tarayıcılarda çoğu zaman boştur.
• User-agent: isteği yapanın kendini tanıttığı metin; Googlebot burada adını yazar.

Bazı kurulumlar yanıt süresini de kaydeder. Bu alan varsa çok değerlidir, çünkü yavaş yanıt veren URL grubunu doğrudan işaretler. Yoksa barındırma sağlayıcınızdan ya da geliştiricinizden log biçimine eklenmesini isteyebilirsiniz.

Log dosyalarına nereden ulaşırsınız?

İlk durak barındırma paneliniz olur. Paylaşımlı barındırmada erişim kayıtları genellikle panelde ham log ya da istatistik bölümü altında indirilebilir. Sanal ya da özel sunucuda ise kayıtlar sunucu yazılımının log klasöründe durur. Yetkiniz yoksa bu adımı sunucu yöneticinizden istemeniz en sağlıklı yoldur.

Siteniz bir içerik dağıtım ağı (CDN) arkasındaysa dikkatli olun. Bu durumda CDN isteklerin bir kısmını önbellekten yanıtlar ve bu istekler hiç kaynak sunucuya ulaşmaz. Dolayısıyla tam tabloyu görmek için CDN tarafının loglarını da almanız gerekir; aksi halde Googlebot'un sayfalarınızı olduğundan az taradığını sanabilirsiniz.

Bir de veri koruma boyutu var. IP adresi kişisel veri sayılabileceği için loglarda gerçek ziyaretçi kayıtları da yer alır. Bu nedenle dosyaları paylaşmadan önce yalnız tarayıcı satırlarını ayırmanızı ya da ziyaretçi IP'lerini maskelemenizi öneririz. Hangi yükümlülüklerin size uyduğunu hukuk danışmanınızla netleştirin; bu not hukuki danışmanlık değildir.

Kaç günlük log verisi yeterli olur?

Tek bir günün logu yanıltıcıdır. Googlebot bazı günler belirli bölümlere yoğunlaşır, bazı günler neredeyse hiç uğramaz. Bu yüzden en az birkaç haftalık, mümkünse bir aylık kesintisiz kayıtla çalışmayı tercih ediyoruz. Büyük sitelerde daha uzun dönem, mevsimsel ve yapısal değişimleri ayırt etmeyi kolaylaştırır.

Örnek senaryo: example.com adlı bir e-ticaret sitesi kategori yapısını değiştirdi ve iki hafta sonra trafik düştü. Değişiklikten önceki ve sonraki dönemi kapsayan loglar olmadan, Googlebot'un yeni adreslere ne zaman geçtiğini söylemek mümkün değildir. Dolayısıyla log saklama süresini önemli sürüm ve taşıma tarihlerini kapsayacak şekilde planlamak işinizi çok kolaylaştırır.

Öte yandan sınırsız saklama da doğru değildir. Hem disk alanı hem veri koruma açısından makul bir süre belirleyin, eski dosyaları sıkıştırıp sunucu dışına alın. Ayrıca her dönem için aynı filtreleri kullanın; böylece karşılaştırmalar gerçekten kıyaslanabilir olur.

Googlebot isteklerini loglarda nasıl ayırırsınız?

İlk filtre user-agent alanıdır. Googlebot istek yaparken bu alana kendi adını yazar; akıllı telefon ve masaüstü tarayıcıları ayrı tanımlarla gelir. Google'ın resmi Googlebot sayfasına göre sitelerin çoğu mobil öncelikli dizine eklendiği için isteklerin büyük kısmı akıllı telefon tarayıcısından gelir. Bu oran sizde tersse, sebebini mutlaka sorgulayın.

Ancak user-agent tek başına yeterli kanıt sayılmaz. Google'ın kendi belgesi, Googlebot'un user-agent başlığının başka tarayıcılar tarafından sıkça taklit edildiğini açıkça söyler. Yani "Googlebot" yazan her satır Google'dan gelmez. Bu nedenle ilk filtreden sonra mutlaka IP doğrulaması yapmanız gerekir.

Pratikte şu sırayı izliyoruz: önce adında Google geçen user-agent satırlarını ayırıyoruz, ardından bu satırlardaki benzersiz IP adreslerini çıkarıyoruz. Son olarak her IP'yi doğrulayıp yalnız gerçek Google adreslerinden gelen satırları analize alıyoruz. Böylece binlerce satır yerine birkaç yüz benzersiz IP ile uğraşırsınız. Googlebot'un genel çalışma mantığını merak ediyorsanız Googlebot nedir ve nasıl doğrulanır yazımıza göz atabilirsiniz.

Sahte Googlebot nasıl anlaşılır?

Google, Googlebot'u doğrulamak için iki resmi yol tarif eder. Birincisi ters DNS (reverse DNS) kontrolüdür ve Google'ın Google tarayıcılarını doğrulama belgesine göre çoğu kullanım için yeterlidir. Mantığı basittir: IP adresinin sahibini sorarsınız, gelen adı tekrar IP'ye çevirirsiniz ve iki ucun eşleşip eşleşmediğine bakarsınız.

1. Logdaki IP adresi için ters DNS sorgusu çalıştırın.
2. Dönen ana makine adının googlebot.com, google.com ya da googleusercontent.com ile bittiğini kontrol edin.
3. Bu ana makine adı için ileri DNS sorgusu yapın.
4. Sonucun logdaki IP adresiyle birebir aynı olduğunu doğrulayın.

Dört adımdan biri bile tutmuyorsa o istek Googlebot değildir. Örneğin ters DNS sonucu Google'a ait bir ad gösterse de ileri sorgu farklı bir IP döndürüyorsa, birisi DNS kaydını taklit ediyor olabilir. Bu tür satırları analizden çıkarın; gerekirse güvenlik ekibinizle paylaşın. Ters DNS kavramını e-posta tarafından tanıyorsanız PTR kaydı yazımız aynı mekanizmayı farklı bir açıdan anlatıyor.

IP aralığı listeleriyle otomatik doğrulama nasıl çalışır?

Binlerce IP'yi tek tek sorgulamak yavaştır. Bu nedenle Google ikinci bir yol sunar: tarayıcılarının kullandığı IP aralıklarını herkese açık JSON dosyalarında CIDR gösterimiyle yayımlar. Logdaki IP'yi bu aralıklarla karşılaştırırsınız; aralığa düşüyorsa isteği Google kaynaklı kabul edersiniz.

Resmi doğrulama sayfasında listelenen dosyalar tarayıcı türüne göre ayrışır: genel tarayıcılar için common-crawlers.json, özel durum tarayıcıları için special-crawlers.json ve kullanıcı tetiklemeli getiriciler için user-triggered-fetchers.json ile ilgili diğer dosyalar. Dosya adları ve kapsamı zamanla değişebilir, bu yüzden güncel listeyi her seferinde resmi sayfadan kontrol edin.

Pratik ipucu: listeleri bir kez indirip sonsuza kadar kullanmayın. Google aralıkları güncelleyebilir; eski bir listeyle gerçek Googlebot'u sahte sanabilirsiniz. Analizden hemen önce dosyaları yeniden almak en güvenli yoldur. Ayrıca iki yöntemi birleştirmek de mümkündür: aralık kontrolüyle toplu eleme yapar, şüpheli kalan birkaç IP'yi ters DNS ile teyit edersiniz.

Hangi Google tarayıcılarını ayrı değerlendirmelisiniz?

Google'ın tüm botları aynı amaçla gelmez. Resmi belgeler tarayıcıları üç gruba ayırır ve her grubun robots.txt ile ilişkisi farklıdır. Bu ayrımı yapmadan tüm Google isteklerini tek sepete koyarsanız, SEO ile ilgisi olmayan getiricileri tarama sorunu sanabilirsiniz.

SEO analizinde odak noktanız genel tarayıcılardır. Örneğin AdsBot isteklerini reklam açılış sayfası kontrolü olarak ayrı bir sekmede tutmak, Googlebot verisini temiz bırakır. Benzer şekilde yapay zeka botlarını da ayrı gruplayın; bu konuyu AI crawler yazımızda ayrıca ele aldık.

Sunucu log analizi adım adım nasıl yapılır?

Yöntemi bir kez oturttuğunuzda her dönem aynı adımları tekrar edersiniz. Aşağıdaki sıra, bizim teknik SEO denetimlerinde kullandığımız iskelettir. Komut ya da yazılım adı vermiyoruz, çünkü aynı işi tablo programıyla da, log analizi aracıyla da yapabilirsiniz.

1. Analiz dönemini seçin ve o döneme ait tüm sunucu ile CDN loglarını toplayın.
2. Satırları ortak bir biçime getirin: IP, zaman, URL, durum kodu, boyut ve user-agent sütunları.
3. Google adı geçen user-agent satırlarını ayırın, benzersiz IP listesini çıkarın.
4. IP'leri resmi aralık listeleri ya da ters DNS ile doğrulayın, sahte satırları atın.
5. URL'leri şablonlara göre gruplayın: kategori, ürün, blog, filtre, arama, statik dosya.
6. Her grup için istek sayısını, durum kodu dağılımını ve son tarama tarihini hesaplayın.
7. Sonuçları site haritası ve tarama aracı listesiyle karşılaştırıp eksik ve fazla taramayı işaretleyin.
8. Bulguları Search Console Tarama İstatistikleri raporuyla çapraz kontrol edin.

Küçük bir siteyle başlıyorsanız ücretsiz log analizi aracımız ilk filtreleri hızlıca görmenizi sağlar. Ancak büyük bir sitede sunucu log analizi şablon gruplama ve düzenli tekrar ister; bu noktada süreci SEO danışmanlığı hizmetimiz kapsamında sizin yerinize kurup takip ediyoruz.

En çok taranan URL'ler size ne söyler?

Tarama sıklığı sıralaması, Googlebot'un sitenizde neyi önemli ya da sorunlu bulduğunu gösterir. Ana sayfa ve güçlü kategoriler listenin başında olabilir; bu normaldir. Asıl uyarı işareti, listenin üst sıralarını değersiz adreslerin doldurmasıdır.

• Sıralama, renk ve beden gibi filtre parametreleriyle türeyen sonsuz URL kombinasyonları.
• Site içi arama sonuç sayfaları ve boş sonuç döndüren aramalar.
• Takvim, sayfalama ya da oturum kimliği içeren adresler.
• Sepete ekleme, karşılaştırma gibi işlem URL'leri.

Bu gruplar tarama isteklerinin önemli bir kısmını tüketiyorsa, Googlebot'un değerli sayfalara ayırdığı zaman azalır. Öte yandan her durumda robots.txt ile engellemek doğru çözüm değildir; önce iç linklerin bu adresleri neden ürettiğine bakın. Filtre yapılarını faceted navigation yazımızda ayrıntılı anlattık. Ayrıca aynı içeriğe sürekli dönen tarama, sayfanın sık değiştiğini düşündüren bir sinyal de olabilir; bunu son değişiklik tarihleriyle birlikte yorumlayın.

Hiç taranmayan önemli sayfaları nasıl bulursunuz?

Bu soru log incelemesinin en değerli çıktısını verir. Yöntem basit bir küme farkıdır: olması gereken URL listesini çıkarırsınız, logda Googlebot'un istediği URL listesiyle karşılaştırırsınız. İlk listede olup ikincide olmayan her adres, dönem boyunca hiç taranmamış demektir.

Olması gereken listeyi üç kaynaktan kurarız: XML site haritası, kendi tarama aracınızın bulduğu dizine eklenebilir sayfalar ve satıştaki ürün ya da yayındaki içerik veritabanı. Örneğin bir sitede yüzlerce ürün site haritasında görünse de logda hiç istek almamışsa, büyük olasılıkla iç link yapısında derinde kalmıştır.

Bu noktada tıklama derinliği belirleyici olur. Ana sayfadan çok sayıda tıkla ulaşılan sayfalar daha seyrek taranma eğilimindedir; konuyu tıklama derinliği (crawl depth) yazımızda ele aldık. Ayrıca taranmayan sayfaların Search Console'da hangi durumda göründüğüne bakın; Keşfedildi, şu anda dizine eklenmedi (Discovered, currently not indexed) durumu çoğu zaman aynı tabloyu işaret eder.

Durum kodu dağılımı nasıl okunur?

Googlebot'un aldığı yanıtların dağılımı, sitenizin taramaya ne kadar temiz kapı açtığını gösterir. Google'ın HTTP durum kodları ve ağ hataları belgesi her kod ailesinin nasıl işlendiğini açıklar. Aşağıdaki tablo, logdan çıkardığınız dağılımı yorumlarken kullandığımız özettir.

Sağlıklı bir dağılımda 200 yanıtları baskındır. Yönlendirme ve 404 oranı yükseliyorsa, iç linkleriniz eski adreslere işaret ediyor olabilir. 304 davranışını merak ediyorsanız 304 Not Modified yazımız konuyu açıyor.

5xx ve 429 yanıtları taramayı neden yavaşlatır?

Google'ın resmi belgesine göre 5xx ve 429 yanıtları, tarayıcıların taramayı geçici olarak yavaşlatmasına yol açar. Sunucu yeniden 2xx yanıt vermeye başladığında tarama hızı kademeli olarak geri gelir. Yani kısa bir kesinti bile birkaç gün boyunca daha az tarama olarak logda iz bırakabilir.

Bu yüzden 5xx satırlarını yalnız saymayın; zamana yayın. Örnek senaryo: hata satırları her gece aynı saat aralığında yoğunlaşıyorsa, sebep büyük olasılıkla o saatte çalışan yedekleme ya da toplu işlemdir. Benzer şekilde hatalar tek bir URL şablonunda toplanıyorsa, sorun o şablonun sorgusundadır.

Bir de 429 tuzağı var. Güvenlik eklentileri ve hız sınırlayıcılar bazen Googlebot'u sıradan bir bot gibi kısıtlar. Google 429'u aşırı yük sinyali saydığı için taramayı düşürür. Öte yandan 401 ve 403 gibi kodlar resmi belgeye göre tarama hızını etkilemez; dolayısıyla taramayı kısmak için bu kodlara başvurmamalısınız. Tarama düşüşünün diğer nedenlerini Googlebot neden daha az tarar yazımızda topladık.

Yönlendirme zincirleri loglarda nasıl görünür?

Logda bir zincir, aynı tarayıcının kısa aralıklarla art arda istediği ve her biri 3xx dönen adresler biçiminde belirir. Örneğin önce http adresi, sonra https adresi, ardından sonda eğik çizgi eklenmiş adres istenir. Her adım ayrı bir istektir ve tarama kapasitesinden pay alır.

Google'ın belgesine göre tarayıcılar varsayılan olarak en fazla 10 yönlendirme adımını izler. Ancak sınıra yaklaşmadan önce bile zincirler gereksiz istek üretir. Bu nedenle logda 3xx alan URL'leri hedefleriyle eşleştirip iki ya da daha fazla adım süren yolları listeleyin; ardından iç linkleri doğrudan son adrese çevirin.

İşin pratik tarafı şudur: zincirin kaynağı çoğu zaman eski menü linkleri, site haritasında unutulmuş adresler ya da kanonik etiketlerdeki eski URL'lerdir. Kaynağı düzeltmezseniz yönlendirme kurallarını ne kadar temizlerseniz temizleyin, Googlebot aynı yolu yürümeye devam eder. Ayrıntılı çözüm adımları için yönlendirme zinciri yazımıza bakabilirsiniz.

Search Console Tarama İstatistikleri raporuyla loglar nasıl karşılaştırılır?

Search Console'daki Tarama İstatistikleri raporu (Crawl Stats), Mülk ayarları altında yer alır ve Google tarafından görülen tarama verisini özetler. resmi yardım sayfasına göre rapor yalnız kök düzeydeki mülklerde, yani alan adı mülkünde ya da kök düzey URL ön eki mülkünde kullanılabilir.

Raporda üç ana grafik yer alır: Toplam tarama istekleri, Toplam indirme boyutu ve Ortalama yanıt süresi. Bunların yanında Ana makinenin durumu bölümü robots.txt getirme, DNS çözümleme ve sunucu bağlantısı sorunlarını gösterir. Ayrıca Tarama yanıtları, Taranan dosya türleri, Tarama amacı ve Googlebot türü kırılımları vardır.

Karşılaştırmayı şöyle yaparız: aynı tarih aralığı için logdaki doğrulanmış Googlebot istek sayısını rapordaki toplamla yan yana koyarız. Ardından durum kodu yüzdelerini ve Googlebot türü dağılımını eşleştiririz. Trend çizgileri benzer yönde ilerliyorsa veri toplama doğru demektir. Search Console'un genel kullanımı için Google Search Console rehberimize göz atabilirsiniz.

Log verisi ile Search Console neden birebir tutmaz?

İki kaynak arasında küçük farklar görmeniz normaldir; Search Console Yardım sayfası da bazı isteklerin sayılmayabileceğini ve toplamların sunucu loglarından biraz farklı olabileceğini belirtir. Farkın kaynağını bilmek, yanlış alarmı önler.

• Rapor yalnız seçili alan adını kapsar; başka alan adında barındırılan görseller gibi istekler dahil değildir.
• Rapor yönlendirme zincirindeki her isteği ayrı sayar ve veriyi kanonik URL'ye atamaz.
• Raporda http ve https istekleri toplamda birlikte yer alır.
• CDN önbelleğinden yanıtlanan istekler kaynak sunucu logunda hiç görünmeyebilir.
• Örnek URL listeleri temsilidir, eksiksiz bir döküm değildir.

Peki fark ne zaman soruna işaret eder? Logdaki sayı rapordan belirgin biçimde düşükse, büyük olasılıkla bir log kaynağını eksik topluyorsunuz, örneğin CDN tarafını. Logdaki sayı belirgin biçimde yüksekse, sahte Googlebot satırları doğrulamadan geçmiş olabilir. Her iki durumda da önce toplama ve doğrulama adımlarınızı gözden geçirin.

Keşfetme ve Yenileme oranı ne anlatır?

Tarama amacı kırılımı iki değer gösterir: Keşfetme, Google'ın daha önce hiç taramadığı URL'lere giden istekleri; Yenileme ise bilinen sayfaların yeniden taranmasını ifade eder. Bu ayrım, sitenizin büyüme dönemlerinde özellikle işe yarar.

Örnek senaryo: example.com yüzlerce yeni ürün ekledi, ama Keşfetme payı neredeyse hiç değişmedi. Bu tablo, yeni sayfaların iç linklerle ya da site haritasıyla yeterince duyurulmadığını düşündürür. Logda da aynı ürün adreslerine ilk isteğin ne zaman geldiğine bakarak gecikmeyi gün olarak ölçebilirsiniz.

Tersine, Keşfetme payı sürekli yüksekse ve yeni içerik eklemiyorsanız dikkat edin. Bu durum çoğu zaman parametreli adreslerin ya da sonsuz sayfalama yapısının sürekli yeni URL ürettiğini gösterir. Böylece Googlebot gerçek içerik yerine yapay olarak türeyen adresleri keşfetmekle meşgul olur. Logdaki URL şablon gruplaması bu yeni adreslerin hangi kaynaktan çıktığını hızla gösterir.

Dosya türü ve yanıt süresi verisi neyi gösterir?

Taranan dosya türleri kırılımı HTML, görsel, JavaScript, CSS ve PDF gibi türlerin payını gösterir. Logda da aynı ayrımı uzantı ya da içerik türüne göre yaparsınız. JavaScript ve CSS istekleri yüksekse, Googlebot sayfaları işlemek için bu kaynakları indiriyor demektir; bu kaynakları gereksiz yere engellemediğinizden emin olun.

Ortalama yanıt süresi ise tarama kapasitesiyle doğrudan ilişkilidir. Google'ın tarama bütçesi belgesi, sunucu hızlı ve sağlıklı yanıt verdiğinde tarama kapasitesi sınırının yükselebileceğini, hatalarda ise düştüğünü anlatır. Logda yanıt süresi alanı varsa, en yavaş URL şablonlarını listeleyip geliştirici ekibinize öncelik sırasıyla iletin.

Bir ayrıntı daha: Googlebot resmi belgeye göre desteklenen bir dosyanın sıkıştırılmamış halinin ilk 2 MB'lık kısmını getirir. Logdaki yanıt boyutu alanı, bu sınıra yaklaşan aşırı büyük HTML sayfalarını yakalamak için de iyi bir filtredir. Örneğin satır içine gömülmüş devasa veri blokları sayfa boyutunu fark ettirmeden şişirebilir.

Hangi sitelerde sunucu log analizi öncelikli olmalı?

Her site için aynı derinlikte bir incelemeye gerek yoktur. Google'ın tarama bütçesi rehberi, kabaca bir tahmin olarak bir milyondan fazla benzersiz sayfası olan ve haftalık değişen siteleri ya da on binden fazla sayfası olup içeriği günlük değişen siteleri hedef kitle olarak tanımlar. Bu sitelerde sunucu log analizi neredeyse zorunludur.

Ancak küçük sitelerde de log incelemesi şu durumlarda hızlı cevap verir:

• Site taşıma ya da alan adı değişikliğinden sonra Googlebot'un yeni adreslere geçişini izlerken.
• Search Console'da çok sayıda Keşfedildi, şu anda dizine eklenmedi durumu görürken.
• Ani trafik düşüşlerinden sonra sunucu hatalarını dışlamak isterken.
• Bir güvenlik katmanının botları engellediğinden şüphelendiğinizde.

Tarama bütçesinin kimleri gerçekten ilgilendirdiğini tarama bütçesi yazımızda ayrıntılı tartıştık. Kısacası ölçek büyüdükçe log verisinin değeri artar.

Log analizinde en sık yapılan yorum hataları nelerdir?

Teknik olarak doğru topladığınız veriyi yanlış okumak da mümkündür. Sahada en sık karşılaştığımız hatalar şunlardır:

• User-agent filtresiyle yetinip sahte Googlebot satırlarını analize katmak.
• Yalnız birkaç günlük veriyle kalıcı sonuç çıkarmak.
• CDN loglarını unutup kaynak sunucudaki eksik tabloyu gerçek sanmak.
• AdsBot gibi özel tarayıcıları organik tarama verisine karıştırmak.
• Yüksek tarama sıklığını otomatik olarak iyi sıralama sinyali saymak.
• Soft 404 sayfalarını 200 yanıt aldıkları için sağlıklı kabul etmek.

Son madde özellikle önemlidir. Google'ın tarama bütçesi belgesi, soft 404 sayfalarının taranmaya devam ettiğini ve bütçeyi boşa harcadığını belirtir. Yani logda 200 dönen her satır gerçek içerik anlamına gelmez; yanıt boyutu çok küçük olan 200 satırlarını ayrıca inceleyin. Tespit yöntemini soft 404 yazımızda anlattık.

Bulguları nasıl önceliklendirip aksiyona çevirirsiniz?

Log incelemesi uzun bir sorun listesi üretir; hepsine aynı anda saldırmak verimsizdir. Biz bulguları iki eksende sıralarız: etkilenen URL sayısı ve o URL'lerin iş değeri. Satış ya da talep getiren şablonlardaki 5xx ve taranmama sorunları ilk sıraya, düşük değerli parametre adresleri sonraya gelir.

Her aksiyonun yanına bir ölçüm noktası koyun. Örneğin filtre adreslerini sınırladıysanız, iki ila dört hafta sonra aynı filtrelerle yeni bir log dönemi alıp o grubun istek payını yeniden hesaplayın. Böylece değişikliğin işe yarayıp yaramadığını tahminle değil, aynı ölçüyle görürsünüz.

Son olarak, log bulgularını sıralama vaadiyle karıştırmayın. Daha temiz bir tarama, Google'ın içeriğinizi daha verimli bulmasına yardım eder; ancak sıralama içerik kalitesi ve başka pek çok etkene bağlıdır. Bu nedenle log çalışmasını teknik temelin bir parçası olarak görün, tek başına bir büyüme kaldıracı olarak değil.

Bu çalışmayı sitenizde birlikte nasıl yürütürüz?

Talha Aslan ve ekibi olarak log incelemesini teknik SEO denetiminin kanıt katmanı olarak ele alıyoruz. Logları toplama ve doğrulama düzenini kuruyor, URL şablonlarını gruplayıp düzenli raporlar çıkarıyor, bulguları geliştirici ekibinize uygulanabilir görevler olarak aktarıyoruz. Ardından aynı ölçüyle düzeltmelerin etkisini takip ediyoruz.

Sıralama garantisi vermiyoruz; Google'ın kararlarını kimse önceden taahhüt edemez. Ancak taramanın nerede tıkandığını kayıtla gösterip sorunu sitenizde çözmeyi ve sonrasını izlemeyi üstleniyoruz. Sitenizin büyüklüğüne ve log erişiminize göre kapsamı netleştirmek için SEO danışmanlığı sayfamızdan teklif isteyebilirsiniz.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.