Canonical Issues on collections/all?page=1

Topic summary

A user encountered three high-priority SEO warnings from Screaming Frog specifically affecting their /collections/all?page=1 and FAQ pagination URLs:

Issues identified:

  • Canonical tags pointing to different URLs
  • Hreflang annotations not using canonical URLs
  • Paginated URLs marked as non-indexable

Other paginated pages work correctly, suggesting the problem isn’t with the general theme.liquid code. The user found no hreflang code in their theme files, though they recently implemented Shopify’s Translate app.

Attempted solution:
A community member suggested modifying the canonical URL code to include ?page=1 parameter on first pages to match hreflang output. However, this created unintended consequences—adding ?page=1 versions across the entire site (home, products, etc.) with circular canonicalization issues that persisted even after reverting the code.

Current status:
A corrected code snippet was provided adding a collection and condition to limit the change to collection pages only. The user plans to contact Shopify support. The helper noted that hreflangs are output via content_for_heading and are largely outside user control without custom solutions.

Summarized with AI on October 24. AI used: claude-sonnet-4-5-20250929.

Screaming Frog is presenting three seemingly related ‘High Priority’ issues about our “…collections/all?page=1” page:

  1. Cannonicals: Cannonicalised - Pages that have a canonical to a different URL. The URL is ‘canonicalised’ to another location. This means the search engines are being instructed to not index the page, and the indexing and linking properties should be consolidated to the URL in the canonical.
  2. Hreflang - URLs not using the canonical URL on the page in its own hreflang annotation. Hreflang should only include canonical versions of URLs.
  3. Pagination: Non-Indexable - The paginated URL is non-indexable. Generally they should all be indexable, unless there is a ‘view-all’ page set, or there are extra parameters on pagination URLs, and they require canonicalising to a single URL. One of the most common mistakes is canonicalising page 2+ paginated pages to the first page in a series. Google recommend against this implementation because the component pages don’t actually contain duplicate content. Another common mistake is using ‘noindex’, which can mean Google drops paginated URLs from the index completely and stops following outlinks from those pages, which can be a problem for the products on those pages.

The first issue also exists on a FAQ page (similarly paginated URL). The second and third issues only exist on the collection page.

We’re on the Dawn theme, and I see in the theme.liquid the seemingly appropriate code:

<link rel="canonical" href="{{ canonical_url }}">

I’m only experienced enough with coding in general to be dangerous, have never gone super-far into html, and liquid is all-new to me. SEO is pretty new to me too, and I this is from our first analysis in Screaming Frog.

But, from the research I’ve been doing, it seems to me that this line of code should automatically handle all paginated URLs like this. And that it is doing so successfully for all of the other paginated URLs; just not this one (two, including the FAQ). As such, I’m thinking the solution isn’t tinkering with the theme.liquid code, but then what?

I also don’t see any “hreflang” in the theme.liquid code. We did recently implement the Shopify ‘Translate’ app, but I don’t see where that is handled in the code.

I’m usually able to sort this stuff out with other examples, but the closest thing I’ve found is Canonical_url and hreflang tags holding back search result , which isn’t exactly the same and doesn’t really present a solution.

Maybe Screaming Frog is just seeing an issue that doesn’t really exist? Makes me nervous that it’s listed as a ‘High Priority Warning’ though, so any help or advice would be greatly appreciated.

Thank you!

Sharing the URL should help here, because other things may be at play.

hreflangs are output as part of the content_for_heading which is referenced in your layouts/theme.liquid

Generally, you have no control over them other than you can reach out to support and ask them to disable hreflangs completely. Then you can try an app or custom code to handle them instead.

The only discrepancy here is on the first page and this happens because collections/all and collections/all?page=1 is the same page and this is the thing canonicals should resolve.
Yes, potentially, one should use canonicals in hreflangs, but I guess Google should be smart enough to work it out.

If you really set to fix it, you can modify your canonical code to make it match the hreflangs. need to account for URL parameters though.

Or redirect visitors from and collections/all?page=1 page to collections/all

#3 – even if this URL with page number (and only for the first page) is not indexed, the URL without page number will be indexed since it’s the canonical. Should not worry about this, IMO.

This is not that important IMO, because collections are not the crucial source in your product page discovery – you have all your product pages in sitemap.

I guess at this point I’d be more concerned about not letting duplicate URL in Google index, like collection-aware product links, URLs from the recommended products, search results, etc…

This code will make canonical have ?page parameter on page 1 to match hreflangs.
Change this code

to

< link rel="canonical" href="{{ canonical_url -}}{%- if current_page == 1 -%}?page=1 {%- endif -%}">

Thanks for the response Tim.

Unfortunately, trying that bit of code update created new page versions for all sorts of pages (like home page, products, etc), appended with “?page=1”, which are canonicalized to the original version. And the original versions are now canonicalized to the new “?page=1” versions.

As such, instead of just the “collections/all?page=1” showing the “Cannonicals: Cannonicalised” issue, much of the site now shows that issue in Screaming Frog, which I think (?) makes most of the site non-indexable. Most disturbingly, changing the code back to the original did not remove these new pages or reset the canonicals. Nor did using our Rewind app to restore things.

I think I’m going to reach out to Shopify help now.

Yes, re-checked this code just yesterday and seem to be not what you’d expect, so it needs fixing.
Say, like this:

< link rel="canonical" href="{{ canonical_url -}}
    {%- if collection and current_page == 1 -%}?page=1 {%- endif -%}">

See the added collection and
Probably extra condition for you FAQ pages – do not know what are they?

Sorry for not enough testing on my side.