Site architecture is the information design layer of SEO: how URLs are structured, how pages group into sections, and how navigation exposes them. Good architecture makes every other optimization more effective; bad architecture quietly caps how far a site can rank, regardless of content quality.
URL design#
URLs are read by users (in SERPs and link previews), by engines (as a relevance hint), and by you (in analytics forever). Design them once, correctly:
GOOD https://example.com/guides/technical-seo/crawl-budget
lowercase · hyphens · hierarchical · descriptive · stable
BAD https://example.com/index.php?id=4302&cat=7&ref=nav
opaque · parameterized · fragileRules that age well:
- Lowercase, hyphens, ASCII. Mixed case creates duplicate-content URLs on case-sensitive servers.
- Reflect hierarchy (
/guides/technical-seo/...): it feeds breadcrumbs, lets you measure sections, and communicates structure. - Keep slugs short and descriptive; skip filler words.
- No dates in evergreen slugs.
/blog/2019/05/postlooks stale forever and breaks on republish. - Stability is the prime directive. Google says 301 redirects don't lose PageRank, but every URL change still costs recrawling time, redirect upkeep and broken external links you can't fix. Choose patterns you can keep for a decade (see Site Migrations).
The hierarchy and click depth#
Architect as a pyramid: homepage → section hubs → detail pages. Two structural rules of thumb (industry practice rather than a Google rule):
- Important pages within about three clicks of the homepage. Pages buried deep get crawled less often and receive less internal link equity.
- Flat beats deep, until hubs lose meaning. A thousand pages linked straight from the homepage is not architecture; group them into meaningful hubs that can themselves rank for category terms (your pillar pages).
Navigation should expose the hierarchy: primary nav for sections, breadcrumbs, contextual links within content (Internal Linking), and hub or index pages for long-tail discovery.
Breadcrumbs are still worth it, but expectations changed: since 2025-01-23 Google no longer shows breadcrumb trails in mobile results (the mobile URL line shows only the domain). Desktop results still use them, and BreadcrumbList markup remains supported (Structured Data).
Pagination#
For lists spanning multiple pages (/blog?page=2 or /blog/page/2):
- Give each page a unique, self-canonical URL. Don't canonicalize page 2+ to page 1: that asks Google to ignore everything past page one, orphaning deep items.
- Link pages sequentially with plain
<a href>anchors (previous/next plus numbered links). Google does not userel="prev"/rel="next"; the tags are harmless but they don't replace real links. - Prefer "load more" backed by real URLs over infinite scroll that exists only in JavaScript. Items reachable only by scripting are invisible to crawlers that don't render (JavaScript SEO).
Faceted navigation: the crawl trap#
Filters and sorts (?color=red&size=m&sort=price) can mint millions of URL combinations from one category: the classic crawl budget catastrophe for e-commerce. Google's faceted navigation guide (moved to the crawling docs in December 2025) gives the containment options:
| Facet type | Treatment |
|---|---|
| High-demand combinations ("red running shoes") | Indexable landing pages with clean URLs, internal links and sitemap entries |
| Everything else | Block crawling with robots.txt Disallow patterns, or implement the filter with URL fragments (#color=red), which Google ignores |
| Sorts, view options, session parameters | Never crawlable; keep them out of internal links where possible |
rel=canonical and rel=nofollow on facet URLs are fallbacks: Google calls them "generally less effective in the long term". And don't combine them with a Disallow on the same URLs: a blocked page is never fetched, so its canonical is never read.
If you do let some facets be crawled, Google asks for the standard & separator, a consistent filter order and a real 404 when a filter combination has no results. Decide which combinations have real search demand (your keyword map answers this) and let only those exist as crawlable URLs. The crawl budget guide explains why this matters mostly for large sites.
Subdomain vs. subdirectory#
The eternal question: blog.example.com vs example.com/blog. Google's John Mueller has said repeatedly that both work for Search. Our opinion, shared by most practitioners: prefer subdirectories for content that should reinforce the main site, because it is simpler to manage as one site, one Search Console property and one link profile, and consolidation tends to measure better in case studies. Use subdomains for genuinely separate applications (app., status., docs for a different product).
Internationalization (hreflang)#
If you serve multiple languages or regions, hreflang tells engines which variant to show to whom:
export const metadata = {
alternates: {
languages: {
"en-US": "https://example.com/en",
"de-DE": "https://example.com/de",
"x-default": "https://example.com/en",
},
},
};Rules: annotations must be bidirectional (each variant lists all others, including itself), each variant must be indexable, and x-default covers everyone unmatched. Half-implemented hreflang is the most common international SEO defect. The full treatment is in International SEO.
Next: Core Web Vitals, the performance metrics that are also ranking signals.