Chat Sitesinde Paginasyon SEO: AJAX/Dinamik Yüklemede Crawl Edilebilir Sayfa Tasarımı Rehberi

Chat uygulamalarında “sohbet listesi” ve “konuşma arşivi” ekranları çoğu zaman AJAX ile akışkan biçimde güncellenir. Bu akıcılık iyi tasarlanmadığında, Google’ın sayfayı keşfetmesini ve özellikle içeriği render edip indekslemesini zorlaştırabilir. Bu rehberin ana odağı: chat sitesi için paginasyon SEO: dinamik yükleme ile crawl edilebilir sayfa tasarımı.

Buradaki hedef, infinite scroll veya SPA/AJAX kullanan ekiplerin “biz URL üretmiyoruz / HTML dinamik” gibi gerekçelerle kaybettiği paginasyon görünürlüğünü sistematik şekilde geri kazanmanızdır. Uygulanabilir mimari seçenekleri, kontrol adımlarını ve örnek URL/route/kanonik kurallarını birlikte göreceksiniz.

Kapsam ve problem tanımı: AJAX paginasyonunda neden crawl/indeks sorunu olur?

AJAX paginasyonunda sık karşılaşılan sorun şudur: kullanıcı sayfayı tarayıcıda sanki “tam dolu” görür, çünkü sohbet kartları istemci tarafında API’den çekilir. Ancak Googlebot bir URL’e geldiğinde, aldığı ilk HTML içinde bu kartlar olmayabilir; hatta veri erişimi bot için birebir aynı şekilde gerçekleşmeyebilir.

Crawl ve index ayrımı burada kritik hale gelir. Googlebot URL’i keşfedebilir; fakat sayfanın asıl içerik bölgesi render edilemezse index kalite sinyalleri zayıflar. Üstelik chat uygulamaları genellikle çok sayıda varyasyon üretir (sayfa/offset/cursor, filtreler, tarih aralığı). Kontrolsüz varyasyonlar hem crawl bütçesini dağıtır hem de kanonik sinyalleri parçalara böler.

Sonuç olarak, indekslenen sayfa sayısı artsa bile “doğru” sayfalar indekslenmeyebilir; ya da indekslenen sayfalar ince içerik/boş liste sinyali verdiği için değer kaybedebilir.

Terminoloji: sayfalama türleri (page=, offset, infinite scroll), crawl vs index

Chat listelerinde paginasyon üç ana biçimde karşımıza çıkar: page (ör. page=2 veya /page/2), offset (ör. offset=20), cursor (ör. cursor=abc). Infinite scroll ise çoğu zaman URL üretmez; yeni veriyi aynı URL altında yükler.

“Crawl” Google’ın URL’i bulması ve GET isteğini yapmasıdır. “Index” ise Google’ın bu URL’deki içerik kalitesini değerlendirip dizine almasıdır. Dinamik uygulamalarda esas problem çoğu zaman crawl değildir; indexi besleyen “render edilen içerik” tarafında çıkar.

Hedef sayfa mimarisi: her paginasyon için ayrı URL üretme ve state yönetimi

SEO açısından hedef, sayfalamanın durumunu URL’de temsil edebilmek olmalı. “Kullanıcı sayfa 2’dedir” gerçeği, hem tarayıcı hem crawler için karşılığı olan bir route ile ifade edilmelidir. Bu sayede Googlebot /chats/page/2 gibi bir URL’i çektiğinde, o URL’in “gerçek içeriğini” alır.

State yönetiminde iki katmanı birlikte düşünün: client state (tarayıcıdaki geçici seçimler) ve server-determined state (URL’den yeniden üretilebilen gerçek veri). Client state üzerine kurulan “yalnızca kullanıcı etkileşimiyle dolan” listeler bot için risklidir.

Bu yüzden hedef mimari şunu sağlar: URL → (SSR/pre-render veya fallback HTML) → sohbet listesi ve navigasyon bileşenleri.

Örnek URL tasarımı: /chats/page/2 vs /chats?cursor=abc (hangisi nasıl crawl edilir?)

Aşağıdaki iki yaklaşımı yan yana koymak, mimari kararlarınızı netleştirir.

1) Path tabanlı page: /chats/page/2 gibi URL’ler Googlebot için daha deterministik. Sunucu veya pre-render mekanizması bu URL’i aldığında listeyi HTML içinde üretebilir. Böylece “crawler’ın gördüğü şey” ile “kullanıcının gördüğü şey” arasındaki uyumsuzluk azalır.

2) Query cursor: /chats?cursor=abc ise “hangi kayıt aralığı” cursor ile tanımlanır. Cursor üretiminiz stabil değilse, bot farklı zamanlarda aynı cursor’ı kullanırken içerik değişebilir ya da cursor’lı sayfalar boş kalabilir. Ayrıca cursor’ı oluşturan mantık botun erişemediği bir şeye bağlıysa (auth, rate-limit, private API) render zinciri kırılır.

Googlebot dostu HTML üretimi yaklaşımları: SSR, pre-render, progressive enhancement, server fallback

AJAX ile dinamik yükleme kaçınılmaz olabilir; ama SEO tarafında kritik olan nokta şudur: sayfa ilk yüklemede “anlamlı HTML” içersin. Aşağıdaki yöntemlerden birini ya da kombinasyonunu düşünün:

• SSR: İlk istekte liste HTML’i üretilir. Genelde en tutarlı SEO sinyali budur.
• Pre-render: Uygulama katmanı (edge/server) bot isteğini tespit edip statik HTML üretir.
• Progressive enhancement: Temel içerik sunucuda vardır; client sadece “hızlandırılmış güncelleme” yapar.
• Server-side fallback: İstemcinin “shell” aldığı senaryolarda bile bot için aynı URL’den HTML dönen bir fallback route bulunur.

Buradaki amaç net: crawler render etmeye çalıştığında “boş bir container” değil, sohbet kartlarının bulunduğu bir DOM görmesi.

AJAX isteklerinin yönetimi: X-Requested-With, history API, gerekli durumlarda ayrı route tasarımı

Chat uygulamaları normal tarayıcı isteklerini farklı doğrular; örneğin X-Requested-With veya özel header bekleyebilir. Bot/renderer davranışı bazen farklı olduğundan, botun çağırdığı API boş yanıt döndürebilir.

Bu yüzden iki hedefiniz olsun: (1) HTML üretimi için botun erişebileceği route, (2) kullanıcı deneyimi için JSON/API route. Örneğin sayfa HTML’i için /chats/page/2, veri için /chats/api/page?cursor=xyz gibi net bir ayrım.

History API kullanıyorsanız (URL değiştirip içerik güncelliyorsanız) botun doğrudan URL’ye gittiğinde aynı listeyi göreceğini garanti etmelisiniz. Kullanıcıda sorunsuz çalışması yetmez; crawler’da “yanlış state” oluşmamalı.

History API ile AJAX paginasyon (kullanıcı tarafı) + server fallback route örneği

Kullanıcı tarafı örnek akış:

1) Kullanıcı “Sonraki”ye tıklar
2) Client: /chats/api/page?cursor=xyz çağırır
3) Gelen veriyi listeye basar
4) URL’yi history.pushState ile /chats/page/3 olarak günceller

Server tarafı garantisi:

GET /chats/page/3  -> sohbet listesi + navigasyon içeren HTML döner
GET /chats/api/page?cursor=xyz -> aynı liste verisini JSON olarak döner

Bu sayede Googlebot doğrudan /chats/page/3 ziyaret ettiğinde “veri render edilir” diye beklemek yerine, “liste HTML içinde hazır” şeklinde görür.

Crawl bütçesi ve performans: paginasyon derinliği, rate-limit, cache ve ETag

Chat sayfalama derinliği çok hızlı büyüyebilir. Crawl bütçesini doğru yönetmezseniz, bot anlamlı sayfalar yerine çok benzer veya düşük kalite varyasyonları tarayabilir. Bu durum hem indeks kalitesini hem de güncelleme hızını olumsuz etkiler.

Uygulamanızda şu politikaları düşünün: (1) sitemap veya internal link ile “ilk N sayfayı” güçlendirme, (2) derin sayfalarda 404/410 veya noindex, (3) sayfa/API response’larında kısa TTL + ETag ile gereksiz tekrarları azaltma.

Cache/ETag kullanırken dikkatli olun: chat verisi çok değişken ise “agresif cache” yanlış içerik riskini artırır. ETag ile fark bazlı dönüş yapmak hem performansı hem tutarlılığı daha iyi korur.

Kanonik etiket stratejisi: sayfa varyasyonları, sıralama parametreleri, filtre/arama ile etkileşim

Pagination SEO’da kanonik etiket, “hangi varyasyonun indeksleneceği” sorusunu yanıtlar. Chat listelerinde aynı içerik farklı URL’lerde üretilebilir: offset ile, page ile, cursor ile, filtre ile.

Kanonik etiket stratejisini “indekslenmesini istediğiniz temsilci URL” olarak kurgulayın. Temsilci URL’nin canonical’i, diğer varyasyonlara doğru şekilde yönlendirmelidir. Rastgele canonical üretmek index çakışmasına yol açabilir.

Kanonik örnekleri: aynı içeriğin farklı query parametrelerle üretilmesi senaryosu

Diyelim ki kullanıcı sıralamayı değiştiriyor ve aynı listeyi ürettiğini varsaydığımız bir durum var:

• /chats?page=2&sort=latest ile /chats?page=2&sort=timestamp aynı sonuçları döndürüyorsa, biri diğerine canonical olmalı.
• /chats?cursor=abc aynı aralığı veriyorsa ve indekslemek istediğiniz format /chats/page/2 ise cursor sayfasını o URL’e canonicalleyin.

Önemli detay: canonical hedefi ile sayfanın gerçekten render ettiği liste eşleşmiyorsa, Google bunu “yanlış sinyal” olarak değerlendirebilir.

Robots meta/noindex ve durum kodları: geçici sayfalar, 404/410 senaryoları

Sayfa numarası sınır aşıldığında (ör. /chats/page/9999) doğru HTTP durum kodu ile davranın. Noindex’i her problemde kullanmak yerine, geçersiz URL’lerde 404/410 kullanmak daha temiz bir sinyal oluşturur.

Geçici boşluk senaryosunda noindex düşünülebilir; fakat “boş kalma” süresi uzun sürerse tekrar değerlendirme yapmanız gerekir. 404/410 yerine noindex vermek, Google’ın URL’i tekrar tekrar taramasına ve crawl bütçesinin boşa harcanmasına neden olabilir.

Geçersiz/boş sayfa senaryosu: sayfa 9999 gibi durumlarda 404/410 vs noindex yaklaşımı

• Sayfa yok: /chats/page/9999 bulunamıyorsa 404 dönün. (Kalıcıysa 410 da düşünülebilir.)
• Sayfa geçmişte vardı ama silindi: Kalıcı kaldırma senaryosunda 410 tercih edebilirsiniz.
• İçerik geçici olarak boş: Örn. çok yeni oluşmuş ve “yakında dolacak”sa kısa süreli noindex uygulanabilir; ancak süreç sahipliği ve izleme şarttır.

İç linkleme ve anchor stratejisi: sohbet listeleri, sayfa sonu navigasyonu, menüler

Chat listesinde internal linkler, sayfa serileri arasında crawler ilerlemesini sağlar. “Önceki/sonraki” navigasyonu sadece kullanıcı tıklasın diye değil, HTML içinde link formunda sunulsun diye önemlidir.

Dinamik uygulamalarda sık yapılan hata: buton var ama href yok veya linkler yalnızca client-side event ile üretiliyor. Oysa crawler href üzerinden yolu takip eder. Bu nedenle server HTML’de gerçek anchor üretin.

İç linkleme örneği: “Önceki/sonraki sayfa” bileşeninin hem kullanıcı hem crawler için çalışması

Örnek yaklaşım:

• Sunucu: <a href="/chats/page/1" rel="prev">Önceki</a>
• Sunucu: <a href="/chats/page/3" rel="next">Sonraki</a>
• Client: kullanıcı tıklayınca içerik AJAX ile güncellense bile, linklerin href değeri korunur; history API sadece URL’yi aynı hedefe taşır.

Bu tasarım, kullanıcı akışını bozmadan crawler’ın “sayfalı keşif” yapmasına izin verir.

XML site haritası kurgusu: paginasyon URL’lerini dahil etme karar ağacı

Sitemap, tüm paginasyon URL’lerini taşımak için değil; önceliklendirmek için vardır. Chat listelerinde sayfa sayısı büyüyebildiğinden sitemap’e her varyasyonu koymak crawl bütçesini daha da dağıtabilir.

Karar ağacını şöyle kurgulayın: (1) URL indekslenmeye değer mi? (2) canonical tekil mi? (3) içerik kalitesi yeterli mi? (4) derinlik eşiğine ulaşıldı mı?

Genelde: ilk sayfalar + yüksek kalite filtre/arama varyasyonları + deterministik page/cursor karşılığı URL’ler sitemap’te yer alır.

Sayfa başına içerik benzersizliği: istek “boş” kalmamalı

Chat listelerinde en çok zarar veren şey “botun gördüğü sayfa iskeleti”dir. Başlıklar ve bölüm tasarımı var ama sohbet kartları bot için ilk yanıt içinde görünmüyorsa, Google bunu zayıf içerik olarak eşleştirebilir.

Bu yüzden paginasyon sayfasında minimum benzersiz içerik kuralını uygulayın: liste elemanları, sayfa kapsamını gösteren özet metin veya en az birkaç sohbet kartı.

İndekslenen her paginasyon URL’si, farklı içerik aralığını temsil etmelidir. Offset/page/cursor fark etmez; önemli olan HTML’de “sayfa farkını taşıyan veri”nin bot tarafından görülebilmesidir.

Structured data (varsa): sohbet/konuşma listeleri için uygun şema olup olmadığı ve dikkat noktaları

Structured data zorunlu değildir; ancak sayfanın “liste” türünde olduğunu anlamaya yardımcı olabilir. Chat arşivlerinde tam mesaj içeriğini schema ile taşımak doğru değildir; veri miktarı ve gizlilik nedeniyle riskli olabilir.

En iyi yaklaşım: liste öğelerini özetleyen ve gizlilik politikasıyla uyumlu alanlar kullanmaktır. Eğer structured data kullanacaksanız, her sayfa paginasyonu ile match eden bir kapsama sahip olmasına özellikle dikkat edin.

Yanlış kapsamlı markup, kanonik ve içerik tutarlılığını bozarak sinyalleri zayıflatır.

Görsel akışlar ve örnek şemalar: “Kullanıcı AJAX ile yükler / Google statik HTML alır”

Aşağıdaki akış, hedef mimariyi kavramsal şekilde özetler.

Kullanıcı:
1) GET /chats/page/2 (HTML iskeleti + temel içerik)
2) JS çalışır
3) AJAX: /chats/api/page?cursor=xyz
4) Liste güncellenir ve history.pushState ile URL korunur

Googlebot:
1) GET /chats/page/2
2) SSR/pre-render HTML alınır
3) DOM içinde sohbet kartları görünür
4) “Önceki/Sonraki” anchor’ları takip edilir
5) canonical ve sitemap sinyalleriyle varyasyon seçilir

Paginasyon SEO kontrol matrisi (URL, render, canonical, index)

Bu tablo, chat paginasyonlarında hangi durumda hangi kararı vermeniz gerektiğini hızlıca görmenizi sağlar. “Crawl edilebilir HTML” hedefi ile “doğru varyasyonun indekslenmesi” hedefi birlikte düşünülmelidir.

Senaryo	Örnek URL	HTML stratejisi	Canonical / Robots	HTTP durum
Klasik sayfalama, indekslenebilir	/chats/page/2	SSR veya pre-render ile sohbet kartlarını ilk HTML’de ver	Canonical kendisine	200 OK
Cursor ile eşdeğer ama temsilci değil	/chats?cursor=abc	Bot için de HTML üretecek fallback (tercihen temsilciye yönlendirme)	Canonical: /chats/page/2	200 OK
Geçersiz sayfa (çok derin)	/chats/page/9999	İçerik render etmeyin (boş shell yerine hata sayfası)	Canonical gerekmez; gerekiyorsa noindex ama önce 404/410	404 (kalıcıysa 410)

Yaygın hatalar

Paginasyon + dinamik yükleme kombinasyonunda ekiplerin en sık düştüğü hatalar, crawler render zincirini kıran veya indeks kalitesini düşüren hatalardır. Aşağıdakiler en problemli alanlardır.

• “Shell” HTML’i göndermek: Sayfa başlığı ve iskelet var ama sohbet kartları bot için ilk yanıt içinde yok. Bu durumda “render edemiyorum” sonucu ile ince içerik riski oluşur.
• History API var ama server fallback yok: Kullanıcı akışta çalışır; Googlebot URL’i direkt ziyaret ettiğinde farklı state veya boş veri görür.
• Sitemap’e her paginasyonu koymak: Crawl bütçesi dağılır, düşük kalite varyasyonlar taranır. Derin sayfalarda 404/410 veya noindex planı yoksa tablo daha da kötüleşir.
• Kanonik çakışması: page/offset/cursor/filtre varyasyonlarının hepsi aynı canonical’e gidiyor. Sonuç: Google tek bir URL’i seçer ve diğer sayfalar değer kaybeder.

Kontrol ve doğrulama adımları: URL Inspection, Fetch & Render, crawl log, test URL’leri

“Doğru yaptık” demeden önce, gördüğünüz şeyin Google’ın gördüğü şey olduğundan emin olmanız gerekir. Aşağıdaki doğrulama adımları pratik ve uygulanabilirdir.

1. URL Inspection: İndekslenmesini istediğiniz /chats/page/2 gibi URL’leri Google Search Console’da test edin; “canlı test” ile render edilmiş HTML’i kontrol edin.
2. Fetch & Render benzeri test: Botun görebileceği HTML’de sohbet liste öğeleri gerçekten DOM’da var mı, kontrol edin. Boş container mı oluşuyor?
3. Crawl log/erişim log: Bot hangi URL’leri çekiyor, API çağrısı yapıyor mu, hangi HTTP durumları görünüyor (403/404 oranı)? Özellikle noindex veya 404/410 doğru mu?
4. Test URL seti oluşturun: geçerli sayfalar (page 1-3), sınır sayfa, filtre varyasyonları ve /chats/page/9999 gibi geçersiz örnekleri ayrı ayrı test edin.

Bu kontrol seti, mühendislik ekibinin dinamik render zincirini SEO perspektifinden doğrulamasına yardımcı olur.

Paginasyon sayfalarında içerik kalitesi ve spam/gürültü etkisi

Chat sitelerinde UGC kalitesi, paginasyon sayfalarının “sayfa değeri” algısını etkiler. Eğer sayfa başına içerik az, tekrar fazla veya spam/gürültü yüksekse; teknik kısım doğru olsa bile index kalitesi düşebilir.

Bu yüzden paginasyon SEO mimarisini kurduktan sonra içerik kalitesini de yönetmeniz gerekir. Örneğin sohbet arşivlerinde hangi içeriklerin görünür kalacağı, hangilerinin filtreleneceği netleştirilmelidir; aksi halde bot her sayfayı tarar ama sayfalar düşük değer sinyali taşır.

Bu noktada ilgili yaklaşım için şu rehber yol gösterici olabilir: Chat Sitesi UGC Spam Tespiti ve Otomatik Filtreleme: Model Seçimi, Eşik Mantığı ve Raporlama Akışı.

İç linkleme hiyerarşisi: oda–kategori–etiket ve paginasyon

Chat uygulamalarında paginasyon sayfaları genellikle kategori/etiket sayfalarına bağlanır. Hiyerarşi net değilse crawler, paginasyon derinliğine ulaşmakta zorlanabilir. Bu yüzden internal linkleme sadece “önceki/sonraki” ile sınırlı olmamalıdır.

Odalar, kategoriler ve etiketler arasında tutarlı bir hiyerarşi kurduğunuzda paginasyon URL’leri daha hızlı keşfedilir. Bu konu için Chat Sitesi İç Linkleme Stratejisi: Oda–Kategori–Etiket Hiyerarşisi Nasıl Kurulur? rehberi, pratik bir çerçeve sunar.

Checklist ve uygulanabilir plan: 1-2-4 sprintlik yapılacaklar

Şimdi bu mimariyi “ürüne” dönüştürmek için sprint planına bağlayalım. Hedef, ilk sprintte crawler’a doğru HTML’i göstermek; ikinci sprintte kanonik/robots/sitemap kurallarını oturtmak; dördüncü sprintte doğrulama + performans optimizasyonu yapmak.

1. 1. Sprint (Temel): /chats/page/{n} gibi indekslenebilir URL şeması; HTML fallback route; “Önceki/Sonraki” anchor’larının server’da üretimi.
2. 2. Sprint (Kontrol sinyalleri): Kanonik etiket stratejisi; robots meta/noindex kararları; 404/410 politikası; sitemap dahil etme karar ağacı.
3. 4. Sprint (Doğrulama & performans): Render doğrulaması (URL Inspection), crawl log analizleri; cache/ETag; gerekiyorsa prerender/SSR maliyet optimizasyonu.

Bu plan, “çalışan SPA”dan “Google’ın gerçekten gördüğü sayfa”ya geçişi daha disiplinli hale getirir.

Sık Sorulan Sorular (FAQ)

Sonsuz scroll (infinite scroll) SEO için tamamen mi kötü? Ne zaman kurtarılabilir?

Infinite scroll tek başına otomatik olarak kötü değildir; ancak URL üretmezse crawl/indeks zayıflar. Kurtarılabilir senaryoda history API ile URL durumu değişir ve bot için SSR/pre-render veya server fallback sağlanır. Ayrıca görünür “sonraki sayfa” linkleri crawler’ın izleyebileceği bir iskelet oluşturur.

AJAX ile yeni içerik geldiğinde Google nasıl “render” ediyor, neyi görüyor?

Google render etmeye çalışır; fakat kritik içerik ilk HTML’de yoksa veya bot için API erişimi/başlıklar farklıysa eksik indeks oluşabilir. Bu yüzden liste öğelerini ilk yanıtın HTML’inde göstermek en güvenli yaklaşımdır; AJAX tarafı “sonraki iyileştirme” rolünü üstlenmelidir.

Cursor bazlı paginasyon (cursor=) crawl edilebilir mi, nasıl yapılmalı?

Evet, ancak cursor deterministik ve stabil olmalı; bot için eşdeğer HTML olarak sunulmalı. Cursor’lı sayfalar canonical ile temsilci URL’ye bağlanabilir. En önemlisi: SSR/pre-render ile HTML’de liste öğeleri görünür olmalıdır.

Kanonik etiket paginasyonlarda nasıl kullanılmalı (page parametresi/offset farkı)?

Temsilci URL formatını seçin (genelde /page/{n}) ve diğer formatları o temsilciye canonicalleyin. offset ile üretilen varyasyonlar aynı içerik aralığını veriyorsa temsilcinin canonical’ine hedeflenmelidir; aksi halde çakışma yaşanır.

Hangi sayfaları sitemap’e dahil etmeliyim (derinlik sınırı nasıl belirlenir)?

Sitemap’e indekslenmeye değer ve canonical’ı doğru olan URL’leri dahil edin. Derinlik sınırı için kalite sinyalleri, crawl log ve sayfa başına benzersiz içerik miktarına bakın. Pratikte ilk N (ör. ilk 100-1000) iyi bir başlangıçtır; sonrasında sürekli ölçümle ayarlayın.

Boş sonuç sayfaları indexlenmeli mi, noindex mi 404 mü?

Kalıcı yoksa 404/410 daha doğru. “Geçici boş” senaryosu kısa vadeli ise noindex düşünülebilir. Uzun süre boş kalacak sayfaları indexte tutmak yerine doğru durum kodu/karar politikası kurun.

Prerender/SSR yükü performansı nasıl etkiler, denge nasıl kurulur?

Performans maliyeti artabilir. Denge için sayfa başına liste öğelerini sınırlayın (ör. 20-50 kart), cache/ETag ile tekrarları azaltın. Prerender’ı tüm trafiğe değil, öncelikli crawler/arama trafiğine daraltmak maliyeti kontrol altında tutar.

Sayfalandırma yapan chat listelerinde içerik benzersizliği nasıl sağlanır?

Her sayfanın farklı kayıt aralığını deterministik sırayla göstermesi gerekir. Sayfa farkını HTML’de taşıyan minimum içerik (ör. en az birkaç sohbet kartı veya kapsam özetleri) bot için görünür olmalıdır. Skeleton’ı yalnızca kullanıcı akıcılığı için kullanın.