Chat’te Beğenilenler & Cevaplarım Sayfaları Crawl Edilsin mi? CTR–Dwell Time Ölçümüyle İndeks Kararı Rehberi

Chat ürünlerinde kullanıcı etkileşimini görünür kılan sayfalar—özellikle “beğenilenler / cevaplarım” gibi ekranlar—SEO ekibinin gündemine giderek daha sık giriyor. Bunun sebebi çok basit: Bu sayfalar doğru kurgulandığında değerli sinyaller üretebiliyor; yanlış kurguda ise indeks israfına ve gereksiz crawl’e dönüşebiliyor. Bu yazıda odaklandığımız soru şu: Chat sitesinde “kullanıcı etkileşim sayfası” (beğenilenler/cevaplarım) crawl edilebilir mi? CTR-dwell time ölçümüyle karar.
Bu soruya tek bir ölçümle “evet/hayır” demiyoruz. Ölçümün yanında teknik kapsamı ve risk yönetimini de birlikte ele alıyoruz. Hedefimiz, “crawled olsun/olmasın” kararını rastgele vermek yerine; CTR ve dwell time gibi performans sinyallerini temel alan bir karar matrisi kurmak.
Kapsam: “Kullanıcı etkileşim sayfası” nedir?
“Kullanıcı etkileşim sayfası” derken genellikle kullanıcı hesabıyla ilişkilendirilen ve kullanıcının platform içindeki tercihlerinin/aksiyonlarının listelendiği ekranları kastediyoruz. En sık gördüğümüz örnekler: beğenilenler, cevaplarım, etkileşim geçmişi ve bazı chatlerde favoriler benzeri varyantlar.
Bu sayfaların URL yapısı ve içerik üretim şekli farklılaşabiliyor. Bazıları oturum (login) ister; bazıları “anonim görünüm” sunar ama içerik maskelenir. Kimi sistemler SSR (server-side rendering) ile tam HTML üretebilir, bazıları ise AJAX ile listeyi sonradan doldurur. Tam da bu farklılıklar crawl edilebilirliği doğrudan etkiler.
- Varyant A (oturum gerektiren): Kullanıcıya özel içerik; bot erişimi kısıtlı olmalı veya indexleme sıfırlanmalıdır.
- Varyant B (erişimi kısıtlı ama genel): Bazı etkileşimler genel sayfaya “genel/anonim görünüm” olarak yansır; indekslenme riski orta-düşük seviyededir.
- Varyant C (AJAX + client render): Liste DOM’a sonradan gelir; crawler’ların gördüğü içerik yetersiz kalabilir.
- Varyant D (SSR + filtre parametreleri): İndekse girebilir; ancak parametreler ve pagination duplicate/ince içerik riski yaratır.
Neden bu sayfalar riskli?
Beğenilenler/cevaplarım sayfaları çoğu zaman “kullanıcı niyeti yüksek” gibi görünse de SEO açısından riskler genellikle küçümsenmez. En önde gelen risk ince içerik ve tekrardır. Çünkü bu sayfalar çoğu zaman aynı mesajların listelenmiş başka bir versiyonudur: içerik varyasyonu sınırlı kalır, değer sunumu ise çoğu durumda kullanıcıya yöneliktir.
İkinci risk kişiye özel (private/personal) içerik ihtimalidir. Bot aynı hesap bağlamına erişemezse “boş/teasersiz” içerik indekslenebilir; erişebilirse de başka kullanıcıya ait içerik görünmesi gibi gizlilik riskleri doğabilir. Bu yüzden sadece “noindex koyduk” yaklaşımı yetmez; crawl kapsamını da planlamak gerekir.
Üçüncü risk index israfı ve crawl bütçesidir. Kullanıcı sayısı arttıkça bu sayfalar yüz binlerce URL üretebilir. Search Console ve log’larda gördüğünüz tarama yoğunluğu gereksiz yere bu alanlara kaydığında, asıl kaynaklar (ör. gerçek içerik sayfaları) daha az keşfedilir.
Mevcut yaklaşımın sınırı: Sadece noindex/canonical ile yetinmek yetmez
Sık görülen senaryo şudur: “Bu sayfalar kullanıcıya özel, o yüzden noindex.” Evet, noindex indeks riskini azaltır; ancak crawling tamamen durmayabilir. Yani arama motoru URL’leri tarayıp sinyal kaynağı olarak kullanabilir; crawl bütçeniz harcanır ve bazı durumlarda yanlış tarama/yanlış önbellek davranışları tetiklenebilir.
Canonical/noindex ikilisinin bir sınırı vardır: CTR, dwell time gibi performans sinyallerini izlemediğinizde hangi sayfa türlerinin gerçekten değer ürettiğini ayırt edemezsiniz. Oysa doğru tasarımla bazı “genel ve kalıcı” etkileşim sayfaları indekslenmeye aday olabilir.
CTR–dwell time karar modeli: Hangi metrikler neyi yakalar?
İndeks kararı verirken CTR ve dwell time çiftini birlikte düşünmek kritik. Çünkü CTR tek başına “snippet ilgi çekti” der; dwell time ise “kullanıcı içerikte değer buldu” sinyaline yaklaşır. İki metriği birlikte yorumlayınca aşağıdaki problem desenleri daha net yakalanır.
Örneğin CTR yüksek ama dwell time düşükse, kullanıcının beklentisi ile sayfadaki içerik hizalanmamıştır. Bu durumda sorunun kaynağı snippet içeriği (başlık/description), sayfa içi ilk ekran tasarımı, filtreleme mantığı (kullanıcıyı ilgisiz sonuçlarla doldurma) veya sayfaya ulaşmanın “yanıltıcı” bir bağlamdan gelmesi olabilir.
Tersine CTR düşük ama dwell time yüksekse, içerik değerli olabilir ama snippet zayıftır ya da erişim kanalları (arama sonuçlarında görünürlük) yeterli değildir. Bu noktada noindex yerine görünürlük optimizasyonlarını düşünmek daha anlamlı hale gelir.
Event/analitik mimarisi: doğru kullanıcı akışı event’leriyle ölçün
Karar matrisi gerçekten işe yarasın istiyorsanız analitik altyapınız, sayfaların hangi versiyonunu sunduğunu ve kullanıcının sayfada ne yaptığını net ayırmalı. Beğenilenler/cevaplarım gibi listeler için “pageview” tek başına yeterli olmaz. Liste etkileşimleri, filtre değişimi, “scroll depth” ve “sonuç seçme” event’leri gerekir.
Ayrıca URL varyantlarını (UTM, ETag, pagination, parametreler) tutarlı biçimde raporlamak önemlidir. Aksi halde CTR/dwell time ile hangi varyantın eşleştiğini karıştırırsınız.
- Sayfa görünümü: Etkileşim sayfası “tam render” olduğunda (SSR veya client render tamamlandığında)
viewevent’i. - Liste tıklaması: Kullanıcı bir cevaba veya mesaja tıkladığında
interaction_clickevent’i. - Sayfada etkileşim: Liste içi filtre/sekme değişimi, “daha fazla yükle” gibi
facet_changeveload_more. - Snippet performans bağlantısı: GSC verisini sayfa URL’leriyle eşleştirirken parametreleri standardize et (ör. pagination indekslerini ayrı tut).
Şunu da unutmayın: “dwell time” ölçümü event tabanlı değilse (ör. yalnızca GA session duration gibi), yanlış yorum riski artar. İdeal yaklaşım: “ilk liste render” ile “ilk anlamlı tıklama/scroll durması” arasındaki süreyi ayrı ölçmektir.
Teknik gereksinimler: crawl edilebilirlik, oturum ve parameter yönetimi
Crawl edilebilirlik bir ikili durum değildir. robots.txt, sitemap.xml, internal linklenme ve sayfa erişim davranışı (login gate, 403/302/401) birlikte çalışır. Eğer etkileşim sayfası crawl edilecekse, arama motorunun görebileceği bir HTML çıktısı (ve mümkünse SSR veya bot-safe SSR) olmalıdır.
Oturum gerektiren sayfalar için iki strateji gündeme gelir: (1) Hiç endeksleme yaklaşımı (noindex + erişimi bot’a kapalı veya teasersız) veya (2) Sınırlı erişim yaklaşımı (genel/anonim teaser ile sınırlı içerik). Hangisini seçeceğiniz; içerik değeri, kişisellik riski ve indeksleme hedefinizle doğrudan ilişkilidir.
Parametre yönetimi de en az erişim kadar belirleyicidir. Pagination (sayfa=2, sayfa=3), filtreler (tarih, konu), dil/tema ve bildirim ayarları URL’ye yansıyorsa duplicate/ince içerik kaçınılmaz olur. Burada canonical kurallarını netleştirmek, sitemap’te indekslenecek canonical URL’leri listelemek ve filtre parametrelerini gerektiğinde “noindex” ile kapatmak gerekir.
Karar matrisi: indekslemeye izin mi, noindex mi, sınırla mı?
Aşağıdaki matris, CTR–dwell time sinyalini teknik risklerle birleştirerek karar verir. Mantık şudur: Önce “erişim ve içerik güvenliği” bariyerlerini geç, sonra “performans sinyali” ile indeks değerini doğrula, ardından crawl kapsamını kontrol et.
| Durum | Teknik risk seviyesi | CTR–dwell time sinyali | Aksiyon |
|---|---|---|---|
| (1) İndekslemeye izin | Düşük (genel/anonim, içerik kalıcı) | CTR orta-yüksek & dwell time orta-yüksek | Index + canonical doğru + sitemap’e dahil et |
| (2) Noindex | Yüksek (kişiye özel, boş/teaser kırılması, duplicate yoğun) | CTR yanıltıcı olma eğiliminde veya dwell time düşük | noindex + robots/kapsam kontrolü + parametreyi kapat |
| (3) Görünür ama sınırla | Orta (bazı filtreler genel, bazıları riskli) | CTR değişken ama dwell time düşük/kararsız | Görünürlük kısıtla: sınırlı sayfa/pagination + noindex parametre bazlı |
| (4) Crawl et ama indexleme | Orta-yüksek (tarama keşif için gerekli) | CTR düşük veya dwell time düşük (değer varsayımı doğrulanmadı) | robots/sitemap ile kontrollü crawl + noindex; kalite doğrulaması sonrası karar ver |
Bu matrisi uygularken şu varsayımı aklınızda tutun: CTR–dwell time yalnızca “indeks kararı için adayları ayıklamak” amacıyla kullanılır. Nihai kararın yanında içerik kalitesi, erişim güvenliği ve crawl bütçesi de eşit ağırlıkla değerlendirilmelidir.
Kontrol adımları: düşük risk deneyi, doğrulama ve geri alma
Kararları bir anda tüm sisteme yaymak yerine kontrollü deney yaklaşımı kullanın. A/B testi gibi düşünmeyin; crawl ve index davranışını etkileyen değişiklikleri küçük bir segmentte doğrulayın. Bu yaklaşım hem teknik ekip hem de SEO tarafında geri alma hızını artırır.
Nasıl kontrol edilir, adım adım doğrulama yaklaşımı:
- Pilot segment belirle: Örn. “son 7 günde etkileşim üreten ve genel/anonim teaser’ı olan” alt küme.
- Index ayarlarını kontrol et: noindex/index ve canonical’i varyant bazında uygula; robots/sitemap uyumunu kontrol et.
- Ölçümü bağla: GSC’de indeks durumu + analitikte event tabanlı dwell time raporlarını aynı canonical URL ile eşleştir.
- Eşikleri izle: Dwell time düşerse geri alma; CTR yükselmiyorsa snippet/ilk ekran uyumsuzluğunu düzelt.
Geri alma planı “yama yapmak” değil, kararı tersine çevirmek olmalı: ör. noindex’e dön, sitemap’ten çıkar, internal linklenme azaltsın. Böylece crawl bütçesi ve index kalitesi hedefiniz zarar görmez.
Örnek senaryo 1: CTR yükseliyor ama dwell time kısa—neden ve ne yapmalı?
Diyelim ki beğenilenler sayfalarınız arama sonuçlarında iyi görünüyor ve CTR belirgin şekilde yükseldi. Buna rağmen dwell time kısa kalıyor. Bu tablo genellikle kullanıcının snippet’te gördüğü şeyle sayfada ilk ekranda gördüğü şeyin uyuşmadığını işaret eder.
En sık karşılaşılan nedenler şunlardır: (1) Başlık ve description etkileşim türünü doğru yansıtmıyor, (2) sayfa ilk ekranı “liste boş/teaser” kalıyor (AJAX geç render, bot-safe içerik zayıf), (3) filtre mantığı kullanıcının beklentisine göre sonuç üretmiyor, (4) sonuç sayfası yoğun ama değeri düşük (çok benzer içerik tekrar ediyor).
Bu senaryoda yapmanız gerekenler: snippet iyileştirme (başlık/ilk metin), ilk ekranı değerle doldurma (SSR veya bot-safe ilk liste), sonuç sayfası filtrelerini “kullanıcının niyetini karşılayacak” şekilde düzenleme. Ayrıca dwell time düşüşünün kaynağını bulmak için scroll depth ve ilk tıklama event’lerine bakın.
Örnek senaryo 2: Cevaplarım sayfası crawl ediliyor ama indeks israfı yaratıyor—noindex veya görünürlüğü kısıtlama
Cevaplarım sayfası crawl ediliyor olabilir; ancak GSC’de “kalite uyarıları” veya indekslenme oranı düşük olmasa bile “ince/tekrar” görünümü artabilir. Bu durumda CTR/dwell time verisi de çoğu zaman çarpıklaşır: bazı kullanıcılar tıklıyor ama sayfada değer bulamıyor ya da çok hızlı geri dönüyor.
Buradaki çözüm iki yoldan biri olabilir. Eğer içerik kişiye özel ve genel arama değerini taşımıyorsa noindex kararı ve erişim kapsamı kısıtlaması uygulayın. Eğer içerik genel/anonim modda sunuluyorsa ama varyantlar (filtre/pagination) indeks israfı yaratıyorsa “görünür ama sınırla” yaklaşımını seçin: pagination derinliğini kısın, filtre parametrelerini indeks dışına alın, sitemap’te yalnızca canonical doğruları bırakın.
Örnek senaryo 3: Oturum gerektiren etkileşim sayfaları için Google bot erişimi nasıl kurgulanır?
Oturum gerektiren etkileşim sayfalarında kritik konu güvenlik ve gizlilik riskidir. Botun kullanıcı hesabına erişmediği bir akışta sayfanın boş kalması, indekslenirse “değer yok” sinyali doğurabilir. Bu nedenle hiç endeksleme çoğu durumda en doğru başlangıçtır.
Alternatif olarak “sınırlı erişim” stratejisi kullanılabilir: bot-safe bir teaser (ör. sadece genelleştirilmiş etkileşim istatistikleri veya kamuya açık içeriklere bağlantı listesi) gösterilir; kişiye özel veri maskelenir. Bu kurguda noindex/robots ile hangi katmanın indeksleneceğine karar verilir. Ancak kişisel veri unsuru varsa default yaklaşım noindex olmalıdır.
Yaygın hatalar
En sık yapılan hata, “noindex ekleyeyim yeter” sanmaktır. Noindex indekslemeyi engeller ama crawl bütçesi harcamasını her zaman tamamen durdurmaz. Etkileşim sayfaları URL keşfedilmeye devam ederse, kaynaklar yanlış yerlere akabilir.
İkinci yaygın hata, CTR–dwell time’ı tek başına yorumlamaktır. CTR yükseldi diye indekslemeyi genişletmek; dwell time kısa olduğu halde devam etmek, arama sonuçlarında düşük memnuniyete yol açabilir ve uzun vadede kalite algınızı zedeler.
Nasıl kontrol edilir? Kontrol listesi ile doğrulama
Aşağıdaki kontrol listesiyle “beğenilenler/cevaplarım crawl edilebilir mi?” sorusunu somut kanıtlara bağlayın.
- GSC: Hangi canonical URL’ler gerçekten indeksleniyor, hangi sayfalar “keşfedildi ama indexlenmedi” durumunda?
- Log’lar: Google bot bu sayfalara ne kadar sık gidiyor, crawl bütçesi diğer içerik türlerini etkiliyor mu?
- Event tracking: Dwell time metrikleri “ilk liste render” ile “ilk anlamlı etkileşim” aralığını doğru yansıtıyor mu?
- Render testi: AJAX doldurmalı liste bot tarafından yeterli görünüyor mu, yoksa SSR gerekiyor mu?
- Index sinyali: Sayfa kalitesi (tekrar/ince içerik) uyarıları artıyor mu?
Bu adımları tamamladıktan sonra “index/noindex” kararını verin ve değişiklik sonrası 2-4 hafta boyunca hem GSC hem de analitik sinyalleri birlikte okuyun.
Negatif işaretler ve geri alma planı
Dikkat etmeniz gereken negatif işaretler arasında dwell time düşüşü, sayfa başına “ilk tıklama” oranında belirgin gerileme ve indekslenme kalitesinde kötüleşme yer alır. Bu sinyaller genellikle snippet uyumsuzluğu veya sayfa içi ilk ekran sorunlarına işaret eder.
Geri alma planı net olmalı: ör. indeks kapsamını daraltın, sitemap’ten ilgili alt kümeyi çıkarın, internal link sayısını azaltın ve gerekirse robots ile taramayı kısın. GSC’de indeks durumu ile event tabanlı dwell time’ı aynı URL canonical ile eşleştirmek, kararın yanlış mı yoksa doğru mu olduğunu hızlı görmenizi sağlar.
Uyumluluk/etik: kişisel veri ve kullanıcıya özel içerik riskleri
Kullanıcı etkileşim sayfaları doğası gereği kişisel veri barındırabilir: beğeniler, cevaplar, etkileşim geçmişi gibi. Bu yüzden gizlilik ilkeleri ile SEO kararları aynı masada ele alınmalı. “Aranabilir olsun” isteği, gizlilik gereklilikleriyle çakışabilir.
Genel çerçeve olarak: kişiye özel veri görünüyorsa noindex ve erişim kısıtlaması yaklaşımı tercih edin. Genel/anonim bir teaser tasarımı gerekiyorsa kişisel içerik maskelenmeli ve sadece kamuya açık alanlar index sinyali taşımalıdır. Ayrıca “hangi kullanıcıya hangi içerik gösterildiği” ayrımı ölçüm altyapınıza da yansıtılmalı; aksi halde yanlış dwell time sonuçları üretebilirsiniz.
Bu konuda daha fazlasını deneyimlemek ister misiniz?
Sohbet Odalarına Katılın →Ek ölçüm senaryoları: küçük vs büyük taban, içerik yoğunluğu
Küçük kullanıcı tabanında bu sayfaların arama sonuçlarına etkisi sınırlı kalabilir; fakat tarama keşfi yine de olur. Bu yüzden crawl bütçesi etkisini log’larla izlemek daha da önem kazanır. Büyük tabanda ise URL sayısı patladığı için risk daha hızlı büyür: parametreli varyantlar, pagination ve filtreler kontrolsüzse indeks israfı kaçınılmaz hale gelir.
İçerik yoğunluğu düşük olan etkileşim sayfalarında (az beğeni/az cevap) dwell time beklenen değeri karşılamaz; bu da “ince içerik” riskini yükseltir. İçerik yoğunluğu yüksek olanlarda ise sayfa değeri artabilir. Bu durumda eşik yaklaşımıyla sınırlı bir alt kümenin indekslenmesi daha mantıklı olabilir.
Arama sonuçlarındaki tıklama davranışı da önemlidir. Örneğin yalnızca belirli anahtar kelimelerde CTR artıyorsa ve dwell time kısa kalıyorsa, “spesifik niyet” ile sayfanın içeriği uyuşmuyor demektir. Bu durumda snippet iyileştirme yerine sonuç türünü ve filtreleme tasarımını gözden geçirmek daha doğru olur.
FAQ: sık sorulan sorular
Google bu sayfaları ne kadar tarar? Crawl bütçesini nasıl etkiler?
Tarama sıklığı; URL sayınıza, içerik değişim hızınıza ve sitenizin genel tarama davranışına bağlıdır. Etkileşim sayfaları çok URL üretiyorsa crawl bütçesi hızla tükenebilir; bu nedenle log + GSC ile düzenli izleyin.
Kullanıcıya özel (kişisel) içerik varsa nasıl yaklaşmalıyım: noindex mi, sadece genel/anonim görünüm mü?
Kişisel veri görünüyor ise default yaklaşım noindex’tir. Genel/anonim mod mümkünse kişisel içeriği maskelenmiş teaser ile sınırlı keşif/erişim sunun ve index kararını CTR–dwell time ile doğrulayın.
CTR–dwell time eşiğini nasıl belirlemeliyim? Benchmark nereden alınır?
Benchmark’ı sitenizde benzer amaçlı sayfalardan alın. Başlangıçta “pilot segment” ile baseline oluşturun. Sonra median değerler ve varyans üzerinden eşik tanımlayın (örn. dwell time median altı tekrar eden URL’lerde noindex).
GSC’de indeks durumu ile event tabanlı dwell time verisi nasıl ilişkilendirilir?
GSC bir sayfanın indekslenip indekslenmediğini ve arama performansını gösterir; event tabanlı dwell time ise kullanıcı davranışını. Aynı canonical URL üzerinden eşleştirin: indekslenen sayfalarda dwell time düşüyorsa risk artar.
AJAX ile doldurulan etkileşim listeleri crawl edilebilir mi, SSR gerekiyor mu?
Bazı durumlarda crawler’lar client render’ı kısmen görebilir ama risk her zaman vardır. Index kararını vermeden önce render test yapın. İlk listeyi SSR veya bot-safe render ile beslemek genellikle daha güvenlidir.
Canonical ve robots birlikte nasıl kullanılmalı?
robots ile taramayı yönetirken canonical ile indekslemeyi yönetin. Örneğin noindex ise robots ile keşfi sınırlamak crawl bütçesini korur; canonical ise duplicate sinyalini azaltır.
Sadece “kullanıcı etkileşim sayfası” değil, filtrelenmiş varyantlar da indekslenmeli mi?
Çoğu zaman filtrelenmiş varyantlar ince içerik üretir. En azından başlangıçta yalnızca kalıcı ve yeterli içerik üreten canonical filtreleri indeksleyin; diğerlerini noindex veya görünür ama sınırla modunda tutun.
İlgili kaynaklar
Bu karar sürecini daha hızlı kurmak için aşağıdaki başlıklara göz atabilirsiniz:
- Chat Sitelerinde Crawl Bütçesi için eşik yaklaşımı
- Pinned section / bölüm bazlı index-noindex stratejisi ve matris
- CTR ve dwell time ölçümünü event taxonomy ile kurma rehberi
Sonuç: Crawl kararı, metrikle doğrulanan bir mühendislik işi
Beğenilenler/cevaplarım gibi kullanıcı etkileşim sayfalarının crawl edilebilirliği, tek bir “noindex var mı yok mu?” sorusu değildir. Crawl bütçesi, erişim kısıtı, duplicate/ince içerik ve kişisel veri risklerini yönetmek; ardından CTR–dwell time sinyalleriyle indeks değerini doğrulamak gerekir.
Doğru tasarım ve ölçüm altyapısıyla bu sayfalar bazı koşullarda indekslenebilir. Koşullar sağlanmıyorsa ise “crawled olsun ama indexleme” veya “görünür ama sınırla” gibi hibrit stratejilerle hem keşfi sürdürür hem de arama kalitesini korursunuz. En önemlisi: her kararı pilot segmentte test edin, GSC ve event verisini aynı canonical ile eşleştirip hızlı geri alma planınızı hazır tutun.
Sıkça Sorulan Sorular
Evet, bazı varyantlarda teknik olarak crawl edilebilir; ancak tek başına “crawl edilir/edilmez” kararı verilmez. Oturum gerektiriyorsa bot erişimi kısıtlanmalı veya indexleme sıfırlanmalıdır. Erişim genel/anonim ise risk orta-düşük olabilir. AJAX ile client render olan ekranlarda crawler gördüğü içerik yetersiz kalabilir. SSR olsa bile filtre/pagination parametreleri duplicate ve ince içerik üretebilir. Bu nedenle crawl ve index kararı, teknik kapsam + risk yönetimiyle birlikte verilir; CTR ve dwell time gibi sinyallerle karar matrisi kurmak önerilir.
ChatYerim'de Binlerce Kişi Seni Bekliyor
Hemen ücretsiz hesabını oluştur, sesli ve görüntülü sohbet odalarına katıl.
Hemen Katıl