Ivaldi has become a part of ReMark! Read more about it here.

SEO Friendly Faceted Search – Part 2

In the first part of our blog we covered a way to retrieve products from the database in a quick way. In this part we will cover the SEO part of our faceted-search technique. Let’s start!

Showing all your filters on the page shouldn’t be a problem. Just retrieve all PropertyTypes with their Properties and show them in a couple of lists. But what should happen once a user clicks on one of them?

GET-parameters are not the way to go!

The easiest way by far would be to have every property pointing to url with a GET-parameter assigned to it. We would get something like this (after ‘Apple’ already has been selected):

<a href=”/shop?brand=apple&webcam=1MP”>1 Megapixel</a>

So why is this a bad idea? For two reasons:

  • GET-parameters are indexable by Google, which means that there a many, many product-overview pages showing iPads (think of every combination of the Properties). Instead of having one page showing all iPads, we will have many of them.
  • URL’s tend to get very long, because every parameter needs a key and a value (‘brand=apple’). Shorter urls are better if they still describe the content of the page. Besides, people won’t search for ‘Webcam 1 MegaPixel Colour White Brand Apple’, but will search for: ‘1 Megapixel white Apple’.

Another option is to do everything by javascript and leaving the url the same for every product-overview page. But then the url is non-descriptive and we cannot target specific keywords (such as ‘Apple’, etc).

A SEO-Friendly Faceted Search

The best way to make our faceted search SEO friendly is to have properties which are indexable by Google (i.e. will be added to our url) and some properties which are not indexable by Google. The last part is a bit tricky, because you do want users to be able to share links with each other. So in one way or another, every link has to be added to our url, however it cannot be indexable. Fortunately all elements after the hash (‘#’) in the url are not indexable. So our goal is to get links like:

/shop/apple/black#16gb&3MP

To get these links is actually quite straightforward. Properties you want to be indexable should be pointing to {current url}/Property and properties you don’t want to be indexable should be pointing to {current url}#property.

Only javascript can read the part after the hash (‘#’), so we need the products to be loaded by javascript. This can be done in a few steps:

  • Read the full url
  • Extract all Properties (before the hash and after)
  • Make an AJAX-call and post all Properties
  • Handle AJAX-call serverside (discussed in our previous post)
  • Send matched products back to the user
  • Display matched products

Some catches

There are a few catches with this method though. The first one being that the properties need to be in a specific order! If they are in random order we will get different pages showing the same content. Which will be marked by Google as duplicate content. Both

/shop/apple/black

and

/shop/black/apple

will be showing black apple products. This will be the same page and therefore duplicate content! The solutions is to make sure all parameters are in alphabetical order (or any order you like).

Another catch is that adding something after the hash doesn’t the effect of refreshing the page. So whenever a user clicks on a non-indexable link you have to make sure that the AJAX-call is made and that all other Property-links are rewritten (add the click property to it).

Next part

So our second challenge is solved! Implementing a working example of our faceted-search technique should possible now. In next part we will cover a technique to get the number of products for each filter.

Ivaldi has become a part of ReMark! Read more about it here.