Site Architecture

Site architecture is the organizational blueprint of a website: how content is grouped into sections, how those sections nest, and how many steps it takes to get from the homepage to any given page. It's the difference between a site that's a library and a site that's a storage unit.

Why it carries real stakes: architecture is the most expensive thing to change later. Content can be rewritten in a week; a URL hierarchy baked into ten thousand pages, their redirects, and their accumulated backlinks is a migration project with real risk attached. Architecture decisions also compound — they determine crawl efficiency, whether topical authority consolidates or scatters across duplicate sections, and whether adding your next thousand pages is trivial or a re-plan. Nail it early and every later job gets easier; botch it and you'll be paying interest for years.

Scope note: architecture is the plan — the taxonomy and hierarchy. Two adjacent topics implement it: URL structure is how the plan shows up in your addresses, and internal linking is how it's wired page-to-page. This page stays at the blueprint level.

What a deliberate hierarchy looks like

A mid-size outdoor gear retailer, planned as topic-first taxonomy rather than mirroring the org chart or the warehouse system:

Home
├── /camping/                 ← pillar category
│   ├── /camping/tents/       ← subcategory (its own search demand)
│   │   ├── /camping/tents/4-season/
│   │   └── product pages
│   ├── /camping/sleeping-bags/
│   └── /camping/guides/      ← supporting content, linked into commerce pages
├── /climbing/
│   ├── /climbing/ropes/
│   └── /climbing/harnesses/
└── /brands/                  ← cross-cutting facet, one canonical home

Three properties make this work. Every level exists because it has its own search demand (people search "4 season tents," so it's a page — not a filter). Supporting content lives inside the section it supports, so guides and the products they inform reinforce each other. And cross-cutting dimensions like brand get exactly one canonical location instead of spawning a parallel duplicate tree ("/brands/msr/tents/" competing with "/camping/tents/?brand=msr").

Flat vs. deep — the honest tradeoffs

"Keep everything 3 clicks from home" is repeated like scripture, but the right shape depends on how much content you have. A flat structure at scale isn't flat, it's a pile.

That distinction in the third row matters more than any rule of thumb: hierarchy depth is how the taxonomy nests; click depth is how many clicks a crawler needs. A five-level taxonomy with good hub pages and cross-linking can keep most URLs within four clicks. A two-level "flat" site with pagination as its only discovery path can bury page 40 of an archive twenty clicks deep.

How to check it on your own site

1. Crawl the site in Sitebulb and open the crawl map — the radial visualization. Healthy architecture looks like an organized tree with distinct clusters; problems show up visually as hairballs, disconnected islands, and long stringy chains of pagination.
2. Chart the click-depth distribution (Sitebulb and Screaming Frog both report it). Rule of thumb from audits: if a meaningful share of pages you want ranked sits at depth 5+, discovery is throttling them.
3. Pull your top-visited and top-converting pages from analytics and locate each in the hierarchy. If your best performers live in weird corners ("/blog/2019/03/random-slug/") while polished section homes get nothing, the architecture doesn't match reality — reality wins, re-plan around it.
4. Check for parallel trees: site-search a few products or topics and count how many distinct URL paths can reach the same content (category path, brand path, tag path, search-page path). More than one indexable path per item means diluted signals.
5. Map query demand against the hierarchy: every subcategory should correspond to real search demand, and every high-demand topic should have exactly one home. Gaps and doubles are both findings.

Common mistakes

• Mirroring the org chart. "/solutions/", "/products/", "/services/" all containing overlapping content because three departments each wanted a section. Searchers don't know your org chart. Organize by topic demand, not by internal ownership.
• Tag and category systems running wild. WordPress sites with 900 tags, each generating an indexable archive with 1–2 posts. That's 900 thin pages competing with your real pages. Prune to the taxonomies you'd deliberately design, noindex or delete the rest.
• Hub pages that are just link lists. A category page that's nothing but a grid of children ranks like nothing but a grid of children. Hubs need their own content: intro copy that actually helps, links to the best children, supporting guides.
• Restructuring URLs when only linking needed fixing. Teams reach for a full URL migration to "fix architecture" when the taxonomy was fine and the problem was orphaned sections and weak hubs. Exhaust linking fixes before touching URLs — one is an afternoon, the other is a risk event.
• Designing for the current size forever. The architecture that fits 200 pages chokes at 5,000. Ask "where will the next 5,000 pages of this type go?" before publishing the first 50. The planning frameworks in enterprise site architecture planning apply in miniature to smaller sites too.

For a checklist-style treatment, the 15 site architecture tips master guide covers the tactical layer, and there's a documented rebuild with results in the SL Development architecture case study.

FAQ

Is the "three-click rule" real?

As a law, no — Google has said click depth matters but there's no cliff at three. As a discipline, yes: pages that are hard to reach get crawled less and inherit less authority. Treat "keep important pages shallow" as the rule and the number as a budget you negotiate per site size.

Do subfolders beat subdomains?

For sections of one site (blog, shop, guides), default to subfolders — consolidation of signals is the practical winner in most migrations I've seen measured. Subdomains make sense when the thing genuinely is a separate product with separate infrastructure needs.

How is site architecture different from internal linking?

Architecture is the noun, linking is the verb. The taxonomy defines where pages belong; links make that structure real to crawlers. You can have a beautiful taxonomy that's invisible because nothing links laterally — and a mediocre taxonomy rescued by excellent linking.

When is it worth a restructure migration?

When the architecture actively caps growth: duplicate parallel trees, sections that can't scale, or hierarchy that doesn't match demand at all. Not for cosmetic URL preferences. A restructure means redirects, temporary volatility, and re-crawling costs — the upside has to be structural, not aesthetic.

Where do faceted navigation pages fit into architecture?

Treat facets as candidate pages, not automatic ones. A facet combination earns a place in the architecture when it has search demand and distinct inventory ("waterproof hiking boots"), and gets canonicalized or blocked when it doesn't ("size 9.5, blue, under $80, sorted by rating"). The handling mechanics are on the URL parameters page.