← Back to Blog

Broken pagination markup quietly deindexes your best content

Broken pagination markup quietly deindexes your best content

If your site has paginated content (blog archives, product listings, search results), the way you mark up those pages tells Google how to handle them. Get it wrong and Google may decide that pages 2 through 10 of your blog archive are duplicates of page 1. Your content still exists on the server, but search engines stop visiting it, stop indexing it, and the posts buried on later pages quietly disappear from search results.

Google officially deprecated rel=next/prev as a ranking signal in March 2019, after years of using it to understand paginated series. But here's the thing: Google still crawls those tags when present, they still help Google understand page relationships, and other search engines like Bing still actively use them. More importantly, the canonical tag on paginated pages is still very much active, and that's where the real damage happens.

The canonical-to-page-1 trap

The most destructive pagination mistake is setting the canonical URL on every paginated page to point back to page 1. This happens constantly. An SEO plugin auto-sets canonical tags, and the developer doesn't configure it to handle pagination differently. So page 2 says its canonical is page 1. Page 3 says its canonical is page 1. Google reads this as: "Pages 2 through 10 are duplicates of page 1. Ignore them."

The content on those pages, every blog post, every product listing, every article on pages 2 and beyond, gets treated as duplicate content. Google won't index those paginated pages, and the individual items linked from them lose their primary discovery path through your site's internal link structure.

The fix is straightforward: each paginated page should have a self-referencing canonical. Page 2's canonical should be page 2's URL. If you want to consolidate, use a "view all" page and set that as the canonical, but only if that page actually loads all content (not lazy-loaded, not behind a "load more" button that requires JavaScript).

Asymmetric rel=next/prev

Another common problem is broken link chains. Page 1 says rel=next points to page 2. Page 2 says rel=prev points to page 1 and rel=next points to page 3. But page 3 has no rel=prev tag at all. The chain is broken, and crawlers that follow it can't confirm the sequence is intentional.

This happens when different page templates handle pagination differently, when a CMS plugin is configured for some content types but not others, or when a site redesign updates the main blog template but misses the category archive template. The result is a mix of correctly linked pages and broken chains that undermine the entire sequence.

Query parameters in canonical URLs create another layer of problems. If your paginated URLs use ?page=2 but the canonical strips query parameters, you've effectively told Google that every page is page 1.

What the audit checks

The Pagination Sanity tool follows the rel=next chain from page 1, validating up to 10 pages. For each page, it checks whether rel=next and rel=prev are symmetric (page 2's prev matches page 1's next), whether the canonical URL is self-referencing or incorrectly pointing to page 1, and whether query parameters like ?page= appear inside canonical URLs where they shouldn't.

It catches the three biggest problems in one pass: the canonical-to-page-1 anti-pattern, broken prev/next chains, and canonical URLs that strip pagination parameters.

This pairs well with the Sitemap Lastmod Truthfulness audit. If your paginated pages are being ignored because of canonical issues, fixing the canonicals will cause a surge of recrawling, and stale lastmod dates in your sitemap could delay that process. The Orphan Page Detector is also relevant here since items on deep paginated pages are often the most at risk of becoming effectively orphaned.

In The $97 Launch, I discuss how content architecture determines whether your work compounds or gets buried. Pagination is one of those structural decisions that seems trivial but directly controls how much of your archive Google actually sees.

Fact-check notes and sources

  • Google deprecated rel=next/prev as a ranking signal in March 2019. Source: Google SearchLiaison tweet, March 21, 2019. Confirmed by John Mueller in subsequent webmaster hangouts.
  • Google still crawls and processes rel=next/prev tags for link discovery, even though they don't function as an indexing signal. Source: Google Search Central documentation on pagination.
  • Bing continues to use rel=next/prev to understand paginated content sequences. Source: Bing Webmaster Guidelines.
  • Self-referencing canonicals on paginated pages are Google's recommended approach. Source: Google Search Central, "Consolidate duplicate URLs".

Related reading

This post is informational, not SEO-consulting advice. Mentions of Google and Bing are nominative fair use. No affiliation is implied.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026