Pagination SEO: Best Practices for Numbered Pages and Infinite Scroll

By Guy Sheetrit, CEO of Over The Top SEO

Pagination Is Still One of the Most Mishandled Technical SEO Issues

Pagination—splitting a collection of content across multiple sequential pages—is ubiquitous on the web. E-commerce category pages, blog archives, search results, and news feeds all use some form of pagination. Yet despite being common, pagination remains one of the most consistently mishandled technical SEO issues, responsible for duplicate content problems, crawl budget waste, and unnecessary ranking dilution on sites of all sizes.

The complexity of pagination SEO increased in 2019 when Google deprecated rel=prev/next, leaving many SEO guides and implementations based on outdated advice. This guide reflects the current best practices for 2026: the correct canonical handling for numbered pages, the technical requirements for crawler-accessible infinite scroll, and the crawl budget implications of long paginated sequences.

The Core Problems Pagination Creates for SEO

Duplicate Content Risk

Paginated pages often contain near-identical content: the same category title, the same navigation, the same metadata structure—differentiated only by the set of products or posts displayed. From a search engine perspective, /category/shoes/ and /category/shoes/page/2/ have very similar structural content. Without clear signals about how these pages relate, Google may treat them as partial duplicates and distribute ranking signals across the pagination sequence rather than consolidating them.

Crawl Budget Consumption

For large e-commerce sites, pagination sequences can run to hundreds of pages. A home goods retailer with 50,000 products organized into 200 categories, each paginated at 20 products per page, has potentially 2,500 pagination pages beyond page 1. Many of these deep pagination pages receive minimal organic traffic and contain low-value products—yet Googlebot must decide whether to crawl them, consuming crawl budget that could be allocated to higher-priority pages.

Thin Content on Deep Pages

Deep pagination pages (page 50, page 100) often suffer from quality issues: discontinued products, low-review items, out-of-season inventory, or items with missing descriptions. These thin-content pages, if indexed, can drag down overall site quality signals. Sites that allow Google to index hundreds of deep pagination pages filled with thin product listings risk triggering quality-related ranking suppression across the entire domain.

Canonical Tags for Pagination: The Correct Implementation

The most common pagination SEO mistake is canonicalizing all paginated pages back to page 1. This approach seems intuitive—consolidate PageRank to the main category page—but it backfires. When /category/shoes/page/2/ has a canonical pointing to /category/shoes/, Google interprets page 2 as a duplicate of page 1. The products listed only on page 2 may not be independently indexed, reducing the crawlable product inventory of your site.

Correct canonical implementation: Each paginated page should have a self-referencing canonical tag—a canonical pointing to its own URL. This signals to Google that each page is distinct and should be evaluated independently.

Example for /category/shoes/page/3/:

<link rel="canonical" href="https://www.example.com/category/shoes/page/3/" />

The category base page (/category/shoes/) similarly has a self-referencing canonical. All pages in the pagination sequence are treated as independent pages with their own content.

Exception: If your paginated pages truly contain the same content as page 1 (e.g., filtered variants of the same product set, or sorted views where all products are already on page 1), canonicalizing to the base page is correct. Apply this exception deliberately, not as a blanket policy.

Noindex Strategy for Deep Pagination

For sites with very long pagination sequences (50+ pages), implementing noindex on deep pages beyond a defined threshold can improve crawl efficiency and site quality. The logic: pages 1-5 of a category contain the most popular, highest-quality products. Pages 50+ typically contain long-tail, slow-moving inventory less likely to generate organic conversions. Noindexing these deep pages concentrates indexation on higher-value pages while reducing thin content in the index.

Implementation approach: add <meta name="robots" content="noindex, follow"> to pagination pages beyond your chosen depth threshold (commonly page 5-10 for category pages). The “follow” directive is important—Googlebot should still crawl links on noindexed pages to discover products listed there, even if the pagination page itself isn’t indexed.

Calibrate the threshold by analyzing organic traffic distribution across your pagination sequence. If pages beyond page 10 collectively receive less than 2% of organic traffic for a category, noindexing them has minimal ranking risk while improving crawl efficiency.

XML Sitemap Treatment of Pagination

Include paginated pages in your XML sitemap if they are intended to be indexed. Sitemaps are the most reliable way to signal to Google which pages in a pagination sequence should be crawled and indexed. Exclude noindexed pagination pages from sitemaps—submitting noindex URLs in sitemaps creates conflicting signals.

For large sites, consider a dedicated pagination sitemap rather than including all paginated URLs in your primary sitemap. A dedicated sitemap (sitemap-pagination.xml) allows you to monitor crawl coverage of paginated pages independently and to enable/disable pagination indexation by submitting or withdrawing the sitemap in Google Search Console without affecting primary content sitemaps.

Infinite Scroll: Making It Crawlable

Infinite scroll provides an excellent user experience—content loads seamlessly without explicit page navigation. However, standard infinite scroll implementations are completely invisible to search engine crawlers. Googlebot does not execute JavaScript scrolling behavior; it sees only the initial page load content. For a 500-product category with infinite scroll that renders 20 products per scroll event, Googlebot indexes only the first 20 products.

The Progressive Enhancement Approach

The correct technical solution for SEO-compatible infinite scroll is progressive enhancement that maps scroll “pages” to actual crawler-accessible URLs:

Step 1: Define real pagination URLs. Ensure your infinite scroll content maps to discrete, accessible URLs: /products/, /products/?page=2, /products/?page=3, etc. (or /products/2/, /products/3/ depending on URL structure). These pages must return their specific content when requested directly by Googlebot—not redirect to page 1 or require JavaScript scroll events to load.

Step 2: Implement History API (pushState). As users scroll through infinite scroll content, update the browser URL using the History API to reflect which “page” of content is currently in view. This enables the user to share a specific scroll position, for the back button to work correctly, and for crawlers to reconstruct the pagination sequence by following navigation links.

Step 3: Provide pagination navigation links. Include explicit next/previous navigation links in the page source, even if they’re hidden from user view via CSS. These links enable Googlebot to discover and crawl subsequent pagination pages. A hidden-but-crawlable pagination navigation fulfills the crawler’s needs without disrupting the infinite scroll UX.

Step 4: Verify with URL Inspection. Test each pagination URL with Google Search Console’s URL Inspection tool to confirm Googlebot can access and render the correct content for each page number.

Load More Button: The Middle Ground

“Load More” button implementations (click to load next page of content appended below current content) are generally preferable to pure infinite scroll from an SEO perspective, because they provide discrete user actions that map more naturally to pagination events. For SEO compliance, each “Load More” click should load content from a distinct URL that is also accessible via direct crawl.

The most SEO-friendly implementation: “Load More” button links to /category/page/2/; clicking it loads the next page’s content via Ajax and appends it to the current page (good UX), but the URL /category/page/2/ also returns its content directly when accessed (good for crawling). This hybrid approach serves users with smooth progressive loading while giving crawlers clean, directly accessible pagination URLs.

Site Search Result Pages

Internal site search result pages—/search/?q=running+shoes—create a specific pagination challenge. These pages generate enormous numbers of unique URLs based on search terms, most of which have no standalone organic value. Best practice: noindex all internal search result pages with a robots meta tag, and block them from crawling with robots.txt if your search result pages are in a predictable URL pattern.

Faceted navigation (filter/sort pages) creates a similar problem: /category/shoes/?color=red&size=10&sort=price creates a URL with no standalone search demand but which consumes crawl budget. Use canonical tags pointing to the base category URL for faceted navigation pages, or block faceted URL parameters in Google Search Console’s URL Parameters tool (though this feature has limited reliability—canonical tags are the more robust solution).

Diagnosing Pagination Issues in Practice

Common symptoms of pagination problems in Google Search Console: high number of “Excluded: Duplicate without user-selected canonical” pages in Coverage report (indicates Google is consolidating pagination pages it views as duplicates), declining organic traffic to deep category pages without content changes (indicates Google deindexing or devaluing deep pagination), and high crawl budget consumption on pagination sequences in the Crawl Stats report.

Screaming Frog audit steps: crawl site with “Follow Internal Nofollow” enabled, export Response Codes > 200, filter URL contains “/page/” (or your pagination URL pattern), compare indexation rate with organic traffic contribution from GSC. Pages receiving zero organic traffic that are fully indexed are candidates for noindex treatment; pages receiving significant traffic but excluded from index require canonical correction.