Chat Sitelerinde Poll/Oylama Mesajları İndekslensin mi? İnce İçerik Riski ve Kazanan Sonuçların Canonical Yönetimi

Chat sitelerinde kullanıcıların “oylama/poll” paylaşımları çoğu zaman kısa, hızlı değişen ve bağlama bağlı UGC (user generated content) parçalarıdır. Bu yüzden SEO ekibi için en kritik soru şudur: Chat sitesinde ‘oylama/poll’ mesajları indekslenir mi? İnce içerik ve kazanan sonuçların kanonik yönetimi doğru şekilde nasıl kurgulanmalıdır? Yanlış bir karar, hem indeks israfına hem de “winner/summary” gibi agregasyon sayfalarının doğru sinyali alamamasına yol açabilir.

Öte yandan doğru politika uygulandığında poll’lar; gerçekten arama niyeti karşılayan, kapanınca kazanan sonucu görünür kılan ve thread bağlamıyla anlam kazanan URL’lere dönüşebilir. Bu yazıda, poll mesajlarının indekslenip indekslenmeyeceğinden başlayarak kazanan sonuçların canonical/robots/parametre stratejisine kadar uygulanabilir bir karar matrisi ve kontrol planı sunacağım.

Sorun tanımı: Poll mesajları neden ince içerik sayılır, kazanan sonuçlar neden ayrı sayfa doğurur?

Poll mesajları çoğunlukla tek bir cümle veya kısa bir soru + birkaç seçenekten oluşur. Kullanıcı etkileşimi (oy verme, yorum yazma, sonuçların oluşması) sonradan gelir; ancak crawl bot’ları çoğu zaman ilk etapta “yetersiz içerik” durumunu yakalayabilir. Üstelik poll’lar sık kapanır, hızlı değişir ve tekrar eden UI varyantları (aktif/kapanmış, gizli/modere edilmiş) nedeniyle “aynı şeyin farklı URL’lerle çoğalması” pratikte kaçınılmaz olur.

İşte bu noktada “kazanan sonuç” (winner) veya “sonuç özeti” (summary) sayfaları devreye girer. Poll kapandığında oy dağılımı ve kazanan seçenek netleşir; yani tek bir poll mesajından daha “kullanışlı” bir bilgi birimi ortaya çıkar. Arama motoru açısından winner/summary sayfası çoğu zaman poll ana mesajından daha değerli ve aranmaya daha yatkın hale gelebilir. Fakat bu değer, canonical doğru yönetilmezse poll ana sayfası, sonuç sayfası ve thread sayfası arasında sinyal parçalanmasına dönüşür.

Kapsam ve kavramlar: poll mesajı vs tartışma/thread vs sonuç/kazanan sayfası

İlk iş, veri modelinizi netleştirmek. Poll mesajı ile poll tartışması aynı şey değil. Poll mesajı genellikle tek bir event’tir: seçenekleri listeler ve kullanıcı oylarını alır. Poll tartışması ise thread içinde yorumlar/cevaplar üzerinden şekillenen UGC konuşmasıdır. Bazı sitelerde poll ana mesajı + thread içindeki yorumlar birlikte render edilir; bazılarında ise yorum sayfaları ayrı URL’lere bölünür.

Kazanan sonuç sayfası (winner/summary) ise poll kapanmasıyla üretilen “aggregate” bir çıktı sayfasıdır. Bu sayfalar genellikle oy sayıları, yüzdeler, zaman damgası ve çoğu zaman “sonuç sayfası parametreleri” (tarih aralığı, oda/kanal filtresi) gibi ek içeriklerle görünür. Bu yüzden karar mekanizması yalnızca “noindex mi index mi?” sorusunu değil, hangi sayfanın canonical olacağı sorusunu da kapsamalıdır.

Karar matrisi: Aktif poll / kapanmış poll / silinmiş-gizlenmiş poll / moderasyonlu poll

Poll’lar için en sağlıklı yaklaşım “durum tabanlı” bir politika kurmaktır. Aktifken ince içerik riski daha yüksektir; kapanınca değer artar. Moderasyon ve gizleme ise botların eriştiği içerik ile kullanıcıların gördüğü içerik arasında tutarsızlık yaratır. Bu tutarsızlık, yanlış indexleme veya yanlış canonical’a yol açabilir.

Aşağıdaki tablo, pratikte kullanılan Index/Noindex/Canonical/Robots seçeneklerini durum bazında özetler. Asıl hedef, crawl budget’ı israf etmeden yalnızca değerli URL’leri indekslemektir.

Durum	Hedef URL türü	Index/Noindex	Canonical önerisi	Robots önerisi
Aktif poll	/poll/123 (poll mesajı)	Noindex (çoğu durumda)	Thread/poll ana içerik URL’si (örn. /poll/123 veya /thread/…)	allow: index sinyali baskılanır; gerekirse noindex + follow
Kapanmış poll	/poll/123/winner ve/veya /poll/123/results	Index (değer yeterliyse)	Kazanan sayfa kendi canonical’ı veya /poll/123/results	allow; iç linklerle canonical’ı destekle
Silinmiş/gizlenmiş (soft-delete)	/poll/123	Noindex + 404/410 stratejisi	İlgili güncel ana URL yoksa boş	robots: noindex sayfayı taramayla boğuşmayın
Moderasyon sonrası gizli	/poll/123	Noindex	Thread ana sayfa veya “moderasyonlu görünüm” URL’si	allow=false veya noindex, canonical’ı ana içeriğe taşı

İnce içerik yönetimi: minimum içerik eşiği (threshold), oy sayısı bantları ve UI varyantları

Poll’larda “ince içerik” riskini yalnızca kelime sayısıyla değil, etkileşim sinyalinin oluşmasıyla birlikte ele almalısınız. Basit bir poll metni çoğu zaman tek başına arama motoru için zayıf bir sinyal olur. Bu yüzden threshold yaklaşımı, “oy sayısı/cevap sayısı” ile entegre edilmelidir.

Önerilen pratik politika: Poll kapanmadan önce noindex davranışı varsayılan olmalı; kapanınca veya oy/cevap eşiği geçince index açılmalıdır. Buradaki kritik nokta, “UI durumunu” da ayırmaktır. Aynı poll farklı UI’lar altında farklı içerik döndürebilir: aktif, aktif ama anonim, aktif ama gizli, kapanmış ama sonuç yüklenmiyor (JS gecikmeli), sonuç sayfası var ama oy dağılımı boş gibi.

• Threshold (örnek başlangıç): Kapanmış poll için toplam oy ≥ X ve/veya yorum/cevap ≥ Y olduğunda index açın.
• Oy bantları: 0–5 oy: noindex; 6–30 oy: çoğu sitede noindex ya da düşük öncelik; 31+ oy: index (değer artıyorsa).
• Variant ayrımı: “Kazanan seçeneği belirlemek mümkün olmayan” (beraberlik/eksik veri/JS ile geç yüklenen) durumlarda index açmayın.

Kazanan sonuçların canonical stratejisi: winner sayfası, sonuç özeti ve tam thread arasındaki kurallar

Kazanan sonuç sayfaları (winner/summary) poll ana mesajından daha spesifik bir bilgi sunar. Ancak canonical seçimini “kimin daha değerli olduğu” kadar “kimin daha kararlı olduğu” belirler. Canonical için temel kural şudur: Aynı bilgiyi farklı URL’lerde tekrarlayan varyantlar varsa, tek bir canonical belirleyin; diğerlerini noindex veya canonical ile sinyalsiz bırakın.

Uygulama örneği olarak şöyle düşünün: /poll/123/winner sayfası yalnızca kazananı ve oy dağılımı grafiğini sunuyorsa canonical’ı yine /poll/123/winner yapabilirsiniz. Eğer siteniz /poll/123/results altında daha zengin bir “sonuç özeti” tutuyorsa canonical’ı /poll/123/results’a taşımak daha tutarlı olur. Tam thread (yorumların olduğu uzun sayfa) ise canonical hedef olmamalıdır; çünkü kazanan sonuç arayan kullanıcıların niyeti farklıdır ve thread içinde ince içerik parçalanması artabilir.

Linkleme ve iç mimari: poll seçenekleri için ayrı URL mi, tek URL içinde varyant mı?

İç mimari kararınız canonical’ı fiilen destekler ya da bozar. Eğer poll seçeneklerini (A/B seçenekleri) ayrı sayfalara bölüyorsanız (/poll/123/option/1 gibi), her seçenek sayfası ince içerik riski taşır. Böyle bir model varsa seçenek URL’lerini çoğunlukla noindex tutmanız, canonical’ı /poll/123/results veya /poll/123/winner’a bağlamanız gerekir.

Alternatif olarak tek bir poll URL’si içinde varyantları parametre veya state olarak gösterebilirsiniz (örn. aktif/kapanmış). Bu yaklaşım URL sayısını azaltır; fakat canonical ve robots yönetimini düzgün kurmazsanız yine de index israfı oluşabilir. Pratikte, seçenekleri ayrı URL yapmadan ilerleyin; kazanan/sonuç çıktısını ise yalnızca kapanınca üreten bir “çıktı URL seti” kurgulayın.

İç link stratejisi de önemlidir: kullanıcı site içinde “sonuç”a tıkladığında, arama motorunun canonical hedefle aynı sayfayı izlemesini sağlayın. Bu yüzden header menüden değil, doğrudan winner/results linkleriyle canonical hedef URL’ye yönlendirme yapın.

Parametre ve filtreler: zaman penceresi, kategoriler/tagler, oda/kanal bağlamı ve index israfı

Poll sonuçlarını filtrelemek caziptir: “son 24 saat”, “son 7 gün”, belirli kategori/tag, oda/kanal bağlamı gibi. Ancak parametreli varyantlar sınırsız şekilde çoğalabilir. Googlebot her parametre kombinasyonunda farklı içerik bulacağını varsayabilir; bu da crawl budget’ın boşa harcanmasına ve “ince varyantların” indekslenmesine yol açar.

Bu yüzden parametre stratejisini şu mantıkla kurun: yalnızca gerçekten ayrı arama niyeti karşılayan filtreleri indexe açın; geri kalanı noindex veya canonical’ı ana sayfaya bağlayın. Örneğin “son 24 saat” çoğu durumda hızlı değişir ve thin slice davranışı gösterebilir; indexe açmak yerine JS/SSR ile kullanıcıya anlık filtre uygulatın, indeks için canonical’ı “genel sonuçlar”a taşıyın.

Noindex + canonical kombinasyonları: ne zaman doğru, ne zaman yanlış?

Noindex + canonical birlikte kullanıldığında sonuçlar netleşir: noindex sayfanın indekslenmesini engeller; canonical ise sinyalin nereye aktarılacağını bildirir. Bu kombinasyon genellikle şu amaçla doğru olur: “Bu URL crawl edilebilir ama indekslenmesin; sinyalin asıl değerli URL’ye aktarılması sağlansın.”

Yanlış kullanım ise şöyledir: noindex verdiğiniz sayfada canonical olarak başka bir noindex sayfayı hedeflerseniz, sinyal düşebilir veya yanlış toplanabilir. Bir başka yanlış senaryo da şudur: “Aktif poll” noindex iken canonical’ı “winner/results” yapmamak. Bu durumda arama motoru aktif poll sayfalarını yakalayıp değerli winner sayfalara konsolide etmeden indeks sinyalini dağıtır. Doğru senaryoda canonical’ı, kullanıcının arama niyetiyle uyumlu nihai hedefe bağlarsınız.

JavaScript/SSR/CSR etkileri: poll sonuçlarının Google tarafından anlaşılması

Poll sonuçlarının bir kısmı JS ile render ediliyorsa (ör. oy yüzdeleri, kazananın belirlenmesi, özet tablolar), Googlebot sayfayı ilk yüklemede “boş/eksik” görürse indexe uygun sinyal oluşmayabilir. Bu durum özellikle winner/summary sayfalarında kritik hale gelir.

Çözüm olarak SSR (server-side rendering) veya önbellek/edge rendering düşünün. En azından sonuç sayfasında “kazanan seçenek metni”, “toplam oy” ve “oy yüzdeleri/dağılım özeti” HTML içinde görünür olmalıdır. Aksi halde indeksleme açılsa bile Google sayfayı ince içerik olarak değerlendirebilir ya da snippet kalitesi düşebilir.

Ölçüm planı: Search Console sorguları, indeks sayıları, crawl istatistikleri ve ince içerik sinyali izleme

Bu iş “kurala göre yap, ölç” döngüsü gerektirir. Önce hangi URL tiplerinin arttığını ve hangi durumda indekslendiğini takip edin. Search Console’da “URL denetimi” ile örnek poll/winner URL’leri kontrol edilirken, “Dizin / URL durumu” raporları üzerinden noindex/canonical etkisini görünür kılabilirsiniz.

Ek olarak crawl verilerini (server log veya platform crawl istatistikleri) izleyin: aktif poll URL’lerinde aşırı tarama varsa, index israfı ve crawl bütçesi kaybı yaşıyor olabilirsiniz. İnce içerik sinyali için de şu metrikler faydalıdır: düşük etkileşimli poll yüzdesi, indekslenen ama kullanıcı etkileşimi zayıf URL oranı, winner/results sayfasına geçirilen canonical oranı ve indeksleme sonrası organik tıklama davranışı.

Uygulama kontrol listesi (doğrulama adımları): robots.txt, meta robots, canonical, sitemap, internal links, 404/410

Bu bölüm “nasıl kontrol edilir / adım adım doğrulama” formatında bir kontrol listesi sunar. Amaç, politika tasarımını canlıya almadan önce sistematik biçimde doğrulamaktır.

1. Robots + meta robots doğrulaması: Aktif poll için noindex/meta robots etkisi var mı; winner/results için index izinli mi kontrol edin.
2. Canonical doğrulaması: Aktif poll sayfasında canonical, beklenen “nihai değerli URL” mi gösteriyor; winner/summary sayfasında canonical kendi kendisi mi (veya tek hedef mi) kontrol edin.
3. Sitemap ve keşif kontrolü: Sadece indexlenmesi istenen URL tiplerini sitemap’a ekleyin. Parametre/facet sayfaları sitemap’a girmesin.
4. Internal link doğrulaması: Kullanıcı “sonuç”a tıkladığında internal linkler canonical hedef URL’ye mi gidiyor kontrol edin.
5. Silinmiş/gizli poll davranışı: Soft delete olanlarda 404/410 ve noindex birlikte doğru mu; redirect (301/302) riskleri var mı log ile doğrulayın.
6. Render doğrulaması (JS): Winner sayfasının kritik metinleri HTML’de görünüyor mu; Googlebot ile erişimde boş içerik kalıyor mu kontrol edin.

İsterseniz parent-child (thread) URL yapısında canonical tutarlılığını şu rehberden de kontrol edebilirsiniz: Chat’te Parent-Child (Thread) URL Yapısını SEO’da Kanonik Hale Getirme Rehberi: Yorum/Cevap Sayfaları.

Örnek senaryolar (5 adet)

Aşağıdaki senaryolar, brief’te istenen örneklerle birebir politika mantığını somutlar.

Örnek 1: Aktif poll URL’si /poll/123 (index değil, canonical olarak thread/poll ana sayfası) senaryosu. Burada hedef, aktif poll’un “ince içerik” sinyalini indekslemeye taşımamak; canonical ile sinyali thread/poll ana içeriğe konsolide etmektir. Aktifken oy sayısı düşükse noindex + canonical yeterlidir; fakat canonical hedefin de indexlenecek bir sayfa olduğundan emin olun.

Örnek 2: Kapanmış poll ve winner özet sayfası /poll/123/winner (canonical: /poll/123 veya /poll/123/results; açıklama ve gerekçe). Eğer results sayfanız daha zengin oy dağılımı içeriyorsa canonical’ı /poll/123/results yapın ve /poll/123/winner için noindex veya index + tutarlı canonical tercih edin. Ama ikisini de farklı canonical’lara bağlamak sinyal bölünmesi üretir.

Örnek 3: Sonuçların oy sayısı eşiğini geçtikten sonra (threshold) index’e açma stratejisi. Örneğin kapanma sonrası toplam oy ≥ 31 olduğunda winner/results index açılır; 0–30 bandında noindex kalır. Böylece “çok az etkileşimli yüzlerce poll” indekslenmez. Eşiğe ulaşıldığında canonical’ı ve internal linkleri güncellemeyi unutmayın.

Örnek 4: Moderasyon sonrası gizlenen poll (noindex, canonical’ı ana thread’e taşıma) senaryosu. Moderasyon sebebiyle poll seçenekleri veya oy sayıları görünmüyorsa, /poll/123 noindex olmalı ve canonical ana thread’e (veya moderasyonlu içerik URL’sine) bağlanmalıdır. Aksi halde Googlebot “eksik içerik” ile sayfayı indekslemeye çalışabilir.

Örnek 5: Aynı poll’un birden fazla bağlamda göründüğü durum (oda/kanal ve kategoriye göre URL varyantları) için canonical birleşik strateji. Örneğin /c/oda-a/poll/123 ve /kategori-x/poll/123 gibi varyantlar üretiyorsanız hepsinin canonical’ı tek bir “master” URL’ye taşıyın (çoğu zaman /poll/123/results). Böylece bağlam sayfaları indexlenmesin; değerli sinyal birleşsin.

Yaygın hatalar (beklenen hatalar)

Hata 1: Aktif poll’ları otomatik olarak indexlemek. Botlar kısa içeriklerle dolu yüzlerce aktif poll keşfeder; crawl bütçesi “zayıf değerli URL”lere akar ve kapanmış winner/results sayfaları daha geç keşfedilir.

Hata 2: Winner sayfası indexliyken canonical’ı poll ana sayfasına ters yönde bağlamak. Örneğin /poll/123/winner index ama canonical /poll/123’e diyorsanız, Google winner’in sinyalini “ikinci planda” görebilir. Canonical yönü, nihai hedef arama niyetiyle uyumlu olmalı.

Hata 3: Parametreli tarih filtresi URL’lerini sitemap’a eklemek veya her varyantı indexe açmak. Sonuçlar hızla değiştiği için “thin slice + churn” oluşur; indeks israfı artar. Bu konuda parametre/facet risklerine benzer bir çerçeveyi diğer indeks israfı yazılarında da görebilirsiniz (ör. arama terimi sayfaları, offset üretimler).

Nasıl kontrol edilir? (Adım adım doğrulama senaryosu)

Canlıya almadan önce küçük bir örnek havuzla test edin. Ardından kararınızı veriyle revize edin. Aşağıdaki adımlar “adım adım doğrulama” yaklaşımıyla uygulanabilir bir test planıdır.

1. Test havuzu seçin: Oy sayısı düşük, orta, yüksek olan 30 aktif poll ve bunların kapanma sonrası winner/results karşılıklarını belirleyin.
2. Render/HTML doğrulaması yapın: Googlebot simülasyonu veya test aracıyla winner sayfasının kazanan metninin HTML içinde göründüğünü kontrol edin.
3. İndeksleme kontrolü: Search Console’da URL denetimi ile “Kullanılabilir mi / İndekslendi mi” statülerini karşılaştırın; canonical hedefinin dikkate alınıp alınmadığını gözlemleyin.
4. Crawl bütçesi kontrolü: Server log veya crawl metriklerinde aktif poll taramasının beklenen seviyede olup olmadığını kontrol edin.
5. Threshold güncellemesi: Eşik değeriniz tutmuyorsa (ör. çok erken index açma ince içerik getiriyorsa) oy/cevap bandlarını revize edin.

Sık sorulan sorular (FAQ)

Aktif poll’ları indexlemek crawl bütçesini tüketir mi?
Evet. Aktif poll’lar kısa içerik ve yüksek churn nedeniyle çok sayıda keşif üretir. Noindex/nofollow veya canonical ile konsolidasyon genellikle daha kontrollü sonuç verir.

Poll kapanınca (winner oluşunca) URL statüsünü (index/noindex) güncellemek gerekir mi?
Gereken durumlar vardır. Kapanınca içerik zenginleşir; bu yüzden index açma (threshold ile) uygulanabilir. Ancak canonical ve internal linkler birlikte güncellenmeli.

Winner sayfası ile poll ana sayfası arasında canonical nasıl seçilmeli?
Arama niyeti açısından kazanan/sonuç sayfası daha spesifikse canonical’ı winner/results’e taşıyın. Poll ana sayfası canonical hedef olmamalı; yalnızca bağlam/akış amaçlı bir “entry” olarak kalabilir.

Noindex mi canonical mi? İkisini birlikte kullanmanın doğru olduğu durumlar nelerdir?
Noindex, indekslemeyi durdurur; canonical ise sinyali doğru URL’ye taşır. Aktif poll gibi ince içerik riskli durumlarda birlikte kullanmak çoğunlukla doğrudur. Ancak canonical’ın kendisinin indexlenmeyecek bir hedefe bağlanmamasına dikkat edin.

Oy sayısı az olan poll’lar ‘ince içerik’ filtrelerine takılır mı; threshold nasıl belirlenir?
Takılma riski vardır. Threshold’u tarihsel veriye dayandırın: indekslenen ama performansı düşük URL oranı ile oy/cevap bandlarını kıyaslayın. A/B veya kademeli açma ile başlayın.

Poll sonuçları sayfası parametreli olursa (tarih aralığı) canonical/robots nasıl yönetilir?
Parametreli tarih filtreleri için noindex veya canonical’ı ana “tüm sonuç” URL’sine bağlayın. Sitemap’a parametreli varyant eklemeyin; aksi halde churn ve thin slice artar.

JS ile render edilen poll sonuçları Google tarafından anlaşılır mı; nasıl doğrulanır?
Anlaşılabilir; ancak sonuçların kazanan metni ve oy özetinin HTML’de görüldüğünden emin olmalısınız. Doğrulama için Search Console URL denetimi + HTML/ekran görüntüsü karşılaştırması yapın; mümkünse SSR/edge rendering tercih edin.

Ek yönlendirme: UGC varyantlarında kararı veriyle kilitleyin

Poll’lar UGC’nin özel bir alt kümesidir ve diğer UGC türlerinde olduğu gibi “UI farkı” ile “içerik farkı”nı karıştırmak kolaydır. Poll varyantlarının bazıları (örn. spoiler benzeri/JS gecikmesi olan alanlar) içeriği anlık değiştirebilir. Bu tarz senaryolarda politika tasarımını başka UI durumları için de düşünmek gerekir. Benzer şekilde içerik/erim/parametre yönetimini şuradaki çerçeveyle de okuyabilirsiniz: Chat’te Spoiler Açılınca İçerik İndekslensin mi? Anlık Güncelleme mi Yeni URL mi? SEO Rehberi.

Özetle, poll indeksleme kararı tek bir etikete indirgenmez: UGC ince içerik sinyali, winner/summary gibi agregasyon sayfaları ve canonical/robots/parametre stratejisi birlikte ele alınmalıdır. Böylece hem crawl bütçesi korunur hem de arama motoruna doğru “tek doğru kaynak” sinyali gider.

Sonuç: Uygulanabilir politika özeti

Aktif poll’larda genellikle noindex + canonical konsolidasyonu ile ince içerik riskini azaltın; kapanmış poll’larda oy/cevap threshold ve render doğruluğu sağlanıyorsa winner/results sayfalarını indexe açın. Parametreli varyantları (tarih penceresi, oda/kanal, tag/kategori) sınırlayın ve canonical’ı tek bir master hedefte birleştirin. Moderasyon/gizleme durumlarında ise noindex + canonical’ı ana thread’e taşıyarak “eksik/zararlı içerik” sinyalini kontrol altına alın.

İsterseniz bir sonraki adım olarak kendi sisteminiz için “aktif poll yüzdesi / kapanmış poll winner sayısı / index oranı / crawl yoğunluğu” verileriyle bir eşik tablosu çıkarıp, karar matrisi üzerinde revizyon yapabilirsiniz. Bu yazının amacı tam olarak bu tür bir kontrol edilebilir karar setini sizde standartlaştırmaktır.