Canonical pagination: page two needs its own identity

Nine products occupy three pages

This authored fixture is a small mug catalogue. The category has nine products, identified M01–M09, split evenly across three public URLs. Each item has its own product URL. The same fixture also offers a view-all document containing all nine product links. These paths explain an implementation; they are not observations from a shop.

The first repair question is whether the proposed target preserves the source’s items. Page two contains M04, M05 and M06; page one contains none of them. Shared navigation, a repeated category introduction and matching titles do not turn those sets into duplicate content.

Try the downloadable pagination fixture: unzip it, run node server.mjs inside its folder, and open http://127.0.0.1:4363/mugs. It uses Node.js 22 or later, needs no packages, and serves real page and product links without JavaScript. Stop the local server with Ctrl+C.

Page two works on a direct visit

Open /mugs?page=2 directly in a fresh tab. It should return the second set without a preceding click, remembered session or visit to page one. Its initial response can supply the product links and navigation; JavaScript can enhance that experience afterward.

The labelled navigation and visible current-page state orient readers, while anchors with href give both keyboard users and crawlers destinations they can follow through the catalogue without relying on a click handler to invent the next address. The HTML Standard defines that hyperlink.

<head>
  <title>Mugs — page 2 | Example</title>
  <link rel="canonical"
        href="https://example.com/mugs?page=2">
</head>
<body>
  <h1>Mugs — page 2</h1>
  <ul>
    <li><a href="/products/M04">M04 · Cedar mug</a></li>
    <li><a href="/products/M05">M05 · Elm mug</a></li>
    <li><a href="/products/M06">M06 · Fir mug</a></li>
  </ul>
  <nav aria-label="Mug catalogue pages">
    <a href="/mugs">Previous · page 1</a>
    <a href="/mugs?page=2" aria-current="page">2</a>
    <a href="/mugs?page=3">Next · page 3</a>
  </nav>
</body>

A view-all page must contain the whole collection

For a continuing category sequence, keep the self-canonicals above. A person browsing page two can bookmark and share that set. You may also offer a view-all option for convenience; its existence does not require rewriting every component’s canonical.

RFC 6596 permits a canonical target containing the source’s complete content, including a view-all version of a multipart document. Google’s current category-pagination advice still favors each chunk’s own canonical. I would keep that default for a Google-facing catalogue unless I deliberately chose a complete-document publishing strategy.

If the publishing strategy is one complete document, the full version must actually be complete and usable: all nine items, all meaningful accompanying information and working links, without waiting for three button clicks. Measure its loading and navigation experience before preferring it. A view-all label attached to the same first three cards fails that test.

Nine reachable products are the discovery test

Trace the links from /mugs to page two, from page two to page three, and from each chunk to its products. In this fixture, traversing those ordinary links should expose nine distinct product URLs. Finding only M01–M03 identifies a discovery defect even if every visible canonical is perfectly formatted.

For a load-more or infinite-scroll interface, retain persistent chunk URLs and sequential links underneath the enhancement. The current URL should identify the chunk a visitor can reload or share. Google’s lazy-loading guidance describes that arrangement; it also explains why loading must work without interaction from Search.

Compare links in the initial response with those in the rendered page. A sitemap can help discovery, but it should not conceal a broken browsing path. The internal-link audit explains how to examine the path and its destinations.

• Direct load: each chunk shows its assigned three items without session state.
• Keyboard: the next-page and product links receive focus and open the promised destinations.
• Reachability: following the category links exposes M01–M09, with no missing or accidental repeated chunk.
• Response identity: the final URL, HTML canonical and rendered canonical agree on the chosen page.
• Target health: every preferred document returns useful public content and permits indexing when that is the intended outcome.

Duplicate titles don’t make duplicate item sets

Keep page numbers in real paths or query parameters. A fragment such as #page=2 changes the position or state within one document; it is unsuitable as the sole address of a separately discoverable chunk. Likewise, a canonical link is metadata: it does not replace the anchors that lead through the collection.

Google no longer uses rel=next and rel=prev head tags to identify pagination. Those HTML relations can still describe a sequence for other consumers; they are not the Google indexing repair. Focus the implementation on stable URLs, visible items and usable links.

Google’s pagination documentation allows titles and descriptions to repeat within a sequence. A clear page number can help a reader orient themselves; the item sets determine whether the pages are duplicates. Canonicalizing unrelated sets to satisfy a duplicate-title warning can hide products.

Treat filter and sort policy separately. Changing the sort can change which products appear on page two, so stripping every parameter can point at a different item set. Classify the actual variants before choosing consolidation, exclusion or independent indexing; use the canonical/noindex decision when the goal is exclusion.

The response family comes before Google’s selection

Capture page one, a middle chunk, the last chunk and the view-all document if you offer one. Compare membership, response status, canonical declarations, indexability and the next links. The hub’s capture checklist keeps those observations together.

After deployment, compare declared and Google-selected canonicals in indexed URL Inspection, keeping the crawl date beside the result. The live test checks present delivery; Google’s later duplicate selection needs its own observation. For duplicate without user-selected canonical, compare the content across the family: the pages may differ, or a routing bug may have served the same chunk everywhere. URL Inspection documentation

The catalogue works when each intended page keeps its identity and every maintained item has a working discovery path. I would protect that path before chasing a lower exclusion count.