Not every Ecommerce platform is perfect in its internal linking and URL structure. In a client project last year, it turned out that we weren’t going to get perfect, so we had to get creative.

Users could not actually access the raw product pages because  internal links used extensive dynamic parameters. These URL parameters meant products were linked to from a number of parameterised versions which changed day to day. A list of the URLs users might end up on while looking at the exact same product would look like this:

As these pages are exact duplicates of the /product.html page, the canonical tag was used to direct Google to the “original” non-parameter URL. The platform prevented us from removing these dynamic parameters from the internal linking. Other considerations prevented us from using excessive redirection.

Now, this is a popular Ecommerce site with stores in the real world, so it attracts links naturally. Unfortunately these links aren’t heading to the ranking canonical URLs, they’re heading to messy parameter URLs.

“But the canonical will handle those.”

No-one is too confident on exactly how much link equity a canonical actually preserves, but’s it’s typically quoted as around the same as a 301 redirect. So, as long as Google respects the canonical, the page will only get around 90% of the link equity. Not good enough. For any parameter URL, we would want all incoming links and link equity to go directly to wherever the canonical refers, rather than indirectly through the canonical tag.

Fixing This

How do people link to pages? They copy the URL from the address bar, and paste it. So how do we get people to link to pages other than the page they are on? We manipulate what appears in their address bar:

Look at your address bar and PRESS THIS.

NOW PRESS THIS. (button stolen remorselessly from Rob Ousbey‘s post on Moz.)

Now go to this URL: http://seogadget.com/manipulating-browser-history/?nowyouseeme

That wasn’t a redirect, the parameter was spirited away. The following code will achieve this change:

We rolled this change out for our client. Even though users are ending up on a non-clean URL, the URL that they will copy+paste to link to or share on social media is stripped clean. What does this change mean for our client? In effect, the existing link equity for the pages was, and still is, being held together with the duct tape of a canonical tag. But the actually natural incoming links since the code was implemented are now going directly to the right places. Since product pages tend not to need too many links to be competitive, the eCommerce team is very happy with the results.

Will this break my Analytics?

No.

Will this work with IE?

Not really. It will work with IE10, and it can be conditionally commented out for other versions if you find it upsetting other bits of JavaScript on failure.

Will this negatively affect XYZ?

Yes.

If you want to read about manipulating browser history for other purposes, this guide is excellent. Just like the canonical tag, I recommend you don’t use this anywhere it doesn’t make sense. Is this dastardly cloaking (no)? Are there incredibly evil uses for this (there are)? Let me know your thoughts below or via twitter.

Image Source

The post Manipulating Browser History (for links) appeared first on SEOgadget.