Blog details
Kategori sayfasının ilk bölümü iyi görünürken, sayfa 5’teki ürünler Google için görünmez kalabilir. Pagination kaynaklı sorunlar çoğu zaman böyle çalışır, sessizdir, ama trafik kaybı yaratır.
Bu yüzden sağlam bir pagination SEO analizi, sadece ?page=2 URL’lerini bulmakla bitmez. Asıl iş, bu sayfaların taranıp taranmadığını, doğru sayfaya canonical verip vermediğini ve site içindeki link akışında yer alıp almadığını kanıtlamaktır.
Aşağıdaki yöntemler, kategori, blog arşivi ve listeleme sayfalarında gerçek problemi hızlıca ayırmanıza yardım eder.
Pagination neden fark edilmeden performans kaybettirir
Pagination sorunları genelde sayfa 1’in güçlü olması yüzünden gözden kaçar. Ana kategori iyi indeks alır, title düzgündür, içerik yüklenir. Ancak sayfa 2 ve sonrası ya taranmaz, ya yanlış canonical yüzünden bastırılır, ya da zayıf iç link akışı nedeniyle arka planda kalır.
Sorun burada bitmez. Derin sayfalarda yer alan ürünler, yazılar veya marka kombinasyonları bağımsız olarak aranabiliyorsa, bu sayfaların görünmez olması doğrudan keşif kaybı yaratır. E-ticarette bunun sonucu geç indekslenen ürünlerdir. Blog arşivlerinde ise eski ama halen değerli içeriklerin bulunamamasıdır.
Birçok geniş çaplı denetimde pagination eksik incelenir. Çünkü örneklem az tutulur. Ana sayfa, birkaç kategori ve birkaç ürün taranır. Oysa tam crawl yapılmadığında duplicate title, aynı meta description, ince içerik ve tıklama derinliği sorunları görünmez. Bu nedenle genel bir teknik denetimden önce bile detaylı SEO analiz yöntemleri içinde pagination segmentini ayrı ele almak gerekir.
En maliyetli hata, sayfa 2 ve sonrasını teknik olarak açık bırakıp arama motoru için görünmez hale getirmektir.
2026 itibarıyla güvenli yaklaşım net: pagination için tek bir evrensel reçete yok. Kategori yapısı, ürün yoğunluğu, arama talebi, JS kullanımı ve URL mimarisi birlikte değerlendirilmelidir.
Analize başlamadan önce URL ve şablon haritasını çıkarın
İlk iş, sayfalamanın sitede nasıl üretildiğini tek bakışta anlamaktır. Çünkü aynı sitede birden fazla örüntü bulunabilir. Kategoriler ?page=2 kullanırken, blog arşivleri /page/3/ yapısında olabilir. Daha kötüsü, filtreli listelemeler ?color=red&page=4&sort=price_asc gibi sonsuz varyasyon üretebilir.
Sağlıklı örnekler genelde şunlardır: /kategori/erkek-ayakkabi?page=2 veya /blog/seo-rehberleri/page/3/. Riskli örnekler ise /#page=2, form submit ile yüklenen sayfalar ve sadece buton tıklaması sonrası oluşan JS durumlarıdır. URL değişmiyorsa ya da HTML içinde taranabilir link yoksa, botların bu içeriğe erişmesi zorlaşır.
Screaming Frog ile tam site taraması yapın ve pagination URL’lerini regex ile ayırın. page= ya da /page/ içeren adresleri ayrı dışa aktarın. Ardından şu alanlara bakın:
- status code
- canonical hedefi
- title ve meta description
- crawl depth
- inlinks sayısı
- indexability durumu
Buna ek olarak XML sitemap’i kontrol edin. Sitemap’te pagination URL’leri varsa bunun bilinçli bir karar olup olmadığını sorun. İndekslenmesini istemediğiniz sayfaları sitemap’e doldurmak, tarama önceliğini bulanıklaştırır. Tersi de sorun yaratır, indekslenmesini istediğiniz derin sayfalar sitemap’te ve iç linklerde yoksa botlar bunları geç keşfeder.
Infinite scroll kullanılan şablonlarda da aynı disiplin gerekir. Arayüz kaydırmayla çalışabilir, ama arka planda gerçek paginated URL’ler bulunmalıdır. Aksi halde kullanıcı içeriği görür, bot göremez.
Canonical ve noindex kararlarını birlikte test edin
Pagination denetiminde en kritik alan canonical ve noindex seçimidir. Çünkü bu iki sinyal yanlış kurulduğunda, sayfalama sayfaları site içinde var olsa da arama sonuçlarında etkisiz kalır.
Tüm sayfaların ilk sayfaya canonical vermesinin riski
En sık hata, tüm paginated URL’lerin sayfa 1’e canonical vermesidir. Örneğin /kategori?page=2, /kategori?page=3 ve /kategori?page=4 adreslerinin hepsi /kategori adresini canonical gösteriyorsa, arama motoru derin sayfaları kopya olarak yorumlayabilir. Bu durumda o sayfalardaki ürün linkleri keşfedilse bile, sayfanın kendi sinyali bastırılır.
Bu yaklaşım bazı ekiplerde “sinyalleri tek sayfada toplama” fikriyle uygulanır. Ancak çoğu sitede sonuç tersine döner. Hele derin sayfalarda yalnızca orada görünen ürünler varsa kayıp büyür. Canonical stratejileri üzerine iyi bir özet bu hatanın indekslemeyi nasıl bastırabildiğini açık anlatıyor.
Daha güvenli yaklaşım çoğu durumda self-canonical’dır. Yani her pagination sayfası kendi URL’sini canonical gösterir. Tek istisna, gerçekten güçlü bir “tümünü göster” sayfası varsa düşünülebilir. Ama o sayfa yavaşsa, devasa boyuttaysa veya kullanıcı deneyimi zayıfsa canonical hedefi olarak da zayıftır.
Noindex kullanımında yan etkiler
“Sayfa 2 ve sonrası noindex olsun” kararı bazen mantıklı görünür. Özellikle blog arşivlerinde veya çok ince sayfalarda bu yaklaşım işe yarayabilir. Fakat bunu otomatik reçete gibi kullanmak risklidir. Çünkü uzun süre noindex kalan sayfalar daha az önemli görülmeye başlayabilir. Sonuçta bu sayfalardaki iç link keşfi de zayıflayabilir.
Bu yüzden karar verirken şu soruyu sorun: Derin sayfalar kendi başına arama talebi taşıyor mu, yoksa sadece gezinme katmanı mı? Eğer arka sayfalarda aranabilir ürünler, marka kümeleri veya eski ama değerli yazılar varsa noindex agresif bir karar olabilir. Pagination için temkinli noindex değerlendirmesi bu ayrımı iyi çerçeveliyor.
Doğrulama tarafında sadece kaynak kod yetmez. Search Console URL Denetimi’nde kullanıcı tarafından bildirilen canonical ile Google’ın seçtiği canonical’ı karşılaştırın. Fark varsa şablon doğru görünse de sinyal zayıf olabilir.
İç link akışı zayıfsa derin sayfalar yetim kalır
Pagination sayfaları yalnızca var olmakla iş görmez. Onlara düzenli ve taranabilir link verilmelidir. En sık sorun, sadece “sonraki” bağlantısının bulunması ve numaralı sayfa linklerinin HTML içinde yer almamasıdır. Bu yapı kullanıcıya yeterli gelebilir, ama derin sayfaları botlar için pahalı hale getirir.
Daha zor vaka ise yetim kalmış, yani orphaned pagination sayfalarıdır. URL teknik olarak çalışır, hatta bazen sitemap’te bile vardır. Fakat site içinde hiçbir HTML link o sayfaya çıkmaz. Bu genelde JS tabanlı bileşenlerde, sonsuz kaydırmada veya yanlış koşullu render mantığında görülür.
Örnek düşünün: /blog/page/5/ adresi canlıdır, ama blog sayfasında sadece ilk üç sayfa linki görünür ve devamı tıklama sonrası API ile yüklenir. Böyle bir durumda sayfa 5’e ulaşım zayıflar. Üstelik sayfa 5’teki yazılar başka iç link de almıyorsa, indeks keşfi ciddi biçimde yavaşlar.
Burada ölçülmesi gereken iki şey vardır. İlki inlinks sayısıdır. Screaming Frog’ta pagination URL’lerinin kaç iç link aldığına bakın. İkincisi crawl depth’tir. Sayfa 6’ya ulaşmak için 8 tıklama gerekiyorsa, mimari gereksiz pahalıdır.
İç link akışını güçlendirmek için her zaman uzun numaralı blok kurmak gerekmez. Ancak “önceki”, “sonraki”, ilk sayfa, son sayfa ve çevredeki birkaç sayfa bağlantısı taranabilir biçimde bulunmalıdır. Kategori üst şablonları da yalnızca sayfa 1’e oturmamalı; önemli alt kümelere editorial link vermelidir.
Tarama bütçesi israfını en net log analizi gösterir
Tarama bütçesi konusu küçük sitelerde abartılır, büyük sitelerde ise hafife alınır. Pagination söz konusu olduğunda gerçek tabloyu en iyi loglar gösterir. Çünkü Search Console özet verir, log dosyası ise botun hangi URL’ye ne sıklıkta geldiğini tam olarak gösterir.
Özellikle e-ticarette sorun, sayfalama ile filtrelerin birleşmesidir. Örneğin /kategori?page=12&sort=price_asc&stock=1 gibi URL kombinasyonları binlerce varyasyon üretebilir. Googlebot bunlara gereğinden fazla uğruyorsa, daha değerli ürün ve kategori sayfalarına daha az zaman kalır.
Bu yüzden pagination denetiminde sunucu logları üzerinden SEO analizi ayrı bir katman olmalı. Şu sinyalleri arayın:
- Googlebot hit’lerinin önemli kısmı derin pagination veya filtre kombinasyonlarında mı?
- 3xx zincirleri pagination URL’lerinde yoğun mu?
- 4xx veren eski sayfa numaraları hâlâ crawl alıyor mu?
- Yanıt süresi sayfa 10 ve sonrası için belirgin şekilde artıyor mu?
Ayrıca GSC Crawl Stats raporu ile logları birlikte okuyun. Eğer loglarda bot trafiğinin büyük bölümü düşük değerli parametreli sayfalara gidiyor, ama yeni ürün URL’leri geç keşfediliyorsa, burada açık bir bütçe israfı vardır. Çözüm çoğu zaman “taramayı engelle” kadar basit olmaz. Önce URL üretimini disipline edin, iç linkleri sadeleştirin, gereksiz kombinasyonları kaldırın ve canonical mantığını temizleyin.
Belirti, olası neden, doğrulama ve çözüm eşleştirmesi
Aşağıdaki tablo, pagination tarafında en sık gördüğünüz sinyalleri hızlıca sınıflandırmak için kullanışlıdır.
| Belirti | Olası neden | Nasıl doğrulanır | Çözüm |
|---|---|---|---|
| Sayfa 2 ve sonrası indeksten düşüyor | Tüm sayfalar sayfa 1’e canonical veriyor | Screaming Frog canonical export, URL Denetimi | Her sayfada self-canonical kullanın, yalnızca güçlü bir “tümünü göster” sayfası varsa farklı düşünün |
| GSC’de “Google farklı canonical seçti” artıyor | Parametreli kopyalar, karışık iç linkler | GSC Sayfa Dizine Ekleme raporu, kaynak kod, site içi link incelemesi | URL normalizasyonu yapın, iç linkleri tek biçime indirin, gereksiz parametre üretmeyin |
| Derin ürünler geç keşfediliyor | Zayıf iç link akışı, yüksek crawl depth | Screaming Frog inlinks ve depth verisi, loglar | Önceki-sonraki ve numaralı linkleri HTML’de sunun, kategori içi linkleri güçlendirin |
| Pagination URL’leri hiç crawl almıyor | Yetim kalmış sayfalar, sadece JS ile yükleme | Liste modunda URL testi, log analizi, manuel kaynak kod kontrolü | Taranabilir <a> linkleri ekleyin, SSR veya prerender kullanın |
| Title ve description tekrar ediyor | Şablon sayfa numarasını yansıtmıyor | Screaming Frog title/meta export | Title’a bağlamlı sayfa numarası ekleyin, meta açıklamayı gerekirse varyasyonlu üretin |
| “Tarandı, şu anda dizine eklenmiş değil” artıyor | Zayıf içerik, fazla benzer listeleme, noindex kalıntısı | GSC durum raporu, sayfa içerik karşılaştırması | Sayfa başına içerik değerini artırın, gereksiz sayfaları üretmeyin, noindex kararını yeniden gözden geçirin |
Tablodaki satırlar çoğu zaman birlikte görülür. Örneğin duplicate title tek başına küçük bir kusur gibi durur, ama self-canonical eksikliği ve zayıf iç linkle birleşince daha büyük bir indeksleme sorunu ortaya çıkar.
Screaming Frog, Search Console ve site: sorguları ile pratik denetim akışı
Günlük iş akışında en hızlı sonuç veren yöntem, birkaç aracı aynı zincirde kullanmaktır. Tek araçla karar vermek pagination tarafında sık hata üretir.
- Önce Screaming Frog ile tam crawl alın. Pagination segmentini ayırın. Canonical, status code, title, meta, indexability, inlinks ve crawl depth sütunlarını dışa aktarın.
- Sonra Search Console’da yalnızca bu URL grubuna bakın. Sayfa Dizine Ekleme raporunda “Tarandı, şu anda dizine eklenmiş değil”, “Bulundu, şu anda dizine eklenmiş değil” ve canonical ile ilgili durumları karşılaştırın.
- Ardından birkaç örnek URL’de URL Denetimi yapın. Google’ın seçtiği canonical sizin tanımınızla örtüşüyor mu, önce bunu görün.
- Daha sonra
site:alanadi.com inurl:"?page="veyasite:alanadi.com inurl:"/page/"gibi sorgular kullanın. Bu yöntem tam sayı vermez, ama kaba eğilim gösterir. Çok sayıda istenmeyen pagination URL’si görünüyorsa sinyal önemlidir. - Son adımda logları açın. Tarama davranışı, teorik ayarlardan daha dürüsttür. Kağıt üzerinde doğru görünen yapı, pratikte bütçe yiyebilir.
Bu aşamada benzer örnekleri karşılaştırmak isterseniz, Google Search Central topluluk tartışması faydalı olabilir. Orada da görüldüğü gibi aynı teknik tercih her sitede aynı sonucu üretmez. Bağlam belirleyicidir.
Sonuç
Pagination sorunları çoğu zaman tek bir etiket hatası değildir. Genelde URL yapısı, canonical seçimi, noindex politikası, iç link akışı ve crawl davranışı birlikte problem üretir.
En güçlü yaklaşım, tahminle değil kanıtla ilerlemektir. Canonical, noindex ve iç link kararlarını Screaming Frog, Search Console, log analizi ve sınırlı site: sorgularıyla çapraz doğruladığınızda, gerçek darboğaz hızla ortaya çıkar.
Sayfa 1 iyi durumda diye geri kalan listeleme katmanını sağlıklı sanmayın. Trafiğin görünmeyen kısmı çoğu zaman orada kaybolur.