Canonical URL Incorrect

[thethreedegrees]

Hi,
have an issue where if I enable canonical url all my CMS pages are like the image below,double entry on the domain name.
All the other URL's are fine its only the CMS ones.
Anyone seen this behaviour before?

[mayday]

Yes, I have the exact same problem.

Another problem, that might be related:

When I Generate a Google Sitemap (module gsitemap) I have my domain name repeated here several times too:

(but not by every entry)

http://www.outdoorstore.ch/lang-de//www.outdoorstore.ch/chalkbags-chalk/15-chalk-bag-arabesque.html

but for the Sitemap.XML, at least I can quickly correct it with some simple find and replace and I make a working file.

But with the problem here for Canonical ... I had to just shut down the module.

Anyone know how to fix this?

[gbaby]

Same problem. Could someone please help?!

[netzhautmassage.de]

From what i've seen the module is not working as expected in any case.

Example:

Let's say you have a product with this url:

www.yourshop.com/1-category/2-the-product.html

The module will take whatever it gets from $_SERVER['REQUEST_URI'] and stuff it in the canonical tag.

Now if i'm a bad guy trying to get your shop off business, i'd link that product with a different url from one of my sites. Like www.yourshop.com/1-category/2-the-product-sucks-dont-buy-it.html.

Google now finds the same content under two urls, considering it double content and making your day with a nice penalty.


I'm not sure if this can be fixed easily, it'd require to find out the actual url from the slugs stored in the database, thus distinguishing between categories, products, cms pages and so on. if i ever find out, i'll post a module.

[Tenberry]

I was advised not to configure this module because of the aforementioned problems. Hopefully a fix will be found as this was/is an attractive feature.

[gbaby]

There's a fix for the double url issue in bug tracker

[rocky]

I just checked SVN and the only change I could see to the canonical module is the following on line 66 of modules/canonicalurl/canonicalurl.php:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   if (isset($rewrited_url))
       $smarty->assign('canonical_url', $protocol.$canonicalUrl.$rewrited_url);
   else
       $smarty->assign('canonical_url', $protocol.$canonicalUrl.$_SERVER['REQUEST_URI']);

It was changed to:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   $smarty->assign('canonical_url', $protocol.$canonicalUrl.$_SERVER['REQUEST_URI']);

Can anyone confirm whether this fixes the issue?

[gbaby]

yes, it worked for me.

[thethreedegrees]

Sweet!:-) Thanks a mil Rocky..

[tomerg3]

From what i've seen the module is not working as expected in any case.

Example:

Let's say you have a product with this url:

www.yourshop.com/1-category/2-the-product.html

The module will take whatever it gets from $_SERVER['REQUEST_URI'] and stuff it in the canonical tag.

Now if i'm a bad guy trying to get your shop off business, i'd link that product with a different url from one of my sites. Like www.yourshop.com/1-category/2-the-product-sucks-dont-buy-it.html.

Google now finds the same content under two urls, considering it double content and making your day with a nice penalty.


I'm not sure if this can be fixed easily, it'd require to find out the actual url from the slugs stored in the database, thus distinguishing between categories, products, cms pages and so on. if i ever find out, i'll post a module.

I have just created a module that redirects all old or incorrect URLs to the default Friendly URL version of them (using a search engine friendly 301 redirect) for all products, categories, manufaturers, suppliers and cms pages.

For more info check out http://www.prestashop.com/forums/viewthread/39736/

[nutbuster]

I just checked SVN and the only change I could see to the canonical module is the following on line 66 of modules/canonicalurl/canonicalurl.php:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   if (isset($rewrited_url))
       $smarty->assign('canonical_url', $protocol.$canonicalUrl.$rewrited_url);
   else
       $smarty->assign('canonical_url', $protocol.$canonicalUrl.$_SERVER['REQUEST_URI']);

It was changed to:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   $smarty->assign('canonical_url', $protocol.$canonicalUrl.$_SERVER['REQUEST_URI']);

Can anyone confirm whether this fixes the issue?

After replacing code, I would need to unstall Canonical url module then reinstall the module?

[rocky]

I don't think you need to reinstall, but it can't hurt to do it anyway.

[tomerg3]

What is the CANONICAL_URL module suppose to do?

Ok, I think I figured it out...

I still am not convinced that a <link rel="canonical"> tag is doing much help.

It certainly does not help eliminate duplicate data, or as a previous poster stated, it does not help the fact that you can still link to a product by using it's id and any other name you want after it. (I.E www.shop.com/7-anything-go-here-and-search-engines-see-it-as-a-duplicate-url.html

I have just found the following on a good SEO site (and saw similar info on others)


The Canonical URL tag attribute is similar in many ways to a 301 redirect from an SEO perspective. In essence, you're telling the engines that multiple pages should be considered as one (which a 301 does), without actually redirecting visitors to the new URL (often saving your dev staff considerable heartache). There are some differences, though:

* Whereas a 301 redirect re-points all traffic (bots and human visitors), the Canonical URL tag is just for engines, meaning you can still separately track visitors to the unique URL versions.

* A 301 is a much stronger signal that multiple pages have a single, canonical source. While the engines are certainly planning to support this new tag and trust the intent of site owners, there will be limitations. Content analysis and other algorithmic metrics will be applied to ensure that a site owner hasn't mistakenly or manipulatively applied the tag, and we certainly expect to see mistaken use of the tag, resulting in the engines maintaining those separate URLs in their indices (meaning site owners would experience the same problems noted below).

* 301s carry cross-domain functionality, meaning you can redirect a page at domain1.com to domain2.com and carry over those search engine metrics. This is NOT THE CASE with the Canonical URL tag, which operates exclusively on a single root domain (it will carry over across subfolders and subdomains).

[kratzbaum]

The canonicalurl module would be very useful, if it generated the cannonical-tag using data from the database.

Unfortunately this does not seem to work correctly.

Has anyone fixed the problem yet? I would be very interested in a solution!

[Subzerorepair]

I'm just exploring this site because it is my first time today, and I'm glad to have found your discussions. I don't have to ask anymore, about that kind of problem. thanks to all of you. :-)

[kratzbaum]

I think I have solved the issue with the canonicalurl module.

The problem with the current script is, that the $rewrited_url variable is set after the include command for the header.php file. I have moved the include command in the following files:

- product.php
- category.php

Additionally I have made a small modification to the module itself. The $rewrited_url variable already includes the protocol and the domain. Therfeore there is no need to add them to the canonical_url string in the module.

In index.php I uncommented the line where the $rewrited_url varibale is set. Otherwise the the canonical tag for the index page will be empty.

So far I haven't found any unwanted side effects.

If you use the modification please be carful and make backups. Also i would be glad if you could post here if you encounter any problems.

I'm really glad that this module is now working. I have a serious issue with duplicate content being indexed by google after changing the url structure of my product pages.

Cheers

canonicalurl.php

category.php

product.php

[kratzbaum]

After some more testing I have found one issue with the modification that might be related to the the change.

The ordering of products is different now on category pages and manufacturer pages.

I have set the order manually so most ordered products are at the top of the page of each category. The order now seems to be reversed.

[x3n0m0rph]

Grat work dude! It works!
Products order is still the same too.

[Rodolfo]

yes, it worked for me.

Also for me.

[delabarca]

is this problem fixed on the new version 1.3.1?

[rocky]

I would say it isn't, since the thread was created after v1.3.1 was released. I reported a bug in the canonical module where the canonical URL was http:// instead of https:// on secure pages. I can't see any other bugs fixed in the canonical module. You can report this issue on the bug tracker if you want to be sure it is fixed in v1.3.2.

[delabarca]

So if I don`t have actived the secure page option, don`t need to make this fix?

Thanks for your answer rocky!

[rocky]

That's right, though it is still worth fixing in case you decide to turn on SSL in the future.

[netzhautmassage.de]

I just checked SVN and the only change I could see to the canonical module is the following on line 66 of modules/canonicalurl/canonicalurl.php:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   if (isset($rewrited_url))
       $smarty->assign('canonical_url', $protocol.$canonicalUrl.$rewrited_url);
   else
       $smarty->assign('canonical_url', $protocol.$canonicalUrl.$_SERVER['REQUEST_URI']);

It was changed to:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   $smarty->assign('canonical_url', $protocol.$canonicalUrl.$_SERVER['REQUEST_URI']);

Can anyone confirm whether this fixes the issue?

without having tried this out, on first sight this change seems to make things worse. now the request uri is *always* used instead of the rewritten url while it should be the exact opposite. or am i mistaken here?

[rocky]

I'm not sure. This is an old post. That line has since been updated to:

if (strlen(Configuration::get('CANONICAL_URL')) > 0)
   $smarty->assign('canonical_url', $protocol_link.$canonicalUrl.Tools::htmlentitiesUTF8(rawurldecode($_SERVER['REQUEST_URI'])));

[mel-]

is this fixed in 1.3.2 or is there a fix for 1.3.1? it is causing a mixed content warning in google chrome and I'd like to fix that.

[JTT]

I think that in 1.3.2 it still works badly... It appends cannonical to all sites and thats not good.
I made a small modification to canonicalurl.php in this way :

if (isset($rewrited_url) and isset($_GET['orderby']))
         $smarty->assign('canonical_url', $rewrited_url);

so now I get canonical url with url on the base site when sorting products. Now I think it is ok... Or still not ?!?

[JTT]

there is one mistake in category.php file... You should not remove (or move)

include(dirname(__FILE__).'/product-sort.php');

from the top of category.php, line 15, because then the product sorting will not work.
Everythnig else you should do.

[stuffy]

Are JTT's comments above correct? can anyone confirm this?

[divers972]

Hello,

 

I have the same probleme (double name domain) when I use the ADDTHIS Module

When I want to share on facebook for example, it doest work : i have this url

http://www.myshop.com/category/www.myshop.com/category/product.html

 

How to solve it please?

[bogdan89]

Hello,

 

I have the same probleme (double name domain) when I use the ADDTHIS Module

When I want to share on facebook for example, it doest work : i have this url

http://www.myshop.co...ry/product.html

 

How to solve it please?

 

You can use this module for canonical url tag: http://addons.presta...al-url-pro.html

This module can remove from the url parameters like orderway=, orderby=,n=, ....

You can specific any parameters you want to be removed from the url.

It also works on every page of the site including categories, best-sales and new-products.

Module is compatible with PS 1.3 - 1.4