Architecture is the part of technical SEO that is hardest to change later and easiest to get wrong early, usually because it's decided by whoever set up the CMS, not by anyone thinking about search. This sub-guide of my technical SEO guide covers the structural decisions that determine whether Google understands what a site is about and which pages matter most.
What architecture has to achieve
A good architecture does four things at once. It makes every important page reachable in a few clicks. It groups pages so related content reinforces itself and Google can see topical boundaries. It concentrates authority on the pages that should rank. And it keeps the number of crawlable URLs close to the number of pages you actually want indexed.
None of those is about URL keywords or folder names. Those matter a little. Links and grouping matter a lot.
Hierarchy versus flat
A hierarchical architecture nests pages: Home, then sections, then subsections, then individual pages. Described as a diagram, it's a tree: a single root, a handful of branches, each branch splitting again, leaves at the end.
- Home
- Section (e.g. Learn SEO)
- Hub (e.g. Technical SEO)
- Sub-guide (e.g. Site Architecture)
A flat architecture links to (almost) everything from the top level. Described as a diagram, it's a hub and spokes: one centre, hundreds of lines radiating out, every page one click from the homepage.
Neither is right in the abstract. Flat works for small sites (under a few hundred pages) where everything can plausibly be one or two clicks away. Hierarchy becomes necessary once a flat structure would mean navigation with hundreds of links, which dilutes everything and tells Google nothing about relationships. What I actually build is a shallow hierarchy: strict grouping, with hubs and cross-links keeping almost every page within three or four clicks of the homepage. Depth comes from grouping, not long chains.
URL structure
URLs should mirror the hierarchy, be readable, and stay stable. That's the whole rule. /learn-seo/technical-seo/site-architecture/ tells a reader and a crawler where the page sits. /p?id=48213 tells them nothing. /learn-seo/technical-seo/site-architecture-for-seo-guide-2026/ tells them something and then has to change next year.
Conventions I apply consistently: lowercase, hyphens between words, no file extensions, one trailing-slash policy, no dates in URLs for evergreen content. Folders should reflect genuine groupings; a folder with one page in it isn't a grouping. And once a URL is indexed, changing it costs something every time, so pick it as if it's permanent.
Hub pages: the structural core
A hub page represents a group: a category in ecommerce, a topic page on a content site, a product-line page in SaaS. It links down to every page in its group and is linked from every page in the group, from the main navigation, and from related hubs. In a diagram it's the node with the most lines attached: the centre of each local cluster.
Hubs do three things no other page can. They give Google a single place that defines the topic, the foundation of topical authority. They let you add a hundred pages to a cluster without the navigation changing, because the hub absorbs the links. And they usually carry the biggest search demand, because they match the broad head terms. The topic clusters guide covers the content side; structurally, every group has a hub, every page knows its hub, and hubs link to each other where topics overlap.
Click depth
I treat click depth as the primary health metric of an architecture. A crawler reports it directly (and it is measured in links, not URL folders). The question is not "what's the maximum" but "what sits at each depth". Pages that need to rank should be at depth one to three; depth four is acceptable for long-tail pages. Anything important at depth five or beyond is a structural failure, fixed by adding a subcategory layer, a hub that links directly to the deep pages, or cross-links from related pages. The linking mechanics are in the internal linking guide and the systematic version in my internal linking framework.
Pagination and faceted navigation
Pagination
Pagination splits a long list across pages. The architecture question is how deep it goes. A category with 2,000 products at 24 per page is 84 pages deep, so the last product is dozens of clicks from the category hub. The fix is not clever pagination markup. It's shorter lists: more subcategories, filters with real demand promoted to landing pages, and larger page sizes where the page can handle it. Each paginated page should self-canonicalise (see canonical tags) and link to a range of neighbouring pages, not just "next".
Faceted navigation
Facets (filters by brand, size, colour, price, rating) are the biggest architectural hazard on ecommerce and listing sites because they generate crawlable URLs combinatorially. The policy I design has three tiers.
| Tier | Which facet combinations | Treatment | Example |
|---|---|---|---|
| Landing pages | Single facets or pairs with real, distinct search demand | Clean static URL, self-canonical, in the sitemap, linked from the hub and the facet menu, unique title and intro | /sarees/silk/ or /laptops/under-50000/ |
| Crawlable but consolidated | Combinations users need but nobody searches for | Parameter URL, canonical to the nearest landing page or parent category | /sarees/silk/?colour=red&sort=price |
| Not crawlable | Sort orders, price sliders, multi-select beyond two facets, view modes | Blocked in robots.txt by parameter pattern, or rendered without crawlable links, or both | ?sort=, ?view=, ?page_size=, ?min_price= |
Which combinations go in tier one is a keyword research decision, made before the facet system is built. Retrofitting a policy onto a live faceted site is possible, but it is a migration of thousands of URLs; see below.
Taxonomy design
Taxonomy is the set of categories and attributes used to classify pages. Architecture is built on it, so a bad taxonomy produces a bad architecture no matter how well you link. My principles: every page has exactly one primary category; categories are named the way people search, not the way the business is organised internally; attributes (tags, filters) cover cross-cutting properties and never duplicate categories; and tag pages are only indexable when they have enough items and real demand.
The failure mode I see most is the overgrown tag system: a blog with 40 categories and 3,000 tags, most with one post, each indexable. That's index bloat created by taxonomy, and it needs pruning before anything else works.
Architecture patterns by site type
Ecommerce
Home → category → subcategory → product, with facet landing pages as a parallel layer under each category and guides linked from the categories they support. The design problem is keeping products within four clicks and facets under control. See the ecommerce SEO guide.
SaaS
Three surfaces: product and feature pages, use-case or industry pages, and a learning hub (guides, docs, integrations, comparisons). Features and use cases cross-link; the blog feeds hubs rather than being a flat chronological list. See the SaaS SEO guide.
Publishers
Topic hubs, not date archives, as the structural spine. Every article belongs to a topic hub and links to related evergreen pieces. Older articles must stay reachable through topics, because chronological pagination buries them within weeks.
Programmatic
Entity-driven: a hub per entity type (city, category, integration), pages generated from data, and links generated from the relationships in that data. The structure is the dataset. I tested the template design in the programmatic page templates experiment; the programmatic SEO guide covers when this is justified at all.
Migrations: changing architecture without losing what you've built
Every architecture change on a live site is a migration, whether a redesign, platform move, URL restructure or taxonomy overhaul. The risk is losing the signals attached to existing URLs. The method is unglamorous and works.
Inventory every URL that matters
Crawl, sitemap, analytics, Search Console and backlink data combined. URLs with traffic, rankings or external links are non-negotiable to preserve.
Design the new structure on paper first
Hubs, depth, URL patterns, facet policy, taxonomy. Check click depth for the top pages before any code exists.
Map old to new, one to one
Every old URL gets a single 301 to its best equivalent. Redirecting everything to the homepage is signal loss, not a redirect.
Update internal links, not just redirects
Templates, navigation, body links and sitemaps point at the new URLs directly. Redirects are for the outside world and Google's memory, not a substitute for correct links.
Test on staging with a crawler
Check canonicals, depth, redirects and that needed resources aren't blocked. Compare against the inventory.
Launch, then monitor by template
Watch crawl stats, page indexing and the redirect map for weeks. Expect some volatility; what you're looking for is any template group that isn't recovering.
The technical SEO and content architecture case study walks through a restructure of this kind end to end.
Frequently asked questions
Is a flat site architecture better for SEO?
For small sites, flat works well because everything is close to the homepage. For larger sites, flat means bloated navigation and no topical grouping, which hurts. The practical goal is a shallow hierarchy: clear groups with hubs, and important pages within three or four clicks.
Do keywords in URLs still matter?
A little, mostly for readability and click-through. A descriptive URL that mirrors the hierarchy is good practice. Changing live URLs to add keywords is not worth the migration risk.
Should I use subfolders or subdomains for a blog or regional section?
Subfolders, in almost every case. Google treats subdomains as more separate, so a blog on blog.example.com shares less with the main site than one at example.com/blog/. Use subdomains only where a genuinely separate product or technical constraint demands it.
How many clicks from the homepage is too many?
There's no hard limit, but pages beyond four or five clicks are crawled less and inherit little authority. Pages that need to rank should sit at depth one to three. If a crawler shows important pages deeper, restructure with hubs or subcategories.
Can I fix architecture without a full redesign?
Often, yes. Adding hubs, introducing subcategories, fixing facet rules, pruning tags and adding cross-links can all be done within an existing design and CMS. A full migration is only needed when the URL structure or platform itself is the problem.
Where this connects
This guide is part of the technical SEO hub. Architecture and depth checks are a core section of my technical SEO audit framework; template-level structure at scale was tested in the programmatic page templates experiment; the technical SEO and content architecture case study shows a restructure end to end; and designing and implementing architecture is part of my technical SEO services.