Pagination is one of those technical SEO topics that seems simple until you see the damage bad implementation causes. Canonicalizing every page to page 1 — which thousands of sites still do — tells Google that pages containing entirely different products are duplicates. Relying on JavaScript-only pagination makes your content invisible to every AI crawler in 2026. And letting faceted navigation multiply pagination URLs can generate millions of near-duplicate pages that devour crawl budget.

The fix isn’t complicated once you understand the mechanics. This guide covers how Google and AI crawlers handle paginated content today, the implementation that works for each site type, how to deal with the faceted navigation intersection, and how to audit what you already have.

How Search Engines Handle Pagination in 2026

Google’s Current Approach

Google deprecated rel=prev/next markup in March 2019 — it had already stopped using it internally “some years” before the announcement. Googlebot now identifies pagination relationships by analyzing the anchor links on each page. It doesn’t need special markup to understand that page 2 follows page 1.

Google treats each paginated page as an individual page for indexing purposes. Page 1 and page 5 are separate URLs with separate content. This is why canonicalizing all pages to page 1 creates a logical contradiction — you’re telling Google that page 5 (which shows completely different products) is a duplicate of page 1.

Google’s official guidance is straightforward:

• Link pages sequentially using standard <a href> tags
• Give each paginated page a unique URL
• Use self-referencing canonical tags (each page canonicals to itself)
• Don’t block paginated pages with noindex or robots.txt
• Don’t use fragment identifiers (#page2) — Google ignores content after the # symbol

Bing and Other Engines

Bing still uses rel=prev/next as hints for understanding page relationships. If you have these tags in your code, leave them in place — they cause no harm with Google and provide value for Bing.

AI Crawlers: The 2026 Factor

This is the dimension most pagination guides still miss. AI crawlers — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot — do not render JavaScript. They read the initial HTML response only.

If your pagination relies on JavaScript to load additional content (pure infinite scroll, client-side-rendered load-more buttons, or AJAX-loaded page navigation), those AI crawlers see an empty container. Your products, articles, and content loaded through JavaScript don’t exist as far as these crawlers are concerned.

Cloudflare’s data shows bots now account for roughly 32% of all HTTP requests, with AI crawlers specifically running at about 22% of bot traffic. ClaudeBot crawls approximately 50,000 pages for every single referral it sends back. Ignoring these crawlers means ignoring a growing discovery channel.

The implication for pagination: your paginated content must be accessible in the initial HTML response — either through server-side rendering (SSR), static site generation (SSG), or traditional server-rendered pages. Client-side rendering alone is no longer sufficient if AI search visibility matters to you.

Core Pagination Implementation

These practices apply regardless of site type. Get these right first, then layer on the site-specific guidance below.

Self-Referencing Canonical Tags

Each paginated page gets a canonical tag pointing to itself:

<!-- Page 1 -->
<link rel="canonical" href="https://example.com/shoes/" />

<!-- Page 2 -->
<link rel="canonical" href="https://example.com/shoes/?page=2" />

<!-- Page 3 -->
<link rel="canonical" href="https://example.com/shoes/?page=3" />

Do not canonical all pages to page 1. This is the single most common pagination SEO mistake, and it directly prevents Google from indexing products, articles, or content on pages 2+. If page 2 contains different products than page 1, they’re not duplicates — and telling Google they are sends a contradictory signal that Google may simply ignore.

Crawlable Anchor Links

Pagination navigation must use standard HTML <a> elements with href attributes. Google can follow these. Google cannot reliably follow JavaScript-only navigation:

<!-- Google can crawl this -->
<a href="https://example.com/shoes/?page=2">Page 2</a>

<!-- Google struggles with this -->
<a onclick="loadPage(2)">Page 2</a>
<button onclick="goto('/shoes/?page=2')">Next</button>

If your pagination uses JavaScript for user experience (smooth transitions, partial page loads), implement it as progressive enhancement on top of working HTML links — not as a replacement.

Clean URL Structure

Pick one format and use it consistently across your site:

• Query parameter: example.com/shoes?page=2
• Directory structure: example.com/shoes/page/2/

Both work. Google recommends query parameters because they’re easier to track in Search Console. What matters most is consistency.

Avoid:

• Fragment identifiers: example.com/shoes/#page2 (Google ignores everything after #)
• Complex parameter strings: example.com/shoes?page=2&sort=price&order=asc&view=grid (creates duplicate content)
• Missing page 1 canonicalization: ensure example.com/shoes?page=1 and example.com/shoes resolve to the same canonical URL

Don’t Noindex Paginated Pages

Adding noindex to pages 2+ prevents Google from indexing those pages, which blocks link equity from flowing through them and prevents Google from discovering content linked from those pages.

Products on page 5 of a category become orphaned if page 5 is noindexed — Googlebot won’t follow the links on that page, so those products lose an important crawl path.

Meta Tags for Pages 2+

De-optimize subsequent pages so they don’t compete with page 1 for your primary keyword:

• Page 1 title: Women's Running Shoes | Free Shipping | BrandName
• Page 2 title: Women's Running Shoes – Page 2 | BrandName
• Page 3 title: Women's Running Shoes – Page 3 | BrandName

Write unique meta descriptions for page 1 (optimized for CTR and keywords). Pages 2+ can use simpler descriptions or let Google auto-generate them.

Pagination by Site Type

Ecommerce Category Pages

Ecommerce pagination has the highest complexity because it intersects with faceted navigation, product sorting, and large catalog sizes.

Items per page: Consider increasing your default from 24 to 48 or even 96 products per page. Fewer paginated pages means less crawl budget consumed, shallower crawl depth to your deepest products, and less pagination-related URL proliferation. Test the impact on Core Web Vitals — as long as the page renders quickly (use lazy-loading for images below the fold), there’s no SEO downside to showing more products per page.

Sorting parameters: If your sort options (price, popularity, newest) create separate URLs (?sort=price), these are duplicate content. The same products appear on both the default page and the sorted page. Either:

• Canonicalize sorted variants to the default sort URL
• Use JavaScript to handle sorting without creating new URLs
• Block sort parameters in robots.txt if they create no unique value

View All pages: If you offer a “View All” option alongside pagination, canonical the View All page to itself and the individual paginated pages to themselves. Don’t canonical paginated pages to the View All page or vice versa — they serve different purposes. Google’s documentation says View All pages can be valuable if they load quickly enough. For catalogs with hundreds of products, View All pages often fail on page speed.

Blog and Publisher Archives

Blog pagination typically involves category archives, date archives, tag archives, and author archives — often all paginating the same set of articles through different paths.

Consolidate archive paths. If your category archive, tag archive, and date archive all show the same articles in different order, you’re creating multiple paginated paths to the same content. Decide which archive type is primary (usually categories), optimize those, and either noindex the redundant archive types or remove them.

Date archives specifically are often thin and redundant for evergreen blogs. If users don’t actually browse by date, and date archives just duplicate content available through category archives, consider noindexing them.

Article excerpts vs. full content: Paginated archive pages that show only post titles and 20-word excerpts risk being flagged as thin content. Include meaningful excerpts (150-300 words) and add unique introductory content to each category’s page 1 that describes what the category covers.

Forum and Discussion Threads

Forum threads with hundreds of comments create deep pagination chains. The main risk is crawl depth — important replies buried on page 15 may never get crawled.

Link from the first page of each thread directly to the last page (not just “next”). Consider showing the most recent and most relevant replies on page 1, with pagination for the full chronological thread.

Handling Faceted Navigation + Pagination

Faceted navigation is the single largest source of pagination-related crawl waste on ecommerce sites. Google’s Gary Illyes attributed half of all reported crawling issues to faceted navigation, with URL parameters accounting for roughly 75% of all crawl complaints.

The problem: a product category with 500 items, 10 color filters, 8 size filters, 5 price ranges, and 4 brand filters can generate tens of thousands of unique URLs — each with its own pagination sequence.

The Decision Framework

Index: Single-facet URLs with verified search demand. If people search for “nike running shoes” and you have a /running-shoes?brand=nike URL, that facet page deserves indexing with self-referencing canonicals and its own pagination sequence.

Noindex, follow: Multi-facet combinations that users find useful but that don’t warrant separate indexing. ?brand=nike&color=black&size=10 — add <meta name="robots" content="noindex, follow"> so Google still follows links to individual products but doesn’t index the filtered page.

Block via robots.txt or disallow parameters: Sort orders, view options (grid/list), and filter combinations that create pure duplicate content with no search value.

Implementation Approach

1. Identify which facet combinations have real search volume (check keyword tools for “[category] + [facet]” queries)
2. Create indexable, canonical facet pages only for those with verified demand
3. Noindex all other facet combinations while keeping links crawlable
4. Prevent sort and view parameters from generating indexable URLs
5. Audit the result with a crawl tool to verify total crawlable URL count is reasonable

Making Infinite Scroll SEO-Friendly

Infinite scroll works for user experience but creates SEO problems unless you implement a paginated fallback. Google’s guidance on this hasn’t changed since 2014: provide a paginated equivalent that crawlers can use.

The Implementation

Your infinite scroll page should have:

1. A visible URL that updates as users scroll (using the History API: pushState)
2. A server-side paginated fallback: when Googlebot (or any crawler that doesn’t render JavaScript) requests the page, it receives a traditional paginated page with numbered navigation links
3. Each paginated URL returns the full page (not just a content fragment) for crawlers

The practical approach most production sites use in 2026: server-side render the paginated version as the base HTML. Layer JavaScript on top for the infinite scroll experience. Crawlers get the paginated HTML with proper <a href> navigation. Users get the smooth scroll experience. Both are served from the same URL — no cloaking, just progressive enhancement.

Load More Buttons

“Load More” buttons sit between pagination and infinite scroll. The SEO requirement is the same: the button must trigger a URL change and the underlying content must be accessible through crawlable paginated URLs.

<!-- SEO-friendly: combines load-more UX with crawlable pagination -->
<a href="/shoes/?page=2" class="load-more-btn" data-page="2">Load More</a>

The <a href> ensures crawlability. JavaScript intercepts the click to load content inline for users. Both audiences are served.

Reducing Crawl Depth

Deep pagination (10+ pages) creates crawl depth problems. Pages requiring 7+ clicks from the homepage see roughly 40% reduced crawl probability.

Strategies to flatten crawl depth:

Increase items per page. Going from 24 to 60 items per page cuts a 20-page sequence to 8 pages.

Add subcategory links. Instead of one “Shoes” category with 50 pages of pagination, create subcategories (“Running Shoes,” “Casual Shoes,” “Dress Shoes”) each with their own shorter pagination sequences. This reduces depth and improves relevance.

Link to deep pages from elsewhere. If page 8 of your category contains products that are also featured in blog posts, buying guides, or related product sections, those additional crawl paths help Google discover those products faster.

Implement “jump to page” navigation. Instead of just “Previous/Next,” show page numbers with strategic gaps: 1 2 3 ... 10 ... 20. This gives crawlers direct links to deeper pages without requiring sequential crawling.

Use XML sitemaps as a complement. Sitemaps don’t replace internal linking, but they provide an additional discovery path. Include your paginated URLs in your sitemap to signal that they’re important.

Auditing Your Pagination

Step 1: Crawl Your Site

Use Screaming Frog, Sitebulb, or a similar crawler. Check:

• Canonical tags: Are paginated pages using self-referencing canonicals? Flag any page that canonicals to page 1.
• Noindex tags: Are any paginated pages noindexed? Unless there’s a deliberate reason, this is usually a mistake.
• HTTP status codes: Do all paginated URLs return 200? Check for soft 404s — pages like ?page=999 that return a 200 status code with an empty product grid.
• Anchor tags: Is pagination navigation using crawlable <a href> elements? Or JavaScript-only buttons?
• Page depth: How many clicks does it take to reach the last paginated page from the homepage?

Step 2: Check Google Search Console

• URL Inspection: Check specific paginated URLs (page 1, page 5, the last page) to see if Google has indexed them.
• Pages report: Under Indexing, check how many paginated URLs are indexed vs. excluded, and why.
• Crawl Stats: Check if Googlebot is spending disproportionate time on paginated URLs vs. your priority content.

Step 3: Review Log Files

Server log analysis reveals what crawlers actually do, not what you think they do. Check:

• How frequently Googlebot crawls paginated URLs vs. product/article pages
• Whether AI crawlers (GPTBot, ClaudeBot) are accessing paginated content at all
• Whether crawlers are hitting invalid paginated URLs (pages beyond your actual pagination range)
• Response times for paginated pages — slow responses can cause Googlebot to reduce crawl rate

Step 4: Prioritize Fixes

Fix immediately: Canonical tags pointing all pages to page 1. JavaScript-only navigation with no crawlable fallback. Noindex on paginated pages that contain unique content.

Fix soon: Faceted navigation generating thousands of unconstrained URLs. Soft 404s on invalid page numbers. Missing self-referencing canonicals.

Optimize when possible: Crawl depth exceeding 7 clicks for deep pagination. Items per page count (test increasing). Redundant archive paths (date + category + tag all paginating the same content).

Frequently Asked Questions

Should I canonical all paginated pages to page 1?

No. This is the most common pagination SEO mistake. Each paginated page contains different content (different products, articles, or items), so they are not duplicates of page 1. Use self-referencing canonical tags instead — each page canonicals to itself. Canonicalizing to page 1 prevents Google from indexing content on pages 2+ and cuts off link equity flow through the pagination sequence.

Does Google still use rel=prev/next?

No. Google stopped using rel=prev/next as a ranking or indexing signal in 2019. Its algorithms now understand pagination relationships through standard anchor links. However, Bing still uses these tags as hints, so leaving them in your code causes no harm and provides some benefit for Bing users.

Which is better for SEO: pagination, infinite scroll, or load more?

Pagination is the safest option because each page has a unique, crawlable URL by default. Infinite scroll and load more can work for SEO if — and only if — they include a paginated URL fallback that crawlers can access without rendering JavaScript. Without this fallback, content loaded through infinite scroll or load more buttons is invisible to all AI crawlers and potentially delayed in Google’s indexing.

How many items should I show per page?

There’s no universal number, but many ecommerce SEO practitioners are moving from 24 to 48-96 items per page to reduce pagination depth and crawl waste. The constraint is page speed: as long as your page loads quickly (use lazy-loading for below-fold images and monitor Core Web Vitals), more items per page means fewer paginated URLs, shallower crawl depth, and less crawl budget consumed. Test different counts and measure the impact on both page speed and user engagement.

How does faceted navigation interact with pagination?

Faceted navigation (filters for size, color, price, brand) creates URL combinations that multiply your pagination URLs exponentially. A category page with 500 products and 10 filter options can generate thousands of filtered + paginated URLs. The recommended approach: only index single-facet pages with verified search demand, noindex multi-facet combinations while keeping links followable, and block sort and view parameters entirely.

Do AI crawlers handle pagination differently than Google?

Yes, significantly. AI crawlers (GPTBot, ClaudeBot, PerplexityBot) do not render JavaScript. If your pagination relies on client-side JavaScript to load content, AI crawlers see nothing beyond the initial HTML. Ensure your paginated content is available in the server-rendered HTML response. This is also good practice for Google, which delays JavaScript rendering to a second crawl wave that can take hours to weeks.