People rarely arrive at a website knowing how its owner has organised the business. They arrive with a question: can you solve my problem, how much information do I need, and what should I do next? Website information architecture translates those questions into pages, navigation, and connections that visitors can understand.
A visually impressive website can still be difficult to use when services overlap, navigation labels are vague, or important answers live several clicks away. This guide explains how to plan a practical structure for a business website before investing in layouts or animations. It focuses on decisions that a business owner and designer can make together, with an example you can adapt to your own project.
What information architecture actually covers
Information architecture is the organisation of content, not simply a sitemap diagram. It includes the relationship between pages, the names people see in menus, the grouping of related information, and the routes between discovery and action. It also affects how editors maintain the website after launch.
A page hierarchy and a navigation menu are different things. Your website might contain forty useful pages while its main menu shows five clear destinations. Footer navigation, breadcrumbs, article links, and related-service links can provide additional routes without forcing every page into the header. Treat navigation as a set of deliberate choices rather than a complete filing cabinet.
Start with the questions behind a visit
Write down the questions your sales conversations repeatedly answer. For a website design business, these might include whether you work with an existing platform, what a redesign involves, whether customers can edit content, and how enquiries will be handled. Ask support colleagues which questions arrive after a sale, too.
Group questions by the stage of the decision. Early visitors need to understand the offer. Evaluating visitors want examples, constraints, and evidence. Ready visitors need a useful contact route. Existing customers may need documentation or support. A page that tries to serve all four groups equally often becomes a long collection of disconnected sections.
Use real wording from enquiries where possible. Customers may say “online shop” while your internal documents say “digital commerce solution.” The internal phrase may describe your service accurately, but the customer’s language is usually a stronger starting point for a navigation label.
Build a content inventory before drawing the new menu
Create a simple inventory containing each existing URL, its purpose, the audience it serves, its owner, and the action it supports. Include PDFs, campaign pages, resource articles, and pages that are absent from the main menu. Hidden content still creates maintenance obligations.
Then assign an intended treatment: retain, improve, combine, or retire. Two pages can share a topic without being duplicates if they answer different questions. Conversely, different titles can conceal almost identical content. Read the material rather than relying only on URL names.
If you are restructuring an existing site, preserve useful addresses where possible and document changes before launch. Our website redesign SEO migration checklist covers the separate task of managing changed URLs and redirects.
Give every important page a clear job
For each proposed page, complete this sentence: “After reading this page, the visitor should understand and be able to .” This creates a testable purpose. A services overview might help people choose the appropriate service, while an individual service page explains suitability, scope, process, and the next step.
Avoid creating pages solely because a competitor has them. A separate page needs useful content and an owner. If your business offers one service with three delivery options, a clear comparison section may be more helpful than three thin pages with nearly identical introductions.
Document what belongs elsewhere. For example, a portfolio overview should help visitors explore work, while a case study can explain one project in depth. Separating these jobs reduces repetition and makes future updates easier.
Choose labels that make sense without explanation
Navigation labels should help visitors predict the destination. “Services,” “Work,” and “Contact” are familiar because their meaning is reasonably clear. A creative phrase can work within a page, but it is less helpful when someone must decode it before taking the next step.
Check labels outside the design. Show a plain list to a colleague who does not work on the website and ask where they would expect to find pricing guidance, examples, or support. If several people choose different places, investigate the ambiguity. This is a useful directional check, not a statistically reliable user study.
Keep mobile navigation in the planning process from the beginning. Labels that fit across a desktop header may wrap awkwardly in a narrow menu. Make sure important links are easy to reach without relying on hover interactions.
A worked example for a professional services website
Imagine a small consultancy that offers strategy, implementation, and ongoing support. Its existing navigation contains “Solutions,” “Capabilities,” “Expertise,” and “Our Approach,” but visitors cannot tell which page explains the service they need.
A clearer structure could use Services as the parent destination, with three descriptive service pages underneath. Work contains project examples, About explains the team and working relationship, Resources contains educational articles, and Contact provides an enquiry route. The process explanation becomes a shared section on service pages, with a dedicated page only if it has enough useful detail.
The consultancy would then map common questions to specific destinations. “Can you help with an existing system?” belongs on the implementation page. “What happens after launch?” belongs on support. “Have you done something similar?” leads to relevant work. The structure now follows customer questions rather than internal department names.
Connect pages around meaningful next steps
After choosing the hierarchy, plan contextual links. A service page can link to a relevant case study, a guide that explains the decision, and the enquiry form. An educational article can link to a more detailed related guide rather than repeating its entire content.
Use link text that describes the destination. “Read the website handover checklist” gives visitors more information than “click here.” Keep the number of links proportionate to the content and avoid linking every mention of a keyword. Our internal linking guide explains how to maintain these connections as the library grows.
Page structure also needs accessible headings and recognisable regions. The W3C page structure tutorial provides official guidance on organising content so its relationships can be understood with different browsing tools.
Test the structure with actual tasks
Before finalising the design, define a small set of realistic tasks: find a suitable service, check a relevant example, understand the process, and send an enquiry. Run through those tasks on a plain prototype and on a mobile layout. Record hesitation and incorrect expectations rather than only whether a participant eventually reaches the destination.
Pay particular attention to visitors entering through an article or service page instead of the homepage. Every important landing page should provide enough context to orient someone arriving directly from search. A website that only makes sense when explored from its homepage is fragile.
Do not respond to every observation by adding another menu item. Sometimes the better fix is clearer wording, a stronger page introduction, or a contextual link at the point where the question arises.
Keep the architecture manageable after launch
Assign responsibility for each major section. Define where new articles, services, and projects should be added and which fields an editor must complete. A simple publishing rule might require a primary category, a descriptive title, a relevant internal link, and an identified reviewer.
Review the structure when the business changes, not only when the website looks dated. A new audience, a discontinued service, or a growing resource library can all justify adjustments. Keep a record of the reason for structural changes so future editors understand the decision.
Questions to answer before approving your sitemap
Can a new visitor explain your offer after reading the main page titles? Does every service page have a distinct purpose? Can someone reach a relevant example and contact route from each important landing page? Are support materials separated from sales material where appropriate? Can your team maintain the proposed number of pages?
Good information architecture makes the website easier to use and easier to own. If you are planning a new structure, explore our website design services or share your project so we can turn your content and customer questions into a practical page plan.