Site Architecture
Last updated
Site architecture refers to how the pages of a website are structured, 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,1 though for most sites that limit is not what architecture is protecting: crawl budget only becomes a practical constraint at hundreds of thousands of URLs. 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, receives links from section indexes and the homepage, and is regularly crawled.
A deep architecture layers pages behind multiple levels of subcategories. A product might sit at /shop/clothing/mens/casual/t-shirts/navy-stripe/: six levels deep. Googlebot can reach this page, but it requires many hops, receives fewer internal links, and carries less accumulated authority than the same page at /shop/t-shirts/navy-stripe/.
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:2
- 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
/APPLEand/appleare 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.3 Site names are supported per domain or subdomain and not at subdirectory level.4 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.
In practice, subdirectories tend to consolidate authority more reliably. Links pointing to example.com/blog/article/ contribute to the authority of example.com as a whole. Links pointing to blog.example.com/article/ build authority on the subdomain, which most third-party tools treat as a separate entity from the main domain.
Use a subdomain when:
- The content is genuinely 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 area and should build authority for the main domain
- You want link equity from that section to compound with the rest of the site
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 link architecture
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.