I’ve worked with many clients (and on my own sites) where avoidable structural/data problems add unnecessary complexity to website management.

I say avoidable because they’re usually a result of not asking the right questions upfront before the site is built. It’s a tough task to cover all bases for an ecommerce platform because there are so many factors in play that can affect elements like on-site UX, business reporting, data flows and SEO.

In my experience, it’s a continuous learning curve, picking up insight from specialists along the way to build a (hopefully) thorough knowledge base of what information you need to effectively build a website, what format the data needs to be in and what it needs to do e.g. data field X in the CMS drives site search results

Information Architecture (IA) may sound dull but it’s a critical component of ecommerce and helps put the right data structures and standards in place to enable, amongst other things:

  • Site & catalogue structure
  • Core processes & functions e.g. site search
  • Business reporting & web analytics
  • SEO. 

This blog takes a look at some of the key components and guidelines for what ecommerce teams need to think about. It’s split into three parts that I’ll publish over the next three weeks to break up the hefty tome I’ve written to do this justice (and it’s still high-level!).

  • Part one: Site structure & catalogue structure.
  • Part two: URL structure & data formats.
  • Part three: SEO & integration of non-product content.

I’d welcome comments to add to my views and share advice/experience of what works, what mistakes to avoid and useful resources to use. Hope you find it useful reading.

1. Site structure

This is a sensible staring point for your IA: mapping out user journey flows through the website to identify key page types and the relationships between pages.

The site structure should provide a visual page hierarchy segmented into levels and inheritances (where a page or group of pages belong to a page at a higher level in the hierarchy).

site structure tree

Source: Siterocket.com

The example above classifies pages into levels to show relative depth of each page in the user journey flow. I like to split out the structure into 3 key page types:

1.     Core page groups:

The key page templates from the Homepage through to the category, sub-category, product list page (PLP) and product details pages (PDP). This also includes site search results pages because the template is essentially a PLP. 

2.     Information pages:

Page that aren’t part of the product catalogue but provide access to key areas of the website, for example My Account. This also includes non-product content such as the About Us page.

3.     Content asset folders.

Folders on the root domain where specific content assets are stored, for example /video for all video content and /buying-guides for all buying guides.

In my experience there are three common oversights with site structure planning:

Insufficient depth of core page groups:

It’s easy to disconnect how the product experts in the business categorise products and where users would expect to find them on the website. 

A shallow catalogue structure can actually make it harder for users to find relevant products. One caveat is that with intelligent faceted navigation, it’s possible to reduce the click path but this creates additional challenges for SEO e.g. how do you ensure maximum coverage in the search index for URL variations created by parameters added when using faceted navigation? Please see ‘Catalogue structure’ below for more discussion.

Lack of attention to detail for non-product content:

Usually this is a lack of long-term thinking, focusing only on what the business has now and how it can be presented to users. However, you need to think about where your content strategy will be in the future and build an architecture that supports that.

Of course plans change and evolve but it pays to think ahead so you don’t have to do lots of fiddly development to accommodate new ideas.

For example, how easy is it to integrate non-product content like blogs, buying guides and videos into your site search results page? Do you have the relevant data tags set against each content asset to enable the search index to return only the most relevant matches to avoid diluting quality?

A common mistake with site search is to use all page content within the index but this can throw up anomalies e.g. if a brand like Halfords wrote a blog on car valeting with text “It’s like riding a bike”, with no restrictions on what data is used in the search index it could returned as a broad match for a search on “men’s bikes”.

Example: Search for “steamer” on Mailshop.com returns steam mops as well as steamers. It looks like this is broad matching on “steam” if it appears anywhere in the product data but good practice is to restrict the initial search to exact word match, then expand the criteria if zero results are found.

mailshop search results 

Loose structure for common assets:

A good example is product pages. By default on some platforms, a product page URL usually contains the string for the category the product is allocated to e.g. my domain.com/mens/jeans/product-title. However, products can sit in multiple categories, which then creates duplicate URLs.

For example: 

my domain.com/mens/jeans/product-title.

my domain.com/sale/mens/product-title.

Trying to iron out duplication issues with something like the canonical tag isn’t always easy in this situation. One solution is to use a dedicated folder for each content asset type, so use /products for all products. You can then allocate a product to as many categories as you want and maintain 1 clean URL.

Of course, there are other implications to consider. If you have a single product allocated to multiple categories, you still need to decide how to report on sales/revenue. Are sales allocated to a primary category, or do you report on sales based on which category on the site it was added to the basket from? Or do you have an aggregated roll-up view that can be split down into category level detail?

It’s important to ask this question and agree business-reporting needs with the finance team before setting data structures in stone.

Using the example above, the URL would be my domain.com/products/product-title

2. Catalogue structure

A key challenge with an ecommerce site is the number of levels within the product catalogue. There is a fine balance between reducing the click path and ensuring there is sufficient depth of category classification to make it obvious to users where to find products.

For retailers with a small product range, the decision is much easier to make than for a large catalogue retailer with hundreds of thousands of SKUs. 

Start by putting yourself in the shoes of your customer and ask the following questions:

  • What category structure would make it easy for users to find your products?
  • How many levels do you need within the catalogue?
  • Does each level need its own page template, or can you use faceted navigation to minimise the click path?
  • Are categories/sub-categories clearly named to make it obvious what’s in them?
  • Do you have enough categories to have a meaningful number of products within each category?
  • Is the language you’re using to name categories in keeping with what your users call them?

You also need to assess the SEO benefit of deep category structures; do you want unique URLs for long tail product searches so that each category level has its own page template, or do you prefer keeping the site hierarchy shallow and using on-site navigation tools to get users to products quickly?

Let’s use an example of a men’s fashion retailer selling Coats & Jackets as a sub-category within Clothing.

There are two key SEO ‘friendly’ options:

  1.  Use a sub-sub-category page for each range within Coats & Jackets so that this unique URL can be indexed and used as a landing page e.g. mydomain.com/mens-clothing/coats-jackets/field-jacket
  2. Don’t have a unique sub-sub-category page but use URL parameters to differentiate between sub-category pages and submit each version to the search index e.g. mydomain.com/mens-clothing/coats-jackets?type=”fieldjacket”

The challenge with the second option is that usually faceted navigation has multiple options (product type, brand, colourm, size, price etc.), so you need to define which facets generate URLs that need to be indexed and which ones don’t.

For example, if in the URL above the user also refined the page display by colour and size, additional URL parameters would be generated (e.g. mydomain.com/coats-jackets?type=”fieldjacket”&colour=”green”&size=”medium”), creating a new URL. Should this URL also be indexed or is it best to focus on the original URL as a primary for all searches relating to ‘mens field jackets’? 

There isn’t a ‘right decision’ so you need to weigh up the practicalities of elaborate rules for URL indexation.

If you submit a unique URL for ‘mens green medium field jackets’, do you have enough products to warrant this? Are you likely at some point to have zero items, therefore the user experience will be compromised and you’re likely to see conversion rates drop?

House of Fraser is a good implementation example of the second option above, although the URL is a touch messy. The page for ‘field jackets’ is accessed by filtering the main Coats & Jackets page by ‘style = field jacket’. However, there is a unique entry in Google pointing to: /Men's+Outerwear/203,default,sc.html?prefn1=Style&prefv1=Field%20jacket


This is simply the URL of the Coats & Jackets sub-category page (http://www.houseoffraser.co.uk/Men's+Outerwear/203,default,sc.html) with a URL parameter added for style.

The Baymard Institute’s write-up of its recent usability study of ecommerce sites gives an interesting insight into the impact of category depth.


I appreciate that this is a whistle stop tour and in reality there is far more detail involved and a lot more elements to consider but hopefully this gives you food for thought. 

Creating an IA for ecommerce is a critical element of your project and it needs to be a constant work in progress, updating based on the evolving needs of the business and your website users.

My recommendation is to give someone ownership of this and make sure it’s clearly documented, then use version control to update the master document over time.

What do you think? What tips and tricks have you got to share to help others plan their information architecture?

You can now also read subsequent editions of this blog series:

James Gurd

Published 13 July, 2015 by James Gurd

James Gurd is Owner of Digital Juggler, an ecommerce and digital marketing consultancy, and a contributor to Econsultancy.He can be found on on Twitter,  LinkedIn and Google+.

49 more posts from this author

You might be interested in

Comments (13)

Save or Cancel
Stuart McMillan

Stuart McMillan, Deputy Head of Ecommerce at Schuh

Hi James, great article, if more sites started life as an IA diagram, we'd have more sites that make sense on the internet!

when it comes to catalogue structure, do you think there are any advantages in using a publicly available taxonomy, like Google's? Or do you think them too broad?

over 4 years ago

James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi Stuart,

Thanks for the kind words.

Just been having an interesting exchange on Twitter with @Panopticrat about this, fact that there is no common standard for ecommerce IA and that anything you see online is very generic advice.

I think there can be advantages to using a publicly available taxonomy as it can help you sharpen names and hierarchies based on something that is used in the wild, rather than what you think is right based on the knowledge within the business.

How does Schuh approach the taxonomy question? Do you learn from public sources and align, or do you put more faith in direct customer & competitor research + analytics data e.g. site search data.


over 4 years ago

Stuart McMillan

Stuart McMillan, Deputy Head of Ecommerce at Schuh

Hi James,
Our own taxonomy is mostly internally derived, coming from the buyers and what they set for the stores. Lots of times this isn't quite right for ecommerce, and we have to adjust it. We keep a close eye on GA & site search.

I think there is still some way for us to go in getting it right as a business.


over 4 years ago


Montse Cano

Hi, James! I have enjoyed this article. The lead generation sites should be easier to design and to implement. Closer similarities start when there are various products. In this sense, most taxonomies I have worked on derived strictly from what the business plan is and no other aspects, such as demand from one region over others.

I wish more plans started with research and tech details first (SEO), then design and everything else. It all depends mostly on what others want, but not necessarily need.

over 4 years ago

James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi Montse,

Thanks for the comment.

Yes i think you need to start with the user needs/experience first to ensure that you cover off all data needs to support them.

For an ecommerce site, this includes defining what data fields are required for a) the products you sell b) the forms users need to complete for core processes like sign-up/checkout etc.

@Stuart raised an interesting question on Twitter about the value of taking an object orientated approach to data. I defer to the more technically experienced to comment.

SEO is a tricky topic and I cover some of the challenges in part 3 - coming soon!


over 4 years ago



Hi, thanks for this informative piece, we're looking at creating a new site structure in stages thanks to your advice. We removed all categories from URL structure a while ago on advice, and it seems to have decimated out reach. We now have almost everything as //mainurl/product, rather than //mainurl/category/product.

I wanted to point out that for items with categories in the URL, Google now displays the categories under the main link in listings, this seems to suggest that using categories in URL's is certainly the way to go.

over 4 years ago

James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi @BlokeToys

Do you know the reason for your reach being affected? Did you change the URLs from existing ones that ranked well? Was there any issue with redirects from the old versions?

Google is certainly displaying breadcrumb trails in SERPs but that doesn't mean your URL has to be explicit with the category name.

Take a look at ASOS and "Lee Jeans Luke Blue Label Skinny Fit Bleach Stretch":
Product URL: http://www.asos.com/Lee/Lee-Jeans-Luke-Blue-Label-Skinny-Fit-Bleach-Stretch/Prod/pgeproduct.aspx?iid=3624097
Site breadcrumb: Home > Mens > Jeans > Skinny Jeans
SERPs breadcrumb: Home > Mens > Jeans > Skinny Jeans

The SERPs breadcrumb matches the site breadcrumb (Home > Clothing > Jeans) but the URL is different.

You can create an architecture for your breadcrumb trail that ticks the SEO box for the links in SERPs but keep your URLs how you want them to be.

Of course, you can have a URL format with the category name included, nothing wrong with that. However, when locating a product in multiple locations you then have to think through the duplicate content challenge. In my experience, having a /products folder takes that headache away and then you simply set the breadcrumb trail to represent the true path (independent of the URL).

So if i have Blue Skinny Jeans in the Category Jeans in Men's Clothing department, I would set:
URL: www.mybrand.com/products/blue-skinny-jeans
Site breadcrumb: Home > Men's Clothing > Jeans > Blue Skinny Jeans

If i then put this item in the sale category, i'd set:
URL: exactly the same
Site breadcrumb: Home > Sale > Jeans > Blue Skinny Jeans

Hope that makes sense!


over 4 years ago


Jörg Lahmann

hi James, i enjoyed reading through the article as website UX is one of my favourites.
and as tip for improvement and applying the knowledge, would be helpfull to crosslink to the part II and III ;-)
best Jörg

over 4 years ago


Georg Spielmann, E-commerce consultant and project manager at Fredhopper

Hi James,

Very informative article!
I would like to add a comment on the category structure from an on site search point of view.
Compounded categories such as "coats & jackets" can be very harmful for on site search if you search in the entire category path.
A maybe clearer example would be a category called "Washing machines & driers". If one searches for a dryer, he is not per se interested in washing machines and vice versa, but if the entire category path is used in the search index, you will receive all washing machines when searching for dryers, in the extrem case maybe even ranked higher.

A common (but rather bad) way to avoid this is to only index the lowest leaf category. Unfortunately often the main information is missing in the lowest level categories i.e. men>shirt>short sleeved.
With a bit of logic, you should exclude any compounded category in your search index, or your category structure should always be as descriptive as possible in the lowest level.


over 4 years ago

James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi Georg,

Hope you're well. Thanks for the comment.

You make a good point - for my the key to compound categories is to ensure that the two parts are closely related, not completely separate product types as per your example.

A good example is high street department stores. The product range is huge, so it's not feasible to create separate high level categories for each and every product type. So you'll get compound options like Coats & Jackets. The focus is on UX - when a user lands on the page, they would expect to be able to browse both types, using filters & faceted navigation to refine the view.

House of Fraser has a Men's Coats & Jackets page - it ranks for both "mens coats" and "mens jackets". Other big retailers do exactly the same.

So i think it comes down to logical associations.


over 4 years ago


Georg Spielmann, E-commerce consultant and project manager at Fredhopper

Hi James,

thanks for your answer, I absolutely agree, just wanted to point out that with "complex" hierarchical structure, you need to put some thought in the search configuration for the category structure.
I agree that compounded categories are necessary for large catalogs. I would argue though that the lowest level category (the leaf) should be unambiguous if possible!


over 4 years ago


Abdulaziz Alrashed, Founder at Searchable Domains

Thank you James . You just motivated me to register to comment on this amazing helpful article.
I am in the process of creating a website structure for my project. I have some categories with no sub-categories. In the other hand, I have some categories with sub-sub-sub-categories. And the good thing, there is no impossible. We all have the ability to read, ask, and think about solutions or at least alternative way to go around the problem. When I look to the first structure I made it, it was useless. But now, it is almost done. I am reading articles to develop it with the good things.

And that is right, when your are building a structure you need during that to keep in mind (keywords, links, navigation, and products search) in the all levels of the structure.
The big challenge in eCommerce is that you don't have the area for contents to rank the categories and the sub-categories pages. But building a clear simple structure, with the points that you mentioned above, it will rank.


almost 3 years ago


Abdulaziz Alrashed, Founder at Searchable Domains

One other question, what about an eCommerce blog? Does it have to have structure, too?
I googled but found nothing about! Help would be appreciated.

almost 3 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Digital Pulse newsletter. You will receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.