Ham Erişim Kayıtları Nasıl Okunur? Siteyi Kim Zorluyor Bulma

Hosting firmanızdan gelen e-postada "hesabınız CPU limitini sürekli aşıyor" yazıyor. Panele giriyorsunuz, kaynak kullanımı grafiği gece 03:00 ile 05:00 arasında tavan yapmış. Analytics'i açıyorsunuz: o saatlerde neredeyse hiç ziyaretçi yok. İki ekran birbirini yalanlıyor gibi görünüyor ama aslında ikisi de doğru söylüyor.

Fark şurada: Google Analytics ve benzeri araçlar sayfaya gömülen JavaScript'i çalıştıran ziyaretçileri sayar. Botlar, tarayıcılar, kötü niyetli tarama betikleri ve sizin kendi eklentilerinizin arka plan istekleri o JavaScript'i hiçbir zaman çalıştırmaz. Yani sunucunuzu asıl yoran trafiğin büyük kısmı analiz panelinde görünmez. Görünür olduğu tek yer, sunucunun her isteği tek tek yazdığı ham erişim kayıtlarıdır (raw access logs).

Bu rehber log analizini SEO gözüyle değil, kaynak tüketimi gözüyle ele alıyor. Önce bir log satırının alanlarını tek tek çözeceğiz, sonra kopyalayıp doğrudan çalıştırabileceğiniz komut kalıplarıyla en çok istek atan IP'yi, en agresif user-agent'ı ve en pahalı URL'i çıkaracağız. Sonunda da elimizdeki veriyi bir karara bağlayacağız: bu yük bir bot mu, bir saldırı mı, yoksa kendi eklentiniz mi?

Ham Erişim Kayıtları Nerede Duruyor?#

cPanel'de yol şudur: Ölçümler (Metrics) → Ham Erişim (Raw Access). Ekranda iki bölüm görürsünüz. Üstteki liste o an açık olan, henüz sıkıştırılmamış güncel kaydı indirir. Alttaki "Arşivlenmiş Ham Günlükler" bölümü ise geçmiş ayların sıkıştırılmış dosyalarını verir.

Aynı ekranda iki onay kutusu var ve bunlar kritik: "Ay sonunda günlükleri arşivle" işaretli değilse, sunucu istatistikleri işledikten sonra ham kayıtları siler ve geçmişe bakma şansınız kalmaz. Sorun yaşamaya başlamadan önce bu kutuyu işaretlemek, sonradan "keşke logum olsaydı" dememenizi sağlar.

SSH erişiminiz varsa dosyalar zaten diskte duruyor:

Son satırı özellikle ayırmak gerekiyor. Erişim kaydı ile hata kaydı farklı şeylerdir: erişim kaydı "kim geldi, ne istedi, ne cevap verdim" sorusuna yanıt verir; hata kaydı ise sadece bir şeyler ters gittiğinde yazılır. Bir PHP çökmesini araştırıyorsanız yanlış dosyaya bakıyor olabilirsiniz; o durumda cPanel hata kayıtları yazısı doğru adres.

Bir HTTPS sitesinde neredeyse tüm trafik ssl_log dosyasındadır. Sadece HTTP dosyasına bakıp "hiç trafik yok" sonucuna varmak, en sık yapılan başlangıç hatasıdır.

Bir Log Satırını Alan Alan Okumak#

Apache ve LiteSpeed, cPanel kurulumlarında combined biçimini kullanır. Tipik bir satır şöyle görünür:

203.0.113.45 - - [17/Aug/2026:03:14:22 +0300] "GET /urunler/?filtre=renk-mavi HTTP/1.1" 200 41822 "https://www.google.com/" "Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)"

Bu satırdaki her parça bir alandır ve awk bunları boşluğa göre numaralandırır. Numaraları ezberlemek, bundan sonraki tüm komutları kendi başınıza yazabilmenizi sağlar:

Son satır önemli bir tuzağa işaret ediyor: user-agent metni boşluk içerdiği için awk onu tek alan olarak göremez. Bu yüzden user-agent'a bakan komutlarda alan ayırıcıyı boşluk yerine tırnak işareti yapacağız (awk -F'"'). O zaman ikinci alan istek satırı, dördüncü alan referans, altıncı alan da user-agent olur.

Bir uyarı daha: combined biçiminde isteğin kaç milisaniye sürdüğü bilgisi yoktur. "En yavaş sayfa hangisi" sorusunun cevabı bu dosyada yazmaz. Elinizdeki veri istek adedi, durum kodu ve gönderilen bayttır; kaynak tüketimini bu üçünden çıkarırsınız. Yanıt süresi ölçmek istiyorsanız sunucu tarafında özel bir log biçimi tanımlamanız gerekir, bu da paylaşımlı hostingte genelde mümkün değildir.

Analize Başlamadan Dosyayı Hazırlamak#

Analizi sunucuda SSH ile yapabilirsiniz. Kabuk erişiminiz yoksa dosyayı cPanel'den indirip kendi bilgisayarınızda çalıştırın: macOS ve Linux'ta terminal doğrudan çalışır, Windows'ta WSL veya Git Bash aynı komutları destekler.

Arşivlenmiş kayıtlar sıkıştırılmıştır. Açmadan okuyabilirsiniz:

# Tek bir sıkıştırılmış dosyayı oku
zcat ~/logs/alanadi.com-ssl_log-Jul-2026.gz | head -5

# Birden fazla ayı tek dosyada birleştir
zcat ~/logs/alanadi.com-ssl_log-*.gz > /tmp/tum.log

Toplam istek sayısı ve tekil IP sayısı, işe başlarken ölçek duygusu verir:

wc -l /tmp/tum.log
awk '{print $1}' /tmp/tum.log | sort -u | wc -l

100.000 istek ve 800 tekil IP gördüyseniz ortalama IP başına 125 istek düşüyor demektir; bu oran normal bir sitede 5 ile 20 arasındadır. Yani daha ilk satırda dengesizliğin varlığını anlarsınız.

Sorun belli bir güne aitse dosyayı daraltın; sonraki komutlar hem hızlanır hem gürültüden arınır:

awk '$4 ~ /17\/Aug\/2026/' /tmp/tum.log > /tmp/gun.log

Belirli bir saat aralığına inmek için de aynı kalıp kullanılabilir:

awk '$4 ~ /17\/Aug\/2026:0[3-5]/' /tmp/tum.log > /tmp/gece.log

Bundan sonraki tüm örneklerde dosya adı olarak erisim.log yazacağım; siz kendi hazırladığınız dosyanın adını koyun. awk mantığını derinleştirmek isterseniz awk ile veri işleme yazısı bu kalıpları kendi başınıza türetmenizi sağlar.

En Çok İstek Atan IP'yi Bulmak#

Analizin ilk sorusu her zaman budur. Klasik üçlü kalıp şöyle çalışır: alanı ayıkla, sırala, tekrarları say, sayıya göre tersten sırala.

awk '{print $1}' erisim.log | sort | uniq -c | sort -rn | head -20

Çıktının en üstündeki sayı, o IP'nin kaç istek attığıdır. Burada mutlak sayıdan çok dağılıma bakın. Sağlıklı bir sitede en üstteki IP toplam trafiğin yüzde birkaçını tutar. En üstteki IP tek başına isteklerin yüzde 30'unu yapıyorsa o bir ziyaretçi değildir.

Tek başına IP yeterli bilgi vermez; yanına kimliğini de koyun:

awk -F'"' '{split($1,a," "); print a[1]"  |  "$6}' erisim.log | sort | uniq -c | sort -rn | head -20

Bu komut "hangi IP, hangi user-agent ile, kaç kez" sorusunu tek satırda cevaplar ve genelde teşhisi doğrudan bitirir.

Bant genişliği açısından bakmak da faydalıdır, çünkü 50.000 küçük istek atan bir bot ile 500 kez büyük dosya indiren bir kazıyıcı farklı sorunlardır:

awk '{trafik[$1]+=$10} END {for (ip in trafik) printf "%9.1f MB  %s\n", trafik[ip]/1048576, ip}' erisim.log | sort -rn | head -15

Şüpheli bir IP bulduğunuzda ne yaptığına yakından bakın:

grep '^203.0.113.45 ' erisim.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Bu çıktı size niyeti gösterir. Ürün sayfalarını sırayla geziyorsa kazıyıcıdır, /wp-login.php ve /xmlrpc.php arasında gidip geliyorsa saldırıdır, tek bir API adresini döngüde çağırıyorsa muhtemelen bozuk bir entegrasyondur.

Hangi Bot Geziyor: User-Agent Analizi#

User-agent, isteği gönderen yazılımın kendini nasıl tanıttığıdır. Zorunlu bir doğrulama içermez, yani sahtesi yazılabilir; ama pratikte botların büyük çoğunluğu kendini dürüstçe tanıtır.

awk -F'"' '{print $6}' erisim.log | sort | uniq -c | sort -rn | head -25

Çıktıyı yorumlarken şu ayrım işinize yarar:

Googlebot görünen her isteğin gerçekten Google'dan geldiğini varsaymayın; bu, engellenmemek için en çok taklit edilen imzadır. Doğrulama yöntemi ters DNS ve ileri DNS kontrolüdür:

# 1. IP'nin hangi ada çözüldüğüne bak
host 66.249.66.1
# crawl-66-249-66-1.googlebot.com

# 2. O adın gerçekten aynı IP'ye döndüğünü doğrula
host crawl-66-249-66-1.googlebot.com

İki adım da tutuyorsa ve ad googlebot.com veya google.com ile bitiyorsa gerçektir. Ad tamamen alakasız bir sağlayıcıya çıkıyorsa karşınızda kendini Google gibi tanıtan bir kazıyıcı var demektir.

Sunucuyu En Çok Yoran URL Hangisi?#

İstek adedi tek başına yanıltıcıdır: 10.000 statik görsel isteği, 200 tane ağır veritabanı sorgusu çalıştıran arama sayfasından daha ucuzdur. O yüzden URL listesini çıkardıktan sonra hangilerinin PHP çalıştırdığını ayırt etmek gerekir.

# Sorgu dizesini atarak en çok istenen yollar
awk '{split($7,u,"?"); print u[1]}' erisim.log | sort | uniq -c | sort -rn | head -25

Bu listede aşağıdaki adresleri özellikle arayın; hepsi klasik kaynak yakıcılardır:

• /wp-admin/admin-ajax.php — eklentilerin arka plan istekleri. Sayı çok yüksekse bir eklenti her sayfa görüntülemesinde sunucuya soru soruyor demektir.
• /wp-cron.php — WordPress'in sanal zamanlayıcısı. Her ziyaretçide tetiklenir; yoğun sitede gerçek bir cron görevine taşınmalıdır.
• /xmlrpc.php — modern sitelerin çoğunda gereksiz, saldırganların favorisi.
• /?s= ile başlayan adresler — arama sayfası. Bot taraması bunu döngüye sokarsa veritabanını yorar.
• Filtre parametreli kategori adresleri — özellikle e-ticarette sonsuz URL üretir ve önbelleğe hiç girmez.

Yöntem bazında bakmak da işe yarar. POST istekleri neredeyse her zaman PHP çalıştırır ve önbellekten dönmez:

grep '"POST ' erisim.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Bu listenin başında /wp-login.php varsa kaba kuvvet denemesi altındasınız; kaç farklı IP'den geldiğini de görün:

grep 'POST /wp-login.php' erisim.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Tek IP çıkarsa engellemesi kolaydır, yüzlerce farklı IP çıkarsa bir botnet ile karşı karşıyasınız ve tek tek IP engellemek işe yaramaz.

Durum kodu dağılımı da hızlı bir sağlık kontrolüdür:

awk '{print $9}' erisim.log | sort | uniq -c | sort -rn
awk '$9==404 {print $7}' erisim.log | sort | uniq -c | sort -rn | head -20

404 listesinin başında /wp-content/plugins/... gibi var olmayan eklenti yolları varsa, biri sitenizde bilinen açıkları tarıyor demektir.

Yük Ne Zaman Bindi: Zaman Ekseni Analizi#

Kaynak uyarısı belirli saatlere denk geliyorsa, o saatte kimin çalıştığını bulmak teşhisi tamamlar. Log dosyası zaten kronolojik olduğu için uniq -c komutunu ön sıralama yapmadan kullanabilir, doğrudan bir zaman histogramı elde edebilirsiniz.

Saat bazında toplam istek:

awk '{print substr($4,2,14)}' erisim.log | uniq -c

substr($4,2,14) ifadesi zaman damgasının başındaki köşeli parantezi atlayıp 17/Aug/2026:03 kısmını alır. Çıktı size saat saat yükün nasıl dağıldığını gösterir.

Şüpheli bir IP'nin dakikalık yoğunluğunu ölçmek, "bu bir insan mı" sorusunu kesin biçimde cevaplar:

grep '^203.0.113.45 ' erisim.log | awk '{print substr($4,2,17)}' | uniq -c | sort -rn | head -10

Buradaki 17 karakter dakikaya kadar iner (17/Aug/2026:03:14). Bir insan dakikada en fazla 10–20 istek üretir ve bu istekler sayfa açılışlarıyla kümelenir. Dakikada 300 istek gören bir satır, tartışmasız otomatik bir istemcidir.

Karar Anı: Bot mu, Saldırı mı, Kendi Eklentin mi?#

Elinizde artık üç veri var: kim (IP), ne ile (user-agent), neyi (URL). Bunları birleştirdiğinizde sonuç genelde üç kategoriden birine düşer.

Dördüncü satır özellikle önemli, çünkü çoğu kişi otomatik olarak dışarıyı suçlar. admin-ajax.php isteklerinin sayısını toplam sayfa görüntülemesiyle karşılaştırın:

grep -c 'admin-ajax.php' erisim.log
grep -c 'wp-cron.php' erisim.log

Sayfa başına birden fazla admin-ajax.php isteği düşüyorsa suçlu bir eklentidir ve engellemekle değil, hangi eklenti siteyi yavaşlatıyor yazısındaki eleme yöntemiyle çözülür. Aynı şekilde bulduğunuz yükü panel tarafındaki grafiklerle karşılaştırmak için cPanel kaynak kullanımı izleme ekranını yanınızda açık tutun; iki kaynağın aynı saati işaret etmesi teşhisi kesinleştirir.

Bulduğunuz Kaynağı Durdurmak#

Teşhis bitti, sıra müdahalede. Sertlik sırasına göre dört seçenek var.

1. robots.txt ile yavaşlatma. Sadece kurallara uyan botlar için işe yarar; kötü niyetli istemciler bu dosyayı okumaz bile. Google Crawl-delay satırını yok sayar, ancak Bing ve pek çok SEO botu dikkate alır.

User-agent: AhrefsBot
Crawl-delay: 20

User-agent: SemrushBot
Disallow: /

User-agent: MJ12bot
Disallow: /

Dosyanın doğru yazımı için robots.txt nasıl yazılır yazısına bakabilirsiniz.

2. User-agent bazlı engelleme. .htaccess dosyasına eklenen bu kural, isteği daha PHP çalışmadan reddeder; yani gerçekten kaynak tasarrufu sağlar.

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot|SemrushBot|MJ12bot|DotBot|Bytespider|PetalBot) [NC]
RewriteRule .* - [F,L]

3. IP engelleme. Tek bir kaynak varsa en kesin çözümdür. Apache 2.4 sözdizimiyle:

<RequireAll>
  Require all granted
  Require not ip 203.0.113.45
  Require not ip 198.51.100.0/24
</RequireAll>

Aynı işi arayüzden yapmayı tercih ederseniz cPanel IP engelleyici aracı tam olarak bunu üretir. Yalnız dikkat: bir IP bloğunu engellemeden önce gerçekten bot olduğunu doğrulayın, aksi halde bir internet sağlayıcısının tüm müşterilerini kapıda bırakabilirsiniz.

4. Hız sınırı ve önbellek. Kendi sunucunuzu yönetiyorsanız istek başına sınır koymak, tek tek bot engellemekten çok daha kalıcıdır; Nginx rate limit ayarları bunun için doğru yer. Paylaşımlı pakette ise en büyük kazanç tam sayfa önbelleğidir: önbellekten dönen bir istek PHP'yi hiç çalıştırmadığı için, bot trafiği CPU limitinize neredeyse hiç yansımaz.

Müdahaleden sonra işi yarım bırakmayın. Bir hafta sonra aynı komutları tekrar çalıştırın ve listenin başındaki ismin değişip değişmediğine bakın; değişmediyse kuralınız çalışmıyordur.

GoAccess ile 30 Saniyede Genel Görünüm#

Kendi sunucunuz varsa ve tek tek komut yazmak yerine bütünsel bir tablo istiyorsanız GoAccess iyi bir ara adımdır. Terminal içinde canlı bir gösterge paneli çizer: en çok istenen adresler, tekil ziyaretçiler, durum kodları, bot listesi ve bant genişliği tek ekranda görünür.

goaccess erisim.log --log-format=COMBINED

# Paylaşılabilir bir HTML raporu üret
goaccess erisim.log --log-format=COMBINED -o /tmp/rapor.html

Paylaşımlı hostingte bu aracı kuramazsınız, ama log dosyasını kendi bilgisayarınıza indirip orada çalıştırabilirsiniz. Yine de komut kalıplarını öğrenmeye değer: GoAccess genel resmi verir, dar soruların cevabını ise grep ve awk kombinasyonları verir.

Sıkça Sorulan Sorular#

Ham erişim kayıtları ne kadar süre saklanır?#

Varsayılan ayarlarda sunucu istatistikleri işledikten sonra günlükleri siler, yani elinizde genelde yalnızca son bir günün kaydı kalır. cPanel'in Ham Erişim ekranındaki arşivleme kutusunu işaretlerseniz her ayın kaydı sıkıştırılmış olarak saklanır. Bu dosyalar disk alanı ve dosya sayısı kotanızdan yer kapladığı için, birkaç aylık arşivi indirip sunucudan silmek iyi bir alışkanlıktır.

Access log ile hata kaydı arasındaki fark nedir?#

Erişim kaydı, sunucuya gelen her isteği başarılı olsun olmasın tek tek yazar; kim geldi, hangi adresi istedi, hangi cevabı aldı sorularına yanıt verir. Hata kaydı ise yalnızca bir şeyler ters gittiğinde yazılır ve PHP hataları, izin sorunları, eksik dosyalar gibi teknik ayrıntıları tutar. Kaynak tüketimi araştırıyorsanız erişim kaydına, site hata veriyorsa hata kaydına bakmanız gerekir.

Logdaki istek sayısı neden Analytics'teki ziyaretçi sayısından çok yüksek?#

Analytics benzeri araçlar sayfaya gömülü JavaScript'i çalıştıran tarayıcıları sayar. Botlar, tarama betikleri, önizleme servisleri ve sitenizin kendi arka plan istekleri bu kodu hiç çalıştırmaz, dolayısıyla panelde görünmez. Ayrıca bir sayfa görüntülemesi logda onlarca satır üretir; her görsel, stil dosyası ve betik ayrı bir istektir. Bu yüzden iki rakamın birbirini tutmaması normaldir.

Bir IP'yi engellemek sorunu çözmeye yeter mi?#

Kaynak tek bir sunucuysa yeter. Ancak kaba kuvvet denemeleri ve büyük tarama ağları yüzlerce farklı adresten gelir; birini kapattığınızda yerine yenisi geçer ve engel listeniz sürekli büyür. Bu durumda doğru yaklaşım tek tek adres engellemek yerine giriş sayfasını korumaya almak, istek hızına sınır koymak ve mümkünse trafiği önbellekten karşılamaktır. IP engelleme tek ve ısrarcı bir kaynak için uygundur.

SSH erişimim yok, bu komutları nasıl çalıştırırım?#

Gerek yok. cPanel'in Ham Erişim ekranından günlük dosyasını kendi bilgisayarınıza indirin ve komutları orada çalıştırın. macOS ve Linux'ta terminal doğrudan çalışır; Windows'ta WSL kurabilir veya Git for Windows ile gelen Git Bash uygulamasını kullanabilirsiniz. Dosya sıkıştırılmış geldiyse önce açın; komutların hiçbiri sunucuda çalışmak zorunda değildir.

Bot trafiğini engellemek SEO sıralamama zarar verir mi?#

Arama motoru botlarını engellerseniz evet, ciddi zarar verir. Ancak listede en çok yer kaplayanlar genellikle Googlebot ve bingbot değil, SEO analiz araçlarının tarayıcılarıdır. Bu botlar sitenize tek bir ziyaretçi getirmez; yalnızca rakip analizi için verinizi toplar. Onları engellemek arama sıralamanızı etkilemez. Engelleme kuralını yazarken imzayı tam yazın ve sonrasında arama konsolunda tarama hatası oluşup oluşmadığını kontrol edin.