Chat Sitelerinde Oda (Room Sidebar) Filtreleri Crawl Edilebilir mi? AJAX’siz Crawl-Friendly İç Yapı Tasarımı

Sorun Tanımı: Room Sidebar filtreleri neden crawl edilmeyebilir (DOM-only, event-driven state, sonsuz scroll ile birleşme)

Chat deneyiminde kullanıcılar oda listelerini ve “duvar arası” (room sidebar) filtreleri kullanırken arayüzün çoğu zaman JavaScript ile güncellendiğini görürüz. Bu yaklaşım, kullanıcı için hızlı ve akıcı olabilir; fakat arama motoru botları için “görünse de yok” problemini tetikleyebilir. Çünkü bot, sayfada beklediği filtrelenmiş linkleri ve içerik parçalarını HTML içinde bulamaz.

Özellikle şu fikri zihninizde netleştirin: chat sitelerinde 'duvar arası' (room sidebar) filtreleri crawl edilebilir mi? AJAX yerine crawl-friendly iç yapı. Asıl mesele “AJAX kullanıyor musunuz?” sorusundan daha fazlası. Filtre state’inin URL’ye nasıl yansıtıldığı ve filtrelenmiş sonuçların HTML’de nasıl temsil edildiği belirleyici.

Room sidebar filtreleri (konu, dil, kategori, online kullanıcı, etiket gibi) çoğu üründe tek bir sayfada sunulur. Kullanıcı bir filtreyi seçtiğinde içerik DOM’dan yeniden çizilir; ancak botlar DOM’u çalıştırsa bile çoğu zaman şu sorunun cevabını alamaz: “Bu filtre kombinasyonu hangi URL’de var ve içerik nerede?” Üstelik sonsuz scroll veya “load more” davranışı işin içine girince, crawl edilebilirlik daha da zorlaşır.

Sonuç olarak arama motoru; (1) filtre linkleri yerine düğme/checkbox görür, (2) filtre kombinasyonlarını ayrı sayfalar olarak keşfedemez, (3) indekslenebilir içerik üretmek yerine sadece dinamik isteklerle karşılaşır. Bunun SEO’ya yansıması genellikle oda sayfalarında zayıf kapsam veya dalgalı görünürlük şeklinde olur.

Terminoloji: room, sidebar filter, filter state, filter URL, crawlability vs indexability

Bu yazıda “crawlability” ile “indexability”yi ayrı ayrı ele alacağız. Crawlability, botun bir URL’yi keşfetmesi ve sayfanın HTML içeriğini okuyabilmesidir. Indexability ise keşfedilen sayfanın indekslenmeye uygun olup olmadığını (robots, noindex, canonical, yeterli içerik gibi) ifade eder.

Room: Sohbet odası listesi ya da tekil oda sayfası. Sidebar filter: Oda listesini daraltan dil/konu/etiket/online kullanıcı gibi seçimler. Filter state: Filtrelerin seçili halinin birleşimi (ör. dil=tr, konu=ask). Filter URL: Bu state’in URL’ye karşılık gelen temsilidir (query string veya path formatı). Crawlability vs indexability: Crawl edilemeyen sayfa zaten indekslenemez; ama crawl edilse bile indexlenmeyebilir.

Kritik Tasarım Kararı: Filtrelerin her biri için ayrı SEO sayfası mı, yoksa bileşik/yalnızca seçili filtre kombinasyonları mı?

Önce hedefi netleştirin: SEO açısından hangi “sayfa türleri” üretmek istiyorsunuz? Her filtreyi ayrı sayfaya çevirmek başta mantıklı görünebilir; fakat pratikte sayfa patlamasına (infinite kombinasyon) yol açma ihtimali çok yüksektir. Örneğin dil (10) × konu (50) × etiket (100) = devasa bir uzay demektir.

O yüzden kritik karar şu iki seçenekten birine doğru verilmelidir: ya (A) filtrelerin tamamını değil “stabil ve arama talebi olan” alt kümeyi indexlersiniz ya da (B) bazı bileşik kombinasyonları seçili şekilde indexlersiniz. Çoğu chat ürününde en sağlıklı yaklaşım “seçili kombinasyonları indexlemek”, yüksek değişkenlik ve düşük değerli kombinasyonları ise noindex/robots ile dışarıda bırakmaktır.

Örnekle netleştirelim: “topic” gibi kavramsal alanlar genellikle daha stabil olduğu için indekslenebilir olabilir. Buna karşılık “online=true” gibi anlık değişen filtreler çoğunlukla değersizdir (low-value) ve hızlı değiştiği için noindex yapılmalıdır. Bu politika, hem crawl budget hem de sıralama tutarlılığı açısından doğrudan etkili olur.

Crawl-Friendly Mimari Seçenekleri (karşılaştırmalı)

Aşağıdaki tablo, aynı hedefe (filtrelenmiş oda listelerinin crawl edilmesi) farklı mimarilerle yaklaşan seçenekleri özetler. “AJAX’siz” yaklaşım tek uçtan diğer uca görünse de önemli olan ayrıntı şudur: filtre state’inin URL ve HTML üzerinden temsil edilmesi, ayrıca içerik yükleme davranışının botlar için anlaşılır olmasıdır.

Seçenek	Nasıl Çalışır	SEO Artısı	SEO Riski	Ne Zaman Uygun?
1) SSR ile gerçek HTML üretimi	Her filtre URL’sinde server’dan HTML döner	Bot için doğrudan okunur	Yanıt süresi maliyeti	Indexlenebilir sayfa sayısı kontrollüyse
2) Prerender + URL (hash/state yok)	Önceden/isteğe göre statik üretim; filtre state URL’de	Keşif kolay, hızlı görünür	Frekans/planlama gerekir	Stabil filtre grupları için
3) Progressive enhancement (initial HTML’de linkler)	İlk HTML’de filtre seçenekleri ve filtrelenmiş sonuçlara linkler var	Link keşfi ve fallback	Uygulama disiplin ister	“İlk yükleme SEO” hedefi varsa
4) API/JSON ile veri (HTML’de eşdeğer render)	API çağrısı olur ama HTML eşdeğeri üretilir	Modern geliştirici deneyimi + SEO	HTML eşdeğerliği yapılmazsa başarısız	Ölçeklenebilirlik önemliyse

AJAX’tan Kaçınma Rehberi: Filtre tetiklerinde URL değişimi, history API, linkler ve içerik varlığı

AJAX tek başına kötü değildir. Asıl risk, filtrelerin sadece DOM state’inde kalması ve filtrelenmiş sonuçların URL’ye bağlanmamasıdır. Botun keşfedebilmesi için her “anlamlı filtre state” bir URL karşılığı taşımalıdır.

Pratikte şu ayrımı yapın: “Filtreyi seçtikten sonra gerçekten farklı bir URL’ye gidiyor musunuz?” Eğer hayırsa, ideal olarak kullanıcı deneyimi için olduğu kadar SEO için de erişilebilir bir link yapısına dönmeniz gerekir. Event-driven state (ör. sadece butona tıklayıp listeyi yeniden çizmek) yerine seçimi URL’ye bağlayın ve sonuç sayfasını aynı URL’de üretin.

History API kullanabilirsiniz (SPA konforu için), ama asıl hedef değişmez: filtre seçiminde URL güncellenmeli ve botun göreceği içerik yine HTML içinde mevcut olmalıdır. Bunu en sorunsuz şekilde SSR/prerender ile garanti etmek genelde en güvenli yoldur.

URL/Query Param Stratejisi: Filtre parametrelerini anlamlı URL’ye çevirme, canonical ve param normalizasyonu

Filtre state’ini URL’ye taşımak hem keşfi kolaylaştırır hem de canonical mantığını sadeleştirir. İki yaygın model var: query string ve path (slug) tabanlı URL’ler.

Örnek filtre->URL eşlemesi:

• /rooms?language=tr&topic=ask
• /rooms/tr/ask

Query string modelinde parametrenin sırası, büyük-küçük harf ve boş değer gibi detayların normalize edilmesi gerekir. Örneğin topic=ASK ile topic=ask aynı kabul edilmeli; boş veya default değerler URL’den çıkarılmalıdır. Path modelinde de “/rooms/tr/ask/” gibi trailing slash ve encoding farkları normalize edilmelidir.

Canonical belirlerken şu mantığı kural haline getirin: Aynı içerik farklı filtre kombinasyonları gibi görünüyorsa veya aynı filtre kombinasyonu farklı param biçimleriyle tekrar ediyorsa, tek bir “ana” URL’yi canonical’a bağlayın. Böylece indeks karmaşası azalır.

Örnek canonical set: Aynı oda listesi şu iki URL’de aynı içerikle açılıyorsa, ör. /rooms?language=tr&topic=ask ile /rooms?topic=ask&language=tr&online=false. İkisi de aynı sonuç döndürüyorsa canonical’ı tek bir forma sabitleyin. online=false gibi default parametreleri canonical seçiminden dışarıda bırakmak çoğu zaman daha sağlıklıdır.

Robots/Index Kontrolleri: Hangi filtre kombinasyonları indexlenmeli? noindex/robots/low-value içeriği azaltma

Her filtre kombinasyonunu indexlemek çoğu chat sitesinde sürdürülemez. Bu noktada bir “indexleme matrisi” oluşturmanız gerekir. Bu matris, filtre değerlerinin stabilitesine ve arama talebinin potansiyeline göre karar verir.

Örnek indeksleme kuralı: 'online=true' gibi dinamik/gerçek zamanlı filtreleri noindex yapın; “topic” gibi daha stabil filtreleri indexleyin. Ayrıca “etiket” gibi çok spesifik alanlarda, düşük sayıda oda döndüren kombinasyonları noindex yapmak crawl budget’ı korur.

Burada robots.txt ile “sayfayı kapatma” ile meta robots/noindex arasında ayrım var: robots.txt, botun keşfetmeyi tamamen durdurmasını sağlar; meta noindex ise keşif sonrası indekslemeyi engeller. Pratikte: keşif amaçlı bağlantılarınız varsa ama indekslememek istiyorsanız meta noindex daha kontrollüdür. Tamamen gereksiz endpoint’leri robots.txt ile engellemek ise crawl maliyetini daha fazla azaltabilir.

Crawl Budget Yönetimi: Sayfa patlamasını önlemek için filtre kombinasyon limitleri, sıralama politikası

Crawl budget, botun sınırlı kaynaklarla sitenizi ne kadar keşfedeceğini anlatır. Filtre kombinasyonları kontrolsüzse botlar çok sayıda düşük değerli sayfaya dağılıp önemli sayfaları geç tarayabilir.

Bu yüzden “index policy” ile “discover policy” birlikte tasarlanmalıdır. Örneğin hangi filtre sayfalarının sitemap’a gireceği, hangi kombinasyonların iç linklerle dağıtılacağı ve hangi değerlerin rel=canonical ile tekleştirileceği planlanır.

Somut limit yaklaşımı: aynı anda birden fazla etiket ile daraltılan kombinasyonları indexlemeyin. Ya da sadece en popüler N etiket + stabil topic kombinasyonlarını indexleyin. Sonuç sayısı çok düşükse (ör. 0–2 oda), noindex/no-follow yaklaşımıyla düşük değerli sayfaları dışarıda bırakmak mantıklıdır.

Sonsuz Scroll ile Birlikte Çalışma: Filtre sonuçlarında ilk sayfa için indexlenebilir içerik; devam yüklemeyi crawl için sınırlama

Sonsuz scroll kullanan chat listelerinde “ilk yükleme” kritik bir SEO penceresidir. Botun çoğu zaman erişebileceği ve değerlendireceği içerik, sayfanın ilk HTML’sinde bulunan içeriktir. Bu yüzden filtre sonuçlarında ilk sayfayı (ilk 20-50 oda gibi) indexlenebilir kılın.

Devam yükleme (next page / infinite) için ise iki kural koyun: (1) indexlenmeyecekse parametreli “sayfa derinliği” URL’leri noindex yapılmalı, (2) indexlenecekse sayfalama benzeri bir modelle (p=2, cursor ile ama URL’de) sınırlı sayıda sayfayı keşfe açmalısınız.

Bu konuda sonsuz scroll ve görünürlük uyumuna dair ilgili çerçeveleri ayrıca incelemek istersiniz: sonsuz scroll ve sayfalama SEO en iyi uygulamaları.

Pratik Uygulama Planı: MVP (ilk 2-3 kritik filtre), ölçümleme metrikleri, iterasyon

Ürün geliştirmede en büyük tuzak “hepsini aynı anda SEO’ya açmak” olur. Bu işi MVP ile başlatın: trafik getirme potansiyeli yüksek olan 2-3 kritik filtreyi seçin. Örneğin topic (konu) ve language (dil) çoğu chat ürününde stabil arama intent’ine sahiptir.

Plan şöyle ilerleyebilir:

1. URL & HTML: /rooms?language=tr&topic=ask gibi adreslere SSR/prerender ile HTML’de sonuç döndürün.
2. İç link: Sidebar filtre seçimlerini, seçili state’e göre sonuç linklerine dönüştürün (a etiketleriyle).
3. İndeks policy: online=true gibi dinamik filtreleri noindex yapın; topic/language sayfalarını indexleyin.
4. Ölçümleme: Search Console’da keşif/indeksleme raporları, sayfa başına organik trafik ve crawl frekansı ile iterasyon yapın.

MVP bitince üçüncü aşamada etiketleri ve kategori gibi diğer boyutları “seçili kombinasyonlar” yaklaşımıyla ekleyin. Her eklenen filtre boyutu için crawl bütçenizi ve index/noindex politikanızı yeniden dengeleyin.

Filtre state değişimi: DOM-only vs erişilebilir link/tab tabanlı filtre farkı

En yaygın yanlış anlama şudur: “Sayfayı tarayıcıda ben görüyorum, bot da görür.” Halbuki botun erişimi, DOM’unuzu sonradan çizmenizden ziyade URL keşfi ve ilk HTML içeriğine bağlıdır.

DOM-only senaryoda filtreyi sadece JS ile değiştirirsiniz: kullanıcı language=tr seçince listeyi yeniden çizer, URL değişmez. Bu durumda farklı filtre kombinasyonlarının ayrı URL’si olmadığı için botun keşfi zayıflar; arama motoru da seçenekleri anlamlandırmakta zorlanır.

Karşı örnek: Filtre seçeneklerini ve seçili filtreli sonuç listesini gerçek linkler olarak kurarsınız. Kullanıcı tıklayınca URL değişir (?language=tr&topic=ask gibi), ilk HTML’de de sonuçlar bulunur. Böylece “crawling” sadece teknik tarama olmaktan çıkar; gerçek sayfa keşfine dönüşür.

Canonical ve parametre normalizasyonu room filtrelerinde nasıl uygulanır?

Chat oda filtrelerinde canonical konusu sadece “tekrar eden içerik” meselesi değildir. Aynı içerik farklı URL’lerle açıldığında ortaya çıkan tutarlılık problemine dönüşür. Room sayfalarında genellikle şu tekrarlar görülür: parametre sırası farklı gelir, default parametreler URL’de kalır, hash veya session benzeri değerler taşınır.

Bu riskleri azaltmak için canonical oluştururken yalnızca “ne zaman” değil “ne biçimde” kanonik URL verdiğinizi standardize edin. Örneğin online=true varsayılan ise URL’den kaldırın; parametre sırasını sabitleyin; boş değerleri encode ederken tutarlı bir kural uygulayın.

Parametre normalizasyonu için pratik referans: room filtrelerinde canonical otomatik üretim hataları gibi örnekler, oturum/hash kaynaklı dağılmayı azaltmanıza yardımcı olur.

Sonsuz Scroll + AJAX görünürlüğü: prerender/SSR ile arama motoru uyumu

Sonsuz scroll ve AJAX, yanlış tasarlandığında crawl edilebilirliği “tek sayfalık görünürlük”te kilitler. Ama doğru kurulduğunda AJAX sadece etkileşim konforu sağlar; HTML’deki eşdeğer içerik ve URL temsilcisi SEO’yu taşır.

İlk yüklemede HTML içinde “filtrelenmiş ilk sonuçlar” olmalı ve bu sonuçların bulunduğu URL crawl edilebilir olmalıdır. Devam yükleme ise ya sayfa derinliği için noindex olur ya da sınırlı ve kontrollü şekilde paginated/URL tabanlı keşfe açılır.

Bu doğrultuda şu rehber çerçevesini de inceleyebilirsiniz: sonsuz scroll’da AJAX görünürlüğü ve prerender/SSR uyumu.

Yaygın hatalar

Room sidebar filtrelerinde ekiplerin en sık düştüğü hatalar, teknik SEO kararlarını ürün deneyiminden koparmaktır. Filtreler tamamen JS’e gömülünce, gerçekte “keşif” değil “görsel demo” optimize edilmiş olur.

• URL değişmiyor, sadece DOM değişiyor: Bot farklı filtre kombinasyonlarını ayrı sayfalar olarak keşfedemez.
• Her kombinasyonu indexlemek: Sayfa patlaması crawl bütçeyi yer, index kaliteyi düşürür; ardından sıralama dalgalanır.
• Dinamik filtreleri indexlemek (online sayısı gibi): Sayfalar hızlı değiştiği için düşük değer, tekrar ve indeks verimsizliği oluşturur.
• Canonical’ı tekleştirmemek: Parametre sırası/boş değerler farklı URL’ler yaratır; canonical savaşına giren sayfalar oluşur.

Nasıl kontrol edilir? Adım adım doğrulama adımları

Uygulamanın gerçekten çalıştığını kanıtlamak için sadece “benim sayfada açılıyor” demek yetmez. Aşağıdaki doğrulama adımlarını tek tek deneyin ve kayıt altına alın:

1. URL & HTML doğrulaması: Bir filtre seçtiğinizde URL değişiyor mu? Değişiyorsa ilgili URL’yi sayfa kaynağında (view-source veya HTML çıktısı) sonuç kartlarıyla birlikte görüyor musunuz?
2. Keşif doğrulaması: Sidebar filtre seçenekleri <a href="..."> olarak mı sunuluyor? Botun linkleri keşfedebilmesi için iç link mantığı var mı?
3. Index kontrolü: Google Search Console’da ilgili filtre URL’sini test edin; sayfa keşfediliyor mu, “noindex” mi, canonical ile başka URL mi gösteriliyor?
4. Noindex politika doğrulaması: online=true gibi dinamik filtrelerde meta robots/noindex doğru mu ve sitemap’a giriyor mu?
5. Crawl bütçe sinyalleri: Birkaç gün sonra crawl sıklığı ve sayfa sayısı raporlarında patlama var mı? Değerli filtre URL’leri daha geç taranıyor mu?

Kontrol Listesi: Devreye almadan önce teknik doğrulamalar

Geliştirme tamamlandıktan sonra şu kontrol listesini kullanın. Bu liste yalnızca mimariyi değil; SEO politikasını ve dağıtım aşamasını da kapsar.

• Filtre state, URL’de temsil ediliyor (query/path) ve parametreler normalize ediliyor.
• Filtrelenmiş ilk sonuçlar indexlenebilir HTML olarak render ediliyor (SSR/prerender/progressive enhancement).
• Filtre seçenekleri keşfedilebilir linkler (a etiketleri) içeriyor; DOM-only butonlar kritik akışta kalmıyor.
• Index/noindex matrisi mevcut: dinamik filtreler noindex, stabil filtreler index.
• Canonical mantığı net: aynı içerik farklı kombinasyonlarda tekrar ediyorsa tek bir canonical belirleniyor.
• Sonsuz scroll sonrası yüklemeler sınırlı ve indexlenebilir derinlik kontrol altında.
• Sitemap yalnızca indexlenecek filtre URL’lerini içeriyor; low-value kombinasyonlar dışarıda.
• Search Console ve log verisiyle keşif/indeksleme davranışı ölçümleniyor.

SSS

Room sidebar filtrelerini crawl edilebilir yapmak için mutlaka SSR mi gerekir?

Mutlaka SSR şart değil; ancak crawl edilebilirlik için HTML’de eşdeğer içerik sağlamak gerekir. Prerender veya progressive enhancement ile ilk HTML’de filtrelenmiş sonuçları sunuyorsanız SSR benzeri etki yakalayabilirsiniz. En kritik koşul: filtre state’in URL’de temsil edilmesi ve botun görebileceği gerçek içerik üretmenizdir.

AJAX kullanacaksak bile search botlarının görebilmesi için minimum şartlar nelerdir?

En azından şunlar olmalı: filtre değişiminde URL güncellenmeli, filtrelenmiş sonuçlar ilk HTML’de veya botun çalıştırabildiği bir şekilde görülebilir olmalı ve filtre seçenekleri link olarak keşfe açık olmalıdır. Sadece DOM-only yeniden çizim, crawlability’yi zayıflatır.

Filtre kombinasyonlarının hepsini indexlemek doğru mu?

Çoğu durumda hayır. Sayfa patlaması crawl bütçeyi boşa harcar ve indeks kalitesini düşürür. Stabil ve arama intent’i olan kombinasyonları indexleyip; düşük değerli veya çok dinamik kombinasyonları noindex yapmanız genellikle daha doğru bir stratejidir.

Dinamik/gerçek zamanlı (online sayısı) filtreler noindex mi olmalı?

Çoğu zaman evet. “online=true” gibi değerler hızlı değiştiği için low-value içerik üretir. İsterseniz bu tür sayfaları noindex yaparak indeks verimsizliğini azaltın; filtre UI ise kullanıcı deneyimi için açık kalabilir.

Sonsuz scroll varken ilk sayfayı nasıl indexlenebilir hale getiririm?

İlk yüklemede HTML içinde filtrelenmiş ilk sonuç kümesini gösterin. Sonraki sayfa derinliğini ise ya noindex yapın ya da kontrollü paginasyon/URL stratejisiyle sınırlı sayfalara dönüştürün. Böylece bot değerlendirmesi için “tamamı erişilebilir” bir minimum içerik sağlanır.

Googlebot’un JavaScript çalıştırmasını beklemek yeterli mi?

Sadece “çalıştırırsa görür” varsayımı risklidir. Çünkü botun davranışı, sayfa karmaşıklığı ve render maliyeti crawl/indeksleme verimini doğrudan etkileyebilir. Bu yüzden en güvenlisi, indexlenebilir içerikleri ilk HTML’de sunmaktır.

Canonical ve parametre normalizasyonu room filtrelerinde nasıl uygulanır?

Canonical’ı tek bir formata sabitleyin: parametreleri normalize edin, default/boş değerleri URL’den çıkarın ve parametre sırası farklılıklarını tekleştirin. Aynı içeriği temsil eden birden fazla URL varsa canonical doğru “ana URL”ye işaret etmelidir.

Crawl budgetı aşmamak için filtre sayfasında hangi limitler olmalı?

Önce indexlenebilir kombinasyon sayısını sınırlayın (ör. stabil filtrelerde bile sadece en değerli alt kümeler). Ardından sonuç sayısı çok düşük veya yüksek varyanslı sayfaları noindex yapın. Sonsuz scroll sonrası derinliği de kontrol ederek yalnızca ilk sayfa veya sınırlı paginasyonu keşfe açık tutun.

Örnek senaryolar (somut farkları görselleştirme)

Senaryo 1: “DOM-only” filtre. Kullanıcı dil filtreyi seçiyor, URL hiç değişmiyor ve içerik sadece JS ile güncelleniyor. Bu durumda bot yeni filtre kombinasyonlarını ayrı URL’ler olarak keşfedemez; sitemap’a da yeni sayfa ekleyemezsiniz. Sonuç: filtre sayfaları görünmez kalabilir.

Senaryo 2: “URL & HTML eşdeğer”. Kullanıcı language=tr ve topic=ask seçince URL değişiyor: /rooms?language=tr&topic=ask. Aynı URL’nin HTML çıktısında ilk sonuç kartları ve filtrelenmiş liste bulunuyor. Bu model, hem crawlability’yi artırır hem de indexlenebilir sayfa üretmenizi sağlar.

Sonuç: Room sidebar filtrelerinde SEO başarısı URL + HTML disipliniyle gelir

Room sidebar filtrelerini crawl edilebilir kılmak için tek hedefiniz “AJAX yerine SSR” olmak zorunda değil; hedefiniz filtre state’ini anlaşılır ve indekslenebilir bir web kaynağına dönüştürmek olmalı. Bunun için filtre state’in URL’de temsil edilmesi, HTML’de eşdeğer içeriğin render edilmesi ve indeks/noindex politikasının dinamik filtreleri dışarıda tutacak şekilde tasarlanması gerekir.

Doğru mimari kurulduğunda, sonsuz scroll/AJAX gerçekliği ürün deneyimini iyileştirirken SEO tarafında görünürlük düşmez. MVP ile başlayın, stabil filtreleri indexleyin, sayfa patlamasını kontrol edin ve her iterasyonda ölçerek ilerleyin.