Category Structure for Large Websites: The Right Architecture for SEO and User Experience

Large websites rarely fail because of a single bad page. In my experience since 2012, they fail because the category structure underneath thousands of pages was never designed. As a result, products hide five clicks deep, filters spawn hundreds of thousands of crawlable URLs, and Googlebot spends its time on duplicates. In this guide I explain the five step method I use for corporate and ecommerce projects, so you can build an architecture that serves both search engines and people.

How do you build a category structure for a large website?

A category structure is the hierarchy of sections, subsections and listing pages that groups a large catalog into paths a visitor and a crawler can follow. You build it in five steps: inventory and demand mapping, card sorting for the user mental model, a depth and URL decision, faceted navigation and pagination rules, then internal linking and breadcrumb validation.

The order matters, because each step feeds the next. First, you need to know what you actually have and what people search for. Then you learn how customers group those things in their heads. Only after that do you decide how deep the tree goes and how URLs look. Finally, you control filters, pagination and links so the whole thing stays crawlable. I treat the result as a map of two budgets at once: Google's crawl budget and the visitor's patience.

• First, inventory every product, article or service and attach search demand to each group.
• Second, run card sorting with real users to discover natural groupings.
• Third, decide depth versus breadth and write the URL scheme.
• Next, define rules for filters, sorting and pagination before launch.
• Finally, verify with internal links, breadcrumbs and Search Console data.

Why does category structure directly affect SEO?

Category pages carry most of the non brand demand on a large site. Someone searching for "women's running shoes" does not want one product; they want a well organised list. Therefore the category page, not the product page, competes for that query. If your category structure has no page for that intent, you leave the ranking to a competitor who built one.

In addition, the category structure decides how link value flows. Every menu link, subcategory link and breadcrumb passes authority downward. A flat, well linked structure spreads that authority across many pages. In contrast, a tangled one traps it in a few sections while orphaned products receive nothing. In my SEO consulting audits, a category architecture review usually comes before any content work, because it changes what every later fix can achieve.

There is also a third effect people forget. Crawlers use categories to discover new pages. When a new product only appears on page 14 of a listing, Googlebot may take weeks to find it. As a result, launches underperform for reasons nobody sees in the content itself.

Does Google understand site hierarchy from URLs or from links?

From links, primarily. Google states in its ecommerce site structure guidance that it infers structure from the linking relationships between pages, not from the URL path. So a product living at /shop/item-123 can still belong to a clear hierarchy if the category page links to it and it links back.

That same document gives a simple rule I repeat to every client. Link from the menu to category pages, from each category to its subcategories, and from each subcategory to every product it contains, using plain anchor links. Otherwise, if a category does not link directly to all of its products, Googlebot may never find some of them by crawling alone.

In practice this means three checks. First, does every category page reach all its items through paginated links? Second, does every product link back up to its category? Third, does the navigation expose each category from the homepage? Readable URLs help humans and give a small extra signal; still, links do the heavy lifting in any category structure.

How many category levels should a large site have?

As few as the catalog allows while every level still carries real demand. I usually aim for three levels below the homepage: category, subcategory and, only where needed, a third tier. In practice, deeper trees push products far from the entry point and dilute link value at each hop. Wider trees keep products close but overload menus and listing pages.

Here is an example calculation, not a client case. Homepage to category to subcategory to product equals three clicks. Now imagine a category structure where one subcategory holds 480 products and 24 items per page. That listing needs 20 pages, so the last product sits 22 clicks from the homepage. Splitting the same 480 items into four subcategories of 120 drops the worst case to about seven clicks.

For catalog taxonomy decisions of this kind I work inside ecommerce consulting projects, because the answer depends on stock, margins and seasonality as much as on SEO.

How do you name categories in the language of your users?

Ask the users, not the product team. For example, internal names such as "Accessories: Tier B" mean nothing to a shopper. The Nielsen Norman Group describes card sorting as a research method where participants place labelled cards into groups that make sense to them. In short, it reveals the mental model your category structure must match.

Two variants serve two different goals. Open card sorting lets participants invent their own group names, so it exposes natural categorisation. Closed card sorting asks them to place cards into categories you already defined, so it validates a proposed structure. NN/g recommends tree testing for that validation step as well, and suggests 30 to 50 participants for quantitative confidence.

Then cross check the labels with search demand. A card sort might produce "Cold Weather Gear", while search data shows people type "winter jackets". In that case the category structure keeps the grouping from the sort and borrows the wording from search. So both signals feed the final category structure.

How do you run card sorting and tree testing step by step?

I follow a seven step plan that fits most projects within two weeks. In practice, it works for a 300 product store and for a 30,000 article knowledge base alike; only the number of cards changes.

1. Pick 40 to 60 representative items and write one card per item in customer wording.
2. Recruit 30 to 50 participants who match your real audience, not colleagues.
3. Run an open sort and let each participant name their groups freely.
4. Cluster the results and note items that split across several groups.
5. Draft the category tree, merging synonyms and dropping groups with fewer than five items.
6. Run a closed sort or a tree test with a fresh group to validate the draft.
7. Record success rate and time per task, then fix labels that scored under 70 percent.

Items that landed in several groups are the interesting ones. For example, "yoga mat" might sit under fitness for some and under home for others. That tells you where cross links or multiple breadcrumb trails will pay off later. Keep those notes, because they feed step five of the method.

What should category URLs look like?

Short, readable and consistent. Google's URL structure guidance for ecommerce sites recommends descriptive words in the path, for example /product/black-t-shirt-with-a-white-collar, rather than numeric codes alone. In addition, it warns against linking internally to temporary parameters such as session IDs or tracking codes, and asks for consistent casing and trailing slashes.

For a category structure I use a subfolder pattern that mirrors the tree: /shoes/, /shoes/running/, /shoes/running/trail/. Each segment doubles as a breadcrumb label. Filters live in query parameters in the ?key=value form, never in new folders. In addition, Google asks you to minimise the number of alternative URLs that return the same content, so one canonical path per category is the rule.

A few habits save trouble later. First, lowercase everything. Use hyphens, not underscores. Keep slugs under five words. When we design a new site in a web design project, I write the URL scheme before the first wireframe. If you need clean slugs quickly, my slug generator turns any category name into a safe path.

How does faceted navigation drain crawl budget?

Filters multiply URLs faster than any other feature in a category structure. Every combination of colour, size, brand and sort order creates a new address. Google's faceted navigation documentation explains the problem plainly: filter URLs look new to a crawler, and the crawler cannot know whether they are useful without fetching them. So it fetches many, and less time remains for genuinely new pages.

For example, consider this calculation, which is an illustration and not a client case. Take one category with 5 colours, 6 sizes and 4 sort orders. That alone yields 120 combinations. Multiply across 40 categories and you reach 4,800 URL variants; with 50 categories and a couple more filter types you pass 240,000 crawlable addresses. Meanwhile the pages you actually want indexed might number 300.

Now compare that with Google's crawl budget thresholds. Its large site crawl budget guide says budget management matters for sites over a million unique pages that change weekly, sites over ten thousand pages that change daily, and any site with many "Discovered, currently not indexed" URLs. A filter explosion pushes a mid sized store straight past the ten thousand mark.

When should you use robots.txt, canonical or noindex for filter URLs?

Each tool solves a different part of the problem, so the choice depends on demand. Google ranks robots.txt disallow as the most effective option for filter URLs you never want in search, because it stops the fetch entirely. A URL fragment (#) keeps dynamic filters out of the crawl altogether. Rel canonical is the weaker choice, however, since Google still fetches the page before it can honour the hint. Nofollow only helps if every link to the URL carries it.

In short, block what has no demand, open what has demand, and canonicalise the rest. To write the disallow rules without syntax mistakes, use my robots.txt generator and test the result in Search Console before deploying.

Pagination, load more or infinite scroll: which one should you choose?

Classic pagination with unique URLs, in nearly every case, because it keeps the category structure crawlable. Google's pagination guidance asks for a distinct URL per page, such as ?page=2, plain anchor links between pages, and a self referencing canonical on each page. It also notes that Google no longer uses rel next and prev, so do not rely on them.

Infinite scroll and load more buttons feel modern, however Googlebot does not click or scroll. Content that only appears after such an action stays invisible to the crawler unless you provide it through a sitemap or feed as well. Therefore I pair any incremental loading with real paginated URLs underneath, so that both people and crawlers reach item 400.

Above all, do not make page one the canonical of the whole series. Also, for sorted or filtered versions of the same list, Google suggests noindex or a robots.txt block rather than a canonical to page one.

How do breadcrumbs and BreadcrumbList schema strengthen the structure?

Breadcrumbs turn your category structure into something visible on every page. A visitor who lands on a product from search immediately sees where it sits and can step up one level. Likewise, that single row of links repeats the hierarchy to crawlers, so every product reinforces the categories above it.

Google's BreadcrumbList documentation adds a search side benefit. Google uses the markup to categorise the page in results, and a breadcrumb needs at least two ListItem entries to qualify. Interestingly, the same page can carry more than one trail in a category structure. A novel might sit under Books, then Science Fiction, and also under Books, then Literature. Remember those items that split during card sorting? This is where they land.

Implementation is quick, then. Generate the JSON-LD once per template with my schema generator, populate it from the same data that renders the visible breadcrumb, and validate it in the Rich Results Test. Then keep visible and structured breadcrumbs identical; mismatches erode trust in the markup.

How should internal links be distributed on a category page?

A category page has four link jobs, and therefore each needs its own space. First, the menu links to sibling and parent categories. Second, a subcategory block links downward to every child. Third, the product grid links to items, with pagination reaching all of them. Fourth, a cross link area points to related categories that card sorting revealed.

The subcategory block deserves the most care, because it shapes the whole category structure for visitors. Placed above the grid, with an image and a short label per child, it lets a visitor narrow down in one click. It also gives Googlebot a clean path to every subcategory. For this reason I never hide subcategories behind a filter widget alone.

• Menu: parent, siblings and top level categories.
• Subcategory block: every direct child, visible without interaction.
• Product grid: 24 to 48 items per page, all linked with anchors.
• Cross links: three to six related categories, chosen from sorting data.
• Breadcrumb: the full upward path on every page.

Finally, avoid linking to the same category twice with different URLs, such as with and without a trailing slash. Consistency here protects the link value you worked to route.

Do category pages need text and content?

Some, yes, but far less than most stores add to their category structure. A short introduction of 60 to 120 words above or below the grid helps Google understand the intent the page serves. Additionally, it gives you space to mention synonyms customers use. What it should not become is a 1,500 word essay pushed below the products that nobody reads.

Specifically, I write category text to answer three implicit questions. What is in this section? Who is it for? How does it differ from the neighbouring section? For example, a trail running category explains grip, drop and terrain in two sentences, then links to road running and hiking. That text also earns snippets for comparison queries.

Keep the keyword usage natural, too. Run the draft through my keyword density checker and stay well below two percent for the main term. Then let the product names and the subcategory labels carry the rest. Over stuffed category text reads like spam to visitors, and visitors leave.

When are intermediate category pages unnecessary?

When a level contains only one child or fewer than a handful of items. A path like Men, then Footwear, then Shoes, then Sneakers forces two extra clicks for no gain. Instead, merge Footwear and Shoes, or drop one. Likewise, a subcategory with four products should fold back into its parent until the assortment grows.

The Baymard Institute studied 344 large ecommerce sites with more than 275,000 UX performance scores. One finding matters here for category structure: 22 percent of sites fail to show the breadth of their product range on the homepage. Baymard recommends surfacing at least 40 to 50 percent of product types there. Hidden intermediate levels create exactly that blindness.

My rule of thumb from ecommerce work: an intermediate page must earn its place with search demand, a distinct assortment, or a distinct buying question. If it has none of the three, remove it and redirect. Every removed level makes the remaining category structure easier to crawl and easier to scan.

How do you design category navigation for mobile?

Design it for thumbs and short attention, not as a shrunken desktop menu; otherwise the best category structure collapses on a phone. Baymard's research found that 67 percent of mobile sites deliver mediocre or poor navigation performance. In practice, the most common causes I see are the same: mega menus crammed into an accordion, subcategory pages that hide children behind a filter, and no breadcrumb at all.

Instead, I use a layered approach. The hamburger menu shows top categories with clear icons. Tapping one opens a full screen list of subcategories with a back link, never a nested accordion three levels deep. On the category page itself, a horizontally scrolling chip row lists the children above the grid. Breadcrumbs stay visible, even if only the last two levels show.

• One category level per screen, with a visible back action.
• Subcategory chips above the product grid, scrollable sideways.
• Filters in a drawer, with the applied count shown on the button.
• Truncated breadcrumb on small screens, full path in the markup.
• Product count next to each subcategory label to set expectations.

Finally, test every path on a real phone. A structure that scores well in a spreadsheet can still take ten taps in practice.

How do you restructure an existing category tree without losing rankings?

With a redirect map and patience, because rankings live on the old category structure until Google processes the new one. Rankings depend on URLs that earned links and history, so every old category needs a one to one 301 to its closest new equivalent. Blanket redirects to the homepage lose relevance and, as a result, lose positions. Google's crawl budget guidance also lists long redirect chains among the top budget drains, so each hop should be a single jump.

The checklist I use on every migration looks like this.

1. Export every old category and filter URL with its clicks and impressions.
2. Map each one to a new URL, or mark it for a 410 if nothing matches.
3. Implement 301s and verify with my redirect checker that no chain has more than one hop.
4. Update canonicals, internal links and breadcrumbs to the new paths.
5. Regenerate the sitemap with the XML sitemap generator and resubmit it.
6. Watch Search Console crawl stats and index coverage for eight weeks.

Also, launch during a quiet season if you can. Furthermore, keep the old sitemap live for a few weeks so Googlebot revisits the redirected URLs quickly.

What are the most common category structure mistakes?

The same ten errors appear in most audits I run, regardless of platform. None of them require a rebuild to fix; still, together they explain a large share of lost visibility on big sites.

• Categories named after internal departments instead of customer words.
• Filter combinations left open to crawling with no demand behind them.
• Infinite scroll with no paginated URLs underneath.
• Subcategories reachable only through a JavaScript filter widget.
• Page one set as canonical for the entire paginated series.
• Duplicate paths to the same category, with and without a trailing slash.
• Products living in only one category when shoppers look in two.
• Intermediate levels with a single child.
• Breadcrumbs missing on product pages or not matching the markup.
• Redirect chains left behind after a previous restructuring.

Google's general URL structure advice sums up the cure: keep URLs simple, use readable words, and avoid infinite URL spaces such as calendars and unbounded filter combinations. In other words, most of the list above violates that one principle in different costumes.

Which metrics show whether the category structure works?

Three groups of numbers tell the story of a category structure. Crawl metrics show whether Googlebot spends time where you want. Index metrics show whether the right pages made it in. Behaviour metrics show whether people find products. I review all three monthly for large clients, and any one of them can flag a structural fault before revenue drops.

• Crawl stats in Search Console: share of requests hitting parameter URLs versus clean category URLs.
• "Discovered, currently not indexed" count: rising numbers signal budget waste or weak linking.
• Indexed category pages versus intended category pages: the gap should be near zero.
• Category page CTR and average position for non brand queries.
• Average click depth to purchase, measured from analytics path reports.
• Internal search usage: heavy use often means the navigation failed.

When a metric moves, trace it back to one of the five steps. A jump in discovered but not indexed URLs usually means a filter leak from step four. Likewise, falling category CTR often points to labels from step two. If you want a second pair of eyes on the numbers, the service packages include a structural review, and you can reach me directly through the contact page. In short, a sound category structure is not a one time project; it is the map you keep correcting as the catalog grows.