Pagination and SEO
Markdown
Pagination creates multiple URLs from a single body of content: a blog archive split across 20 pages, a product category divided into pages of 24 items each, or a comment thread spread across 10 pages. Each paginated URL is technically distinct, and Google must decide what to do with them. The decisions you make about pagination structure affect crawl efficiency, indexation, and where ranking signals consolidate.
The end of rel=prev/next
Many technical SEO guides still recommend rel=prev and rel=next link attributes to signal paginated sequences to search engines. Google announced in March 2019 that it was dropping support for them, and the 2011 blog post that introduced the attributes now carries a note saying they are not an indexing signal anymore.1 Google’s John Mueller put the timing bluntly on the day: “We noticed that we weren’t using rel-next/prev in indexing for a number of years now, so we thought we might as well remove the docs.”2 They have no effect on how Google handles paginated content, though Google’s current pagination guidance notes that other search engines may still use them.3
The announcement surprised many SEOs because Google had previously recommended these attributes.1 The clarification confirmed what Google actually does: it analyses paginated content individually, makes independent indexation decisions for each URL, and does not use prev/next relationships to consolidate signals.2 Implementing rel=prev/next does no harm, but it does nothing in Google Search.
How does Google handle paginated URLs?
Google’s approach to paginated content is largely pragmatic:
- It finds paginated URLs through links in the
hrefof<a>elements, typically “next page” links, and does not click buttons to load more3 - It treats each paginated URL as a separate page and indexes pages as it finds them32
- It does not automatically consolidate signals from paginated URLs to the first page
How deep into a sequence Google indexes varies by site. URL Inspection on, say, pages 5, 10 and 20 of a large category shows where it stops on yours. Page 1 is the URL that should match a category query, because it carries the category name, any introduction and most of the internal links. Nobody searches for “page 14 of your shoes category.”
URL structure for paginated content
Paginated URLs can use path-based or parameter-based formats:
Path-based: /blog/page/2/, /category/shoes/2/
Parameter-based: /blog/?page=2, /category/shoes/?paged=2
Either format works. Google’s requirement is a unique URL for each page, and its own example is a ?page=n parameter.3 The format to avoid is a URL fragment (#page=2): Google ignores everything after the #, and may not follow a link to the next page if only the fragment differs.3 The practical risk with parameters is your own configuration: a broad robots.txt rule such as Disallow: /*?, written to stop filter and sort URLs being crawled, also blocks ?page=2.
Should paginated pages appear in search results?
These are the arguments usually made for keeping pages 2 and beyond out of search results, and they are not equally strong.
A paginated page makes a poor landing page. A searcher who arrives on page 4 lands halfway through a list, without the introduction and filters page 1 carries. Listing pages also shift: as products are added or sell out, items move between pages, so the item that matched the search may have moved by the time someone clicks. This holds whatever a search engine does, because it is about the reader.
Page 2 can outrank page 1. When a paginated URL ranks for the category query, the searcher gets the weaker page. This holds, with a limit: if page 2 ranks for a query matching items that sit on page 2, it is the more relevant result, and the diagnosis is in the section on why page 2 ranks instead of page 1.
“Thin listing pages drag down the whole site.” The concern is that hundreds of pages with no unique copy count against the site as low-quality content. Google’s pagination guidance treats a sequence as ordinary site structure: pages in it can share one title and description, because “Google tries to recognize pages in a sequence and index them accordingly”.3 It does not describe paginated listings as a quality risk.
“Keeping them out saves crawl budget.” Google still fetches a noindexed page to read the tag, so noindex keeps pages out of the index without reducing crawling; only a robots.txt block does that. Google also scopes crawl budget to sites with over a million pages, or over 10,000 pages that change daily.4
Duplicate-title warnings and report clutter. SEO crawlers flag every page in a sequence as a duplicate title, and Search Console lists the extra URLs. Google says reusing titles across a sequence is fine,3 so this is a reporting nuisance rather than a search problem.
Against all of them: pages 2 and beyond can rank for long-tail queries that match the items on them, and a long-standing noindex cuts off any item linked only from pagination.5 The first two arguments are the ones worth acting on, and giving page 1 content the later pages cannot have addresses both before any noindex is needed.
A paginated URL is a slot, not a page
On a list that grows or churns, nothing stays on page 3 for long. A news section sorted newest first pushes every article down one place each time something is published, so today's lead story sits on page 40 a year from now, dozens of clicks from page 1. A product category moves both ways: new stock pushes items back and sold-out stock pulls them forward, so page 3 changes even when nobody edits the category. Whatever Google stored for page 3 describes items that may have moved on, and an item whose only internal link is its current slot keeps sinking. Give items links that do not move: the XML sitemap, sub-category pages, related-item links and, for news, date archives such as /2026/10/, which stop changing once the month ends.
The exception is pagination where nothing is added or removed: a long guide split across several pages, a gallery or list article served one item per page, or the episode list of a finished podcast season. There, page 3 stays page 3, and the case against indexing it is weaker.
Strategies for paginated content
Give each page its own canonical (Google’s documented approach): each paginated URL points its canonical at itself, and each can be crawled and indexed. Google’s ecommerce pagination guidance is explicit: “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL.”3 This suits a long-running blog where older posts have no other access path, or a product catalogue where pages 2+ list entirely different products.
Do not canonical deep pages to page 1. A widely taught recommendation was to add <link rel="canonical" href="/category/shoes/"> to pages 2, 3, 4 and so on, to consolidate signals onto the first page. Google’s current guidance says not to.3 When Google does follow that canonical, the result is not consolidation: Google said in 2013 that it “would result in the content on pages 2 and beyond not being indexed at all”.6 A canonical tag is a signal Google weighs, not an instruction it must follow,7 so it may be followed on some pages in a set and overridden on others, which is why results from it vary. If the goal is keeping deep pages out of the index, noindex does that directly. The one canonical target Google has endorsed for a paginated series is a view-all page listing every item, in 2011;8 that recommendation does not appear in its current pagination guidance.
noindex on pages 2 and beyond: keeps the deeper pages out of the index while leaving them crawlable. Many SEOs do this as standard on large catalogues, and Google’s pagination guidance does not advise against it; the noindex it recommends there is for filter and sort URLs.3 Whether it is safe depends on whether the items on those pages can be found another way. Mueller’s account is that Google follows a noindexed page’s links at first and then, if the noindex persists, drops the page entirely and stops following them, which makes “a noindex and follow … essentially kind of the same as a noindex, nofollow” in the long run.5 If every product or post is also in the XML sitemap or linked from sub-categories and other pages, nothing is lost. If page 7 of a blog archive is the only route to an old post, noindex eventually cuts that post off. The page must be crawlable for noindex to work; do not also block it in robots.txt.
Test whether your items survive without pagination
Whether noindexing pages 2 and beyond helps or hurts comes down to one thing that differs by site, and you can measure it before changing anything. Crawl the site with paginated URLs excluded (in Screaming Frog, Configuration > Exclude with a pattern such as .*/page/.* or .*\?page=.*), then compare the product or post URLs the crawl found with the full list from your XML sitemap or CMS export. Anything missing is reachable only through pagination, and it is what a long-standing noindex on pages 2+ would cut off. The same applies to a canonical pointing at page 1, which removes those pages from the index whenever Google follows it. A short list means noindex is low-risk; a long one means fixing the internal linking comes first.
Infinite scroll: presents an SEO challenge because paginated content only loads as users scroll. Google Search does not scroll or click to load content, so content that loads only when a user scrolls or clicks never loads for Google. Google’s guidance is to give each chunk its own persistent URL (/category/shoes/, then /category/shoes/2/), link to those URLs sequentially so they can be discovered, and update the displayed URL with the History API as each chunk becomes the primary visible element.9
Why is page 2 ranking instead of page 1?
A paginated URL outranking the page it belongs to is a common and frequently misdiagnosed problem. The instinct is to reach for a canonical pointing at page 1, which is the one fix Google’s pagination guidance rules out. Work through the causes in this order.
Check whether it is a problem at all. Filter the Search Console Performance report by the paginated URL and read the queries it wins. If the query matches items that sit on page 2, Google has made a reasonable choice and page 1 has nothing better to offer it. The click still arrives. The only real cost is a reader landing halfway through a list, and that is a content problem rather than a canonical one.
Redirect ?page=1 to the bare URL. This is the one true duplicate in a paginated set, and it is a common reason the parent URL loses to a numbered one. The same applies to any other parameter that renders the first page, such as ?start=0 or ?offset=0. Unlike page 2, these URLs are identical to the parent, so a 301 is correct here in a way it never is further into the sequence.
Give page 1 content the later pages cannot have. Most first pages are a bare listing, identical in template and wording to page 2, which leaves Google choosing between them on link signals alone. Put the descriptive introduction, the query-matching copy and any supporting sections on page 1 only, and let pages 2 and beyond carry the listing and nothing else. This is the durable fix, because it makes page 1 the only page in the set that matches the query.
Audit the internal links into the set. The parent URL should be what navigation, breadcrumbs and hub pages link to. Google’s pagination guidance also suggests linking back to the first page from every page in the collection, as a hint that page 1 is the better landing page.3 Check external links too: a single decent link pointing at the ?page=2 URL can outweigh everything else you do.
Use noindex on pages 2+ only if the items have another route in. It takes the competing page out of the index, but Google eventually stops following a noindexed page’s links,5 so check first that every item on those pages is also in the XML sitemap or linked from elsewhere. If the paginated page ranks for a distinct query, the better answer is usually that the query deserves its own filtered or sub-category URL rather than being suppressed.
URL Inspection on the paginated URL is a fast first diagnostic: the Google-selected canonical and the referring page data usually separate a genuine duplicate from a differentiation problem in seconds.
Does deep pagination waste crawl budget?
Only on large sites. Google’s crawl budget guidance is written for sites with over a million pages, or over 10,000 pages whose content changes daily, and says that if your pages are crawled the same day they are published, “you don’t need to read this guide”.4 A large ecommerce catalogue is where it applies: 500 category pages, each paginated to 50 or more pages, is tens of thousands of listing URLs for Googlebot to fetch alongside the products.
What each fix does to crawling:
- Show more items per page. Fewer pages in the sequence means fewer URLs to crawl, with no loss of discovery.
- Block deep pagination in robots.txt. This is the fix that stops the crawling, and Google’s guidance reserves robots.txt for pages you do not want crawled at all.4 It also stops Google following the links on those pages, so every item on them needs another route in, through the XML sitemap, sub-categories or other internal links. Google also says it will not move the freed crawling to other pages unless it is already hitting your site’s crawl capacity limit.4
- noindex does not save crawl budget. Google still has to fetch the page to read the tag, and its crawl budget guidance says not to use noindex for this: Google “will still request, but then drop the page”, “wasting crawling time”.4 Use noindex to keep pages out of the index, not to reduce crawling.
If deep paginated URLs are already indexed and you want them both out of the index and no longer crawled, sequence the two: noindex first, wait for the URLs to drop out, then add the robots.txt block. Blocking first stops Googlebot reading the noindex, so the URLs stay in the index with nothing to show.
Parameter-based pagination and Search Console
If your site uses parameter-based pagination (e.g. ?page=2), Google now handles parameter detection automatically. The Search Console URL Parameters tool was removed in April 2022.10 What remains is on the page and in robots.txt: a self-referencing canonical on each page, noindex on deep pages if you want them out of the index, and robots.txt rules that block filter and sort parameters without catching the page parameter. Do not reach for a canonical pointing at the first page: Google advises against it whether the pagination is path-based or parameter-based.
Frequently asked questions
Does Google index paginated pages?
Yes, as separate pages: Google indexes paginated URLs as it finds them rather than as a set. How deep it goes varies by site, so check a few deep pages with URL Inspection. Page 1 is the one that should rank for the category query, because it carries the category name and introduction.
Should I noindex all pages after page 1?
It is a common choice, and Google’s pagination guidance does not advise against it. It is safe when every item on those pages is also linked from somewhere else, such as the XML sitemap or sub-category pages. Google eventually stops following a noindexed page’s links, so items reachable only through pagination lose their route in.
Should I canonical pages 2+ to page 1?
No. Google advises against it. When Google follows that canonical, pages 2 and beyond drop out of the index, the same end state as a noindex but less predictable. Give each page a self-referencing canonical, and use noindex if you want to keep deep pages out of the index.
Footnotes
-
Pagination with rel=“next” and rel=“prev” — Google Search Central Blog (updated to note the attributes are no longer an indexing signal) ↩ ↩2
-
Google: rel=prev/next is not an indexing signal anymore — Search Engine Roundtable (John Mueller, 21 March 2019) ↩ ↩2 ↩3
-
Ecommerce pagination and incremental page loading — Google Search Central ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
-
Optimize your crawl budget — Google Search Central ↩ ↩2 ↩3 ↩4 ↩5
-
English Google Webmaster Central office-hours hangout, 15 December 2017 — Google Search Central, YouTube, from 54:51; transcribed in Google: Long Term Noindex Will Lead To Nofollow On Links — Search Engine Roundtable, 28 December 2017. Asked how long it takes, Mueller answered “it depends”. ↩ ↩2 ↩3
-
5 common mistakes with rel=canonical — Google Search Central Blog, April 2013 ↩
-
Consolidate duplicate URLs — Google Search Central (describes
rel="canonical"as “a strong signal”) ↩ -
View-all in search results — Google Search Central Blog, September 2011 ↩
-
Fix lazy-loaded content, infinite scroll section — Google Search Central ↩
-
Spring cleaning: the URL Parameters tool — Google Search Central Blog ↩