Canonical

So a page such as this
https://domain.com/154/index.php?main_page=product_info&cPath=3_10&products_id=12

has a rel="canonical" of this

Which forces a redirect for tools such as OpenGraph, Google Shopping etc who read and respect the canonical attribute.

I see where it can be changed in init_canonical.php

$includeCPath = TRUE;

However, I would rather think TRUE should be default and not the other way around.

~Melanie

What about the scenario where the product is linked to multiple categories?

Either way, the "canonical" URL for the product is the product URL, regardless of category, isn't it?

Agreed, but this is not linked.... so every product out of the box Facebook is forced to follow a redirect to the canonical... and they're testy about it.

Sigh. Nobody's forcing Facebook to do anything. That's their choice, and frankly IMO a misinterpretation of the purpose of canonical.

Why exactly does Facebook believe they need to do a redirect in the first place? Do they document the why behind their madness?

I couldn't say for sure, but I suspect they are trying to weed of fake links and BS

To find the object, these are the redirects we had to follow
original https://domain.com/154/index.php?main_page=product_info&products_id=12
og:url https://domain.com/154/index.php?main_page=product_info&cPath=3_10&products_id=12
The following will be treated as a redirect by the crawler:

A HTTP redirect
A <link rel="canonical" href=".." /> tag
A <meta property="og:url" content=".." /> tag

The final URL, which we tried to extract metadata from is highlighted in bold.

Out of curiosity, does that page contain the "og:url" tag? If it does, is there any reason the Open Graph URL is not the same as the Canonical URL? Would making them the same reduce things down to "one" redirect and make FaceBook happier?

The URL in the address bar does not match the canonical is the issue.

mprough:

The URL in the address bar does not match the canonical is the issue.

Apart from this weird situation with the Facebook crawler telling you they "had to redirect" to og:url (and they didn't complain about canonical), I've seen no evidence anywhere else which suggests that the canonical URL should ever have to "match" the browser URL. In fact, the whole issue of creating the canonical reference was to specifically allow for the browser URL to be pointing to 1 page and the canonical pointing to the official master page so that 2 pages showing duplicate content could be properly mapped to just 1 page in the crawler's database.

So, I'm still not understanding how this is a bug at all.

The point is that the cPath displays in the address bar should be in the canonical the same, when possible because not everyone obeys it. So theoretically, Google does, no problem, but Bing most times not, so they would index the cPath version.

People bookmarking and linking to your website also would use the address bar link and link juice doesn't pass to the canonical correctly... It decays. Unless you have the parameters excluded in webmaster's tools.

""Jon Mueller from Google stated that the rel=canonical tag doesn't merge the link profile.""

http://moz.com/community/q/quick-rel-canonical-link-juice-question

I came across this thread while using the facebook debug tool and trying to find the cause of the wrong product images being pulled. I have been adding additional og tags that FB debug was complaining were missing. For the og:url I added <?php echo $canonicalLink; ?>.

<meta property="og:url" content="<?php echo $canonicalLink; ?>" />

Facebook accepts that ok. Is there any reason I should not do this?

For the same reasons mentioned above I have encountered the same message

The following will be treated as a redirect by the crawler:

A HTTP redirect
A <link rel="canonical" href=".." /> tag
A <meta property="og:url" content=".." /> tag

The final URL, which we tried to extract metadata from is highlighted in bold.

I did notice though that on another site using the ceon uri mapper mod the http redirect is not an issue in FB debug because canonical writes the url as it appears in the address bar. Just thought I'd mention it. Still haven't gotten tot he bottom of wrong images being pulled.