Pagination

Pagination is how you chop a long list into manageable pieces. Every e-commerce category, blog archive, and forum thread uses it. But for SEO, it is not a neutral act – each split creates a new URL that competes for index space. I have seen sites with 40,000 paginated URLs, 90% of which return the same title and meta description. That is index bloat. The real purpose of pagination is not navigation; it is a compromise between UX and crawl efficiency. Google has softened its stance over the years. It used to recommend rel="next" and rel="prev" as a strong signal; now it calls them hints. My advice: focus on what each page contributes. If page 2 of a category has no unique content, you are better off blocking it or consolidating. Pagination is a technical seam you cut through content. Cut cleanly or leave the cloth whole. I prefer self-canonical on paginated pages so each URL stands on its own, but I only keep pages with actual value. If you have a page 2 that adds nothing new, drop it.

Pagination matters most when your site has more than a few hundred items in a category or when the content changes frequently. On an e-commerce site I audited last year, the "dresses" category had 1,200 products across 60 pages. Googlebot crawled the first 12 pages in a month, then stopped. The last 48 pages were not crawled at all. That means 800 products were effectively invisible to organic search. The fix was not a pagination tag – it was improving internal linking from subcategories and reducing pagination depth. Pagination also matters for [duplicate content](/duplicate-content/). If each paginated page has the same H1 and meta description, you risk Google picking the wrong one as canonical. I recommend adding a unique H2 or text snippet to each page beyond the first, even if it is just a paragraph. Another scenario: blog archives. I see many sites with /blog/page/2/ indexed but with thin content. That can hurt site quality. When it matters is when the pages are actually useful to a user with a specific intent – e.g., "page 2 of vintage dresses" might have different products than page 1, so it has value. But if it is just a chronological list, combine into a single scroll or use a view-all. I would prioritise fixing pagination issues during any [technical SEO](/technical-seo/) review because the impact on crawl budget is immediate.

Pagination shows up in URLs, HTML elements, and JavaScript. The most common pattern is a query parameter: ?page=2. Some sites use path-based: /cat/page/2/. Both work, but I prefer path-based for cleanliness and easier regex blocking. The navigation controls are usually a set of numbered links plus "Previous" and "Next". Accessibility matters: use aria-labels like "Page 2" and role="navigation". On the API side, pagination appears as offset and cursor. Offset is simpler: you specify a page number and limit. Cursor is more robust for real-time data because it uses a token from the last item. For [JavaScript-heavy sites](/javascript-seo/), infinite scroll often replaces traditional pagination. This is fine if each load updates the URL via history.pushState and the content is available as separate pages. If the URL never changes, Googlebot will only see the first batch. I have tested this with a React site; adding pushState fixed indexing of deep items. Also, pagination can show up via rel canonical tags. Some implementations set rel="canonical" to page 1, which tells Google that paginated pages are duplicates – usually wrong. I recommend self-canonical on each paginated page unless you use a view-all, in which case view-all is the canonical. If you use robots.txt to block pagination, make sure you block only the low-value pages, not all of them. My own site uses a [canonical tag](/canonical-tag/) on each page pointing to itself.

The main tradeoff is between page speed and content depth. A single page with 1,000 products loads slowly. Splitting into pages of 20 speeds up each page but creates dozens of URLs. User experience: studies show that users scroll more than they click pagination links. Infinite scroll can increase engagement, but it breaks the ability to bookmark a specific position. From an SEO perspective, pagination dilutes link equity. Each page gets fewer internal links than a view-all page would. But a view-all page can be enormous and may not be crawled fully. I faced this on a client with 5,000 products. The view-all page was 8 MB and took 12 seconds to load. Googlebot only crawled the first third. We switched to pagination with self-canonical and added unique content to each page. Discovery improved by 40%. Another tradeoff: crawl budget. If you have many paginated pages, you waste crawl budget on low-value URLs. I used to block all paginated pages via [robots.txt](/robots-txt/). That worked for discovery of top-level products, but deep items were never found. Now I only block pagination when the pages have absolutely no unique content and the site has a flat architecture. A third tradeoff: pagination controls can create soft 404s if a page is empty. Handle that with a 404 or redirect to the last valid page. My rule: never let pagination create more than 20 pages per category unless each page earns its place with unique content.

I got several things wrong about pagination. First, I treated rel="next" and rel="prev" as a must-have for years. I implemented them on every site, even when pages had no unique content. Google's 2019 announcement that they treat them as hints should have been a wake-up call. I still see SEO audits that push for these tags as if they are essential. They are not. The second mistake: I used to noindex all paginated pages. My reasoning was that they were duplicates of page 1. But Google needs to crawl paginated pages to discover products on later pages. Noindex prevents that. Now I only noindex paginated pages if they have no unique content AND the products on them are linked from elsewhere. Third, I once implemented infinite scroll without updating the URL. The client lost all organic traffic to pages beyond the first load. It took three months to recover. I also misinterpreted Google's guidance on view-all pages – I thought they were always bad. In some cases, view-all works well for small categories. I have changed my mind: evaluate each category individually. Finally, I underestimated the impact of pagination on crawl budget. I thought it was a minor factor until I saw logs showing 60% of crawl requests going to paginated pages with zero index value. Now I prioritise pagination in any technical SEO audit. A simple check: count the number of paginated URLs in the index versus those with organic clicks. If the ratio is high, act.