Website structure and information architecture

Website structure is the set of decisions about which pages exist, what each one is called, how they nest inside one another, and how a reader moves between them. It is settled before anything is designed and before anything is written, because both of those depend on it.

Structure is also the thing most quotes price by proxy. A supplier who asks “how many pages?” is asking a structure question in order to produce a number, and a buyer who answers with a guess has priced their own project without meaning to. That is why this section exists in a section about commissioning websites rather than in a section about design theory.

What information architecture guides are in this section

What a sitemap is — the document that lists every page and its parent, and the difference between the one you agree with a supplier and the one a search engine reads.

How many pages a small business website needs — how a page count is actually derived, and why the number is an output of scope rather than an input to it.

The pages every business website needs — the standing set, what each page has to contain to earn its place, and the measured fact that nobody asks an AI assistant this question.

Service pages or one services page — the single most common structural decision, and the test that settles it.

Navigation depth and the three-click idea — where the three-click rule came from, why it is not a rule, and what actually matters about depth.

Naming pages people search for — why internal vocabulary in a navigation bar costs enquiries, and how to choose between the two.

URL structure — what a URL communicates, what makes one stable, and the cost of changing one later.

Service area page structures — how to build location coverage without producing pages that say nothing, which is a real risk rather than a theoretical one.

Footer and utility navigation — what belongs below the fold on every page, and why the footer is where legal obligations usually land.

Why website structure and information architecture is decided first

Three things depend on the structure and cannot be settled before it.

The quote. Scope is expressed as pages and features. A quote written against an unfixed structure is an estimate against an unknown, which is why it moves.

The content. Somebody has to write the words for each page. Until the pages exist as a list, nobody can be given a writing task, and content is the most common reason a build stalls.

The design. A page template is a design for a type of page. You cannot decide how many templates a project needs until you know what types of page there are.

Card sorting: a simple way to test your information architecture before building it

Card sorting is the standard information architecture technique for checking a structure against how actual users think, rather than how the business is internally organised: write each candidate page or topic on a card, and ask a handful of people unfamiliar with the business to group the cards into categories that make sense to them and label each group in their own words. The resulting categories rarely match the org chart, and the labels people choose are usually plainer and more specific than the ones a business would pick for itself — both are useful signals for naming navigation items and deciding how hierarchical the resulting tree of pages needs to be. It does not replace anything in this section; it is a cheap way to test a draft structure’s taxonomy before a supplier builds against it.

Taxonomy, hierarchical categories and sitemaps: organising principles behind navigation

Beneath card sorting sits a smaller set of organising principles that decide how a sitemap actually takes shape. Taxonomy is the system of categories a structure is grouped under. A shallow, broad taxonomy usually serves users better than a deep, narrow one, because a visitor should not need to guess which branch of a hierarchical tree a page sits under. Labeling — the actual words used for each category — matters as much as the grouping itself, since a technically correct label a visitor does not recognise defeats the navigation it sits in. These principles apply whether the sitemap has nine pages or ninety, and whether the site serves consumer users or a business audience; only the number of categories needed to hold them changes.

The failure modes this section is written against, from a users’ point of view

Failure	What it looks like	Where it is dealt with
Page count guessed	“Let’s say ten pages” in the first meeting	How many pages a small business website needs
Structure inherited from a template	Pages exist because the theme had them	The pages every business website needs
Everything on one page	A single services page listing nine services	Service pages or one services page
Internal vocabulary in the nav	A menu item nobody outside the business understands	Naming pages people search for
Location pages with nothing local	Twelve suburb pages differing only in the suburb name	Service area page structures
URLs that encode the platform	Addresses that break when the platform changes	URL structure

Each of those is cheap to fix before a build and expensive afterwards, because after launch every one of them has links, bookmarks and search results pointing at it.

How this structure and information architecture connects to the rest of the site

Structure is one of the parts named on what web design actually covers. The count it produces is one of the inputs to what drives the cost of a website, and the document it produces is the same document the project brief generator asks you to write.

If you are scoping a first website rather than restructuring an existing one, what a small business actually needs is the better place to start, and this section is the detail underneath it.

What to do next with your site’s information architecture

Write the list of pages you think you need on one sheet of paper, with a one-line statement of what each page is for. Take it to the supplier before you ask for a price. If the supplier changes it, that is a useful conversation. If the supplier does not look at it, that is also useful information.