Guides/Pagination and SEO, Explained
Technical

Pagination and SEO, Explained

Page 2 of your blog archive isn't harmless, but it's also not the crisis some SEO advice makes it out to be. Here's how paginated content actually gets crawled and indexed.

Bartu Cavusoglu

Founder, Vazagency · Runs reputation recovery and SEO campaigns for businesses across 35+ industries.

8 min read·Updated July 2026

Any time a list of content is too long for one page — a blog archive, a services category with dozens of entries, a page of customer reviews — it usually gets split into a numbered sequence: page 1, page 2, page 3, and so on. That splitting is called pagination, and it creates a real, if often overstated, set of SEO questions: does each page get indexed on its own? Do they compete with each other? Does splitting content this way waste anything search engines care about?

What pagination actually is

Pagination is any URL pattern that breaks one long list into multiple pages — commonly something like /blog?page=2 or /blog/page/2. For a local service business, the places this shows up most are a blog or news archive, a large photo gallery of completed jobs, and occasionally a reviews page if there are enough reviews to split. Each of those numbered pages is its own distinct URL, and search engines treat it that way — it can be crawled, indexed, and shown in results independently of the others.

The rel="next"/rel="prev" era, and why it's gone

For years, the standard advice was to add rel="next" and rel="prev" link tags in the page's <head> to explicitly tell Google which paginated pages were part of the same series. Google confirmed it stopped using those tags as an indexing signal. A lot of themes, plugins, and older CMS templates still add them automatically — that's harmless, but there's no reason to add them yourself if they're missing, and no benefit to removing them if they're already there.

How Google actually treats paginated pages today

Without special pagination markup to lean on, Google largely treats each paginated URL the way it treats any other page: it evaluates the content actually on that page and follows the links on it, including the link to the next page in the sequence. That means two things in practice. First, paginated pages need real, crawlable links between them — a plain <a href> to "next" and "previous," not a button that only works through a JavaScript click handler with no underlying URL. Second, most deep paginated pages simply won't rank for much, and that's fine — page 4 of a blog archive was never going to be anyone's landing page. Its job is to give search engines (and visitors browsing manually) a path to the individual posts listed on it, not to rank on its own.

Self-referencing canonicals: the right default

A common instinct is to set the canonical tag on every paginated page to point back to page 1, treating pages 2 and beyond as "duplicates" of the first page. That's usually a mistake. A canonical tag is a statement that two URLs show essentially the same content — page 2 of a blog archive doesn't show the same posts as page 1, so it isn't a duplicate of it. The safer default is a self-referencing canonical: each paginated page canonicalizes to its own URL. Treating pagination as duplicate content when it isn't can cause Google to drop pages 2 and beyond from the index entirely, cutting off a crawl path to whatever's listed on them. For the broader mechanics of when canonicals should and shouldn't point elsewhere, see canonical tags, explained.

The most common pagination mistakes

  • Canonicalizing every page to page 1 — treats genuinely different content as duplicate, which can suppress indexing of everything past the first page.
  • Noindexing all paginated pages by default — sometimes reasonable for very deep pagination, but blanket-applied it can remove one of the only paths to older content on a thin site.
  • "Next" links that only exist as JavaScript click handlers — with no real underlying URL, a crawler that doesn't execute the interaction never finds the next page.
  • Identical title tags and meta descriptions across every page — worth at minimum appending "— Page 2," "— Page 3," so paginated URLs aren't flagged as duplicate titles in a technical audit.

Better patterns than plain numbered pagination

A "view all" page

If the full list is short enough that a single page loads reasonably fast, a "view all" version can be a better landing page than any individual paginated slice — it's the one URL that actually contains everything, which makes it a natural target for both search engines and for anyone sharing a link to your archive.

"Load more," done correctly

A "load more" button is fine for visitor experience, but only when it's layered on top of real, crawlable paginated URLs rather than replacing them entirely. If the additional content only ever loads via a click with no corresponding URL a crawler can follow, that content may never get discovered at all — a much worse outcome than slightly old-fashioned numbered pages.

Filtered and faceted listings

If your site lets visitors filter a list by category, price, or location and each filter combination generates its own URL, that's a pagination-adjacent problem that can multiply URLs fast. Most filter combinations aren't worth indexing individually — this is where a canonical back to the unfiltered list, or a noindex on filtered variants, is usually the right call, unlike plain sequential pagination.

A practical checklist

  • Give each paginated page a unique, if minor, title tag variation.
  • Use a self-referencing canonical tag on each paginated page.
  • Don't noindex pagination by default — reserve that for genuinely deep, low-value pages.
  • Make sure "next" and "previous" controls are real, crawlable links.
  • Keep pagination shallow where you can — fewer, slightly larger pages beat dozens of thin ones.

Worth knowing

For most local service business sites, pagination only shows up on a blog archive or a job-photo gallery with a modest number of pages — not the tens of thousands of URLs that make pagination a genuine crawl budget concern for large e-commerce or publisher sites. It's worth setting up correctly, but it shouldn't be where a small site spends the bulk of its technical SEO attention.

Frequently asked questions

Do I still need rel="next" and rel="prev" tags on paginated pages?
No. Google announced years ago that it no longer uses rel="next"/rel="prev" as a signal for how it crawls or indexes paginated series. A lot of CMS themes and plugins still add these tags automatically, and that's harmless — they just don't do anything for you anymore. Don't spend time adding them if they're missing.
Will page 2, page 3, and so on of my blog compete with each other in rankings?
Generally no, because they usually don't target the same query. Page 1 of a blog archive might rank for your brand name or a broad topic; page 4 rarely ranks for anything specific, because it's just a slice of an ongoing list with no unique topical focus. That's normal — paginated archive pages aren't meant to be landing pages for search traffic, individual posts are.
Should I noindex page 2 and beyond?
Usually not by default. Noindexing every paginated page can cut off one of the only crawl paths to older content buried deeper in the archive, especially on a site with limited internal linking elsewhere. It's a reasonable move for genuinely low-value, deep pagination (page 40 of a large archive) but not a blanket rule for page 2 or 3.
What about "load more" buttons instead of numbered pages?
They work fine for the visitor, but if "load more" only works through JavaScript with no underlying paginated URL or crawlable link, search engines may never discover the additional content at all. The safer pattern is a "load more" button that's a progressive enhancement over real, crawlable paginated URLs — so a crawler that doesn't execute the click still has a path to every page.
Does pagination actually affect crawl budget for a small local business site?
Rarely in a meaningful way. Crawl budget is mostly a concern for sites with tens of thousands of URLs or more. A local service business with a blog of a few dozen posts and two or three archive pages isn't going to run into a crawl budget problem from pagination — it's worth doing correctly, but not worth losing sleep over at that scale.

More guides

Want this handled for you?

We build the SEO foundation and handle the ongoing work — no long-term contract, no guaranteed-rankings sales pitch.