localwebadvisor
WIKI← Wiki home

What Is Pagination in SEO?

By FayUpdated Jul 9, 2026EVERGREEN
⚡ THE ANSWER

Pagination in SEO is the practice of splitting a large set of content across multiple sequential pages, such as page 1, page 2, and page 3 of blog listings, product categories, or search results. Each page carries its own URL, usually with a parameter like ?page=2. Good pagination helps search engines discover and crawl deep content efficiently while giving users a manageable way to browse long lists without loading everything at once.

Common URL pattern
?page=2 or /page/2/ appended to the base category URL (industry-typical)
rel=next / rel=prev
Google stopped using these link attributes as an indexing signal in 2019 (Google Search Central)
Canonical rule
Each paginated page should self-canonicalize, not point to page 1 (Google Search Central)
Crawl benefit
Pagination exposes deep URLs to crawlers that would otherwise be buried (industry-typical)

What does pagination actually do? #

Pagination breaks a long collection of items into a series of numbered pages so neither the browser nor the crawler has to process hundreds of entries in a single request. A plumber's blog with 200 articles might show 10 posts per page across 20 pages, and an HVAC parts store might list products across dozens of category pages. Each page in the sequence gets a unique, crawlable URL. This matters for two audiences at once. Human visitors get a predictable way to move through a list without an endless scroll or a multi-megabyte page. Search engine crawlers get a trail of links that leads them to older or deeper content they might never reach otherwise. Without pagination, or with pagination that hides links behind JavaScript-only buttons, your newest ten items might be indexed while everything older quietly falls out of Google's view. For local businesses building content over years, that buried archive is often where a lot of long-tail search traffic lives.

How has Google's guidance on pagination changed? #

For years, webmasters used rel=next and rel=prev link attributes in the page head to tell Google that a set of URLs formed one logical sequence. In 2019 Google confirmed it had not used those signals for indexing in a long time, which surprised many SEOs. The practical takeaway is that you no longer need to rely on those tags for Google, though Bing and some other engines still read them, and they cause no harm. What Google does instead is treat each paginated page as its own page and rely on the plain HTML anchor links between them to understand the relationship. This is why the single most important rule today is simple: make sure page two, page three, and beyond are linked with ordinary crawlable <a href> links, not buttons that only work with JavaScript. If a crawler cannot follow the link, the page effectively does not exist. Our /services/local-seo work almost always includes an audit of how category and blog pagination is wired.

Should paginated pages be canonicalized to page 1? #

No, and this is one of the most common and damaging mistakes we see. A canonical tag tells search engines which URL is the master version of a set of duplicates. Some site owners set every paginated page to canonicalize back to page one, assuming this consolidates ranking signals. In reality it tells Google to ignore pages two and beyond entirely, which means every item listed only on those deeper pages loses its discovery path. The correct approach is self-referencing canonicals: page two canonicalizes to page two, page three to page three. Each is a distinct page with distinct content, so each should point to itself. If you genuinely want a single indexable page, use a proper view-all page and canonicalize the paginated series to it, but only when that view-all page loads reasonably fast. You can confirm what a page declares with our /tools/schema-validator and by inspecting the page source directly. For most local business sites, self-canonical pagination is the right default.

What is the difference between pagination and infinite scroll? #

Infinite scroll loads more items automatically as the user scrolls down, usually by fetching data with JavaScript and appending it to the page. It feels smooth on mobile, but it creates a real SEO problem: if there are no distinct URLs and no crawlable links, Googlebot cannot reach the content beyond the first batch. Traditional pagination assigns each chunk a URL that a crawler can request directly. The best of both worlds is progressive pagination, where infinite scroll is layered on top of real paginated URLs, so users get the smooth experience while crawlers and users who share links still get addressable pages. If your site relies heavily on client-side rendering, review our /wiki/what-is-javascript-seo entry, because the same rendering pitfalls that break JavaScript sites also break JavaScript-driven infinite scroll. A restaurant showing a long menu or a gym listing class schedules should make sure every section has a stable, linkable URL rather than hiding it behind an endless scroll.

How does pagination affect crawl budget? #

Crawl budget is the number of URLs a search engine is willing to fetch from your site in a given window. On very large sites, poorly designed pagination can waste that budget by generating endless combinations of filters, sort orders, and page numbers. A product category that can be sorted by price, filtered by five attributes, and paginated twenty deep can spawn thousands of near-duplicate URLs. Crawlers burn time on these instead of your important pages. To keep budget focused, avoid indexing filtered and sorted variants, keep the paginated sequence clean and shallow where possible, and make sure your XML sitemap points to the canonical URLs you actually want ranked. Our /tools/broken-link-checker helps confirm that the links inside your pagination all resolve, and /services/speed-optimization work often uncovers bloated category pages that generate excessive URL variants. For most local business sites crawl budget is not a constraint, but ecommerce catalogs and large content archives need to watch it closely.

Should you index every paginated page? #

In most cases yes, let paginated pages be indexable, because they are the discovery path to your deeper content. A common wrong instinct is to add noindex to pages two and beyond. The danger is that Google eventually treats noindexed pages as nofollow over time, which cuts off crawling of the items linked only from those pages. If you want the individual items indexed, keep the pages that link to them crawlable and indexable. That said, thin paginated pages that add no unique value, like an author archive with two posts, may not deserve indexing, and you can use robots meta tags thoughtfully. The safest default for a growing local business site is: index the paginated series, self-canonicalize each page, and make sure every page links clearly to the next and previous. Read /wiki/sitemaps-and-robots-txt-explained for how sitemaps and robots rules interact with these decisions, and confirm your setup with /tools/website-grader.

What are best practices for pagination URLs? #

Keep paginated URLs clean, consistent, and predictable. Use a single, stable parameter such as ?page=2 or a path segment like /page/2/, and pick one pattern for the whole site rather than mixing formats. Avoid stacking multiple parameters that reorder or randomize, because that generates duplicate content under different URLs. Do not append tracking or session parameters to paginated links. Make sure page one is reachable at the clean base URL, for example /blog/, and does not also exist at /blog/page/1/ as a separate indexable duplicate; if both exist, canonicalize the numbered version to the clean base. Provide visible numbered links and next/previous controls in the HTML so both users and crawlers can navigate. Add descriptive, unique title tags where practical, though many sites reasonably keep titles consistent across the series with the page number appended. If you are planning a /services/website-redesign, lock down the pagination URL pattern early so redirects stay simple.

How do you test that pagination works for SEO? #

Start by disabling JavaScript in your browser and reloading a category or blog listing. If the next-page and numbered links disappear, crawlers likely cannot follow them either, and you have a rendering problem worth escalating to /services/website-rescue. Next, use Google Search Console's URL Inspection tool to fetch page two and confirm Google sees the links to individual items and to page three. Check the rendered HTML, not just the raw source, since JavaScript frameworks assemble navigation after load. Verify that each paginated page returns a 200 status, self-canonicalizes, and is not blocked in robots.txt. Crawl the site with a desktop crawler and confirm the pagination forms an unbroken chain with no orphaned deep pages. Finally, watch your index coverage report over a few weeks to make sure deeper items are actually getting indexed. Our /tools/website-grader gives a fast first-pass read, and a full /services/local-seo audit digs into the coverage data behind it.

Does pagination matter for local businesses? #

It matters more than most owners expect. A single-location dentist may only have a handful of pages, but the moment you start publishing regularly, running a blog, or listing services, procedures, or a portfolio, you accumulate content that needs an organized navigation path. A landscaper with years of project write-ups, a law firm with dozens of practice-area articles, or an auto repair shop with a growing FAQ library all rely on pagination to keep older content discoverable. If pagination is broken, that back catalog stops earning search traffic, which is exactly the long-tail traffic that converts well because it answers specific questions. When we build sites at /services/web-design and support them through /services/care-plans, clean pagination is part of the baseline. It is not glamorous, but it is the plumbing that keeps your growing content library visible to both Google and the customers searching for the specific thing you wrote about.

FAQ

Do I still need rel=next and rel=prev tags?

Google no longer uses them for indexing, so they are optional for Google. Bing and some other engines still read them, and they cause no harm, so many sites keep them. The more important requirement is plain, crawlable HTML links between your paginated pages so any search engine can follow the sequence.

Should page two canonicalize to page one?

No. Each paginated page should self-canonicalize, meaning page two points to page two. Canonicalizing everything to page one tells Google to ignore the deeper pages, which cuts off discovery of every item listed only on pages two and beyond. Self-referencing canonicals keep the whole series indexable.

Is infinite scroll bad for SEO?

It is risky when it has no crawlable URLs behind it, because search engines cannot reach content past the first batch. The fix is progressive pagination: layer infinite scroll on top of real paginated URLs so users get smooth scrolling while crawlers and shared links still reach every addressable page.

How many items should I show per page?

There is no fixed rule, but 10 to 30 items per page is typical and keeps pages fast. Showing too few creates unnecessarily deep sequences that dilute crawling; showing too many slows the page. Balance page speed against the number of pages a crawler must traverse to reach your oldest content.

Should paginated pages have unique title tags?

It helps but is not mandatory. Many sites keep a consistent title across the series and append the page number, such as Blog Page 2. This avoids awkward or thin variations while still distinguishing each URL. Focus first on making the pages crawlable and self-canonical before optimizing titles.

Can pagination hurt my crawl budget?

On large sites, yes. Filters, sort orders, and deep page numbers can multiply into thousands of near-duplicate URLs that waste a crawler's time. Keep the sequence clean, avoid indexing filtered variants, and point your sitemap at the canonical URLs. Most small local sites are not affected, but big catalogs must watch this closely.

Was this helpful?