Website information architecture (IA) is the structure of pages and the names of the groups they sit in. Navigation is the interface that exposes that structure: menus, footers, breadcrumbs, and in-page links. If the structure is wrong, a prettier menu does not help.
This is not a CMS manual. How editors publish into a structure is a separate topic. What a CMS is, is explained in what is a CMS.
Build the hierarchy from tasks
List what a first-time visitor must be able to find:
- What you offer, in their words
- Who it is for, if that changes the offer
- Evidence: work, clients, or credentials you are willing to show
- How to start: call, form, or visit
- Practical facts: location, hours, company name
Group pages by those tasks. A header with twelve items usually means the groups are not finished. Five to seven top-level items is a useful ceiling for a company site. The rest can live under a parent or in the footer.
Labels should match the visitor’s language. “Solutions” and “Synergy” fail. “Web design”, “CRM systems”, and “Contact” tell people where they will land. Do not use an internal department name unless the public uses it too.
Menus, footers, and journeys
The header is for the main tasks. The footer repeats contact details and holds secondary pages: privacy, careers, terms. Utility links such as language or client login should not compete with the primary menu.
A journey is a path you expect: home, service, related work, enquiry. Each step needs an obvious onward link. A dead-end service page with no next action wastes the structure you just designed. The interface of that action is covered in UI vs UX and form usability.
Breadcrumbs help when the site is deep. They are less useful on a flat five-page site. Do not invent depth so breadcrumbs look serious.
Card sorts and label tests
You do not need a lab. Write each planned page on a card, ask two people who are not on the project to group them, and listen to the group names they invent. If they say “pricing” and your menu says “engagement models,” rename the menu. Repeat with the final header before visual design locks the width of the bar. A label that only fits because the font is small will break when it is translated or when a longer service name arrives.
Testing whether people can find a page
- Write five tasks in visitor language
- Hide the design from a colleague who did not build it
- Ask them to find each item from the homepage
- Record the wrong clicks and the label they expected
- Rename or regroup before visual polish
A practical example
A company site lists “Products”, “Services”, “Capabilities”, and “What we do” as four header items that overlap. Visitors open all four. The revision keeps “Services” for the offers, moves detailed method pages under each service, and puts company facts under “About”. A five-minute test with someone from outside the project finds the contact page on the first try. That test is more useful than another round of icon design.
Project galleries need the same discipline: categories people recognise, not a dump of thumbnails. See how to organise a website portfolio.
Key takeaways
- Group pages by visitor tasks, then name the groups in their words.
- Keep the header short. Put legal and secondary links in the footer.
- Give each important page a sensible next step.
- Test with people who did not design the menu.
FAQ
Should every page be in the header?
No. Header space is for frequent tasks. Deep pages are reached from their parent. A sitemap footer link can cover the rest.
Is search a substitute for navigation?
Search helps on large sites. It does not fix vague labels. People still need to browse when they do not know the name of the page.
How is this different from a URL plan?
IA is the public structure. URLs should follow it closely so a redesign does not invent a second, conflicting map. Preserving old URLs during a move is covered in website redesign migration.