Kısa cevap: Sayfalama (pagination), uzun bir listeyi — bir blog arşivini, ürün kategorisini, arama sonuçlarını, forum konusunu — numaralandırılmış bir sayfa dizisine bölme yöntemidir (?page=2, /sayfa/3/ gibi). Doğru kurulduğunda Google, tarama bütçesini israf etmeden ve ince, kopya sayfalar üretmeden setteki her öğeyi keşfeder ve dizine ekler. Yanlış kurulduğunda ise hiç taranmayan ürünleri gömer, sıralama sinyallerini böler ya da siteyi neredeyse aynı URL’lerle doldurur. Bu rehber, 2026’da arama motorlarının sayfalanmış sayfaları tam olarak nasıl değerlendirdiğini, gerçekten önemli olan canonical ve taranabilirlik kurallarını, sonsuz kaydırma ile “daha fazla yükle” düğmelerinin nasıl kurgulanacağını ve adım adım bir denetim yöntemini anlatıyor.

Sayfalama tam olarak nedir?

Sayfalama, tek bir büyük içerik koleksiyonunu, her biri bütünün bir dilimini gösteren ve bir sonrakine bağlanan daha küçük sayfalara ayırma pratiğidir. Her yerde karşınıza çıkar: sayfa başına 24 ürün gösteren ve 40 sayfaya yayılan bir kategori, her arşiv sayfasında on yazı listeleyen bir blog, onlarca numaralı sonuca dağılan bir arama sayfası, 15. sayfaya uzanan bir forum konusu. Belirleyici özellik şudur: dizideki her sayfa tek bir mantıksal setin parçasıdır. “Koşu Ayakkabıları’nın 2. sayfası”, ancak “Koşu Ayakkabıları’nın 1. sayfası”nın devamı olarak anlam taşır.

İşte bu ayrım — birlikte tek bir koleksiyon oluşturan sayfa dizisi — sayfalamayı kendine özgü bir SEO sorunu yapar. Ne birbirinden bağımsız sayfalar kümesiyle aynıdır, ne de tüm içeriğin tek sayfada toplandığı yapıyla. İkisinin arasında durur ve arama motorlarının bunu ele almak için belirli bir yolu vardır. Sinyalleri doğru verirseniz Google, diziyi normalde ulaşmakta zorlanacağı derin içeriğe açılan bir kapı olarak görür. Yanlış verirseniz ya katalogunuzun yarısını saklarsınız ya da en iyi sayfalarınızın otoritesini bir düzine ince kopyaya dağıtırsınız. Sayfalama, tam da bu yüzden ciddi her teknik SEO denetiminde tekrar eden bir madde olarak yer alır.

Sayfalama; sonsuz kaydırma, “daha fazla yükle” ve filtreli navigasyon değildir

Herhangi bir şeyi düzeltmeden önce, sürekli karıştırıldığı üç kalıptan sayfalamayı ayırmakta fayda var; çünkü her biri botlar açısından farklı davranır:

  • Klasik sayfalama — her biri kendi taranabilir URL’sine sahip ayrık, numaralı sayfalar (/blog/sayfa/2/). Arama motorlarının en iyi ele aldığı kalıp budur; çünkü koleksiyonun her dilimi, botun doğrudan isteyebileceği bir adreste yaşar.
  • Sonsuz kaydırma — kullanıcı aşağı kaydırdıkça yeni öğeler otomatik yüklenir, çoğu zaman görünür sayfa sınırı ve çoğu zaman URL değişikliği olmadan. Kendi hâline bırakılırsa botlara düşmandır: bot kaydırmaz, dolayısıyla ilk yüklemenin altındaki hiçbir şey, arkasında gerçek URL’ler yoksa asla görülmeyebilir.
  • “Daha fazla yükle” düğmeleri — kullanıcının sonraki grubu getirmek için tıkladığı bir ara çözüm. Düğme, altında bir bağlantı veya URL olmayan salt bir JavaScript eylemiyse, tıklamayan bir bot tıpkı sonsuz kaydırmadaki gibi ilk grupta takılı kalır.
  • Filtreli navigasyon — yeni URL kombinasyonları üreten filtre ve sıralama seçenekleri (?renk=mavi&sirala=fiyat). Bu tamamen farklı bir sorundur: URL patlaması ve kopya içerik. filtreli navigasyon SEO’su yazısında ele alınıyor. Sayfalama ve filtreleme çoğu zaman aynı kategori sayfasında birlikte görünür ve en kötü tarama bütçesi kazaları da bu birleşimden çıkar.

Pratikteki çıkarım şu: arayüz insana nasıl görünürse görünsün, arama motorlarının altta düz, taranabilir bir URL dizisine ihtiyacı vardır. Bu diziyi numaralı bağlantı, “daha fazla yükle” düğmesi ya da sonsuz kaydırma olarak sunmak bir arayüz tercihidir; ama taranabilir URL’ler her hâlükârda var olmak zorundadır.

Sayfalama SEO için neden önemli?

Sayfalama, aynı anda sıralamaya komşu birkaç sistemi birden etkiler; küçük bir şablon kararının, sitenizin ne kadarının gerçekten sıralandığı üzerinde orantısız büyük bir etki yaratmasının sebebi budur:

  • Taranabilirlik ve keşif. Sayfalama bağlantıları çoğu zaman botun derin öğelere ulaşabildiği tek yoldur. Bir ürün kategorinin 30. sayfasındaysa ve ona o sayfalama dizisi dışında hiçbir şey bağlanmıyorsa, diziyi bozduğunuzda o ürünün keşfini de bozarsınız.
  • Tüm setin dizine eklenmesi. Google’ın her öğeyi dizine ekleyebilmesi için dizideki her sayfaya ulaşması gerekir. Engellenmiş, canonical’ı yanlış ya da yalnızca JavaScript ile çalışan sayfalama, katalogunuzun kuyruğunun sessizce dizinden düşmesi demektir.
  • Tarama bütçesi. Büyük sitelerde verimsiz bir sayfalama kalıbı — özellikle filtre ve sıralama parametreleriyle iç içe geçtiğinde — Googlebot’un zamanının büyük bölümünü düşük değerli bileşen sayfalarında harcayabilir. tarama bütçesi sorununun özü budur.
  • Bağlantı gücü. Her sayfalama URL’si bir iç bağlantı hedefidir. Diziyi nasıl bağladığınız, otoritenin derin sayfalara ve kategoriye nasıl aktığını belirler; bu da aslında bir iç bağlantı stratejisi meselesidir.
  • Kopya ve ince içerik. Bileşen sayfaları aynı başlığı, meta açıklamayı, giriş metnini ve filtreleri paylaşır; yalnızca öğe listesi farklıdır. Dikkatsizce ele alınırsa neredeyse kopya veya ince sayfa gibi okunurlar.
  • Kullanıcı deneyimi. Aramadan 4. sayfaya düşen bir kullanıcının nerede olduğunu bilmesi; 1. sayfaya, sonraki sayfaya ve kategoriye ulaşabilmesi gerekir. Net sayfalama kontrolleri, insanları arama sonuçlarına geri gönderen sürtünmeyi azaltır.

rel=“next” / rel=“prev” hikâyesi ve neyin değiştiği

Yıllarca standart tavsiye, sayfaların bir dizi oluşturduğunu Google’a söylemek için her sayfanın <head> bölümüne rel="next" ve rel="prev" etiketleri eklemekti. Sayfalama SEO’sunu 2019 öncesinde öğrendiyseniz, bu tüm tekniğin can damarıydı ve eski birçok rehber ile eklenti hâlâ bunu dayatıyor.

2019’da Google, rel="next"/rel="prev" etiketlerini bir süredir dizine ekleme sinyali olarak kullanmadığını ve sayfalanmış sayfaları bunun yerine ayrı ayrı sayfalar olarak değerlendirdiğini doğruladı. Yani on yıl boyunca rehberlerin “olmazsa olmaz” dediği etiket, Google için sessizce işlevsiz hâle gelmişti. Modern sayfalama hakkında anlamanız gereken en önemli tek şey budur: Google artık “bu bir dizidir” diyen özel bir işaretlemeye güvenmiyor — ilişkiyi sayfalarınız arasındaki sıradan bağlantılardan kendisi çıkarıyor.

İki açıklama, insanların bu duruma aşırı tepki vermesini önler. Birincisi, rel="next"/rel="prev" eklemek zararlı değildir — Bing ve bazı araçlar hâlâ kullanır ve geçerli HTML olmaya devam eder; platformunuz üretiyorsa bırakabilirsiniz. İkincisi ve çok daha önemlisi, bu etiketin emekli olması yükü tamamen sayfa içi sayfalamanıza kaydırır: sayfalar arası gerçek, taranabilir bağlantılar; mantıklı canonical’lar ve temiz URL’ler. Google artık bunları okuyor. Google’ın güncel tutumu sayfalama ve kademeli sayfa yükleme dokümantasyonunda açıklanıyor.

Google sayfalanmış sayfaları bugün nasıl değerlendiriyor?

rel etiketleri devre dışı kaldığına göre, Google’ın şu an kullandığı modeli netleştirmekte fayda var. Bir dizideki her sayfa kendi başına bir sayfa olarak ele alınır — 2. sayfa, taranabilen, dizine eklenebilen ve prensipte kendi başına sıralanabilen ayrı bir URL’dir. Google sayfalar arasındaki ilişkiyi, herhangi bir ilişkiyi keşfettiği gibi keşfeder: aralarındaki bağlantıları izleyerek. 1. sayfa 2’ye, 2. sayfa 3’e bağlanıyorsa Googlebot zinciri yürür ve tüm sete ulaşır.

Bunun üç doğrudan sonucu var. Birincisi, bileşen sayfaları arasındaki bağlantılar gerçek, taranabilir <a href> bağlantıları olmalı — “sonraki” kontrolü URL’süz bir düğmeyse zincir kopar ve derin sayfalar hiç bulunmayabilir. İkincisi, her bileşen sayfası kendi öz-referanslı canonical’ıyla dizine eklenebilir bir URL olarak ayakta durmalı, 1. sayfanın kopyası olduğu söylenmemeli. Üçüncüsü, Google her sayfayı ayrı gördüğü için derin bileşen sayfaları rekabetçi ana terimlerde nadiren sıralanır — ve bu normaldir. Onların işi keşiftir: bireysel ürün ve yazıların dizine eklenmesini sağlayan taranabilir kanal olmak; öğeler daha sonra kendi değerleriyle sıralanır. Zincirin sağlam olduğunu bir Teknik Site Denetimi (Tarayıcı) ile tarayıp her sayfanın bir sonrakine bağlandığını doğrulayarak teyit edersiniz.

Canonical: sayfalamadaki en büyük hata

Bu yazıyı okuduktan sonra tek bir şeyi düzeltecekseniz, o da canonical etiketleriniz olsun. En yaygın ve en zararlı sayfalama hatası, her bileşen sayfasının canonical etiketini 1. sayfaya geri işaret ettirmektir:

<!-- /kategori/ayakkabi?page=2 üzerinde bu YANLIŞ -->
<link rel="canonical" href="https://ornek.com/kategori/ayakkabi" />

Sezgisel gelir — “asıl sayfa 1’dir, gerisi uzantı” — ama size zarar verir. Canonical, bu sayfa şunun kopyasıdır diyen güçlü bir ipucudur. 2. sayfayı 1’e canonical yaptığınızda Google’a 2. sayfanın ayrı dizine eklenmeyi hak etmediğini söylersiniz. Google o zaman diziye derinlemesine taramayı bırakabilir; yalnızca 2. sayfa ve sonrasında görünen her ürün veya yazı keşif yolunu kaybeder. Büyük bir katalogda bu, uzun kuyruğunuzu sessizce dizinden düşürür.

Doğru kalıp, dizideki her sayfada kendine referans veren canonical’dır — 2. sayfa 2’yi, 3. sayfa 3’ü gösterir:

<!-- /kategori/ayakkabi?page=2 üzerinde bu DOĞRU -->
<link rel="canonical" href="https://ornek.com/kategori/ayakkabi?page=2" />

Bu, her bileşen sayfasını taranmaya ve dizine eklenmeye uygun tutar; böylece Google tüm sete ulaşabilir. Tek meşru istisna, aşağıda ele alacağımız hepsini-göster (view-all) sayfası’dır. Tüm koleksiyonu listeleyen tek bir sayfa sunuyorsanız ve kabul edilebilir hızda yükleniyorsa, sayfalanmış bileşen sayfalarını o view-all URL’sine canonical yapabilirsiniz — çünkü o durumda bileşen sayfaları gerçekten tek bir tam sayfanın kısmi görünümleridir. View-all yoksa kural, öz-referanslı canonical’dır. Her sayfanın ne beyan ettiğini şablona güvenmeden önce bir Meta Etiket Analizcisi ile doğrulayın.

Taranabilir sayfalama bağlantıları, salt JavaScript kontrolleri değil

Google artık diziyi bağlantılardan çıkardığı için, bağlantıların botun gerçekten izleyebileceği şeyler olması gerekir. Şaşırtıcı sayıda modern, JavaScript ağırlıklı site tam da burada tökezliyor. Kural basit: sayfalama kontrolleri gerçek URL’lere işaret eden, gerçek href özniteliğine sahip bağlantı öğeleri olmalı ya da bunları içermeli.

  • İyi: <a href="/blog/sayfa/2/">Sonraki</a> — botun hiçbir betik çalıştırmadan izlediği düz bir bağlantı.
  • Riskli: <button onclick="sayfaYukle(2)">Sonraki</button> — href’siz bir düğme. Sonraki grup yalnızca bir betik tetikleyen tıklamadan sonra görünüyorsa, tıklamayan bir bot onu asla görmez.
  • Kötü: bağlantı gibi görünecek şekilde biçimlendirilmiş ama hiçbir href taşımayan bir <div> veya <span> — navigasyon yolu olarak botlara görünmezdir.

Google JavaScript işleyebilir; ama işleme ertelenir, kaynak sınırlıdır ve statik bir bağlantıyı izlemeye kıyasla güvenilmezdir. Bu yüzden derin içeriğinize ulaşmak kadar temel bir şey için ona asla bel bağlamamalısınız. Bu, daha geniş JavaScript SEO ilkesinin özel bir hâlidir: bir bağlantı tarama için önemliyse, onu betik-yalnızca bir etkileşim olarak değil, HTML’de gerçek bir <a href> olarak gönderin. En güvenli ve dayanıklı kalıp aşamalı geliştirmedir — gerçek sayfalama bağlantılarını sunucu tarafında oluşturun, ardından JavaScript’i olan kullanıcılar için üstüne AJAX veya sonsuz kaydırma davranışını ekleyin. Sayfalama bağlantılarının taranabilir bağlantı olarak var olduğunu bir Link Analizcisi ile, hiçbirinin 404 vermediğini bir Kırık Link Kontrolü ile doğrulayın.

Sonsuz kaydırma ve “daha fazla yükle”yi doğru kurmak

Sonsuz kaydırma ve “daha fazla yükle” düğmeleri mobilde akıcı hissettirdiği için popülerdir; ama kendi başlarına içeriği Google’dan gizlemenin en etkili yollarından biridir. Bot kaydırmaz ve tıklamaz; dolayısıyla varsayılan olarak yalnızca ilk öğe grubunu görür. Ekranın altında kalan her şey — muhtemelen katalogunuzun çoğu — görünmez olur.

Çözüm, kalıptan vazgeçmek değil, onu gerçek sayfalamayla desteklemektir. Google’ın kendi önerdiği teknik, kaydırma veya düğme deneyimini altta gerçek, taranabilir sayfalama URL’leriyle eşleştirmektir:

  • Her gruba gerçek bir URL verin. Kullanıcı 2. gruba ulaştığında yüklenen içerik, ?page=2 gibi doğrudan istenebilir bir adreste de var olmalıdır. Googlebot’un taradığı o URL’dir; kaydırma yalnızca insana yönelik süstür.
  • Adres çubuğunu History API ile güncelleyin. Kullanıcı yeni bir bölüme kaydırdıkça, URL’yi o bölümün sayfalama adresine çevirmek için history.pushState() kullanın. Bu, deneyimi kesintisiz tutarken her parçaya paylaşılabilir, taranabilir bir URL sağlar — Google&rsquo;ın kademeli sayfa yükleme yönergesinde anlatılan yaklaşım budur.
  • Yedek olarak statik “sonraki” bağlantıları ekleyin. Düz bir sayfalama bağlantısı (gören kullanıcılardan gizlenmiş ama HTML’de mevcut olsa bile) botlara, kaydırma davranışından bağımsız olarak dizi boyunca net bir yol verir.
  • Botun ne gördüğünü test edin. Bir kategori sayfasını JavaScript kapalıyken yükleyin veya ham sunucu HTML’sini inceleyin. O HTML’de 2. sayfa ve sonrasına bağlantı bulamıyorsanız, Google da güvenilir biçimde bulamaz.

Bu şekilde kurulduğunda sonsuz kaydırma SEO açısından tamamen güvenlidir: kullanıcılar akıcı deneyimi alır, botlar ise eski usul numaralı bağlantılarla elde edecekleri aynı düz sayfalama URL’leri setine kavuşur.

Sayfalanmış sayfalar için URL yapısı

Dizi için kullandığınız URL’ler; temizlik, tutarlılık ve tarama verimliliği açısından önemlidir. İki gelenek öne çıkar ve ikisi de Google için kabul edilebilir:

  • Yol tipi: /blog/sayfa/2/ — okunaklıdır, bloglarda ve CMS platformlarında yaygındır.
  • Parametre tipi: /blog?page=2 — aynı ölçüde geçerlidir ve dinamik ile e-ticaret sistemlerinde üretmesi çoğu zaman daha kolaydır.

Hangisini seçerseniz seçin, her yerde uyguladığınız URL yapısı kurallarını burada da uygulayın: tek bir kalıp seçin ve tutarlı kalın, bileşen URL’leri arasında değişen tek şey sayfa numarası olsun ve filtre, sıralama ile izleme parametrelerinin sayfa numarasının üzerine yığılıp aynı listenin onlarca varyantını üretmesine izin vermeyin. Birkaç özel kural sayfalama URL’lerini derli toplu tutar:

  • “1. sayfa”yı ayrı bir URL olarak dizine eklemeyin. Bir dizinin ilk sayfası, /blog/sayfa/1/ değil temiz kategori URL’si (/blog/) olmalıdır. Sisteminiz bir sayfa/1 URL’si üretiyorsa, açılış sayfasının kopyasını yaratmamak için onu çıplak kategori URL’sine yönlendirin.
  • Parametre sırasını ve harf durumunu tutarlı tutun ki ?page=2 her zaman kelimesi kelimesine aynı dize olsun — tutarsız parametreler, aynı içerik için kopya URL’ler imal eder.
  • Sayfalamayı oturum kimlikleri veya izleme parametreleriyle birleştirmekten kaçının (taranabilir bağlantılarda); bunlar diziyi sonsuz kopyaya çoğaltır ve tarama bütçesini tüketir.

Hepsini-göster sayfası: tek sayfa çokluya üstün geldiğinde

Sık gözden kaçan bir seçenek, hepsini-göster (view-all) sayfası’dır — hiç sayfalama olmadan tüm koleksiyonu listeleyen tek bir URL. Google uzun süredir, böyle bir sayfa varsa ve hızlı yükleniyorsa kullanıcılara onu göstermeyi tercih etme eğiliminde olduğunu söylüyor; çünkü arama yapanlar genellikle her şeyi tek yerde görmeyi, bir dizi boyunca tıklamaya yeğler.

Bir view-all sayfası sunuyorsanız SEO kalıbı nettir: kullanıcılar kolaylık için bileşen sayfalarında gezinsin, ama her bileşen sayfasını view-all URL’sine canonical yapın ve sıralama sinyallerini o tek kapsamlı sayfada toplayın. Püf noktası performanstır. Binlerce ürünü listeleyen bir view-all sayfası devasa ve yavaş hâle gelebilir; Core Web Vitals puanlarınıza zarar veren bir sayfa, dizine eklemeyi basitleştirse bile kötü bir takastır. Yani karar bir dengedir:

  • View-all sayfası kullanın — tüm koleksiyon hızlı yüklenecek kadar makulse (birkaç düzineden birkaç yüze kadar öğe) ve sinyalleri orada toplayın.
  • Öz-canonical veren sayfalanmış sayfalarda kalın — koleksiyon, tek sayfanın ağır ve yavaş olacağı kadar büyükse.

Evrensel bir doğru yok; setinizin boyutuna ve ne kadar hızlı sunabildiğinize bağlı. Yapmamanız gereken tek şey, hem bir view-all sayfası sunup hem de bileşen sayfalarını 1. sayfaya canonical yapmaktır — tek bir toplama hedefi seçin ve tutarlı olun.

Sayfalama, iç bağlantı ve bağlantı gücü

Taramanın ötesinde, sayfalama otoritenin sitenizde nasıl dolaştığını da şekillendirir. Her bileşen sayfası hem iç bağlantı alıcısı hem de kaynağıdır; kontrolleri nasıl kurduğunuz akışı belirler. Birkaç ilke bu akışı sağlıklı tutar:

  • Her zaman 1. sayfaya ve kategoriye geri bağlanın. Derin bileşen sayfaları dizinin başına ve üst kategoriye yukarı doğru bağlanmalı ki otorite uzun bir zincirin dibinde mahsur kalmasın.
  • Yalnızca “sonraki” ve “önceki”den fazlasını gösterin. Birkaç numaralı sayfayı ilk ve son sayfayla birlikte açığa çıkaran bir kontrol (1 … 4 5 6 … 40), yalnızca bir sonraki sayfayı sunan bir zincire kıyasla derin sayfalara tıklama-ve-tarama mesafesini kısaltır. Bu kısa yol, Googlebot’un 30. sayfaya otuz sıçrama yerine birkaç sıçramada ulaşması demektir.
  • Derin öğeleri yetim bırakmayın. En önemli ürün ve yazılar, yalnızca bir kategorinin 25. sayfasında bulunmaya bel bağlamamalı. Onları bağlamsal iç bağlantılar, ilgili öğe modülleri ve merkez sayfalarla destekleyin ki keşifleri tümüyle sayfalama zincirine bağlı olmasın. Başka bağlantısı olmayan gömülü öğeler klasik bir yetim sayfa kaynağıdır.
  • Bileşen sayfalarını asıl bağlantı gücü hikâyenizin dışında tutun. Onlar botları dağıtmak için vardır, sıralanmak için değil. Dış bağlantılarınızı, navigasyonunuzu ve çapraz bağlantılarınızı ?page=7’ye değil kategoriye ve bireysel öğelere yöneltin.

Bağlantı grafiğinizi bir Link Analizcisi veya tam bir Teknik Site Denetimi (Tarayıcı) ile haritaladığınızda, sağlıklı sayfalama derin içeriğe kısa, tutarlı tarama yolları ve kategoriye net geri bağlantılar olarak görünür; uzun, tek adımlı “yalnızca sonraki” zincirleri ve çıkmaza giren derin sayfalar ise uyarı işaretidir.

Sayfalama ve XML site haritaları

Sık sorulan bir soru, sayfalama URL’lerinin XML site haritanıza girip girmeyeceğidir. Genel yanıt: hayır. XML site haritanız gerçekten dizine eklenip sıralanmasını istediğiniz URL’leri — kategori sayfalarınızı ve her şeyden önce bireysel ürün ile yazı sayfalarınızı — listelemeli; esasen tarama kanalı olarak var olan ?page=2 bileşen URL’lerini değil.

Gerekçe, Google’ın diziyi ele alış biçiminden çıkar. Bileşen sayfaları, sayfa içi sayfalama bağlantıları üzerinden zaten sorunsuz keşfedilir ve arama sonuçlarında görünmesini istediğiniz sayfalar değildir; dolayısıyla site haritasını onlarla doldurmak, hangi URL’lerin önemli olduğuna dair sinyali seyreltir. Bunun yerine, sayfalanmış setin içinde yaşayan her öğenin site haritasında kendi URL’si olduğundan emin olun. Böylece Google uzun bir diziye derinlemesine taramada yavaş kalsa bile, dizine ekleyeceği her ürün ve yazının doğrudan bir listesine sahip olur. Site haritasını canlı sayfalarınızla bir Sitemap Bulucu & Doğrulayıcı ile karşılaştırın ve sayfalama bileşen URL’lerine değil öğelere işaret ettiğinden emin olun.

Sayfalama ile filtreli navigasyon çakıştığında

En karmaşık sayfalama senaryosu, hem sayfalanan hem filtrelenebilen bir e-ticaret kategorisidir. Artık her filtre kombinasyonunun kendi sayfalama dizisi vardır: /ayakkabi?renk=mavi&page=2, /ayakkabi?renk=mavi&numara=42&page=3 ve böyle uzayıp gider. Çarpım acımasızdır — birkaç filtre onlarca sayfaya yayıldığında, aslında tek bir ürün kategorisi için on binlerce taranabilir URL üretebilir.

Sayfalamanın tek başına bir sorun olmaktan çıkıp filtreli navigasyon stratejisinin parçası olduğu yer burasıdır. Yol gösterici kararlar şunlardır:

  • Hangi filtrelenmiş görünümlerin dizine eklenmeyi hak ettiğine karar verin. Yüksek talepli bir kombinasyon (insanların gerçekten aradığı bir renk gibi) dizine eklenebilir, öz-canonical veren bir sayfalama dizisini hak edebilir. Filtre kombinasyonlarının büyük çoğunluğu bunu hak etmez ve dizin dışında tutulmalıdır.
  • Botların filtrelenmiş sayfalamaya ne kadar derine indiğini denetleyin. Dizine ekmek istemediğiniz kombinasyonlar için filtreli navigasyon denetimi araçlarını kullanın — robots.txt disallow kuralları, filtresiz kategoriye dikkatli canonical veya o parametre bağlantılarını hiç taranabilir yapmamak — ki Googlebot asla sıralanmayacak kombinasyonlarda bütçe harcamasın.
  • Filtrelenmiş sayfalamanın temiz kategoriyi yamyamlaştırmasına asla izin vermeyin. Filtresiz, sayfalanmış kategori genellikle sıralama varlığınızdır; filtrelenmiş varyantlar onu desteklemeli, onunla yarışmamalı veya kopyalarla gömmemelidir.

Yönergelerinizi bir Robots.txt Test Aracı ile doğrulayın ve filtrelenmiş URL’lerin nereye yönlendirdiğini ya da canonical verdiğini bir Yönlendirme & HTTP Durum Kontrolü ile kontrol edin; çünkü sayfalama ile filtreleme çakıştığında yanlış şeyi engellemek veya kopyalamak çok kolaydır.

SEO’ya zarar veren yaygın sayfalama hataları

Sayfalama hasarının çoğu, kısa bir mükerrer suçlular listesinden gelir. Bunları kendi şablonlarınızda kollayın:

  • Tüm bileşen sayfalarını 1. sayfaya canonical yapmak. Bir numaralı hata — Google’a 2. sayfa ve sonrasını dizine eklememesini söyler, derin içeriğinizi mahsur bırakır. Bunun yerine öz-referanslı canonical kullanın.
  • Salt JavaScript sayfalaması. Arkalarında gerçek <a href> URL’leri olmayan “sonraki” düğmeleri ve sonsuz kaydırma, ilk grubun ötesindeki her şeyi botlardan gizler.
  • Bileşen sayfalarına noindex vermek. 2. sayfa ve sonrasına noindex eklemek düzenli görünür; ama Google uzun vadede bir noindex sayfasını sonunda nofollow gibi de değerlendirir — ve o sayfalardaki bağlantıları izlemeyi bırakınca üzerlerindeki öğeleri keşfetmeyi de bırakır. Bileşen sayfaları dizine eklenebilir kalsın.
  • Sayfalamayı robots.txt’te engellemek. ?page=’yi disallow etmek Googlebot’un diziyi hiç taramamasına yol açar ve keşif için ona bel bağlayan her derin öğeyi keser. Sayfalamayı engellemek ile canonical ile toplamak iki farklı stratejidir — karıştırmayın ve ikisini birden yapmayın. Aralarındaki ayrımlar noindex, nofollow ve Disallow yazısında ele alınıyor.
  • Ayrı bir sayfa/1 URL’sini dizine eklemek. Bu, temiz kategori açılış sayfanızın kopyasını yaratır. sayfa/1’i çıplak kategori URL’sine yönlendirin.
  • Farklılaştırılmamış, aynı başlık ve metalar. Tam olarak aynı başlığı ve açıklamayı paylaşan bileşen sayfaları kopya gibi okunur; sayfa numarasını eklemek (“… – Sayfa 2”) onları farklılaştırmanın hafif ve dürüst bir yoludur.
  • Yalnızca “sonraki” sunan sayfalama. Sayfa başına tek sonraki bağlantısı olan bir zincir, derin sayfaları tepeden çok sıçrama uzağa koyar ve keşfi yavaşlatır. Yolu kısaltmak için numaralı bağlantıları ve bir “son” bağlantısını gösterin.
  • Giriş metninin tamamını her sayfada tekrarlamak. Her bileşen sayfasının tepesindeki uzun, anahtar kelime yoğun kategori açıklaması, dizi boyunca neredeyse aynı metni çoğaltır. Onu 1. sayfada gösterin, gerisinde kısaltın.

Sayfalamanızı adım adım denetleyin ve düzeltin

Yukarıdaki teoriyi düzeltmelere çevirmek kısa, tekrarlanabilir bir süreçtir. Her seferinde tek bir sayfalanmış şablon üzerinde ilerleyin:

  1. Sayfalanmış bir dizi bulun. Birkaç sayfaya yayılan gerçek bir kategori, arşiv veya liste seçin ve URL kalıbını not edin (?page= ya da /sayfa/).
  2. 2. sayfa ve sonrasındaki canonical’ı kontrol edin. Bir bileşen sayfasını açın ve canonical’ını bir Meta Etiket Analizcisi ile inceleyin. Kendine (ya da gerçek bir view-all sayfasına) işaret etmeli — asla 1. sayfaya değil.
  3. Bağlantıların taranabilir olduğunu doğrulayın. Ham HTML’yi görüntüleyin veya bir Link Analizcisi çalıştırın ve “sonraki” ile numaralı bağlantıların betikli düğmeler değil, gerçek <a href> bağlantıları olduğunu doğrulayın.
  4. JavaScript kapalıyken test edin. JS’yi devre dışı bırakıp yeniden yükleyin. Hâlâ 2. sayfa ve sonrasına ulaşabiliyorsanız, bot da ulaşabilir. Sayfalama kaybolursa, sunucu tarafı bağlantılarla çözmeniz gereken salt JavaScript sorununuz var demektir.
  5. Tüm diziyi tarayın. Bir Teknik Site Denetimi (Tarayıcı) çalıştırın ve botun setin son sayfasına ve yol üstündeki her öğeye ulaştığını doğrulayın; 404 veren sayfalama bağlantılarını yakalamak için bir Kırık Link Kontrolü kullanın.
  6. sayfa/1 kopyasını yok edin. Bir sayfa/1 URL’si var mı ve varsa temiz kategoriye yönlendiriyor mu diye bakın — bir Yönlendirme & HTTP Durum Kontrolü ile doğrulayın.
  7. Başlık ve metaları gözden geçirin. Bileşen sayfalarının tam kopya yerine farklılaştırıldığından (sayfa numarası eki) emin olun; dizinin birkaç sayfasında bir Sayfa İçi SEO Kontrolü (Anahtar Kelime) kullanın.
  8. Sonsuz kaydırma veya “daha fazla yükle”yi çözün. Şablon ikisinden birini kullanıyorsa, her grubun gerçek bir URL’si olduğunu ve kullanıcı ilerledikçe history.pushState()’in adres çubuğunu güncellediğini doğrulayın.
  9. Site haritasını ve iç bağlantıları budayın. Site haritanızın bileşen URL’lerini değil öğeleri listelediğinden ve derin öğelerin sayfalama zincirinin ötesinde bağlamsal bağlantıları olduğundan emin olun.
  10. Doğrulamak için yeniden tarayın. Değişikliklerden sonra Teknik Site Denetimi (Tarayıcı)’i tekrar çalıştırın ve Search Console’da dizinin derinindeki sayfaların tarandığını ve öğelerin dizine eklendiğini kontrol edin.

Bunu bir kontrol listesine dönüştürün

Analiz, ancak şablonu değiştirirse bir işe yarar. Bunu yayına-almadan-önce sayfalama kontrol listeniz olarak kullanın:

  • Her bileşen sayfasında kendine referans veren canonical (ya da hızlı bir view-all’a canonical) — asla 1. sayfaya değil.
  • Sunucu tarafında oluşturulan HTML’de mevcut, gerçek ve taranabilir <a href> sayfa bağlantıları.
  • Bileşen sayfaları dizine eklenebilir bırakılmış — toplu noindex yok, dizide robots.txt disallow yok.
  • Yalnızca “sonraki” değil, numaralı bağlantılar ile ilk/son — derin sayfalara tarama yolunu kısaltmak için.
  • Temiz, tutarlı URL’ler; sayfa/1 çıplak kategoriye yönlendirilmiş.
  • Farklılaştırılmış başlık/metalar (sayfa numarası eki); giriş metni her sayfada tam olarak tekrarlanmamış.
  • Sonsuz kaydırma ve “daha fazla yükle”, gerçek sayfalama URL’leri ve History API güncellemeleriyle desteklenmiş.
  • Site haritası ?page= URL’lerini değil bireysel öğeleri listeliyor; derin öğelerin bağlamsal bağlantıları var.
  • Filtrelenmiş sayfalama, tarama bütçesi israfına dönüşmeyecek şekilde denetlenmiş.
  • Tüm dizi taranıp doğrulanmış — son sayfa ve her öğe erişilebilir.

Sayfalama, çalıştığında nadiren takdir gören ama çalışmadığında trafiğinizi sessizce sınırlayan o sessiz teknik temellerden biridir. Şablonu bir kez doğru kurun — öz-canonical veren, taranabilir, dizine eklenebilir, temiz bağlanmış — ve sitenizdeki her liste, derin içeriğinin güvenilir keşfini miras alır. Bu kontrolleri düzenli tarama bütçesi ve teknik SEO denetimi rutinlerinize katın; bir liste şablonunu değiştirdiğinizde veya yeni bir filtrelenebilir kategori eklediğinizde yeniden gözden geçirin.

Sık sorulan sorular

Sayfalama için hâlâ rel=“next” ve rel=“prev” kullanmalı mıyım?

Google, rel="next"/rel="prev"’i dizine ekleme sinyali olarak kullanmayı bıraktı ve diziyi artık sıradan bağlantılardan çıkarıyor; dolayısıyla Google için gerekli değil. Zararlı da değil ve Bing gibi diğer motorlar hâlâ kullanıyor, o yüzden platformunuz üretiyorsa bırakabilirsiniz — ama ona bel bağlamayın. Artık önemli olan, taranabilir sayfa içi bağlantılarınız ve canonical’larınızdır.

Bir kategorinin 2. sayfasında hangi canonical olmalı?

Kendine referans veren biri: 2. sayfa 2. sayfaya canonical vermeli. İstisna, tüm koleksiyonu listeleyen hızlı bir view-all sayfanız varsa; o zaman bileşen sayfalarını o view-all URL’sine canonical yapabilirsiniz. 2. sayfa ve sonrasını asla 1. sayfaya canonical yapmayın — bu Google’a daha derin sayfaları dizine eklememesini söyler ve üzerlerindeki öğeleri mahsur bırakır.

Sonsuz kaydırma SEO için kötü müdür?

Yalnızca arkasında taranabilir URL yoksa. Kendi başına sonsuz kaydırma, ilk grubun ötesindeki her şeyi Google’dan gizler; çünkü botlar kaydırmaz. Onu gerçek sayfalama URL’leriyle (?page=2…) destekleyin ve kullanıcı kaydırdıkça adres çubuğunu history.pushState() ile güncelleyin; böylece tamamen SEO-güvenli hâle gelir.

Sayfalama URL’leri XML site haritama girmeli mi?

Genellikle hayır. Dizine eklenmesini istediğiniz URL’leri — kategori sayfalarını ve en önemlisi bireysel ürün ile yazı sayfalarını — listeleyin; ?page=2 bileşen URL’lerini değil. Bileşen sayfaları, sayfa içi bağlantılar üzerinden keşfedilir; site haritası, gerçekten sıralanmasını istediğiniz öğelere işaret etmeli.

Sayfalanmış sayfalar kopya içeriğe yol açar mı?

Dikkatsizce ele alınırsa açabilir — dizi boyunca aynı başlıklar, metalar ve giriş metni neredeyse kopya gibi okunur. Ama doğaları gereği kopya içerik değildirler: her bileşen sayfası farklı bir öğe dilimini gösterir. Başlıkları bir sayfa numarası ekiyle farklılaştırın, kategori açıklamasının tamamını her sayfada tekrarlamayın ve kendine referans veren canonical’ları koruyun; kopya sorun olmaktan çıkar.