Sohbet Sitelerinde Sonsuz Scroll SEO: AJAX Görünürlüğü ve Prerender/SSR ile Arama Motoru Uyumu

Sohbet sitesi için sonsuz scroll SEO nasıl yapılır (AJAX ve prerender) sorusunun cevabı, klasik “sayfa SEO”dan çok daha fazlasıdır; çünkü sohbet akışında içerik ve kullanıcı etkileşimi çoğu zaman sonradan oluşur. Bu da discoverability (keşfedilme) sorununu tetikler. Bu yazıda, sohbet listeleri ve mesaj akışlarında sonsuz scroll ile gelen içerikleri arama motorlarının görebilmesi için uygulanabilir mimari seçenekleri adım adım ele alıyoruz.

Temel amacımız şu riski azaltmak: “Sonsuz kaydırma var ama Google nereden öğrenecek?” Bunun için crawl-friendly veri akışı, URL/kanonik stratejisi, prerender/SSR yaklaşımları ve doğrulama (Search Console + site: testi + log analizi) odaklı pratik bir yol haritası paylaşacağız.

Sorun Tanımı: Sonsuz scroll + AJAX neden indekslenmez (render, crawl, discoverability)

Sonsuz scroll’un doğası gereği, ilk ekranda genellikle sadece “ilk mesajlar” (ya da ilk sayfa) HTML’in içinde durur; geri kalan mesajlar ve sohbet/oda içeriği ise tarama sırasında henüz yüklenmemiş olabilir. Botlar sayfayı aldığında içerik yerinde olmadığı için indekslenecek net bir metin bulamaz.

Bir diğer mesele de şu: Arama motorları her zaman kullanıcı gibi “sonuna kadar kaydır” davranışını sergileyemez. Sürekli AJAX çağrıları botların sayfada ilerlemesini zorlaştırabilir; ayrıca bazı botlar JS tarafında farklı render davranışları gösterebilir. Sonuç olarak sayfa, görünür içerikten yoksun kalabilir.

Keşfedilme tarafında da sorun büyür: Sonsuz scroll’da “sayfa 2, sayfa 3…” gibi ayrı HTML URL’leri çoğu zaman yoktur. Oysa keşif için genellikle linkler, sitemap’ler ve URL çeşitliliği gerekir. Bu yüzden sohbet akışının “sonsuz” olması, indeksin de “sonsuz” olacağı anlamına gelmez; çoğu senaryoda indeks, ilk yükle sınırlı kalır.

Hedef Sayfalar ve İçerik Modeli: sohbet listesi, kanal/oda sayfaları, mesaj sayfaları, kullanıcı profili

Önce hangi sayfaların hedefleneceğini netleştirin. Sohbet sitelerinde arama motoru değeri genellikle şu alanlarda oluşur: odaların/kanalların listelenmesi, oda içeriğinin anlaşılır başlıklar ile temsil edilmesi, belirli mesajların veya sohbet bölümlerinin bulunabilirliği ve kullanıcı profillerinin doğrulanabilirliği.

Bu yüzden içerik modelini “akış” gibi düşünmek yerine “indekslenebilir parçalar” olarak tasarlayın. Örneğin bir oda sayfasında mesajlar akış gibi görünse bile, arama motoru için sayfa tabanlı bir görünüm sağlamanız gerekir.

Tipik hedefler: (1) sohbet listesi (kategori/şehir/etiket), (2) oda/kanal sayfası (oda meta bilgisi, son mesaj özeti), (3) mesaj sayfaları (ör. kronolojik dilim), (4) kullanıcı profili (konuşma geçmişi, öne çıkan odalar).

SEO Stratejisi Seçenekleri: SSR/SSG, Prerender, Hybrid, Crawl-friendly pagination, Render fallback

Aşağıdaki stratejiler, sohbet akışında sonsuz scroll’un indekslenebilirliğini sağlamak için farklı risk/eylem seviyeleri sunar. En kritik nokta, arama motoru için “ilk HTML’de anlamlı içerik” üretip üretmediğinizi kontrol etmektir.

1. SSR/SSG: Sunucu tarafında ilk görünümü HTML olarak üretmek (odanın/mesajların bir kısmı).
2. Prerender: Önceden belirli mesaj dilimlerini statik veya yarı statik üretmek (tam “sonsuz” değil, sınırlı bir pencere).
3. Hybrid: Server-side ilk N mesaj + client-side devam (AJAX).
4. Crawl-friendly pagination: Botlara sayfa tabanlı HTML (sayfa 1..K), kullanıcılara sonsuz scroll.
5. Render fallback: JS ile devam eden akışın yanında, kullanıcıların ve botların güvenli bir alternatif görmesi için temel içerik sağlamak.

Bu seçenekleri birlikte düşünün. Pratikte en düşük riskli başlangıç genellikle “Hybrid + crawl-friendly pagination fallback” olur: kullanıcı sonsuz scroll ile akışı deneyimler, botlar ise sayfa tabanlı sürümlerden içerik keşfeder.

Prerender Nasıl Yapılır? (ör. Next.js prerender/SSG, static export kısıtları, mesaj limiti)

Prerender yaklaşımı, “gelecek tüm mesajları” otomatik olarak dökmek değil; indekslenmesi anlamlı bir pencereyi hedeflemek üzerine kuruludur. Örneğin bir oda için ilk 50-200 mesajı HTML’de üretmek çoğu zaman daha rasyoneldir. Sonrasında geri kalanlar AJAX ile devam eder.

Next.js gibi framework’lerde bu yaklaşım şu akışla ilerler: sunucuda veya build sürecinde, oda başına mesaj dilimlerini belirleyin; her dilim için URL üretin; ilk N mesajı HTML’de render edin. Static export kısıtları varsa (tamamen statik site üretimi), oda sayfalarını “yarı statik” üretmek için ISR/route handler + edge/server prerender kombinasyonlarını değerlendirin.

Mesaj sayısı limiti kritik bir parametredir. Çok büyük pencereler hem crawl bütçesini hem de render maliyetini şişirir. Ayrıca aynı odada sürekli yeni mesaj geldiği için prerender sürümlerinin güncelliğini bir “yenileme sıklığı” ile yönetin.

AJAX Görünürlüğü: İlk yüklemede HTML’de içerik, sonradan gelen sayfalamada meta/URL tutarlılığı

Sonsuz scroll kullanan sohbet sitelerinde AJAX görünürlüğü, “JS çalışınca görünür içerik geliyor” demekle bitmez. Arama motoru açısından asıl kritik olan, ilk yüklemede HTML’de bulunacak metin ve linklerin neler olduğudur. Eğer bot ilk HTML’de sadece iskelet görürse, sonradan gelecek mesajları alamayabilir.

Bu yüzden ilk yükte oda/mesaj sayfasının bir bölümünü HTML olarak verin. Sonraki dilimleri ise AJAX ile getirin; ancak burada meta ve URL uyumunu koruyun. Örneğin kullanıcı scroll ettikçe içerik değişir, ama tarayıcı adres çubuğunda karşılık gelen URL güncellenmiyorsa canonical/indeks sinyalleri tutarsız hale gelebilir.

En güvenli yaklaşım: Sonsuz scroll devam ederken yeni içerik dilimi “URL tabanlı bir pencereye” karşılık gelecek şekilde tasarlayın. Botlar için bu sayfalara doğrudan erişilebilir olmalı; kullanıcılar için ise aynı URL’ler sonsuz scroll deneyimiyle örtüşmelidir.

URL Tasarımı: sayfa/offset/cursor, kanonik etiketler, kronolojik tutarlılık

URL tasarımı, sonsuz scroll SEO’nun omurgasıdır. Cursor tabanlı sistemler pratik olabilir ama kanonik strateji olmadan içerik çoğalmasına yol açabilir. Öte yandan sayfa tabanlı URL’ler botlar için daha anlaşılırdır. Bir denge kurun: kullanıcı sonsuz scroll ile ilerlerken, URL aslında bir “dilim”i temsil etsin.

Örnek URL şemaları:

• /oda/{slug}?cursor=eyJpZCI6MTIzNCwiZGF0ZSI6IjIwMjYtMDQtMTIifQ (cursor tabanlı)
• /oda/{slug}/sayfa-2 (sayfa tabanlı crawl-friendly)

Kanoniğe dair kritik nokta: Aynı içerik, farklı cursor parametreleriyle çoğalıyorsa indeks karmaşası yaşanır. Bu nedenle her dilim için “o dilimin tek canonical’ı” belirlenmeli, içerik örtüşmeleri mümkün olduğunca minimize edilmelidir.

Örnek kanonik etiket stratejisi: Kullanıcı scroll ile ?cursor=... değerine girdiğinde, bu dilimin “sayfa-2” karşılığı varsa canonical’ı /oda/{slug}/sayfa-2 olacak şekilde ayarlayın. Böylece farklı cursor’ların aynı pencereyi üretmesi halinde arama motoru tek URL’ye toplanır.

Crawl Bütçesi ve Performans: mesaj sayısı sınırları, kademeli yükleme, cache

Sohbetler doğal olarak yüksek hacimli ve sürekli değişen içeriklerdir. Bu nedenle crawl bütçesini yönetmek zorundasınız. Her mesajın ayrı indekslenmesi hem maliyet hem de faydasız çoğalma üretebilir. Bunun yerine indekslenmesi anlamlı olan “pencere”yi sınırlayın.

Pratik yaklaşım: her oda için maksimum indeks dilimi belirleyin (ör. son 30 dilim yerine ilk 5 dilim + belirli etkileşimli dönemler). Güncellemeler için cache stratejisi koyun: sık değişen son mesajları kısa TTL ile tazeleyin, daha eski pencereleri daha uzun TTL ile saklayın.

AJAX tarafında lazy loading yapın ama görünürlüğü bozmayın. Lazy loading sadece görsel bileşenler için değil, mesaj listelemesi için de kullanılıyorsa, botların ihtiyaç duyduğu metinleri ilk HTML’de sağlayacak bir “bootstrapped payload” eklemeyi unutmayın.

Sayfa/Endpoint	Hedef (SEO)	Önerilen İlk HTML İçerik	Sonrası (AJAX)
/oda/{slug}	Oda keşfi ve temel konu	İlk 50-100 mesaj + oda açıklaması	Cursor ile sonraki mesaj dilimleri
/oda/{slug}/sayfa-{n}	Mesaj dilimi indekslenmesi	Bu sayfanın mesajları (tam liste)	Kullanıcı akışında ilerleme

Yapılandırılmış Veri ve İç Bağlantılar: sohbet/oda/mesaj bağlamı için uygun schema ve linkleme

Yapılandırılmış veri, mesaj akışını “anlamsal objelere” çevirmenin en hızlı yollarından biridir. Her platform için schema birebir aynı değildir ama sohbet/oda/mesaj bağlamını doğru tanımlamak, arama motoru anlayışını ciddi şekilde artırır. Örneğin oda sayfasında “Organization/Place benzeri” bağlamlar, mesaj sayfasında ise “Conversation” benzeri temsiller hedeflenebilir.

İç bağlantılar da sonsuz scroll’da kritik hale gelir. Her mesaj diliminin sayfa tabanlı versiyonuna bir “pagination link seti” ekleyin veya en azından “bir önceki/sonraki dilim” bağlantılarını HTML içinde bulundurun. Böylece botlar JS tetiklemeden de ilerleyebilir.

Schema ve iç linkleme için iyi bir başlangıç: Sohbet Odaları İçin Schema.org Yapılandırılmış Veri Nasıl Eklenir? (JSON-LD Örnekleriyle Adım Adım) içeriğindeki örnekleri sohbet akışınızın veri modeline uyarlayın.

Robots/Crawl Kontrolleri: robots.txt, noindex/nofollow senaryoları, rate limit

robots.txt ve robots meta etiketleri, indekslenmeyi “kapatmak” için değil; crawl davranışını “yönetmek” için kullanılmalı. Sonsuz scroll’da sayfa patlaması riski vardır: cursor parametreleri veya offset tabanlı URL’ler sonsuz kombinasyonlar üretebilir. Bu URL’leri ya tamamen indeks dışı tutun ya da kanonik/pagination ile kontrollü hale getirin.

noindex/nofollow senaryoları da dikkat ister. Örneğin botların taramasını tamamen engellemek istemiyorsanız nofollow her zaman doğru tercih olmaz; bunun yerine canonical ile sinyalleri toplayın, robots ile gereksiz URL’leri sınırlayın. Ayrıca rate limit koyun: sohbet siteleri yoğun olduğundan bot trafiği uygulama performansını etkileyebilir.

robots.txt ve sitemap kurgusu için Chat Sitesi SEO: robots.txt ve sitemap.xml Dosyaları Nasıl Yapılandırılır? (Adım Adım Rehber) rehberi ile kontrol noktalarını sistemleştirebilirsiniz.

Uygulama Planı: 0-1 MVP (en az riskli yaklaşım) + iterasyon adımları

“Sıfırdan her şeyi SSR yapalım” yaklaşımı sohbet uygulamalarında genellikle maliyetli olur. En az riskli MVP, server-side ilk görünüm + crawl-friendly fallback ile başlamak olacaktır. Yani kullanıcı sonsuz scroll görür, bot ise sayfa tabanlı HTML dilimlerini keşfeder.

Önerilen MVP akışı:

• İlk adım: Oda sayfasında ilk N mesajı HTML’de render edin (Hybrid).
• İkinci adım: Botlar için /oda/{slug}/sayfa-1..sayfa-K aralığını üretin (crawl-friendly pagination).
• Üçüncü adım: Sonsuz scroll’da URL çakışmalarını kanonik ile yönetin (cursor farklılıklarını tek canonical’a toplayın).

Iterasyon: önce indekslenme sinyallerini doğrulayın, sonra K aralığını ve pencere boyutunu ayarlayın. En son aşamada schema ve performans optimizasyonlarını genişletin.

Örnek Prerender Yaklaşımı: ilk N mesajı HTML’de render etme + kalanını AJAX ile getirme

Prerender örneği, risk azaltan bir “kademeli indeksleme” modelidir. Diyelim ki oda içeriği çok büyüyor; o zaman HTML’de ilk 100 mesajı verirsiniz. Kullanıcı scroll ettikçe client-side, devam eden mesajları /api/oda/{slug}/messages?cursor=... gibi endpoint’lerden alır.

Botlar için kritik nokta şu: İlk HTML’de metin ve linkler eksiksiz olmalı. Böylece Google sayfayı render etmeden bile “varlık” sinyalini alabilir; render edebilirse daha fazla metin görür.

Cursor tabanlı devam yine kullanılabilir ama “indekslenebilir pencere”yi sayfa tabanlı bir alternatifle sabitleyin. Böylece AJAX görünürlük problemi azalır.

Örnek Next.js/React Mimari Akışı (server-side ilk yük + client-side devam)

Aşağıdaki mimari desen, sonsuz scroll SEO hedefleriyle uyumludur. İlk yükte server-side HTML üretilir, ardından client-side devam eder. Örneğin Next.js’te oda sayfası bir server component/SSR route üzerinden ilk pencereyi render eder.

Akış şöyle düşünülür:

1. Bot veya kullanıcı oda sayfasını ister.
2. Sunucu, ilk pencereyi (ör. ilk 100 mesaj) HTML’e basar; ayrıca sayfa tabanlı “bir sonraki dilim” bağlantısını ekler.
3. İstemci, görünürlük eşiğine ulaştığında AJAX ile kalan mesajları getirir.
4. URL güncellenir ya da canonical belirlenir; cursor tabanlı değişimler tek dilime map edilir.

React/Vue SPA kullanıyor olsanız bile aynı fikri koruyun: “ilk içerik” mutlaka HTML’de olmalı. Tamamen client-side render ile başlamak, sohbet akışında indekslenmeyi ciddi biçimde düşürür.

Örnek “crawl-friendly pagination” fallback: botlara sayfa tabanlı HTML, kullanıcılara sonsuz scroll

Crawl-friendly pagination fallback stratejisi, kullanıcı deneyimini bozmadan SEO’yu iyileştirir. Bot bir sayfayı isterken /oda/{slug}/sayfa-2 gibi URL’ler sunulur ve HTML içinde o sayfaya ait tam mesaj seti bulunur. Kullanıcı ise aynı içerik “sonsuz scroll” ile deneyimler.

Bu yaklaşım özellikle “aynı oda içinde mesajların mantıksal dilimlenmesi” gereken durumlarda etkilidir. Ayrıca canonical etiket stratejinizi daha temiz kurarsınız: sonsuz scroll sırasında farklı cursor değerleri oluşsa bile, arama motoru dilimlere tek bir URL ile ulaşır.

Kontrol ve Doğrulama: test araçları, log inceleme, indeksleme sinyalleri (adım adım doğrulama)

En iyi mimari bile yanlış konfigürasyonla bozulabilir. Bu yüzden “nasıl kontrol edilir” sorusunu sürecin merkezine alın. Aşağıda uygulanabilir bir “doğrulama adımları” seti var:

1. HTML doğrulaması: Oda/mesaj sayfasının “view-source” çıktısında ilk N mesajın metnini görebiliyor musunuz? İçerik sadece client-side runtime ile mi geliyor, yoksa HTML’de var mı?
2. URL ve kanonik tutarlılık: Scroll ile yeni dilime geçtiğinizde adres değişiyor mu? Değişmiyorsa canonical doğru URL’ye map ediyor mu? Cursor varyantları farklı canonical üretmemeli.
3. Google sinyalleri: Search Console’da “İnceleme > Canlı test” ve “Dizinlenme durumu” üzerinden sayfaların durumunu kontrol edin. Ayrıca site:{domain} /oda/{slug}/sayfa-2 ile sayfanın görünürlüğünü test edin.
4. Log analizi: Sunucu loglarında botların hangi endpoint’leri taradığını inceleyin. Örneğin sadece /oda/{slug} mi istiyorlar, yoksa /oda/{slug}/sayfa-n URL’lerine de ulaşıyorlar mı?

Bu kontrol seti, “AJAX ile gelen içerik indekslenmiyor” gibi sorunlarda hızlı teşhis sağlar. Özellikle HTML’de metin yoksa, crawler davranışını optimize etmek yerine içerik üretimini düzeltmek gerekir.

Yaygın Hatalar

Sonsuz scroll SEO uygulamalarında görülen hatalar genellikle üç grupta toplanır: içerik üretimi, URL/kanonik tutarsızlık ve crawl kontrolünün eksikliği. Aşağıdaki anti-pattern’ler doğrudan indekslenmeme veya sayfa patlaması doğurur.

• İlk HTML’de mesaj yerine yalnızca iskelet render: Botlar metin görmeden “zayıf içerik” ile karşılaşır.
• Cursor parametreli sınırsız URL üretimi: Kanonik veya pagination ile kontrol edilmezse aynı içerik farklı parametrelerle çoğalır.
• İlk yükte doğru metin var ama link yok: Botlar dilimler arası geçişi keşfedemez; sayfaların tamamı indekslenmez.
• noindex/nofollow’u yanlış kullanmak: “Sadece bazı sayfalar indekslenmesin” hedeflenirken yanlışlıkla ana sayfa sinyalleri de bozulabilir.

Bu hatalar gerçekleştiğinde “render edilsin mi edilmesin mi” tartışmasına saplanılır; oysa çoğu durumda kök neden, HTML’de içerik ve linklerin eksik olmasıdır.

FAQ

Google sonsuz scroll’u nasıl keşfeder ve indeksler?

Keşif için genellikle URL çeşitliliği ve linkler gerekir. Sonsuz scroll tamamen tek URL’de kalıyorsa botlar yeni içerik dilimlerini keşfetmekte zorlanır. Bu yüzden sohbet akışında botlara sayfa tabanlı alternatif (crawl-friendly pagination) sunmak ve ilk HTML’de anlamlı metin/link sağlamak gerekir.

Prerender ile SSR arasındaki fark sohbet sitelerinde ne zaman kritik olur?

Sürekli değişen mesajlar nedeniyle “tam SSR” her istek için maliyetli olabilir. Prerender/SSG ise belirli pencereleri daha verimli hale getirir. Kritik nokta, indekslenecek içerik penceresinin nasıl üretileceğidir: ilk N mesajı HTML’de vermek çoğu senaryoda net bir avantaj sağlar.

Cursor tabanlı sonsuz scroll SEO için uygun mu, nasıl kanoniklenmeli?

Uygun olabilir; ancak cursor parametreleri aynı içeriği farklı şekillerde temsil edebilir. Canonical stratejisi ile her dilimi tek bir “referans URL”e toplamak gerekir. Örneğin cursor varyantları yerine /sayfa-n gibi bir canonical referans belirleyin.

İlk yüklemede kaç mesajı HTML’de vermek gerekir?

Genel kural, HTML’de indekslenebilir ve kullanıcıya da anlamlı bir pencere sunmaktır. Başlangıç için 50-200 mesaj bandı sık tercih edilir; ancak mesaj uzunluğu, oda yoğunluğu ve crawl bütçesine göre ayarlanmalıdır. Çok yükseltmek performans/crawl maliyetini artırır.

AJAX ile gelen içerik için “view-source”/HTML doğrulaması nasıl yapılır?

Tarayıcıda sayfayı “view-source” ile inceleyin. İlk yükte metin bulunuyor mu? Metin yoksa içerik yalnızca client runtime ile oluşuyordur. Ayrıca mesajların bulunduğu DOM alanının HTML’de var olup olmadığına bakın; sadece API çağrıları yapılıp DOM’a sonradan basılıyorsa bot görünürlüğü zayıf kalabilir.

Search Console’da indekslenmeme nedenleri nasıl teşhis edilir?

Search Console’da sayfaların indekslenmeme nedenlerini (ör. “tarandı ama indekslenmedi”, “tarama hatası”, “kopya/farklı URL”) inceleyin. Ardından HTML doğrulaması, kanonik kontrolü ve URL keşif sinyallerini (linkler/sitemap) birlikte değerlendirin.

Log analizinde botların hangi endpoint’leri taradığını nasıl görürüm?

Sunucu loglarında kullanıcı aracısı (user-agent) ve bot IP/etiketleri ile istek yapılan path’leri filtreleyin. En çok talep edilen URL’ler ile taranan API/HTML endpointlerini karşılaştırın; botların /sayfa-n URL’lerine ulaşıp ulaşmadığını bu şekilde anlarsınız.

Çok büyük sohbetlerde crawl bütçesini nasıl yönetirim?

Mesaj başına değil, dilim başına indeksleme yapın. Oda başına maksimum pencere sayısı belirleyin, crawl-friendly pagination ile kontrollü URL üretin, cursor varyantlarını kanonik ile toplayın ve cache/TTL stratejisini kurun. Ayrıca “öncelikli odalar” için güncellemeyi hızlandırın.

İç bağlantılarla teknik çerçeveyi genişletin

Sonsuz scroll’un indekslenebilirliğine odaklanırken genel teknik SEO kontrol adımlarını da senkronize etmeniz gerekir. Bu nedenle ilgili rehberleri birlikte kullanın: Chat Sitelerinde Pagination (Sayfalama) ve Sonsuz Kaydırma için SEO En İyi Uygulamalari içeriği, “kullanıcı deneyimi + indekslenebilirlik” dengesini kurmanıza yardımcı olur.

Ayrıca uygulama sırasında crawl bütçesi/patlama sorunlarını yönetmek için Chat Sitelerinde Crawl Budget (Indexleme Bütçesi) Yönetimi: Sayfa Patlamasını Kontrol Etme Rehberi doğrudan operasyonel bir çerçeve sunar.

Sonuç: Sohbet akışında SEO’yu “indekslenebilir pencere”ye çevirin

Sohbet akışında sonsuz scroll kullanmak kullanıcı için harika bir deneyim olabilir; ancak arama motoru açısından içerik keşfedilebilir ve indekslenebilir olmalı. Bunun yolu, AJAX ile devam eden akışın yanında ilk HTML’de anlamlı metin/link üretmek ve crawl-friendly pagination veya prerender/SSR ile dilimler sunmaktır.

Doğru URL/kanonik stratejisi, crawl bütçesi yönetimi ve doğrulama adımları ile bu riski kontrol altına alırsınız. Hedefiniz büyüme ve sürdürülebilir keşif ise mimariyi “sonsuz” değil “indekslenebilir pencere” mantığıyla tasarlayın; ardından pencere boyutlarını ve yenileme sıklıklarını iteratif biçimde optimize edin.