Bot Trafiği Sunucu Yükünü Nasıl Artırır

Bot trafiği, sunucu yükü tartışmalarında en çok küçümsenen kalemdir. Analiz panelinde günde 3.000 ziyaretçi görürsün, sunucu ise 90.000 istek işlemiştir; aradaki fark analitik betiği çalıştırmayan, çerez kabul etmeyen ve kendini oturumla tanıtmayan otomatik istemcilerdir. Daha kötüsü, bu isteklerin büyük kısmı gerçek kullanıcının hiç uğramadığı, önbelleğe girmeyen adreslere gider; yani sunucuya birim başına gerçek ziyaretçiden birkaç kat pahalıya mal olur.

Bu yazıda bot trafiğinin yükü tam olarak nasıl büyüttüğünü mekanizmasıyla anlatacağım: neden bir botun isteği bir insanın isteğinden pahalıdır, günlükten bot payını nasıl ölçersin, kendini Googlebot ilan eden bir isteğin gerçekten Googlebot olup olmadığını nasıl doğrularsın ve arama sıralamana zarar vermeden hangi katmanda nasıl sınırlama koyarsın. Sonda da en pahalı hataya, yani yanlışlıkla arama motorunu engellemeye ayrı bir bölüm var.

Bot Türleri: Hepsini Aynı Kefeye Koyma#

Bütün otomatik trafiği "bot" diye tek torbaya atmak, hem gereksiz kaynak harcamana hem de yanlışlıkla değerli tarayıcıları engellemene yol açar. Üç kategoriye ayır.

Bu ayrımın pratik karşılığı şudur: iyi botlara hız ayarı, gri botlara kota, kötü botlara engel uygularsın. Aynı aracı üçüne birden uygulamak, ya arama trafiğini kaybetmene ya da kaynak israfına devam etmene yol açar.

Kötü botların önemli bir kısmı aslında içerik peşinde bile değildir; /wp-login.php, /xmlrpc.php, /.env, /admin gibi adresleri sırayla deneyen zafiyet tarayıcılarıdır. Bunlar 404 dönseler bile sunucunda bir istek maliyeti üretir ve WordPress gibi çatılarda 404 sayfası çoğu zaman tam bir uygulama yüklemesi gerektirir; yani "bulunamadı" cevabı hiç de bedava değildir.

Bot İsteği Neden Gerçek Kullanıcıdan Pahalı#

Bu bölüm yazının en önemli kısmı, çünkü çoğu kişi bot yükünü sadece istek sayısıyla ölçer ve asıl mekanizmayı kaçırır. Bir botun isteği dört ayrı sebeple daha pahalıdır.

Birincisi, önbelleğe girmez. Gerçek kullanıcı popüler sayfaları gezer ve bunlar önbellekte sıcak durur. Bot ise sitenin derinliklerine, aylardır kimsenin açmadığı sayfalara gider. Bu adresler önbellekte yoktur, dolayısıyla her biri tam bir uygulama çalıştırması ve veritabanı sorgusu demektir.

İkincisi, kombinatoryal adresleri gezer. Bir e-ticaret sitesinde renk, beden, marka ve fiyat filtrelerinin kombinasyonu binlerce benzersiz adres üretir. İnsan bunların beş onunu kullanır, bot hepsini dener. Her filtre kombinasyonu genelde WHERE koşulları eklenmiş, indeksin işe yaramadığı ağır bir sorgudur.

Üçüncüsü, paralel ve düzensizdir. Gerçek kullanıcılar gün içinde dağılır. Bir tarama dalgası ise dakikalar içinde yüzlerce eşzamanlı istek gönderebilir ve bu, PHP-FPM havuzunu doldurup gerçek kullanıcıların kuyrukta beklemesine yol açar.

Dördüncüsü, statik varlıkları çekmez. Kulağa iyi gelir ama değildir: analiz panelin sayfa görüntülemelerini genelde JavaScript ile sayar, bot JavaScript çalıştırmaz, dolayısıyla panelde görünmez. Sunucun 90.000 istek işlerken sen 3.000 ziyaretçi görürsün ve yük artışını açıklayamazsın.

Bu dördünün toplamı şu sonuca çıkar: trafiğin yüzde 30'u bot olsa bile sunucu yükünün yüzde 60–70'i onlardan geliyor olabilir. Yük ortalaması tırmandığında bu payı hesaba katmadan yapılan kapasite kararları hep yanlış çıkar; yükü doğru yorumlamak için load average nasıl okunur yazısındaki iowait ve çekirdek normalizasyonunu birlikte kullan.

Bot Payını Günlükten Ölçmek#

Tahmin etmeyi bırak, ölç. Web sunucusu erişim günlüğü elinde zaten var ve tek ihtiyacın birkaç awk komutu.

LOG=/var/log/nginx/firmaniz-access.log

# 1) En çok istek yapan kullanıcı aracıları
awk -F'"' '{print $6}' "$LOG" | sort | uniq -c | sort -rn | head -20

# 2) Bot / insan oranı
awk '{
  s=tolower($0)
  if (s ~ /bot|crawl|spider|slurp|scrapy|headless|python-requests|curl|wget/) b++; else i++
} END { printf "bot=%d insan=%d bot_orani=%%%.1f\n", b, i, 100*b/(b+i) }' "$LOG"

# 3) En çok istek yapan IP'ler - tek IP'den gelen yığın saldırıyı gösterir
awk '{print $1}' "$LOG" | sort | uniq -c | sort -rn | head -20

# 4) Botların en çok gezdiği yollar - önbellek dışı kalıpları ortaya çıkarır
awk '{ s=tolower($0); if (s ~ /bot|crawl|spider/) print $7 }' "$LOG" \
  | sed 's/?.*//' | sort | uniq -c | sort -rn | head -20

Dördüncü komut genellikle en çarpıcı sonucu verir. Çıktının başında filtreli kategori adresleri, sayfalama parametreleri veya tarih bazlı arşiv sayfaları görüyorsan, bot bütçesinin büyük kısmı hiç kimsenin aramadığı içerikte harcanıyor demektir. Bu kalıpların arama tarafındaki maliyeti için tarama bütçesi ve site hızı yazısına bak.

Yanıt süresi alanını da günlüğe eklediysen (yöntemi sunucu yanıt süresi izleme yazısında var) bot isteklerinin ortalama süresini insan isteklerinden ayrı hesaplayabilirsin. Aradaki farkı ilk kez gördüğünde tablo netleşir.

Sahte Googlebot'u Doğrulamak#

Kullanıcı aracısı alanı istemci tarafından yazılır ve hiçbir doğrulaması yoktur; herkes kendini Googlebot ilan edebilir. Kötü botların önemli bir kısmı tam olarak bunu yapar, çünkü çoğu site Googlebot'u sınırlamadan geçirir. Bu yüzden bir isteği "iyi bot" olarak muamele etmeden önce doğrulaman gerekir.

Doğru yöntem çift yönlü DNS kontrolüdür: IP'nin ters DNS kaydına bak, çıkan alan adının beklenen alan adına ait olduğunu gör, sonra o alan adını tekrar ileri DNS ile çözüp aynı IP'ye çıktığını doğrula.

IP="66.249.66.1"

# 1) Ters DNS - googlebot.com veya google.com ile bitmeli
host "$IP"
# Örnek çıktı: 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

# 2) Çıkan ismi ileri çöz - aynı IP'ye dönmeli
host crawl-66-249-66-1.googlebot.com
# Örnek çıktı: crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Bunu toplu hâlde çalıştırmak için basit bir betik yeterlidir:

#!/bin/bash
# Kendini Googlebot ilan eden IP'leri doğrula
LOG=/var/log/nginx/firmaniz-access.log
awk '/Googlebot/ {print $1}' "$LOG" | sort -u | while read -r ip; do
  ad=$(dig +short -x "$ip" | head -1)
  case "$ad" in
    *.googlebot.com.|*.google.com.)
      geri=$(dig +short "$ad" | head -1)
      if [ "$geri" = "$ip" ]; then echo "GERCEK  $ip  $ad"; else echo "SAHTE   $ip  $ad"; fi
      ;;
    *) echo "SAHTE   $ip  ${ad:-ters-dns-yok}" ;;
  esac
done

Sahte çıkan IP'leri artık gönül rahatlığıyla sınırlayabilir ya da engelleyebilirsin; gerçek Googlebot'a asla dokunma. Aynı doğrulama mantığı Bingbot için search.msn.com alan adıyla çalışır. Bu yöntemi Cloudflare arkasında uygularken günlükteki IP'nin gerçek istemci IP'si olduğundan emin ol; aksi hâlde hep kenar düğümün adresini doğrulamaya çalışırsın. Bunun nasıl düzeltileceğini Cloudflare arkasında gerçek IP ve Fail2ban yazısında anlattım.

Sunucu Katmanında Sınırlama#

Doğrulama bittiyse sıra sınırlamaya gelir. Amacın engellemek değil, kotalamak olsun; engelleme en son çaredir.

nginx tarafında istek hızı sınırlaması, tek bir kaynaktan gelen yığını yumuşatmanın en etkili yoludur:

# http bloğu içinde: IP başına saniyede 5 istek, 10 MB durum belleği
limit_req_zone $binary_remote_addr zone=genel:10m rate=5r/s;

# Bilinen ağır botlar için ayrı ve daha dar bir bölge
map $http_user_agent $bot_sinif {
    default            "";
    ~*(SemrushBot|AhrefsBot|MJ12bot|DotBot|PetalBot)  "agir";
}

server {
    location / {
        # burst ile kısa dalgalanmaya izin ver, nodelay ile gecikmeyi kaldır
        limit_req zone=genel burst=20 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    # Ağır SEO botlarını doğrudan reddet - arama motorları etkilenmez
    if ($bot_sinif = "agir") { return 429; }

    # Sık denenen zafiyet yollarını uygulamaya hiç indirme
    location ~* ^/(xmlrpc\.php|wp-config\.php\.bak|\.env|\.git/) {
        deny all;
        access_log off;
    }
}

Buradaki limit_req_status 429 ayarı önemlidir. Varsayılan 503 yerine 429 (Too Many Requests) dönmek, iyi davranan tarayıcılara "yavaşla" mesajı verir ve çoğu bunu dikkate alır; 503 ise kalıcı bir sunucu hatası gibi algılanabilir.

Zafiyet yollarını deny all ile kesmenin değeri, yalnızca güvenlik değil performanstır: o istek artık PHP'yi hiç çalıştırmaz, nginx tek satırda kapatır. access_log off eklemek de günlük dosyanın şişmesini engeller.

Tekrarlayan saldırgan IP'ler için Fail2ban ile otomatik geçici engelleme kurabilirsin. Manuel kara liste tutmaya çalışma; IP'ler sürekli değişir ve liste kısa sürede hem eskir hem yönetilemez hâle gelir.

robots.txt, CDN Katmanı ve Doğru Sıralama#

robots.txt bir güvenlik aracı değildir; iyi niyetli tarayıcıların uyduğu bir nezaket sözleşmesidir. Kötü bot onu okumaz bile. Ama iyi ve gri botların yükünü ciddi biçimde azaltır, üstelik bedavaya.

User-agent: *
# Filtre ve sıralama parametreleri - sonsuz kombinasyon üretir
Disallow: /*?renk=
Disallow: /*?siralama=
Disallow: /*?filtre=
Disallow: /arama
Disallow: /sepet
Disallow: /hesabim

# Ağır SEO tarayıcıları için tamamen kapat
User-agent: SemrushBot
Disallow: /

User-agent: AhrefsBot
Disallow: /

Sitemap: https://firmaniz.com/sitemap.xml

Crawl-delay direktifini Google desteklemez; Bing ve bazı diğer tarayıcılar dikkate alır. Google tarafında tarama hızını doğrudan robots.txt ile ayarlayamazsın, ancak sunucun sürekli 429 ya da 5xx dönerse Google tarama hızını kendiliğinden düşürür. Bu mekanizmanın nasıl çalıştığını tarama bütçesi ve site hızı yazısında ayrıntılandırdım.

Önünde bir CDN varsa, en verimli yer orasıdır: bot isteği senin sunucuna hiç ulaşmadan kenar düğümde karşılanır ya da reddedilir. Cloudflare kullanıyorsan bot yönetimi kuralları, hız sınırlama ve gerektiğinde tarayıcı doğrulaması bu işi kaynak sunucuna hiç dokunmadan halleder; saldırı anındaki agresif mod için Cloudflare Under Attack modu yazısına bakabilirsin. Sıralama şöyle olmalı: önce CDN katmanı, sonra web sunucusu, en son uygulama. Bir isteği ne kadar erken karşılarsan o kadar ucuza gelir.

Sık Yapılan Hatalar#

Googlebot'u yanlışlıkla engellemek. En pahalı hata budur ve genelde geniş bir kullanıcı aracısı kalıbıyla ya da agresif bir hız sınırıyla olur. Sonucu haftalar sonra, organik trafiğin düşüşüyle fark edersin. Herhangi bir engelleme kuralı yazmadan önce mutlaka ters DNS doğrulaması yap ve arama motoru tarayıcılarını kuralın dışında bırak.

Kullanıcı aracısına körü körüne güvenmek. Bu alan istemci tarafından yazılır ve hiçbir bağlayıcılığı yoktur. Doğrulanmamış bir "Googlebot" imzasına ayrıcalık tanımak, kötü botlara açık kapı bırakmaktır.

Tüm botları engellemeye çalışmak. Arama motoru tarayıcısı olmadan organik trafik de olmaz. Amaç bot trafiğini sıfırlamak değil, kaynak tüketimini bütçelemektir.

IP'yi kalıcı olarak kara listeye almak. Ev ve mobil IP'ler dinamiktir; bugün engellediğin adres yarın gerçek bir müşteriye atanabilir. Geçici engelleme kullan, süreli olsun.

Sadece engelleyip kök nedeni düzeltmemek. Botlar filtreli adreslerini geziyorsa asıl sorun o adreslerin taranabilir olmasıdır. Kanonik etiket, parametre yönetimi ve robots kuralları ile bu adresleri baştan üretmemek, hız sınırından daha kalıcı bir çözümdür.

Sıkça Sorulan Sorular#

Trafiğimin ne kadarı bot, nasıl öğrenirim#

Analiz paneline değil, web sunucusu erişim günlüğüne bak. Analiz araçları JavaScript ile sayım yapar ve botların çoğu JavaScript çalıştırmadığı için orada hiç görünmez. Günlükte kullanıcı aracısı alanında bot, crawl, spider gibi anahtar kelimeleri sayarak kaba bir oran çıkarabilirsin. Tipik bir sitede bu oran yüzde 20 ile 50 arasında değişir; e-ticaret ve haber sitelerinde daha yüksektir.

Bot trafiği bant genişliğimi tüketir mi#

Evet ama asıl maliyet bant genişliği değil, işlem gücüdür. Botlar genellikle görsel ve statik dosya indirmedikleri için transfer hacimleri düşük kalır. Buna karşılık gittikleri adresler önbelleğe girmediği için her istek tam bir uygulama çalıştırması ve veritabanı sorgusu üretir. Yani faturanı bant genişliği değil, CPU ve veritabanı yükü kabartır.

robots.txt kötü botları engeller mi#

Hayır. robots.txt yalnızca kurallara uymayı seçen tarayıcılar için bağlayıcıdır; kötü niyetli bir bot dosyayı okumaz ya da okuyup görmezden gelir. Hatta bazı kazıyıcılar Disallow satırlarını "burada ilginç bir şey var" ipucu olarak kullanır. Kötü botlara karşı gerçek araçlar sunucu katmanında hız sınırlama, ters DNS doğrulaması, Fail2ban ve CDN düzeyinde bot kurallarıdır.

Bot yüzünden sunucum çöker mi#

Doğrudan çökmez ama doygunluğa itebilir. Yoğun bir tarama dalgası PHP-FPM havuzunu doldurur, gerçek kullanıcı istekleri kuyrukta bekler ve site dışarıdan çökmüş gibi görünür. Veritabanı bağlantı limiti dolduğunda ise gerçekten hata sayfaları dönmeye başlar. Bu yüzden hız sınırlaması yalnızca bir optimizasyon değil, bir kararlılık önlemidir.

Yapay zekâ tarayıcılarını engellemeli miyim#

Bu bir performans sorusundan çok bir içerik politikası sorusudur. Sunucu yükü açısından bakarsan, düzenli ve yoğun gezen her tarayıcı bir maliyettir ve kotalanabilir. İçeriğinin dil modellerinde kullanılmasını istemiyorsan robots.txt'te ilgili kullanıcı aracılarını kapatabilirsin; ancak bu da yalnızca kurallara uyanlar için geçerlidir. Karar verirken referans trafiği kazancını ve sunucu maliyetini birlikte tartmanı öneririm.

Hız sınırı koyduktan sonra neyi kontrol etmeliyim#

İki şeyi: 429 dönen istek oranını ve arama motoru tarama istatistiklerini. Günlükte 429 sayısının aniden patlaması, sınırı fazla dar koyduğunu gösterir. Arama konsolundaki tarama istatistiklerinde tarama isteklerinin düşüp hata oranının artması ise gerçek tarayıcıları etkilediğin anlamına gelir ve derhal geri alman gerekir. İlk hafta bu iki metriği günlük kontrol et.

Kapanış#

Bot trafiği, sunucu yükü hesaplarında görünmeyen ama faturayı belirleyen kalemdir. Aklında kalması gereken dört alışkanlık şu: bot payını analiz panelinden değil erişim günlüğünden ölç, iyi ve kötü botu ters DNS doğrulamasıyla ayır, sınırlamayı isteğin ulaşabildiği en dış katmanda uygula ve engellemeden önce mutlaka arama motoru tarayıcılarını kuralın dışına al. Bu dördü, hem kaynak tüketimini düşürür hem de organik trafiğini riske atmadan çalışmanı sağlar.

Bot dalgalarında sunucun sürekli sınırına dayanıyorsa, izole kaynak ve daha yüksek eşzamanlılık için VDS veya bulut sunucu paketlerimize geçebilirsin. Saldırgan trafiği kaynak sunucuna hiç ulaşmadan kesmek için DDoS koruma ve uygulama katmanı filtreleme için WAF hizmetlerimiz devreye girer. Hız sınırlama kurallarını ve Fail2ban yapılandırmasını kendin kurmak istemiyorsan sunucu yönetimi hizmetimiz bu ayarları senin adına yapar.