Website Structure Types and How to Plan the Right One for Your Business

A website structure is the hierarchical map of every page on a site: which sections exist, what sits underneath each one, and the route a visitor takes from the homepage to the page they actually came for. It gets drawn before the first mockup.

It is also the cheapest document to change and the most expensive one to skip. Rename a section on a whiteboard and it costs thirty seconds. Find the same mistake six months after launch and it costs a navigation rebuild, a redirect map, and a few weeks of unstable rankings while search engines work out what moved where.

This guide covers the whole thing: what the term means, the main website structure types with a comparison table, a seven-step method, three example trees you can copy, a template that drops straight into a spreadsheet, the famous numbered rules and which of them hold up, and the test to run before anyone opens a design tool.

Website structure means the way pages are organised and connected: a homepage at the top, a handful of top-level sections beneath it, subsections under those, and individual pages at the ends of the branches. It fixes three things before any design work starts: how deep the site goes, what the menu labels say, and what the URL paths look like.

Two neighbouring terms get used loosely, so it helps to pin them down. Site architecture usually means the same thing with an engineering accent. Information architecture is the wider discipline of organising and labelling content so people can find it, and website structure is the part of that discipline you can draw as a tree.

It is worth saying what a structure is not. No colours, no fonts, no finished copy. Page names and parent-child links, nothing else. That poverty is deliberate, and it is exactly what lets a team rework a whole site ten times in one morning without throwing away a single pixel.

Who owns it? Rarely one person. The founder brings commercial priorities, marketing brings real demand data, the designer brings journey logic. When a structure comes out of a single head, it tends to reproduce the company org chart instead of what visitors need.

Three documents get confused in almost every project brief, because the word map turns up in all three. A website structure exists to decide which pages there will be. An HTML sitemap page exists to orient a visitor on a site that is already live. An XML sitemap exists to tell crawlers which URLs to look at and when they last changed.

The confusion costs meeting time and occasionally money. Ask an agency for a site structure, get a sitemap.xml file back, and you have an answer to a different question: that file lists the URLs of a site that already exists, and it decides nothing at all.

Keep the three straight before the first workshop and you save a quarter of an hour of circular discussion.

According to Google Search Central, grouping topically similar pages into directories helps Google work out how often the URLs in each directory tend to change. Your structure is therefore a map of your subjects and of the pace at which each one moves. It files your pages, and it explains your priorities at the same time.

Depth then acts as a filter. A page parked on the fourth level with one inbound link from a dropdown gets seen far less often than a section page linked from the homepage. Nothing mystical is going on: internal links follow the tree, and crawl attention follows internal links. The mechanics are covered in our guide to website architecture and search visibility.

Topic silos work on the same principle. Filing everything about one subject under a single section produces a coherent block that is easier to interpret than a dozen pages scattered across different levels.

On the conversion side the effect is blunter. A visitor who cannot find your pricing page does not negotiate, they leave. Section labels usually matter more than the graphics, and a well-named menu rescues an average design. It has never worked the other way round.

One honest caveat before you take this to a board meeting: nobody can promise a specific percentage gain from structure alone. It sets the ceiling on your results, it does not produce them by itself.

A website hierarchy is the parent-child relationship between pages, counted in levels. The homepage sits at level zero. Top-level sections sit at level one. Anything filed under a section sits at level two, and so on down the branch. A hierarchical website structure is simply a site where those relationships stay consistent enough to draw as a tree.

The vocabulary comes up in every meeting, so agree on it early. A parent page contains others. A child page sits under exactly one parent. Sibling pages share a parent. Depth counts the levels between the homepage and a given page. Breadcrumbs display that path back to the visitor, usually at the top of the page.

Two kinds of depth get mixed up constantly. URL depth is how many segments a path contains. Click depth is how many links a visitor follows from the homepage. They often differ: a page at /services/web-portals/integrations/ sits three segments deep but one click away when the homepage links straight to it. Crawlers and people both react to click depth. Only humans read the URL.

The rule that keeps a hierarchy usable: every page has exactly one home. If a page genuinely belongs in two sections, that is a signal to link between them, not to file it twice. Duplicate placement splits internal links and confuses everyone who later has to explain the menu.

Three website structure types cover almost every professional site. The hierarchical model files pages in successive levels. The flat model puts nearly everything within one click of the homepage. The hub-and-spoke model gathers a set of pages around a central page that links to all of them. Choose on the content volume you expect in two years, not the volume you have today.

Hierarchical, also called a tree. The default for company sites and catalogues. Home, then sections, then subsections. It grows by adding branches, and it fails by burying a page at level four where almost nothing links to it.

Flat. Everything within one or two clicks. Sensible below roughly twenty pages, and it fails by overflowing the menu the moment the site grows past that.

Hub-and-spoke. A pillar page plus a cluster of related pages that all link back to it. Strong for blogs and resource centres, and it fails when the internal linking is left half-finished and the hub ends up orphaned.

Two further types of website structure turn up in specific places. A sequential structure walks the visitor through fixed steps, which suits checkouts, onboarding and application forms. A matrix structure lets people arrive by several routes at once, filtering a catalogue by price, brand or size. Both normally live inside a larger hierarchy rather than replacing it.

The method runs in seven steps, in this order. The usual mistake is skipping the inventory and drawing the tree straight away, which quietly reproduces the current site along with all of its faults. Budget half a day for a brochure site and two to three days once you pass fifty pages.

Step 1. Frame the goal and the priority journeys. One question: what should a visitor do before they leave? Request a quote, download a document, create an account. Two or three journeys are enough, and they decide what earns a place at level one. A written website design brief saves two meetings here.

Step 2. Inventory what already exists. List every live URL with its title, type, primary keyword and role. On a redesign this is the step that decides what you keep, merge or delete. Our website audit guide covers the collection side, and the template further down handles the recording.

Step 3. Collect real demand. Three free sources get you started: Search Console queries, your own internal site search log, and the list of questions your sales team hears on the phone. The third one is the most neglected and often the most useful.

Step 4. Group with a card sort. Write each page on a card, then ask users to make piles and name them. You will find out fast that your internal categories do not survive contact with an outsider.

Step 5. Name sections in your customers' words. Solutions, Expertise, Universe: none of these mean anything to a visitor in a hurry. Write Services, Pricing, Case Studies. A label that lands beats a label that sounds clever, and this is the step where internal disagreements surface.

Step 6. Fix depth and URLs. The tree turns into paths. Google's URL structure guidance favours readable words over numeric identifiers, and hyphens as the separator between words. A path like /services/web-portals/ reads without effort and mirrors the tree.

Step 7. Validate before the mockups. A thirty-minute tree test saves three weeks of correction. The full protocol is further down this page.

One note from practice: steps 4 and 5 happen together, never apart. Grouping without naming produces piles that nobody can announce in a menu.

Three levels, three clicks, seven menu items. These numbers have circulated for twenty years and get quoted as law. They are not law. They are rules of thumb, often useful, and it pays to know which one rests on something solid before you refuse a client an extra menu section in a meeting.

In Flat vs. Deep Website Hierarchies, Kathryn Whitenton of Nielsen Norman Group compares the two extremes and concludes that no universal answer exists. She does document one telling case: a hospital site whose menu exposed more than 32 entries drowned visitors rather than helping them. The recommendation that comes out of it is methodological, not numerical. Watch your own users instead of applying a threshold you read in an article.

Keep three reference points and their status. Three levels below the homepage is a comfortable trade convention, not a technical limit. A main menu of five to seven items descends from the seven plus or minus two rule of thumb, which Nielsen Norman Group no longer presents as a fixed ceiling. Past roughly thirty entries visible at once, the documented 2013 case shows people disengaging.

An opinion that runs against most of what you read: depth is rarely the real problem. A well-signposted fourth level gets walked without complaint. A second level called Universe stops everybody.

Here are three complete website structure examples, written as indented lists rather than pictures so you can paste them into a document in ten seconds. They match the three project families we are asked about most often. Swap the labels for your own sector and keep the level logic intact.

Brochure site, 12 pages. The common shape for a small company or a professional practice.

• Home
• Services
  • Landing pages
  • Corporate website
  • Web portal
• Case studies
  • Case study 1
  • Case study 2
• About
  • Team
  • Careers
• Blog
• Contact

Online store. Depth increases by one level, because a catalogue forces a subcategory layer.

• Home
• Shop
  • Category
    • Subcategory
      • Product page
  • New arrivals
  • Sale
• Buying guides
• Customer service
  • Delivery and returns
  • FAQ
• My account
• Contact

Client portal. Two trees live side by side: a public part that has to convert, and a logged-in part that has to serve.

• Public area
  • Features
  • Pricing
  • Log in
• Dashboard (after login)
  • My projects
  • Documents
  • Billing
  • Messages
• Administration
  • Users and roles
  • Activity log
• Help

Page count is not a comfort detail, it sets the budget. On our pricing page, a landing page covers one to five pages and starts at €1,500, a corporate website covers ten to thirty pages and starts at €4,500, and a web portal starts around fifty pages and from €9,000. A structure that drifts from twelve pages to forty mid-project changes price bracket, not only the calendar.

A website structure template is really two things: a skeleton tree you fill with your own section names, and an inventory sheet that holds one row per page. The tree settles the shape. The sheet settles the decisions, because it makes you write down what each page is for and whether it survives the rebuild.

Copy the block below into a spreadsheet and split it on the semicolon. One row per page, one decision per row.

A structure is a decision. Navigation is the part of it a visitor actually experiences. The main menu carries your top-level sections, breadcrumbs show the current position in the hierarchy, the footer catches everything secondary, and a sidebar earns its place in documentation and logged-in areas where the section list runs long.

Internal links do the rest of the work. Navigational links repeat on every page and should point at your priority pages. Contextual links sit inside body copy and carry topical meaning: a link from an article about structure to our UX/UI design services tells search engines the two subjects are related. Hub links tie a pillar page to its cluster and back again.

Plan the links alongside the tree rather than after the copy is written. A simple linking matrix, key pages as rows and as columns, marks which page should point at which and exposes orphans before they exist. Our guide to website navigation goes deeper into menu patterns and labelling.

The same handful of structural problems keeps turning up, and none of them is exotic. Every one started as a decision that felt reasonable in a meeting and turned expensive a year later. Here are the six that do the most damage to rankings and to conversions, roughly in the order we meet them.

1. Burying the pages that make money. If your highest-value service page takes four clicks to reach, it is close to invisible to visitors and to crawlers alike. Flatten the branch so revenue pages sit within two clicks.

2. Organising by department instead of by task. Your org chart is not a menu. Visitors do not care whether Support and Billing are different teams, they care about solving something. Structure around tasks and questions.

3. Leaving orphan pages. An orphan has no internal links pointing at it. Search engines may still reach it through an XML sitemap, but it inherits nothing and generally ranks accordingly. Audit for orphans on a schedule.

4. Letting two pages chase the same query. A service page and an article both targeting website design will compete with each other. Merge them, or make the intent of each clearly different.

5. Mega menus that expose everything at once. Fifty links on hover creates paralysis, and it gets worse on a phone where the same tree has to collapse into a hamburger. Test the menu on a real device, not a resized browser window. This is one of the UX mistakes that hurt conversions we see most often.

6. No room for growth. If adding one service page means rebuilding the navigation, the architecture was too rigid from day one. Categories should be broad enough to absorb next year's content without breaking the tree.

Two methods are enough, and they complement each other. A card sort builds the tree: you hand over cards, participants make piles and name them. A tree test validates it: you show the bare tree with no design and no search box, then ask people to find something specific. The first one opens the question, the second one closes it.

According to Nielsen Norman Group (Samhita Tankala and Katie Sherwin, 2024), a qualitative card sort needs at least 15 participants to understand the reasoning behind the groupings, and 30 to 50 participants if you want results that generalise to a wider population. Below 15 you are collecting anecdotes.

A tree test takes about an hour to prepare. Write eight to ten tasks phrased as a real need rather than a route. Ask where someone would find the delivery time, never click Customer Service then Delivery. Then measure three things per task: success rate, time to reach the right place, and how many times the participant bounced between sections before landing.

Treat 80% success per task as your target and anything under 70% as a section that needs renaming or moving. Both thresholds are working conventions, handy for settling an argument in a meeting. No standards body publishes them, and the acceptable figure depends on how hard the tasks you wrote happen to be.

On tools: GlooMaps and Octopus.do draw an exportable tree in minutes, Slickplan goes further on collaboration, and FigJam or Miro do the job when the workshop has several people in the room. Screaming Frog crawls an existing site and returns every URL with its depth. Treejack and Maze run remote tree tests. Free tiers on all of these change often, so check the terms before you commit.

Honestly? A whiteboard and a spreadsheet beat any paid tool when the naming work is done properly. A flawless tree built in a professional app still fails its first user test if nobody argued about the labels.

Not every site needs rebuilding, but a few signals say the current structure has become a liability. Organic traffic sliding while you keep publishing. High exit rates on pages that should convert. A large share of visitors reaching for the internal search box. Content scattered across categories that no longer agree with each other. Or a business that changed shape while the site stayed as it was two years ago.

When you do restructure, the redirect plan is the job. Every URL that disappears points at the closest equivalent page with a permanent 301, and never at the homepage. Mass redirects to the homepage are the classic fault: fast, tidy on paper, and generally read as a disguised 404.

Keep what already works. If three pages bring half your organic traffic, their URLs stay put even when the new tree suggests moving them. A tidy structure has never been worth a lost position. Our website redesign preparation guide sets out the full sequence, and the corporate website development guide covers how structure decisions sit inside a larger build.

Expect a temporary dip. A few weeks of movement is normal after a large structural change while search engines recrawl and reassign signals. Phase the work if you can: one section at a time, watch what happens, then move to the next.

If you take one thing from this guide, take this. Write your tree out in plain text, hand it to ten people who do not work for you, and only start designing the site once they can find things in it.