Site Architecture

Site architecture refers to how the pages of a website are organised and linked together. It determines how search engines discover and crawl content, how PageRank distributes across pages, and how users navigate between sections.

A good site architecture serves both crawlers and users: it ensures every important page is reachable efficiently, and it communicates which pages are most significant through their position in the hierarchy and the volume of internal links pointing at them.

Why does site architecture matter for SEO?

Search engines have limited crawl resources for any given site, though for most sites that limit is not what architecture is protecting: crawl budget is a constraint Google scopes to sites of 1 million or more pages, or 10,000 or more whose content changes daily.1 The effect that applies at any size is discovery and link equity. A page buried six clicks from the homepage is reached by a longer discovery path and by fewer internal links, so it accumulates less authority than the same page two clicks from the root.

Architecture also distributes PageRank. Each internal link passes a share of the linking page’s equity to the destination. Pages near the top of a hierarchy, linked from the homepage or major section pages, accumulate more equity than pages deep in the tree. This makes architectural decisions inseparable from keyword targeting: the pages that deserve the highest organic visibility should also sit highest in the architecture.

Flat versus deep architectures

A flat architecture minimises the number of clicks required to reach any page from the homepage, typically aiming for three clicks or fewer. Every important page sits close to the root and receives links from section indexes and the homepage. John Mueller, who hosted Google’s Webmaster Central office hours, said in 2018 that Google does not count the slashes in a URL, and that a page several clicks from the homepage is harder for Google to understand as important. He added a limit in the same answer: linking to every page from the homepage brings little value.2

A deep architecture layers pages behind multiple levels of subcategories. A product might take six clicks to reach: shop, clothing, men’s, casual, t-shirts, then the product itself. Googlebot can reach the page by following that chain, but the page usually has fewer internal links pointing at it than one two clicks from the homepage. The URL does not set the depth: the same product could sit at /products/navy-stripe/ and still be six clicks deep, or at /shop/clothing/mens/casual/t-shirts/navy-stripe/ and be one click deep if the homepage links to it.

Neither structure is inherently wrong. A large e-commerce site with tens of thousands of products needs hierarchy. Ecommerce site architecture is a distinct problem from the general case: category pages, not products, are the durable ranking and link targets, and filter URLs multiply the crawl surface faster than any other site type. The question is whether important category and product pages are as close to the root as the taxonomy allows, or whether they are unnecessarily deep because the navigation grew without architectural planning.

URL structure

URL structure reflects architecture directly. Consistent, predictable URLs make the hierarchy legible to both crawlers and users.

Principles for well-structured URLs, the first two of which are Google’s own recommendations:3

  • Use hyphens to separate words, not underscores or spaces. Google advises against underscores specifically, because programming languages already use them to join words that belong together
  • Keep paths lowercase and consistent. Google’s URL handling is case sensitive, so /APPLE and /apple are distinct URLs with their own content
  • Avoid session IDs, tracking parameters, and dates in URLs for evergreen pages
  • Match URL depth to content hierarchy: section pages one level deep, cluster pages two levels, individual items three

Changing URL structure on an established site requires 301 redirects for every affected path. URL restructuring without redirects destroys accumulated link equity and drops pages from the index.

Subdomains versus subdirectories

The choice between hosting content at blog.example.com versus example.com/blog/ has been debated for years. Google documents no ranking advantage either way, but it does document three places where the hostname is the dividing line. Site diversity “generally treats subdomains as part of a root domain”, though “sometimes subdomains are treated as separate sites” when Google judges it relevant.4 Site names are supported per domain or subdomain and not at subdirectory level.5 And Google’s crawling infrastructure “defines a site as a unique hostname”, so www.example.com and code.example.com carry separate crawl budgets.1 A subdomain is its own unit in the last two always, and in the first only most of the time.

Many SEOs still prefer subdirectories, on the view that links to example.com/blog/article/ build up the main site while links to blog.example.com/article/ stay with the subdomain. Google has not documented links working that way, and its SEO Starter Guide lists subdomains versus subdirectories among the things it believes you shouldn’t focus on.6 Migration case studies, such as the 14 Rand Fishkin, Moz’s co-founder, collected in 2018, report traffic gains after a move to a subfolder, but each compares one site before and after a migration that changed other things too, and moves that lost traffic are rarely written up.7

Use a subdomain when:

  • The content is distinct from the main site and serves a different audience (e.g., a developer API portal, a support knowledge base, a regional site)
  • There are technical or platform reasons that make subdirectory hosting impractical

Use a subdirectory when:

  • The content is on the same topic, for the same audience, as the rest of the site
  • You want it shown under the main site’s name in search results, since Google sets site names per domain or subdomain, not per subdirectory5
  • Nothing forces a subdomain: a subdirectory is the simpler default, with one hostname to configure and monitor

A reverse proxy can serve a forced subdomain as a subfolder

Some hosted platforms only connect to your domain as a subdomain. Say your main site is example.com, and your help centre runs on a hosted help-desk product whose setup screen offers one option: point help.example.com at it. The same happens with hosted blogs and careers systems. The subdirectory-versus-subdomain decision looks made for you, but it is not. A reverse proxy is a server rule that fetches a page from somewhere else and serves it under your own address: a visitor or crawler requests example.com/help/, your server fetches the page from the help-desk platform behind the scenes, and the address bar never changes. This is ordinary CDN and web server configuration rather than a workaround.

Two conditions decide whether it works. Every internal link, canonical tag and sitemap URL the platform generates has to use example.com/help/ rather than help.example.com, or both versions end up live and competing. And once the proxy is in place, the platform's own address needs blocking from indexing or redirecting, so it cannot be crawled as a parallel copy.

Siloed architecture

A silo organises content into topically coherent groups. Pages within a silo link to each other and to the top-level section page, but have minimal links to unrelated silos. This concentrates topical relevance signals on section pages and category hubs.

In practice, most well-run content sites implement a looser version: a pillar page covering a broad topic, supported by cluster pages on subtopics, with internal links flowing primarily within each cluster. This pattern works for both topical relevance and crawl efficiency without requiring rigid silo enforcement that blocks natural editorial cross-linking.

The topic cluster model and its planning implications are covered in topic clusters and pillar pages.

Internal links are the primary mechanism through which architecture transmits authority. A page with many internal links from high-authority pages accumulates more equity than one with few or weak links, regardless of its URL depth.

Key architectural link patterns:

  • Hub pages (category indexes, pillar pages) should link to every important child page within their section
  • Homepage should link directly to the highest-priority section hubs
  • Breadcrumb navigation provides consistent structural links that help crawlers and users understand the hierarchy
  • Footer links to major sections distribute crawl priority globally, but are discounted compared to editorial in-body links

Orphan pages, those with no internal links pointing to them, receive no crawl priority signal and no internal equity. Even high-quality content on an orphaned page will be crawled infrequently and rank below its potential.

Don't bury evergreen content in a chronological blog

Evergreen content published as a blog post starts near the top of the listing, then gets pushed further down as newer posts appear. More clicks from the homepage means fewer internal links, lower crawl frequency, and less accumulated authority. That is the opposite of what you want for a page intended to rank for years. If a piece of content should remain valuable and visible long-term, give it a permanent home in a section hub or pillar structure rather than a blog slot that deprioritises it within months of publication.

How do you audit site architecture?

Signs that architecture needs attention:

  • Important pages sit unnecessarily deep relative to the taxonomy, more clicks from the homepage than their level warrants
  • Category or section pages are rarely crawled according to server logs
  • URL structure is inconsistent across sections, with mixed depth and naming conventions
  • Orphan pages appear in log analysis (crawled by Googlebot but not linked from any other page)
  • Internal link equity concentrates on low-value pages (e.g., the contact page or 404 handler)

A crawl tool such as Screaming Frog can map click depth, identify orphaned pages, and flag structural inconsistencies across a site. Log file analysis shows which pages Googlebot actually visits and how frequently, which reveals real crawl prioritisation regardless of how the theoretical architecture looks.

For a full site architecture audit checklist, see the Technical SEO Audit Checklist.

Footnotes

  1. Optimize your crawl budget — Google Search Central ↩ ↩2

  2. English Google Webmaster Central office-hours hangout, 1 June 2018 — Google Search Central on YouTube, from 31:09. ↩

  3. Keep a simple URL structure — Google Search Central ↩

  4. A guide to Google Search ranking systems — Google Search Central ↩

  5. Site names in Google Search — Google Search Central ↩ ↩2

  6. SEO Starter Guide — Google Search Central, “Things we believe you shouldn’t focus on” section. ↩

  7. Subdirectories vs subdomains: which is better for SEO? — Portent, which summarises Rand Fishkin’s March 2018 thread of 14 case studies. ↩