How to Optimize Pagination and Infinite Scroll for SEO

By Guru Editorial | August 14, 2026

Google's own crawling team puts a number on this problem. On the Search Off the Record podcast, Google's Gary Illyes said faceted navigation and action parameters together account for roughly 75% of the crawling issues Google encounters across the web, with faceted navigation alone responsible for about half, a comment later reported by Search Engine Land. That single data point explains why so many paginated catalogs, blog archives, and infinite scroll feeds quietly fall out of the index: Googlebot either can't find the deep pages in the series, or it finds so many low-value variants of them that it gives up before reaching the ones that matter.

The stakes for getting this wrong keep rising. ChatGPT now serves roughly 900 million weekly active users, and Google's own AI Overviews cut position-1 organic click-through rates by 58% as of December 2025, up from 34.5% just eight months earlier, while zero-click sessions on AI Overview queries rose from 54% to 72% over the same stretch. A page that never gets indexed can't rank in classic Google results, and it can't be crawled, quoted, or cited by an AI answer engine either, so pagination and infinite scroll are no longer just an ecommerce nuisance, they're a gate on everything downstream. This guide covers what happened to rel="next" and rel="prev", the load-more and infinite scroll patterns that keep JavaScript content crawlable, the canonical mistakes that quietly deindex entire series, when a view-all page helps versus hurts, where faceted navigation overlaps with pagination to waste crawl budget, and how to confirm your deepest pages are actually getting indexed.

What Happened to rel="next" and rel="prev" (and What Replaced Them)

Google confirmed in 2019 that it no longer uses rel="next" and rel="prev" as a ranking or indexing signal, and had in fact stopped relying on the pair internally years before making that public. If you already have the tags in place, there's no harm in leaving them: Bing and some other tools still read them, and they cost you nothing. But if you're building or rebuilding a paginated series in 2026, don't spend engineering time implementing rel=next/prev from scratch. It won't help Google understand your series, and it won't substitute for the things that actually do.

What replaced it is simpler than the old tag pair, and it's really just standard crawling mechanics. Google's official pagination documentation says to give each page in a series its own unique URL and to link every page to the next with a plain <a href> tag, because Googlebot discovers new URLs almost entirely by following href links in rendered HTML. There's no special pagination markup required. A blog archive at /blog/page/2/ that links to /blog/page/3/ with a normal anchor tag tells Google exactly what it needs to know: that this is another page in the series, worth crawling and worth indexing on its own.

The failure mode to watch for is JavaScript-only pagination controls: page number buttons wired to onclick handlers or href="#" placeholders that only change the DOM client-side. Googlebot renders JavaScript, but it doesn't click buttons or trigger event handlers that require a simulated user action, so a pagination control without a real href is functionally invisible to the crawler even though a human visitor never notices anything missing. The fix is almost always the same: make sure every page number, every "next" link, and every load-more control resolves to a real, fetchable URL in the raw HTML, not just in the post-interaction DOM state.

What to do instead of rel="next"/"prev":

• Give every page a unique, static URL such as ?page=2 or /page/2/
• Link sequentially with real <a href> anchors, not JavaScript-only controls
• Add a self-referencing canonical tag to every page in the series
• Link back to page 1, and ideally the last page, from deep in the series so crawlers can jump in
• List every paginated URL in your XML sitemap as a backup discovery path

The Three Pagination Patterns Google Actually Endorses

Google recognizes three legitimate ways to handle a paginated series, and the right one depends on how many items you're dealing with and how much unique value each page holds. All three rely on the same underlying discovery mechanics described above; they differ only in how you handle the canonical tag and whether you consolidate pages into one URL.

The default pattern, and the one Guru recommends for most content-heavy and ecommerce sites, is to index every page in the series individually. Each page gets a self-referencing canonical, sequential internal links, and its own entry in the sitemap. This works well when each page surfaces genuinely different items, like search results, blog archives, or a large product catalog, because each page has a legitimate claim to rank for slightly different long-tail queries.

Mixing patterns inconsistently across a site, view-all on some categories, an indexed series on others, no consistent rule anywhere, is itself a common source of confusion for crawlers, and it's exactly the kind of inconsistency technical audits tend to surface. Pick one pattern per content type and apply it consistently across every template that uses it.

Infinite Scroll and Load-More: Keeping JavaScript Content Crawlable

Pure infinite scroll, where new items append automatically as a user nears the bottom of the page with no URL change and no href anywhere in the markup, is close to invisible to Googlebot. Google's own documentation on incremental page loading says its crawler generally doesn't trigger JavaScript functions that require a user action like scrolling, so when Googlebot requests an infinite-scroll page it typically sees only whatever loaded in the initial HTML response, often the first 20 to 40 items, and nothing beyond that.

The fix isn't to abandon infinite scroll, it's to pair it with real URLs underneath. This hybrid pattern, sometimes called load-more with pushState, keeps the continuous-scroll experience for human visitors while giving Googlebot a normal, linkable series of pages to crawl. As a user scrolls or clicks a load-more button, the page fetches the next batch of items and simultaneously updates the browser URL with the History API, so the address bar reflects ?page=2, then ?page=3, and so on, without a full page reload.

Pure infinite scroll strands everything past the first batch of items behind a scroll event Googlebot never triggers; pairing load-more with real URLs and pushState keeps every page crawlable.

Steps to convert infinite scroll into a crawlable pattern:

1. Give every batch of results its own unique, static URL, whether that's a query parameter like ?page=2 or a path segment like /page/2/
2. Make sure the raw HTML response, not just the rendered DOM, includes a real <a href> link to the next page's URL, even if it's visually replaced by scroll behavior for human users
3. Use history.pushState() (or replaceState() on initial load) to update the visible URL as users scroll or click, so the experience stays continuous while the address bar stays accurate
4. Server-render or pre-render at least the first two or three pages of content so Googlebot's initial fetch contains real items, not an empty shell waiting on a client-side fetch call
5. List every paginated URL in your XML sitemap so discovery doesn't depend entirely on Googlebot finding and following each href
6. Confirm the fix worked using the URL Inspection tool in Search Console to check what Googlebot actually rendered, and compare it against what a logged-out user sees

Sites that skip this and ship infinite scroll without real URLs behind it tend to see the same symptom in crawl stats and log files: a large first page indexed, then a hard cliff, with nothing from page 2 onward ever appearing in the index no matter how much content actually exists behind the scroll.

Canonical Tag Mistakes That Quietly Deindex Your Series

Google has said directly that the single most common pagination mistake it sees is pointing every page's canonical tag back to page 1, on the theory that page 1 is the "main" page worth ranking. It's the opposite of helpful: Google treats a canonical tag as a strong hint about which URL to index, so a canonical from page 3 to page 1 tells Google that page 3's content is a duplicate of page 1, not a distinct page worth keeping in the index, and the unique items on page 3 quietly disappear from search results.

Canonicalizing every page back to page 1 tells Google the deeper pages are duplicates and they drop from the index; a self-referencing canonical on every page keeps the whole series indexable.

Canonical mistakes that quietly cost you indexed pages:

• Canonicalizing every paginated page to page 1 instead of self-referencing
• Relative canonical URLs that resolve incorrectly once combined with staging subdomains, trailing slashes, or query parameters
• Canonical tags left pointing to http or a pre-migration domain after an https or domain migration
• Multiple, conflicting canonical tags on the same page, often from a CMS template and a plugin or tag manager both injecting one
• Canonicalizing a filtered or sorted URL to a version with different filters actually applied, which tells Google the pages are duplicates when they aren't

The fix is mechanical but worth auditing on a schedule rather than assuming it's still correct after every CMS update, template change, or migration: every page in a standard paginated series should canonicalize to itself, full stop, unless you've deliberately chosen the view-all consolidation pattern below.

View-All Pages: When They Help and When They Backfire

A view-all page, one URL that loads every item in a collection at once, is a legitimate pagination strategy, not a workaround. When every paginated page in a series canonicalizes to a single /category/all URL and that page self-canonicalizes, Google will generally index the view-all page and treat the component pages as a secondary, user-facing convenience.

It works well when the total item count stays in the low hundreds and the page can still load quickly with lazy-loaded images and deferred non-critical scripts. It backfires the moment "view all" means five hundred products or two thousand blog posts on one URL, because loading that much markup and that many images at once tends to wreck Largest Contentful Paint and other Core Web Vitals metrics, which are themselves a ranking input. If your view-all page can't stay fast, use the indexed-series pattern instead and skip view-all entirely rather than shipping a slow page just to consolidate signals.

One detail worth checking directly: view-all only works as an indexing strategy if you actually apply the canonical consistently across every paginated URL in the series, not just the first two or three pages. A partial rollout, where pages 1 through 4 canonicalize to view-all but pages 5 onward were added later without the same template update, is a common gap that technical audits catch and manual reviews usually miss.

Faceted Navigation Overlap: Where Filters and Pagination Collide

Faceted navigation and pagination compound each other's worst problems. A category page with ten filter attributes and ten options each can theoretically generate billions of unique URL combinations, and this pattern has become one of the largest sources of wasted crawl budget on the web, serious enough that Google published dedicated guidance on crawling and faceted navigation. Add pagination on top of every one of those filter combinations, such as ?color=red&size=10&page=2, and the number of low-value, near-duplicate URLs a crawler has to sort through multiplies again.

The goal isn't to eliminate facets or their pagination, it's to be deliberate about which combinations deserve a crawlable, indexable URL and which don't. A facet combination with genuine standalone search demand, like "red running shoes" if people actually search that phrase, deserves its own clean, indexable, paginated URL built the same way as any other series. A facet combination with no search demand, like a five-way combination of color, size, brand, and price sorted by newest, doesn't, and serving it as an indexable URL only dilutes the pages that do matter.

Fixes for faceted and pagination overlap:

• Block low-value parameter combinations in robots.txt rather than relying on noindex, since a noindex page still costs Googlebot a fetch every time it's found
• Canonicalize sort-order and display-preference parameters, like ?sort=newest or ?view=grid, back to the clean, unsorted category URL
• Reserve real, indexable, paginated URLs for facet combinations with actual search volume behind them
• Keep parameter order and structure consistent across the site so the same filter combination never generates two different-looking URLs
• Apply the same real-URL, self-canonical rules from earlier sections to paginated pages within a facet, not just to the base category

This is one of the highest-leverage fixes available on a large ecommerce faceted navigation build, because every fetch Googlebot spends on a worthless filter-and-page combination is a fetch it didn't spend discovering a new product, a restocked item, or an updated category description.

Getting Deep Pages Indexed: Internal Links, Sitemaps, and Log Files

None of the fixes above matter if you can't confirm Googlebot is actually reaching the deep pages in your series. Pages more than three or four clicks from the homepage get crawled less often and less thoroughly, and a paginated series is exactly the kind of structure that pushes real content deep into that danger zone, one click at a time, page after page. Auditing and flattening crawl depth for your most valuable paginated content is worth doing before you touch anything else on this list.

A few structural habits shorten that path. Linking to page 1, the last page, and a handful of intermediate page numbers from every pagination block, rather than only "next" and "previous," lets a crawler jump ten pages deep in two or three hops instead of ten. Hub or landing pages that link directly out to a curated set of your best deep items, bypassing the full pagination chain entirely, give crawlers and users a shortcut to content that would otherwise sit behind page fifteen.

Sitemaps matter more for paginated and infinite-scroll content than for almost any other page type, because internal link discovery alone can be slow or incomplete for a series that runs dozens of pages deep. Listing every canonical, indexable URL in the series in your XML sitemap gives Google a direct discovery path that doesn't depend on it successfully rendering and following every href first, which matters even more for JavaScript-heavy pagination that needs a render pass before those links are even visible.

The only way to know for certain whether any of this is working is to look at what Googlebot is actually doing, not what your template is supposed to do. Server log files show every request Googlebot makes, including the ones that never make it into Search Console, and comparing hit frequency across page 1, page 5, and page 20 of a series usually reveals exactly where crawl interest falls off. Pairing that with the Google Search Console integration inside Guru, which surfaces indexing status and crawl stats without needing to pull raw logs by hand, is generally the fastest way to confirm a pagination fix actually moved the needle rather than just looking correct in a code review.

Frequently Asked Questions

Does Google still use rel="next" and rel="prev" for pagination?

No. Google confirmed in 2019 that it dropped rel="next" and rel="prev" as a ranking and indexing signal, and had already stopped relying on it internally before that announcement. The tags aren't harmful to leave in place, since Bing and some other tools still reference them, but they're not required and won't substitute for real crawlable URLs and self-referencing canonicals.

Should I noindex pagination pages 2 and beyond?

Generally no. Noindexing deep pagination pages tends to make Google stop crawling the links they contain over time, which can orphan the products, articles, or listings that only appear on those pages. Index each page with a self-referencing canonical instead, and reserve noindex for genuinely low-value, duplicate facet or sort combinations rather than the core paginated series itself.

Is infinite scroll inherently bad for SEO?

No, but pure infinite scroll without real underlying URLs effectively hides everything past the first batch of content from Googlebot, since the crawler doesn't simulate scrolling to trigger lazy-loaded fetches. A hybrid pattern that pairs infinite scroll with real, crawlable URLs and History API pushState updates keeps the same user experience while staying fully indexable.

What's the difference between load-more and infinite scroll for SEO purposes?

Functionally, very little, as long as both are implemented with real URLs behind them. Load-more is triggered by a button click and infinite scroll is triggered automatically near the bottom of the page, but Googlebot can't interact with either trigger, so both need a raw, fetchable <a href> link and a distinct URL for the next batch of content to be crawlable at all.

Should paginated pages canonicalize back to page 1?

No, and Google has called this out directly as the most common pagination mistake it sees. Canonicalizing page 2 or page 5 to page 1 tells Google those pages are duplicates of page 1, which typically causes their unique content to drop out of the index entirely. Each page in a standard paginated series should carry a self-referencing canonical tag instead.

When does a view-all page make sense instead of standard pagination?

A view-all page works well when the full collection is small enough, generally a few hundred items or fewer, to load quickly with lazy-loaded images, since Core Web Vitals are a ranking input and a bloated view-all page tends to fail them. Beyond that scale, standard indexed pagination or a load-more pattern with real URLs is usually the safer choice.

How do I check whether Googlebot is actually crawling my deep pagination pages?

Server log file analysis is the most direct method, since it shows every request Googlebot makes regardless of whether the page ended up indexed. Search Console's Crawl Stats report and URL Inspection tool are good complements for spot-checking individual URLs without pulling raw logs.

Does FAQ or HowTo schema help pagination or category pages rank?

Google removed the visual FAQ rich result from Search in May 2026, and it retired the HowTo rich result earlier, so neither markup produces a special listing in Google's results anymore. Both schema types remain valid, and they're still worth keeping where genuinely relevant, since structured Q&A and step content helps AI answer engines parse and cite a page even without a Google-side rich result.

Sources

• Pagination Best Practices for Google, Google Search Central
• Crawling December: Faceted navigation, Google Search Central Blog
• Google: 75% of crawling issues come from two common URL mistakes, Search Engine Land
• OpenAI: ChatGPT now has 900 million weekly active users, Search Engine Land
• Update: AI Overviews Reduce Clicks by 58%, Ahrefs
• GEO: Generative Engine Optimization, arXiv