Sohbet Sitesi SEO İçin Server Log Analizi: Hangi Sayfalar Google/Bot Tarıyor? (Adım Adım Rehber)

Sohbet sitesi büyüdükçe içerik yalnızca “sayfalar”dan ibaret kalmaz: sohbet odaları, mesaj akışı, kullanıcı profilleri, öneri/akış endpoint’leri ve çoğu zaman gerçek zamanlı çağrılar da devreye girer. Bu yüzden “hangi sayfalar taranıyor?” sorusuna ekran görüntüsüyle değil, somut veriyle cevap vermek gerekir; işte tam da bu noktada sohbet sitesi SEO için log dosyası analizi (server logs) ile hangi sayfalar taranıyor yaklaşımı kritik hale gelir.

Bu rehberde server log’larınızı (Nginx/Apache + reverse proxy + CDN varsa ilgili loglar) analiz ederek botların (özellikle Googlebot) sohbet sitenizde hangi URL/endpoint’leri gerçekten taradığını birlikte çıkaracağız. Ayrıca taranmayan ya da yanlış taranan sayfalar için net bir aksiyon planı oluşturacağız; “render edilmediği için görünmüyor” ya da “robots.txt izin verse de bot farklı davranıyor” gibi gerçek hayattaki tuzakları da gündeme alacağız.

Log analizi neden kritik? (chat sitelerinde dinamik içerik ve uzun kuyruklu sayfalar)

Sohbet sitelerinde dinamik içerik yüzünden klasik SEO raporları (yalnızca Search Console veya index sayısı) çoğu zaman gecikmeli ve dolaylı kalır. Mesela bir oda açılır açılmaz saatler içinde botlar bazı varyasyonları deneyebilir; ama aynı odanın mesaj sayfaları, arama sonuçları ya da öneri akışları “görünür içerik” olarak indexlenmeyebilir.

Log analizi ise bot trafiğinin “gerçek istek” düzeyinde ne yaptığını görmenizi sağlar. Böylece şu sorulara daha net cevap bulursunuz: Hangi URL’ler gerçekten istek görüyor? 404/410’lu eski oda linkleri hâlâ taranıyor mu? robots.txt bazı sayfaları engelliyor ama bot hâlâ deniyor mu? En önemlisi: taranıyor ile indexleniyor aynı şey değil; log size ilk kısmı söyler, devamında teknik/erişilebilirlik katmanıyla birlikte yorum yapılır.

Özellikle “uzun kuyruklu URL” (çok sayıda benzersiz oda slug’ı, kullanıcı profili, arama terimi, sayfalama parametreleri) barındıran chat sistemlerinde, tarama bütçesi çok hızlı biçimde israf edilebilir. Loglar bu israfın tam olarak nerede başladığını gösterir.

Hangi log türleri gerekir? (web server, reverse proxy, CDN, uygulama logları)

Doğru sonuç için log katmanlarını doğru sırayla ele almalısınız. Genelde şu kaynaklar işin içine girer:

• Web server logları (Nginx/Apache): En temel istek kaydı burada olur; method, path, status code, user-agent ve çoğu kurulumda client IP bilgisi yer alır.
• Reverse proxy logları (Nginx önünde başka bir load balancer varsa): Gerçek bot davranışı bazen proxy katmanında daha net izlenir.
• CDN logları (Cloudflare/Fastly/Akamai vb. kullanıyorsanız): CDN bot filtreleme yapıyorsa, origin’a ulaşmayan istekleri de görebilirsiniz.
• Uygulama logları: Örneğin endpoint isabeti, kullanıcı/oda kimliği, SSR mi SPA mı render edildiği gibi sinyaller; ama her uygulama bunu loglamaz.

Uygulama loglarınız yoksa da sorun değil; endpoint → sayfa eşleştirmesi için Nginx/Apache log genellikle yeterli olur. Yine de “JS ile render edilen içerik” gibi durumlarda, uygulama tarafında render/SSR bilgisi varsa analiz kalitesi ciddi şekilde artar.

Bot/arama motoru trafiğini ayırma (User-Agent, IP, reverse DNS doğrulama)

Loglarda tarama davranışını sayfaya dönüştürmeden önce botları insan trafiğinden ayırmanız gerekir. En basit yöntem User-Agent filtrelemedir; ancak daha sağlam yaklaşım olarak IP ve reverse DNS doğrulamasını da eklemek gerekir. Çünkü sohbet sitelerinde “scraper” diye dolaşan pek çok farklı bot, benzer User-Agent’ları kullanabilir.

Pratik bir akış şöyle ilerler: Googlebot için UA eşleşmesi yapın, ardından IP aralıklarını (ve varsa reverse DNS) doğrulayın. Ek olarak bir botun farklı alan adlarından geldiğini veya CDN üzerinde farklı log formatları ürettiğini de hesaba katın.

Örnek Nginx/Apache log satırı üzerinden bot filtresi

Aşağıdaki örnek, Nginx’in tipik bir formatında Googlebot isteklerini yakalamaya yönelik hızlı bir bakıştır:

203.0.113.10 - - [13/Apr/2026:10:21:45 +0300] "GET /sohbet/oda-ankara?x=1 HTTP/1.1" 200 48231 "https://www.google.com/" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Burada iki sinyal öne çıkar: status code ve User-Agent. “Googlebot” UA’sını filtreleyip ilgili path’leri toplayarak; o botun hangi oda/akış URL’lerini denediğini görebilirsiniz. Reverse proxy/CDN kullanıyorsanız “gerçek bot IP’si” ile “proxy IP’si” karışabildiği için X-Forwarded-For gibi header’ların kaydını da kontrol etmek iyi olur.

Tarama verisini sayfa/URL’e dönüştürme (endpoint → sayfa eşleştirme)

Sohbet sitelerinde URL’ler çoğu zaman tek bir HTML sayfasına karşılık gelmez. Örneğin oda sayfası görünür HTML’yi verebilir; mesaj akışı ise ayrı bir endpoint’ten (REST/GraphQL/WebSocket/SSE/AJAX) çekilir. Log’ta “taranıyor” gibi görünen şey bazen bir HTML sayfası değil, bir endpoint isteği olabilir.

Bu nedenle doğru analiz için endpoint → sayfa eşleştirme tablosu hazırlamanız gerekiyor. Örneğin:

• Oda ana sayfası (SSR/HTML) varsa: /sohbet/{oda-slug} veya /o/{slug}
• Mesaj akışı endpoint’i varsa: /api/rooms/{roomId}/messages veya /rooms/{roomId}/messages?cursor=...
• Arama endpoint’i varsa: /search?query=... veya /rooms/search/{query}
• Kullanıcı profili: /u/{username}

Bu eşleştirme olmazsa yalnızca path istatistiği çıkarmak “tarama bütçesi” sorunlarını yanlış yorumlatabilir. Örneğin bot mesaj endpoint’ini çok sık çağırıyor olabilir; fakat bu endpoint indexlenemiyor/HTML üretmiyor olabilir. Ya da tam tersi: bot oda sayfasını seyrek tarıyor, mesajları daha sık çekiyor olabilir; bu da render/indexlenebilirlik tarafında bir problem işaret eder.

Durum kodları ve tarama kalitesi (200/3xx/4xx/5xx) ile birlikte yorumlama

Log analizinde en kritik metriklerden biri status code dağılımıdır. Ancak sadece “200 çok” demek yetmez. 3xx yönlendirmelerinin doğru hedefe gitmesi, 4xx ve 5xx’lerin hangi URL desenlerinden çıktığı ve botun gerçekten içeriğe ulaşıp ulaşmadığı birlikte yorumlanmalıdır.

Genel yorum rehberi:

• 200: Bot içerik almış olabilir; burada HTML/SSR mi JSON mu aldığınızı endpoint eşleştirmeyle doğrulayın.
• 3xx: 301/302 döngüleri veya yanlış canonical/redirect zincirleri tarama verimini düşürür. Sohbet sitelerinde oda slug varyasyonları sık olabildiği için yönlendirme kalitesi önemli hale gelir.
• 4xx (özellikle 404/410): Eski oda linkleri, yanlış parametreler veya erişim kısıtları. Taranan ama indexlenmeyen uzun kuyruk burada kendini gösterebilir.
• 5xx: Botun denediği sırada servis hatası. Bu durum crawl’lerin “quality”sini düşürür ve botun tekrar deneme sıklığını azaltabilir.

Status code dağılımını Googlebot’a özel ve diğer botlara özel ayrı ayrı raporlamak daha anlamlıdır. Çünkü sohbet sitelerinde farklı bot davranışları (ör. sosyal önizleme botları, scrapers, yanlış UA kullananlar) aynı endpoint’lere farklı yoğunlukta yüklenebilir.

Robots.txt, sitemap ve canonical etkisini log üzerinden doğrulama

robots.txt ve sitemap.xml mantıksal olarak “bot ne yapmalı?”yı tanımlar; log ise “bot ne yaptı?” sorusunun cevabını verir. Bu iki kaynağı birlikte görmek, özellikle chat odalarında URL patlaması yaşayan sitelerde en hızlı teşhis yollarından biridir.

Örneğin robots.txt ile bazı sayfaları engellediyseniz, log’da ilgili path’lere istek gelmesi beklenen davranışla uyumsuz görünür. Beklenti genelde şudur: Bot o URL’yi taramaya devam etmez veya en azından istek sayısı belirgin düşer. Engellediğiniz halde aynı URL’ler sık sık isteniyorsa; (1) robots.txt yanlış konfigüre edilmiştir, (2) bot robots kurallarını uygulamıyordur, (3) CDN cache/redirect yüzünden istek farklı bir endpoint’e yönleniyordur.

Canonical için de aynı yaklaşım geçerlidir: canonical yanlışsa bot farklı varyasyonları taramaya devam edebilir; doğru canonical ile yönlendirme/etiketler düzeltilmiş olsa bile botun “eski varyasyonları” bir süre daha denemesi normaldir. Bu yüzden trend analizi yapmak önem taşır.

Bu adımı desteklemek için şu rehberden robots.txt ve sitemap kurgusunu kontrol edebilirsiniz: Chat Sitesi SEO: robots.txt ve sitemap.xml Dosyaları Nasıl Yapılandırılır? (Adım Adım Rehber).

Sohbet sitelerinde sık görülen URL desenleri: oda, mesaj, profil, arama, öneri/akış endpoint’leri

Sohbet sitenizin teknik yapısına göre URL desenleri değişir; ama çoğu chat platformunda aşağıdaki kategoriler tekrar eder. Log analizini hızlandırmak için önceden bir desen sözlüğü hazırlamanız işinizi kolaylaştırır. Böylece “%20’si nedir?” gibi detay sorulara dakikalar içinde yanıt verebilirsiniz.

Örnek URL desenleri (tipik şablonlar):

• Oda: /sohbet/{sehir}-{ilce}/{oda-slug} veya /oda/{slug}
• Mesaj: /api/rooms/{roomId}/messages, /rooms/{roomId}/messages?cursor=...
• Profil: /kullanici/{username} veya /u/{id}
• Arama: /arama?query=..., /search?text=...
• Öneri/akış: /api/recommendations, /feed?type=rooms, /stream/...

Bu desenleri kullanarak log path’lerini kategorilere ayırdığınızda, botların gerçekten hangi “SEO değerli” sayfalara yöneldiğini anlarsınız. Sohbet sitelerinde SEO değeri genelde oda sayfaları ve kullanıcı profillerindedir; mesaj endpoint’leri çoğunlukla HTML üretmez ve “indexlenebilir sayfa” gibi değerlendirilmemelidir.

Örnek: URL desenleriyle sohbet odası ve mesaj endpoint’lerinin ayrıştırılması

Diyelim ki log’da şu iki tür istek sık geliyor:

GET /sohbet/oda-ankara HTTP/1.1 200 ...
GET /api/rooms/12345/messages?cursor=... HTTP/1.1 200 ...

Bu durumda “bot tarıyor” yorumunu doğru yapmak için endpoint eşleştirmesi gerekir. Odalar genellikle taranıp indexlenmesi hedeflenen HTML sayfalarıdır; mesaj endpoint’leri ise genellikle dinamik veri sağlar ve sayfa olarak indexlenmeyebilir.

Bu ayrımı yaptıktan sonra şu sonucu çıkarabilirsiniz: Googlebot oda sayfasını düzenli taramıyor ama mesaj endpoint’ini çağırıyor. Bu, muhtemelen oda sayfasının içerik/erişilebilirlik problemleri (ör. SSR yok, içerik JS bağımlı, internal linkler zayıf) yaşadığını ya da botun “önizleme” yerine başka bir akışa düştüğünü düşündürür.

Tarama sıklığı ve tarama bütçesi sinyalleri (gün içi dağılım, benzersiz URL sayısı)

Log analizi yalnızca “hangi URL”yi değil, aynı zamanda “ne kadar sık” tarandığını da gösterir. Sohbet sitelerinde gün içine yayılan istek dağılımı önemlidir: Etkin saatlerde botların yükü artıyor mu, yoksa her gün aynı eski URL’ler tekrar tekrar mı isteniyor?

Tarama bütçesi sinyali olarak şunları raporlayın:

• Gün içi saat bazında Googlebot istek sayısı (dağılım).
• Belli bir periyotta benzersiz URL sayısı (ör. son 7 günde farklı oda slug’ı denendi mi?).
• Aynı URL’ye tekrar deneme oranı (ör. 404 dönen URL’ler tekrar tekrar mı soruluyor?).
• Endpoint karışımı: SEO değerli HTML sayfaları oranı vs API/JSON istek oranı.

Örneğin bot “eski oda” URL’lerini 404 olarak sürekli istiyorsa, tarama bütçesi boşa harcanır. Bu da “crawl budget” yönetimi gerektiren klasik bir işarettir. Sohbet sitelerinde Crawl Budget konusunu ayrıca şuradan okuyabilirsiniz: Sohbet Sitelerinde Crawl Budget (Indexleme Bütçesi) Yönetimi: Sayfa Patlamasını Kontrol Etme Rehberi.

Örnek: 404/410 ile taranan “eski oda” URL’leri ve çözüm önerisi

Eski oda ya da silinmiş içerik linkleri sohbet sitelerinde sık görülür. Log’da şu senaryolar uyarı verir: Googlebot veya diğer botlar bir URL’ye tekrar tekrar istek atıyor ve her seferinde 404/410 dönüyor.

Örnek log kaydı:

66.249.73.12 - - [13/Apr/2026:11:02:31 +0300] "GET /sohbet/eski-oda-istanbul HTTP/1.1" 410 312 "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Çözüm yaklaşımı üçe ayrılır:

1. URL gerçekten kaldırıldıysa: 410 kalabilir; ancak botun aynı URL’yi uzun süre denememesi için iç linkleri ve harici sızıntıları temizleyin (yönlendirme/kanonikleştirme seçeneklerini gözden geçirin).
2. URL başka bir sluga taşındıysa: 301 yönlendirme ile yeni adrese taşıyın (mümkünse tek atlama yapın).
3. URL “geçici olarak kapandıysa”: 404 yerine uygun süreli mantık (ör. 302/503 + doğru başlıklar) ve tekrar deneme sinyallerini doğru kurgulayın.

Buradaki kritik nokta, log’da 404/410’un sadece varlığını değil, tekrar deneme yoğunluğunu da izlemenizdir. Tek bir istek normal sayılabilir; günlerce süren tekrarlar ise indeks/erişim planında revizyon ihtiyacını gösterir.

Örnek: robots.txt ile engellenen sayfaların log’da nasıl görünmesi gerektiği

Bir URL’yi robots.txt ile engellediğinizde log’da iki olasılıktan biriyle karşılaşırsınız: (1) bot o path’i daha az denemeye başlar ya da hiç denemez, (2) bazı botlar yine de denemeyi sürdürebilir; bu normal ama yoğunluk değişmeli.

Örnek senaryo:

GET /profil/username-amp HTTP/1.1 200 "-" "Googlebot/2.1 ..."
GET /profil/username-amp HTTP/1.1 200 "-" "Googlebot/2.1 ..."

Eğer robots.txt ile bu varyantın taranması engellendiğini düşünüyorsanız, log’da aynı URL varyasyonunun 200 ile sık gelmesi “robots engeli çalışmıyor” ya da “bu istek başka bir path üzerinden geliyor” anlamına gelebilir. Kontrol adımı olarak şunları yapın: robots kuralını ilgili path’e göre doğrulayın, CDN/edge kurallarının robots dosyasını override edip etmediğini kontrol edin ve son kullanıcıya görünen URL ile server log’daki path’in aynı olduğundan emin olun.

Örnek rapor şablonu: “Tarananlar / Taranmayanlar / Hatalı tarananlar / Aşırı tarananlar”

Analiz çıktınızı ekip içinde paylaşılabilir hale getirmek için aşağıdaki gibi bir rapor şablonu kullanabilirsiniz. Bu şablon; hem teknik SEO hem ürün ekibi hem de geliştirici için aksiyon belirlemeyi kolaylaştırır.

Kategori	Tanım	Örnek URL/Endpoint	Kanıt (Log Metriği)
Tarananlar	HTML/SEO sayfası veya hedeflenen endpoint düzenli isteniyor	/sohbet/oda-ankara	Googlebot: son 7 günde 120 istek, 200 oranı %85
Taranmayanlar	Sitemap’te var ama log’da düşük istek	/sohbet/oda-adana	Googlebot: son 7 günde 2 istek, 200 oranı %100
Hatalı tarananlar	4xx/5xx ile sürekli taranıyor	/sohbet/eski-oda-istanbul	410/404: günde 30+ istek, tekrar deneme yüksek
Aşırı tarananlar	Tarama bütçesini tüketen API/yanlış endpoint trafiği	/api/rooms/{id}/messages	Googlebot/API: istek hacmi çok yüksek, benzersiz sayfa düşük

Sitemap’te olan ama log’da az taranan sayfalar için kontrol adımları

Bu durum en sık şu sebeplerle yaşanır: URL’ler gerçekte erişilebilir değildir (redirect zinciri, auth gerektiriyor, rate-limit var), içerik indexlenebilir değil (JS render, geç yükleme), canonical veya internal link kurgusu sorunludur.

Özellikle sohbet odalarında oda slug’ı üretimi dinamikse ve sitemap sürekli güncellenmiyorsa, bot yeni URL’leri keşfetmekte zorlanabilir. Buna rağmen log’da istek hiç gelmiyorsa, sitemap “kâğıt üzerinde var” demektir.

Şimdi doğrulama adımları ile ilerleyelim:

1. Log’da URL’yi eşleştirin: Sitemap’ten bir URL alıp ilgili path’i log’da arayın; 404/3xx/401/429 gibi yanıtlar var mı kontrol edin.
2. Canonical ve redirect zincirini inceleyin: Aynı URL farklı varyasyonlara yönleniyor mu? 301/302 döngüsü var mı? Canonical etiketi hedef URL’yi doğru gösteriyor mu?
3. İç link ve keşif sinyallerini kontrol edin: Oda sayfası internal linklerle (arama sonuçları, kullanıcı profili listeleri, öneri modülleri) botun görebileceği alanlarda mı?
4. Render bağımlılığını test edin: Oda sayfası SSR yerine yalnızca JS ile içerik oluşturuyorsa botun aldığı “ilk HTML” yetersiz olabilir. Bu durumda log’da 200 görünür ama SEO değeri yoktur.

Bu süreçte robots/sitemap kurgusu ile ilgili temel kontrol noktalarını ayrıca gözden geçirmeniz faydalı olur: robots.txt ve sitemap.xml Dosyaları Nasıl Yapılandırılır?.

Sohbet odaları dinamik olduğu için log’da URL nasıl görünür? (render/JS etkisi)

Sohbet odaları çoğu zaman “ilk sayfa” ve “sonrasında dolan içerik” olarak iki katmanda çalışır. Bu nedenle log’da URL’nin görünümü sizi yanıltabilir: Bot oda URL’sini çağırır (200 alır) ama oda sayfası içindeki sohbet mesajları endpoint’lerden çekildiği için HTML içinde indekslenebilir içerik az olabilir.

Log’da şu iki sinyali birlikte okuyun: (1) oda sayfasına gelen isteklerin sayısı ve (2) bu sayfayı takip eden mesaj endpoint çağrıları. Eğer bot mesaj endpoint’lerine yönleniyor ama oda sayfasını seyrek tarıyorsa, keşif/indexlenebilirlik tarafında bir sorun olabilir. Tersine, oda sayfası var ama mesaj çağrıları yoksa botun “gönderilen ilk HTML” ile yetindiğini ya da endpoint’lerin bot için farklı davrandığını düşünün.

Tarama sorunları için aksiyon planı (indexlenebilirlik, yönlendirme, cache, rate-limit, render/JS etkisi)

Elinizde “tarananlar/taranmayanlar/hatalı tarananlar/aşırı tarananlar” ayrımı olduğunda, aksiyon planını kategorilere göre sıralamak daha kolay olur. Chat sitelerinde aksiyonlar genellikle dört ana başlık altında toplanır.

• Indexlenebilirlik: Oda sayfaları ve profil sayfaları SSR/önizleme dostu mu? Meta robots, sayfa içi bağlantılar ve canonical doğru mu? Mesaj endpoint’leri “indexlenebilir sayfa” olarak tasarlanmadıysa botu gereksiz şekilde onlara yönlendirmeyin.
• Yönlendirme & canonical: Eski oda slug’larını tek bir hedefe yönlendirin; 3xx zincirlerini kısaltın. Canonical yanlışsa bot farklı varyasyonları taramaya devam edebilir.
• Cache: CDN/edge cache yanlışsa bot sürekli origin’a vurur ya da doğru varyasyonları alamaz. Cache-control değerlerini ve vary başlıklarını test edin.
• Rate-limit & erişim: 429/403 gibi cevaplar botu durdurur ya da geri dönüşleri geciktirir. Bu kısıtların botları “haksız” etkileyip etkilemediğini doğrulayın.

Özellikle aşırı tarama tespit ettiğiniz endpoint’lerde (ör. mesaj akışı gibi) amaç, botu tamamen engellemek değildir; doğru sayfaları keşfetmesini sağlamak ve tarama bütçesini “SEO değerli” alana çekmektir. Bu nedenle robots.txt, canonical ve internal link stratejisi birlikte ele alınmalıdır.

Yaygın hatalar (Beklenen değil, en çok yapılan)

Log analizi yaparken ekiplerin düştüğü bazı tipik hatalar var. Bunları bilmek, yanlış sonuç çıkarma riskini azaltır.

• “Log’da 200 var = indexlenecek” sanmak: Sohbet odalarında 200 çoğu zaman HTML getirir ama içinde indekslenebilir içerik az olabilir. JS render söz konusuysa log’da “erişti” görürsünüz, fakat görünür içerik olmayabilir.
• Endpoint’i sayfa sanmak: Mesaj/akış API’leri indexlenebilir sayfaya karşılık gelmez. Tarama bütçesi israfı varsa bile bunu doğru kategoriye yazmadan aksiyonlar yanlışlaşır.
• Bot filtrelemeyi tek sinyalle yapmak: Yalnızca User-Agent’a güvenmek scraper’ları bot diye etiketleyebilir. IP/reverse DNS doğrulaması ve UA varyasyonlarıyla kontrol şarttır.
• robots.txt/sitemap’i güncelledikten “hemen” sonuç beklemek: Log değişimini görmek çoğu zaman tarama döngüsüne bağlıdır. Trend analizi yapın; tek güne bakmayın.

Nasıl kontrol edilir? (Adım adım doğrulama adımları / kontrol listesi)

Bu bölüm, pratik bir “log tabanlı doğrulama” kontrol listesi olarak kullanılabilir. Aynı akışı her sprint/ayın başında tekrarlamak, sohbet sitenizde crawl davranışını kontrol altında tutmanıza yardımcı olur.

1. Periyodu seçin: En az 7 gün (tercihen 14) log alın. Etkin saatleri de kapsasın. Aynı dönem içinde trafik dalgalanmasını yorumlamak daha kolay olur.
2. Botları ayırın: Googlebot ve diğer botları User-Agent + IP/reverse DNS mantığıyla ayrıştırın. Mümkünse “aynı botun varyasyon UA’ları”nı da gruplayın.
3. URL desen eşlemesi yapın: Oda, mesaj, profil, arama, öneri/akış endpoint’lerini kategoriye ayırın. Böylece “taranıyor” analizini SEO değeriyle eşleştirmiş olursunuz.
4. Durum kodlarını ve tekrarları raporlayın: 404/410/5xx oranını çıkarın; aynı hata URL’si tekrar deniyor mu, görün.
5. Sitemap/robots ile bağlayın: Sitemap’te olan ama az taranan URL’leri log’da arayın; robots ile engellenmesi gerekenlerde istek yoğunluğu artıyor mu bakın.
6. Aksiyon ve doğrulama: Redirect/canonical/cache/render değişikliklerini yaptıktan sonra, yeni log döneminde kategori bazlı metriklerin değişip değişmediğini kontrol edin.

Bu kontrol listesi uygulandığında, “hangi sayfalar Google/Bot tarıyor?” sorusunu sadece cevaplamakla kalmaz; sohbet sitenizin dinamik yapısına özel crawl davranışını ölçüp iyileştirebilirsiniz.

SSS

Googlebot’u loglardan nasıl ayırt ederim? En yaygın yöntem User-Agent içinde “Googlebot” geçtiğini kontrol etmektir; daha sağlam olması için IP aralıkları/Reverse DNS doğrulaması ekleyin. CDN kullanıyorsanız gerçek IP’nin hangi header’dan geldiğini teyit edin.

CDN kullanıyorsam hangi logları analiz etmeliyim? Origin logları tek başına her zaman yetmeyebilir; çünkü bazı istekler CDN’de sonlanır. Hem CDN hem origin loglarını birlikte kullanarak botun taradığı gerçek path’i daha doğru görürsünüz.

Log’da “taranıyor” ile “indirilmiş” arasındaki fark nedir? Loglar genellikle HTTP istek/yanıtını kaydeder. “Taranıyor” demek botun dosyayı/endpoint’i istemesi demektir; “indirilmiş” ise yanıtın alındığı ve büyük ölçüde başarılı geldiği anlamına gelir. Yine de indexlenme için içerik/parse edilebilirlik ayrıca değerlendirilir.

Sohbet odaları dinamik olduğu için log’da URL nasıl görünür? Oda ana sayfası bir URL ile gelir; mesaj içeriği ise farklı endpoint’lerden (API/cursor/WebSocket/SSE benzeri) çağrılır. Log’da hem oda URL’si hem mesaj endpoint’leri birlikte görülebilir; doğru yorum için endpoint → sayfa eşlemesi şarttır.

Taranmayan sayfaları nasıl önceliklendiririm? Öncelik sırası genelde: sitemap’te olan ama log’da az taranan SEO hedefleri, ardından 4xx/5xx kaynaklı hatalı taranan URL’ler ve son olarak aşırı taranan ama SEO değeri düşük endpoint’lerdir.

Sık 404 üreten URL’leri nasıl temizlerim? 404’lerin kaynağını (eski oda slug’ı, yanlış link, yönlendirme eksikliği) belirleyin. Mümkünse 301 ile güncel adrese taşıyın; gerçekten kaldırıldıysa iç linkleri ve harici sızıntıları temizleyin ve tarama tekrarını izleyin.

JS ile render edilen içerikler log’da nasıl değerlendirilir? Log’da 200 görmeniz render edildiği anlamına gelmez. Oda sayfasının HTML’inde indekslenebilir içerik olup olmadığını test edin; mümkünse SSR/prerender yaklaşımıyla botun ilk içeriği görmesini sağlayın.

Sitemap ve robots.txt değişikliklerini log’da ne zaman görürüm? Mutlak bir zaman yoktur; tarama döngüsüne bağlı olarak günler içinde fark edilebilir. En doğru yaklaşım, değişiklik öncesi ve sonrası aynı uzunlukta dönemleri karşılaştırarak trend görmek ve kategori bazlı (oda/profil/endpoint) metriklerin değişimini izlemektir.