Pagination and SEO: How to Handle Paginated Pages

What is pagination?

Pagination splits a large set of items into smaller pages with separate URLs:

/academy/
/academy/?page=2
/academy/?page=3

Each page shows a different portion of the same collection. The interface may use page numbers, previous and next controls, a load-more button or continuous scrolling.

Common examples include:

• Ecommerce category products.
• Blog and news archives.
• Search or directory listings.
• Customer reviews.
• Forum threads and comments.
• Galleries.
• Long datasets.

Pagination describes the underlying division of content. Infinite scroll and load more describe how someone experiences that content in the interface. A site can provide an infinite-scroll experience while maintaining crawlable paginated URLs underneath it.

How does pagination affect SEO?

Deeper items need a discovery route

If a category displays only its first 24 products and the remaining products appear only after someone clicks a button, a crawler may never find the deeper items. Google generally discovers URLs through href values in links and does not click interface buttons to load more results.

A crawlable page sequence provides routes from the first set to the next and onward through the collection.

Every URL needs a stable purpose

Google treats the URLs in a paginated sequence as separate pages. Page two must consistently show its own portion of the collection rather than changing whenever new content is added in a way that makes the URL unreliable.

Absolute page numbers such as ?page=12 create a more stable reference than relative descriptions such as ?date=yesterday.

Canonical mistakes can hide the sequence

Canonicalising every component page to page one suggests that later pages are duplicates of the first, even though they contain different products or articles. That can make the routes to deeper items less clear.

Useful component pages should normally declare themselves as canonical.

The sequence can create inefficient URLs

Sorting, filters, session values and tracking parameters can combine with pagination to produce many alternate versions:

/chairs/?colour=blue&sort=price&page=3
/chairs/?sort=price&colour=blue&page=3&utm_source=email

The site needs a deliberate policy for which combinations deserve crawlable, indexable URLs and which should be limited or consolidated.

Pagination affects visitor experience

People may want to estimate the number of results, return to a previous position, share a particular page or reach the footer. The best interface depends on the task, not SEO alone.

Pagination, load more or infinite scroll?

Numbered pagination

Numbered pagination loads one result page at a time and shows controls such as:

Previous  1  2  3  4  5  Next

It helps people understand their position and move to a known page. It also naturally exposes separate URLs when implemented with links.

The trade-off is that each move requires another page load and the collection feels divided.

Load more

A load-more button appends another group of items to the current view. It gives the visitor control while preserving a continuous list.

The button itself is not a reliable crawl route. The same content should also exist at persistent paginated URLs connected by crawlable links.

Very large collections can eventually create an unwieldy page if every loaded group stays in the document.

Infinite scroll

Infinite scroll loads more content as someone reaches the end of the current set. It can feel natural for exploratory feeds but makes the size and position of the collection less obvious.

It also creates accessibility and navigation concerns when:

• The footer keeps moving away.
• Keyboard focus is not managed.
• A person cannot return to the same position.
• The URL does not update.
• Content loads only after a user scroll event.
• There is no way to pause or request the next set.

For search discovery, infinite scroll needs a paginated URL structure beneath the interface.

Choosing the pattern

Consider:

• How many items exist.
• Whether people compare specific results.
• Whether they need to return to a position.
• Device and network constraints.
• Page performance.
• Accessibility.
• Whether each content set has a stable URL.
• How crawlers reach the deeper items.

The choice is not permanent. A product category may use numbered pagination while a social feed uses infinite scroll, even on the same website.

Give every page a stable URL

Each component page needs a distinct URL:

https://www.example.com/chairs/
https://www.example.com/chairs/?page=2
https://www.example.com/chairs/?page=3

Use a consistent format and make each URL return the same portion of content whenever it is requested within a reasonable publishing model.

Keep page one consistent

Choose one form for the first page and use it throughout the site:

Preferred: /chairs/
Alternate: /chairs/?page=1

If both forms resolve, redirect or canonicalise the alternate appropriately and link internally to the preferred form. Do not alternate between them in menus, breadcrumbs and pagination controls.

Return a sensible response beyond the final page

A URL such as ?page=9999 should not return a successful empty copy of the category. When the requested page does not exist, return a suitable not-found response or otherwise prevent endless empty sequences.

Avoid session and temporary state

Do not include session IDs or relative values such as “today” in the core page URL. A link should remain shareable, refreshable and meaningful when revisited.

Keep the URL aligned with the content

If ?page=3 loads page one, redirects unexpectedly or shows a different set on every request, the sequence becomes difficult for people and crawlers to understand.

Link paginated pages sequentially

Use standard HTML links from each page to the next page:

<a href="/chairs/?page=2">Next</a>

On later pages, provide a previous link and continue the sequence:

<a href="/chairs/">Previous</a>
<a href="/chairs/?page=3">Next</a>

Google recommends linking pages sequentially so its crawler can find subsequent content. Consider linking every component page back to the first page as well, making the start of the collection clear.

Numbered links can give visitors more control and provide shorter routes to deeper pages:

<nav aria-label="Pagination">
  <a href="/chairs/">1</a>
  <a href="/chairs/?page=2" aria-current="page">2</a>
  <a href="/chairs/?page=3">3</a>
  <a href="/chairs/?page=3">Next</a>
</nav>

The interface does not need to link to every page in a collection of thousands. It needs a dependable route forward and back, with useful shortcuts where appropriate.

Do not rely on button clicks

This is an interface control:

<button onclick="loadNextPage()">Load more</button>

It may work for a person, but it does not give a crawler a URL to follow. Provide an underlying anchor route or progressive enhancement that exposes the paginated URL in the rendered HTML.

Do not nofollow the sequence

The pagination route exists to help crawlers and people reach deeper content. Adding nofollow to the next-page links works against that purpose and is not a substitute for controlling unwanted filtered URLs. Make every page in a sequence reachable through clear category navigation and a breadcrumb trail.

How to use canonical tags on paginated pages

Each useful page in the sequence should normally have a self-referencing canonical:

<!-- On /chairs/?page=2 -->
<link rel="canonical" href="https://www.example.com/chairs/?page=2">

Page three should canonicalise to page three, and so on.

Do not canonicalise every page to page one

Pages two and three are not duplicates of page one when they list different items. A page-one canonical can send the wrong consolidation signal and reduce the clarity of routes to deeper content.

Handle alternate versions separately

If the same page-two content is available with tracking or session parameters, those alternate URLs can canonicalise to the clean page-two URL:

/chairs/?page=2&utm_source=email
            ↓ canonical
/chairs/?page=2

That is different from canonicalising page two to page one.

A view-all page needs to be genuinely equivalent

A view-all URL can be useful when the complete collection loads reliably and remains usable. Do not create one solely to receive canonical tags if it is slow, incomplete or too large.

Only treat the component pages as duplicates of a view-all page when that page genuinely contains the equivalent complete content and is the preferred experience. For most large collections, self-canonical component pages are clearer.

Should later pages be indexable?

Do not automatically add noindex to every page after the first. Later pages contain links and items not present on page one and may provide valuable discovery routes.

Default to crawlable, indexable component pages when they contain useful parts of the collection and form the route to deeper items.

Consider exclusion only when the URL has no independent value and a deliberate alternative discovery system exists. Examples may include certain internal-search combinations or duplicate sort orders, but those are filtering decisions rather than ordinary pagination rules.

Before excluding a page, ask:

• Which products, articles or profiles are reached through it?
• Can crawlers reach those items through another reliable route?
• Does the page contain a unique portion of a useful collection?
• Is the real issue an uncontrolled filter or duplicate URL pattern?
• Would a canonical, redirect or link change better express the relationship?

Noindex should not be used to hide a sequence that the site still depends on for discovery.

Titles, descriptions and content across the sequence

Paginated pages share a topic and template, so some repetition is normal. Google states that pages in a sequence do not need distinct titles and descriptions solely because of pagination.

You may add a page number when it helps people distinguish tabs or results:

Office Chairs – Page 2 | Example Store

Do not spend time manufacturing unique promotional copy for every component page unless it genuinely improves the experience.

Focus on the content set and controls:

• Each page should show the intended items.
• Product or article links should use useful anchor text.
• Pagination controls should identify the current position.
• Headings should continue to describe the collection accurately.
• Filters and sort state should be visible when applied.
• Empty or invalid pages should not look like valid copies.

Duplicate metadata warnings on paginated sequences need context. They are not equivalent to several standalone landing pages accidentally sharing the same title.

How to make infinite scroll crawlable

Infinite scroll should be a presentation layer over a persistent sequence.

Give each chunk its own URL

Map every group of results to an address such as:

/articles/?page=2
/articles/?page=3

Opening that URL directly should return the correct group without requiring someone to scroll from page one first.

Link the chunks

Expose sequential <a href> links in the rendered page so crawlers can reach the next URL. They can be integrated with the interface or available through a progressive fallback.

Update the browser URL

When a newly loaded chunk becomes the primary visible content, the History API can update the displayed URL. That allows a person to refresh, share and return to their position.

Do not require user actions for discovery

Google does not scroll, click or trigger interface actions in the same way a person does. The relevant content and links need to become available through load behaviour that crawlers can process or through the underlying paginated pages.

Test the rendered output

Use URL Inspection and a browser's developer tools to confirm that the intended item links appear in the rendered HTML. Test page URLs directly, not only by scrolling from the first page.

What about rel="next" and rel="prev"?

Google no longer uses rel="next" and rel="prev" as indexing signals. Older articles may still recommend adding them to the document head, but they do not replace crawlable links between component pages.

Other consumers may use these relationships, so an existing valid implementation does not need to be removed solely for Google. Do not expect it to repair a sequence with missing URLs, broken links or incorrect canonicals.

Build the pagination around:

• Persistent component URLs.
• Sequential <a href> links.
• Appropriate self-referencing canonicals.
• Accessible controls.
• Direct links to the items in each set.

How filters and sorting affect pagination

Pagination becomes more complex when visitors can filter and reorder a collection:

/chairs/?page=2
/chairs/?colour=blue&page=2
/chairs/?colour=blue&sort=price&page=2

Decide which filtered combinations deserve stable search landing pages. A useful colour category with demand and unique value may be indexable; ten thousand arbitrary combinations may create unnecessary crawl volume.

Keep parameter order and URL output consistent

Do not generate several URLs for the same state by changing parameter order or including empty values. Normalise the format used by internal links.

Separate sorting from distinct content

Changing the order from price-low-to-high to price-high-to-low normally does not create a new collection. Avoid multiplying crawlable versions when the items are the same.

Handle empty combinations

Filter combinations with no results should not produce endless successful pages. Remove internal links to invalid combinations and return an appropriate response according to the site's design.

Keep canonical decisions accurate

Do not canonicalise a filtered page to an unfiltered category when their content and search purpose are materially different. Equally, do not self-canonicalise every machine-generated combination by default.

Pagination should follow the indexability policy chosen for the underlying collection state.

How to audit paginated pages

Identify the page pattern

Find URL parameters or paths used for page two and beyond. Group them by category, archive or template rather than treating every URL separately.

Test the sequence from page one

Follow the next links and confirm that:

• Every control resolves to the expected URL.
• No step returns an error.
• The sequence does not loop.
• The last page stops correctly.
• Previous links return to the right component.
• Page-one links use the preferred page-one URL.

Check rendered crawlable links

Confirm that next, previous and numbered routes exist as anchors with href values. Buttons and script events should not be the only route.

Review canonical targets

Find component pages canonicalised to page one, canonical tags that omit the page parameter or canonicals pointing through redirects. Each intended component should normally reference its own clean URL.

Check status and indexability

Look for noindexed component pages, soft 404s, empty successful pages and server errors. Determine whether the behaviour is intentional and whether deeper items still have a discovery route.

Compare items across pages

Find repeated or missing products caused by unstable sorting, inventory changes or off-by-one errors. A page number should return a predictable portion of the collection.

Review depth and reachability

Check whether deeper products or articles can be reached and how many steps the route requires. Very long sequences may benefit from numbered shortcuts, subcategories or additional relevant links.

Inspect filtered sequences separately

Measure how pagination combines with facets, sorting and tracking parameters. A correct base category can still generate a very large duplicate URL space after filters are applied.

Review pagination in Clearcrawl

Clearcrawl helps show whether the live website exposes the same sequence the interface appears to offer. A load-more button may work in a browser while a crawl reveals that no links lead to page two, or a shared canonical rule may collapse every component into page one.

Review patterns at template level. A single correction to a category component can repair hundreds of sequences.

How to fix and verify pagination

1. 01
   Define the intended collection

   Decide which items belong, how they are ordered and how many appear per page. Establish the clean URL format and the preferred version of page one.

2. 02
   Create stable component URLs

   Make every page independently accessible. Confirm that opening page three directly returns its expected items and navigation controls.

3. 03
   Add crawlable sequential links

   Use standard anchors for next and previous routes. Add page numbers or shortcuts when they improve navigation through a long collection.

4. 04
   Align technical signals

   Use the correct status, indexability and self-referencing canonical on each intended page. Normalise alternate page-one and tracking versions.

5. 05
   Test interface variants

   Check numbered pagination, load-more and infinite-scroll behaviour on desktop, mobile, keyboard and slower connections. Verify URL changes, history and return-to-position behaviour.

6. 06
   Crawl the sequence after launch

   Confirm that page links, canonical targets and item URLs are present in the rendered output. Test the final page and an out-of-range URL as well as the first few pages.

7. 07
   Monitor discovery and indexing

   Use Search Console to inspect representative component and item URLs. Allow time for recrawling, then investigate any important items that remain undiscovered or are assigned unexpected canonicals.

Common mistakes

Frequently asked questions