Disconnected category structure

The optimal solution for an end user would be a totally dynamic category structure that has no links to rigid and fixed structures at all. This will however create a mess when it comes to search engines with continuously changing category structures where the content is always changing. Not good for SEO.


In a traditional e-commerce site, there is often only possible to navigate to a structure in one way or maybe two different ways. I mentioned about this problem in my previous posts about the non flexible e-commerce stores.

Categories and attributes

In my case, when using STORM as the source of my product information, I have categories created with a focus on how to structure products in categories where the categories also are used to control which attributes that are valid under each category.


In this implementation, we have chosen to create a shallow category tree compared to what we used to have before in the previous solution. This structure will be available on the web site as a basic navigation structure where it is possible to navigate to each of those nodes.

Site navigation structure


The navigation structure in Sitecore is much deeper than the structure in STORM in order to assist the user in finding the correct product in category navigation. Each of the categories in Sitecore are then connected to a search criteria to find out which of the products to show in each category. The connection is made by the following search parameters:

  • One or several categories in the master structure
  • Filter on manufacturer
  • Filter on attributes
  • Filter on stock status

This makes it easy to drill down into the category structure without maintaining the details of each level by managing which products that belongs to each node.


In the screen shot above, you can see that we have connected the category source to a part in the commerce connect data model for classifications. We selected to set the name of each node with the entire hierarchical structure in order to know which leaf that has been selected. In our case, we have the leaf node of E14 in more than 8 places and we prefer to know which E14 we are dealing with.

Using STORM data within Commerce Connect data model

The other benefit of connecting Sitecore Commerce connect classifications with STORM categories is that we manage which attributes that are available on the classification level. This means that we can make an intelligent selection of which attributes that are really possible to drill down into in the end user interface in the e-commerce site. In STORM, we also select which of the attributes that will be possible to drill down on a category so that the user interface is kept nice and tidy for the end user.

When it comes to the actual content of the categories when it comes to populating them, we are using the STORM API to make real time requests to get a sorted list of which products to display on each category level based on the configured source categories and search parameters. The products are then fetched by using standard Sitecore item retrieval which makes us benefit from all cache functions in Sitecore.

Examples of such a query:

  • Category: Master Catalog / Lighting / LED / E14
  • Attribute: Bulb Shape = Classic P
  • Attribute: Dimmable = False

Then Storm will return a list of SKUs matching the query. In Sitecore Commerce Connect, the products all have an external product ID.


This external ID can be calculated to find out the Sitecore ID of that item. There is an IdGenerator class that is accessible through the ProductRepository provided as part of Commerce Connect to really quickly retrieve items based on primary keys for display in the category tree. The request to STORM is of course also managed in a cache to not run a request over the network for each category browsing request.

What about SEO?

From a SEO perspective, we will make sure to have each product existing in one of the master categories that are quite full of data as the master source of that product. Bread crumbs will always point to this category if a product is referred to from a random URL or found in a result of a search engine. This category is then tagged with previous and next SEO style tagging of the links to show browse several pages of the category that at this point is really large. The focus on the smaller categories will be the category text section and prioritized images for each category.

The main navigation will not contain links to every category on the site. It will be limited to the top levels only to make sure that the search engine will have relevant child links when drilled down on each category structure. You will only see one or two levels down in the tree for each level that you drill down.

Each product will have a unique URL that is not connected to a category, so when ever there is a link to a product from a category, the link till go to the product URL and have no relation at all to the category.  This eliminates the need for dealing with canonical tags for each product and risk having a product appearing with details on several pages.

We have to be a bit careful about which information about a product that we share on the categories compared to on the product pages, which is also why we will save the important copy text to only be available on the product pages.

The following two tabs change content below.

Fredrik Gustavsson

CEO, IT-consultant at Jolix AB
Software and integration magician with an interest in how to improve commerce in a multi channel environment. Owns his own IT-consultancy business and runs an e-commerce store that has a physical store. Will write blog posts on how to take his own store into the future.