SEO site architecture defines how pages are grouped, named, linked and maintained so people and search systems can understand the website. It is not a diagram of departments and it is not a demand that every page sit three clicks from the homepage.

A strong architecture reflects user tasks, content relationships and organisational capability. It creates stable paths to important pages while controlling duplication and change.

Inventory the current system

Before designing a new hierarchy, collect:

  • canonical URLs and status codes;
  • page type and template;
  • title, description and primary heading;
  • parent and navigational path;
  • internal links in and out;
  • sitemap inclusion;
  • organic landings and conversions;
  • backlinks or important external references;
  • owner, publication state and last meaningful update;
  • known duplicates and redirect history.

Combine crawls, analytics, search data, CMS exports and server information. The result is a URL inventory, not yet an architecture decision.

Model user tasks and objects

Users navigate through concepts the organisation provides: products, services, problems, locations, topics, records, people and support tasks. Identify these objects and their relationships.

For an ecommerce site:

department → category → subcategory → product

For a SaaS site:

problem → solution → capability → integration → documentation

For a government service:

life event → service → eligibility → application → support

These are starting models, not mandatory URL shapes. A page can participate in several journeys while retaining one canonical location.

Give every page a role

Define a small set of page types and what each does:

  • hub or department page;
  • category or collection;
  • product or service;
  • guide or explanation;
  • comparison or selection aid;
  • tool or database;
  • documentation or support;
  • location or market page.

For each type, document required fields, internal-link behavior, indexability, structured data, ownership and retirement rules. Architecture becomes reliable when templates enforce relationships rather than relying on editors to remember them.

Design parent-child relationships

A parent should help users understand and navigate its children. A category with only a heading and a list of links may be functional, but important collections often need selection criteria, scope and context.

Avoid creating a hierarchy deeper than the information requires. Extra folders and landing pages add maintenance without creating meaning. Also avoid a flat system where thousands of unrelated pages depend on the homepage.

Questions for each parent:

  • Does it represent a real user concept?
  • Does it help choose among children?
  • Can it remain useful as the site grows?
  • Is there a responsible owner?
  • Does it have distinct value from its children?

Navigation establishes broad structure. Contextual links explain specific relationships and next steps.

Use:

  • global navigation for primary tasks;
  • local navigation for a section or workflow;
  • breadcrumbs for hierarchical context;
  • contextual links within useful text;
  • related-content modules with explicit logic;
  • pagination for ordered collections;
  • HTML links with stable destinations.

Anchor text should describe the destination naturally. Avoid generic “read more” links when the relationship can be clear. Do not hide important navigation behind scripts that do not render crawlable anchors.

Treat click depth as evidence, not doctrine

Important pages should be reasonably accessible, but a universal three-click rule ignores site scale and user behavior. Measure depth by page type and priority. Investigate why a valuable page is buried or orphaned.

A low-value archive page can be deeper than a priority service. A product reachable only through internal search may need a category path. The architecture should distribute attention intentionally.

Keep URLs stable and readable

URLs should be persistent identifiers. Google’s URL structure guidance recommends simple, descriptive URLs and consistent conventions.

Good operating rules include:

  • lowercase paths;
  • words separated consistently;
  • no volatile session or tracking data in canonical URLs;
  • one protocol and hostname;
  • controlled parameters;
  • no unnecessary date or department segment that will age poorly;
  • permanent redirects when a published path must change.

The URL does not need to reproduce every level of navigation. A page can move between departments while keeping a durable path.

Control faceted navigation

Filters improve user choice and can create an uncontrolled crawl space. List all parameters and decide which states are:

  • indexable landing pages with verified demand and distinct value;
  • crawlable user states that should not be indexed;
  • non-crawlable interactions;
  • invalid combinations that should not return successful pages.

Align internal links, canonicals, robots controls and sitemaps with those decisions. Do not canonicalize every filter to the unfiltered category if some filtered pages are deliberately intended to rank.

Design for multiple languages and markets

International architecture begins with service capability. Decide whether language, country or both define the experience. Use stable locale URLs and connect true equivalents with valid language annotations.

Local pages need material differences when product, regulation, terminology or support changes. Do not manufacture one page per location by swapping a city name.

Prevent orphaning and cannibalization

An orphan page has no meaningful internal path even if it appears in a sitemap. Compare the URL inventory with the internal crawl and add a relationship or retire the page.

Cannibalization is not simply two pages containing the same keyword. It becomes a problem when several pages compete to serve the same task without distinct roles. Resolve it by:

  • consolidating evidence;
  • differentiating audience or intent;
  • selecting one primary destination;
  • updating internal links;
  • redirecting a retired duplicate to the true successor.

Plan migrations as architecture changes

Redesigns and CMS moves often change paths because the new system prefers a different structure. Challenge whether the change creates user value. Stable URLs preserve external references, bookmarks and operating history.

When change is justified:

  1. freeze and verify the current inventory;
  2. map every material old URL to its closest equivalent;
  3. test redirect chains and status codes;
  4. update internal links, canonicals and sitemaps;
  5. preserve important metadata and content purpose;
  6. monitor by page type and market;
  7. keep redirects for as long as old references remain relevant.

Do not redirect unrelated retired pages to the homepage merely to avoid a 404.

Measure architecture health

Useful measures include:

  • indexable URLs by approved page type;
  • orphan and dead-end pages;
  • depth distribution for priority pages;
  • internal links to key hubs and leaves;
  • duplicate and parameter URL growth;
  • crawl activity by useful and wasteful surface;
  • successful discovery of new pages;
  • user completion paths and navigation failures;
  • broken links and redirect chains;
  • pages without an owner or maintenance date.

Metrics should lead to an architecture decision. A high link count is not automatically good if links are repetitive or irrelevant.

Maintain an architecture register

Record new URLs, redirects, consolidations and removals before release. Require approval for permanent path changes. Keep the canonical inventory, sitemap source and redirect registry aligned.

For each new page, document its role, parent, internal entry points, owner, evidence, indexability and retirement condition. This prevents the site from returning to an ungoverned pile of URLs after the redesign is complete.

Site architecture is a maintained model of the organisation’s useful information. It succeeds when people can predict where to go, search systems can follow stable relationships and teams can change the site without discarding its history.