Paginated pages name page 1 as the main one

In the reportPaginated URLs declare page 1 as their canonical

pagination_canonical_to_first_page · Issue

Short answer

This appears when a page of a paginated list, such as ?page=2 or /page/2/, names page 1 as its canonical. Google advises against this and asks for each page to have its own canonical. Point each page's canonical at itself.

Severity: Medium. Fix it when you next edit the list template.

Why it matters

Google's guide to pagination says not to use the first page of a paginated sequence as the canonical page and to give each page its own canonical URL instead, and that Google treats the URLs in a paginated sequence as separate pages.

What to do

  1. Look at the finding: it shows the page, its page number and the canonical it declares.
  2. Make the canonical of each page in the list point to that page itself, so that /cakes/?page=2 names /cakes/?page=2.
  3. Fix it in the list template or your SEO plugin's pagination setting, since it usually applies to every list.

What we read

We read each crawled page’s final address and its retained <link rel="canonical"> declarations in <head>, resolved against the first <base href>. HTTP-header canonicals and declarations carrying hreflang, lang, media or type are ignored.

A single ASCII page query value, such as ?page=3, or a path ending in /page/3 or /page/3/ identifies pagination when its number is greater than 1 and has at most 18 digits. The rule reports one canonical targeting page 1 of the same series: the scheme, host, port and other query parameters must match. For ?page=N, the target keeps the path with page omitted or set to 1. For /page/N[/], it uses the base path or /page/1. Leading zeros are accepted.

Other URL patterns are not applicable. Missing, unusable or several distinct canonical targets, an unusable base, lossy queries, more than 32 distinct targets or unavailable head qualification leave a paginated page unchecked. Head placement must qualify; inert style-only <noscript> can qualify. A status code, noindex or render state alone does not decide the result: usable retained head evidence is still required.

Example & evidence

Illustrative example — one page of a list, not a live audit.

https://bakery.example/cakes/?page=3 has:

<link rel="canonical" href="https://bakery.example/cakes/">

Page 3 names page 1 of the same list as its canonical, so it is reported.

<link rel="canonical" href="https://bakery.example/cakes/?page=3">

A possible correction: page 3 names itself.

Confirm & check again

Check for yourself: open page 2 or 3 of a list, view its source, and compare the canonical's href with the page's own address.

Check again: Full audit — run a new site audit through the address where the problem was found. The same final page must be read again with one usable canonical that does not target page 1 of that series. Checking it only through a different redirecting address does not confirm a fix. Missing, ambiguous or unread head evidence, or a redirect to a different final page, keeps the finding open.

Limits & sources

This is a diagnostic of two URL patterns and retained head declarations. It makes no additional request to page 1 and does not establish which canonical Google selects. A target with different filters or another origin is not reported by this rule. An error status alone does not show that its head was captured and checked.

Confidence: High because the address and the canonical are read directly.

Sources

Editorial review: 4 November 2026