We are using Webflow’s auto-generated canonical tag by configuring it in the site settings. This goes well everywhere, except for pages containing our blog articles. There the canonical tags contain weird page=<mumber> query parameters. I have searched this forum and found these are usually used for pagination purposes, but these pages have no paginated elements, so I think the query params should be removed from the canonical tag. Now Google Search Console reports an error containing:
Page is not indexed: Duplicate, Google chose different canonical than user
Yes, I noticed this change in Webflow recently and support confirmed it. Apparently it’s a feature change that hasn’t been announced yet.
I’m not sure of their thinking on this, except that a lot of users were complaining that pages with paginated collection lists should have distinct canonicals. So many I wrote an article about it.
It’s hilarious that Google is identifying the new approach as incorrect. My best guess is google is measuring the content differences between the pages and in most cases it’s too small to treat it as a separate page.
Other than the ugly warnings, I don’t think you have anything to worry about, it’s saying it won’t index the paginated url because it identifies it as a duplicate.
They likely do- 3 different paginated collection lists from the looks of it. You may have the pagination elements hidden if you’re using something like Finsweet CMS Load.
Hi Michael. I noticed that Google is actually indexing a few of the paginated pages with query parameters that are created from collection list pagination. This isn’t ideal, because we only want the original, non-paginated version to show in Google. Is there a way to canonical all of the paginated versions to the original in Webflow?
Alternatively, I’m using Finsweet “Load More” which removes pagination in a practical way for users but the problem is that the query parameter href still shows up on the page and is showing up in screaming frog crawls (e.g. ?4f50a7c8_page=2)
If I could just remove that paginated href from the pages with paginated collection lists, Google wouldn’t be able to crawl the query parameter URLs and the problem would be solved.
Unfortunately the way Webflow has set up collection list pagination is a mess for SEO.
Webflow changed their approach early this year, so that the pagination querystrings are included in the canonical URLs. I’m not a fan of that either.
In a few cases, I remove that from the canonical using a reverse proxy. Client side scripts could possibly work as well, but tools like screaming frog likely wouldn’t see script-based changes.
Hmm I’m not savvy enough to set up a reverse proxy
What do you think about using rel=next and rel=prev on the collection list pagination links?
For context, I’m essentially working on an ecommerce site with product category pages that have product listings living in a collection list. There are four different collection lists on each page, all with pagination.
Now, if you choose to include rel="next" and rel="prev" markup on the component pages within a series, you’re giving Google a strong hint that you’d like us to:
Consolidate indexing properties, such as links, from the component pages/URLs to the series as a whole (that is, links should not remain dispersed between page-1.html, page-2.html, etc., but be grouped with the sequence).
Send users to the most relevant page/URL—typically the first page of the series.
Sounds like this could do the trick, but I’d love to know your take.
I like it, however the question is “what is next and prev?”.
If you have a single paginated collection list on your page, that’s logically understandable- but you can have up to 20 of them, so it’s important to consider what you’re trying to build and nav through.
In the case were you have a single paginated collection list, or only one that’s relevant from an SEO perspective, you could generate those METAs with JS and Google would likely pick them up.
The only caveat is that since you probably don’t know how many pages there are ( without more advanced JS work, parsing page numbers, etc ), then your last next will probably end up back on the first page (?). E.g. 4 pages, you generate a next to go to 5, but 5 doesn’t exist, so likely Webflow will default to page 1 (?). Worth checking perhaps.
