[Done v157a] Canonical link now keeps the 'page=' parameter (zc156, too)

[lat9]

As identified in this USU support-thread post, the page= parameter is no longer considered an exclusion.

Using a fresh zc157a (beta) install with the demo products, specifically the Test Examples category, click on the categories sidebox to view the first page.

zc155f: <link rel="canonical" href="http://localhost/zc155fusu/index.php?main_page=index&amp;cPath=23">
zc156c: <link rel="canonical" href="http://localhost/zc156posm/index.php?main_page=index&amp;cPath=23" />
zc157a: <link rel="canonical" href="http://localhost/zc157a/index.php?main_page=index&amp;cPath=23">

Now, click to navigate to page 2:

zc155f: <link rel="canonical" href="http://localhost/zc155fusu/index.php?main_page=index&amp;cPath=23">
zc156c: <link rel="canonical" href="http://localhost/zc156posm/index.php?main_page=index&amp;cPath=23&amp;page=2" />
zc157a: <link rel="canonical" href="http://localhost/zc157a/index.php?main_page=index&amp;cPath=23&amp;page=2">

Not sure when in the zc156 releases this unwanted change was introduced.

[mc12345678]

While I would agree thus far of not knowing how/what introduced it, I would disagree that "for some" that it is/was unwanted. Not saying I necessarily am in favor nor at the moment opposed to its presence, but I do recognize the trouble caused by the duplication of reference to the "first" page...

[mc12345678]

Those results are interesting because includes/init_includes/init_canonical.php contains 'page' as a keepable parameter in ZC 1.5.5f.

Here's the commit that "added it back": https://github.com/zencart/zencart/c...5d19e062776a9f

Of course there is also a notifier in that area that can be used to address removal of such things as page=1...

[lat9]

Those results are interesting because includes/init_includes/init_canonical.php contains 'page' as a keepable parameter in ZC 1.5.5f.

Here's the commit that "added it back": https://github.com/zencart/zencart/c...5d19e062776a9f

Of course there is also a notifier in that area that can be used to address removal of such things as page=1...

Nice detective work, @mc12345678! Now, if we could get @DrByte to chime in on what additional results are being lost by search engines when the 'page=' parameter is excluded.

[DrByte]

Now, if we could get @DrByte to chime in on what additional results are being lost by search engines when the 'page=' parameter is excluded.

I vaguely remember a series of forum complaints that precipitated that change.

[richard7315]

Hi,
Thank you lat9 for starting this bug report. Whilst looking into improving the SEO for my website I noticed the following issue.

On a fresh 1.5.7 install (as well as some of the previous versions) there is some duplicate content being created. This issue is present on categories containing more than 10 products.

The bug can be noticed when navigating from page 2 back to page 1. As shown in the example below, the browser URL and canonical have parameters added.


Page 1 browser URL (after navigating from page 2): example-website-com/index.php?main_page=index&cPath=23&sort=20a&page=1

Page 1 canonical (after navigating from page 2): example-website-com/index.php?main_page=index&cPath=23&page=1


When navigating to a category the first page always has the cPath parameter (as is expected). However, when navigating from page 2 back to page 1 the sort and page parameters are being applied. These parameters should be consistently applied (or excluded) on all links to page 1 – if they are not search engines may see these as duplicate pages as they have the same content (but different canonicals).

As far as I understand the page= parameter is essential on page 2, page 3 etc... so each page can be indexed by search engines.

I would be very grateful if someone could help look into this issue. If it requires a significant amount of work to resolve I would of course be willing to donate to help cover costs.
--
Many thanks
Richard

[DrByte]

So, lat9 says "having the page= parameter" is a bug, er "unwanted change", and seems to want page= to be removed.

But richard7315 says "page= is essential", and also wants to always include "page=1" if no page-number is known.

[mc12345678]

So, lat9 says "having the page= parameter" is a bug, er "unwanted change", and seems to want page= to be removed.

But richard7315 says "page= is essential", and also wants to always include "page=1" if no page-number is known.

To throw another wrinkle, I say that page=1 should not be used or should not exist on the first page or by going to the first page, but other page= values should be used with the idea that the page parameter *could* be important.

I have a modification prepared to prevent page=1 from showing on page changes, but the modification doesn't yet address removal of page=1 from the canonical link if the site is presented with that in the visited Web page.

My reasoning is that the absence of a page parameter should resolve to the first page, that a page=1 parameter should not be presented to the resulting html, and that in cases where a paginated grouping is sequenced that a page=x where x is greater than or equal to 2 could be important to linking to the content. Unfortunately where items are randomly presented across multiple pages the page number doesn't reflect the same importance and actually adds no external value if the order changes on each page load or with each session.

Having page=1 on a page that comprises only one page seems wasteful and having it at any other time seems pointless.

[DrByte]

Something like this?

  if (isset($_GET['page']) && is_numeric($_GET['page']) && $_GET['page'] < 2) $excludeParams[] = 'page';

[lat9]

So, lat9 says "having the page= parameter" is a bug, er "unwanted change", and seems to want page= to be removed.

But richard7315 says "page= is essential", and also wants to always include "page=1" if no page-number is known.

That was my (mis)interpretation of richard7315's posting in the USU support thread.

One way or another, the first page of a listing should either always include the "page=1" parameter or never include that parameter to prevent duplicate-content errors.