Log Analizi ile SEO: Googlebot'un Gerçek Davranışını Keşfedin

Google Search Console size sitenizin arama performansını gösterir; ancak Googlebot’un sitenizde gerçekte ne yaptığını, hangi sayfaları kaçırdığını, hangi URL’leri defalarca ziyaret ettiğini ya da hangi hatalarla karşılaştığını söylemez. Bu boşluğu yalnızca bir araç doldurabilir: log dosyası analizi.

Sunucu logları, sitenize gelen her isteğin ham kaydıdır. Googlebot dahil tüm botların ve gerçek kullanıcıların sitenizle nasıl etkileşime girdiğini, zaman damgasına kadar hassas biçimde belgeler. Bu veriler doğru okunduğunda, teknik SEO’nun en değerli içgörülerinden bazılarını üretir: hangi sayfaların hiç taranmadığını, crawl bütçesinin nereye harcandığını ve hangi URL yapılarının botlar için engel oluşturduğunu net olarak ortaya koyar.

Bu rehberde log analizinin ne olduğunu, nasıl yapıldığını, hangi araçların kullanıldığını ve elde edilen bulgulardan nasıl eyleme geçildiğini adım adım ele alacağız.

Log Analizi Nedir ve Neden SEO İçin Kritik Öneme Sahiptir?

Bir ziyaretçi ya da bot sitenize istek gönderdiğinde, web sunucunuz bu isteğin tüm ayrıntılarını bir metin dosyasına yazar. Bu dosyalara erişim günlüğü (access log) adı verilir. Her satır; isteğin zamanını, kaynak IP adresini, istenen URL’yi, HTTP yöntemini, sunucunun döndürdüğü durum kodunu, döndürülen veri boyutunu ve istek yapan ajanın (user agent) kimliğini içerir.

Log analizi; bu ham verileri toplamak, filtrelemek, gruplamak ve SEO kararları almak için anlamlı hale getirmek sürecidir.

Neden Google Search Console Yeterli Değil?

Google Search Console harika bir araçtır; ancak sunduğu veriler Google’ın size görmesini istediği verilerdir. Search Console’daki “Kapsam” raporu hangi sayfaların dizine eklendiğini gösterir; ama Googlebot’un sunucunuza ne sıklıkla bağlandığını, 3xx yönlendirme zincirlerini kaç kez takip ettiğini ya da 5xx sunucu hataları nedeniyle geri döndüğünü göstermez. Loglar ise tarafsız bir hakemdir; gerçekte olanı kaydeder.

Log analizinin Search Console’un ötesine geçtiği başlıca durumlar şunlardır:

• Gizli crawl bütçesi israfı: Googlebot, robots.txt ile engellenmiş URL’leri yine de deneyebilir; ya da parametre bazlı URL’lere bütçenizin büyük bölümünü harcayabilir. Bu durum Search Console’da görünmez, loglarda görünür.
• Bot trafiğini gerçek trafikten ayırt etme: Analytics araçları bot trafiğini büyük ölçüde filtreler. Loglar tüm botları yakalar ve Googlebot ile zararlı tarayıcılar arasındaki farkı net olarak ortaya koyar.
• Dizin dışı içeriklerin taranıp taranmadığını doğrulama: Noindex etiketi sayfanın dizine eklenmemesini söyler; ama Googlebot o sayfayı taramaya devam eder. Loglar bu davranışı doğrular.
• Yeni içeriklerin ne kadar hızlı keşfedildiğini ölçme: Yeni bir sayfa yayımladığınızda Googlebot’un onu kaç gün içinde bulduğunu yalnızca loglardan öğrenebilirsiniz.

Crawl budget nedir ve nasıl yönetilir konusunda daha önce kapsamlı bir rehber hazırladık; log analizi ise bu bütçenin gerçekte nasıl harcandığını görmenin birincil yoludur.

Access Log Formatı: Apache ve Nginx

Log analizine başlamadan önce log dosyalarının yapısını anlamak gerekir. İki en yaygın web sunucusu olan Apache ve Nginx, varsayılan olarak birbirine çok benzer bir format kullanır.

Apache Combined Log Format

Apache’nin en yaygın log formatı Combined Log Format olarak bilinir. Bir satır şu şekilde görünür:

203.0.113.52 - - [13/Jul/2026:09:14:22 +0300] "GET /blog/teknik-seo-rehberi HTTP/1.1" 200 14823 "https://www.google.com/" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Bu alanların anlamı şöyledir:

Nginx Default Log Format

Nginx’in varsayılan log satırı yapı olarak Apache’ye benzer ancak zaman biçimi farklıdır:

203.0.113.52 - - [13/Jul/2026:09:14:22 +0300] "GET /urun/mavi-sneaker?renk=lacivert&beden=42 HTTP/1.1" 200 9341 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Log Dosyası Nerede Bulunur?

Sunucu türüne ve yapılandırmasına göre log dosyalarının konumu değişir:

# Apache (Debian/Ubuntu)
/var/log/apache2/access.log

# Apache (CentOS/RHEL)
/var/log/httpd/access_log

# Nginx
/var/log/nginx/access.log

# Paylaşımlı hosting cPanel
/home/kullaniciadiniz/logs/siteniz.com-ssl_log

Büyük sitelerde log dosyaları günlük olarak döndürülür ve sıkıştırılır; access.log.1, access.log.2.gz gibi adlar alır. SEO analizi için genellikle son 30 ile 90 günlük loglar yeterlidir.

Googlebot User Agent Tanımlama

Log dosyalarında Googlebot’u diğer isteklerden ayırt etmek için user agent alanını filtrelemek gerekir. Googlebot’un resmi user agent dizeleri şunlardır:

# Masaüstü Googlebot
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

# Mobil Googlebot (Smartphone)
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

# Google AdsBot (reklam kalite değerlendirmesi)
AdsBot-Google (+http://www.google.com/adsbot.html)

# Google Image Bot
Googlebot-Image/1.0

# Google Video Bot
Googlebot-Video/1.0

# Google News Bot
Googlebot-News

# Googlebot için Google'ın yapay zeka içerik değerlendirmesi (2025+)
Google-InspectionTool/1.0

Googlebot IP Aralıklarını Doğrulama

Önemli bir uyarı: User agent taklit edilebilir. Zararlı botlar kendilerini Googlebot olarak tanıtabilir. Gerçek Googlebot’u doğrulamanın yolu IP adresini kontrol etmektir. Google, Googlebot IP aralıklarını JSON formatında yayımlar:

https://developers.google.com/search/apis/ipranges/googlebot.json

Loglardan çektiğiniz Googlebot isteklerinin IP adreslerini bu JSON dosyasıyla karşılaştırmak, sahte botları ayıklamanıza olanak tanır. Büyük ölçekli analizlerde bu doğrulamayı otomatikleştirmek için Python veya log analiz araçları kullanılabilir.

Googlebot ile Diğer Botları Ayırt Etme

Bir web sitesinin log dosyaları, onlarca farklı bot tarafından üretilen isteklerle doludur. SEO odaklı bir analizde bunları birbirinden net biçimde ayırt etmek gerekir.

Aşağıdaki tablo, yaygın botları ve SEO analizi açısından önemlerini özetlemektedir:

SEO analizi yaparken önceliğiniz Googlebot ve Googlebot Mobile olmalıdır. Bununla birlikte, Ahrefs, Semrush ve Moz gibi ticari SEO araçlarının botları da crawl bütçenizi tüketir; bu botların aktivitesini izleyip robots.txt ile sınırlandırmayı değerlendirmelisiniz.

SEO İçin Log Analizi Araçları

Ham log dosyalarını okuyabilir; ancak makul bir veriyi anlamlandırmak için araçlara ihtiyaç duyarsınız. Kullanım amacınıza ve teknik altyapınıza göre birkaç farklı yaklaşım mevcuttur.

1. Screaming Frog Log File Analyser

Screaming Frog, popüler SEO tarama aracının yanı sıra yalnızca log analizi için özel bir uygulama sunmaktadır. Windows ve macOS’ta çalışan bu masaüstü uygulaması, Apache ve Nginx log dosyalarını doğrudan içe aktarabilir.

Öne çıkan özellikler:

• Googlebot ve diğer botlar için otomatik filtreleme
• Durum kodu dağılımı grafikleri
• En çok taranan URL’lerin listelenmesi
• Screaming Frog SEO Spider ile entegrasyon: taranan URL’leri spider verileriyle karşılaştırabilirsiniz
• Crawl frekansı analizi: hangi URL’nin hangi sıklıkta tarandığını gösterir

Küçük ve orta ölçekli sitelerde (günde birkaç yüz bin satıra kadar) Screaming Frog Log Analyser hızlı ve pratik bir çözümdür. Ücretsiz sürümde 1.000 URL sınırı vardır; profesyonel kullanım için ücretli lisans gerekir.

2. ELK Stack (Elasticsearch, Logstash, Kibana)

Büyük ölçekli siteler için endüstrinin standart çözümü ELK Stack’tir. Logstash ile logları toplayıp ayrıştırabilir, Elasticsearch’te indeksleyebilir ve Kibana’nın görsel dashboard’larıyla analiz edebilirsiniz.

Örnek bir Logstash yapılandırması:

input {
  file {
    path => "/var/log/nginx/access.log"
    start_position => "beginning"
    type => "nginx_access"
  }
}

filter {
  grok {
    match => {
      "message" => "%{COMBINEDAPACHELOG}"
    }
  }
  useragent {
    source => "agent"
    target => "useragent"
  }
  if [agent] =~ /Googlebot/ {
    mutate { add_tag => ["googlebot"] }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "nginx-logs-%{+YYYY.MM.dd}"
  }
}

Bu yapılandırmayla Kibana’da şu sorguları çalıştırabilirsiniz:

• Son 30 günde Googlebot’un tarattığı benzersiz URL sayısı
• Googlebot’a döndürülen durum kodlarının dağılımı
• Saatlik ve günlük Googlebot istek yoğunluğu grafikleri
• En çok 404 dönen URL’lerin listesi

ELK Stack kurulumu teknik bilgi gerektirir; ancak kurulduktan sonra gerçek zamanlı log takibi ve tarihi karşılaştırma için eşsiz bir esneklik sunar.

3. Splunk

Splunk, kurumsal ölçekte log yönetimi ve analizi için kullanılan güçlü bir platformdur. Özellikle büyük e-ticaret siteleri, bankalar ve kurumsal yapılarda yaygın biçimde kullanılır.

Googlebot aktivitesini Splunk’ta sorgulamak için Search Processing Language (SPL) kullanılır:

index=web_logs sourcetype=access_combined
| where like(useragent, "%Googlebot%")
| timechart span=1d count as "Günlük Googlebot İsteği"

Durum kodu dağılımı için:

index=web_logs sourcetype=access_combined
| where like(useragent, "%Googlebot%")
| stats count by status
| sort -count

Splunk’un güçlü yanı, log verilerini diğer iş verileriyle birleştirebilmesidir; örneğin Googlebot aktivitesiyle e-ticaret dönüşümlerini aynı dashboard’da görmek mümkündür.

4. Python ve pandas ile Özel Analiz

Dışarıya veri çıkarmak istemiyorsanız ya da tam esneklik arıyorsanız Python, güçlü ve ücretsiz bir alternatiftir. pandas kütüphanesi ile log dosyalarını dakikalar içinde analiz edebilirsiniz.

import pandas as pd
import re

# Log satırını ayrıştırmak için regex deseni
LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<url>\S+) \S+" '
    r'(?P<status>\d{3}) (?P<size>\S+) '
    r'"(?P<referer>[^"]*)" "(?P<useragent>[^"]*)"'
)

def parse_log_line(line):
    match = LOG_PATTERN.match(line)
    if match:
        return match.groupdict()
    return None

# Log dosyasını yükle
rows = []
with open('/var/log/nginx/access.log', 'r', encoding='utf-8', errors='ignore') as f:
    for line in f:
        parsed = parse_log_line(line.strip())
        if parsed:
            rows.append(parsed)

df = pd.DataFrame(rows)
df['status'] = df['status'].astype(int)

# Yalnızca Googlebot isteklerini filtrele
googlebot_df = df[df['useragent'].str.contains('Googlebot', na=False)]

# Durum kodu dağılımı
print("Durum Kodu Dağılımı:")
print(googlebot_df['status'].value_counts())

# En çok taranan URL'ler
print("\nEn Çok Taranan 20 URL:")
print(googlebot_df['url'].value_counts().head(20))

# Tarama derinliği analizi (URL dizin derinliği)
googlebot_df = googlebot_df.copy()
googlebot_df['depth'] = googlebot_df['url'].apply(
    lambda x: len([s for s in x.split('/') if s]) if x != '/' else 0
)
print("\nDerinliğe Göre Tarama Dağılımı:")
print(googlebot_df['depth'].value_counts().sort_index())

Bu betiği çalıştırdığınızda saniyeler içinde Googlebot aktivitesinin temel profilini elde edersiniz. Daha ileri analizler için veriyi CSV’ye aktarabilir ya da matplotlib veya plotly ile görselleştirebilirsiniz.

Analiz Edilmesi Gereken Temel SEO Metrikleri

Log dosyalarınızı elde ettikten ve Googlebot verilerini filtreledikten sonra hangi metriklere odaklanmanız gerektiğini bilmek kritik önem taşır.

1. Taranan Sayfa Sayısı ve Kapsam Oranı

İlk adım, belirli bir zaman diliminde (genellikle 30 gün) Googlebot’un kaç benzersiz URL’yi tarattığını tespit etmektir. Bu sayıyı sitenizin toplam indekslenebilir URL sayısıyla karşılaştırın.

Kapsam Oranı = (Googlebot Tarafından Taranan Benzersiz URL / Toplam İndekslenebilir URL) × 100

Örneğin 10.000 URL’lik bir sitede Googlebot 30 günde yalnızca 3.200 URL’yi ziyaret ettiyse kapsam oranı yüzde 32’dir. Bu ciddi bir tarama açığına işaret eder.

Kapsam oranı düşükse şu soruları sorun:

• Siteniz için crawl budget yeterli mi?
• İç bağlantı yapısı zayıf mı; bazı sayfalar derinlerde mi kalıyor?
• Sayfalama (pagination) veya filtre parametreleri bütçeyi tüketiyor mu?
• Sunucu yanıt süreleri yavaş olduğundan Googlebot erken ayrılıyor mu?

2. Durum Kodları Dağılımı

Googlebot’un karşılaştığı HTTP durum kodlarının dağılımı, sitenizin sağlık durumunun en hızlı göstergesidir.

Sağlıklı bir sitede Googlebot isteklerinin yüzde 90’ından fazlası 200 döndürmelidir. 4xx hataları yüzde 5’i, 5xx hataları ise yüzde 1’i geçmemelidir.

3. Tarama Sıklığı (Crawl Frequency)

Her URL’nin kaç kez tarandığını ve bu ziyaretler arasındaki süreyi ölçün. Tarama sıklığı hem içerik kalitesinin hem de crawl bütçesinin doğal bir göstergesidir.

Örnek analiz çıktısı:

URL                                  | 30 Günde Taranma Sayısı | Ort. Aralık
-------------------------------------|-------------------------|------------
/                                    | 187                     | 3.8 saat
/blog/                               | 94                     | 7.7 saat
/blog/teknik-seo-rehberi             | 45                     | 16 saat
/urun/mavi-sneaker?renk=mavi        | 2                      | 15 gün
/urun/kirmizi-sneaker?renk=kirmizi  | 1                      | 30 gün
/hakkimizda                          | 12                     | 2.5 gün
/eski-urun-sayfasi                   | 0                      | Hiç taranmamış

Bu tabloda birkaç önemli sinyal var: Anasayfa ve blog kategorisi beklendiği gibi sık taranıyor. Ürün sayfalarının parametre bazlı versiyonları nadiren ziyaret ediliyor; bu durum crawl bütçesinin boşa harcandığının ya da bu sayfaların düşük öncelikli algılandığının işareti olabilir. Hiç taranmamış sayfa ise ya iç bağlantıdan yoksundur ya da robots.txt ile engellenmiştir.

4. Crawl Derinliği

Googlebot bir sayfayı bulmak için kaç iç bağlantıyı takip etmek zorunda kalıyor? Bu sayı ne kadar yüksekse, o sayfanın taranma ve indekslenme olasılığı o kadar düşüktür.

Genel kural olarak, önemli tüm sayfaların anasayfadan 3 tıklama veya daha az derinlikte erişilebilir olması hedeflenmelidir. Log analizinde her URL’nin yolundan (path) kaçıncı seviye olduğunu çıkararak derinliğe göre tarama dağılımını inceleyebilirsiniz:

Derinlik 0 (Anasayfa)      : 1 URL    — 187 tarama
Derinlik 1 (/blog/)        : 3 URL    — 289 tarama
Derinlik 2 (/blog/yazi/)   : 142 URL  — 6.241 tarama
Derinlik 3 (/blog/sayfa/)  : 38 URL   — 743 tarama
Derinlik 4+                : 211 URL  — 182 tarama

Bu dağılımda derinlik 4 ve üzerindeki URL’lerin toplam tarama sayısının oldukça düşük olduğu görülüyor. Bu sayfalar için iç bağlantı yapısını güçlendirmek ya da bunları üst seviye sayfalara taşımak önerilir.

5. Tarama Zamanlaması

Googlebot sitenizi gün içinde ne zaman ziyaret ediyor? Bu bilgi, bakım pencerelerini ve yüksek yük dönemlerini planlamak için değerlidir.

Saat | Googlebot İstek Sayısı
-----|------------------------
00   | 1.241
01   | 1.089
02   | 987
03   | 843
04   | 799
05   | 912
06   | 1.103
07   | 1.452
08   | 1.788
09   | 2.341
10   | 2.876
11   | 3.012
...

Eğer sunucu bakımı yapılacaksa ya da büyük bir güncelleme yayınlanacaksa, Googlebot aktivitesinin en yoğun olduğu saatlerden kaçınmak iyi bir pratiktir.

6. Yanıt Süresi (Time to First Byte — TTFB)

Bazı log yapılandırmaları her isteğin yanıt süresini de kaydeder. Googlebot’a verilen yanıt süresi önemlidir: yavaş yanıt, botun daha az sayfa taramasına yol açar.

Nginx’te bu metriği etkinleştirmek için:

log_format combined_timing '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                'rt=$request_time';

Yanıt süresi 200 milisaniyenin altında olması hedeflenmelidir. Googlebot isteklerinin ortanca yanıt süresi bu eşiğin üzerindeyse, sunucu optimizasyonu ve önbellek stratejisi gözden geçirilmelidir.

Bulgu → Eylem: Pratikte Log Analizi

Log verilerinden anlamlı içgörüler çıkarmak önemlidir; ancak asıl değer, bu bulguları somut iyileştirme adımlarına dönüştürmektedir.

Senaryo 1: Googlebot Parametre Bazlı URL’lerde Bütçe Tüketiyor

Bulgu: Googlebot’un son 30 günde gerçekleştirdiği 50.000 isteğin 18.000’i (yüzde 36) URL parametresi içeren sayfalara yöneliktir: ?sira=fiyat, ?renk=mavi, ?sayfa=2 gibi.

Eylem:

1. Google Search Console’da URL Parametreleri aracını kullanarak bu parametrelerin taranmaması gerektiğini belirtin.
2. robots.txt ile parametre bazlı URL kalıplarını engelleyin: Disallow: /*?sira=
3. Kanonik etiketler (canonical tag) ekleyerek parametreli sayfaların yetkisini parametresiz ana sayfaya yönlendirin.
4. Hreflang veya sayfalama için rel="next" ve rel="prev" etiketlerini doğru uygulayın.

Senaryo 2: Önemli Ürün Sayfaları Hiç Taranmıyor

Bulgu: Sitenizin 2.000 ürün sayfasından 730’u son 60 gün içinde Googlebot tarafından hiç ziyaret edilmemiş.

Eylem:

1. Bu sayfaların iç bağlantı profilini inceleyin. Siteye bağlantı veren sayfalar yoksa Googlebot bu URL’leri bulamaz.
2. XML sitemap’i kontrol edin; bu sayfalar sitemap’te yer alıyor mu? Yer almıyorsa ekleyin.
3. Sitemap’i Google Search Console’dan manuel olarak yeniden gönderin.
4. Kategori sayfalarındaki ürün listelerinin pagine edilip edilmediğini kontrol edin; derinlerdeki sayfalara giden bağlantılar yeterince oluşturulmuş mu?
5. İlgili blog içeriklerinden bu ürün sayfalarına bağlantı ekleyin.

Senaryo 3: 500 Hataları Belirli Bir Sunucu Saatinde Yoğunlaşıyor

Bulgu: Googlebot isteklerine dönen 500 hatalarının yüzde 78’i saat 10:00-12:00 arasında gerçekleşiyor; bu saatlerde kullanıcı trafiği de zirvededir.

Eylem:

1. Sunucu kapasitesini bu yük altında değerlendirin; yatay ölçeklendirme veya CDN entegrasyonu gerekiyor olabilir.
2. Uygulama sunucusu önbelleklemesini (Redis, Memcached) devreye alın ya da yapılandırmasını optimize edin.
3. Google Search Console’daki Crawl Stats raporundan Googlebot’un o saatlerdeki yükünü gözlemleyin; gerekirse Search Console’dan tarama hızını geçici olarak azaltın.
4. Veritabanı sorgu sürelerini analiz edin; olası darboğazları tespit edin.

Senaryo 4: 301 Yönlendirme Zincirleri Crawl Bütçesi Tüketiyor

Bulgu: Googlebot’un tarattığı URL’lerin yüzde 12’si en az iki aşamalı yönlendirme zincirine (A → B → C) giriyor.

Eylem:

1. Yönlendirme zincirlerini haritalayın ve her zinciri tek adıma indirin (A doğrudan C’ye yönlendirilmeli).
2. İç bağlantılarınızı güncelleyin; her dahili link doğrudan son URL’ye işaret etmeli.
3. Geçmiş blog yazılarındaki eski URL’leri güncel hedef URL’lerle değiştirin.

Senaryo 5: Mobil Googlebot Masaüstü Googlebot’tan Daha Az Sayfa Tarıyor

Bulgu: Son 30 günde masaüstü Googlebot 42.000, mobil Googlebot yalnızca 11.000 istek yapmış. Mobil-öncelikli dizinleme döneminde bu oranın tersine dönmesi beklenir.

Eylem:

1. Sitenizin gerçek anlamda mobil uyumlu olup olmadığını Google’ın Mobil Uyumluluk Testi ile kontrol edin.
2. Mobil ve masaüstü sürümlerde içerik farkı var mı? Mobil sayfalar aynı metni sunuyor mu?
3. Robots.txt’in mobil Googlebot user agent’ını engelleyip engellemediğini kontrol edin.
4. Sunucu taraflı User Agent algılama (dinamik sunum) kullanılıyorsa, Googlebot’un mobil versiyonunu doğru şekilde algılayıp algılamadığını test edin.

Küçük ve Büyük Siteler İçin Log Analizi Sıklığı

Her site aynı yoğunlukta log analizi gerektirmez. Site büyüklüğüne ve değişim hızına göre farklı bir analiz ritmi benimsemek gerekir.

Küçük Siteler (1–1.000 Sayfa)

Küçük siteler için aylık bir log analizi çoğunlukla yeterlidir. Şu durumlarda ise ek analiz yapılması önerilir:

• Büyük içerik güncellemesi sonrasında (yeni sayfa grubu yayınlandığında)
• Organik trafik aniden düştüğünde
• Site yapısında köklü değişiklik yapıldığında (domain değişimi, büyük URL yapısı revizyonu)

Araç olarak Screaming Frog Log Analyser ya da basit bir Python betiği yeterlidir. Günlük log dosyası boyutu genellikle birkaç MB’ı geçmediğinden analiz dakikalar içinde tamamlanır.

Orta Ölçekli Siteler (1.000–50.000 Sayfa)

Orta ölçekli siteler için haftalık ya da iki haftada bir analiz önerilir. Bu ölçekte:

• ELK Stack ya da Splunk gibi merkezi bir log yönetim sistemi kurulması değerlidir.
• Googlebot aktivitesini izleyen otomatik alarmlar kurulmalıdır (5xx hata oranı yüzde 2’yi aşarsa bildirim gelmeli gibi).
• Her ay daha kapsamlı bir trend analizi yapılmalı: önceki ayla kıyaslandığında tarama oranı değişti mi?

Büyük Siteler (50.000+ Sayfa)

E-ticaret devleri, haber siteleri ve büyük içerik platformları için log analizi sürekli ve gerçek zamanlı olmalıdır. Bu ölçekte:

• ELK veya Splunk’ta 7/24 aktif dashboard kurulur.
• Anormal Googlebot aktivitesi (ani düşüş ya da ani artış) otomatik alarmla ilgili ekibe bildirilir.
• Log verileri, Google Search Console verileri, Analytics verileri ve Core Web Vitals metrikleriyle birleştirilerek bütüncül bir performans takibi yapılır.
• Üç ayda bir derinlemeli dönem analizi gerçekleştirilir; tarama örüntüleri ve dizin kapsama oranı tarihsel olarak karşılaştırılır.

Büyük ölçekli sitelerde log boyutları da devasa olabilir: günde onlarca GB log verisi üretilmesi mümkündür. Bu durumda bulut tabanlı log analiz platformları (Google Cloud Logging, AWS CloudWatch Logs, Datadog) tercih edilmelidir.

Log Analizi Yaparken Kaçınılması Gereken Hatalar

Log analizinden maksimum değer almak için yaygın hatalar hakkında farkındalık önemlidir.

1. Yalnızca user agent üzerinden filtrelemek. User agent’ı taklit etmek kolaydır. Gerçek Googlebot trafiğini doğrulamak için mutlaka IP adresi doğrulaması da yapın. Sahte Googlebot trafiğini gerçek veriye karıştırmak yanlış sonuçlara yol açar.
2. Kısa zaman dilimlerini analiz etmek. Bir günlük ya da bir haftalık log verisi, Googlebot’un davranışını yeterince temsil etmez. Tarama döngüleri ve periyodik aktiviteler nedeniyle en az 30, tercihen 60-90 günlük bir zaman penceresi kullanın.
3. Logları tek başına değerlendirmek. Log analizi güçlü bir araçtır; ancak en yüksek değeri Google Search Console verileri, Analytics ve Screaming Frog tarama raporlarıyla birleştirildiğinde üretir. Örneğin bir sayfa Googlebot tarafından taransa bile Search Console’da “Crawled - currently not indexed” olarak görünüyorsa, sorun tarama değil içerik kalitesidir.
4. Bulguları eyleme dönüştürmemek. Log analizi, raporların dosyalanıp rafta bırakıldığı bir egzersiz olmamalıdır. Her analiz oturumunda en az 2-3 somut iyileştirme aksiyonu tanımlanmalı ve önceliklendirilmelidir.
5. Örnekleme (sampling) yapılmış veriyle tam veri arasındaki farkı göz ardı etmek. Bazı CDN’ler ve bulut log servisleri varsayılan olarak isteklerin yalnızca bir kısmını kaydeder. Örneklenmiş veriyle tam veri karıştırıldığında tarama sıklığı ve durum kodu oranları yanıltıcı çıkabilir; analiz öncesi loglama yapılandırmanızın örnekleme oranını mutlaka doğrulayın.
6. CDN veya WAF önünde duran isteklerin gerçek IP’sini kaybetmek. Bir CDN (Cloudflare, Akamai vb.) kullanıyorsanız, sunucu loglarınızdaki IP adresi CDN’in kendi IP’si olabilir; gerçek istemci IP’sini X-Forwarded-For başlığından almanız gerekir, aksi halde Googlebot doğrulaması hatalı sonuç verir.
7. Yalnızca Googlebot’a odaklanıp Bingbot ve diğer arama motoru botlarını tamamen göz ardı etmek. Türkiye pazarında Google baskın olsa da bazı sektörlerde (B2B, uluslararası pazarlar) Bing ve diğer motorlardan gelen tarama trafiği de değerlidir; en azından temel sağlık göstergelerini bu botlar için de takip edin.

Log Analizi Kararları İçin Hızlı Çerçeve

Aşağıdaki tablo, log analizinde karşılaşabileceğiniz yaygın belirtileri doğrudan bir aksiyon önerisine bağlar; ilk müdahale noktanızı belirlemek için kullanabilirsiniz.

Vaka Kurgusu: Bir Emlak İlan Sitesinin Crawl Bütçesi Sorunu

Türkiye genelinde faaliyet gösteren, 40.000’in üzerinde ilan barındıran bir emlak portalı, yeni yayınlanan ilanların Google’da görünmesinin haftalar sürdüğünü fark ediyor. Search Console’da “Keşfedildi - şu anda dizine eklenmedi” durumundaki URL sayısı sürekli artıyor.

Uygulama: SEO ekibi son 60 günlük Nginx loglarını Python ve pandas ile analiz ediyor. Bulgular çarpıcı: Googlebot isteklerinin yüzde 44’ü ?sehir=, ?fiyat_araligi= ve ?siralama= gibi filtre parametreleri içeren URL’lere gidiyor; bu URL’lerin neredeyse tamamı aynı ilan verisinin farklı sıralamalarını gösteriyor ve hiçbiri kanonik etiketle ana ilan sayfasına işaret etmiyor. Aynı zamanda yeni yayınlanan ilanların yüzde 60’ı, kategori sayfalarının yalnızca ilk iki sayfasında listelendiği için (sayfalama derinliği fazla) iç bağlantı yoksunluğu yaşıyor.

Ekip üç değişiklik uyguluyor: filtre parametrelerini robots.txt ile engelliyor ve kalan parametreli URL’lere canonical etiketi ekliyor, yeni ilanlar için ayrı bir “Yeni İlanlar” XML sitemap’i oluşturup Search Console’a gönderiyor, kategori sayfalarındaki sayfalama yapısını rel="next"/"prev" ile güçlendirip yeni ilanlara anasayfadan da bağlantı ekliyor.

Sonuç penceresi: Değişikliklerden 45 gün sonra tekrar yapılan log analizinde, Googlebot’un parametreli URL’lere harcadığı istek oranı yüzde 44’ten yüzde 9’a düşüyor; boşalan bütçe doğrudan yeni ilan sayfalarına kayıyor. Yeni yayınlanan ilanların Googlebot tarafından ilk taranma süresi ortalama 11 günden 2 güne iniyor ve “Keşfedildi - şu anda dizine eklenmedi” sayısı belirgin biçimde azalıyor. (Vaka temsilidir.)

Log Analizinde Yapay Zeka Destekli Yaklaşımlar

2026 itibarıyla büyük ölçekli siteler, log verisini yalnızca kural tabanlı sorgularla değil, makine öğrenmesi destekli anomali tespitiyle de analiz etmeye başladı. Bu yaklaşımın temel mantığı basit: Googlebot’un günlük istek hacmi, durum kodu dağılımı ve tarama derinliği zamanla belirli bir örüntü izler; bu örüntüden sapan ani değişiklikler (örneğin normalde günde 5.000 istek alan bir bot trafiğinin bir gecede 500’e düşmesi) genellikle bir teknik sorunun erken habercisidir.

ELK Stack ve Splunk gibi platformlarda hazır anomali tespit eklentileri bulunur; bunlar geçmiş verilerden bir “normal” aralık öğrenip bu aralığın dışına çıkan durumları otomatik olarak işaretler. Daha küçük ölçekli siteler için de basit istatistiksel yöntemler (hareketli ortalama ve standart sapma bazlı eşik belirleme) Python ile kolayca uygulanabilir. Ayrıca büyük dil modelleri, log analizinden çıkan ham bulguları (“500 hataları saat 10-12 arasında yoğunlaşıyor” gibi) daha anlaşılır özetlere ve öncelik sıralı aksiyon listelerine dönüştürmek için giderek daha fazla kullanılıyor; ancak üretilen özetlerin doğruluğunu ham log verisiyle karşılaştırarak doğrulamak, yanlış yorumlanmış bir bulgunun yanlış bir teknik karara yol açmasını önler.

Bununla birlikte, yapay zeka araçları log analizinin yerini almaz; ham veriyi okuma, doğru sorguyu kurma ve bulguyu doğru teknik aksiyona bağlama becerisi hâlâ insan uzmanlığı gerektirir. AI destekli araçlar, büyük veri hacimlerinde ilk taramayı hızlandıran bir yardımcı olarak değerlendirilmelidir.

Sık Sorulan Sorular

Log Analizini Teknik SEO Stratejinize Entegre Etmek

Log analizi; teknik SEO çalışmalarınızın tamamlayıcı bir parçasıdır. Site denetimleri, hız optimizasyonu ve iç bağlantı çalışmaları gibi alanlarla doğrudan bağlantılıdır. Yapısal iyileştirmelerin Googlebot davranışına yansıyıp yansımadığını doğrulamanın tek güvenilir yolu yine log analizidir.

Örneğin bir crawl budget optimizasyonu çalışması yaptıysanız; parametre bazlı URL’leri robots.txt ile engelledikten ve iç bağlantı yapısını güçlendirdikten sonra logları tekrar analiz ederek Googlebot’un bu bütçeyi artık önemli içeriklere harcayıp harcamadığını somut olarak doğrulayabilirsiniz.

Sonuç olarak, log analizi tahminden gerçeğe geçişi sağlar. “Googlebot muhtemelen bu sayfaları tarıyor” yerine “Googlebot geçen ay bu sayfaları tam olarak şu sıklıkta, şu durum kodlarıyla tarattı” diyebilmek, daha isabetli kararlar almanızı ve yatırımlarınızın geri dönüşünü ölçmenizi sağlar.

Sonuç

Log dosyası analizi, SEO profesyonellerinin çoğunlukla göz ardı ettiği güçlü bir tekniktir. Google Search Console ve diğer SEO araçlarının sağladığı verilerin ötesine geçerek Googlebot’un sitenizle gerçekte nasıl etkileşime girdiğini anlamak, teknik sorunları erken tespit etmenizi ve crawl bütçenizi verimli kullanmanızı sağlar.

Başlangıç için karmaşık bir altyapıya ihtiyacınız yoktur: basit bir Python betiği ya da Screaming Frog Log Analyser ile ilk analizinizi yapabilir, ne tür verilerle karşılaştığınızı görebilirsiniz. Ölçek büyüdükçe ELK Stack veya Splunk ile daha kapsamlı bir sisteme geçiş yapabilirsiniz.

Log analizini düzenli teknik SEO çalışmalarınızın parçası haline getirdiğinizde, Googlebot davranışındaki değişimleri zamanında fark eder; olası sıralama kayıplarını önleyici biçimde ele alırsınız. Veri odaklı kararlar almanız, kör noktaları ortadan kaldırır ve rakiplerinizin göremediği fırsatları görmenizi sağlar. Bu da uzun vadeli, sürdürülebilir organik büyümenin temel taşlarından birini oluşturur.