Skip to content

Explainer · 9 min read

Site ArchitectureHow stores are found and browsed

Diagrams
02
Tools
02
Sections
09

The short answer

Ecommerce site architecture is the way an online store organises its pages, from home page to categories, subcategories, filters and products, and links them together. Good architecture lets shoppers reach any product in a few clicks, gives search engines clear paths and distinct pages for each demand, and keeps filters from multiplying into thin duplicate URLs.

Structure is a merchandising decision

Site architecture is often handed to developers or SEO specialists as a technical matter. It is really a merchandising decision. The way you group products says what you think customers are looking for, and it shapes which products they see first.

It also determines which searches the store can rank for. A category page can only rank for a demand it is built to serve. If shoppers search for ‘running shoes for flat feet’ and your store has no page that represents that idea, no amount of optimisation elsewhere will fill the gap.

Every category page is a promise that you understand a particular kind of shopper.

The hierarchy

Most stores follow a hierarchy from broad to narrow. The shape matters: too flat, and categories become unmanageable lists; too deep, and products sit many clicks from the home page, which hurts both shoppers and crawlers.

Fig. 01 · Hierarchy

A typical ecommerce hierarchy

  1. 01 · Home

    Brand, best routes into the range, current priorities

  2. 02 · Departments

    Broad groupings such as women, men, home

  3. 03 · Categories

    Product types such as dresses, kurtas, footwear

  4. 04 · Subcategories and curated pages

    Narrower demands: occasion, style, use, concern

  5. 05 · Product pages

    Individual items and their variants

Each level should represent a real way customers think about the range.

A common rule of thumb is that important products should be reachable in a few clicks from the home page. The exact number matters less than the principle: depth should reflect how customers narrow down, not how the warehouse organises stock.

Designing categories from demand

Start with how customers describe what they want. Sources include site search logs, keyword research, marketplace category structures, customer service conversations and the language in reviews. Group demand into themes, then decide which themes deserve their own page.

  • Product type is the backbone for most stores: shirts, sofas, serums.
  • Use or occasion suits many categories: workwear, wedding guest, gym.
  • Problem or concern suits health, beauty and home: dry skin, back pain, small spaces.
  • Attribute sometimes deserves a page when demand is distinct: linen shirts, solid wood tables.
  • Audience matters where needs differ: kids, seniors, beginners.

See keyword research for methods and information architecture for the broader discipline.

Faceted navigation: the double-edged filter

Filters for size, colour, price, brand and other attributes help shoppers narrow large categories. They also generate URLs. A category with several filters, each with many values, can produce an enormous number of combinations, most of which have no search demand and near-duplicate content.

The architectural question is which filter combinations deserve to be indexable landing pages and which should exist only for browsing. The answer depends on demand and on whether the resulting page is genuinely useful.

Fig. 02 · Matrix

Which filtered pages should be indexable?

HighSearch demand for the combinationLow
FewProducts in the filtered set →Many
Decide filter by filter, and revisit as demand changes.

The technical mechanisms, canonical tags, robots directives, parameter handling and internal linking choices, are covered in technical SEO. The decision about which pages should exist is a business one and should be made before the technical implementation.

URLs and breadcrumbs

URLs should be readable, stable and consistent. A product should have one canonical URL even if it appears in several categories. Changing URL structures later is costly, because it requires redirects and risks losing search visibility; see site migration SEO.

Breadcrumbs show shoppers where they are and give search engines a clear sense of hierarchy. They are especially useful on product pages reached from search, where the visitor has skipped the category path entirely. Breadcrumb structured data can help search engines display the path; see schema markup.

Internal linking as architecture

Navigation menus are only part of the structure. Links within category descriptions, related product modules, buying guides and editorial content also shape how authority and attention flow through the site. Pages with few internal links tend to be treated as less important by search engines and are seen less by shoppers.

  • Link from buying guides to the categories they discuss.
  • Use related product and ‘complete the look’ modules to connect products across categories.
  • Avoid orphan pages: every indexable page should be linked from somewhere sensible.
  • Keep the main menu focused; mega menus with hundreds of links dilute attention.

Our guide to internal linking explains the principles in more depth.

Seasonal and campaign pages

Stores often create pages for sales, festivals and campaigns, then delete them when the event ends. That throws away whatever search visibility and links the page earned. A better pattern is a permanent URL for recurring events, such as a Diwali gifting page, updated each year and kept live with evergreen content between seasons.

For one-off campaigns, decide in advance whether the page should be indexable and what happens to it afterwards: redirect to the most relevant category, or keep it as an archive. Make that decision part of the campaign brief rather than an afterthought. See festive sale marketing.

Architecture by store size

Compare scenarios

What changes as a catalogue grows

Tens of products. Architecture is mostly about clarity and focus.

  • A handful of collections that match customer needs
  • Strong product pages carry most search demand
  • Avoid creating empty or near-empty categories

Testing your architecture

Self-diagnostic

0/6

Does your store’s structure work?

Answer from a customer’s point of view and from a crawler’s.

  1. 01Can a new visitor reach any best-seller in a few taps on a phone?

    If yes: Navigation is doing its job. If no: Simplify the menu or surface best-sellers higher.
  2. 02Does each major search demand in your category have a matching page?

    If yes: Your structure reflects demand. If no: Plan new category or curated pages from keyword and site search data.
  3. 03Do you know which filter URLs are indexable and why?

    If yes: Good governance; review it as demand shifts. If no: Audit faceted URLs; uncontrolled filters often create thin duplicates.
  4. 04Does every product have one canonical URL?

    If yes: Duplicates are under control. If no: Fix canonicalisation before adding more pages.
  5. 05Are there indexable pages with no internal links?

    If yes: Link them in or remove them. If no: Good; keep checking after catalogue changes.
  6. 06Does site search return relevant results for common misspellings and synonyms?

    If yes: Search is supporting navigation. If no: Tune synonyms; failed searches reveal missing structure.

Architecture is never finished. New products, seasonal ranges and shifting search demand mean the structure should be reviewed at least annually, and whenever the range changes significantly. Treat it as part of ecommerce SEO and of merchandising, not a one-off build.

Key takeaways

  1. 01Site architecture is a merchandising decision about how customers look for products, not only a technical task.
  2. 02Build categories from demand: product type, use, problem, attribute and audience.
  3. 03Decide deliberately which filter combinations deserve indexable pages and keep the rest browse-only.
  4. 04Give each product one canonical URL and support the hierarchy with breadcrumbs and internal links.
  5. 05Review architecture regularly as the range and search demand change.

Frequently asked

What is ecommerce site architecture?
It is the organisation of an online store’s pages and the links between them: home page, departments, categories, subcategories, filtered views and product pages. It affects how easily shoppers find products and how well search engines understand and rank the store’s pages.
How many clicks should a product be from the home page?
There is no fixed rule, but important products should be reachable in a few clicks through logical navigation. Very deep structures make products harder to find for shoppers and can make them appear less important to search engines. Depth should mirror how customers narrow their choices.
Should filtered pages be indexed by Google?
Only some. Filter combinations with genuine search demand and enough products to be useful can work as landing pages. Most combinations have no distinct demand and create near-duplicate content, so they should be kept out of the index using appropriate technical controls.
How do I structure categories for SEO?
Base them on how customers search, using keyword research, site search logs and customer language. Give each distinct demand one page, avoid overlapping categories that compete with each other, write useful category copy, and link categories from navigation, guides and related products.
What is the difference between categories and collections?
The terms vary by platform. Generally, categories form the permanent hierarchy of product types, while collections are curated groupings such as seasonal edits, occasions or best-sellers. Both can be landing pages, but collections change more often and need clear rules on whether they should be indexed.

Published by Fabulous.Media, a network of specialist marketing agencies. Updated 9 October 2026. Platform features change often; check current official documentation before acting on platform-specific detail.

Read next

Prefer a specialist to do this with you? The network has a house for every discipline in this library.

Request an Introduction