Information Architecture and SEO for e-commerce sites

Fernando Maciá

Written by Fernando Maciá

The information architecture is one of the primary aspects with a substantial impact on a website’s SEO. In most cases, the optimisation unfortunately takes place on already published websites, so there’s barely any wriggle room, so to speak, to improve their architecture.

However, when SEO recommendations are implemented during the website’s development stage, we can make an enormous difference, by focussing the website’s structure in a much more suitable manner, according to our target audience’s most popular search patterns.

This post is an overview of my lecture for #Monetiza19, organised by José Facchin. You can check out the full presentation (in Spanish) linked at the end of this article.

Tools for analysing a website’s information architecture

Screaming Frog is a very useful tool for analysing how a website is structured. If you go to its Crawl Depth section, you will see the number of pages located at one, two, or three-click distance from the crawled page. This indicates us how far from the home page a particular piece of content is.

Our experience tells us that Google crawls more frequently and gives more importance to pages which are closer to the home page. As a matter of fact, this is how it analyses the website’s architecture –through its internal linking structure– and not its URL syntax. I.e. the number of directories included in a URL is much less important than how the content is linked when it comes to evaluating its position and value within a site’s internal architecture.

Screaming Frog also evaluates the relative importance of a page using an indicator called Link Score, depending on its standing within the information architecture of a website. As we can see in the screenshot below, the Link Score is usually higher for pages receiving a higher amount of internal links. We can also see pages registering a high Link Score despite not receiving many links. To understand this situation we have to look into the relevance of those pages, from which these links are coming to them. In the end, Link Score behaves in a similar manner to Google’s Page Rank.

Link Score in Screaming Frog
Link Score in Screaming Frog


Another way to see our internal links is by going to Google Search Console > Links > Top linked pages in “Internal links”. If we scroll down this list, we’ll eventually reach a breaking point where the decrease in links is no longer progressive and descends abruptly. This means that pages from there on aren’t linked from the website’s common areas, namely the main menu or the footer; and thus have less inbound links.

OnPage Rank on Ryte
OnPage Rank (OPR) on Ryte


We can also use tools like Ryte, which calculates the OnPage Rank (OPR) for each page, based on their position within the architecture and internal linking. This indicator also reaches a breaking point, making a distinction between pages linked from common areas of the layout and pages with a considerably smaller number of inbound links.

Information Architecture aspects which influence SEO

If we assume that information architecture largely determines the relative relevance of a content in the context of a website, then during the optimisation of an e-commerce store our goal will be to get the best rankings for our product categories and subcategories, as well as our most popular and profitable products.

We can concentrate internal authority and popularity of a website on the most profitable pages, by acting on these three points:

  • Proximity of the page to the home page (depth level within the architecture)
  • Total number of inbound internal links.
  • Relevance of internal pages from which internal links are directing towards that content.

So, building on top of the ideal information architecture that would propose a usability expert, from an SEO point of view we introduce changes that will influence these three key points on pages we’re aiming to position. Without noticeably altering the website’s navigation we can, for example, situate first and second-level subcategories, or even products, at the same level as the main categories, provided the search volume recommends doing so.

Let’s see how we can apply this concept in each particular scenario. First, we need to decide when a piece of content should or shouldn’t be indexed. Two criteria that should be met at the same time for a page to be indexed are:

  1. It must have search volume.
  2. Our store must have sufficient products to satisfy the needs of a user carrying out this search (sufficient models, sizes, stock, etc.).

If either of these two conditions isn’t met, then it’s probably this content is not worth indexing.

Analysing the potential of two search patterns to determine primary and secondary taxonomies

The search volume will thus mark the first criterion to establish the foundation for our website’s information architecture. Let’s take a look at the following example, where we analyse the monthly search volume of queries related to “toys” seed keyword:

Toys seed keyword example

We can see how, starting from the most popular search queries, we can deduce other recurring queries which follow specific patterns:

  • Toys + ages
  • Toys + characters (tv series, films, video games…)
  • Toys + types

These patterns usually match the most popular taxonomies, that is to say, characteristics specified by most users to define or indicate their search intent.

Once we’ve identified these taxonomies, our work will consist in deciding which ones should become the main categories, and which ones should be used as filters.

This is our recommendation:

  • Taxonomies with a higher search volume should be our main or parent categories (families) of products.
  • Taxonomies with a lower search volume should be our product child subcategories.
  • Taxonomies or combinations of features used at a second stage (when the user is looking at a list of products) should be defined as filters.

In our example, “baby toys”, registers 1,220,000 monthly searches, so the “toys + ages” search patterns should probably be established as a main category within our site’s menu.

“toys cars” or “toys dinosaurs” search patterns specify a product type and their search volumes go down to 663,000 and 368,000 monthly searches respectively, so it could be a subcategory of the main category matching the keyword “Cars” and “Dinosaurs”.

And finally, “toys pokemon”, “toys barbie”, etc. register even less monthly searches. A user could possibly apply them as filters at a second stage (once they landed on our main category “toys + ages”). In this case, our recommendation would be to use the character or brand as a filter. I.e. “toys + cars + barbie” or “toys + dinosaurs + jurassic world”

Menu organisation

Main menu

Now that we’ve identified the main taxonomies and the most profitable product categories, we place them within the top level navigation on a page, i.e. main menu items.

Once that’s out of the way, we add crawlable drop-down menus (using CSS, for example), where we will include links to first and second-level subcategories selected earlier, based on their search volume and profitability.

Additional links through AJAX

Finally, we will add a “See more” link, which the user can click on to view the remaining items in the menu, that is, first and second-level child subcategories. These links will be expanded using AJAX, which means Google will not crawl them initially.

Crawlable links (CSS) and non-crawlable links (AJAX)

What we are trying to do here is to place first and second level subcategories at the same depth as main categories (level 1), and with the same amount of links, whilst links loaded through AJAX are placed at a deeper level (level two, we’ll see how to link them shortly) and with a correspondingly smaller amount of links).

Contextual submenus

One of the most common errors on many websites is that the side menu directly includes all of the first and second-level subcategories pertaining to the same main category we are browsing. Sometimes it even displays all existing categories, with their corresponding first and second-level subcategories. As a result, the amount of outbound links goes through the roof and there is no hierarchy whatsoever.

Our recommendation to ensure a correct interlinking strategy for the first and second-level subcategories linked using AJAX from the main menu is to include links to them only from pages placed at the same hierarchy level. Let’s see how to do this.

Main category pages

The main product category page’s contextual submenu should include links to all the first-level subcategories, with additional links to expand second-level subcategories loaded through AJAX. This way, Google will only see first-level subcategories as crawlable links. Although this structure partially duplicates links already present in the main menu, it doesn’t usually pose any problems.

Crawlable links in the contextual submenu

Let’s recap: the group of subcategories present in the main menu receives links from all pages of the website, whilst the group of subcategories loaded through AJAX in the main menu will receive links only from all pages belonging to the same main category. This means that these pages are one more click deeper within the architecture, and thus, get the corresponding amount of links based on the number of first and second-level subcategories of each family.

Subcategory pages

When we navigate to a subcategory, we’ll see expanded links to the second-level subcategories handing from said subcategory. The rest of second-level subcategories belonging to other subcategories will be loaded through AJAX.

This way, all second-level subcategories –not originally present in the main menu– will be within a three-click distance from the home page (level 3) and they will get the corresponding amount of links based on the number of second-level subcategories within that subcategory.

Links to second-level child subcategories from their first-level subcategories

Let’s recap: second-level subcategories present in the main menu will be at a one-click distance from the home page and will have inbound links from a 100% of the website’s pages, whilst links which aren’t in the main menu (which are loaded through AJAX) will be at a three-click distance from the home page and will only have inbound links coming from the remaining pages of the subcategory, making them third-level subcategories.

This strategy allows us to juggle any navigation requirements posed by the website usability experts (for example, to allow users to navigate to any section of the website from its main menu), and at the same time, it keeps under control the total number of outbound links from each page, establishing a hierarchy which rewards the most profitable pages with link-juice.

Filter management

As we’ve already seen, we can facilitate navigation on our website both with menus structured by categories and subcategories, and with filters. Filters are useful to help users to specify additional features regarding the product, and which are usually considered at a second stage, once the user is looking at product listed within a category or subcategory.

One of the decisions we must take in terms of SEO is whether we want to index a filter page or not. The decision will once again depend on the search volume and product availability.

In general, filters corresponding to popular search queries should be indexable. To make them so, we need to include crawlable links next to the checkboxes used to activate the desired filters. Crawlers can follow these links to category pages + filter which are indexable. For example: “men’s” boots category, “leather” subcategory + “brown” filter register 9,900 monthly searches, so it should be indexed.

Browsable filter with link to category page + filter for creating an indexable page
Browsable filter with link to category page + filter for creating an indexable page


However, the selection of two or more filters at the same time will rarely generate a page with search potential. For example: “men’s” boots category, “leather” subcategory + “brown” filter, + “lace up” filter, + “size 8” doesn’t register search volume. Applying two or more filters should be allowed (the user should be able to navigate to the page), but they can’t be indexable (thus Googlebot shouldn’t have access to them).

The decision between indexing or not indexing a page, as a result, depends on the search volume and product availability. The decision to enable navigation to a page depends, however, on how useful it is for the user. Also depending on the product availability we should decide when it’s convenient to enable navigation to these pages and when we shouldn’t.

When the user is willing to “wait” for an out-of-stock product to become available, or can request some kind of alert when it’s back, then we can enable navigation to the filter, but not make it indexable.

To control the indexing of several different filters which can be navigated to, we either implement obfuscation of links and include “noindex” in the meta robots, or manage parameters.

If there are no available products for a specific filter, and it’s not useful for the user, then the recommendation is to directly avoid “painting” the link, so that it’s both blocked to navigation and indexing.

Managing products with stock variation

One of the most frequent issues in terms of information architecture poses the question of how we should treat stock shortages for specific products. Should they continue to be displayed all the same? Should we do something different?

If they are products with a high search volume, then we should do everything in our hands to maintain the rankings of these pages whilst the product remains out of stock. For this to happen the page should continue returning 200 OK and we need to make sure to include related products or possible substitutes, which could easily satisfy the user’s needs (and avoid losing the conversion).

Nevertheless, given that this page’s conversion will be temporarily affected, our recommendation would be to situate the link to unavailable products at the end of these category or subcategory pages, to concentrate the crawl budget on available products and with the highest conversion potential.

Once the original products are back in stock, the link to the product page would recover its position within their corresponding pages.

Managing discontinued products

Products with high search volume

Discontinued products should continue to be indexed while they continue to be searched by users. Even though a product might have stopped being manufactured, it will be still searched by users for some time. We recommend keeping that page indexed for as long as the term the page is optimised for has search potential.

Just as in the previous case, given that these discontinued products will have a lower conversion rate than the rest, our recommendation is to link them at the end of their category pages, giving higher priority to current products that are in stock.

The product sheets for discontinued products should include references to the new model or a substitute product of the obsolete one, in an attempt to redirect the user to said product and to avoid losing the conversion.

Products without search volume

Once the search volume of a discontinued product decreases, it won’t be worth wasting our crawl-budget on its page, so we recommend creating a 301 redirect to the page of a new model, or a substitute product if there is one.

Don’t forget to perform a comprehensive crawl of the entire website in case there are links still pointing to the obsolete product sheet that need to be updated. For example, links from blog posts or from other types of content. This way, we will concentrate in the substitute product’s URL any residual popularity gathered by the removed item.

Managing discontinued product categories

Sometimes entire product categories get discontinued, or the number of products contained in them is reduced to the point where it’s better to merge them into their parent category. In this kind of situation we would relocate products from the discontinued subcategory into their immediate parent. 301 redirect implementation is in order if the product URL syntax is about to change to include the parent category directory. We would also need to redirect the discontinued product subcategory URL to its parent category. This way we will concentrate in the parent category any residual popularity juice gathered by the removed page.

If a product page or category are discontinued for good, and there are no substitute products or a parent category to which they can be redirected, our recommendation is to implement a 410 gone error (content removed) and correct any internal links pointing to the destroyed categories.

Managing product categories with copious pages

One of our goals with an information architecture is to determine the ideal level of granularity in the categorisation of products. Having tons of subcategories with barely two or three product references is just as bad as keeping categories so generic their portfolios contain a vast amount of products that extend over a huge number of pages. We know that neither Googlebot nor users are about to deep-dive into paginated content.

In such scenarios our recommendation for main categories is to include featured product sections, for at least two of the most relevant subcategories.

Featured products to avoid endless pagination issues

We should highlight the products with the highest potential from each most-searched subcategory. And below those, list the products of the main category, ordered by their most prominent features (higher search volume, profitability, stock volume, competitive price, new additions, etc.).

This places direct links to the most important subcategories, as well as to the most attractive products on the first page of the paginated content, where it’s more likely to be crawled by search engines. It is also a more usable approach for users, who are unlikely to move deeper and deeper in the pagination to find the desired product.

Managing seasonal products

There are online shops, whose product catalogues change radically from winter to summer, namely those related to fashion:

seasonal products
An online shoe store has to prioritise different product ranges depending on the season


In this situation, the goal is to successfully manage product categories with seasonal demand so that they don’t lose their rankings from one season to the other.

When we have seasonal product ranges, we can prioritise one over the other in the menu.

We can avoid deindexing categories if we keep these sections linked from the “Outlet” or “Clearance” areas until the next season, with some product references. Although it’s normal that the products won’t last until the next season, most categories will stay from one season to the next. These are the pages, on which we must concentrate our efforts to prevent loss of rankings.

We can corroborate on Sistrix how handles its seasonal product range avoiding cyclical declines, which, on the other hand, do affect

Visibility seasonal variation on fashion sites is affected by the removal of products, while Zalando is successful at maintaining its levels of visibility each season. Source: Sistrix.


Key aspects to remember

  • Menu: as many links as necessary, as little as possible.
  • Contextual submenus: links in proportion to each category and subcategory’s potential.
  • Only pages with search potential and for which we can provide an attractive offer should be indexed.
  • Correct management of stock breakage to avoid loss of rankings / bounce.
  • Introduction of hierarchy in lists of products to speed up navigation towards subcategories, avoiding clunky pagination.
  • Keeping menus ordered according to their categories’ seasonal potential, to focus authority on pages with the highest conversion rate.


Fernando Maciá
Autor: Fernando Maciá
CEO of Human Level. He's an expert in SEO, online marketing plans and web internationalisation. He's also a digital marketing teacher and an accomplished writer, having published several books on web positioning, social media marketing, and strategies to earn customers on the Internet.

Leave a comment

Your email address will not be published. Required fields are marked *