Sonsuz Kaydırma SEO: Haber Arşivinde Sayfalama Kararı

Haber arşivinde sonsuz kaydırma kullanabilirsiniz, ama eski haberlerin Google tarafından bulunması için her parçanın kendi kalıcı URL'si ve sayfalar arasında gerçek bir a href bağı olması gerekir. Google'ın belgelerine göre tarayıcılar düğmelere "tıklamaz" ve kullanıcı eylemi gerektiren JavaScript'i genellikle çalıştırmaz. Yani yalnızca kaydırınca gelen bir akış, arşivin derinindeki haberleri görünmez bırakabilir. Önce desen seçilir (kaydırma, numaralı sayfa ya da ikisi birden), ardından URL ve geçmiş davranışı kurulur, en sonda sonuç betiksiz HTML ve URL Denetimi ile sınanır.

Yazı geliştiriciler, SEO uzmanları ve arşiv sayfasından sorumlu ürün ekipleri için. Genel sayfalama ilkeleri için kategori sayfalandırma rehberimize, görsel ve iframe yüklemesi için lazy loading yazımıza bakabilirsiniz. Mekanik ayrıntılar orada. Burada tek karar var: tarihli haberlerden oluşan bir arşivde sonsuz kaydırma mı, numaralı sayfalama mı, yoksa ikisinin birleşimi mi?

Sonsuz kaydırma Googlebot'a ne gösterir

Sonsuz kaydırma, kullanıcı sayfanın sonuna yaklaştıkça yeni içeriğin aynı sayfaya eklendiği bir arayüz desenidir. Kullanıcı için akıcıdır, ama arama motoru için sorun şudur: yeni içerik bir eyleme bağlıysa, o eylemi gerçekleştirecek kimse yoktur. Google'ın sayfalama belgesi bu noktada açıktır. Tarayıcılar genellikle a öğelerinin href niteliğindeki URL'leri tarar, düğmelere tıklamaz ve kullanıcı eylemi gerektiren JavaScript'i çoğu durumda tetiklemez.

Kullanıcı eylemine bağlı yükleme

Google'ın JavaScript tembel yükleme belgesi şunu söyler: Google Arama sayfanızla etkileşime girmez, bu yüzden içeriğin görünmesi için kaydırma ya da tıklama şart olmamalıdır. Bunu haber arşivine çevirelim. Ana sayfanın altına indikçe 20'şer haber ekleyen bir betik varsa ve bu haberlerin hiçbirinin ayrı bir bağlantısı yoksa, arşiv Google'ın gözünde ilk yüklenen kısımdan ibaret olabilir. Belge bunu yasaklamaz, ama sonucu net biçimde tarif eder: yalnızca etkileşimle ortaya çıkan içerik keşfedilmeyebilir.

Burada dikkat edilecek ince nokta şu: sorun kaydırma olayının kendisi değil, içeriğe giden tek yolun o olayın içinde kalması. Aynı haberlere kalıcı URL'li bir sayfa dizisi üzerinden de ulaşılabiliyorsa, kaydırma deneyimi yalnızca bir kullanıcı kolaylığına dönüşür.

Görünüm alanına girince yükleme

Belge, içeriğin görünüm alanına girdiğinde yüklenmesi için tarayıcının yerel tembel yükleme özelliğini, IntersectionObserver arayüzünü ve görünürlüğe duyarlı kütüphaneleri öneriyor. Ayrıca kullanıcının hemen göreceği içeriğin tembel yüklenmemesini, çünkü bunun yüklemeyi kullanıcının fark edeceği biçimde yavaşlatabileceğini belirtiyor. Haber sayfasında bunun karşılığı açık: ilk ekrandaki manşet ve ilk haber listesi sunucudan HTML içinde gelsin, ekran dışındaki parçalar sonradan yüklensin.

Belgelerde Googlebot'un görünüm alanı boyutu ya da kaç kez "kaydırdığı" gibi sayısal ayrıntılar yok. Bu yüzden "bot şu kadar kaydırır" türünden iddialara dayanmayın. Güvenli yol, kaydırmaya hiç bağımlı olmayan bir URL yapısıdır.

Hangi içerik neden kaybolur?

Pratikte arşivde şu üç durum görülür ve her birinin çözümü farklıdır:

• Yalnızca betikle gelen liste: HTML'de ilk parça var, geri kalanı bir API çağrısıyla ekleniyor ve haberlere giden bağlantı yok. Çözüm, her parçaya URL vermek ve bağlantıları HTML'e koymaktır.
• Düğmeyle açılan liste: "Daha fazla göster" bir düğme ve hedefi olmayan bir olay. Çözüm, düğmeyi gerçek bir bağlantıya dönüştürmek ya da yanına bağlantı koymaktır.
• Tek URL, değişen içerik: Aynı adres kaydırdıkça farklı haberleri gösteriyor ve yenilediğinizde başa dönüyor. Çözüm, geçmiş yönetimiyle URL'yi içeriğe bağlamaktır.

Bağlantılı sayfalama ile birlikte kullanım

Google'ın belgelerinde sonsuz kaydırma için önerilen yol, kaydırma deneyimini bağlantılı sayfalamanın üstüne kurmaktır. Yani her "parça" aslında numaralı sayfalama dizisindeki bir sayfadır: kendi URL'si, kendi içeriği ve sıradaki sayfaya giden gerçek bir bağlantısı vardır. Kaydırma betiği ise bu sayfaları kullanıcı için birbirine yapıştırır.

Her parçaya kalıcı ve benzersiz URL

JavaScript tembel yükleme belgesi şöyle der: her parçaya kalıcı ve benzersiz bir URL verin. Belgedeki tek örnek ?page=12 gibi mutlak sayfa numaralarıdır. Sayfalama belgesi de her sayfaya kendi URL'sini vermeyi, örneğin ?page=n parametresiyle, öneriyor. Haber arşivi için bu şuna benzer: /arsiv/siyaset?sayfa=1, ?sayfa=2 ve devamı. İlk sayfa için ek bir kısa adres de kullanabilirsiniz, ama dizinin geri kalanı sabit numaralarla ilerlemelidir.

Belge ayrıca göreli parametrelerden kaçınmayı söyler. ?tarih=dun gibi bir adres zamanla farklı içerik gösterir ve bu, URL'nin dizinlenmesini zorlaştırır. Arşivde bunun karşılığı "geçen hafta" ya da "son 24 saat" sayfalarıdır. Böyle bir süzgeç kullanıcı için yararlı olabilir, ama kalıcı arşiv adresi olarak mutlak tarih veya mutlak sayfa numarası kullanın.

Sayfaları sırayla bağlayın

Sayfalama belgesinin önerisi şu: her sayfadan sıradaki sayfaya a href bağlantısı koyun ve koleksiyonun sayfalarından ilk sayfaya geri bağlantı verin. İlk sayfaya geri bağlantı, Google'a bu sayfanın daha iyi bir giriş noktası olabileceği yönünde ipucu verir. Haber arşivi için bunun anlamı: sayfa 7'de en azından "önceki", "sonraki" ve "ilk sayfa" bağlantıları bulunsun. Çok uzun dizilerde belirli aralıklarla atlama bağlantıları eklemek kullanıcı için de faydalıdır; bu, belgenin dediği bir şey değil, tasarım tercihidir.

Sayfa başlıklarını ve açıklamalarını ayırmak

Sayfalama belgesi, sayfaların aynı başlığı ve açıklamayı kullanabileceğini söylüyor; ama normalde farklı başlıkların önerildiğini de ekliyor. Haber arşivinde bunu ucuza yapabilirsiniz. Şablon, kategori adına sayfa numarasını ekler: "Spor Haberleri, Sayfa 7". Açıklama alanında ise o sayfadaki en eski ve en yeni haberin tarih aralığını yazmak okuru da bilgilendirir. Ancak bu ayrım bir sıralama hilesi değil, arşivde "bu sayfa neresi?" sorusunun cevabıdır. Başlığa anahtar kelime yığmayın; Google'ın bağlantı belgesi de bağlantı metninde anahtar kelime doldurmanın spam politikasını ihlal edebileceğini hatırlatıyor.

Ne zaman sonsuz kaydırmadan vazgeçilir?

Üç işaret varsa kaydırmayı bırakıp numaralı sayfalamaya dönmeyi düşünün. Birincisi, kullanıcılar arşivde belirli bir haberi arıyorsa ve "şu tarihten önceki haberler" gibi hedefli gezinme istiyorsa. Sayfalama belgesi numaralı desenin konum hakkında fikir verdiğini yazar; kaydırma bunu vermez. İkincisi, ekibiniz her parça için sunucu tarafı bir URL ve geçmiş yönetimi bakımını üstlenemiyorsa. Yarım uygulanmış bir sonsuz kaydırma, hiç uygulanmamış bir sayfalamadan daha kırılgandır. Üçüncüsü, altbilgideki hukuki ve iletişim bağlantılarına ulaşmak yasal ya da ticari olarak önemliyse.

Canonical, başlık ve rel next/prev

Aynı belge birkaç net karar verir:

• Dizinin canonical adresi ilk sayfa olmasın. Her sayfa kendi canonical URL'sine sahip olsun.
• Sayfa numarası için # parçası kullanmayın. Google parça kısmını yok sayar ve bağlantıyı atlayabilir.
• Sayfalar aynı başlık ve açıklamayı paylaşabilir, ancak belge genellikle farklı başlıkları önerir. Haber arşivinde "Siyaset Haberleri, Sayfa 7" gibi bir ayrım yeterlidir.
• rel="next" ve rel="prev" etiketlerini Google artık kullanmıyor. Diğer arama motorları kullanabilir, ama bu etiketler Google için bir çözüm değildir.

Belge noindex etiketini ve robots.txt engelini, aynı listenin sıralama gibi istenmeyen varyasyonları için anıyor; numaralı sayfaların kendisini dizin dışı bırakmayı öneren bir ifade içermiyor. Bu ayrım önemlidir: ?sirala=populer gibi varyasyonları dizin dışında tutarken, numaralı arşiv sayfalarını dizinlenebilir bırakın.

URL'ler ve geçmiş (history) yönetimi

Kaydırma sırasında kullanıcı yeni bir parçaya geldiğinde adres çubuğu da güncellenmeli. Aksi halde kullanıcı sayfayı yenilediğinde başa döner, bağlantıyı paylaştığında arkadaşı başka bir yere düşer ve siz de hangi parçanın hangi URL'ye ait olduğunu analitikte göremezsiniz.

History API ile adres güncelleme

Yeni bir parça ana görünür içerik haline geldiğinde URL'yi History API ile güncellemek, kullanıcının yenileyebilmesi, paylaşabilmesi ve o anda görünen adrese bağlantı verebilmesi için gerekir (tembel yükleme belgesi). pushState ile replaceState arasındaki seçimi belge vermiyor; ayrıntılar tembel yükleme yazısında. Arşiv için asıl karar daha dar: hangi katmanlarda buna gerek var? Güncel akışın ilk parçalarında gerekir; kapanmış aylık arşiv sayfalarında gerekmez, çünkü her sayfa zaten kendi adresidir.

Yenileme ve doğrudan erişim

Kural basit: tarayıcıya yazılan /arsiv/siyaset?sayfa=7 adresi, sunucudan o parçanın içeriğini HTML içinde döndürmelidir. Betik yalnızca sayfa=1 yüklendikten sonra çalışıp 7. parçayı getiriyorsa, URL'niz bir yer imi değil bir bilmecedir. Bunu denemek için URL'yi yeni bir sekmeye yapıştırın, JavaScript'i kapatın ve sayfanın yine de o dilimin haberlerini listelediğini doğrulayın.

Parçanın kararlılığı

Belge, her yüklemede aynı içeriğin gelmesini bekliyor. Haber arşivinde kayan pencere sorunu burada ortaya çıkar: yeni haber yayımlandıkça 2. sayfadaki içerik 3. sayfaya kayar. Bu, ?sayfa=2 adresinin içeriğini sürekli değiştirir. Ortak çözümler şunlardır:

• Eski haberler için tarih tabanlı arşiv (ay veya gün sayfaları) kullanmak. Bir ayın haberleri sabittir.
• Canlı akışı yalnızca ilk birkaç sayfayla sınırlamak, derin arşivi tarih sayfalarına bırakmak.
• Sayfa başına öğe sayısını değiştirmemek, aksi halde tüm sınırlar kayar.

Haber siteleri için en dayanıklı model, güncel akışı kayan sayfalamayla, geçmiş içeriği ise tarih ve kategori kombinasyonuyla sunmaktır. Arşivin genel yapısı için haber sitesi arşiv yapısı kontrolü yazımız ayrıntı veriyor.

"Daha fazla yükle" düğmesi

Google'ın sayfalama belgesi üç deseni karşılaştırıyor: numaralı sayfalama, "daha fazla yükle" ve sonsuz kaydırma. Her birinin güçlü ve zayıf yanı var, ve haber arşivi için seçim büyüklüğe bağlıdır.

Düğme gerçek bir bağlantı olabilir

Düğme tek başına bir olay dinleyicisiyse tarayıcı onu takip edemez. Arşiv için asıl soru düğmenin nerede durduğudur: en yeni haberlerin üstündeki kısa ve güncel bir akış için uygundur ve a href olarak yazılıp hedefi sonraki arşiv sayfasının URL'si olmalıdır (örneğin /arsiv/siyaset?sayfa=2). JavaScript çalıştığında tıklama yakalanır ve parça aynı sayfaya eklenir; çalışmadığında bağlantı normal bir sayfaya gider.

Google'ın bağlantı belgesi a öğesinde onclick gibi ek niteliklere izin verir, yeter ki geçerli bir href bulunsun; href'siz onclick, span üzerindeki href ve javascript: sahte URL'lerini önermez.

Bağlantı metni ve erişilebilirlik

Aynı belge "buraya tıklayın" gibi genel ifadelerden kaçınmayı ister. Düğme metni "Siyaset haberlerinde sonraki sayfa" gibi bir ayrım taşırsa ekran okuyucu kullanan okurlar için de açıklayıcı olur.

Sonsuz akışta altbilgiye ulaşamama

Bir tasarım sorunu da SEO ile iç içe: sonsuz akışta altbilgi ve hukuki bağlantılar sürekli aşağı kayar. Kullanıcı hiçbir zaman altbilgiye ulaşamaz. Bu, belgenin söylediği bir şey değil, ama arşiv sayfasının sonunda "tüm arşive git", kategori bağlantıları ve iletişim gibi öğelerin sabit bir yerde durması gerektiğini gösteriyor. Çözüm, belirli bir parçadan sonra "daha fazla yükle" düğmesine dönmek ya da önemli bağlantıları sabit bir kenar çubuğuna taşımaktır.

Haber arşivi için karar kuralı

Elinizdeki içerik hacmine ve sayfanın amacına göre bir seçim yapın. Aşağıdaki kural, belgedeki karşılaştırmayı haber yayıncılığına uyarlar.

1. Derin arşiv, binlerce haber: numaralı sayfalama ya da tarih tabanlı arşiv. Her sayfa kalıcı URL taşır, sayfa numaraları ve atlama bağlantıları görünür.
2. Güncel akış, sınırlı derinlik: "daha fazla yükle" düğmesi, düğmenin altında gerçek sayfa bağlantısı.
3. Mobil ağırlıklı akış: sonsuz kaydırma kullanabilirsiniz, ama her parça bir sayfalama URL'sine karşılık gelsin ve kaydırma bittiğinde numaralı sayfalama bağlantıları görünsün.
4. Kayan içerik riski yüksekse: tarih sayfalarına geçin, sayfa numarası yerine ay ya da gün kullanın.

Bu kural bir Google gereksinimi değil. Google'ın belgeleri kaç haberin hangi desenle sunulacağını söylemiyor, yalnızca her desenin artı ve eksilerini sıralıyor. Karar sizin kullanıcı davranışınıza ve sunucu yükünüze bağlıdır.

Kuralı haberlerin yaşına göre uygulamak

Sitemap tamamlayıcıdır, çözüm değildir

Sayfalama belgesi, ürünlerin keşfini kolaylaştırmak için sitemap dosyasının düşünülebileceğini belirtir (örnek e-ticaret bağlamında, ama mantık haber için de geçerli). Haber arşivinde sitemap, her haberin adresini tek yerde toplamak için yararlıdır. Ancak sitemap bağlantı yapısının yerine geçmez; iç bağlantısı olmayan bir haber hem kullanıcı hem tarayıcı için zayıf bir sayfadır. Belgede sitemap'in bağlantı eksikliğini telafi ettiğine dair bir ifade yok.

Test: taranabilirlik kontrolü

Teorik olarak doğru görünen bir yapı, uygulamada kırılabilir. Aşağıdaki kontrol listesini yayına almadan önce ve her büyük arayüz değişikliğinden sonra uygulayın.

Kontrol listesi

• Her arşiv sayfası kendi URL'sinde, JavaScript kapalıyken de listeyi gösteriyor mu?
• Sayfalar arasında a href bağlantısı var mı, sıradaki ve ilk sayfaya geri bağlantı dahil mi?
• Sayfa numaraları için # parçası kullanılmıyor, değil mi?
• Her sayfanın canonical adresi kendisi mi, yoksa ilk sayfaya mı işaret ediyor? İlkini isteriz.
• "Daha fazla yükle" düğmesi gerçek bir bağlantı mı, yoksa yalnızca olay dinleyicisi mi?
• Kaydırma sırasında adres çubuğu güncelleniyor mu?
• Sıralama ve süzgeç varyasyonları dizin dışı bırakılmış mı?
• Her haberin arşiv dışında da en az bir iç bağlantısı var mı?

URL Inspection ile doğrulama

Google'ın tembel yükleme belgesi, içeriğin gerçekten yüklendiğini ve işlenmiş HTML'de göründüğünü Search Console'daki URL Inspection (URL Denetleme) aracıyla doğrulamayı öneriyor. Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir. Haber arşivi için adımlar şöyle:

1. Derin bir arşiv sayfasının URL'sini, örneğin 7. sayfayı, araca girin.
2. Canlı testi çalıştırın ve işlenmiş HTML'e bakın.
3. Listedeki haber bağlantılarının işlenmiş HTML'de a href olarak yer aldığını doğrulayın.
4. Sıradaki sayfa bağlantısının da orada olduğunu doğrulayın.

Belgede bu araç dışında bir otomatik test tarifi yok; Puppeteer gibi araçlardan söz edilmiyor. Kendi ekibiniz isterse bir tarayıcı otomasyonuyla "betiksiz HTML'de bağlantılar var mı" kontrolünü sürekli entegrasyona ekleyebilir; bu bir mühendislik tercihidir.

Sunucu kayıtlarıyla eşleştirme

Arama botlarının hangi sayfa numaralarına girdiğini sunucu erişim kayıtlarından izleyebilirsiniz. Eski sayfalara hiç istek gelmiyorsa bağlantı yapınız zayıf olabilir. Bu veri sayfa başına keşif hızını görmek için kullanışlıdır, ama dizine alma garantisi vermez; Google tarama ve dizinlemenin her sayfa için gerçekleşeceğini taahhüt etmez. Search Essentials sayfası da üç parçanın karşılanmasının bile içeriğin taranacağı ya da dizine alınacağı anlamına gelmediğini söylüyor.

Örnek senaryo: bölgesel haber sitesinin arşivi

Örnek senaryo: Bir bölgesel haber sitesinin spor kategorisi, masaüstünde numaralı sayfalama, mobilde sonsuz kaydırma kullanıyor. Mobil kullanıcılar sayfa 1'den başlıyor ve aşağı indikçe yeni haberler geliyor. Ekip arşivdeki eski haberlerin Google'da az göründüğünü fark ediyor ve nedeni araştırıyor.

İlk bulgu: mobil şablonda sayfa numaraları gizlenmiş ve sonraki parçalar bir API çağrısıyla, URL değiştirmeden ekleniyor. Masaüstü şablonunda ise sayfa bağlantıları var. Ekip kaydırma deneyimini korumaya karar veriyor, ama altına şu değişiklikleri yapıyor:

• Her parça için sunucuda ?sayfa=n URL'si hazırlanıyor ve bu URL'ler HTML liste döndürüyor.
• Kaydırma betiği parçayı eklerken adresi güncelliyor.
• Listenin altında, gizli olmayan "sonraki sayfa" bağlantısı kalıyor.
• Her sayfanın canonical adresi kendisi oluyor.
• Eski haberler için ay bazlı arşiv sayfaları ekleniyor.

Ekip sonrasında URL Inspection ile derin sayfaları sınıyor. Bu senaryoda iyileşmenin ne kadar sürdüğü ya da ne ölçüde olduğu konusunda bir sayı verilmiyor; sonuç sitenin otoritesine, haber hacmine ve tarama bütçesine bağlıdır. Önemli olan, düzeltmenin tahmine değil, doğrulanabilir bir kontrole dayanmasıdır.

Hangi ekip neyi üstlenir?

Sık görülen hatalar ve düzeltmeleri

Haber sitelerinde sonsuz kaydırmaya geçişte tekrar eden birkaç hata var. Hepsi önlenebilir, ama çoğu canlıya çıktıktan sonra fark ediliyor.

Tüm sayfaların aynı canonical'a işaret etmesi

Sayfalama belgesi ilk sayfayı dizinin canonical'ı yapmayı önermiyor. Şablonda "canonical her zaman kategori kök sayfası" kuralı varsa, derin sayfalar kök sayfaya bağlanır ve arşivin keşfi zayıflar. Sayfa şablonunda canonical'ı sayfa numarasına göre üretin.

Tüm sayfalara noindex eklemek

"Çift içerik riski" korkusuyla 2. sayfadan sonrasını noindex yapmak yaygın bir refleks. Belge noindex'i yalnızca sıralama gibi istenmeyen liste varyasyonları için anıyor. Numaralı arşiv sayfalarını noindex yaparsanız, o sayfalardan geçen bağlantı sinyali de zayıflayabilir ve haberler yalnızca sitemap'e bağımlı kalır. Belgede bu etkinin ayrıntıları yok; karar verirken test edin.

Yalnızca kaydırma olayını izlemek

Analitikte kaydırma olaylarını sayıyor ama sayfa görüntülemelerini ayrıca kaydetmiyorsanız, derin arşivin kullanımını göremezsiniz. Her parça için sanal sayfa görüntüleme olayı üretmek, hem kullanım hem tarama analizini kolaylaştırır. Bu bir ölçüm tercihi olarak değerlendirilir, Google gereksinimi değildir.

Reklam ve içerik dengesinde kayma

Sonsuz akışta her parçaya reklam yerleştirmek gelir modelinin parçasıdır. Dikkat edilecek nokta, yeni parçaların yüklenirken düzen kaymasına yol açmamasıdır. Belge bu konuyu işlemiyor; sayfa deneyimi için genel prensip, yer ayırma ve boyut tanımlamaktır. Reklam alanlarını nasıl sunduğunuz, kullanıcı deneyimini ve sonuç olarak sayfanın değerini etkiler.

Mevcut bir arşivi dönüştürmek: adım adım uygulama

Sıfırdan kurulan bir arşivde bu kararlar kolaydır. Zor olan, yıllardır çalışan ve sonsuz kaydırmayla yazılmış bir arşivi sorunsuz dönüştürmektir. Aşağıdaki sıra riski küçük tutar.

1. Envanter çıkarın. Arşivde hangi şablonların kaydırma kullandığını, hangilerinin numaralı sayfalama sunduğunu listeleyin. Kategori, etiket, yazar ve tarih arşivleri çoğu zaman farklı şablonlar kullanır.
2. Parça URL'lerini sunucuda üretin. Kaydırma betiğini dokunmadan bırakın; yalnızca betiğin çağırdığı veri uçlarının karşılığı olarak tam HTML sayfa döndüren adresler ekleyin.
3. Bağlantıları HTML'e koyun. Sıradaki sayfa bağlantısını liste altına yerleştirin. Önce görünür kılın, sonra tasarım gerekiyorsa betik çalıştığında gizleyin; bağlantı DOM'da kalsın.
4. Canonical ve başlıkları sayfa bazlı yapın. Şablondaki sabit canonical'ı sayfa numarasından üretilene çevirin.
5. Geçmiş yönetimini ekleyin. Parça görünür olduğunda adresi güncelleyin ve yenilemede doğru dilime inildiğini deneyin.
6. Test edin. Yukarıdaki kontrol listesini staging ortamında çalıştırın, ardından canlıda birkaç derin sayfayı URL Inspection ile sınayın.
7. İzleyin. Search Console'daki dizin kapsamı ve tarama istatistikleri ile sunucu kayıtlarını birkaç hafta takip edin. Arşivle ilgili bir düşüş görürseniz önce canonical ve bağlantı çıktısına bakın.

Burada bir süre ya da sayı vermiyoruz, çünkü Google belgelerinde yeniden taramanın ne zaman olacağına dair bir söz yok. Değişiklikten sonra beklemek dışında yapabileceğiniz şey, tarama için hazırlıklı olduğunuzdan emin olmaktır.

Sürümleme ve geri dönüş

Dönüşümü tek seferde bütün arşive açmak yerine önce tek bir kategoride yayına alın. Spor veya yerel haberler gibi hacmi orta bir kategori iyi bir deneme alanıdır. Sorun çıkarsa eski şablona dönmek kolay olur. Geri dönüş planınıza, değişen URL'ler için yönlendirme gereksiniminin olup olmadığını da ekleyin: mevcut URL'ler korunuyorsa yönlendirme gerekmez, ancak yeni adresler eskileri değiştiriyorsa 301 haritası hazır olmalıdır.

Teknik denetim içinde yeri

Sonsuz kaydırma kararı tek başına bir proje değil, teknik denetimin bir maddesidir. Teknik SEO denetimi kontrol listesi yazısındaki sıraya göre taranabilirlik, dizinlenebilirlik ve işleme adımlarını birlikte ele alın. Sayfalama düzeltmesi, bozuk bir canonical düzeltmesinden sonra gelebilir; öncelik sırası sitenin durumuna göre değişir.

Sürüm ve tarihe bağlı olarak Google belgelerindeki öneriler değişebilir; uygulamadan önce güncel sayfaya bakın. Bu yazıda anılan rel="next" ve rel="prev" durumu gibi ayrıntılar zamanla güncellenebilir.

İlgili rehberler: Haber Sitesi SEO Kontrol Listesi, Haber Sitesinde Article İşaretlemesi: Tarih ve Yazar Alanları, Haber Sitesinde Yapay Zeka ve Toplu İçerik: Spam Politikası Sınırları.

Sonuç

Sonsuz kaydırma tek başına haber arşivinin taranabilirliğini bozar; ama bağlantılı sayfalama ile birleştirildiğinde kullanıcıya akıcı bir deneyim, tarayıcıya erişilebilir bir arşiv sunar. Kural dört cümleyle özetlenebilir: her parçaya kalıcı ve benzersiz bir URL verin, parçaları gerçek a href bağlantılarıyla zincirleyin, kaydırma sırasında adresi History API ile güncelleyin ve her şeyi JavaScript kapalıyken ve URL Inspection ile sınayın. Derin arşiv için numaralı ya da tarih tabanlı sayfalama en az riskli seçimdir. Hiçbir desen sıralama garantisi vermez; amaç, haberlerin bulunabilir kalmasıdır.

Arşiv sayfalarının çevresinde reklam gelirini planlıyorsanız, Akua Adforce'ta reklam alanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.

Google'ın resmi çerçevesi için sayfalama ve artımlı yükleme (yeni sekmede açılır) belgesi, JavaScript tembel yükleme (yeni sekmede açılır) belgesi, taranabilir bağlantılar (yeni sekmede açılır) belgesi ve Search Essentials (yeni sekmede açılır) sayfası ilk başvuru noktalarıdır.

Sık Sorulan Sorular

Sonsuz kaydırma Google'da dizinlemeyi engeller mi?

Tek başına engellemez, ama içeriğe giden tek yol kaydırma ya da tıklama ise engel oluşturabilir. Google'ın belgelerine göre tarayıcılar düğmelere tıklamaz ve kullanıcı eylemi gerektiren JavaScript'i genellikle çalıştırmaz. Her parçaya kalıcı bir URL ve gerçek bağlantılar vermek sorunu çözer.

Haber arşivi için numaralı sayfalama mı daha güvenli?

Derin arşiv için evet, çünkü her sayfa doğal olarak kendi URL'sini taşır ve Google'ın "çok büyük sonuç kümelerini taşıyamaz" dediği tek sayfalı desenlerin sınırına takılmaz. Kullanıcı deneyimi için kaydırma tercih edilirse, altına numaralı sayfalama bağlantıları eklenmelidir.

Sayfa numarası için URL'de # kullanabilir miyim?

Hayır. Google'ın sayfalama belgesi, sayfa numaraları için parça (#) kullanılmamasını söylüyor, çünkü Google parçaları yok sayar ve bağlantıyı atlayabilir. ?sayfa=2 gibi bir sorgu parametresi ya da ayrı bir yol kullanın.

İlk sayfayı canonical yapmalı mıyım?

Google'ın belgesi dizinin ilk sayfasını tüm sayfaların canonical'ı yapmayı önermiyor. Her sayfa kendi canonical URL'sini taşımalıdır.

rel=next ve rel=prev hâlâ gerekli mi?

Google belgesine göre Google bu etiketleri artık kullanmıyor. Diğer arama motorları kullanabilir, ama Google için tek başına bir çözüm değildir; asıl önemli olan sayfalar arasındaki gerçek bağlantılardır.

Daha fazla yükle düğmesi taranabilir mi?

Düğme yalnızca olay dinleyicisiyse taranmaz. Hedef URL'ye giden gerçek bir bağlantı olarak yazılırsa, hem JavaScript'siz istemciler hem tarayıcılar sıradaki sayfaya ulaşabilir.