Chat’te Kullanıcının Beğenilenler/Cevaplar Sayfası Crawl Edilebilir mi? Dinamik Yükleme + Pagination Yerine Offset Planı

Chat sitelerinde kullanıcıya özel etkileşim sayfaları (beğenilenler/cevaplarım) çoğu zaman “dinamik yükleme” mantığıyla listeyi parça parça getirir. Peki chat sitesi kullanıcı etkileşim sayfalarında (beğenilenler/cevaplarım) dinamik yükleme crawl edilebilir mi? Pagination yerine ‘offset’ planı ne kadar gerçekçi? Asıl hedef, arama botlarının listeye erişmesini güvenli ve kontrol edilebilir bir şekilde sağlarken; aynı zamanda crawl bütçesini zorlamadan, varyant/duplicate riskini de düşürmek.

Bu rehber, özellikle “kullanıcı profiline bağlı etkileşim listeleri” için mimari kararları (SSR/Prerender, bot-safe endpoint, noindex/canonical) ele alacak; ardından pagination yerine offset tabanlı indekslenebilirlik planını adım adım anlatacaktır.

Kapsam ve terminoloji: dinamik yükleme, crawl edilebilirlik, pagination vs offset

Dinamik yükleme, kullanıcı sayfayı açtığında ilk anda kısa bir iskelet (shell) gösterip liste içeriğini sonrasında XHR/fetch/stream ile getirme yaklaşımıdır. Arayüz açısından hızlı görünür; ancak botlar çoğu zaman JavaScript çalıştırma maliyetine ve içerik zamanlamasına takılabilir. Sonuç: “Botun gördüğü” ile “kullanıcının gördüğü” aynı olmayabilir.

Crawl edilebilirlik ise botun URL’e erişip HTML yanıtını alması; sayfa içeriğini anlamlandırması ve devam linklerini (ör. sonraki sayfa) keşfetebilmesidir. Burada pagination yerine offset kullanmak, botun aynı mantıksal sırayı sayfalara bölmesini kolaylaştırır.

Pagination klasik olarak ?page=2 gibi bir şemaya dayanır. Fakat içerik sıralaması değişkense (ör. “latest” ve verinin sürekli yenilenmesi), page sayfaları aynı öğe aralığını her zaman temsil etmeyebilir. Offset ise ?offset=48&limit=24 gibi sayısal aralık mantığıyla daha deterministik bir erişim sunar; doğru tasarımla duplicate ve tutarsızlık azalır.

Kişisel etkileşim sayfaları neden farklı? (auth, varyantlar, erişim, kişiselleştirme)

Beğenilenler ve cevaplarım sayfaları çoğu uygulamada kimlik doğrulama gerektirir. Bu da işi doğrudan “botların erişimi” meselesine getirir: Auth kapısı varsa bot ya hiç içerik göremez ya da yanlış/kişisel veri görmeye çalışabilir.

Bir diğer kritik fark, varyant üretimidir: Aynı liste “sort=latest/top”, “filter=read/unread” veya cihaz/dil tercihlerine göre farklı HTML çıktısı üretebilir. Ayrıca kullanıcı etkileşimi zamanla değiştiği için liste “moving target” hâline gelir; crawl sırasında sayfa içeriği kayabilir.

Bu yüzden kişisel etkileşim sayfalarında hedef net olmalı: Botlar yalnızca izinli ve gerekli sürümü görsün. İndekslenmesi istenmeyen varyantlar (ör. auth gerektiren veya düşük değerli içerikler) noindex kalsın.

Risk haritası: crawl tuzakları (sonsuz scroll), duplicate/parameter varyantları, crawl bütçesi taşması, veri sızıntısı/robots uyumsuzluğu

Sonsuz scroll (infinite scroll) en yaygın tuzaklardan biridir. Botlar “scroll” yapmadığı için liste hiç dolmayabilir; dolsa bile devam istekleri kullanıcı etkileşimiyle tetiklendiğinden botun keşfetmesi zorlaşır. Bu durumda içerik “sayfa içinde” kalır ve discoverable olmaktan çıkar.

Duplicate/parameter varyantları offset/pagination tasarımında da karşımıza çıkar. Örneğin sort parametresi değiştiğinde ya da “limit” farklı olduğunda aynı öğeler farklı URL’lerle gelebilir. Bot aynı veri için farklı URL’leri tekrar tekrar tararsa crawl bütçesi gereksiz yere yanar.

Crawl bütçesi kişisel sayfalarda ayrıca kritiktir. Çok sayıda kullanıcı için etkileşim listeleri üretiliyorsa botlar “çok sayfalı keşif” yapar. Bu noktada rate limit, robots sinyalleri, noindex politikaları ve sayfa başına öğe sayısı gibi kontroller şarttır.

Son risk ise veri sızıntısı ve robots uyumsuzluğu. “Kişisel” içerik yanlışlıkla index alırsa veya auth kapısı yanlış yönetilirse kullanıcı verisi istemeden üçüncü taraflara açık hale gelebilir. Bu yüzden hem HTTP hem HTML sinyalleri birlikte ele alınmalıdır.

Bot erişimi için mimari seçenekler: (1) server-rendered liste, (2) prerender/SSR, (3) crawler-friendly API/HTML ara görünümü

Aynı üründe hem kullanıcıya iyi UX hem botlara iyi içerik sunmanın birkaç deseni var. Karar, sisteminizin gerçek zamanlılık ihtiyacına ve liste boyutuna göre şekillenir.

Üç yaygın yaklaşım:

1. Server-rendered liste: Kullanıcı oturumunda doğrulanan HTML içinde ilk N öğeyi (örn. 24) doğrudan render edin. Dinamik yükleme sadece sonraki offset blokları için çalışsın.
2. Prerender/SSR hibrit: İlk yükleme SSR olur, ardından client-side fetch ile devam edilir. Böylece Google ilk request’te içerik görür.
3. Crawler-friendly endpoint/HTML ara görünümü: Botlar için ayrı bir HTML “görüntüleme modu” (ör. ?_format=html-safe gibi) veya Accept header/izinli bot kimliğiyle farklı bir yanıt verin. Bot SAFE HTML, edit/JS gerektiren parçaları sadeleştirir.

Seçim yaparken “minimum görünür içerik” kriterini akılda tutun: Botun ilk HTML’de gördüğü liste öğeleri, tek tek mesaj kartları veya en azından erişilebilir linkler ve açıklayıcı metin olmalıdır. Aksi halde sayfa shell olarak kalır ve indeksleme için değer düşer.

“Pagination yerine offset planı” tasarımı: URL şeması, limit, sort sabitleme, tutarlılık (snapshot/ordering)

Offset planında amaç, botun her sayfada “aynı aralık” mantığıyla ilerlemesini sağlamak. Bu yüzden URL tasarımını baştan deterministik kurun: Her istekte offset, limit ve sort birlikte tanımlanmalı; mümkünse sort sıralaması sabitlenmelidir.

Örnek temel şema:

/u/{username}/likes?offset=0&limit=24&sort=latest

Sort sabitleme önerisi pratikte şu demek: Kullanıcı “latest” dediğinde liste, tarama boyunca aynı sıralama referansına göre ilerlemeli. Eğer tamamen “canlı” sıralıyorsanız bot tararken içerik kayabilir; bu da aynı öğenin iki offset aralığı arasında tekrar görülmesine yol açabilir.

İkinci örnek (sort “top” olduğunda):

/u/{username}/replies?offset=48&limit=24&sort=top

“Top” hesaplaması zamanla değişebileceği için mümkünse bir snapshot (örn. asof=2026-04-23T12:00Z ya da sürüm numarası) eklemek iyi sonuç verir. Alternatif olarak “offset tabanlı erişim”i canlı sıralamada yalnızca kullanıcı deneyimi için kullanıp botlar için sabit bir ordering üretmek daha güvenlidir.

Dinamik yükleme crawl edilebilir mi? Uygulama desenleri ve seçim koşulları

Dinamik yükleme tek başına “kötü” bir şey değildir. Kritik olan, botun göreceği çıktı ile client-only davranış arasındaki mesafedir. Eğer sayfa ilk HTML’de liste öğelerini hiç render etmiyorsa, dinamik yükleme bot açısından çoğunlukla çalışmaz.

Uygulamada şu desenleri kullanabilirsiniz:

• Progressive rendering: İlk request’te ilk limit kadar öğeyi HTML’e basın. Client, aynı endpoint’ten sonraki offset bloklarını alıp append etsin.
• Bot için prefetch: “İzinli bot” veya crawler-safe modunda server, ilk iki bloğu (örn. offset 0 ve 24) birleştirip tek sayfa olarak döndürsün. Böylece bot pagination/offset keşfi için daha az ek request yapar.
• AJAX yerine HTML ara görünüm: Tam JS uygulaması yerine bot-safe HTML’de öğe kartlarını sadeleştirin. Örneğin ?_format=html-safe ile script bağımlılıklarını azaltın.

“Hangi yaklaşım hangi koşulda seçilmeli?” sorusunun pratik cevabı: SSR/prerender en güvenlisi; crawler-friendly ara görünüm ise auth, izinli bot ve farklı rendering modlarına ihtiyaç duyduğunuzda daha esnek bir çözümdür.

Indexlenebilirlik stratejisi: hangi sayfalar index almalı, hangi bileşenler noindex/canonical almalı

Kişisel etkileşim listelerinde “tam index” her zaman doğru değildir. Promosyon değeri yüksek sayfalar (örn. kullanıcı profilinde gerçekten aranan bir içerik hiyerarşisi) index alabilir; buna karşılık düşük değerli veya hassas listeler noindex olmalıdır.

Genel kural yaklaşımı: URL parametre varyantları ve erişimi kısıtlı içerikler için ya canonical normalizasyonu ya da noindex gerekir. Örneğin sort=top ve sort=latest aynı öğeleri içeriyor olsa bile ayrı sayfalar farklı sıralama mantığıyla geldiğinden duplicate/kanonik karışıklık yaratabilir.

Özellikle auth gerektiren sayfalarda iki strateji düşünün: (1) “izinli bot” yaklaşımıyla botlara read-only bir görünüm sunmak ve noindex yerine gereken sinyalleri vermek, (2) tamamen noindex politikasıyla botun sadece kontrol amaçlı erişmesine izin vermek.

Auth gerektiren sayfalar için örnek politika: Etkileşim listesinin index alması istemiyorsanız response’ta X-Robots-Tag: noindex ve uygun canonical (veya canonical’ı hiç üretmeden tutarlı noindex) uygulayın. Eğer index alacaksa, bot SAFE HTML’de içerik stabil olmalıdır.

Crawl bütçesi ve performans: rate limit, caching, ETag/Last-Modified, sayfa başına öğe sayısı, log analiz planı

Offset planı doğru olsa bile bot sayfa başına çok fazla URL keşfedebilir. Bu yüzden crawl bütçesini hem backend performansı hem bot davranışıyla birlikte yönetmelisiniz.

Somut uygulama önerileri:

• Rate limiting: Kullanıcıya özel endpoint’lerde botlara daha düşük bant genişliği ayarlayın (IP/ASN bazlı, kullanıcı bazlı throttling de mümkün).
• Caching: İlk blok (offset 0) için kısa süreli cache (örn. 1-5 dk) ve varyantları kontrollü cache etme.
• ETag/Last-Modified: Aynı offset aralığı değişmediyse 304 dönerek gereksiz HTML transferini azaltın.
• Sayfa başına öğe sayısı: 25-30 aralığı çoğu kullanıcı listesinde iyi bir denge sağlar; 100’e çıkarmak HTML’i şişirir, 10’a düşürmek ise keşif sayısını artırır.

Log analiz planı: Bot kullanıcı ajanlarını ayırın, keşfedilen offset aralıklarını sayın, aynı kullanıcı için tekrar eden offset URL’leri tespit edin. Search Console tarafında indexlenen URL sayısı ile loglarda görülen istek sayısını karşılaştırın; sapma varsa canonical/noindex ya da keşif stratejisinde problem vardır.

A/B test değil veriyle doğrulama: Search Console + log data ile bot davranışı ölçümü

Bu tür SEO teknik kararları için “A/B test” çoğu zaman doğru yöntem değildir; botlar düzensiz ziyaret eder ve indeksleme geri bildirim döngüsü uzundur. Bunun yerine ölçüm-odaklı doğrulama yapın.

Adım adım doğrulama yaklaşımı (en az 3 adım):

1. Ön test: Uygulamada crawler-safe HTML modunu açın, offset 0 ve offset 24 URL’lerini bir test kullanıcıyla üretin. Her bir URL için istenen HTML’in bot-safe içerik içerdiğini kontrol edin.
2. Bot simülasyonu: Uygun bir Googlebot simülasyon aracı veya staging ortamında benzer user-agent ile fetch alıp DOM içinde liste öğesi var mı inceleyin. (Sadece “500ms sonra JS tamamlandı” kabul etmeyin; ilk HTML’de görünen metin olsun.)
3. Gözlem: İndekslemenin gerçekleştiği süre boyunca Search Console’da ilgili örnek URL’lerin “Google tarafından keşfedildi ama şu sebeple indexlenmedi” benzeri durumlarını takip edin. Aynı anda server log’larında botun hangi offset URL’lerini taradığını karşılaştırın.

Bu üç adımın sonunda, “dinamik yükleme crawl edilebilir mi?” sorusuna pratikte net bir cevap verebilirsiniz: Botun gördüğü ilk HTML’de liste var mı, offset aralıkları keşfediliyor mu, duplicate üretiyor musunuz?

Somut örnek URL şemaları ve karşılaştırma tablosu (pagination vs offset)

Aşağıdaki şema örnekleri, offset tabanlı tasarımın “daha deterministik” olabileceğini gösterir. Ayrıca canonical ve parametre normalizasyonuyla duplicate riskini azaltmayı hedefler.

Kriter	Pagination ile	Offset ile
Sıralama değişirse tutarlılık	?page=2 “aynı öğe aralığı” olmayabilir	?offset=24 doğru ordering ile daha stabil ilerler
Duplicate riskini yönetme	Sayfa numarası ile varyantların etkisi artabilir	sort/limit sabitlenirse canonical daha kolay normalize edilir

Duplicate riskini azaltmak için örnek yaklaşım: Botun aynı listeyi farklı parametre setleriyle görmesini engellemek amacıyla parametre normalizasyonu yapın. Örneğin limit’i tek bir değere sabitleyip diğer limit varyantlarını redirect veya canonical ile tek sürüme toplayın. Aynı zamanda canonical üretimini offset’e göre “standart aralık” mantığıyla düzenleyin.

URL şablon örnekleri:

/u/{username}/likes?offset=0&limit=24&sort=latest

/u/{username}/replies?offset=48&limit=24&sort=top

Bot için crawler-friendly HTML ara görünümü örneği: /u/{username}/likes?offset=0&limit=24&sort=latest&_format=html-safe. Bu modda gereksiz bileşenleri kaldırıp liste öğelerini metin olarak daha görünür kılın.

Yaygın hatalar: Sonsuz scroll, canonical karmaşası ve bot-safe HTML yokluğu

Sonsuz scroll’u sadece client-side’a bırakmak en sık hatadır. Bot listeyi göremediğinde, offset/pagination planınız olsa bile keşif ve indeksleme beklediğiniz gibi ilerlemez. Çözüm: İlk HTML’de en azından ilk limit öğeyi render etmek veya crawler-safe HTML modu sunmak.

Canonical’ı yanlış üretmek bir başka hatadır. Örneğin sort değiştiğinde hepsini aynı canonical’e çekerseniz, Google hangi sıralamayı temsil ettiğini anlayamayabilir. Tam tersi senaryo da mümkün: Her parametre farklı index üretirse duplicate şişer. Canonical politikanızı “indexlemek istediğiniz kanonik sıralama”ya göre tasarlayın.

Auth gerektiren sayfalarda robots uyumsuzluğu da ciddi bir risktir. Sayfada noindex isteseniz bile yanlış yönlendirmeler veya canonical yanlışlığı hassas içerik sızıntısına yol açabilir. Bu yüzden auth + bot-safe + noindex/canonical birlikte düşünülmelidir.

Uygulama kontrol listesi (yayına almadan önce)

Bu bölüm, “yayına almadan önce” doğrulamanızı hızlandırmak için pratik bir checklist’tir. Burada amaç, crawl edilebilirliği ve crawl bütçesini aynı anda garanti altına almak.

1. İlk HTML kontrolü: offset=0 URL’ini bot-safe modda açtığınızda liste öğeleri DOM içinde var mı? (Sadece placeholder olmamalı.)
2. URL normalizasyonu: limit, sort gibi parametreler normalize ediliyor mu? Duplicate üretmeyi azaltmak için canonical/redirect tutarlı mı?
3. Snapshot/tutarlılık: “top/popüler” gibi zamanla değişen sıralamalarda snapshot veya ordering sabitleme planınız var mı?
4. Robots ve X-Robots-Tag: Index almasını istemediğiniz sayfalar noindex mi? İstediğiniz sayfalar için canonical doğru mu?
5. Crawl bütçesi: rate limit, sayfa başına öğe sayısı ve cache/ETag stratejiniz hazır mı?
6. Ölçüm planı: Search Console ve log data ile “keşfedildi/indeks” ayrımını takip edecek metrikler tanımlı mı?

Ek olarak, UI varyantları varsa canonical/hreflang veya varyant politikası gibi konuları da ayrıca ele almanız gerekir. Bu makaledeki offset planı, aynı zamanda varyantların doğru tekilleştirilmesiyle güçlenir.

İç link odakları (yakın konular)

Eğer chat’te bot-safe HTML yaklaşımını bir adım ileri götürmek isterseniz şu rehber “uygulama testi checklist’i” açısından yardımcı olabilir: WebSocket + SSR Hibrit Chat’lerde Bot-Safe HTML Doğrulama: Googlebot Simülasyon Test Checklist’i.

UI durumuna göre içerik varyantı üreten akışlar (ör. “mute/gizle” sonrası farklı mesaj görünümü) indexlenme davranışını etkileyebilir; bunun için UI durumuna göre içerik varyantı politikası bakış açısını da ekleyin.

Nasıl kontrol edilir? Adım adım doğrulama (minimum teknik şartlar)

“Dinamik yüklenen içerikte Google’ın görmesini garanti etmek” için minimum şartları pratik bir doğrulama akışına bağlamak gerekir. Aşağıdaki kontrol adımları, hem erişimi hem içerik görünürlüğünü birlikte test eder.

1. HTML fetch doğrulaması: offset=0 URL’ini bot-safe modla çağırın; dönen HTML içinde liste öğelerinin metni (başlık/izah, linkler) görünür durumda mı?
2. Keşif doğrulaması: Sayfa içinde “sonraki offset” linkleri var mı ve bu linkler bot-safe durumda href olarak render ediliyor mu?
3. İndeks doğrulaması: Search Console’da aynı URL için “Google’ın gördüğü içerik” ile beklenen liste eşleşiyor mu? Loglarda aynı URL’lerin tekrar eden taramaları var mı?

Bu doğrulama, pagination yerine offset planınızın sadece “tasarım kararı” değil, gerçek crawl davranışına dönüştüğünü gösterir.

SSS

Kullanıcıya özel sayfaları botlar görebilir mi? Auth duvarını nasıl yönetmeliyim? Erişim gerektiriyorsa ya izinli bot yaklaşımıyla read-only, güvenli bir görünüm verin ya da bu sayfaları tamamen noindex yapın. En kritik nokta: botların gördüğü HTML’de kişisel veri sızıntısı olmaması ve robots/noindex sinyallerinin tutarlı olmasıdır.

İndekslemek istemediğim kişisel liste sayfalarını nasıl noindex ederim (canonical ile birlikte)? İlgili endpoint’lerde X-Robots-Tag: noindex veya meta robots noindex kullanın. Canonical’ı “indexlenmesini istemediğiniz” sayfalarda ya kapatın ya da yalnızca tek ve tutarlı bir referans URL’ye normalize edin; karışık canonical’lar indeks dalgalanması yaratabilir.

Offset URL’leri sıralama değiştikçe (popüler/son) duplicate üretir mi? Snapshot nasıl sağlanır? Evet, sıralama değişkense aynı offset aralığı farklı öğelerle dolabilir. Snapshot eklemek (örn. asof parametresi veya ordering_version) veya botlar için sabit ordering üretmek duplicate ve “tutarsız sayfa içeriği” riskini azaltır.

Sonsuz scroll yerine offset kullanmak SEO’da zorunlu mu? Hangisi daha iyi? Zorunlu değil; ancak SEO hedefliyorsanız offset/pagination benzeri keşif linkleri botun devam sayfalarını öğrenmesini kolaylaştırır. Sonsuz scroll sadece client-side’a dayanıyorsa kırılgan olur. Pratik olarak: İlk blok HTML’de, sonraki bloklar offset linklerle keşfedilebilir olmalı.

Dinamik yüklenen içerikte Google’ın görmesini garanti etmek için hangi minimum teknik şartlar var? İlk HTML’de liste öğelerinin metnini göstermek, bot-safe modda JS bağımlılığını azaltmak, keşif için href tabanlı offset linkleri sağlamak ve noindex/canonical/robots sinyallerini tutarlı kullanmak gerekir.

Crawl bütçesi taşarsa ne yapmalıyım (limit, rate, sayfa sayısı, robots)? Botlara rate limit uygulayın, sayfa başına öğe sayısını optimize edin, gereksiz parametre varyantlarını normalize edin ve indexlenmemesi gereken kullanıcı listelerinde noindex politikasını sertleştirin. Ayrıca robots sinyalleri ve keşif linklerinin sayısını kontrol edin.

Sayfa başına öğe sayısını kaç almalıyım (25/50/100) ve bunun etkisi nedir? 25-30 genellikle iyi bir başlangıçtır: HTML boyutu yönetilir, botun daha az request atması sağlanır. 50-100 bazen kabul edilebilir ama sayfa ağırlığı artar; 10 gibi düşük değerler ise daha fazla offset URL üretip crawl bütçesini tüketebilir.