Chat Filtreleri İçin Facet Bucket’lama: Aktiflik/Güven Seviyesi Facet Değerlerini Nasıl Indexlenebilir Hale Getirirsiniz?

chat sitesi tarafında kullanıcı filtreleri (aktif mi, güven seviyesi ne durumda gibi) için “indexlenebilirlik” kararı vermek, aslında modern sohbet platformlarının en zor teknik SEO problemlerinden biri. Çünkü filtreler çoğunlukla kullanıcı deneyimi için tasarlanır; ama arama motoru tarafında URL varyantlarına, kontrolsüz facet kombinasyonlarına ve sonuç olarak index bütçesinin boşa gitmesine yol açabilir.

Bu yazıda, noindex/render/URL kontrolü gibi tekil yaklaşımların ötesine geçerek facet değerlerini “değer sayısı + kullanım niyeti + doğruluk/umutilik” ekseninde cluster’layan; tek bir URL/param stratejisiyle indexlenebilirlik kararını sistematik hale getiren bir bucket’lama çerçevesi paylaşıyorum. Hedef net: indexi güçlendirmek, varyant çoğalmasını frenlemek ve kanibalizasyonu azaltmak.

Sorun Çerçevesi: Chat filtreleri neden varyant patlatır?

Chat sitelerinde filtreler genellikle “listeyi daralt” mantığıyla çalışır. Örneğin aktiflik (last seen/last active), güven seviyesi (trust score), oda tipi, dil, ülke, engel durumu gibi boyutlar aynı ekrana gelir. Bu noktada facet x facet çarpanı devreye girer. Her facet değeri bir URL paramına dönüştüğünde, arama motoru açısından neredeyse sınırsız sayıda “benzersiz sayfa” oluşur.

Varyant patlamasının ikinci büyük sebebi sayfalama ve offset farklarıdır. Bazı sistemler pagination yerine offset/limit kullanır; limit/offset kombinasyonları da ek varyant üretir. Pagination’da sayfa sayısı daha sınırlıyken, offset’te “sonsuz liste kaydırma” davranışı botların farklı offsetlerle tarama yapmasına imkân verir.

• Facet kombinasyon patlaması: aktiflik (4 bucket) x güven (3 bucket) x oda tipi (5) = 60 potansiyel filtre URL’si.
• Çoklu sıralama varyantları: en yeniler/önce eski, popülerlik, en çok mesaj atan vb. seçenekler indekslenmemesi gereken ayrışmalar yaratır.
• Dinamik skorlar: güven seviyesi zamana göre değişiyorsa “aynı parametre farklı içerik” üretir; canonical/noindex kararı daha da hassaslaşır.

Facet indexlenebilirlik karar matrisi (hangi koşullar indexe açılır?)

Her facet değerini “mutlaka indexle” ya da “mutlaka noindex” demek, chat platformları için çoğu zaman doğru olmaz. Daha iyi yaklaşım, facet değerini bir “arama niyeti birimi” gibi düşünmek ve indexlemeye açmanın getirisini (tıklanma/kalıcılık/kalite) index bütçesi maliyetiyle birlikte değerlendirmektir.

Aşağıdaki kriterler facet indexlenebilirlik karar matrisi için temel alınmalıdır: arama niyeti (SERP’de gerçekten karşılığı var mı?), kalıcılık (değer ne kadar stabil?), bot erişilebilirliği (render edilmeden görülebiliyor mu?), teknik doğruluk (bucket içerikleri vaat ettiği sınıfa gerçekten uyuyor mu?) ve umutilik (kullanıcıların aradığı bilgiye hizmet ediyor mu?).

Facet değeri/bucket özelliği	İndekse açma eğilimi	Gerekçe
Arama niyeti net (örn. “aktif son 24 saat”)	Index +	Sınırlı ve hedefli bir kümeye hizmet eder; SERP’de anlamlı gezinme sağlar.
Değer sayısı çok yüksek, kombinasyon patlıyor	Index - (noindex)	Index bütçesini tüketir; çoğu sayfa kullanıcıya “yeni bilgi” sunmaz.

Matrisin pratik kullanımında şu akış işe yarar: Önce facet değerlerini “bucket”a indirgersiniz. Sonra bucket’ın hangi klasöre (indexlenebilir küme) gireceğine karar verirsiniz. Böylece tekil değerler yerine yönetilebilir bir sayfa hiyerarşisi kurulur.

Bucket’lama modeli: ‘aktiflik’ ve ‘güven seviyesi’ gibi metriklere göre kategorize etme

Bucket’lama, tek tek facet değerleriyle sürekli uğraşmak yerine arama motoruna sunacağınız “kümeleri” tarif eder. Chat kullanıcı filtrelerinde en sık iki problem boyutu öne çıkar: zaman bazlı aktiflik ve davranış bazlı güven seviyesi. Bu iki boyutu doğru bucket’lamak, hem index israfını hem de kanibalizasyon riskini düşürür.

Örneğin “aktiflik” sürekli bir metriğe dayanıyorsa (son görülen dakika/saat/saniye), doğrudan indexe açmak yerine aralıklı bucket’lar oluşturun. “Güven seviyesi” de zamana bağlı veya olay bazlı değişiyorsa, bucket eşiklerini daha stabil bir zaman penceresiyle güncelleyin.

Bucket eşikleri nasıl belirlenir? (frekans/CTR, ziyaret & dönüşüm, SERP benzerliği, stabilite)

Bucket eşiklerini sadece “tahmin ederek” belirlemek yerine, ölçülebilir sinyallerle kurmalısınız. Eşik tasarımı SEO açısından iki şeyi aynı anda optimize eder: (1) kullanıcı niyeti için yeterince ayırt edici olmak, (2) arama motoru tarafında sayfa sayısını kontrol altında tutmak.

En doğru başlangıç, ölçülebilir sinyallerden gelmelidir: bucket başına filtre kullanım sıklığı, ortalama dönüşüm oranı (ör. gerçek sohbet başlatma), SERP benzerliği (benzer niyette sayfalar hangi granülerlikte sıralanıyor) ve değer stabilitesi (bucket’ın içeriği ne kadar çabuk başka bucket’a taşınıyor).

Pratik eşik önerisi

Eğer aktiflik verisi “dağılım” şeklindeyse bucket genişliklerini uçları kapsayacak ama orta bantlarda daha ayırt edici olacak şekilde tasarlayın. Güven seviyesi için ise üç sınıf (yüksek/orta/düşük) çoğu zaman iyi bir denge verir: indekslenebilir kümeler oluşur ve kombinasyon patlaması daha yönetilebilir hale gelir.

URL/param stratejisi: bucket kimliğiyle tekilleştirme

Indexlenebilirlik kararını doğru vermek kadar, uygulama tarafında URL üretim modelini doğru kurmak da kritik. Her bucket’ı “stabil bir kimlikle” temsil etmelisiniz. Böylece değer değişse bile URL mantığı aynı kalır; sadece bucket içeriği zaman içinde güncellenir.

Burada temel öneri: parametreyi ham değerden türetmeyin; bucket ID’si verin. Örneğin aktiflik facet’i için status_bucket=active_bucket_1 ya da güven facet’i için trust_bucket=high_only gibi kimlikler kullanın. Böylece “aktif 7 gün” gibi hassas bir değer doğrudan URL’de dolaşmaz.

1. Bucket kimliği üretin: aktiflik için 4 bucket, güven için 3 bucket gibi sabit bir set tanımlayın.
2. URL şablonunu tekleştirin: /chats?status_bucket=...&trust_bucket=... gibi parametreler her zaman aynı isimleri taşısın.
3. Sayfalama bağımsızlaştırın: offset/pagination parametreleri bucket indexlemeyi “çoğaltmasın”; mümkünse bucket sayfasında sınırlı sonuç gösterin ve “daha fazla”yi ayrı akışa taşıyın.

Noindex ve canonical politikası: bucket dışındakiler için ne yapmalı?

Bucket dışındaki değerler indexe açık olmamalı. Ama noindex/canonical uygulamasını “rastgele” yaptığınızda crawler davranışı düzensizleşebilir. En sağlıklı yaklaşım: indexlemeye açılan bucket’lara canonical verin; kapalı bucket’lar için noindex + robots talimatıyla taramayı da kontrollü hale getirin.

Politikayı şöyle düşünün: allowlist (indexlenebilir bucket listesi) seti tanımlanır. Bu setin dışındaki tüm kombinasyonlar noindex,follow (ve bot davranışına göre x-robots-tag) ile işaretlenir. Ayrıca içerik tamamen farklılaşsa bile index dışındaki bucket’lardan allowlist bucket’lara canonical akışı kurgulanabilir.

Index bütçesi ve kanibalizasyon önleme: benzer bucket’lar arasında hiyerarşi

Kanibalizasyon, farklı bucket URL’lerinin birbirine benzer içerik üretmesiyle oluşur. Chat platformlarında kanibalizasyon genellikle “iki bucket çok fazla kapsıyor” ya da “bucket’lar arası geçiş çok sık” olduğunda artar. Bu yüzden bucket tasarımında hem kapsama hem de sayfa hiyerarşisini birlikte düşünmelisiniz.

İki pratik kural: (1) bucket aralıkları çakışmasın (ör. aktif 8-30g bucket’ı ile aktif 1-7g çakışmamalı), (2) internal linking’i indexlenebilir bucket’ların lehine kurgulayın. Breadcrumb ve kategori yönlendirmeleri indexlenebilir kümeleri güçlendirsin; kapalı kümelerden “kendi kendini besleyen” link ekosistemi oluşmasın.

JavaScript/render ve crawl uyumluluğu: facet değerleri bot’a tutarlı sunulmalı

Facet sayfalarında sonuç listesi JS ile render ediliyorsa bot-safe bir yaklaşım şarttır. Google gibi botların render yeteneği olsa bile ilk taramada “mutlaka” doğru HTML içerik gösterilmelidir. Aksi halde hem indekse alma kalitesi düşer hem de bucket doğruluğu bozulur.

Uygulamada çözüm şu şekilde özetlenebilir: bucket sayfalarının SSR/ön-işleme ile bot’a aynı şablon üzerinden sunulması; facet değerlerine bağlı filtrelenmiş içeriklerin bot tarafından okunabilir olması; ayrıca bucket kimliğinin meta ve structured veri gibi unsurlarla doğrulanmasıdır. Böylece crawl loglarında da “doğru sayfa, doğru bucket” eşleşmesi daha net görünür.

Uygulama adımları: veri toplama → bucket tasarımı → test → kademeli yayın → izleme

Bu işi tek seferlik bir noindex kampanyasına dönüştürmeyin. Bucket’lama kararı bir ürün kararıdır ve ölçümle olgunlaşmalıdır. İlk adım, facet değerlerinin kullanım davranışını ve içerik değişim hızını toplamaktır.

Sonra bucket setini tasarlayıp allowlist’i oluşturursunuz. Ardından küçük bir yüzdeyle kademeli yayına geçersiniz. İzleme aşamasında iki tarafta birlikte bakarsınız: teknik sinyaller (index, crawl, render hataları) ve kalite sinyalleri (arama görünürlüğü, CTR, dönüşüm).

Örnek 1 (Aktiflik facet’i): {aktif <24s, aktif 1-7g, aktif 8-30g, pasif 30g+}

Farz edelim aktiflik facet’inizin ham verisi çok granular; ama raporlama için şu bucket’ları önermek istiyorsunuz: aktif <24s, aktif 1-7g, aktif 8-30g, pasif 30g+. Burada indexlenebilirlik kararı “niyet + değer stabilitesi + içerik kalitesi” ile birlikte ele alınmalıdır.

Öneri yaklaşımı:

• Indexe açın: aktif <24s ve aktif 1-7g. Çünkü bu aralıklar çoğu zaman “şu an sohbet edecek aktif kullanıcı/oda” niyetiyle daha doğrudan ilişkilidir.
• Noindex yapın: aktif 8-30g bazen indekse açık olabilir; ancak sayfa boyutu çok küçükse veya içerik birbirini fazla tekrar ediyorsa noindex’e alın. pasif 30g+ ise genellikle düşük niyet ve içerik seyrelmesi riski taşıdığı için noindex’e daha uygun olur.

Eğer platformunuzda “pasif 30g+” bucket’ı gerçekten aranıyor ve içerik kalitesi yüksekse, allowlist’e almayı düşünebilirsiniz; fakat bunu karar kılmak için arama görünürlüğü + filtre kullanım sıklığı verisi görmeniz gerekir.

Örnek 2 (Güven seviyesi facet’i): {yüksek, orta, düşük} ve ‘high_only’ / ‘medium_or_high’ bucket’ları

Güven seviyesi facet’inde amaç, kullanıcı deneyimini “zararlı içerik riskini azaltma” yönünde optimize ederken arama motoru için de SERP’de anlamlı kümeler sunmaktır. Diyelim güven seviyeniz üç değer içeriyor: yüksek, orta, düşük.

Bucket’lama örneği: high_only (yalnız yüksek güven) ve medium_or_high (orta + yüksek). low_only ise çoğu senaryoda “niyeti zayıf” ve “umutili olmayan” bir küme üretir; bu nedenle noindex yapabilirsiniz.

• high_only → index (veya “tek güçlü sayfa” yaklaşımıyla ana allowlist)
• medium_or_high → koşullu index (kullanım sinyali yeterliyse)
• low_only → noindex (genellikle)

Böylece üç ham değer yerine iki indekslenebilir kümeyle daha düşük varyant üretilir; SERP’de birbirini ezmeyen, daha net gruplar ortaya çıkar.

Örnek 3: İki facet birlikte gelince kombinasyon patlamasını önleme (allowlist kombinasyonlar)

Şimdi aktiflik ve güven facet’leri aynı anda seçiliyor: active_bucket + trust_bucket. Eğer aktiflik 4 bucket, güven 3 bucket ise olası kombinasyonlar 12’ye kadar çıkar. Bu noktada kritik olan şey şu: Bu 12 kombinasyonun hepsini indexe açmak zorunda değilsiniz.

Çözüm olarak “allowlist kombinasyonlar” yaklaşımını uygulayın. Yalnızca SERP niyeti güçlü olan ve içerik kalitesi yeterli kombinasyonları indexe açın; geri kalan kombinasyonları noindexleyin.

• İndekse aç: active_bucket_1 (aktif <24s) + trust_high_only
• İndekse aç: active_bucket_2 (aktif 1-7g) + trust_medium_or_high
• Noindex: active_bucket_4 (pasif 30g+) ile low_only kombinasyonları (genellikle düşük niyet + düşük kalite)

Böylece hem index bütçesi korunur hem de benzer sayfalar arası kanibalizasyon riski azalır.

Örnek 4: Güven seviyesi zamana göre değişiyorsa bucket’ı nasıl stabil hale getirirsiniz?

Güven seviyesi dinamik bir skor ise, her taramada bucket içeriği dramatik biçimde değişebilir. Bu durum hem “aynı URL farklı içerik” problemine yaklaşır hem de canonical/noindex kararını zorlaştırır. Stabilite için zaman penceresi yaklaşımı önerilir.

Örnek olarak güven skoru hesaplamasını “günlük batch” (ör. UTC 00:00-23:59) gibi sabit aralıklarda yapın. Bucket’ları gün içinde hesaplanan mikroskor yerine “son 7 gün ortalaması” gibi daha yavaş değişen metriklere dayandırın. Güncelleme sıklığını (ör. günde 1 kez) tutarlı belirlemek, bucket sınırlarının aşırı sık değişmesini engeller.

• Zaman penceresi: trust_bucket’ı “son 7 gün ortalaması” ile üret
• Güncelleme sıklığı: her saat değil, günde 1 kez yeniden hesapla
• Canonical/noindex: allowlist bucket’lar için canonical sabit kalsın; allowlist dışına düşen değerler için noindex uygulanmaya devam etsin

Kontrol checklist’i (Day-1 ve sürekli): index, crawl, log, cache ve şablon doğrulama

Bu modelin başarısı, yayından sonra “tesadüfi” değil “izlenebilir” olmasına bağlıdır. Başlangıçta bucket sayfalarının gerçekten index alıp almadığını, botların doğru HTML’i görüp görmediğini ve cache/CDN davranışının tutarlı olup olmadığını doğrulayın.

Adım adım doğrulama için en az şu kontrolleri uygulayın: (1) index sorgusu ve GSC’de URL inceleme, (2) crawl/log analiziyle botların hangi parametre kombinasyonlarında gezdiğini görmek, (3) render/SSR şablon doğrulamasıyla bucket içeriklerinin doğru bucket kimliğine göre filtrelendiğini kanıtlamak.

1. Day-1 GSC/Index kontrolü: allowlist bucket URL’lerinde “Index: var mı?” ve snippet tutarlılığı var mı inceleyin.
2. Crawl & log analizi: botların noindex bucket kombinasyonlarına ne kadar girdiğini ve crawl waste oluşup oluşmadığını gözleyin.
3. Şablon + render doğrulaması: JS render yerine SSR çıktısında bucket başlığı/filtre metni doğru mu kontrol edin.

Facet URL’leri JS ile render ediliyorsa bot-safe nasıl doğrulanır?

Bot-safe doğrulama, “sayfada görünür” demek değildir. Gerçek doğrulama, render edilen DOM ile botun tükettiği HTML arasındaki farkı olabildiğince azaltmaktır. Bucket sayfalarında aktiflik/güven etiketlerinin tarama anında bot tarafından okunabilir olması gerekir.

Doğrulama adımlarında hem statik HTML çıktısını hem de render sonrası sayfa durumunu test edin. Özellikle facet parametreleriyle üretilen içeriklerin bucket kimliğiyle uyumlu olup olmadığını kontrol edin; aksi halde Google yanlış sınıfa göre değerlendirme yapar ve SERP kalitesi düşer.

Yaygın hatalar

En sık yapılan hata, facet değerlerini bucket’lamadan doğrudan indexe açmaktır. Bu hem aşırı URL üretir hem de farklı facet kombinasyonlarının benzer içerik üretmesine yol açarak kanibalizasyonu tetikler. İkinci sık hata, bucket eşiklerini keyfi seçip sonra “noindex/canonical ile düzeltirim” yaklaşımıdır; çünkü indeksleme davranışı varyantlar arasında zaten dağılmış olur.

Üçüncü yaygın hata, canonical/noindex politikasını allowlist mantığı olmadan uygulamaktır. Canonical’ı rastgele bir ana sayfaya çekmek, yanlış içerik sinyali üretir. Dördüncü hata ise JS render tabanlı facetlerde bot-safe doğrulama yapmadan yayına geçmektir; crawler doğru bucket’ı görmez ve sıralama sinyalleri zayıflar.

Kanibalizasyonu tespit etmek için nasıl kontrol edilir?

Kanibalizasyon tespiti için tek bir göstergeye güvenmeyin. Hem SERP davranışı hem de crawl/index dağılımı birlikte analiz edilmelidir. Aşağıdaki araçlar ve yöntemler genellikle en hızlı sinyali verir.

Önce “site:” sorgularıyla bucket’larınızın birlikte görünüp görünmediğini kontrol edin; ardından GSC’de URL inceleme ile aynı keyword için hangi bucket’ların gösterildiğini karşılaştırın. Son olarak sunucu erişim loglarıyla botların hangi parametre kombinasyonlarında sayfa yüklediğini ve hangi URL’lerin daha sık tarandığını doğrulayın.

• SERP/keyword testi: “aktif son 24 saat” gibi niyetli ifadelerle hangi bucket URL’lerin göründüğüne bakın.
• GSC URL inceleme: impression alan URL’ler arasında benzer içerik üretenleri ayırın.
• Log analizi: noindex bucket’lara gereksiz crawl gidiyor mu, bot waste oluşuyor mu kontrol edin.

Uygulamayı olgunlaştırma ve sürekli iyileştirme

Bucket seti bir kez tasarlanıp bırakılmamalıdır. Chat platformlarında kullanıcı davranışı değişir: sezonluk dalgalanmalar, kampanya dönemleri, moderasyon politikası güncellemeleri gibi etkenler facet dağılımını etkiler. Bu yüzden bucket eşikleri zaman içinde revize edilebilir olmalıdır.

En iyi süreç şu şekilde ilerler: her bucket için aylık kullanım sinyali (filtre kullanım oranı), arama görünürlüğü (impression) ve dönüşüm etkisi izlenir. Stabilite problemi görülürse (ör. güven skorları aşırı dalgalanıyor) zaman penceresi daraltılır/genişletilir; çok zayıf kalan bucket’lar allowlist’ten çıkarılır.

Sık Sorulan Sorular (SSS)

Facet değerlerinin kaç tanesini indexe açmalıyım? Pratik bir üst limit kombinasyon patlamasına göre belirlenir. Örneğin iki facet için toplam indexlenebilir bucket sayısı 6–12 bandında tutulduğunda genellikle kontrol sağlanır. Ancak bu üst limit “allowlist kombinasyon” yaklaşımıyla birlikte düşünülmelidir: her zaman tek boyut sınırı değil, kombinasyon sayısı belirleyicidir.

Güven seviyesi dinamik değişiyorsa canonical/noindex stratejisi nasıl olmalı? Allowlist bucket’lara canonical sabitleyin; allowlist dışına düşen değerleri noindexleyin. Ek olarak bucket içeriğinin “günlük batch” veya “son 7 gün ortalama” ile daha stabil olması, canonical sinyalinin anlamlı kalmasına yardım eder.

Active/pasif gibi zaman bazlı facetlerde ‘kapanan’ değerleri nasıl yönetmeliyim? Kapanan veya değeri hızla geçen bucket’lar için genellikle noindex daha güvenlidir. 410/404 yalnızca URL kalıcı olarak kullanılmayacaksa anlamlıdır; bucket mantığında çoğu zaman URL kalır, içerik güncellenir. Yani “kapanan değer”i URL’nin kendisi değil, bucket’ın içeriği olarak ele almak daha sürdürülebilirdir.

Bucket’lama internal link yapısını nasıl etkiler? İndekse açtığınız bucket’lar kategori/breadcrumb/ilgili linklerde daha fazla görünsün; noindex bucket’lar ise kullanıcıya sunulsa bile internal linking ile güçlenmesin. Bu, crawl bütçesini allowlist lehine optimize eder ve kanibalizasyonu azaltır.

Facet URL’leri JS ile render ediliyorsa bot-safe nasıl doğrulanır? SSR/ön-işleme ile bucket kimliğine bağlı başlık ve sonuç listesinin bot tarafından görülebilir olduğundan emin olun. Render sonrası DOM ile statik HTML arasındaki farkı test edin; gerekiyorsa prerender/SSR uyumunu düzeltin.

Kanibalizasyonu nasıl tespit ederim? “site:” sorguları, GSC URL inceleme ve log analizi birlikte kullanılmalıdır. Özellikle aynı niyetli keyword’lerde birden fazla bucket URL’nin yarışıp yarışmadığını ve Google’ın hangi URL’i tercih ettiğini karşılaştırın.

İçerik derinleştirme için önerilen rehberler

Facet bucket’lama stratejisini sağlamlaştırırken, benzer teknik varyant problemlerinin nasıl ele alındığını anlamak faydalıdır. Özellikle conditional içerik ve render/noindex etkileşimi, bucket kararlarınızın tutarlılığını doğrudan etkiler.

• Kullanıcı Engeli Sonrası Aynı URL’de Koşullu İçerik: Chat Sitelerinde Varyant SEO Uyumlu Tasarım (Canonical/Cache/Noindex Stratejileri)
• Chat Konuşma Arşivinde Private Room Sızıntısını Önleme: Teaser Yerine Yetki Kontrollü Güvenli Meta (noindex + SSR)
• Chat Sitelerinde Autocomplete (Arama Önerileri) İndekslenir mi? URL Üretmeyen Tasarımla SEO Kaybını Önleme Rehberi

Sonuç: Bucket’lama kararını sistemleştirin, indexi büyütün

Chat filtrelerinde facet bucket’lama, “indexe aç/kapat” ikili kararından çok daha fazlasıdır. Doğru tasarlanmış bucket’lar; arama niyetiyle uyumlu kümeler üretir, URL varyantlarını kontrol eder, kanibalizasyonu azaltır ve crawl bütçesini daha verimli kullanmanızı sağlar. Özellikle aktiflik ve güven seviyesi gibi zaman/aksiyon tabanlı metriklerde stabiliteyi hedeflemek (zaman penceresi, güncelleme sıklığı, allowlist kombinasyonlar) fark yaratır.

En iyi yol, bu kararı bir kere verip bırakmak değil; veri toplama, bucket tasarımı, test ve izleme döngüsüyle sürekli iyileştirmektir. Böylece hem teknik SEO hem de ürün/enginierlik ekiplerinin aynı hedefe çalıştığı, ölçülebilir bir sistem kurarsınız.