Skip to main content
searchmaxxed
GUIDE

Pagination SEO for large sites (2026)

Pagination SEO for large sites: Google’s current rules for canonicals, infinite scroll and rel next/prev, plus a practical catalogue release checklist.
PUBLISHED 28 OCTOBER 2026UPDATED 28 OCTOBER 202611 MIN READ
SUMMARIZE WITH AI
Summarize with ChatGPTSummarize with PerplexitySummarize with ClaudeSummarize with GeminiSummarize with Grok

Pagination SEO keeps every part of a long listing reachable through separate URLs and crawlable links, so products don't disappear behind navigation. Give each page its own canonical URL. Don't canonicalise everything to page one. Infinite scroll and “load more” can work too, provided the underlying pages load directly without anyone scrolling or clicking. Google no longer uses rel="next" and rel="prev" to understand pagination, so those tags won't fix a broken path through your catalogue.

The real test comes later: can Google reach the detail pages that matter to a buyer researching your products, integrations or published resources?

I'm Brenden House, founder of Searchmaxxed. Our technical SEO work covers crawl and indexing fixes, canonical tags, site structure and mobile rendering, including the templates those systems depend on. This guide turns Google's current instructions into practical checks your engineering team can use before releasing a listing template across the whole website.

In summary

  • Keep ordinary paginated listings crawlable, with separate URLs, sequential links and self-referencing canonicals.
  • Build infinite scroll over accessible component pages. The visible interaction can change without removing the crawl path.
  • Don't confuse pagination with filtering. Different slices of a catalogue need different treatment from unwanted sorting and filter combinations.
  • Test the records behind the links. A working “Next” button doesn't prove the sequence contains every item.
  • Measure discovery of the destination pages. More indexed archive pages isn't the business outcome.

What is pagination SEO, and what does Google recommend now?

Pagination SEO is the work that makes a collection's separate pages accessible and understandable to search engines. Google treats paginated URLs as separate pages. The links between them matter.

A manufacturer's component catalogue is an obvious example, but the same problem appears wherever a growing collection becomes too long for one page. A B2B SaaS company might split an integration directory, while a public-sector website uses pagination for publications or procurement notices.

Those listings also lead people and crawlers towards the detail pages that answer a specific search, whether that's a product specification or an integration. Google's pagination guidance gives a direct instruction:

“Don't use the first page of a paginated sequence as the canonical page”.

It also says:

“Google no longer uses these tags, although these links may still be used by other search engines”.

The tags in that passage are rel="next" and rel="prev". They don't replace navigation links.

Keep the links. A normal <a href="?page=2">Next</a> remains useful because it points to an actual page. The head element does something different.

Fix unreachable pages before spending engineering time removing harmless old next/prev tags, because the missing crawl path is what stops access to the collection.

Which canonical tags should paginated pages use?

Ordinary paginated pages should use self-referencing canonical tags, because each page contains a different part of the collection that deserves its own address. Page two isn't a duplicate of page one simply because both use the same template.

A canonical URL identifies the preferred address when duplicate or very similar versions of the same content exist elsewhere on the website. It doesn't mean “my favourite page”.

For an illustrative manufacturer's catalogue, the mapping looks like this:

Page URLCanonical URLWhy
/components/valves/components/valvesMain category and first results
/components/valves?page=2/components/valves?page=2Different products
/components/valves?page=3/components/valves?page=3Another distinct slice
/components/valves?page=1/components/valvesDuplicate first-page address, if it exists

Choose one first-page address for navigation. If the parameter version serves identical content, a permanent redirect to the clean address is another consolidation option.

For page two, the document head would contain:

<link rel="canonical"
      href="https://example.com/components/valves?page=2">

Then check the rendered page. A correct server response isn't enough if JavaScript later replaces the canonical with the category root, leaving Google to interpret a different instruction.

Google describes canonicals as signals for duplicate or similar pages, not commands it must follow. Check both canonicals in Search Console.

Should you noindex pages two and beyond?

Don't apply noindex to an ordinary pagination sequence just because later pages aren't your preferred search landing pages. Keep the deeper path intact.

Here's how the controls differ when applied to a paginated listing:

ControlWhat it doesPagination implication
Self-referencing canonicalIdentifies the preferred URL for that pageNormal starting point for distinct listing slices
noindexExcludes a crawled page from search resultsAn indexing decision, not a crawl-saving switch
robots.txt disallowRestricts crawlingCan prevent Google reading the page and its navigation
Omission from XML sitemapRemoves a sitemap discovery routeDoesn't prevent crawling or indexing through other links

Google has to read the instruction. Its noindex documentation explicitly warns against blocking that page in robots.txt, because the crawler would then be unable to read the exclusion rule.

There are legitimate exclusions. Internal search results and unwanted filtered views need their own policy, with important destination pages reachable elsewhere.

Don't apply that policy blindly to ?page=. Our faceted navigation SEO guide covers the separate question of which filtered combinations deserve search visibility.

Can infinite scroll and load more work for SEO?

Infinite scroll and load more can work for SEO when each content chunk has a persistent URL and crawlable links. No scrolling should be necessary.

Google's lazy-loading guidance says:

“Give each chunk its own persistent, unique URL”.

Choose the interface that suits your visitors, while preserving the underlying URLs and links that let search engines reach the rest of the collection.

InterfaceWhat the visitor doesWhat the implementation must preserve
Numbered paginationOpens another results pageDirect URLs and sequential anchor links
Load moreRequests another batchLinked component URLs that also work independently
Infinite scrollScrolls into another batchLinked component URLs, direct loading and useful URL updates

For a SaaS integration directory, /integrations?page=3 should open that slice directly. No earlier browsing should be necessary.

Try a fresh browser tab. Paste, reload and check the cards. Then compare those cards with the same slice reached through scrolling, checking both the visible labels and the destination URLs attached to them.

Google recommends updating the displayed URL through the History API when the new chunk becomes the primary visible content. That lets a visitor share or refresh the address they can see without losing their place and starting the entire collection again.

The address bar isn't a link. Preserve normal anchors in the rendered navigation, alongside the JavaScript behaviour:

<nav aria-label="Integration pages">
  <a href="/integrations">First page</a>
  <a href="/integrations?page=2">Previous page</a>
  <a href="/integrations?page=4">Next page</a>
</nav>

Use this on the third page. At the end of the collection, remove the forward link rather than sending visitors and crawlers to another empty copy of the template.

Don't use #page=3 as the only address. Google's pagination guidance says fragment identifiers aren't suitable page numbers because Google ignores them.

Does the content need to stay identical forever?

No. Catalogues change, but a URL must identify a meaningful slice rather than depend on a visitor's earlier clicks or session state.

Use a deterministic default order. When items share a sort value, add a stable tie-breaker, such as the record ID.

That's engineering advice, not ranking magic. It makes the sequence testable and reduces avoidable duplication when equal-valued records shuffle between requests.

For fast-changing collections, test additions and removals separately. If offsets shift, confirm important items remain discoverable through category links, detail-page links and sitemaps.

Should you replace pagination with a view-all page?

A view-all page can suit a compact collection that loads comfortably in full. It isn't the default answer for a large catalogue.

A view-all page contains the complete collection at one address. The label alone doesn't count.

SituationRecommended approachCheck before release
Small, finite collectionConsider one complete listingFull content, mobile speed and usability
Large catalogueRetain paginated component pagesDirect loading and complete coverage
Existing view-all alternativeAssess before changing canonicalsComplete content, performance and canonical selection
Button that reveals more itemsTreat as incremental loadingIndependent URLs for the extra chunks

Before choosing a view-all canonical, check what the destination contains.

Google's current pagination instructions recommend a canonical for each page, rather than asking site owners to consolidate every sequence into a complete listing. Canonical guidance has a narrower purpose.

Start with self-referencing canonicals for distinct component pages. Consider consolidation only where the complete version genuinely represents the collection and remains usable, then verify Google's response.

Test on a phone. Moving every result onto one slow page trades an access problem for a performance problem.

For Searchmaxxed, that decision sits with technical SEO work on rendering, site speed and canonicals. Changing a tag without checking its destination misses the point.

How do you keep deeper products and resources reachable?

Link sequentially through the collection, and provide useful category paths to important detail pages. Don't make a long “Next” chain their only route.

Crawl depth is the number of links followed from a starting page to reach another page. Shorter, relevant routes make deep content easier to discover.

Google recommends linking each component page to the following page. It also suggests links back to the first page to emphasise the collection's starting point.

For a manufacturing catalogue, organise links around genuine product families and applications, giving buyers a useful route to products that meet their requirements. For a SaaS resource library, connect guides to their relevant product and integration pages.

Those links also help actual buyers who arrive with a specific requirement, rather than an afternoon free to browse every item in the catalogue. Someone researching a valve specification shouldn't need to browse the entire catalogue to reach the matching product.

Keep important canonical detail URLs in the XML sitemap too. Google's sitemap guidance presents sitemaps as help with discovery, not a replacement for linking.

Separate discovery from indexation. Google finding a URL doesn't mean it has indexed it, and an indexed URL hasn't necessarily earned useful search traffic.

Counts alone don't diagnose crawl problems. Our crawl budget guide for large sites explains how to investigate actual crawling without repeating that work here.

How do you test a pagination release properly?

Test completeness, not just navigation. A sequence can look healthy while silently omitting records between pages, even when every link works and each page declares the right canonical.

Give engineering a fixed test catalogue. The following example is an invented manufacturing catalogue, designed for this guide to make the checks reproducible rather than describe a measured client case.

Assumptions: 95 valve records, 24 records per page, deterministic ordering and no catalogue changes during the test. Four pages; the last contains 23.

The arithmetic is simple: 24 + 24 + 24 + 23 = 95. Every record should appear exactly once in this frozen default sequence, so an apparently correct total cannot hide a missing item behind a duplicate.

TestExpected resultWhat a failure exposes
Open the first page24 records and a link to page twoIncomplete initial rendering or missing navigation
Open pages two and three directly24 records each, matching their navigation-loaded versionsDependence on browser state or incorrect offsets
Open page four23 records, no forward linkBroken terminal-page logic
Request page fiveHTTP 404 for this out-of-range pageEndless empty URLs or repeated final-page content
Combine record IDs across all pages95 unique IDs, each appearing onceMissing records or repeated slices
Compare source and rendered canonicalEach valid component URL points to itselfClient-side metadata replacement
Inspect rendered product linksEvery card links to its detail URLClick-only cards that hide destinations

For this fixture, return HTTP 404 when the requested page doesn't exist, rather than serving an empty template with a successful response code. Stop linking to them too.

The completeness test is deliberately strict. Promotional cards or changing inventory need separate expectations agreed before testing, rather than becoming an unexplained exception whenever the records fail to add up.

What should engineering hand back?

Ask for the tested URLs, their record IDs, response codes, canonicals and rendered navigation. Include screenshots for mobile behaviour and direct-load evidence for a later page.

Then check Search Console. Use URL Inspection to review the rendered content and, where available, Google's selected canonical from the indexed version.

A live test checks access. It doesn't prove existing indexation.

After release, follow discovery and indexing of the destination pages the fix was meant to expose, keeping them separate from the listing URLs. Track impressions and enquiries separately.

Searchmaxxed's technical SEO scope includes implementation and measurement, so the work can continue beyond an audit document. The business keeps its website, repository and data.

Is Searchmaxxed right for your pagination problem?

Searchmaxxed fits companies that need technical SEO changes built and checked, alongside ongoing work on the pages buyers actually search for. We handle implementation, not just recommendations.

Our technical SEO service covers crawl and indexing fixes, site structure, canonical tags, XML sitemaps, site speed and mobile rendering. Those are the systems a pagination change touches.

The right scope depends on the pagination fault and the ongoing search work your company needs.

Searchmaxxed is a good fit ifLook elsewhere if
You need technical SEO changes implemented alongside ongoing page workYou want strategy advice with no changes to your site
Your growing B2B SaaS library needs page releases and internal-link workYour engineers can fix an isolated template bug using the checks above
Your enterprise site needs dedicated engineering and custom reportingYou only need a one-off review of a template your team already maintains

Growth System combines page releases with technical SEO and internal-link work. Agentic Search Engineering adds comparison, industry and integration page families. Custom & Enterprise can include dedicated engineering, multiple markets and custom reporting.

You speak directly to the people building and checking the work, rather than passing technical questions through an account manager who isn't implementing it.

If nobody can change the template, settle implementation access first. An audit cannot make a blocked release happen.

Frequently asked questions

Is pagination bad for SEO?

Pagination isn't inherently bad for SEO. Problems come from inaccessible pages, incorrect canonical tags or missing paths to deeper content. A linked sequence can support both browsing and discovery.

Does Google still use rel next and rel prev?

Google no longer uses rel="next" and rel="prev" to identify pagination relationships. Its current documentation states this explicitly. Keep normal anchor links between pages.

Should page two canonicalise to page one?

No, not when page two contains a different set of items. Give it its own canonical URL. Consolidating duplicate first-page addresses is a separate decision, because those URLs show the same slice rather than another part of the catalogue.

Is infinite scroll better than pagination for SEO?

Neither interface wins automatically. Infinite scroll needs independently accessible component URLs and crawlable links beneath it. Numbered pagination still needs testing.

Do paginated pages need unique titles and meta descriptions?

Google permits the same titles and descriptions across a paginated sequence, so repeated metadata alone isn't a reason to exclude the later pages. Page numbers help orient visitors. You don't need to invent new copy for every slice just to make an audit tool stop reporting the titles as repeated text.

Does API pagination make a website crawlable?

API pagination alone doesn't make a website crawlable, because an endpoint returning another batch doesn't create linked HTML pages that search engines can navigate. Expose persistent browser URLs that render the relevant content and navigation.

How many items should each page contain?

Test performance and usability first. Google's pagination guidance doesn't prescribe a universal item count, so choose a page size that suits the cards, devices and collection you're serving. The 24-item example here is a test assumption, not an SEO target.

What should you do next?

Start beyond the first page. Check direct access, the canonical and the path onward before changing the interface, then follow the product or resource links to their destinations.

If the fault spans templates, rendering and internal links, bring that example to Searchmaxxed. We'll scope the work from there.

Let's talk pricing.

REFERENCES
  1. pagination guidance
  2. signals for duplicate or similar pages
  3. noindex documentation
  4. lazy-loading guidance
  5. sitemap guidance

Let's make you the answer.

Own the searches that bring customers.

Searchmaxxed does technical SEO, content, local SEO, link building, GEO and AEO, so you rank in Google and get named in ChatGPT, Gemini and Perplexity.

  • Google and AI search in one system
  • Weekly releases with evidence
  • You own the site and data
  • Technical SEO, content and links