Fix Pagination rel=next/prev & Canonical Errors
Your audit found a problem with how your paginated pages (page 2, page 3, and beyond) declare their relationships: rel=next/prev links are broken or in the wrong place, the chain loops back on itself, or a paginated page's canonical points somewhere it shouldn't. Google stopped using rel=next/prev as an indexing signal back in 2019, so the modern fix is a self-referencing canonical on every paginated page, sequential rel links kept in the head only if you use them at all, and no page that canonicalizes to page 1. Done right, this keeps crawlers on a clean path to your deeper pages and indexes the correct URLs.
What this means
This warning covers three related pagination mistakes on a paginated series: category listings, blog archives, search results, or any /page/2, ?page=3 style URLs.
pagination_in_body means your rel="next" / rel="prev" link elements were found inside the page body instead of the document <head>. A <link> with a rel of next or prev is only valid in the <head>. Placed in the body, parsers ignore it and it does nothing.
pagination_loop means the rel chain is malformed and points back on itself. For example, page 3 declares page 1 as its "next", or a page lists itself as its own "prev". A broken chain sends conflicting signals about the order and boundaries of the series.
paginated_page_canonical_mismatch means a paginated page (say ?page=4) has a rel="canonical" pointing to a different URL, most often page 1. That tells Google "this page is a duplicate of page 1", which buries every link and piece of content that only exists deeper in the series.
Context that changes the priority: Google confirmed in 2019 that it no longer uses rel=next/prev as an indexing signal, and treats each page in a series as its own page. Having the tags is not an error. Bing and some other crawlers still read them, and they help assistive technology, but they must be correct. The load-bearing fix is the canonical setup.
Why it matters
The canonical mismatch is the part that actively hurts you. When ?page=2 through ?page=N all canonicalize to page 1, Google consolidates them onto page 1 and drops the deeper pages from the index. Everything that only appears on those deeper pages, such as product links, article links, and long-tail content, loses its path to being crawled and ranked. On large catalogs and archives this can strand thousands of URLs, because pagination is often the only internal-link route to them.
A broken rel chain (a loop, or tags stranded in the body) is a weaker signal, but it still muddies how any crawler that reads those tags understands your series. Paired with a canonical mismatch, you are sending genuinely contradictory instructions, and Google may lean on your canonical hints less across the site as a result.
For AI answer engines like ChatGPT, Perplexity, and Google AI Overviews, the mechanism is the same. Their crawlers reach deep products and articles mainly by walking pagination links. If page 2 and beyond are marked as duplicates of page 1 and effectively dropped, that content becomes invisible to the models. It cannot be cited in an answer if the crawler was told it was not worth keeping. Clean, crawlable pagination with correct canonicals keeps your full catalog reachable by both classic search and AI crawlers.
How to fix it
- 1
Give every paginated page a self-referencing canonical
This is the fix that matters most. ?page=2 must canonicalize to ?page=2, not to page 1. Each page in the series is distinct, so its canonical points to itself. Only point paginated canonicals at page 1 if you also publish a single 'View All' page and are deliberately consolidating onto it. Otherwise, self-reference every page and confirm the canonical URL matches the crawlable URL exactly (same protocol, host, trailing slash, and query format).
- 2
Move rel=next/prev into the head, or drop them
If you use rel="next" and rel="prev", they must live in the document <head>, never the body. That is exactly what pagination_in_body catches. Since Google ignores them for indexing, one clean option is to remove them entirely and rely on canonicals plus normal <a href> links between pages. If you keep them for Bing and accessibility, make sure they are server-rendered in the head.
- 3
Fix the chain so it does not loop
Walk the series and confirm each page points forward and backward correctly: page 2's rel="prev" is page 1 and its rel="next" is page 3. Page 1 has no rel="prev", and the last page has no rel="next". No page should list itself, and page N's rel="next" must never wrap back to page 1. A loop usually traces to a template that computes the wrong page number at the boundaries.
- 4
Keep pagination links as crawlable anchor tags
Regardless of rel tags, Googlebot and AI crawlers find deeper pages by following real <a href="..."> links. Make sure your page-2, next, and previous controls are actual anchors with real URLs in the HTML, not buttons that load content only via JavaScript on click. Infinite scroll and 'Load more' patterns need real paginated URLs behind them (via the History API) so each page state is crawlable on its own.
- 5
Do not noindex paginated pages or block ?page= in robots.txt
A common overcorrection is to noindex page 2 and beyond, or block ?page= in robots.txt. Either move severs the crawl path to everything those pages link to. Leave paginated pages indexable with self-canonicals, and let the individual content pages rank. Only noindex a paginated series if those pages genuinely offer nothing a crawler needs to reach.
- 6
Re-crawl and confirm in Search Console
After deploying, view source (or use URL Inspection in Google Search Console) on page 2 and confirm the canonical is self-referential and any rel links sit in the head. Re-run your audit. In Search Console, watch deep URLs move out of 'Alternate page with proper canonical tag' and 'Duplicate' states into 'Indexed' over the next few crawls.
Example
<!-- In the <head> of https://example.com/blog?page=3 -->
<head>
<!-- Self-referencing canonical: page 3 canonicals to page 3, NOT page 1 -->
<link rel="canonical" href="https://example.com/blog?page=3" />
<!-- Optional rel links (Bing/accessibility; Google ignores them). Head only. -->
<link rel="prev" href="https://example.com/blog?page=2" />
<link rel="next" href="https://example.com/blog?page=4" />
</head>
<!-- Boundaries:
page 1 -> NO rel=prev, rel=next = page 2
last N -> rel=prev = page N-1, NO rel=next
never let page N's rel=next wrap back to page 1 (that is the loop) -->
<!-- In the body: real crawlable anchor links, not JS-only buttons -->
<nav aria-label="Pagination">
<a href="https://example.com/blog?page=2">Previous</a>
<a href="https://example.com/blog?page=4">Next</a>
</nav>Correct markup for page 3 of a series: rel links in the head, a self-referencing canonical, and a chain that does not loop.
Platform-specific steps
Both plugins output self-referencing canonicals (and rel=next/prev in the head) automatically for core archive and category pagination, so the usual fix is to stop overriding them. Check that you have not manually set a canonical to the page-1 URL in a template or via a filter, which is the classic 'canonical points to page 1' bug. In Rank Math, open Titles & Meta and confirm archives are not set to noindex; in Yoast, avoid custom code that rewrites wpseo_canonical on paged views. If a theme or page builder injects pagination markup into the body, that is your pagination_in_body source.
Collection pagination lives at /collections/name?page=2. Some themes canonicalize paginated collection pages back to the collection root, so edit theme.liquid (or the relevant pagination snippet) to build the canonical from the current URL, appending ?page= when the current page number is greater than 1. Confirm your next/previous collection controls render as real <a href> links, which Liquid's default pagination does, rather than JavaScript-only buttons.
Render the canonical and any rel links server-side in the head, not from client-side effects that run after load. In the App Router, return a self-referencing canonical from generateMetadata using the current page's params, so /blog?page=3 emits its own canonical. Keep Link and anchor pagination controls as real hrefs. If you build the rel chain by hand, guard the boundaries: no rel=prev on page 1, no rel=next on the last page, and never wrap next back to page 1.
These platforms manage pagination and canonicals for you and do not expose per-page canonical editing, so you generally cannot create this mismatch by hand or hand-fix it. If an audit still flags it, check that you have not added a global canonical or rel tag through custom header or code injection that applies to paginated views. Otherwise the default behavior (self-referencing canonicals, crawlable links) is already correct and the flag is low priority.
Frequently asked
To themselves. Pointing every page's canonical at page 1 tells Google those pages are duplicates, which removes them from the index along with the links they contain. Use a self-referencing canonical on each page, so ?page=2 canonicals to ?page=2. Only canonicalize to page 1 when you also offer a single 'View All' page you are intentionally consolidating onto.
No. Google confirmed in 2019 that it had not used rel=next/prev as an indexing signal for years. Having the tags is not harmful as long as they are correct and in the head, and Bing plus assistive technology still read them, but they no longer influence Google's indexing. Your canonical setup and crawlable anchor links are what matter for Google.
Because these are <link> elements, which are only valid inside the document <head>. If your template or a page builder injected them into the <body>, browsers and crawlers ignore them and the markup does nothing. Move them into the head as server-rendered tags, or remove them and rely on canonicals and anchor links.
No. Paginated pages are not duplicates, since each has different content. Noindexing them cuts the crawl path to every product or article they link to, which can strand large parts of your catalog. Keep them indexable with self-referencing canonicals. The individual content pages are what should compete in search, and pagination is how crawlers find them.
Back the experience with real paginated URLs. Use the History API so each batch maps to a crawlable URL like ?page=2, and make sure those URLs return the same content when requested directly. If deeper content only loads via a JavaScript click with no unique URL, crawlers and AI bots cannot reach it, and the pagination effectively does not exist for SEO.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.