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 URL | Canonical URL | Why |
|---|---|---|
/components/valves | /components/valves | Main category and first results |
/components/valves?page=2 | /components/valves?page=2 | Different products |
/components/valves?page=3 | /components/valves?page=3 | Another distinct slice |
/components/valves?page=1 | /components/valves | Duplicate 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:
| Control | What it does | Pagination implication |
|---|---|---|
| Self-referencing canonical | Identifies the preferred URL for that page | Normal starting point for distinct listing slices |
noindex | Excludes a crawled page from search results | An indexing decision, not a crawl-saving switch |
robots.txt disallow | Restricts crawling | Can prevent Google reading the page and its navigation |
| Omission from XML sitemap | Removes a sitemap discovery route | Doesn'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.
| Interface | What the visitor does | What the implementation must preserve |
|---|---|---|
| Numbered pagination | Opens another results page | Direct URLs and sequential anchor links |
| Load more | Requests another batch | Linked component URLs that also work independently |
| Infinite scroll | Scrolls into another batch | Linked 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.
| Situation | Recommended approach | Check before release |
|---|---|---|
| Small, finite collection | Consider one complete listing | Full content, mobile speed and usability |
| Large catalogue | Retain paginated component pages | Direct loading and complete coverage |
| Existing view-all alternative | Assess before changing canonicals | Complete content, performance and canonical selection |
| Button that reveals more items | Treat as incremental loading | Independent 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.
| Test | Expected result | What a failure exposes |
|---|---|---|
| Open the first page | 24 records and a link to page two | Incomplete initial rendering or missing navigation |
| Open pages two and three directly | 24 records each, matching their navigation-loaded versions | Dependence on browser state or incorrect offsets |
| Open page four | 23 records, no forward link | Broken terminal-page logic |
| Request page five | HTTP 404 for this out-of-range page | Endless empty URLs or repeated final-page content |
| Combine record IDs across all pages | 95 unique IDs, each appearing once | Missing records or repeated slices |
| Compare source and rendered canonical | Each valid component URL points to itself | Client-side metadata replacement |
| Inspect rendered product links | Every card links to its detail URL | Click-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 if | Look elsewhere if |
|---|---|
| You need technical SEO changes implemented alongside ongoing page work | You want strategy advice with no changes to your site |
| Your growing B2B SaaS library needs page releases and internal-link work | Your engineers can fix an isolated template bug using the checks above |
| Your enterprise site needs dedicated engineering and custom reporting | You 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.