Chat Sitesi İçin Server Log Analizi: Hangi Sayfalar Taranıyor? Crawl Bütçesi Nasıl Optimize Edilir?

Chat sitelerinde SEO’nun en zor yanı şu: Arama motoru botlarının gerçekten nerelere gittiğini ölçmeden, çoğu zaman “tahmin” yürütmek gerekiyor. Oysa en net veri server log kayıtlarında saklı. Botların (ve diğer crawler’ların) istekleri, URL desenleri, parametreli varyantlar, durum kodları ve tekrar sıklıkları bir araya geldiğinde, bize gerçekten neyin tarandığını gösteren somut bir “crawl gerçekliği” çıkıyor.

Bu yazıda chat sitesi için log dosyası analizi: hangi sayfalar taranıyor ve crawl bütçesi nasıl optimize edilir? sorusunu kanıt tabanlı bir şekilde ele alıyoruz. Genel teknik SEO tavsiyeleriyle yetinmek yerine, logdan taranan URL kümelerini çıkarıp crawl bütçesinin nerede boşa aktığını azaltmak için karar mekanizması kuracağız.

Kapsam ve ön koşullar: log türleri, formatlar ve veri toplama periyodu

Analize başlamadan önce tek bir şey netleşmeli: Hangi log ile çalışıyorsunuz? En yaygın senaryolar Nginx access log veya Apache access log’dur. Nginx genelde $remote_addr, $request, $status, $body_bytes_sent, $http_user_agent gibi alanlarıyla kaydı oluşturur. Apache ise benzer bilgileri; %h, %u, %t, \"%r\", %>s ve %{User-agent}i gibi alanlarla üretir.

Log formatları farklı olsa da hedef aynı: Her satırdan en azından şu bilgileri çıkarabilmek. Bot kimliği için IP ve User-Agent, URL için path + querystring, sonuç için status code, zaman için timestamp ve istek tekrarları için aynı bot + aynı URL kombinasyonunun sıklığı. Bu minimum set olmadan crawl bütçesiyle ilgili yorum yapmak zorlaşır; çünkü “ne taranıyor?” sorusunun yanına “ne kadar ve ne kadar tekrar ediyor?” sorusu eklenemeyince tablo bulanıklaşır.

Veri toplama periyodu tarafında pratik bir başlangıç önerisi: İlk denetimlerde 7 günle başlayın, trendi daha istikrarlı görmek için 30 güne genişletin. Chat sitelerinde yoğun dönemler (kampanya, etkinlik, büyüme) log davranışını değiştirebildiği için, tek gün/tek saatlik örneklemi “kesin sonuç” gibi görmek yanıltıcı olabilir.

Hangi botlar kritik? Googlebot türleri ve log filtreleme

Log analizinde ilk işi “kimin taradığı” ayırmak yapın. Sadece “Googlebot var mı?” diye bakmak yeterli değil; Google’ın farklı crawler türleri, görüntü/arama varyantları ve diğer arama motorları bambaşka hız ve rota ile davranabilir. Buna ek olarak saldırgan botlar (scraper, credential stuffing denemeleri) crawl bütçesini boşa harcatabilir; bu yüzden ayrı değerlendirme şart.

Filtreleme yaklaşımı için iki katmanlı bir yol daha güvenilir olur: (1) IP/ASN tabanlı kaba eleme (güvenilir olmayan kaynakları hızlıca azaltmak için), (2) User-Agent / reverse DNS / davranış tabanlı ince eleme. Özellikle chat sitelerinde kullanıcı trafiğiyle bot trafiği iç içe geçebilir. Bu yüzden UA filtrelemesini “tek başına” güvenilir saymayın; URL desenleri ve hız (rate) gibi sinyallerle doğrulayın.

• Googlebot segmentasyonu: user-agent içinde “Googlebot” geçenleri ayrı bir grup olarak etiketleyin; mümkünse farklı alt türleri (smartphone/desktop gibi) ayrıştırın.
• Diğer crawler grupları: Bingbot, Yandex, Baidu gibi arama motorlarını ayrı tutun; “link preview bot” veya “monitoring botları”nı üçüncü kategoriye alın.
• Şüpheli botlar: aşırı 4xx/5xx oranı, çok yüksek istek hacmi, deneme sayısı artan token/oturum URL kalıpları “şüpheli” işaretidir.

Log’tan taranan sayfaları çıkarma: URL normalizasyonu ve parametre stratejisi

Logdan “taranan sayfa”yı çıkarmak ilk bakışta basit görünür: en çok istek alan URL’leri listelersiniz. Ancak chat sitelerinde parametreler (ör. arama sorguları, oda varyantları, sayfa numarası, locale, filtreler) aynı içeriği farklı URL’ler olarak temsil edebilir. Bu durumda crawl bütçesi ölçümü doğrudan yanlışlaşır.

Öncelik: URL normalizasyonu. Örneğin /chat-room/oda-adi sabit kabul edilirken, ?q=...&sort=... gibi sorgular indekslenmemesi gereken varyantlar olabilir. Analizde “URL’yi olduğu gibi” raporlamak yerine en azından ana path’i ve “parametre kümelerini” ayırın. Buradaki hedef net: Veriyle karar vermek—hangi query kombinasyonları gerçekten indekslenebilir sayfaya karşılık geliyor?

Bu normalizasyon yaklaşımı, raporlarınızı okunur hale getirir. Aksi halde aynı sohbet odası farklı arama terimleriyle tekrar tekrar taranır; crawl bütçesi israfı gereksiz şekilde “şişkin” görünür ve optimizasyon kararı gecikir.

Crawl bütçesi sinyalleri: istek hacmi, tekrarlar, durum kodları ve tarama derinliği mantığı

Crawl bütçesini tek bir sayı gibi düşünmeyin. Server log verisiyle crawl bütçesi israfını anlamak için birkaç sinyali birlikte okumanız gerekiyor. En temel ölçüt istek hacmi: toplam istek sayısı, isteklerin gün/saat dağılımı ve bot başına bant genişliği etkisi. İkinci ölçüt tekrarlar: aynı botun aynı URL’i tekrar tekrar istemesi.

Durum kodları da doğrudan sinyal verir. 200 ve 3xx devamlılık gösterir; 4xx (özellikle 404/410) boşa giden denemeler anlamına gelir; 5xx ise tarayıcıların hatalı/yanıt veremeyen endpointleri tekrar denemesi ihtimalini artırır. Chat sitelerinde ayrıca rate-limit (429) sinyalini göz ardı etmeyin. Doğru ayar, “robots’un ulaşmaması gerekeni” engellerken önemli sayfaları da gereksiz yavaşlatmaz. Yanlış ayar ise önemli sayfaların taramasını da geciktirir.

Tarama derinliği mantığı için pratik bir yorumlama kuralı geliştirin: botun bir URL tipinden (ör. oda sayfası) başka URL tiplerine geçiş paterni var mı? Bot sürekli arama/filtre sayfalarında dönüp duruyorsa, crawl bütçesi odak dışıdır; sorunun kaynağı muhtemelen indekslenmemesi gereken alanlardır.

Sayfa kümeleriyle analiz: statik içerik, sohbet odaları, arama/filtre ve oturum sayfaları

Log analizini sadece URL listeleriyle sınırlarsanız, karar çıkaramazsınız. Bunun yerine URL’leri “sayfa kümeleri”ne ayırın. Chat sitelerinde en yaygın kümeler: statik içerikler (hakkımızda, blog, kurallar), sohbet odaları/oda sayfaları, oturum veya kullanıcı bağlamlı sayfalar (üyelik, profil), arama/filtre ekranları ve parametreli varyantlar.

Bu yaklaşımı somutlaştırmak için URL kümelerini desenlere göre etiketleyin. Örneğin /live-chat veya /chat-room gibi giriş odaklı sayfalar ayrı bir grup olabilir; ardından /chat-room/<oda_id> ve /chat-room/<oda_id>/messages gibi alt path’ler ayrılır. Buradaki metrikler: grup başına istek yüzdesi, benzersiz URL sayısı, durum kodu oranları ve aynı URL tekrar sıklığı.

Özellikle chat odaları içinde parametreli varyantlar varsa, bunları indekslenebilir/indekslenemez olarak ikiye ayırın. Chat arama kutusu sonuçları gibi sayfalar, küçük farklarla yüzlerce varyant üretebilir. Bu da botun crawl bütçesini, arama terimi “evreninde” boğar—yani asıl değerli oda sayfalarına gereken sıra gelmeyebilir.

URL Kümesi	Örnek URL Deseni	Tipik Durum Kodları	Gözlenen Risk	Önerilen Aksiyon
Sohbet Odası (indekslenebilir)	/chat-room/{oda_id}	200 / 304	Düşük; doğru indekslenme	Canonical + erişim kontrolünü doğrula
Sohbet Arama / Filtre (çoğunlukla israf)	/live-chat?q={terim}&sort={...}	200, bazen 404	Parametre patlaması, tekrar	Normalizasyon + noindex/canonical + rota kısıtlama
Oturum/Üye sayfaları (kısıtlı)	/account, /me, /room/{id}?token=...	401/403/404	Yetkisiz tarama, 4xx israfı	WAF/erişim kısıtı + robots/meta ile sınırlama

Kötüye giden kalıplar ve nedenleri: sonsuz URL uzantıları, token’lı URL’ler

Loglarda en çok zarar veren desenler genelde “sonsuz alan aralığı” üretir. Chat’lerde mesaj sayfaları, tarih aralığı, filtre seçenekleri ve arama sorguları birlikte ele alındığında botların önüne dev bir varyant evreni çıkar. Örneğin arama sonuç sayfası için her ?q=... değeri yeni bir URL’dir; bu da botun her terimi deneyip crawl bütçesini tüketmesine yol açar.

Bir diğer kritik desen token/oturum içeren URL’lerdir. URL’de token, session, auth gibi parametreler varsa bu içerik çoğu zaman kişiseldir ve indekslenmemelidir. Botların bu sayfalara erişme denemeleri hem crawl israfı yaratır hem de güvenlik/PII (kişisel veri) riskini artırır.

Aksiyon haritası: robots.txt, meta robots, X-Robots-Tag, canonical, noindex, 404/410 ve rate-limit

Artık logdan gördüğünüz sayfa kümelerine göre aksiyon planı çıkarma zamanı geldi. Crawl bütçesi optimizasyonu “tek bir ayar” ile bitmez; dışlama (disallow/noindex), yönlendirme (redirect), kopya sinyaller (canonical) ve erişim hızı (rate-limit) gibi parçaların birlikte çalışması gerekir.

Robots.txt çoğunlukla botun bazı yolları hiç denememesini sağlamak için kullanılır. Meta robots / X-Robots-Tag ise sayfanın taranmasına izin verip indekslenmesini engelleyebilir. Chat sitelerinde indekslenmeyecek sayfalar için noindex daha ince bir kontrol sağlar; ancak URL’ler taranmaya devam ederse crawl bütçesi yine tüketilir. Bu yüzden log tabanlı karar mekanizması önemlidir: Hedefiniz sadece indekslemeyi engellemek mi, yoksa tarama denemelerini de gerçekten azaltmak mı?

Aşağıdaki örnek “karar akışını” pratik hale getirelim:

1. Logdan bir URL kümesini belirleyin (ör. parametreli sohbet arama).
2. Bu kümenin indekslenebilir içerik üretip üretmediğini sınıflandırın (aynı içerik mi, benzersiz kullanıcı üretimi mi?).
3. İndekslenebilir değilse: canonical/noindex ve mümkünse robots disallow ile tarama denemelerini azaltmaya odaklanın.
4. Eski ve artık kullanılmayan URL’ler için: 404/410 stratejisiyle botun tekrar tekrar denemesini minimize edin.
5. Oturum/token sayfalarında: erişim kontrolünü güçlendirin, gerekirse rate-limit/WAF ile tarama maliyetini düşürün.

Örnek senaryolar (mini vakalar) ve beklenen crawl bütçesi etkisi

Vaka 1: Parametreli sohbet arama sayfalarının (?q=...) taranıp kaynak israf etmesi. Logda /live-chat?q=... türü URL’lerin çok sayıda benzersiz query ile tekrar tekrar istendiğini görürsünüz. Çözüm: Bu sayfalar indekslenmeyecekse canonical ile ana arşiv/oda sayfasına yönlendirin ve noindex uygulayın. Ek olarak, parametreleri normalize ederek farklı query’leri aynı “sayfa kümesi” altında raporlayın; böylece gerçekten nerede israf olduğunu ölçersiniz.

Vaka 2: 404/410 döngüsüne giren eski sohbet odası URL’leri. Eğer eski oda slug’ları kaldırıldıysa ve botlar hâlâ eski URL’leri deniyorsa crawl bütçesi 404’lerde boşa akar. Strateji: Kalıcı kaldırmalarda 410 kullanmayı değerlendirin (varsa). Ayrıca 404’lerde tekrar eden denemeleri izleyip, mümkünse doğru redirect (301/308) veya temizleme politikası uygulayın.

Vaka 3: Botların oturum/üye sayfalarını taraması ve erişim/kısıtlama ile azaltma. Logda /account, /me veya token içeren endpointlere yüksek 401/403 görüyorsanız bu, botların sınırın yanlış anlaşıldığını düşündüğü anlamına gelebilir. Çözüm: Erişim kontrolünü sadece istemciye bırakmayın; server tarafında doğru HTTP kodlarıyla yanıt verin. Ardından robots/meta noindex ya da sayfa bazlı X-Robots-Tag ile indeks sinyallerini kapatın.

Vaka 4: /live-chat, /chat-room gibi sayfa tipleri için URL kümeleri ve metriklerin yorumlanması. Örneğin /live-chat “giriş” ekranı, /chat-room ise “gerçek oda”ysa, bot isteklerinin büyük kısmı giriş ekranında yoğunlaşıyorsa iç link yapılandırması ve taranabilirlik değerlendirilir. Logdan geçiş oranına bakın: bot giriş ekranından oda sayfasına geçiyor mu, yoksa yalnızca giriş ekranında geri mi dönüyor?

Doğrulama: GSC URL Denetimi, Crawl stats ve log ile geri kontrol periyodu

Optimizasyon yaptıktan sonra “beklenen etkiyi” görmek gerekir. Bunun en pratik yolu log ile geri kontrol yapmaktır: Önceki dönemde taranan URL kümelerinin istek hacmi ve durum kodları azalıyor mu? Benzersiz query varyant sayısı düşüyor mu?

GSC tarafında URL Denetimi ve Crawl stats verilerini de tamamlayıcı olarak kullanın. GSC daha çok indeksleme/keşif perspektifi sunar; log ise gerçek istekleri gösterir. Bu yüzden farkları yanlış yorumlamak mümkün: Logda taranan bir URL’nin indekslenmemesi tek başına normal olabilir; ama logda tarama azalmıyorsa crawl bütçesi optimizasyonu eksik kalmış demektir.

Adım adım doğrulama yaklaşımı: (1) Logdan optimasyondan önce hedef kümeyi seçin ve bot başına istek metriklerini kaydedin. (2) Robots/noindex/canonical ve erişim kısıtlarını uyguladıktan sonra 7 gün gözlem penceresi açın. (3) Sonrasında hem log metriklerini hem de GSC’de ilgili URL tipleri için “taranan/indekslenen” sinyallerini birlikte karşılaştırın; gerekiyorsa ayarı iteratif şekilde revize edin.

Yaygın hatalar

Log analizi yaparken en sık karşılaşılan hata, normalizasyonu ihmal ederek “aynı içeriğin” farklı URL’ler olarak şişkin görünmesine yol açmaktır. Bu durumda crawl bütçesi problemi olduğundan büyük görünür ve yanlış kümeye müdahale edebilirsiniz. En azından path + parametre kümesi ayrımı yapmadan karar vermeyin.

İkinci yaygın hata, robots.txt ile disallow yapıp taramanın tamamen biteceğini varsaymaktır. Bazı durumlarda bot disallow’a rağmen URL keşfedebilir, bağlantılar üzerinden deneme yapabilir ya da farklı davranabilir. Bu nedenle robots yerine noindex/X-Robots-Tag kombinasyonu veya erişim kısıtları gibi katmanlı strateji düşünün. Üçüncü yaygın hata ise logları yalnızca “toplam istek” üzerinden okumaktır. Durum kodu dağılımı ve tekrar sıklığını görmeden gerçek israfı ayırt edemezsiniz.

Sık yapılan hatalar: güvenlik ve PII (kişisel veri)

Chat sitelerinde URL içinde oda adı, mesaj parametreleri, kullanıcı ID’leri ve token’lar bulunabilir. Log analizi sırasında bu değerleri raporlarken maskeleme uygulamadan paylaşmak ciddi risk yaratır. PII içerebilecek parametreleri (ör. token, sessionId, userId) hesaplamalarda kullanın ancak çıktı raporlarında anonimleştirin.

Bir diğer sık hata, şüpheli botları “önemsiz” saymaktır. Agresif botlar oturum/üye sayfalarına çarpıyor ve 4xx/5xx üretiyorsa bu hem güvenlik hem de crawl bütçesi açısından birlikte değerlendirilmelidir. Doğru rate-limit ve WAF kuralları crawl bütçesini de dolaylı olarak korur.

Analiz nasıl kontrol edilir? Adım adım süreç ve kontrol listesi

Log tabanlı crawl bütçesi optimizasyonunu sürdürülebilir kılmak için küçük bir kontrol listesi oluşturun. Her denetimde aynı listeyi kullanırsanız, aynı hataları azaltır ve yaptığınız değişikliklerin etkisini daha net ölçersiniz.

• Ön hazırlık: Nginx/Apache access log formatını doğrulayın, timestamp aralığını (7/30 gün) seçin, saat dilimini standardize edin.
• Bot segmentasyonu: Googlebot ve diğer crawler gruplarını UA/IP davranışıyla etiketleyin; şüpheli botları ayrıca işaretleyin.
• URL normalizasyonu: path + query kümesi çıkarın; “aynı içeriği temsil eden varyantları” gruplayın.
• Durum kodu analizi: 200/3xx/4xx/5xx oranlarını bot bazında karşılaştırın; 404/410 döngülerini tespit edin.
• Sayfa kümeleri: /live-chat, /chat-room ve oda mesaj/arama ekranlarını ayrı metrikle raporlayın.
• Aksiyon planı: İndekslenmeyecek kümeler için robots/noindex/canonical; artık yoksa 404/410/redirect stratejisini uygulayın.
• Doğrulama: GSC Crawl stats + log metriklerini birlikte izleyin; 7 günlük geri kontrol döngüsü uygulayın.

SSS

Server log’larda IP/UA filtrelemeyi nasıl yapmalıyım? UA tabanlı sınıflandırmayı birinci adım yapın, ardından davranış sinyaliyle (istek hızı, 4xx oranı, URL hedefleri) destekleyin. IP tabanı için güvenilir ASN listesini kullanmak daha tutarlı sonuç verir.

Normalizasyon yapmazsam crawl bütçesi analizi neden bozulur? Çünkü parametreli URL’ler aynı içeriği farklı varyantlar olarak çoğaltır. Böylece israfın kaynağı yanlış kümeye kayar ve optimizasyonun etkisini ölçemezsiniz.

Robots.txt mi meta robots noindex mi? Hangi durumda hangisi daha doğru? Hedef “botun hiç denememesini” azaltmaksa robots.txt daha uygun olur. Hedef “taramaya izin verip indekslemeyi engellemekse” meta robots/X-Robots-Tag daha iyi çalışabilir. Logdan tarama devam ediyorsa sadece noindex yetmeyebilir.

404 ile 410 arasındaki fark crawl bütçesi açısından nedir? 404 genelde geçici/var olmayan durum gibi algılanabilir; 410 ise kalıcı kaldırma sinyali verir. Logda sürekli denenen eski URL’lerde 410 yaklaşımı denemeye değer olabilir.

Log verisi ile GSC crawl stats arasındaki farkları nasıl yorumlamalıyım? Log gerçek istekleri gösterir; GSC ise keşif/tarama ve indeksleme durumlarını özetler. Logda tarama yüksek ama GSC’de indekslenme düşükse içerik değerinin düşük olması veya noindex/canonical etkisi olabilir.

Chat sitelerinde oturum/token içeren URL’leri nasıl güvenli şekilde analiz etmeli ve raporlamalıyım? Token/session değerlerini raporlarda maskeleyin, ham URL’leri paylaşmayın. Bu URL’leri ayrı bir “kısıtlı alan” kümesine alıp erişim kontrolleri ve indeks sinyallerini kapatın.

Analiz için ideal zaman aralığı nedir (7 gün / 30 gün)? İlk denetim için 7 gün çoğu zaman yeterli sinyali verir; kalıcı trend ve kampanya etkisi için 30 güne genişletin.

Tek bir bot yerine hangi crawler gruplarına odaklanmalıyım? Öncelikle Googlebot (varsa mobil/desktop ayrımı) ve birincil diğer arama motorlarını ayrı grup yapın. Ek olarak saldırgan/şüpheli crawler’ları ayrı inceleyin; crawl bütçesi israfını çoğu zaman onlar da büyütür.

İsterseniz bir sonraki adım olarak, sizdeki log formatına ve chat mimarinize göre URL normalizasyon kurallarını ve sayfa kümesi taksonomisini birlikte netleştirecek bir denetim tasarlayabilirsiniz. Böylece “hangi sayfalar taranıyor?” sorusunu yalnızca cevaplamakla kalmaz, crawl bütçesini ölçülebilir şekilde optimize edersiniz.

İç bağlantı önerileri: Chat sitelerinde crawl edilebilirlik yalnızca logla değil, sayfa tasarımıyla da güçlenir. Şu rehberlerinizle birlikte kullanabilirsiniz: paginasyon SEO: AJAX/dinamik yüklemede crawl edilebilir sayfa tasarımı ve sohbet siteleri için teknik stratejiler.