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.
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
Frequently asked questions
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.