Website Structure & Navigation

Information architecture: organise before you design

Information architecture is simply the practice of organising a site's content into a logical structure before deciding what anything looks like. It answers three questions: what pages exist, how are they grouped, and how does someone move between them. Skipping this step is exactly how sites end up with a navigation bar that grew one item at a time until it no longer makes sense to anyone but the person who built it.

Working from the sitemap built in Chapter 1, group related pages into a small number of top-level sections — typically four to seven. A visitor should be able to guess which section a piece of content lives in before they even click, because the grouping matches how they already think about the business, not how the business is organised internally.

The two-or-three click reality

A useful design constraint: almost any page on the site should be reachable within two or three clicks from the homepage. This is not an arbitrary rule — it reflects how people actually browse. Each additional click is a chance for a visitor to lose patience, get distracted, or simply give up and search for something else. A shallow, well-grouped structure keeps that click depth low without cramming everything into one giant navigation menu.

Primary nav vs footer nav — what belongs where

The main navigation bar is prime real estate and should be treated that way. It belongs to the handful of destinations a visitor is most likely to need immediately: core service or product categories, an about or credibility page, and a contact path. As a rough ceiling, once the primary nav needs a horizontal scroll or a cramped font to fit everything, it has too many items — group some of them under a dropdown, or move the less time-critical ones out entirely.

The footer is where the rest of the site's structure lives without competing for attention: policy pages, a sitemap link, social profiles, secondary resources, and any page that matters for completeness or trust but is not something most visitors need on their way in. A well-built footer effectively works as a backup navigation system — many visitors scroll straight to it looking for exactly this kind of page.

URL structure basics

URLs should describe where a page sits in the structure, in plain words a visitor could guess. A URL like /services/website-design/ tells both a visitor and a search engine exactly what the page is and where it fits, long before the page even loads. A few habits keep this clean:

• Use lowercase words separated by hyphens, not underscores or spaces (website-design, not Website_Design or websitedesign).
• Keep URLs reasonably short and skip filler words that add no meaning.
• Match the URL folder structure to the site's actual information architecture where practical, so /services/ genuinely contains service pages.
• Decide the structure early — changing URLs after launch means setting up redirects (covered in Chapter 9) to avoid breaking links and rankings.

Avoiding orphan pages

An orphan page is any page with no internal link pointing to it from anywhere else on the site — reachable only by typing the exact address, or not reachable at all. They accumulate quietly: a landing page built for one campaign, an old blog post that fell out of the main list, a policy page linked only from a footer that got redesigned. Orphan pages are invisible to most visitors and hard for search engines to find any reason to trust.

The fix is a habit rather than a one-time task: whenever a new page is published, deliberately link to it from at least one relevant, already-indexed page — a related article, a category page, or the navigation itself. Periodically auditing the site (clicking through every link in the main nav and footer, and checking that every page in the sitemap has at least one inbound link from somewhere else on the site) catches the ones that slip through.