Sonsuz Kaydırma (Infinite Scroll) mu, Sayfalama (Pagination) mı? SEO ve Kullanıcı Deneyimi Rehberi

Bir blogun arşivini, bir e-ticaret sitesinin kategori sayfasını veya bir haber sitesinin akışını düşünün. Yüzlerce, bazen binlerce içerik tek bir listede sunulmak zorunda. Bu listeyi kullanıcıya nasıl göstereceğiniz, ilk bakışta bir tasarım tercihi gibi görünür; oysa hem kullanıcı deneyimini hem de arama motorlarının içeriklerinizi bulup bulamayacağını doğrudan belirler.

Üç temel seçenek vardır: sayfalama (pagination), sonsuz kaydırma (infinite scroll) ve ikisinin arasında duran “Daha fazla yükle” düğmesi. Bu yazıda üçünün nasıl çalıştığını, Google’ın bu yapıları nasıl taradığını, hangi durumda hangisinin seçilmesi gerektiğini ve sonsuz kaydırmayı SEO uyumlu hâle getirmenin teknik adımlarını ele alıyoruz.

Sayfalama (pagination) nedir?

Sayfalama, uzun bir içerik listesini belirli sayıda öğe içeren ayrı sayfalara bölme yöntemidir. Kullanıcı listenin sonuna geldiğinde “Sonraki”, “2”, “3” gibi bağlantılarla bir sonraki sayfaya geçer. Her sayfanın kendine ait bir adresi vardır: /blog/, /blog/page/2/, /kategori?page=3 gibi.

Sayfalama web’in en eski ve en öngörülebilir liste yöntemidir. Arama sonuçları sayfaları, e-ticaret kategorileri, forumlar ve blog arşivleri uzun yıllar bu yöntemle çalıştı; bugün de pek çok sitede varsayılan yöntemdir. Bu blogun arşivi de sayfalama ile çalışır: her sayfanın kendi adresi, kendi başlığı (“Blog – Sayfa 2” gibi) ve kendine işaret eden canonical etiketi vardır.

Sonsuz kaydırma (infinite scroll) nedir?

Sonsuz kaydırma, kullanıcı sayfanın sonuna yaklaştıkça yeni içeriklerin otomatik olarak yüklendiği ve mevcut listenin altına eklendiği yöntemdir. Kullanıcı hiçbir düğmeye tıklamaz; kaydırmaya devam ettiği sürece içerik gelmeye devam eder. Sayfa yenilenmez, adres çoğu zaman değişmez.

Yöntem 2006’da tasarımcı Aza Raskin tarafından geliştirildi ve 2010’larda sosyal medya platformlarıyla yaygınlaştı. Instagram, TikTok, X, Facebook ve Pinterest akışları, sonsuz kaydırmanın en bilinen örnekleridir. Raskin’in yıllar sonra bu buluşun ekran başında geçirilen süreyi artırmadaki rolünden duyduğu pişmanlığı dile getirmesi, yöntemin ne kadar güçlü bir etkileşim aracı olduğunu da gösterir.

Sonsuz kaydırma nasıl çalışır?

1. Algılama: Tarayıcı, kullanıcının listenin sonuna yaklaştığını algılar. Modern uygulamalarda bu, listenin sonuna yerleştirilen görünmez bir öğenin ekrana girdiğini izleyen IntersectionObserver ile yapılır.
2. İstek: JavaScript, sunucudan bir sonraki içerik grubunu ister (genellikle bir API çağrısıyla).
3. Ekleme: Gelen içerik mevcut listenin altına eklenir; kullanıcı kaydırmaya devam eder.
4. (İdeal olarak) Adres güncelleme: SEO uyumlu uygulamalarda, kullanıcı yeni bir içerik grubuna geçtiğinde adres çubuğu o gruba karşılık gelen sayfa adresiyle güncellenir. Bu adımı birazdan ayrıntılı ele alacağız.

“Daha fazla yükle” düğmesi nedir?

“Daha fazla yükle” (load more) düğmesi iki yöntemin melezidir. İlk içerik grubu sayfada görünür; kullanıcı listenin sonuna geldiğinde bir düğmeye tıklayarak yeni içerikleri aynı sayfaya ekler. Sonsuz kaydırmanın kesintisiz akışını korur, ama kontrolü kullanıcıya verir. Sayfa sonundaki bilgilere (footer) erişim sorunu ortadan kalkar; kullanıcı istemediği sürece sayfa uzamaz.

Bazı siteler iki yöntemi birleştirir: ilk iki-üç grup otomatik yüklenir, ardından “Daha fazla yükle” düğmesi çıkar. Bu, kısa göz atmalarda kesintisiz deneyim sunarken sayfanın kontrolsüz uzamasını engeller.

Karşılaştırma: sayfalama, sonsuz kaydırma ve “Daha fazla yükle”

Google sayfalama ve sonsuz kaydırmayı nasıl tarar?

Doğru yöntemi seçmeden önce Googlebot’un bir sayfayı nasıl işlediğini anlamak gerekir. Googlebot sayfaları JavaScript çalıştırarak işleyebilir; ancak bir kullanıcı gibi davranmaz. Sayfayı aşağı kaydırıp yeni içeriğin yüklenmesini beklemez, “Daha fazla yükle” düğmesine tıklamaz. Sayfayı yükler, işler ve sayfadaki <a href> bağlantılarını takip eder.

Bunun pratik sonucu çok nettir: yalnızca kaydırma veya tıklama ile yüklenen içerik, Google için büyük olasılıkla görünmezdir. Bir kategori sayfasında 500 ürün varsa ve bunların yalnızca ilk 24’ü ilk yüklemede geliyorsa, kalan 476 ürüne başka bir bağlantı yolu yoksa Google onları bu sayfa üzerinden keşfedemez. Ürün sayfaları başka yollarla (site haritası, iç bağlantılar) bulunsa bile, kategori sayfasının bu ürünlere verdiği bağlantı değeri kaybolur.

Google’ın resmî yönergelerinin özü şudur: listedeki her içerik grubu, kendine ait bir adrese sahip olmalı ve bu adreslere normal HTML bağlantılarıyla ulaşılabilmelidir. Sonsuz kaydırma kullanıcıya sunulabilir; ama arka planda arama motorunun takip edebileceği bir sayfalama yapısı bulunmalıdır.

rel="next" ve rel="prev" artık kullanılmıyor

Uzun yıllar boyunca sayfalı serileri Google’a tanıtmanın standart yolu, sayfanın <head> bölümüne eklenen rel="next" ve rel="prev" etiketleriydi. Google, 2019’da bu etiketleri uzun süredir dizine ekleme sinyali olarak kullanmadığını açıkladı. Yani bugün bu etiketleri eklemek Google açısından bir fayda sağlamaz; Google sayfalı seriyi sayfalar arasındaki normal bağlantılardan anlar.

Bu, etiketleri silmeniz gerektiği anlamına gelmez. Zararları yoktur; Bing gibi başka arama motorları ve bazı tarayıcı özellikleri hâlâ yararlanabilir. Ama sayfalamanın SEO’su artık bu etiketlere değil, sayfalar arasındaki gerçek bağlantılara ve her sayfanın doğru işaretlenmesine dayanır.

SEO uyumlu sayfalama nasıl kurulur?

1. Her sayfaya benzersiz bir adres verin

Her sayfa kendi adresine sahip olmalıdır: /kategori/?page=2 veya /kategori/page/2/. Sayfa numarasını # işaretinden sonra taşıyan adresler (/kategori#page=2) kullanılmamalıdır; Google # sonrasını ayrı bir adres olarak görmez ve bu sayfaları taramaz.

2. Sayfaları normal bağlantılarla birbirine bağlayın

Her sayfadan bir sonraki sayfaya, gerekiyorsa önceki sayfaya ve ilk sayfaya <a href> ile bağlantı verin. Yalnızca JavaScript olayıyla çalışan düğmeler (onclick) arama motoru için bağlantı değildir.

Uzun serilerde yalnızca “Sonraki” bağlantısı vermek, 40. sayfadaki içeriğe ulaşmak için 40 adım gerektirir. Sayfa numaralarını (1, 2, 3 … 10, 20, 40) göstermek, derin sayfalara giden yolu kısaltır ve tarama derinliğini azaltır.

3. Her sayfa kendine canonical vermeli

En yaygın sayfalama hatası, 2., 3. ve sonraki sayfaların canonical etiketini ilk sayfaya yönlendirmektir. Bu, Google’a “bu sayfalar ilk sayfanın kopyasıdır” demektir; oysa değildir, her biri farklı ürünler veya yazılar listeler. Sonuç olarak Google derin sayfalardaki içeriklere daha az önem verebilir. Doğru uygulama, her sayfanın kendi adresine canonical vermesidir. Canonical mantığını canonical URL rehberimizde ayrıntılı anlattık.

Tek istisna, tüm içeriği tek sayfada gösteren bir “Tümünü göster” sayfanız varsa ve bu sayfa makul hızda yükleniyorsa, sayfalı serinin bu sayfaya canonical vermesidir. Ancak yüzlerce ürünlü kategorilerde bu sayfa ağır olacağı için genellikle uygun değildir.

4. Sayfa 2 ve sonrasını noindex yapmayın

Bazı siteler, “ince içerik” kaygısıyla 2. ve sonraki sayfalara noindex ekler. Bu, kısa vadede zararsız görünse de uzun vadede sorun yaratır: Google uzun süre noindex kalan sayfalardaki bağlantıları da zamanla takip etmeyi bırakabilir. Böylece derin sayfalardan bağlantı alan ürün veya yazılar keşfedilmez hâle gelir. Sayfalı sayfaların dizinde olması bir sorun değildir; Google zaten kullanıcıyı genellikle ilk sayfaya veya doğrudan içeriğe gönderir.

5. Başlık ve açıklamada sayfa numarasını belirtin

Aynı başlığı taşıyan onlarca sayfa, Search Console’da kopya başlık uyarılarına ve kullanıcı için belirsizliğe yol açar. “Blog – Sayfa 2” gibi başlıklar, sayfaların birbirinden ayırt edilmesini sağlar. Kategori açıklama metni gibi tanıtım içeriklerini ise yalnızca ilk sayfada göstermek, sayfalar arasında tekrar eden metni azaltır.

6. Filtre ve sıralama adreslerini kontrol altında tutun

E-ticaret sitelerinde sayfalama, filtre ve sıralama parametreleriyle birleşince (?renk=mavi&sirala=fiyat&page=3) binlerce adres varyasyonu ortaya çıkar. Bu varyasyonlar tarama bütçesini tüketir. Sıralama varyasyonları için canonical, değer taşımayan filtre kombinasyonları için robots.txt veya noindex gibi yöntemlerle dizine eklenecek adresleri sınırlamak gerekir. E-ticaret tarafındaki ayrıntıları e-ticaret SEO rehberimizde ele aldık.

SEO uyumlu sonsuz kaydırma nasıl yapılır?

Sonsuz kaydırmayı arama motorlarıyla uyumlu hâle getirmenin yolu, onu sayfalamanın üzerine kurmaktır. Google’ın bu konuda önerdiği yaklaşım, “bileşen sayfaları” (component pages) mantığına dayanır.

Adım 1: Önce çalışan bir sayfalama kurun

Listeyi, her biri kendi adresine sahip sayfalara bölün: ?page=1, ?page=2, ?page=3. Her sayfa, JavaScript olmadan açıldığında da yalnızca kendi içerik grubunu göstermeli ve sonraki sayfaya normal bir bağlantı içermelidir. Bu sayfalar, arama motorunun gördüğü yapıdır.

Adım 2: Sonsuz kaydırmayı bunun üzerine ekleyin

JavaScript çalıştığında, kullanıcı listenin sonuna geldiğinde bir sonraki sayfanın içeriği aynı adres yapısından çekilip listeye eklenir. Sayfa altındaki “Sonraki sayfa” bağlantısı JavaScript ile gizlenebilir; ancak HTML’de bulunmaya devam etmelidir.

Adım 3: Kaydırdıkça adresi güncelleyin

Kullanıcı yeni bir içerik grubuna geçtiğinde, tarayıcının History API’si ile adres çubuğu o gruba karşılık gelen sayfa adresiyle güncellenir. Kaydırma sırasında adresi değiştirmek için genellikle history.replaceState() tercih edilir; bu yöntem tarayıcı geçmişine yeni kayıt eklemez, böylece “Geri” tuşu kullanıcıyı onlarca ara sayfada gezdirmez. Kullanıcının bilinçli bir eylemiyle (örneğin “Daha fazla yükle” düğmesi) yeni bir gruba geçildiğinde history.pushState() kullanılabilir.

Bu adım iki sorunu birden çözer: kullanıcı o an baktığı noktayı paylaşabilir veya yer imine ekleyebilir; sayfayı yenilediğinde de baştan değil, kaldığı gruptan başlar.

Adım 4: Her bileşen sayfasının doğrudan açılabildiğinden emin olun

Birisi ?page=5 adresini doğrudan açtığında, sayfa 5. grubun içeriğini göstermeli ve gerekirse yukarı doğru önceki grupları yükleme imkânı sunmalıdır. Bu adres boş bir sayfa veya ilk sayfanın içeriğini gösteriyorsa yapı bozuktur.

Adım 5: Test edin

• JavaScript kapalı test: Tarayıcıda JavaScript’i kapatıp listeyi açın. Sonraki sayfalara normal bağlantılarla ulaşabiliyor musunuz?
• URL denetimi: Search Console’daki URL Denetimi aracıyla derin bir sayfayı (örneğin ?page=5) canlı test edin; oluşturulan HTML’de o sayfanın içerikleri görünüyor mu?
• Tarayıcı araçları: Screaming Frog gibi bir tarama aracıyla siteyi taratıp derin sayfalardaki içeriklerin bulunup bulunmadığını ve tarama derinliğini kontrol edin.
• Adres güncelleme: Kaydırırken adres çubuğunun değiştiğini, sayfayı yenileyince doğru gruptan başladığını ve “Geri” tuşunun beklendiği gibi çalıştığını doğrulayın.

Kullanıcı deneyimi açısından hangisi daha iyi?

Kullanıcı deneyimi araştırmalarının ortak sonucu şudur: doğru yöntem, kullanıcının o sayfada ne yapmaya çalıştığına bağlıdır.

Keşif odaklı deneyimler: sonsuz kaydırma

Kullanıcının belirli bir şey aramadığı, sadece göz attığı ve bir sonraki içeriğin öncekiyle eşit önemde olduğu akışlarda sonsuz kaydırma iyi çalışır. Sosyal medya akışları, görsel keşif platformları ve kısa video akışları bunun tipik örnekleridir. Bu deneyimlerde her sayfa geçişi, kullanıcının akıştan kopması için bir fırsattır; sonsuz kaydırma bu kopuşu ortadan kaldırır.

Hedef odaklı deneyimler: sayfalama

Kullanıcının belirli bir ürünü, yazıyı veya bilgiyi aradığı; seçenekleri karşılaştırdığı ve bir sonuca varmaya çalıştığı sayfalarda sayfalama daha iyi sonuç verir. Arama sonuçları, ürün karşılaştırma listeleri ve arşivler bu gruba girer. Sayfalama kullanıcıya bir konum hissi verir: “Beğendiğim ürün 3. sayfadaydı” diyebilmek, geri dönüp bulmayı kolaylaştırır. Sonsuz bir listede ise aynı ürünü yeniden bulmak için baştan kaydırmak gerekir.

E-ticaret listeleri: “Daha fazla yükle”

Baymard Institute’un e-ticaret kullanılabilirlik araştırmaları, ürün listelerinde “Daha fazla yükle” düğmesinin (ilk grupların otomatik yüklenmesiyle birlikte) çoğu durumda hem klasik sayfalamadan hem de saf sonsuz kaydırmadan daha iyi sonuç verdiğini gösteriyor. Kullanıcılar sayfa geçişi beklemeden daha fazla ürün görüyor, ama listenin sonunu ve footer’ı da görebiliyor. Mobilde bu fark daha belirgindir; küçük ekranda sayfa numaralarına dokunmak zordur.

Sonsuz kaydırmanın kullanıcı deneyimi sorunları ve çözümleri

Footer’a ulaşılamaması

Sayfa sürekli uzadığı için kullanıcı footer’daki iletişim, iade politikası, kariyer gibi bağlantılara bir türlü ulaşamaz. Footer tam görünecekken yeni içerik yüklenir ve footer yeniden aşağı kayar. Çözümler: otomatik yüklemeyi birkaç grupla sınırlayıp ardından düğme göstermek, kritik bağlantıları üst menüye veya sabit bir alana taşımak.

Geri dönüşte konum kaybı

Kullanıcı sonsuz listede 80. ürüne kadar kaydırır, ürüne tıklar, sonra “Geri” tuşuna basar ve kendini listenin en başında bulur. Bu, sonsuz kaydırmanın en sinir bozucu sorunlarından biridir. Çözüm için liste durumu (yüklenen gruplar ve kaydırma konumu) saklanmalı, geri dönüşte yeniden kurulmalıdır. Tarayıcının geri-ileri önbelleği (bfcache) sayfayı olduğu gibi saklayabildiğinde sorun kendiliğinden çözülür; bu yüzden bfcache’i engelleyen kodlardan (örneğin unload olay dinleyicileri) kaçınmak da önemlidir. Adresin kaydırmayla güncellenmesi de burada yardımcı olur.

Bitmeyen liste hissi ve karar yorgunluğu

Sonu görünmeyen bir liste, özellikle karar verilmesi gereken durumlarda kullanıcıyı yorar. Listenin kaç öğe içerdiğini göstermek (“240 ürün”), kullanıcıya ne kadar yolu kaldığını hissettirir.

Kaydırma çubuğunun anlamını yitirmesi

Kaydırma çubuğu normalde sayfanın ne kadarının okunduğunu gösterir. Sonsuz listede çubuk her yüklemede zıplar ve bu bilgi kaybolur.

Performans ve Core Web Vitals etkileri

Sonsuz kaydırma ve “Daha fazla yükle”, performans açısından dikkat gerektirir. Core Web Vitals metriklerinin üçü de etkilenebilir:

• CLS (düzen kayması): Yeni içerik için yer ayrılmadan ekleme yapılırsa veya görsellerin boyutları tanımlanmazsa sayfa zıplar. Kullanıcı etkileşiminden sonraki kısa süre içinde oluşan kaymalar CLS’e sayılmaz; ama otomatik yüklemeler kullanıcı eylemi sayılmadığı için sayılır. İskelet yer tutucular ve sabit görsel boyutları bu riski azaltır. Ayrıntılar için CLS rehberimize bakabilirsiniz.
• INP (etkileşime yanıt): Liste büyüdükçe sayfadaki HTML öğesi sayısı (DOM) binlere çıkar. Büyük DOM, her etkileşimde tarayıcının yapması gereken işi artırır ve yanıt süresini uzatır. Ekran dışına çıkan öğeleri DOM’dan çıkarıp gerektiğinde yeniden ekleyen liste sanallaştırma (virtualization) bu sorunu çözer. CSS’in content-visibility: auto özelliği de ekran dışındaki öğelerin işlenmesini erteler.
• LCP (en büyük içerik): İlk yüklemede gelen içerik grubu makul boyutta tutulmalı; ekranın üst kısmındaki görseller geç yüklenmemeli, sonraki gruplardaki görseller ise geç yüklenmelidir (lazy loading).

Mobil cihazlarda bellek sınırlıdır. Yüzlerce görselli bir sonsuz liste, düşük donanımlı telefonlarda sayfanın yavaşlamasına, hatta tarayıcının sekmeyi yeniden yüklemesine neden olabilir. Hız konusunda daha fazlası için site hızı rehberimizi okuyabilirsiniz.

Erişilebilirlik

Sonsuz kaydırma, erişilebilirlik açısından en sorunlu liste yöntemidir:

• Klavye kullanıcıları: Tab tuşuyla listede ilerleyen bir kullanıcı, sayfanın sonundaki bağlantılara hiç ulaşamayabilir; çünkü her seferinde yeni içerik yüklenir.
• Ekran okuyucular: Yeni yüklenen içerik ekran okuyucuya bildirilmezse kullanıcı listenin uzadığını fark etmez. aria-live bölgeleriyle “24 yeni ürün yüklendi” gibi kısa bir bildirim yapılabilir. Akış tipi içerikler için ARIA’nın role="feed" rolü de vardır.
• Odak yönetimi: “Daha fazla yükle” düğmesine basıldığında klavye odağı yeni yüklenen ilk öğeye taşınmalıdır; aksi hâlde kullanıcı düğmede kalır ve yeni içeriği bulmak için geri gitmek zorunda kalır.
• Bilişsel yük: Sürekli değişen ve büyüyen bir sayfa, dikkat sorunları yaşayan kullanıcılar için zorlayıcıdır.

Bu yüzden erişilebilirlik öncelikli projelerde sayfalama veya odak yönetimi doğru yapılmış bir “Daha fazla yükle” düğmesi tercih edilmelidir.

Ölçüm: hangi yöntemin işe yaradığını nasıl anlarsınız?

• Sanal sayfa görüntülemeleri: Google Analytics 4’ün geliştirilmiş ölçüm ayarlarındaki “tarayıcı geçmişi olaylarına göre sayfa değişiklikleri” seçeneği açıksa, History API ile yapılan adres güncellemeleri sayfa görüntüleme olarak kaydedilebilir. Bu, kullanıcıların listenin ne kadar derinine indiğini görmenizi sağlar; ancak raporlarda sayfa görüntüleme sayısının şişeceğini hesaba katmalısınız.
• Özel olaylar: “Daha fazla yükle” tıklamaları ve otomatik yüklenen grup sayısı için ayrı olaylar tanımlayın.
• Dönüşüm karşılaştırması: Asıl soru “daha fazla ürün görüldü mü?” değil, “daha fazla ürün sayfasına gidildi mi ve satış arttı mı?” sorusudur. Mümkünse iki yöntemi A/B testiyle karşılaştırın.
• Arama tarafı: Search Console’da derin sayfalardaki içeriklerin dizine eklenme durumunu ve tarama istatistiklerini izleyin.

Hangi site için hangi yöntem?

Sık yapılan hatalar

1. Sonraki içerikleri yalnızca kaydırmayla veya onclick düğmesiyle yüklemek, HTML bağlantısı bırakmamak.
2. Sayfa numarasını # ile taşımak.
3. 2. ve sonraki sayfaların canonical etiketini ilk sayfaya vermek.
4. Derin sayfaları noindex yapmak.
5. Tüm sayfalarda aynı başlık ve açıklamayı kullanmak.
6. Kaydırırken adresi pushState ile güncelleyip “Geri” tuşunu kullanılmaz hâle getirmek.
7. Doğrudan açılan ?page=5 adresinde ilk sayfanın içeriğini göstermek.
8. Yeni içerik için yer ayırmayıp düzen kaymasına yol açmak.
9. Footer’daki kritik bağlantıları başka bir yerde sunmamak.
10. Değişikliği JavaScript kapalıyken ve Search Console URL Denetimi ile test etmeden yayına almak.

Örnek uygulama: sayfalamanın üzerine “Daha fazla yükle”

Aşağıdaki örnek, arama motoru için çalışan bir sayfalamanın üzerine kullanıcı için “Daha fazla yükle” davranışının nasıl eklendiğini gösteriyor. JavaScript çalışmazsa bağlantı normal bir sayfa geçişi yapar; çalışırsa içerik aynı sayfaya eklenir.

<ul id="liste">
  <li>…ürün 1…</li>
  …
  <li>…ürün 24…</li>
</ul>
<p id="durum" aria-live="polite"></p>
<a id="sonraki" href="/kategori/?page=2">Daha fazla ürün göster</a>

const link = document.getElementById('sonraki');
link.addEventListener('click', async (e) => {
  e.preventDefault();
  const url = link.href;
  const html = await (await fetch(url)).text();
  const doc = new DOMParser().parseFromString(html, 'text/html');
  const yeni = doc.querySelectorAll('#liste > li');
  document.getElementById('liste').append(...yeni);
  history.pushState({}, '', url);          // kullanıcı eylemi: geçmişe ekle
  yeni[0]?.querySelector('a')?.focus();    // odağı yeni içeriğe taşı
  document.getElementById('durum').textContent = yeni.length + ' yeni ürün yüklendi';
  const next = doc.getElementById('sonraki');
  next ? (link.href = next.href) : link.remove();
});

Bu yaklaşımın güzelliği, sunucu tarafında ek bir API gerektirmemesidir: “Daha fazla yükle” düğmesi, arama motorunun da takip ettiği sayfalı adresleri kullanır. Böylece kullanıcının gördüğü ile arama motorunun gördüğü yapı aynı kalır. Gerçek projelerde yükleme sırasında düğmeyi devre dışı bırakmak, hata durumunda normal sayfa geçişine düşmek ve geri dönüşte durumu yeniden kurmak gibi ayrıntılar da eklenmelidir.

Sayfa başına kaç öğe gösterilmeli?

Bunun evrensel bir cevabı yoktur ama birkaç ilke yol gösterir:

• Tarama derinliği: Sayfa başına çok az öğe (örneğin 10), yüzlerce öğelik bir listede onlarca sayfa ve derin bir tarama yolu demektir. Derindeki öğelere ulaşmak zorlaşır.
• Performans: Sayfa başına çok fazla öğe (örneğin 200), ilk yüklemeyi ağırlaştırır ve LCP’yi bozar.
• Izgara düzeni: E-ticarette öğe sayısını satırdaki ürün sayısının katı seçmek (3, 4 veya 6 sütunlu ızgaralarda 24 veya 48 gibi) son satırın yarım kalmasını önler.
• Kullanıcı davranışı: Kullanıcıların listede genellikle ne kadar derine indiği verisi varsa, ilk sayfanın bu derinliğin büyük kısmını karşılaması iyi bir başlangıçtır.

Pratikte blog arşivlerinde 10–20, e-ticaret kategorilerinde 24–48 öğe sık görülen ve genellikle dengeli sonuç veren aralıklardır. Öğe sayısını değiştirirseniz sayfa adreslerindeki içeriklerin de değişeceğini, bunun geçici tarama dalgalanmalarına yol açabileceğini unutmayın.

“Tümünü göster” sayfası ne zaman mantıklı?

Liste kısa veya orta uzunluktaysa (örneğin birkaç düzine öğe) ve tüm öğeler tek sayfada hızlı yüklenebiliyorsa, bir “Tümünü göster” sayfası hem kullanıcıya hem arama motoruna en basit yapıyı sunar. Bu durumda sayfalı seri bu sayfaya canonical verebilir. Kullanıcılar da özellikle karşılaştırma yaparken tüm seçenekleri tek ekranda görmeyi sever.

Liste yüzlerce öğeye ulaşıyorsa “Tümünü göster” sayfası ağırlaşır, mobilde kullanılmaz hâle gelir ve performans metriklerini bozar. Bu durumda sayfalama ve her sayfanın kendine canonical vermesi daha doğru yoldur.

Tek makale sonrası sonsuz kaydırma: haber sitelerinin yöntemi

Bazı haber siteleri, bir haberin sonuna gelindiğinde bir sonraki haberi otomatik yükler. Bu kullanımda her yüklenen haber ayrı bir makaledir ve SEO açısından kural değişmez: her haberin kendi adresi olmalı, kullanıcı yeni habere geçtiğinde adres, sayfa başlığı ve gerekirse analitik sayfa görüntülemesi güncellenmelidir. Aksi hâlde kullanıcı ikinci habere geçtiği hâlde adres çubuğu ilk haberi gösterir; paylaşılan bağlantı yanlış habere gider, analitik veriler de yanlış sayfaya yazılır.

Özetle

Sayfalama, sonsuz kaydırma ve “Daha fazla yükle” düğmesi, uzun listeleri sunmanın üç farklı yoludur. Arama motoru açısından belirleyici olan, kullanıcıya hangi yöntemi gösterdiğiniz değil; arka planda her içerik grubunun kendi adresine sahip olup olmadığı ve bu adreslere normal bağlantılarla ulaşılıp ulaşılamadığıdır. Kaydırma veya tıklama ile yüklenen içerik, bağlantı yolu yoksa Google için görünmezdir. rel=next/prev artık Google’ın kullandığı bir sinyal değildir; her sayfa kendine canonical vermeli, sayfa 2 ve sonrası noindex yapılmamalıdır. Liste yapınızın taranabilirliğini birlikte denetlemek için SEO hizmetimizi inceleyebilirsiniz.