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

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.

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...

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...

Quote:

---

Originally Posted by 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...

---

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.

Quote:

---

Originally Posted by lat9

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.

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

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.

Quote:

---

Originally Posted by 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.

---

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.

Something like this?

Code:

---

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

---

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by DrByte

Something like this?

Code:

---

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

---

---

Unless there is some known expectation of the page parameter *NOT* being a number, I was thinking a little bit "more" like:

Code:

---

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

---

This would cause the page parameter to be removed if the value of the page parameter was non-numeric or if it is numeric and the value is less than 2 (e.g. 1, 0, a negative number, 1.5)

FYI, my to become a PR on the issue as far as generating the pages (in reference to ZC 1.5.7) is:
https://github.com/zencart/zencart/c...on-split-pages

Something like the above is expected to be added into that branch which is to become a PR.

1. Yes your additional code changes to split_page_results would prevent page=1 from even being generated in the first place (at least where split_page_results is invoked, which is pretty much everywhere in core code).

2. And I'd be fine with your proposed change to my code snippet above for init_canonical.

3. Might also be worth adding a line to init_sanitize, to make it clear that page= is always expected to be numeric, so if someone writes custom code that wants non-numeric at least they'd be able to see where it gets cast to numeric:

Code:

---

// if present, 'page' should always be a number because it is used for pagination and canonical URL generation
if (isset($_GET['page'])) $_GET['page'] = (int)$_GET['page'];


/**
 * process all $_GET terms
 */

---

Hi Drbyte and mc12345678
Thank you for your attention to this issue. I have just made a donation to show my appreciation. The code provided (in the forum and on github) seems to work very well.

The issue with the canonical link generation is now resolved.

I have noticed that on pages 2 onwards a sort order (&sort=20a) is automatically applied to the browser bar link. This sort order is also applied when returning to page 1 from page 2. I believe this may be an issue that has been overlooked.

To avoid making this thread confusing I have made a new thread to discuss the sort=20a parameter.

It would be much appreciated if you could have a look at the thread and let me know if a solution is available.

https://www.zen-cart.com/showthread....arameter-(SEO)
--
Many thanks
Richard