Most pagination SEO best practices still circulating were written for a signal Google no longer reads. In March 2019, Google’s John Mueller said Google had not used rel="next" and rel="prev" in indexing for a number of years, as Search Engine Journal reported at the time. Google indexes paginated pages like any other pages.
The timing is what annoyed people. As late as January 2019, Google had still been recommending the markup. SEOs had spent years adding tags to archive templates for a signal that was already being ignored. The lesson is not that the tags were harmful. It is that pagination was always a crawling and linking problem, and the markup let people believe it was solved.
What changed when rel=next/prev went away
The markup was meant to tell Google that page 2, 3 and 4 belonged to one sequence. Without it, each paginated URL stands on its own. Page 3 of a category is just a page: it gets crawled if something links to it, indexed if Google finds it worth indexing, and judged on what it contains.
That shifts the work to things you control directly. Can a crawler reach page 7 by following links? Does page 7 have a stable URL? Does its canonical tell Google to keep it, or to throw it away in favour of page 1? Those three questions cover most of what goes wrong.
It also changes which pages deserve attention. Under the old model, people worried about consolidating a series into page 1. Now the useful question is narrower: which items can only be reached through deep pagination, and how many clicks does that take? A paginated archive is mostly a route to the things it lists, and the route is what needs checking.
Pagination SEO best practices that still hold
None of the guidance below depends on a Google number, because Google has not published one for pagination. It is the general practice that follows from paginated pages being treated as ordinary pages.
| Approach | Status | Why |
|---|---|---|
| rel=”next” / rel=”prev” | Not used by Google for indexing | Mueller confirmed in March 2019 it had not been used for years |
| A crawlable link to each page | Needed | Pages nothing links to are hard for a crawler to find |
| A distinct URL per page | Needed | Google indexes pages, and a page needs an address |
| Self-referencing canonical on page 2+ | Recommended | Page 2 is not a duplicate of page 1; its items differ |
| Canonical on every page pointing to page 1 | Avoid | Tells Google to drop the deeper pages and what they link to |
| Infinite scroll with no paginated URLs | Avoid | A crawler that does not scroll never reaches the later items |
Give each page a real <a href> link, not a JavaScript click handler that fetches the next set. Give each a URL that returns the same items every time it is requested, usually a ?page= parameter or a /page/2/ path. Either pattern works; consistency matters more than the format.
The canonical mistake that hides your deeper pages
The most common pagination error is pointing the canonical on every paginated page back to page 1. It looks tidy, and it comes from treating page 2 as a duplicate. It is not. Page 2 lists different products or posts from page 1, so telling Google they are the same page is inaccurate.
The cost is indirect. If Google follows that hint and drops page 2 onward, the products or articles linked only from those pages lose one of their main discovery paths. On a large category, that can be most of the catalogue. Use a self-referencing canonical on each paginated URL instead; our guide to the canonical tag covers how the hint works and where it goes wrong.
Duplicate content is a real concern in pagination, but it comes from somewhere else: sorting and filter parameters that create many URLs for the same list. That is a duplicate content problem with its own fixes, and it should not be solved by collapsing a genuine sequence into one page.
Infinite scroll vs pagination for SEO
Infinite scroll and load-more buttons are not the problem. Implementing them with nothing underneath is. If new items arrive only when a user scrolls or clicks, a crawler that does neither sees the first batch and nothing else.
The fix is to back the experience with paginated URLs. Each chunk of loaded items maps to a URL such as ?page=3, the page updates its address as the user scrolls, and plain links to those URLs exist in the HTML. Users get the scroll; crawlers get the series. A view-all page is another option for short lists, though for a long catalogue it can become a very heavy page.
Load-more buttons follow the same rule. A button that fetches items through a script is invisible to a crawler unless the next page also exists as a linked URL. The simplest pattern is a button that is a real link to page 2, enhanced with a script for users, so the page still works when the script does not run.
How to check your own pagination
Run a crawl and filter for paginated URLs. You are looking for three patterns: pages with no inbound links, pages whose canonical points elsewhere, and series that stop early because a link is rendered only after interaction.
- Depth: if the last page of a category sits a long click path from the homepage, the items on it are crawled less. Shorter series or better category structure help.
- Canonicals: every page 2+ should declare itself, not page 1.
- Raw HTML: view source, not the rendered page, and confirm the next-page link is there.
- Product links: check whether items reached only through deep pagination show up as orphan pages in your crawl.
Here is the limitation. Google has not published what it does with long paginated series beyond indexing them as ordinary pages, so nobody can tell you the page depth at which crawling falls off on your site. Anyone quoting a precise threshold is guessing. Your own crawl data and Search Console’s indexing reports are the only evidence that applies to your templates.
The practical takeaway is that pagination is rarely what holds back a small site. It matters most on large catalogues and archives, where the items deep in a series depend on those pages to be found at all. Start there, and use the internal linking guide to give important items a shorter path than page twelve.
Frequently asked questions
Does Google still use rel=”next” and rel=”prev”?
No. In March 2019 John Mueller said Google had not used them in indexing for a number of years. Paginated pages are indexed like any other page.
Should paginated pages canonicalise to page 1?
Generally no. Page 2 onward lists different items, so a self-referencing canonical on each page is the safer choice.
Is infinite scroll bad for SEO?
Only when there are no paginated URLs underneath it. Back the scroll with crawlable links to a URL for each chunk of items.
Should I remove the rel=next/prev tags?
There is no urgency. Google does not use them for indexing, and removing them gains nothing on its own. Spend the time on links and canonicals instead.
The takeaway Treat every paginated page as an ordinary page: its own URL, a crawlable link to it, and a canonical that points at itself. The markup was never the fix.
