Kısa cevap: Log dosyası analizi, sunucunuzun ham erişim kayıtlarını okuyarak arama motoru botlarının hangi URL’leri, ne zaman ve hangi durum koduyla istediğini birebir görmenizi sağlar. Tarama simülatörleri ya da Search Console tahminlerinin aksine loglar, gerçek bot davranışının tek kesin kaydıdır. Onları boşa harcanan tarama bütçesini, Google’ın hâlâ ziyaret ettiği yetim sayfaları, yönlendirme zincirlerini ve hata artışlarını bulmak için kullanır, ardından her bulguyu somut bir teknik düzeltmeye dönüştürürsünüz.

SEO için log dosyası analizi tam olarak nedir?

Bir tarayıcı ya da bot sunucunuzdan bir şey her istediğinde, web sunucusu erişim kaydına bir satır yazar. Log dosyası analizi; bu satırları toplama, onları doğrulanmış arama motoru botlarına indirgeme ve Googlebot ile diğer botların sitenizde ne yaptığını anlatan gerçek bir günlük gibi okuma pratiğidir. Örnekleme yok, modelleme yok, hiçbir "tahmini" değer yok — log’da varsa olmuştur; yoksa olmamıştır.

Bu ayrım önemli, çünkü SEO’cuların güvendiği araçların çoğu eğitimli birer tahmindir. Bir tarama simülatörü, bir botun bağlantılarınızdan neyi keşfedebileceğini gösterir. Search Console’un tarama istatistikleri raporu yardımcı ama toplulaştırılmış bir özettir. Erişim kaydınız ise ikisinin de yaklaşmaya çalıştığı asıl kaynaktır. Çeliştiklerinde log kazanır; çünkü o bir yorum değil, doğrudan bir kayıttır. İşte bu yüzden log analizi, ciddi her teknik SEO denetiminin teknik çekirdeğinde durur — başka hiçbir veri kaynağının yanıtlayamadığı soruları yanıtlar.

Bir log satırının alan alan anatomisi

Erişim kayıtları, bir satırı parçalarına ayırana kadar gözünüzü korkutur. İşte alanlarını görebilmeniz için sarmalanmış tipik bir Apache combined-format satırı:

66.249.66.1 - - [01/Aug/2026:09:14:22 +0000] "GET /blog/log-file-analysis-seo HTTP/1.1" 200 18542 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Soldan sağa her alan size tek bir şey söyler:

  • İstemci IP’si (66.249.66.1) — isteği kim yaptı. Gerçek bir botu doğrulamak için DNS ile karşılaştırdığınız şey budur.
  • Zaman damgası ([01/Aug/2026:09:14:22 +0000]) — isteğin ne zaman geldiği, saat dilimiyle. Her sıklık ve trend analizinin temeli budur.
  • İstek yöntemi ve yolu (GET /blog/log-file-analysis-seo) — HTTP fiili ve alan adı olmadan istenen tam URL.
  • Durum kodu (200) — sunucunun yanıtı: 200 tamam, 301 yönlendirme, 404 bulunamadı, 5xx sunucu hatası.
  • Gönderilen bayt (18542) — yanıt boyutu; botun indirmek zorunda kaldığı şişmiş sayfaları yakalamakta işe yarar.
  • Yönlendiren ("-") — bu isteğe bağlantı veren sayfa, varsa. Botlar genelde hiç göndermez.
  • Kullanıcı aracısı (uzun Mozilla/5.0 ... Googlebot/2.1 dizesi) — istemcinin kendi beyan ettiği kimliği. Faydalı, ama tek başına asla güvenilmez.
Tek bir ham sunucu erişim-kaydı satırı, etiketli alanlara ayrılmış — istemci IP’si, zaman damgası, GET istek yolu, 200 ve 404 HTTP durum kodları, bayt ve vurgulanmış Googlebot kullanıcı aracısı — altında tarama isabetlerini site bölümüne göre gösteren küçük bir çubuk grafik.
Tek bir log satırı çözüldü: bir botun geride bıraktığı her alan, Googlebot kullanıcı aracısı ve durum kodları öne çıkarılmış.

Erişim kayıtlarınızı nasıl elde edersiniz?

Sahip olmadığınız logları analiz edemezsiniz; dolayısıyla ilk iş onları elde etmektir. Nerede durdukları teknoloji yığınınıza bağlıdır ama neredeyse her zaman bir yerlerde bulunurlar:

  • Apache — genellikle /var/log/apache2/access.log ya da vhost başına bir dosya. Varsayılan "combined" biçimi, ihtiyacınız olan yönlendiren ve kullanıcı aracısını içerir.
  • Nginx — tipik olarak /var/log/nginx/access.log. log_format’ın kullanıcı aracısını yakaladığından emin olun; paketle gelen combined biçimi yakalar.
  • CDN ve ters vekiller — Cloudflare, Fastly veya Akamai kaynağınızın önünde duruyorsa, birçok bot isteği kenarda yanıtlanır ve sunucunuza hiç ulaşmaz. Logları doğrudan CDN’den çekin, yoksa taramayı fena hâlde eksik sayarsınız.
  • Hosting kontrol panelleri — cPanel, Plesk ve yönetilen hostlar, kabuk erişimi olmadan indirebileceğiniz "Ham Erişim Kayıtları" sunar. Geçmiş korunsun diye log arşivlemeyi açın.
  • Yük dengeli kurulumlar — birden çok uygulama sunucusu varsa, logları her düğümden toplayıp birleştirin; yoksa trafiğin yalnızca bir dilimini görürsünüz.

En az birkaç haftalık kesintisiz log, ideal olarak bir ay veya daha fazlasını hedefleyin. Tarama dalgalıdır ve tek bir gün; desenler, bütçe ya da trendler hakkında size çok az şey söyler.

Gerçekten Googlebot mu doğrulayın — kullanıcı aracısına asla güvenmeyin

Bu, acemilerin atladığı ve sonrasındaki her şeyi geçersiz kılan adımdır. Kullanıcı aracısı dizesi kendi beyan edilen düz metindir: herkes Googlebot olduğunu iddia eden bir istek gönderebilir. Kazıyıcılar, spam botları ve rakipler bunu rutin olarak taklit eder. Taklit isabetleri gerçek tarama etkinliği sayarsanız, tüm analiziniz bir kurgudan ibarettir.

Güvenilir kontrol, istemci IP’si üzerinde Google’ın kendi belgelediği ters-sonra-ileri DNS aramasıdır:

  1. Log satırındaki IP’yi alın ve üzerinde ters DNS (PTR) araması yapın.
  2. Ana makine adının resmî bir Google alan adıyla — googlebot.com ya da google.com — bittiğini doğrulayın.
  3. O ana makine adı üzerinde ileri DNS araması yapın ve tam olarak aynı IP’ye çözümlendiğini doğrulayın.
  4. Yalnızca iki yön de eşleşirse isabet gerçek bir Googlebot isteğidir; aksi hâlde sahtekâr olarak eleyin.

Bing, DuckDuckGo ve saygın motorların çoğu aynı ters-ileri doğrulamayı destekler. Bunun yerine IP aralıkları yayımlayan botlar içinse adresi resmî listeyle karşılaştırın. Temiz, doğrulanmış alt küme; aşağıdaki analize besleyeceğiniz tek veridir — ve aynı disiplin, yapay zeka botları ve robots.txt denetimi yaparken loglarınızı okuma biçiminizin de temelidir.

Sayfa ve bölüme göre tarama sıklığı

Doğrulanmış bot isabetlerini elde ettikten sonra, ilginin gerçekte nereye aktığını görmek için onları URL’ye ve dizine göre gruplayın. En çok taranan URL’lerinizi azalan sırada dizin, bir hikâye ortaya çıkar: çoğu zaman tarama etkinliğinin büyük bir kısmı bir avuç sayfaya iner — ana sayfanız, üst kategoriler, filtreler — oysa önemsediğiniz sayfalar nadiren ziyaret edilir. Bölüme göre gruplamak (örneğin /blog/, /urunler/ ve /etiket/ karşılaştırması), Google’ın sitenin hangi kısımlarını zamanına değer bulduğunu gösterir.

En az taranan liste de en az onun kadar açıklayıcıdır. Google’ın ayda bir dokunduğu önemli, gelir getiren sayfalar, yaptığınız herhangi bir değişikliği yavaş yansıtır. Stratejik saydığınız bir bölüm neredeyse hiç görünmüyorsa, bu iç bağlantılarınızın ya da site haritanızın onu öne çıkarmadığının bir işaretidir. Google’ın görmezden geldiği sayfaları taze bir Teknik Site Denetimi (Tarayıcı) ile karşılaştırın ve iç bağlantı bakımından da zayıf olup olmadıklarına bakın — iki sorun genelde birlikte gezer.

Çöpe harcanan tarama bütçesini bulun

Tarama bütçesi sınırlıdır ve Google’ın işe yaramaz bir URL’ye harcadığı her istek, önemli bir sayfaya harcamadığı bir istektir. Loglar bu bütçenin tam olarak nereden sızdığını açığa çıkarır ve sızıntılar genelde belirli yerlerde yoğunlaşır:

  • Parametre ve filtre URL’leri — işlevsel olarak kopya olan bitmek bilmez ?sort=, ?filter= ve oturum kimliği çeşitleri. Googlebot bunların binlercesini dövüyorsa, gürültüye bütçe yakıyorsunuz demektir.
  • Yumuşak ve sert 404’ler — aynı ölü URL’lerde tekrarlanan 404 isabetleri, eski bağlantıların hâlâ takip edildiği anlamına gelir. Bağlantıları düzeltin ya da doğru durumu döndürün.
  • Yönlendirme zincirleri — başka bir 301’e, o da üçüncü bir URL’ye işaret eden bir 301, her sıçramada bir isteği boşa harcar. Zincirleri tek bir yönlendirmeye indirin.
  • Düşük değerli yollar — dizine hiçbir şey katmayan site içi arama sonuçları, takvim arşivleri, yazdırma sürümleri ve sonsuz sayfalama.

Çözümler standart alet çantasıdır: gerçekten işe yaramaz yolları robots.txt’de engelleyin, kopyaları kanonikleştirin, yönlendirme zincirlerini budayın ve bozuk bağlantıları onarın veya kaldırın. robots yönergelerinizi gerçek bot davranışına karşı Robots.txt Test Aracı, o 404 isabetlerini üreten ölü bağlantıları yakalamak için de Kırık Link Kontrolü kullanarak doğrulayın. Asıl derdiniz tarama bütçesiyse, tarama bütçesi optimizasyonu rehberimiz loglarınızın burada açığa çıkardığıyla doğrudan eşleşir.

Google’ın hâlâ ziyaret ettiği yetim sayfalar

Yetim sayfa, kendisine işaret eden hiçbir iç bağlantısı olmayan sayfadır — bir bot onu gezinmenizi izleyerek keşfedemez. Yine de loglar sıklıkla Googlebot’un, iç bağlantı grafiğinizde hiçbir yerde görünmeyen URL’leri istediğini gösterir. Nasıl? Google, eski site haritalarındaki, dış geri bağlantılardaki, tarihsel bağlantılardaki URL’leri ve kendi uzun hafızasını hatırlar; onları siz varlıklarını unuttuktan çok sonra bile kontrol etmeyi sürdürür.

Bu yetimler her iki yönde de önemlidir. Yetim kalmış değerli bir sayfa, aldığı taramayı boşa harcar; çünkü hiç iç otorite geçirmez ve kullanıcılar ona ulaşamaz — çözüm onu düzgünce bağlamaktır. Yetim ama hâlâ taranan bir çöp sayfa ise sessizce bütçe tüketir ve yönlendirmeniz veya emekliye ayırmanız gereken eski bir URL olabilir. Onları bulmak için loglarınızda görünen URL’lerin tümünü alın ve Teknik Site Denetimi (Tarayıcı) aracınızın tarayarak keşfettiği kümeyi çıkarın; geriye kalan her şey bağlanmadan isabet alıyor demektir ve her biri bir karar hak eder.

Zaman içinde durum kodları ve yanıt süreleri

Doğrulanmış botlara döndürülen durum kodlarının dağılımını gün gün çizin; bir erken uyarı sistemi elde edersiniz. Sağlıklı bir siteye, ince ve istikrarlı bir kasıtlı 301 şeridiyle birlikte 200 yanıtları hâkimdir. Tehlike işaretlerine dikkat edin:

  • Artan 404 payı — belki kötü bir taşıma ya da silinmiş bir bölüm, bir şey bozuk bağlantılar üretmeye başladı.
  • Sürekli herhangi bir 5xx hatası — Googlebot’a sunulan sunucu arızaları, logdaki en acil sorundur; çünkü tekrarlanan hatalar Google’ın taramayı yavaşlatmasına ve sayfaları düşürmesine yol açabilir.
  • Büyüyen 301/302 hacmi — zincirlere ya da kötü yönetilmiş bir URL değişikliğine işaret eden yönlendirme yayılması.

Yanıt boyutu ve log biçiminiz kaydediyorsa yanıt süresi, paralel bir hikâye anlatır. Googlebot’un ortalama getirme süresi tırmanıyorsa, sunucu tarama yükü altında yavaşlıyordur ve Google ne kadar istediğini kısabilir. Aniden baytça şişen bir sayfa, hem taramaya hem kullanıcılara zarar vermeden önce araştırmaya değer. Bir log kaydı sizi şaşırttığında, belirli bir URL’nin bir bota döndürdüğü durum kodlarını ve başlıkları HTTP Başlık Kontrolü ile doğrulayın.

Mobil ve masaüstü Googlebot karşılaştırması

Google web’i ağırlıklı olarak akıllı telefon kullanıcı aracısıyla tarar ve loglarınızdaki mobil-masaüstü Googlebot isabet oranı, siteniz için mobil öncelikli dizinlemenin tam anlamıyla yürürlükte olup olmadığını doğrular. Bugün hemen her site için, doğrulanmış Google isabetlerinin ezici çoğunluğu mobil Googlebot Smartphone kullanıcı aracısını taşımalıdır. Loglarınız hâlâ ağır bir masaüstü eğilimi gösteriyorsa ya da mobil bot masaüstünden farklı durum kodları alıyorsa, peşine düşmeye değer bir mobil eşitlik sorununuz var demektir.

Önemli olduğunda analizi cihaza göre bölümleyin: her kullanıcı aracısının hangi URL’leri istediğini ve mobil botun, masaüstü botun almadığı hataları alıp almadığını karşılaştırın. İkisi arasındaki farklı davranış çoğu zaman bir duyarlı-render hatasına, cihaza özgü bir yönlendirmeye ya da yalnızca bir biçim faktörüne sunulan içeriğe işaret eder.

Bulguları düzeltmelere dönüştürün

Analiz, bir şeyi değiştirene kadar değersizdir. Logdaki her desen somut bir eyleme karşılık gelir; bu yüzden onları öncelik sırasıyla ele alın:

  • Çöp URL’lerde yüksek tarama → robots.txt’de engelleyin, kanonik ekleyin, parametreleri düzenleyin.
  • Tekrarlayan 404’ler → kaynak bağlantıları düzeltin ya da kaldırın, veya URL’yi geri getirin.
  • Yönlendirme zincirleri → her sıçramayı doğrudan nihai hedefe işaret edecek şekilde yeniden yazın.
  • Nadiren taranan değerli sayfalar → iç bağlantıları güçlendirin ve onları site haritanıza dâhil edin.
  • Yetim sayfalar → iyi olanları bağlayın, kötüleri yönlendirin ya da emekliye ayırın.
  • Googlebot’a giden herhangi bir 5xx → bunu bir olay gibi ele alın ve önce sunucu kararlılığını düzeltin.

Sonra döngüyü kapatın: bir düzeltmeyi yayına aldıktan sonra, tarama davranışının gerçekten değiştiğini — daha az 404, öne çıkardığınız sayfalarda daha çok isabet, daha düz bir durum kodu grafiği — doğrulamak için logları izlemeyi sürdürün. Log analizi tek seferlik bir denetim değil, sürekli bir geri bildirim sinyalidir; onu tekrarlanabilir bir Sayfa İçi SEO Denetimi içine katmak, tarama bütçenizi size trafik kazandıran sayfalara yönlendirmeyi sürdürür.

Sıkça sorulan sorular

Log analizi Google Search Console’dan nasıl farklıdır?

Search Console’un tarama istatistikleri raporu, Google tarafından sağlanan toplulaştırılmış, örneklenmiş bir özettir. Erişim kaydınız ise kendi sunucunuzun yazdığı ham, eksiksiz kayıttır. Search Console size Google’ın kabaca ne kadar taradığını söyler; log ise her tam URL’yi, durum kodunu ve zaman damgasını söyler. Yön için Search Console’u, özellikle ikisi çeliştiğinde kesin gerçek için logu kullanın.

Neden sadece kullanıcı aracısı dizesine güvenemem?

Çünkü o, herkesin taklit edebileceği kendi beyan edilen bir metindir. Kazıyıcılar ve spam botları, engelleri aşmak için rutin olarak Googlebot olduğunu iddia eder. Taklit istekleri gerçek tarama sayarsanız, bütçe ve sıklık rakamlarınız anlamsızlaşır. Bir isabeti gerçek Googlebot saymadan önce her IP’yi ters-sonra-ileri DNS aramasıyla mutlaka doğrulayın.

Ne kadar log geçmişine ihtiyacım var?

En az iki ila dört haftalık kesintisiz log, bir ay veya fazlası ise daha iyidir. Tarama dalgalı ve düzensizdir; dolayısıyla tek bir gün desenleri, boşa harcanan bütçeyi ya da trendleri açığa çıkaramaz. Her seferinde sıfırdan başlamak yerine elinizde daima kayan bir pencere olsun diye log saklamayı açın ya da logları depolamaya aktarın.

Bir CDN, loglarımı okuma biçimimi değiştirir mi?

Evet, hem de belirgin biçimde. Cloudflare gibi bir CDN bot isteklerini kenarda yanıtladığında, o isabetler kaynak sunucunuza hiç ulaşmayabilir; dolayısıyla kaynak logları taramayı eksik sayar. Logları CDN katmanından da çekin ve DNS doğrulamanız çalışmayı sürdürsün diye gerçek istemci IP’sinin korunduğundan emin olun.

Aranacak en acil tek şey nedir?

Doğrulanmış Googlebot’a sunulan sürekli 5xx sunucu hataları. Tekrarlanan sunucu arızaları, Google’ın tarama hızını yavaşlatmasına ve sonunda etkilenen sayfaları dizinden düşürmesine yol açabilir. Gerçek bir bota giden 500 sınıfı yanıtların herhangi bir deseni, loglarınızdaki en yüksek öncelikli bulgudur ve her şeyden önce düzeltilmelidir.