Panduan SEO Infinite Scroll

TL;DR — Infinite scroll memuat lebih banyak konten saat Anda menggulir ke bawah, bukan meminta Anda mengeklik halaman 2, halaman 3, dan seterusnya. Masalahnya: Googlebot tidak menggulir dan tidak mengeklik. Jadi, jika produk atau artikel baru muncul setelah pengunjung menggulir, Google mungkin tidak pernah melihatnya. Solusinya adalah memberi setiap “halaman” konten URL nyata tersendiri agar mesin pencari tetap memiliki sesuatu untuk di-crawl meskipun tidak pernah melakukan pengguliran.

Apa itu infinite scroll

Anda mungkin sudah ratusan kali menggunakannya tanpa menyebut namanya. Di feed media sosial, kategori belanja, atau artikel panjang, Anda terus menggulir dan konten baru terus muncul—tanpa tombol “Halaman berikutnya” atau nomor halaman. Itulah infinite scroll: JavaScript memantau seberapa jauh Anda menggulir, lalu mengambil dan menambahkan kelompok konten berikutnya saat Anda mendekati bagian bawah.

Pengalaman ini terasa mulus bagi manusia. Masalahnya, mesin pencari bukan manusia.

Mengapa pola ini berisiko bagi SEO

Google menemukan dan membaca halaman Anda dengan program otomatis bernama Googlebot. Googlebot memuat halaman, tetapi perilakunya tidak seperti pengunjung manusia:

• Googlebot tidak menggulir halaman.
• Googlebot tidak mengeklik tombol.

Karena itu, konten yang baru dimuat setelah seseorang menggulir (atau mengeklik “Muat lebih banyak”) pada dasarnya tidak tersedia bagi Googlebot. Jika halaman kategori menampilkan 24 produk terlebih dahulu dan memuat sisanya ketika digulir, Google mungkin hanya akan melihat 24 produk pertama tersebut.

Satu aturan yang membuatnya aman

Inti solusinya dapat diringkas dalam satu kalimat: setiap kelompok konten harus memiliki alamat web nyata tersendiri.

Selain mengandalkan pengguliran, penerapan yang ramah mesin pencari menyediakan halaman biasa yang dapat di-crawl di balik layar—example.com/shoes?page=2, ?page=3, dan seterusnya—serta menghubungkannya dengan tautan normal yang dapat diikuti Google. Infinite scroll memberi pengalaman yang nyaman bagi manusia; URL bernomor menjadi jaring pengaman bagi mesin pencari. Penerapan modern bahkan mengganti alamat di bilah browser saat Anda menggulir, sehingga URL yang disalin akan kembali ke posisi yang sama.

Kekeliruan yang paling sering terjadi

• “Google kini dapat merender JavaScript, jadi pasti akan memahami semuanya.” Google memang dapat menjalankan JavaScript Anda, tetapi tetap tidak akan menggulir atau mengeklik untuk memicu pemuat. Mampu merender tidak sama dengan melakukan interaksi.
• “Tombol ‘Muat lebih banyak’ lebih aman daripada pengguliran otomatis.” Benar hanya jika tombol itu merupakan tautan nyata ke halaman nyata. Tombol yang sekadar menjalankan penangan klik juga tidak terlihat oleh Google.
• “Jika halaman tidak terindeks, berarti Google mengabaikannya.” Pada infinite scroll, “tidak terindeks” kadang berarti kontennya tanpa sengaja digabungkan ke halaman lain— masalah berbeda yang memerlukan solusi berbeda.

Infinite scroll tidak dilarang atau dikenai penalti. Jika diterapkan dengan benar— dengan URL nyata sebagai fondasinya—pola ini tidak bermasalah. Ingin memahami mengapa dua halaman kadang terindeks sebagai satu serta pola kode untuk menerapkannya? Buka tab Lanjutan.

TL;DR — Googlebot tidak pernah menggulir atau mengeklik, sehingga konten yang bergantung pada pengguliran tidak terlihat secara bawaan. Google mengatasinya dengan merender dalam viewport yang sangat tinggi (sekitar 411×12 140px di perangkat seluler dan 1024×9 307px di desktop). Namun, tinggi yang sama dapat memicu pemuat saat proses rendering, menyatukan halaman logis berikutnya dengan halaman saat ini sehingga dua halaman terindeks sebagai satu URL. Solusi yang tahan lama bersifat arsitektural: URL absolut, persisten, dan unik untuk setiap kelompok (misalnya ?page=12), tautan yang dapat di-crawl, serta History API untuk memperbarui bilah alamat ketika kelompok utama berubah. rel=next/rel=prev sudah usang bagi Google (ditinggalkan pada 2019), tetapi masih dipakai Bing. Untuk PLP ecommerce, gunakan sitemap atau feed Merchant Center sebagai jalur penemuan cadangan. Verifikasi semuanya melalui HTML hasil render di Alat Inspeksi URL.

Pertama, bedakan dua hal

Jika menelusuri “Google infinite scroll”, Anda akan menemukan hasil tentang pengguliran berkelanjutan milik Google pada halaman hasil penelusurannya—fitur SERP yang sempat diaktifkan lalu dihentikan pada pertengahan 2024. Itu adalah keputusan UX untuk produk Google dan tidak berkaitan dengan cara Googlebot meng-crawl situs Anda. Artikel ini membahas hal yang kedua: infinite scroll sebagai pola pemuatan pada halaman Anda sendiri dan apakah Google dapat mengindeks konten yang dimuatnya.

Kendala utama: Google tidak berinteraksi dengan halaman Anda

Semua pembahasan ini bermula dari satu fakta. Dokumentasi lazy-loading Google menyatakan: recommended patterns “don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (terjemahan) “Pola yang disarankan tidak bergantung pada tindakan pengguna, seperti menggulir atau mengeklik, untuk memuat konten; hal ini penting karena Google Penelusuran tidak berinteraksi dengan halaman Anda.” Dokumentasi paginasi menyatakannya lebih lugas: “Google’s crawlers don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions to update the current page contents.” (terjemahan) “Crawler Google tidak mengeklik tombol dan umumnya tidak memicu fungsi JavaScript yang memerlukan tindakan pengguna untuk memperbarui isi halaman saat ini.”

Seperti yang saya tulis dalam panduan SEO JavaScript: “Googlebot tidak melakukan tindakan di halaman web. Ia tidak akan mengeklik atau menggulir, tetapi bukan berarti tidak memiliki cara lain. Selama konten dimuat ke DOM tanpa memerlukan tindakan, Google akan melihatnya. Jika konten baru dimuat ke DOM setelah klik, konten itu tidak akan ditemukan.”

Jadi, infinite scroll yang hanya terpicu oleh peristiwa pengguliran nyata sudah menjadi masalah penemuan konten sebelum menjadi masalah lainnya.

Cara Google mengatasinya: viewport yang sangat tinggi

Google tidak menyimulasikan pengguliran. Google merender halaman dalam viewport yang sangat tinggi sehingga konten beberapa layar di bawah sudah berada dalam area render. Catatan John Mueller pada 2017 menyatakan bahwa “Googlebot renders with a very tall viewport, which skews some CSS (often images). Try in Chrome dev-tools, eg 9000px high viewport.” (terjemahan) “Dengan viewport yang amat tinggi, render Googlebot dapat mengubah tampilan sejumlah CSS, terutama gambar. Uji kondisi itu di Chrome DevTools pada tinggi sekitar 9000px.”

Angka spesifik yang pernah saya dokumentasikan: untuk perangkat seluler, Google memuat halaman pada ukuran layar 411×731 piksel lalu mengubah tingginya menjadi 12 140 piksel— “pada dasarnya menjadi ponsel sangat panjang dengan ukuran layar 411×12140 piksel. Untuk desktop, Google melakukan hal serupa, dari 1024×768 piksel menjadi 1024×9307 piksel.” (Saya belum melihat pengujian ulang terbaru atas angka persis tersebut, dan hasilnya dapat berubah mengikuti panjang halaman; dimensi awal berasal dari pengujian independen peneliti SEO JR Oakes.) Intinya bukan angka piksel yang persis, melainkan Google meniru kemampuan “melihat jauh ke bawah halaman” melalui ketinggian, bukan gerakan.

Perlakukan dimensi piksel persis dan perilaku penggabungan dua halaman di bawah sebagai pengamatan lama yang bergantung pada penerapan, bukan kontrak platform yang stabil. Google tidak menerbitkan spesifikasi resmi untuk angka maupun perilaku rendering tersebut, dan keduanya dapat berubah. Jangan berasumsi situs Anda berperilaku sama; konfirmasikan perilaku terkini untuk URL Anda dengan pengujian HTML hasil render pada bagian berikutnya.

Mode kegagalan yang jarang dijelaskan: dua halaman terindeks sebagai satu

Di sinilah viewport tinggi menimbulkan masalah. Karena viewport render sangat tinggi, pemuat berbasis pengguliran dapat terpicu selama rendering meskipun tidak ada pengguliran dalam arti manusia—tinggi DOM saja dapat memenuhi syarat IntersectionObserver atau pemeriksaan posisi gulir. Ketika itu terjadi, pemuat menambahkan konten halaman logis berikutnya ke hasil render halaman saat ini, lalu Google mengindeks hasil gabungan tersebut sebagai satu URL.

Saya sudah beberapa kali mendiagnosis masalah ini. Dari panduan SEO JavaScript saya:

“Masalah lain yang pernah saya lihat dalam penerapan ini adalah sesekali dua halaman terindeks sebagai satu. Beberapa kali orang mengatakan halaman mereka tidak dapat diindeks, tetapi saya menemukan kontennya terindeks sebagai bagian dari halaman lain— biasanya posting sebelumnya.”

“Teori saya: ketika Google memperpanjang viewport, tindakan itu memicu infinite scroll dan memuat artikel lain saat rendering. Dalam kasus ini, saya menyarankan pemblokiran berkas JavaScript yang menangani infinite scroll agar fungsi tersebut tidak terpicu.”

John Mueller menjelaskan mekanisme yang sama dalam sesi office hours 2022. Menurutnya, viewport tinggi Google “would trigger some amount of infinite scrolling,” (terjemahan) “akan memicu sejumlah pengguliran tak terbatas,” dan Google mungkin memuat “two or three of these pages loaded on one page,” (terjemahan) “dua atau tiga halaman ini dalam satu halaman,” tetapi tidak semuanya. (Kutipan ini disampaikan melalui Search Engine Journal dan belum dikonfirmasi terhadap rekaman primer.)

Dari sini muncul dua konsekuensi:

1. Tidak ada jaminan berapa banyak yang ikut dimuat. Mungkin tidak ada tambahan, mungkin dua atau tiga halaman, tetapi tidak pernah dapat diandalkan untuk memuat semuanya. Infinite scroll saja bukan cara andal untuk mengindeks konten yang dalam.
2. “Tidak terindeks” dapat menjadi diagnosis yang keliru. Halaman yang tampak hilang mungkin sebenarnya terindeks sebagai bagian dari URL sebelumnya. Solusinya berbeda dari perbaikan masalah pengindeksan biasa.

Cara mendiagnosisnya

Gunakan Alat Inspeksi URL di Search Console dan baca HTML hasil render, bukan kode sumber mentah. Dokumentasi Google menjelaskan: “Anda dapat menggunakan Alat Inspeksi URL di Search Console untuk melihat apakah seluruh konten sudah dimuat. Periksa HTML hasil render untuk memastikan konten Anda ada di sana dengan mencarinya melalui Alat Inspeksi URL.” Cari konten yang seharusnya hanya ada di halaman 1. Jika konten halaman 2 (atau artikel berikutnya) muncul dalam hasil render halaman 1, Anda telah mereproduksi bug penggabungan.

Anda juga dapat mereplikasi viewport tinggi secara lokal: buka Chrome DevTools, atur viewport khusus yang sangat tinggi (Mueller menyarankan sekitar 9000px), lalu muat halaman untuk melihat apakah pemuat terpicu tanpa pengguliran.

Solusi: URL berhalaman + History API

Solusi tahan lama bersifat arsitektural dan berasal langsung dari dokumentasi lazy-loading Google saat ini. Agar infinite scroll dapat diindeks, “pastikan situs Anda mendukung pemuatan berhalaman untuk kelompok-kelompok konten ini”:

• “Berikan URL persisten dan unik kepada setiap kelompok.”
• “Pastikan konten yang ditampilkan pada setiap URL tetap sama setiap kali dimuat di browser”—Google menyarankan nomor halaman absolut seperti ?page=12.
• “Hindari elemen relatif seperti ?date=yesterday dalam URL tersebut”—alamat yang mengembalikan konten berbeda pada setiap pemuatan tidak dapat menjadi kanonis.
• “Tautkan secara berurutan ke masing-masing URL agar mesin pencari dapat menemukan URL dalam rangkaian paginasi”—gunakan tautan <a href> nyata, bukan penangan klik.
• “Ketika kelompok halaman baru dimuat sebagai respons atas pengguliran dan menjadi elemen utama yang terlihat, perbarui URL yang ditampilkan menggunakan History API.”

Poin terakhir adalah bagian yang elegan. history.pushState() / replaceState() mengganti URL di bilah alamat saat pengguna melewati setiap batas, sehingga URL yang terlihat selalu cocok dengan konten utama dan pengguna dapat memuat ulang, membagikan, serta menautkan ke posisi yang tepat. Sementara itu, URL ?page=N yang dapat di-crawl tetap tersedia secara mandiri, sehingga Google dapat mencapai setiap kelompok secara langsung, terlepas dari apakah renderer pernah memicu pengguliran.

Dua catatan penerapan yang penting:

• Gunakan IntersectionObserver (atau lazy-loading bawaan browser), bukan listener scroll mentah. Kinerjanya jauh lebih baik karena tidak membebani setiap pengguliran, dan mekanisme “muat saat terlihat” ini direkomendasikan Google untuk konten tertunda.
• Pastikan rangkaian paginasi dapat ditemukan secara independen dari JavaScript. Sediakan anchor nyata dalam DOM dan/atau cantumkan URL ?page=N dalam sitemap XML. Apa pun yang ditangkap renderer, lapisan sitemap dan tautan menjadi jalur cadangan.

Jika situs aktif sudah mengalami bug penggabungan dan Anda perlu menghentikan dampaknya sebelum membangun ulang, perbaikan darurat yang lugas adalah memblokir berkas JavaScript yang memicu infinite scroll di robots.txt agar tidak dapat dijalankan saat rendering. Langkah ini memberi waktu untuk menerapkan arsitektur URL berhalaman yang semestinya.

Status navigasi: kembali, maju, muat ulang, dan berbagi harus merekonstruksi tampilan yang sama

Poin History API di atas baru mencakup separuh kontrak: memperbarui bilah alamat ketika sebuah kelompok menjadi utama. Separuh lainnya adalah memastikan setiap jalur masuk kembali ke URL tersebut merekonstruksi konten yang tepat, bukan hanya posisi gulir yang tepat:

• Gunakan pushState() ketika sebuah kelompok menjadi konten utama yang terlihat untuk pertama kalinya. Itu merupakan langkah navigasi nyata dan membuat tombol kembali bermakna.
• Gunakan replaceState() untuk koreksi yang tidak perlu membuat titik berhenti tersendiri, seperti menyelaraskan URL setelah pengguliran cepat melewati beberapa kelompok sekaligus.
• Dengarkan popstate, lalu render ulang (atau ambil ulang) kelompok yang cocok dengan URL pada peristiwa tersebut. Perilaku kembali/maju bawaan browser memulihkan posisi gulir, bukan status daftar dinamis yang dibangun JavaScript. Jika pemuat telah menambahkan 40 item, Anda harus merekonstruksi item milik halaman itu, bukan sekadar menggulir ke sana.
• Jangan mengandalkan pemulihan gulir otomatis saja. Fitur itu mengatur posisi viewport, bukan konten yang tersedia. Jika daftar dapat berubah antarkunjungan, posisi gulir tanpa rekonstruksi konten dapat menempatkan pengguna dalam konteks yang salah.

Ini adalah disiplin yang sama dengan solusi URL berhalaman: URL sebuah kelompok harus mengembalikan konten yang dijanjikannya ketika dibuka langsung, dimuat ulang, dan diuji secara langsung di Search Console—bukan hanya saat pertama kali diambil di tengah guliran.

Status pemuatan, kesalahan, dan akhir hasil

Penerapan untuk produksi memerlukan lebih banyak status daripada sekadar “memuat” dan “dimuat”:

• Pemuatan awal—kelompok pertama seharusnya sudah ada dalam HTML mentah yang dikirim server, bukan seluruhnya dirakit JavaScript sesudahnya.
• Memuat kelompok berikutnya—tampilkan indikator proses agar pengguna dan penguji teknologi bantu mengetahui bahwa pengambilan data sedang berlangsung.
• Kosong—sediakan status khusus untuk nol hasil, bukan ruang kosong yang tampak rusak.
• Kesalahan / coba lagi—pengambilan yang gagal tidak boleh membuat halaman buntu tanpa cara mencoba lagi; percobaan ulang juga tidak boleh menggandakan atau mengubah urutan item.
• Akhir hasil—tampilkan sinyal yang jelas, bukan indikator berputar tanpa akhir, ketika tidak ada lagi yang dapat dimuat.

Semua ini tidak khusus untuk Google, tetapi mencerminkan keandalan yang juga dibutuhkan solusi URL berhalaman. Jika pemuat dapat diam-diam gagal di tengah pengambilan, Anda tidak dapat memastikan suatu crawl atau sesi pengguna menangkap kelompok yang seharusnya.

Aksesibilitas dan performa: dua hal yang tidak otomatis diberikan infinite scroll

Infinite scroll tidak memiliki dampak Core Web Vitals yang melekat, baik atau buruk; hasilnya sepenuhnya bergantung pada penerapan. Setiap kelompok tambahan memperbesar DOM, dan DOM yang cukup besar meningkatkan biaya tata letak serta penghitungan ulang gaya. Pantau biaya penambahan, pemuatan gambar, pergeseran tata letak akibat ruang yang tidak dicadangkan, dan tugas panjang ketika daftar membesar. Pada halaman sangat panjang, pertimbangkan virtualisasi kelompok yang sudah jauh di luar tampilan dengan menghapus node DOM-nya agar DOM tidak tumbuh tanpa batas.

Aksesibilitas memerlukan rancangan khusus, bukan asumsi bahwa “jika dapat dirender berarti sudah baik”:

• Pengguna keyboard harus dapat mencapai konten baru serta footer atau navigasi akhir halaman tanpa urutan tab terus bergeser akibat halaman yang diam-diam memanjang.
• Pengguna pembaca layar perlu mendapat pemberitahuan tentang konten baru tanpa gangguan; region status yang sopan biasanya lebih tepat daripada peringatan yang menginterupsi.
• Pola desain feed WAI-ARIA dibuat untuk kasus ini: region setingkat artikel dalam kontainer feed, dengan perilaku keyboard yang jelas untuk berpindah antaritem dan mencapai konten sebelum maupun sesudah feed.
• Fokus tidak boleh berpindah atau hilang tanpa penjelasan ketika kelompok baru dimuat.

Ini bukan pekerjaan tambahan yang opsional. Inilah perbedaan antara infinite scroll yang berfungsi bagi semua orang dan penerapan yang hanya berfungsi bagi pengguna mouse, JavaScript, dan jalur ideal.

Konteks historis: rel=next/prev sudah usang

Jika Anda mempelajari paginasi bertahun-tahun lalu, Anda mengenal rel="next" / rel="prev". Google memperkenalkannya pada 2011 dan memasangkannya dengan “rekomendasi infinite scroll yang ramah penelusuran” pada 2014 (membuat paginasi konten dan menyediakan halaman komponen). Pada 2019, Google mengumumkan bahwa tag tersebut sudah bertahun-tahun tidak digunakan dan resmi meninggalkannya. Dokumentasi paginasi kini menegaskan: “Dahulu, Google menggunakan <link rel="next" href="..."> dan <link rel="prev" href="..."> untuk mengidentifikasi hubungan halaman berikutnya dan sebelumnya. Google tidak lagi menggunakan tag tersebut, meskipun tautannya mungkin masih dipakai mesin pencari lain.”

Jadi, resep Google saat ini adalah URL unik + tautan yang dapat di-crawl + History API; rel=next/rel=prev tidak diwajibkan. Namun, “mesin pencari lain” mencakup Bing, yang masih menggunakannya. Menyimpan tag tersebut dalam markup dapat memberi manfaat lintas mesin dan aksesibilitas. Bing tidak menerbitkan panduan khusus infinite scroll; posisinya bermuara pada peringatan umum tentang rendering JavaScript: bingbot dapat merender JavaScript, tetapi “sulit bagi bingbot untuk memproses JavaScript dalam skala besar”. Karena alasan yang sama seperti pada Google, cadangan paginasi yang dapat di-crawl membantu Bing.

Halaman kategori ecommerce: kasus dengan risiko terbesar

Penggunaan infinite scroll yang paling umum adalah pada halaman kategori / daftar produk (PLP) ecommerce, dan di sinilah risikonya menimbulkan kerugian nyata. Jika produk dalam katalog yang dalam, setelah layar pertama, tidak pernah terindeks, produk tersebut tidak dapat memperoleh peringkat dan Anda kehilangan trafik organik long-tail di tingkat produk. Materi halaman kategori membahas wilayah yang sama secara mendalam; infinite scroll menjadi alasan tambahan mengapa UX tersebut memerlukan struktur yang dapat di-crawl.

Dua jalur cadangan penting dalam kasus ini:

• Sitemap XML yang mencantumkan setiap produk kanonis dan URL kategori berhalaman, sehingga penemuan tidak bergantung pada renderer.
• Feed produk Merchant Center, yang memberikan data produk kepada Google secara independen dari apa pun yang ditangkap renderer halaman kategori.

Analisis Lumar terhadap peritel fesyen terkemuka di Inggris menyebut infinite scroll sebagai “pihak yang paling dirugikan dalam hal kemampuan pengindeksan dan keramahan SEO” di antara berbagai pola paginasi. Ini mengingatkan bahwa masalah tersebut bukan kasus tepi teoretis, melainkan kegagalan bawaan UX PLP yang sangat populer. (Baca angka persentase spesifik Lumar dari laporan langsungnya sebelum mengutip angka persis.)

Infinite scroll dibanding paginasi dan tombol muat lebih banyak

Dokumentasi paginasi Google menyajikan tiga pola UX dan menjelaskan pertukarannya secara terbuka. Infinite scroll “menggunakan satu halaman untuk semua konten” dan terasa “intuitif—pengguna hanya perlu terus menggulir”, tetapi dapat “menimbulkan kelelahan menggulir karena ukuran hasil tidak jelas” serta “tidak dapat menangani hasil dalam jumlah sangat besar”. Paginasi bernomor klasik paling tangguh untuk SEO karena setiap halaman secara bawaan memiliki URL nyata. “Muat lebih banyak” berada di tengah: baik jika tombolnya merupakan atau membungkus tautan nyata ke URL berhalaman, tetapi tidak berguna untuk SEO jika hanya berupa penangan klik.

Pertanyaannya bukan “pola mana yang diizinkan”—ketiganya diizinkan. Pertanyaannya: “UX mana yang Anda inginkan, dan apakah Anda sudah membangun lapisan URL yang dapat di-crawl di bawahnya?” Ringkasan Mueller pada 2023 mencakup semuanya: “jika setiap bagian atau halaman virtual juga dapat diakses dan ditemukan melalui URL unik, secara umum infinite scroll seharusnya tidak bermasalah.”

Ringkasan AI

Versi ringkas dari pembahasan Lanjutan:

• Kendala utama: Googlebot tidak menggulir atau mengeklik. Konten yang berada di balik peristiwa gulir atau klik tidak terlihat secara bawaan (“Google Penelusuran tidak berinteraksi dengan halaman Anda”).
• Cara Google mengatasinya: Google merender dengan viewport sangat tinggi (~411×12 140px seluler, ~1024×9 307px desktop), bukan dengan menggulir.
• Mode kegagalan: viewport tinggi dapat memicu pemuat selama rendering, menyatukan halaman logis berikutnya dengan halaman saat ini sehingga dua halaman terindeks sebagai satu URL. Halaman “tidak terindeks” mungkin sebenarnya terindeks di URL lain.
• Tidak ada jaminan: menurut Mueller, Google mungkin memuat “dua atau tiga halaman ini, tetapi tidak semuanya”. Infinite scroll saja bukan metode pengindeksan mendalam yang andal.
• Solusi arsitektural: URL absolut, unik, dan persisten per kelompok (misalnya ?page=12), tautan <a href> yang dapat di-crawl, serta History API (pushState/replaceState) untuk memperbarui bilah alamat saat kelompok menjadi utama.
• Mekanisme pemicu: gunakan IntersectionObserver / lazy-loading bawaan, bukan listener scroll mentah.
• Catatan lama: Google meninggalkan rel=next/rel=prev pada 2019; Bing masih mendukungnya, jadi pertahankan untuk manfaat lintas mesin.
• Ecommerce: PLP adalah kasus berisiko terbesar; dukung dengan sitemap dan feed Merchant Center. Verifikasi melalui HTML hasil render di Alat Inspeksi URL.
• Perbaikan darurat bug gabungan: blokir berkas JavaScript infinite scroll agar tidak terpicu saat rendering selama proses pembangunan ulang.
• Status navigasi: gunakan pushState untuk langkah navigasi nyata, replaceState untuk koreksi di tempat, dan penangan popstate yang merekonstruksi konten kelompok— bukan hanya posisi gulir—ketika pengguna kembali atau maju.
• Status pemuatan/kesalahan/akhir: bedakan pemuatan awal, pemuatan kelompok berikutnya, kosong, kesalahan/coba lagi, dan akhir hasil. Pemuat rusak adalah masalah keandalan sebelum menjadi masalah SEO.
• Aksesibilitas dan performa: infinite scroll tidak menentukan hasil Core Web Vitals; jangkauan keyboard, pemberitahuan yang tidak mengganggu, dan pola feed WAI-ARIA merupakan pekerjaan desain terpisah dari perbaikan pengindeksan.
• Pengamatan lama: perlakukan dimensi viewport persis dan mekanisme bug penggabungan sebagai hal spesifik penerapan, bukan spesifikasi stabil; verifikasi setiap URL.

Dokumentasi resmi

Dokumentasi sumber primer tentang infinite scroll, paginasi, dan rendering JavaScript.

Google

• Memperbaiki konten yang dimuat secara lazy —mencakup bagian “Mendukung pemuatan berhalaman untuk infinite scroll” (URL unik per kelompok, nomor halaman absolut, History API) serta langkah pengujian melalui Inspeksi URL. Terakhir diperbarui 2025-12-10.
• Paginasi, pemuatan halaman inkremental, dan dampaknya pada Google Penelusuran —tiga pola UX (paginasi / muat lebih banyak / infinite scroll), kelebihan dan kekurangannya, catatan interaksi crawler, serta penghentian rel=next/rel=prev.
• Rekomendasi infinite scroll yang ramah penelusuran —posting blog asli 2014 (bersifat historis; pasangan rel=next/rel=prev yang dijelaskan sudah digantikan).
• Transkrip SEO Office Hours September 2023 —penegasan Mueller yang tercatat tentang aturan URL unik.
• Memahami dasar SEO JavaScript —konteks rendering yang lebih luas untuk infinite scroll.

Bing / Microsoft

• Seri bingbot: JavaScript, Rendering Dinamis, dan Cloaking —panduan umum Bing tentang rendering JavaScript (tidak ada halaman khusus infinite scroll; Bing masih menggunakan rel=next/rel=prev).

Kutipan dari sumber

Pernyataan tercatat dari Google dan Bing. Setiap tautan menuju bagian yang dikutip pada halaman sumber.

Google—aturan infinite scroll dan pemuatan berhalaman

• “To implement infinite scroll in an indexable way, make sure your website supports paginated loading of these chunks.” (terjemahan) “Untuk menerapkan infinite scroll dengan cara yang dapat diindeks, pastikan situs Anda mendukung pemuatan berhalaman untuk kelompok-kelompok ini.”
• “Give each chunk its own persistent, unique URL.” (terjemahan) “Berikan URL persisten dan unik kepada setiap kelompok.” — Google Search Central, “Fix lazy-loaded content.” Buka kutipan
• “When a new page chunk is loaded in response to the user scrolling, and it becomes the primary visible element for the user, update the displayed URL using the History API.” (terjemahan) “Ketika kelompok halaman baru dimuat karena pengguna menggulir dan menjadi elemen utama yang terlihat, perbarui URL yang ditampilkan menggunakan History API.” Buka kutipan
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (terjemahan) “Metode tersebut tidak bergantung pada tindakan pengguna, seperti menggulir atau mengeklik, untuk memuat konten; hal ini penting karena Google Penelusuran tidak berinteraksi dengan halaman Anda.” Buka kutipan
• “You can use the URL Inspection Tool in Search Console to see if all content was loaded. Check the rendered HTML to make sure your content is in the rendered HTML by looking for it in URL Inspection Tool.” (terjemahan) “Anda dapat menggunakan Alat Inspeksi URL di Search Console untuk melihat apakah seluruh konten sudah dimuat. Periksa HTML hasil render untuk memastikan konten Anda ada di sana dengan mencarinya melalui Alat Inspeksi URL.” Buka kutipan

Google—dokumentasi paginasi: perilaku crawler dan rel=next/prev

• “Google’s crawlers don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions to update the current page contents.” (terjemahan) “Crawler Google tidak mengeklik tombol dan umumnya tidak memicu fungsi JavaScript yang memerlukan tindakan pengguna untuk memperbarui isi halaman saat ini.” Buka kutipan
• “In the past, Google used <link rel="next" href="..."> and <link rel="prev" href="..."> to identify next page and previous page relationships. Google no longer uses these tags, although these links may still be used by other search engines.” (terjemahan) “Dahulu, Google menggunakan rel=next dan rel=prev untuk mengidentifikasi hubungan halaman berikutnya dan sebelumnya. Google tidak lagi menggunakan tag tersebut, meskipun tautannya mungkin masih dipakai mesin pencari lain.” Buka kutipan

John Mueller, Google—office hours September 2023

• “It depends how you implement infinite scrolling. if each piece or virtual page is also accessible and findable through a unique URL, generally it should be fine to have infinite scroll.” (terjemahan) “Hal ini bergantung pada cara Anda menerapkan infinite scrolling. Jika setiap bagian atau halaman virtual dapat diakses dan ditemukan melalui URL unik, secara umum infinite scroll seharusnya tidak bermasalah.” Buka kutipan

John Mueller, Google—tweet “viewport 9000px” (November 2017)

• “Googlebot renders with a very tall viewport, which skews some CSS (often images). Try in Chrome dev-tools, eg 9000px high viewport.” (terjemahan) “Googlebot merender dengan viewport yang sangat tinggi, yang membuat sebagian CSS (sering kali gambar) menyimpang. Coba di Chrome DevTools, misalnya viewport setinggi 9000px.” — direproduksi oleh Search Engine Roundtable. Baca liputannya

Bing—rendering JavaScript umum (tanpa halaman khusus infinite scroll)

• “As we shared last week at SMX East, bingbot is generally able to render JavaScript. However, bingbot does not necessarily support all the same JavaScript frameworks that are supported in the latest version of your favorite modern browser.” (terjemahan) “Seperti yang kami sampaikan pekan lalu di SMX East, bingbot umumnya mampu merender JavaScript. Namun, bingbot tidak selalu mendukung semua kerangka JavaScript yang didukung versi terbaru browser modern favorit Anda.” — Fabrice Canel & Frédéric Dubut, Microsoft Bing. Buka kutipan

Pola paginasi mana yang sebaiknya digunakan?

Ikuti dari atas ke bawah.

1. Apakah konten setelah layar pertama perlu memperoleh peringkat di penelusuran?

• Tidak (misalnya feed internal atau dasbor yang memerlukan login) → pola apa pun dapat dipakai; optimalkan murni untuk UX.
• Ya → lanjutkan.

2. Apakah Anda sudah memiliki (atau dapat membangun) URL nyata untuk setiap kelompok?

• Tidak, dan tidak dapat membuatnya → gunakan paginasi bernomor klasik. Setiap halaman memiliki URL nyata secara bawaan, sehingga risikonya paling rendah untuk SEO.
• Ya → infinite scroll atau “muat lebih banyak” sama-sama dapat digunakan; lanjutkan.

3. Seberapa besar rangkaiannya?

• Sangat besar (ribuan item, katalog dalam) → pilih paginasi bernomor atau infinite scroll di atas URL nyata; infinite scroll murni “tidak dapat menangani hasil dalam jumlah sangat besar”. Tambahkan sitemap sebagai jalur penemuan cadangan.
• Sedang → infinite scroll atau muat lebih banyak, dengan URL berhalaman, dapat digunakan.

4. Saat membangun infinite scroll, apakah penerapannya terhubung ke URL nyata + History API?

• Tidak (hanya peristiwa gulir, tanpa URL) → jangan rilis. Penerapan inilah yang membuat konten dalam tergabung atau tidak terindeks.
• Ya (URL ?page=N + anchor yang dapat di-crawl + pushState) → rilis, lalu verifikasi HTML hasil render melalui Alat Inspeksi URL.

5. Situs sudah aktif dan halaman dalam “tidak terindeks”?

• Periksa lebih dahulu HTML hasil render dari halaman/posting sebelumnya di Alat Inspeksi URL; konten yang “hilang” mungkin tergabung di sana.
• Jika ya → perbaikan darurat: blokir berkas JavaScript infinite scroll agar tidak terpicu saat rendering, lalu bangun ulang di atas URL berhalaman.

Daftar periksa infinite scroll yang ramah penelusuran

• Setiap kelompok konten memiliki URL absolut, unik, dan persisten tersendiri (misalnya ?page=2, bukan ?date=yesterday).
• Setiap URL mengembalikan konten yang sama setiap kali dimuat (stabil, tidak bergantung pada sesi).
• Kelompok dihubungkan dengan tautan <a href> nyata, yang dapat ditemukan tanpa menjalankan JavaScript.
• URL yang terlihat diperbarui melalui History API (pushState/replaceState) ketika setiap kelompok menjadi konten utama.
• Pemuat menggunakan IntersectionObserver (atau lazy-loading bawaan), bukan listener peristiwa scroll mentah.
• URL berhalaman dicantumkan dalam sitemap XML (dan untuk ecommerce didukung feed Merchant Center).
• rel=next/rel=prev tersedia secara opsional bagi Bing (tidak berbahaya bagi Google, yang mengabaikannya).
• Alat Inspeksi URL → HTML hasil render memastikan konten dalam tersedia dan tidak tergabung dari halaman berdekatan.
• Pengujian lokal dengan viewport DevTools tinggi (~9000px) memastikan pemuat tidak terpicu berlebihan saat render.
• Penangan popstate merekonstruksi konten kelompok saat kembali/maju, bukan hanya posisi gulir.
• Status memuat, kesalahan/coba lagi, kosong, dan akhir hasil berbeda; pengambilan yang gagal tidak diam-diam membuat halaman buntu.
• Pengguna keyboard dapat mencapai konten baru dan footer; konten baru diumumkan melalui region status yang sopan, bukan peringatan yang mengganggu.

Hal-hal yang merusak infinite scroll untuk SEO

Pemuatan hanya melalui peristiwa gulir tanpa URL nyata. Ini kesalahan klasik. Konten baru ada di DOM setelah pengguliran terpicu; Googlebot tidak pernah menggulir sehingga konten tidak terlihat. Tidak ada yang dapat di-crawl maupun dijadikan cadangan.

Tombol “Muat lebih banyak” yang hanya berupa penangan klik. Terasa lebih aman daripada pengguliran otomatis, padahal tidak. Google juga tidak mengeklik tombol. Tombol hanya membantu jika merupakan (atau membungkus) <a href> nyata menuju URL berhalaman.

URL fragmen/hash untuk paginasi (#page=2). Fragmen tidak membuat URL berbeda yang dapat di-crawl. Gunakan URL berbasis parameter kueri atau path nyata.

URL relatif atau tidak stabil (?date=yesterday, konten khusus sesi). Jika URL yang sama mengembalikan konten berbeda pada pemuatan berbeda, URL itu tidak dapat menjadi halaman stabil yang dapat diindeks. Gunakan nomor halaman absolut.

Mengabaikan bug penggabungan viewport tinggi. Jangan berasumsi “tidak terindeks” berarti Google mengabaikan halaman. Pada infinite scroll, konten sering kali tersatukan ke URL berdekatan karena pemicu saat render—masalah berbeda yang memerlukan perbaikan berbeda.

Memblokir seluruh JavaScript/CSS sebagai “solusi”. Memblokir berkas pemicu infinite scroll tertentu adalah langkah darurat yang disengaja. Memblokir semua JavaScript/CSS bukan solusi; tindakan itu merusak rendering seluruh halaman.

Infinite scroll SEO—ringkasan cepat

Tiga pola UX

Syarat mutlak infinite scroll

• URL unik, absolut, dan persisten per kelompok (?page=12).
• Konten yang sama pada setiap pemuatan (bukan ?date=yesterday).
• Tautan <a href> yang dapat di-crawl antarkelompok.
• History API (pushState/replaceState) untuk menyelaraskan bilah alamat.
• IntersectionObserver, bukan listener scroll mentah.

Fakta singkat

• Googlebot: tidak menggulir, tidak mengeklik.
• Viewport render (dilaporkan): ~411×12 140px seluler, ~1024×9 307px desktop.
• Bug penggabungan: viewport tinggi dapat memicu pemuat saat render → dua halaman terindeks sebagai satu.
• rel=next/rel=prev: ditinggalkan Google pada 2019; masih dipakai Bing.
• Verifikasi: Alat Inspeksi URL → HTML hasil render.
• Perbaikan darurat pada bug gabungan aktif: blokir berkas JavaScript infinite scroll.

Gambaran penerapan yang baik dan buruk

Buruk—hanya pengguliran, tidak terlihat oleh Google

Halaman kategori mengirim 24 produk dalam HTML. Listener scroll mengambil 24 berikutnya lalu menambahkannya. Tidak ada URL ?page=N, anchor, atau History API. Googlebot memuat halaman, tidak menggulir, dan mengindeks 24 produk. Sebanyak 300 produk lain dalam katalog tidak dapat ditemukan melalui halaman tersebut.

Buruk—bug penggabungan di situs nyata

Blog penerbit memakai infinite scroll untuk menambahkan posting berikutnya di bawah posting saat ini. Seorang penulis mengeluh artikel barunya “tidak mau terindeks”. Artikel itu sebenarnya terindeks—sebagai bagian dari URL posting sebelumnya—karena viewport render Google yang tinggi memicu pemuat dan memasukkan artikel berikutnya ke hasil render halaman saat ini. Solusi: buat paginasi yang benar dan, sementara itu, blokir skrip pemicu infinite scroll.

Baik—infinite scroll di atas URL nyata

Kategori yang sama tersedia di /shoes?page=1, /shoes?page=2, …; masing-masing merupakan URL nyata dengan konten stabil, tercantum dalam sitemap XML, dan dihubungkan dengan <a href> di bawah daftar. Untuk manusia, IntersectionObserver memuat kelompok berikutnya ketika mereka mendekati bagian bawah, lalu history.pushState() memperbarui bilah alamat menjadi ?page=2 saat kelompok itu menjadi konten utama. Google mencapai setiap halaman secara langsung melalui tautan dan sitemap; UX pengguliran hanya menjadi peningkatan tambahan.

Cuplikan penerapan dan diagnosis

Pola History API (sisi klien)

Muat setiap kelompok saat hampir memasuki tampilan menggunakan IntersectionObserver, lalu ganti URL yang terlihat ketika kelompok tersebut menjadi utama. Kuncinya, URL ?page=N merupakan halaman nyata yang tersedia di server terlepas dari skrip ini.

// A sentinel element sits at the bottom of the current chunk.
const sentinel = document.querySelector('#load-more-sentinel');
let nextPage = 2;

const io = new IntersectionObserver(async (entries) => {
  if (!entries[0].isIntersecting) return;
  const res = await fetch(`/shoes?page=${nextPage}&partial=1`);
  const html = await res.text();
  document.querySelector('#product-grid').insertAdjacentHTML('beforeend', html);

  // Update the address bar so refresh/share/link land on this chunk.
  // pushState adds a history entry; replaceState if you don't want back-button steps.
  history.pushState({ page: nextPage }, '', `/shoes?page=${nextPage}`);
  nextPage++;
}, { rootMargin: '600px' }); // start loading before the user hits the very bottom

io.observe(sentinel);

Yang terpenting, cadangan yang dapat di-crawl tetap ada dalam DOM—tautan inilah yang diikuti Google:

<nav aria-label="Pagination">
  <a href="/shoes?page=2" rel="next">Next</a>
  <!-- rel="next"/"prev" is ignored by Google since 2019 but still used by Bing -->
</nav>

Konsol DevTools: apakah pemuat terpicu tanpa pengguliran nyata?

Simulasikan viewport tinggi Google secara lokal, lalu periksa apakah kelompok tambahan memuat sendiri. Di Chrome DevTools, atur viewport perangkat khusus yang sangat tinggi (~1024×9000), muat ulang, lalu jalankan perintah berikut di Konsol untuk menghitung kelompok yang tersedia tanpa pengguliran manual:

// Count rendered product cards (adjust the selector to your markup)
console.log('cards rendered without scrolling:', document.querySelectorAll('#product-grid .product-card').length);
// If this is much higher than your per-page count, the loader is over-firing on height alone.

Konsol DevTools: pastikan URL berhalaman benar-benar tersedia

Sebelum mengandalkan cadangan, verifikasi bahwa setiap ?page=N mengembalikan konten nyata dan berbeda dari sisi server (bukan route yang hanya bekerja dengan JavaScript):

// Run in the console; a real paginated URL should return HTML containing products.
for (const n of [2, 3, 4]) {
  const html = await (await fetch(`/shoes?page=${n}`)).text();
  console.log(`page ${n}: ${html.includes('product-card') ? 'has products ✅' : 'EMPTY — JS-only? ❌'}`);
}

Bookmarklet: langsung buka pemeriksaan HTML hasil render sebuah halaman

Seret bookmarklet ini ke bilah bookmark untuk membuka URL saat ini di Alat Inspeksi URL Search Console. Di sana, baca HTML hasil render (bukan kode sumber) untuk melihat seberapa jauh konten yang ditangkap Google:

javascript:(()=>{const u=encodeURIComponent(location.href);open('https://search.google.com/search-console/inspect?resource_id=&id='+u,'_blank');})();

Buktikan infinite scroll dapat diindeks setelah diluncurkan

Uji grid produk yang dimuat secara lazy tanpa mencampur status browser

Satu tangkapan layar dari jendela browser tinggi tidak cukup. Jalankan URL kategori yang sama melalui matriks berikut, dan mulai setiap kasus navigasi baru dengan cache halaman kosong atau status cache konsisten yang didokumentasikan:

Navigasi baru dan perubahan ukuran merupakan pengujian berbeda. Komponen mungkin mendaftarkan observer, menghitung ambang, atau mengambil kelompok pertama hanya saat inisialisasi. Karena itu, mengubah ukuran halaman yang sudah berjalan dapat lulus sementara navigasi seperti crawler pada dimensi akhir gagal, atau sebaliknya. Pengguliran bertahap adalah kontrol jalur pengguna, bukan pengganti sesi tanpa interaksi.

Untuk setiap sesi, catat:

• URL yang diminta dan URL akhir di bilah alamat;
• dimensi viewport dan apakah halaman dimuat atau diubah ukurannya pada dimensi tersebut;
• kartu produk yang dirender setelah setiap pemuatan;
• URL produk unik dalam atribut <a href> nyata;
• URL produk duplikat, hilang, atau lintas halaman;
• permintaan jaringan dan pemicu yang memulai setiap kelompok tambahan;
• apakah batas halaman/kelompok memperbarui URL dan bertahan setelah muat ulang;
• node, nama, peran, dan tujuan tautan yang relevan dalam pohon aksesibilitas.

Cocokkan jumlah tersebut dengan inventaris katalog atau kelompok berhalaman yang diharapkan. Jumlah kartu terlihat dan jumlah tautan unik adalah dua pernyataan terpisah: grid dapat menampilkan 48 kartu sambil mengekspos lebih sedikit tautan produk yang dapat di-crawl, tujuan duplikat, atau kontrol yang tidak ada di pohon aksesibilitas. Pertahankan SKU pertama dan terakhir yang khas untuk setiap kelompok agar Anda dapat mendeteksi viewport tinggi yang diam-diam menggabungkan halaman 2 ke halaman 1.

Uji setiap kelompok sebagai URL mandiri

Pengujian: Minta URL berhalaman pertama, tengah, dan terakhir secara langsung dengan JavaScript dinonaktifkan. Hasil yang diharapkan: Masing-masing mengembalikan konten unik dan stabil serta respons berhasil tanpa perlu menggulir. Makna kegagalan: Lapisan URL hanya kosmetik atau masih bergantung pada interaksi klien. Jendela pemantauan: Segera setelah deployment. Pemicu rollback: Kelompok yang tercantum mengalihkan ke halaman pertama, mengembalikan shell bersama, atau mengubah konten antarpermintaan.

Uji penemuan crawler tanpa interaksi

Pengujian: Periksa DOM hasil render sebelum menggulir dan ekstrak tautan paginasi. Hasil yang diharapkan: Kelompok berurutan ditautkan melalui nilai href absolut atau relatif terhadap root yang nyata. Makna kegagalan: Crawler tidak memiliki jalur setelah rangkaian pertama yang dimuat. Jendela pemantauan: Segera. Pemicu rollback: Kelompok berikutnya hanya tersedia di balik penangan tombol atau peristiwa gulir.

Uji bug penggabungan viewport tinggi

Pengujian: Render kelompok pertama dalam viewport Chrome yang sangat tinggi, lalu cari item khas dari kelompok berikutnya di DOM. Hasil yang diharapkan: URL pertama tidak menyerap konten utama URL berikutnya. Makna kegagalan: Pemuat terpicu saat rendering meskipun tanpa interaksi pengguna. Jendela pemantauan: Segera secara lokal, lalu periksa ulang Inspeksi URL setelah Google meng-crawl kembali. Pemicu rollback: Dua kelompok logis muncul sebagai satu dokumen atau bilah alamat tidak mengikuti kelompok utama yang terlihat.

Uji pemahaman Anda: SEO Infinite Scroll

Lima pertanyaan singkat tentang cara membuat infinite scroll dapat diindeks. Pilih jawaban, lalu periksa hasilnya.

Sumber daya yang layak Anda baca

Tulisan saya yang terkait

• Masalah SEO JavaScript & Praktik Terbaik —ulasan lengkap saya, termasuk bagian “Masalah infinite scroll” (dua halaman terindeks sebagai satu) dan angka viewport pada bagian “Apa yang dilihat Googlebot”.
• Panduan Pemula untuk SEO Teknis —posisi rendering dan kemampuan crawling dalam gambaran yang lebih luas.

Presentasi saya

• Cara Kerja Penelusuran (SlideShare) —pemaparan saya tentang crawling, rendering, pengindeksan, dan pemeringkatan, yang menjadi latar setiap keputusan infinite scroll. (Penafian saya tetap berlaku: “Ini adalah pemahaman saya tentang sistem … dan tidak akan 100% lengkap atau akurat.”)

Dari industri

• Google Search Central, Memperbaiki konten yang dimuat secara lazy —panduan resmi terkini “Mendukung pemuatan berhalaman untuk infinite scroll”.
• Google Search Central, Paginasi, pemuatan halaman inkremental, dan dampaknya pada Google Penelusuran —tiga pola UX serta penghentian rel=next/rel=prev.
• Matt G. Southern, Cara Google Meng-crawl Halaman dengan Infinite Scrolling (Search Engine Journal) —penjelasan Mueller tentang “dua atau tiga halaman dimuat dalam satu halaman” dan risiko penggabungan.
• Matt G. Southern, Martin Splitt dari Google Menjelaskan Mengapa Infinite Scroll Menyebabkan Masalah SEO (Search Engine Journal) —“Googlebot tidak menggulir”, IntersectionObserver dibanding pengguliran, serta saran menguji penerapan.
• Barry Schwartz, GoogleBot Meng-crawl & Merender Tinggi, dengan Viewport 9000px? (Search Engine Roundtable) —asal penjelasan viewport tinggi.
• Matthew Edgar, Infinite Scroll yang Ramah SEO —kerangka “halaman komponen” (kelompok yang berfungsi mandiri, bahkan tanpa JavaScript).
• Go Fish Digital, Cara Menerapkan Infinite Scroll untuk SEO —panduan yang berorientasi pada penerapan.
• Lumar, Kondisi Paginasi dalam Ecommerce —analisis kemampuan pengindeksan peritel fesyen terkemuka Inggris yang menilai infinite scroll sebagai pola dengan performa terburuk.

Log perubahan