Googlebot does not scroll.
This single limitation explains why thousands of e-commerce products remain invisible to search despite being live on websites. A 10,000-product site with 500-page category listings depends entirely on pagination working correctly. When it does not, 9,500 products might as well not exist.
Infinite scroll makes the problem worse. Users love the seamless experience. For crawlers, infinite scroll is like an invisible elevator. Users step on and ride smoothly to any floor. Googlebot stands in the lobby watching an elevator that never arrives.
This guide covers how to implement pagination that search engines can actually follow, why infinite scroll fails by default, and the hybrid approaches that satisfy both users and crawlers.
Why Pagination Creates SEO Problems
Pagination fragments content across multiple URLs. Each paginated page contains different products or articles, but they share structural similarity. This creates three distinct challenges.
Crawl discovery: Googlebot must follow pagination links to find content on page 50. If those links are JavaScript-rendered, hidden behind “load more” buttons, or missing entirely, page 50 never gets crawled. Products there become invisible.
Link equity dilution: Internal links pointing to “/category/” do not benefit products on page 25. External links rarely target deep pagination. Products buried deep in pagination receive minimal link equity regardless of their quality.
Thin content concerns: A category page showing 20 products with minimal unique content might look thin compared to comprehensive product pages. Multiply this across hundreds of pagination pages, and you have a thin content pattern that affects the whole section.
None of these problems are insurmountable. But default pagination implementations often ignore them entirely, and the consequences only become visible when you check specifically.
Traditional Pagination Done Right
Standard numbered pagination remains the most crawler-friendly approach when implemented correctly.
URL structure matters. Use clean, consistent URL patterns. Parameter-based (?page=2) and path-based (/page/2/) both work. Pick one and use it consistently across your site. Avoid session IDs, tracking parameters, or randomly generated pagination URLs.
Canonical tags require attention. Every pagination page should have a self-referencing canonical. Page 5 canonicals to page 5. Page 12 canonicals to page 12.
Here is the most destructive mistake: canonicalizing all pagination pages to page 1. This tells Google “only page 1 matters.” Products on pages 2 through 500 lose their ranking signals. You have effectively told Google to ignore 95% of your catalog. This mistake is common, easy to make, and devastating.
Internal linking reduces crawl depth. Do not rely solely on next and previous links. Include links to page 1, the last page, and a range around the current page. When on page 47, show links to pages 45, 46, 48, and 49, plus jumps to page 1 and page 100.
A link structure like “1 … 45 46 [47] 48 49 … 100” lets crawlers reach any page within two clicks from any other page. Only showing “Previous” and “Next” means page 100 is 99 clicks from page 1. That depth kills discoverability.
Unique metadata differentiates pages. Page 2 should not have the same title tag as page 1. Append pagination context: “Running Shoes – Page 2 of 15” or “Running Shoes (Products 25-50).” This prevents duplicate title issues and helps users understand where they are in the sequence.
The rel=next/prev Situation
Google officially supported rel=”next” and rel=”prev” for indicating pagination relationships. In 2019, Google revealed they had not actually used this signal for years.
The announcement confused many SEOs. Should you still implement it?
Current guidance: rel=next/prev does not hurt, but do not rely on it as your pagination strategy. Google understands pagination through URL patterns and linking structures without these tags. If your CMS already adds them, leave them. If you are building new pagination, focus effort on URL consistency and link structure instead. Those are what actually matter.
Why Default Infinite Scroll Fails
Infinite scroll loads content dynamically as users scroll down. No page refreshes, no clicking, seamless experience. For users, it is often superior to pagination.
For Googlebot, default infinite scroll is invisible.
Googlebot requests a URL, receives HTML, and processes that HTML. It does not scroll. JavaScript scroll event listeners do not fire for Googlebot. Even with Google’s rendering service processing JavaScript, the scroll action that triggers loading more content never happens.
If your infinite scroll implementation serves only the first 20 items in the initial HTML and loads the rest via JavaScript scroll events, Googlebot sees only those first 20 items. The rest might as well not exist.
Signs your infinite scroll is not being crawled: only products from the initial load appear in search results, Google Search Console shows far fewer indexed pages than you have products, and URL Inspection shows rendered HTML with only initial content loaded.
Making Infinite Scroll SEO-Compatible
SEO-friendly infinite scroll requires providing a fallback that crawlers can follow. Two approaches work.
History API with real URLs. As users scroll and content loads, use the History API to update the browser URL. Scroll to page 2 content, URL becomes /category/page/2/. Each of these URLs must work as standalone pages, returning their respective content when accessed directly.
Implementation requirements: each scroll “page” gets a unique URL via history.pushState(), direct URL access returns appropriate content through server-side logic, and pagination links exist somewhere on the page so crawlers can discover all URLs even if those links are visually minimal.
This approach gives users infinite scroll while providing crawlers with discrete, linkable URLs.
Progressive enhancement with pagination fallback. Serve traditional pagination by default. Layer infinite scroll on top for users with JavaScript. Crawlers receive clean pagination links. Users get seamless scrolling.
Implementation: server renders traditional pagination with next and previous links, JavaScript intercepts pagination clicks and loads content dynamically instead, URLs optionally update via History API as content loads, and users without JavaScript fall back to traditional pagination.
This approach is more robust because pagination works even if JavaScript fails. It separates the user experience enhancement from the underlying crawlable structure.
Load More Buttons
“Load More” buttons offer a compromise between pagination and infinite scroll. Users click once to load additional content, avoiding both page refreshes and the discoverability issues of automatic infinite scroll.
SEO considerations are similar to infinite scroll. The button click triggers JavaScript to load content. Googlebot does not click buttons. Without additional implementation, content beyond the initial load is hidden from crawlers.
The solution mirrors infinite scroll: implement proper URLs for each content batch, ensure those URLs work standalone when accessed directly, and provide crawlable links for discovery.
After the first “load more” click, the URL might become /category/?loaded=40 or /category/page/2/. After the second click, /category/?loaded=60 or /category/page/3/. Each URL returns the appropriate content batch when accessed directly. Links to these URLs exist in the HTML for crawler discovery even if users never see them.
Handling Large Catalogs
Sites with thousands of category pages face additional strategic decisions.
Indexing depth decisions. Should page 500 of a category be indexable? Products there have minimal visibility regardless of indexing status. Some sites noindex deep pagination while ensuring products remain accessible through other paths like search, filters, and related products.
Crawl budget concerns. Deep pagination consumes crawl budget. If Google crawls through 500 pagination pages to reach products that could be accessed through better internal linking, you have wasted crawl resources that could have gone to more valuable pages.
Alternative product access paths. Instead of relying solely on category pagination, ensure products are accessible through multiple routes: subcategories that reduce depth, internal search if Google can crawl search results, related products sections, indexable filter combinations, sitemap inclusion, and location-based paths for multi-location businesses.
A Nashville, TN furniture store might have /nashville/living-room-sofas as an alternate path to products that would otherwise be buried on page 47 of a general category. This location-based structure provides alternative access while serving local SEO needs.
Pagination page content enrichment. Consider adding unique content to pagination pages. Category page 12 could include a text section about mid-range products in that category. This differentiates pagination pages from each other and adds value beyond simple product listings.
Testing Pagination and Infinite Scroll
Verification matters because pagination failures are often invisible until you check specifically.
URL Inspection tool. In Google Search Console, test a pagination URL like page 5 or page 10. Check the rendered HTML. Is the content present? Are internal links to other pagination pages visible?
Site: search. Query site:example.com/category/page/ to see which pagination URLs are indexed. Significant gaps suggest crawl or indexing problems.
Log file analysis. Review which pagination URLs Googlebot actually requests. If Googlebot stops at page 3 but your category has 100 pages, there is a discovery problem.
JavaScript rendering test. Use Chrome’s “View Page Source” versus “Inspect Element.” Page source shows what Googlebot initially receives. Inspect shows the rendered DOM. If content only appears in the rendered DOM, verify Google is actually rendering it through URL Inspection.
Structured verification: Access a pagination URL directly without navigating from page 1. Check that correct content loads. Verify the canonical tag is self-referencing. Confirm links to other pagination pages exist in HTML. Test on URL Inspection tool. Monitor indexing over time in Search Console.
Common Pagination Mistakes
Canonicalizing all pages to page 1. This tells Google that only page 1 content matters. Products on other pages lose ranking signals entirely. Each pagination page should have a self-referencing canonical.
Parameter handling conflicts. If you have told Search Console to ignore certain parameters, but those parameters control pagination, you have effectively told Google to ignore your pagination.
Blocking pagination in robots.txt. Disallowing /page/ or ?page= prevents crawling of paginated content entirely. Those products become invisible.
Inconsistent URL structures. Mixing /page/2/ and ?page=2 across different categories creates confusion and potential duplicate content. Pick one format site-wide.
Missing pagination links in HTML. Pagination that relies entirely on JavaScript-rendered links might not be discoverable by crawlers. Include at least some pagination links in server-rendered HTML.
Shallow linking patterns. Only showing “Previous” and “Next” links means page 100 is 99 clicks from page 1. Include jumps to distant pages.
Pagination is not glamorous SEO work. But for sites with large catalogs, it is foundational. E-commerce sites that fix pagination problems often see significant traffic gains as previously trapped products become discoverable. The products were always there. They just needed a path for Google to find them.
Sources
- Google Search Central: Pagination Best Practices – https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading
- Google Search Central: Infinite Scroll Search-Friendly Recommendations – https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- Google Search Central Blog: rel=next/prev Update (2019) – https://webmasters.googleblog.com/2019/09/evolving-nofollow-new-ways-to-identify.html
- Search Console Help: URL Parameters Tool – https://support.google.com/webmasters/answer/6080550