Chat Sitelerinde Oda Index Sitemap Eşik Kuralı: Son 24 Saat mi, 7 Gün mü? Mantık, Segmentasyon ve Ölçüm Planı

Chat ürünlerinde oda sayfalarını arama motoruna göstermek istiyorsanız, “sitemap’e oda ekleme eşiği” kararı index sağlığına doğrudan etki eder. Bu yazıda Chat sitesinde sitemap’e oda ekleme eşiği: Son 24 saat/7 gün odalar mı indexlenmeli? Mantık ve segmentasyon sorusunu operasyonel bir kurala çeviriyoruz: Hangi odalar, ne zaman “add/remove” ile indexlenebilir hale gelmeli?

Amacımız net: index israfını azaltmak (index budget’ın boşa gitmesini engellemek), sıralama dalgalanmasını minimize etmek ve ekip içinde aynı tartışmaları tekrar tekrar yaşamamak. Bunu yaparken recency (tazelik) ile kalite arasındaki dengeyi, crawl/ index bütçe farkını ve oda segmentlerine göre zaman penceresi mantığını birlikte ele alacağız.

Konu Haritası: Sitemap’te index (add/remove) neden ‘zaman eşiği’ gerektirir?

Sitemap, arama motorlarına “dolaşılacak” URL sinyali verir; fakat her URL’yi hemen eklemek, özellikle chat gibi sürekli değişen içeriklerde index kararını gereksiz yere dalgalı hale getirebilir. Chat odaları dinamik olduğu için sayfa kalitesi (başlık, ilk mesajlar, konuşma hacmi, etkileşim sinyalleri) zaman içinde değişir. Bu değişimi doğru yakalayamazsanız, daha erken eklenen odalar zayıf sinyallerle indexlenip sonra “düşük kalite” gibi görünebilir.

Zaman eşiği, sitemap index’te URL’lerin hangi olgunluk seviyesinde dışarıya açılacağını belirleyen bir “kapı” gibidir. Eşik yoksa iki uç risk oluşur: (1) çok erken ekleme → kalite sinyalleri oluşmadan indexlenme ve ardından gerileme, (2) çok geç ekleme → değerli odalar hiç indexleyemeden boşa dolaşır ve görünürlük gecikir.

Temel Kavramlar: recency vs kalite, crawl budget vs index budget, index israfı

Recency (tazelik) chat odalarında doğal olarak yükselir: yeni oda, yeni mesaj akışı, hatta başlık değişiklikleri bile hızlıca gelir. Ama recency tek başına SEO kalitesi demek değildir. Arama motoru, sayfanın içerik zenginliği ve kullanıcı değeriyle ilişkili sinyallerini zaman içinde daha iyi değerlendirir. Bu yüzden recency ile kaliteyi ayırmak gerekir.

Crawl budget, tarayıcının belli bir alanı (site/alt alan) ne sıklıkla gezebileceğine dair bütçedir. Index budget ise indexlenmeye aday URL sayısının ne kadarının “değerli” bulunup tutulduğunu ifade eder. Chat sistemlerinde her yeni oda bir URL adayıdır; eşik kuralı koymadan bu adayların tamamını sitemap’e hemen almak, index budget’ı düşük değerli URL’lerle doldurur (index israfı). Bunun sonucu olarak daha kaliteli sayfaların daha geç veya daha az keşfedilmesi mümkün olur.

Index israfı genellikle şu tür durumlarda ortaya çıkar: kısa ömürlü odalar (kimse gelmeden kapanan), az mesajlı odalar, erişim kısıtlı/oturum gerektiren sayfalar, embed/ek içerikle bot-safe olmayan DOM üreten sayfalar veya arama terimi türetilmiş “low intent” oda sayfaları. Zaman eşiği, bu grupların olgunlaşmadan dışarı çıkmasını engelleyerek bir filtre görevi görür.

Karar Çerçevesi: 24 saat/7 gün eşikleri için hangi sorulara cevap aranır?

“24 saat mi 7 gün mü?” sorusunun cevabı tek bir evrensel kural değildir; oda davranışları, altyapı maliyetleri ve hedef pazar/cluster stratejisi belirleyici olur. Örneğin hedef ülke tek ve trafikleri oradan geliyorsa kullanıcı etkileşimi daha hızlı olgunlaşabilir; bu da 24 saat penceresini destekler. Çoklu ülke/cluster söz konusuysa, ilk kullanıcıların gelmesi daha uzun sürebilir.

Şu sorular, eşik kararını tartışmasız hale getirmeye yardımcı olur:

1. Hedef cluster/ülke: Yeni odalara ilk etkileşim ne kadar sürede geliyor? (ortalama “ilk mesaj - ilk 10 mesaj - ilk aktiflik” zamanları)
2. Sistem maliyeti: Sitemap index’te add/remove yapmak ve yeniden crawl tetiklemek ekstra yük oluşturuyor mu? Log/CPU maliyetini ölçtünüz mü?
3. Kullanıcı davranışı: Oda açıldıktan sonra kaç saat içinde “kapanma” ya da “donuk kalma” yaşanıyor?
4. İçerik türü: Oda sadece sohbet mi, yoksa embed/video/mp3 transkript gibi içerikler var mı? İçerik zenginliği gecikmeli mi geliyor?
5. Arama niyeti: “Terim bazlı oda” mı üretiyorsunuz? Bu sayfalar genellikle daha hızlı ama daha düşük değerli mi oluyor?

Bu soruların cevabı, 24/7 gün yerine aslında “hangi oda segmenti hangi recency penceresinde indexlenmeye değer?” fikrine götürür.

Oda Segmentasyonu Tasarımı: oda yaşı, mesaj hacmi, aktiflik trendi, benzersizlik sinyalleri

Zaman eşiğini tek bir kural gibi düşünmek, chat ürünlerinde en sık yapılan hatalardan biridir. Çünkü tüm odalar aynı “risk” profilini taşımaz. Daha sağlıklı yaklaşım, oda segmentlerine göre recency ve kalite sinyallerini birleştirerek karar vermektir.

Pratik segmentasyon örnekleri:

• Yeni oda: İlk mesajlardan sonra nasıl bir büyüme gösteriyor?
• Aktif oda: Mesaj akışı istikrarlı mı, yoksa tek seferlik mi kalıyor?
• Düşük mesaj odaları: 0-10 mesaj gibi kısa kalıp kapananlar (index israfı riski yüksek).
• Embed/video/audio içeren odalar: Zengin içerik geç yükleniyorsa 24 saat erken olabilir; embed tamamlanınca indeks daha anlamlı olur.
• Erişim kısıtlı/profil tabanlı oda sayfaları: Genel index için uygun olmayabilir; sitemap index yerine farklı sinyal (veya hiç index) değerlendirilir.
• Arama terimi odaları: Terim normalize ediliyor mu ve sayfanın özgün değeri var mı? Düşük intent riskini ölçün.

Zaman Eşiği Modeli: tek eşik mi çoklu eşik mi?

Çoğu ekip “tek eşik” ile başlar; örneğin “odayı açıldıktan 24 saat sonra sitemap’e ekle”. Bu yaklaşım bazen çalışır, ama chat’te içerik olgunlaşması segmentlere göre değişir. Bu yüzden çoğu durumda çoklu eşik daha anlamlıdır: 0-24 saat “teaser/deneme”, 24-72 saat “kalite doğrulama”, 7 gün “kalıcı index” gibi.

Basit bir model şöyle kurgulanabilir: 0-24 saat pencere içinde URL’yi ya hiç göstermemek ya da sadece belirli segmentlerde (yüksek sinyal beklenen) göstermek. 24-72 saat aralığında mesaj hacmi/etkileşim trendi yeterliyse indexe izin vermek. 7 gün sonrasında ise “kalıcılık” sinyali (user retention, aktiflik devamı) güçlenirse URL’yi daha stabil biçimde tutmak.

Eşik Seçimi İçin Ölçüm Planı: GSC verileri, log/rawl tabanlı sinyaller, indexlenme oranı

Zaman eşiğini seçmek için “hisse” yerine ölçüm planı şart. Çünkü hangi eşiği (24 saat mi 7 gün mü) tercih ettiğinizde, hangi metriklerin gerçekten iyileştiğini netleştirmek gerekir. Bu metrikler iki grupta toplanır: (1) arama motoru görünürlüğü ve index durumu, (2) altyapı/operasyon maliyeti.

Önerilen ana metrik seti:

• Indexlenme oranı: Sitemap’e eklenen URL’lerin kaçının “Indexed, not submitted in sitemap” veya beklenen kategoriye düştüğü
• İlk crawl süresi: Eklemeyi takiben kaç saatte/kaç günde crawl gerçekleşti?
• İlk index gecikmesi: İlk crawl’den indexlenmeye geçiş süresi
• GSC’de “Discoveries” ve “Crawled - currently not indexed” sinyali
• SERP görünürlük: İndekslenen odaların query bazlı görünümü ve ortalama pozisyonu (özellikle recency etkisi)
• Log bazlı başarı: 200/304 dağılımı, rendering başarısı, JS erişim engelleri

Bu ölçümlerle, 24 saat penceresi erken dönen zayıf odaları indexleyip dalgalanma yaratıyor mu; yoksa 7 gün penceresi değerli odaları geç mi bırakıyor sorusunu somut şekilde yanıtlayabilirsiniz.

Kontrol Deneyleri (A/B veya kohort): aynı oda tipinde farklı eşik politikaları

Eşik politikasını “tek seferde” değiştmek yerine kontrollü test yapın. En iyi yaklaşım kohort bazlıdır: Aynı oda tipi (ör. genç odalar, az mesajlı odalar, embedli odalar) içinde farklı zaman pencereleri uygular, sonuçları daha adil karşılaştırırsınız.

Örneğin iki grup oluşturabilirsiniz: Grup A 24 saat, Grup B 7 gün. Sonra 7-14 gün sonrası şu soruları ölçün: indexlenme oranı arttı mı, “crawled but not indexed” oranı azaldı mı, SERP’de stabilite (pozisyon varyansı) iyileşti mi? Aynı zamanda operasyonel maliyet: add/remove sayısı ve crawl tetik yoğunluğu nasıl etkileniyor?

Otomasyon Akışı: sitemap index’te ekleme/çıkarma kuralı, late arriving data ve geri alma stratejisi

Eşik kuralı sadece “mantık” değildir; otomasyonun add/remove akışında somutlaşır. Sitemap index yaklaşımında genellikle iki set oluşur: index’te tutulacak URL’ler (aktif liste) ve henüz “olgunlaşmadığı” için bekletilen URL’ler (staging liste). Eşik koşulu değişince URL’nin sitemap index’te eklenip çıkarılması gerekir.

Uygulamada ayrıca şu senaryoları planlayın: late arriving data (ilk mesajlar geç geliyor), başlık/title değişikliği (kullanıcı profiline göre), embed/video yüklenmesi (gecikmeli). Eşik koşulu sağlandığında ekleyin; koşul bozulduğunda (ör. erişim kısıtı açıldı veya oda kalitesizleşti) geri çekin. Rollback stratejisi de hazır olmalı: test yanlış sonuç verirse 24-48 saat içinde grubu geri almak gibi.

Noindex/robots/canonical ile birlikte çalışma: zaman eşiği kuralı nasıl çakışır?

Zaman eşiği kuralı sitemap index’e URL ekleme kararını etkiler; ancak arama motorunun index kararını tek başına belirlemez. Bu yüzden noindex, robots ve canonical sinyalleriyle çakışma riskini yönetmeniz gerekir. Örneğin, erişim kısıtlı oda sayfalarında “noindex” varsa sitemap’e ekleseniz bile indexlenmeyebilir; bu da ölçümünüzde farklı sapmalara neden olur.

Genel kural şu olmalı: sitemap’e eklediğiniz URL’nin indexlenmesine izin veren sinyallerle uyumlu olduğundan emin olun. Yani zaman eşiği, “noindex/robots”tan bağımsız çalışmamalı; karar matrisiyle birlikte ele alınmalıdır.

Risk Analizi: yanlış eşikte ne olur?

Yanlış eşik seçimi, teknik SEO’da anlık bir “hata” gibi görünmeyebilir; ama zaman içinde performans düşüşü ve dalgalanma olarak geri döner. Erken eşikte (ör. 24 saat) risk: zayıf odaların hızlı indexlenmesi, ardından oda içeriğinin sönmesiyle sayfa kalitesinin düşmesi ve SERP stabilitesinin bozulmasıdır. Bu dalgalanma, büyüme ekibinin “sıralamalar neden oynuyor?” sorusunu gündeme taşır.

Geç eşikte (ör. 7 gün) risk: değerli odaların indexlenemeden “zaman penceresi” kaçırması. Özellikle trend olan odalarda (aktiflik patlaması) içerik hızla büyüyüp sönüyorsa, geç eşik görünürlük fırsatını kaçırabilir. Ayrıca orphan/kırık trafik (sitemap’te yer almasına rağmen canonical/noindex veya erişim engeli nedeniyle 404/redirect döngüsüne düşme) oluşabilir.

Uygulama Kontrol Listesi: launch öncesi/sonrası doğrulama adımları

Bu bölümde pratik bir “doğrulama adımları” kontrol listesi veriyorum. Eşik kuralını devreye almadan önce otomasyonun doğru çalıştığını ve ölçümün temiz sinyal verdiğini garanti altına alın.

1. Politika simülasyonu: Son 30 gün oda verisini kullanarak 24 saat ve 7 gün kurallarını “dry-run” çalıştırın; kaç URL eklenmiş/çıkarılmış hesaplayın.
2. Sinyal uyumu kontrolü: Noindex/robots/canonical durumunu oda segmentine göre doğrulayın. Eşik sağlansa bile indexe izin veriliyor mu?
3. GSC ve log eşleştirme: Sitemap’e eklenen URL’lerin GSC’de hangi statüye düştüğünü (indexed/crawled-not-indexed) zaman ekseninde izleyin.
4. Render ve erişim testi: JS render engeli, oturum gerektiren sayfa, profil bazlı erişim gibi durumlarda tarayıcı davranışını test edin.
5. Rollback planı: Test başarısızsa hangi parametreyle geri döneceğinizi (eşik değeri, segment kapsamı, add/remove frekansı) yazılı hale getirin.

Örnek Politikalar: startup/growing/scale için eşik setleri

Tek bir eşik seti her aşamada aynı şekilde uygun olmaz. Aşağıdaki örnekler, farklı büyüme olgunluklarına göre recency/kalite dengesini nasıl ayarlayabileceğinizi gösterir. Buradaki amaç “nereden başlamak” için bir başlangıç çerçevesi sağlamak; sonraki ölçümlere göre rafine etmektir.

Oda Olgunluk Seviyesi	Hedef Segment	Recency Penceresi	Kalite Doğrulama Kriteri (örnek)	Sitemap Index Davranışı
Startup	Yeni + yüksek beklenti odaları	0-24s (deneme), 24-72s (doğrulama)	İlk 10-20 mesaj gelmiş, embed içeriği tamamlanmış	0-24s: çoğu segment beklemede; 24-72s: uygun olanlar ekle
Growing	Genel odalar	24-72s eşik	Aktiflik trendi pozitif + benzersizlik sinyali (ör. başlık/sorgu eşleşmesi)	24-72s sonunda ekle; zayıf kalanları beklet
Scale	Trend patlaması yaşayan odalar	0-12s teaser, 12-48s dinamik güncelleme, 7g kalıcı tutma	İlk saatlerde mesaj hızlanması + tekrar eden etkileşim	Trend başlayınca hızlı add; 7 gün kalite koruması

Örnek 1: Yeni oluşturulan odalar için ‘0-24 saat deneme modu’, ‘24-7 gün kalite doğrulaması’

Yeni oda açıldığında recency çok yüksektir ama kalite sinyalleri henüz oluşmamış olabilir. Bu yüzden 0-24 saat aralığını “deneme modu” gibi düşünün. Bu modda oda URL’sini her zaman index sitemap’e eklemeyin; özellikle az kullanıcı etkileşimi beklenen segmentlerde bekletin.

Akış örneği: Oda açıldı → 0-24 saat içinde sadece teaser/limited listeye al → 24-72 saat aralığında mesaj hacmi ve embed içeriğinin tamamlanması gibi sinyaller geçiyorsa index sitemap’e ekle → 7 gün boyunca kalite doğrulaması devam eder. 7 gün sonunda hala aktifse kalıcı tut, değilse geri çek.

Örnek 2: Az mesajlı odalar için zaman eşiği + mesaj eşik kombinasyonu

Az mesajlı odalarda sadece zaman eşiği koymak çoğu zaman yeterli olmaz. Çünkü oda 24 saat dolsa bile konuşma hacmi düşük kalabilir ve sayfa “ince içerik” gibi görünebilir. Bu durumda zaman eşiğini mesaj sayısı eşiğiyle birleştirin: mesaj sayısı düşükse indexe eklemeyi geciktirin.

Örnek akış: 0-24 saat beklemede kal → 24 saat geçince mesaj sayısı N altındaysa “ekleme geciktir” → mesaj sayısı N üstüne çıkarsa 24-72 saat penceresinde indexlenmeye izin ver. Böylece index israfını azaltırken gerçekten büyüyen odaları da kaçırmazsınız.

Örnek 3: Aktiflik patlaması yaşayan odalarda (trend) zaman eşiğinin dinamik güncellenmesi

Trend odalarda “saatler içinde değer değişimi” çok hızlı olur. Bu tip odalarda sabit 7 gün eşik, fırsat maliyetine dönüşür. Bu yüzden dinamik recency güncellemesi uygulayabilirsiniz: trend sinyali geldiğinde eşik penceresini kısaltın.

Örnek: Son 30-60 dakikada mesaj hızı belirli bir eşik üstüne çıkarsa (ör. dakikada X mesaj), oda “trend cohort” olarak işaretlenir. Bu odalarda 24 saat yerine daha kısa pencereyle sitemap add tetiklenir. Trend zayıflarsa geri çekme veya tutma politikası 7 gün doğrulamasına bağlanır.

Örnek 4: Erişim kısıtlı/profil tabanlı oda sayfaları varsa sitemap index yerine hangi sinyal?

Profil tabanlı veya erişim kısıtlı odalarda sitemap index’e ekleme çoğu zaman yanlış sinyal üretir. Çünkü tarayıcılar sayfayı göremeyebilir ya da içerik oturumla şekillendiği için “render edilen gerçek içerik” tarayıcıda eksik görünebilir. Bu segmentte zaman eşiği bile tek başına kurtarmaz.

Bu segmentte sitemap index yerine daha uygun sinyal seçin: kısıtlıysa noindex yaklaşımı veya genel sayfada (ör. kullanıcı/oda rehberi gibi) kontrollü teaser + güvenli içerik yönetimi. Böylece arama motorunun boşa crawl ettiği sayfaları azaltır, index israfını daha en baştan engellersiniz.

Yaygın hatalar

En yaygın hatalardan biri, tüm oda segmentleri için tek eşik kuralı uygulamaktır. Yeni oda, trend oda ve az mesajlı oda aynı davranışı beklemez; tek eşik, index bütçeyi rastgele dağıtır. Sonuç olarak hem düşük değerli URL’ler erken indexlenir hem de kaliteli odalar fırsatı kaçırır.

Bir diğer sık hata, noindex/robots/canonical sinyalleriyle eşik politikasını çakıştırmadan otomasyon kurmaktır. Sitemap’e eklediğiniz URL “noindex” taşıyorsa ölçümünüzde “neden indexlenmiyor?” sorusu çıkar ve test tasarımınız bozulur. Ayrıca add/remove frekansını kontrolsüz yapmak, crawl ve index kararlarını daha da dalgalı hale getirebilir.

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

“Eşik çalışıyor mu?” sorusunun cevabını tek bir rapordan vermek zor. Aşağıdaki adımlar zaman eşiği politikasını doğrulamak için pratik bir akış sağlar:

1. Sitemap envanterini çıkarın: Son test haftasında eklenen/çıkarılan URL sayısını ve dağılımını (segment bazında) listeleyin.
2. GSC statülerini zaman ekseninde izleyin: “Indexed”, “Crawled - currently not indexed”, “Submitted URL not selected for indexing” gibi farkları eşik değişim günleriyle eşleştirin.
3. Log/rawl tabanlı crawl başarı oranını karşılaştırın: 200/304, rendering başarısı ve redirect/blocked oranlarında anomali var mı kontrol edin.
4. SERP görünürlük stabilitesini ölçün: İlk index sonrası 3-7 gün bandında ortalama pozisyon ve görünüm dalgalanmasını karşılaştırın.

Bu kontrol zinciri, 24 saat/7 gün seçiminizin gerçekten etkili olup olmadığını ve hangi segmentte daha iyi çalıştığını ortaya çıkarır.

Sık Sorulan Sorular (SSS)

Sitemap index’e eklediğim oda kesin indekslenir mi?
Hayır. Sitemap, keşfi kolaylaştırır; ancak arama motoru sayfanın kalite sinyallerini değerlendirerek indexlemeyi seçer. Bu yüzden eşik kuralı, özellikle chat’te, “kesin index” garantisi değil “indekslenmeye aday olgunluk” yönetimidir.

24 saat eşiği yerine 7 gün kullanmak hangi koşullarda daha doğru?
Eğer odalarda içerik olgunlaşması geç oluyorsa (ör. embed içeriğin tamamlanması gün sürüyorsa, kullanıcı gelme döngüsü uzunsa veya az mesajlı odalar sık görülüyorsa) 7 gün daha az index israfı üretebilir. Trend olmayan ama kalıcı etkileşim gösteren odalarda da 7 gün daha tutarlı sonuçlar verir.

Eşik kurallarıyla noindex/robots/canonical çakışırsa ne olur?
Sitemap’e eklediğiniz URL noindex/robots ile engelleniyorsa arama motoru indexlemeyi geciktirir ya da hiç seçmeyebilir. Ayrıca canonical yanlışsa (ör. başka URL’ye canonical yönlendirme) indexlenen sayfa beklediğiniz oda sayfası olmayabilir. Bu durumda ölçüm ve raporlama yanlış yorumlanabilir.

Yeni oda çok hızlı değişiyorsa (title/başlık) zaman eşiği nasıl ayarlanmalı?
Başlık sürekli değişiyorsa, arama motorunun “son hali”ni yakalaması için eşiği biraz uzatmak veya sadece title değişimi belirli bir süre sabitlenince eklemek mantıklı olur. Trend sinyali varsa dinamik eşik, yoksa gecikmeli doğrulama tercih edilmelidir.

GSC’de hangi metrikler “yanlış zaman eşiği” sinyali verir?
Sıklıkla “Crawled - currently not indexed” artışı, “Submitted URL not selected for indexing” oranlarının test boyunca yüksek kalması veya indexlenenlerin kısa sürede düşüş göstermesi yanlış eşik belirtisi olabilir. Ayrıca segment bazında indexlenme oranı ile SERP görünürlüğünün uyuşmaması da sinyal verir.

Oda içeriği güncelleniyorsa (en son mesaj) yeniden crawl/yeniden index gerekir mi?
Her güncelleme yeniden index gerektirmez; fakat önemli içerik değişimleri (zengin içerik eklenmesi, erişim açılması, anlamlı başlık güncellemesi, mesaj hacminin belirgin artması) crawl ihtiyacını artırır. Zaman eşiğini “ilk index” için koyup, sonrası için yeniden crawl tetikleme politikasını ayrı planlamak daha sağlıklıdır.

Farklı oda segmentleri için tek bir eşik kuralı neden riskli?
Çünkü segmentlerin olgunlaşma süresi, kalite sinyali ve risk seviyesi farklıdır. Tek eşik, hem düşük değerli URL’leri erken indexler (israf) hem de değerli URL’leri geç bırakarak görünürlüğü geciktirir. Bu da büyüme hedefleriyle çatışır.

İlgili teknik rehberler

Eşik kuralını doğru segmentasyonla tamamlamak için aşağıdaki konularla birlikte düşünün. (Bu bağlantılar, aynı altyapı ekibinin sık ihtiyaç duyduğu tamamlayıcı başlıklardır.)

• oda bazlı index sitemap (segmentasyon) altyapısını kurma
• en son mesaj güncellemesi sıralama dalgalanmasını azaltma
• oda eşiği modeli ile arşiv/teaser indeksleme kararı