Website Structure Examples

The structure of a website, also called its information architecture, is how its pages are organized and linked together. If the homepage, the navigation menu, and the footer are the signposts, the structure is the map behind them: which pages exist, how they group, and how many clicks it takes to reach any page.

This page delivers the examples. It covers the four types of website structure (hierarchical, sequential, matrix, and database) with a diagram and real sites for each, then shows hierarchical website structure examples drawn from the live navigation of GOV.UK, Apple, MDN, the Python docs, Stripe's documentation, and this site. After that come six copyable sitemap trees for the site types people actually build (a simple business, a service business, an ecommerce store, a portfolio, a SaaS product, and a blog), the difference between a structure and an XML sitemap, and a blank template. It is part of the website basics library.

What is website structure?

Website structure is the way pages are grouped and connected. It covers three things:

1. Hierarchy: which pages sit above which (the tree).
2. Navigation: the menus and links visitors click to move around.
3. Internal links: the in-content links that connect related pages.

A clear structure matters for the same reason a table of contents matters in a book: visitors can predict where things live, and search engines can follow the links to discover every page. Google's SEO starter guide has a section titled "Group topically similar pages in directories" and says that using directories to group similar topics can help Google learn how often the URLs in each directory change.

Three words are easy to mix up, so here is the distinction in one table:

An XML sitemap is often confused with the structure itself. It is not the structure. It is a file that describes the URLs so search engines can find them. The trees on this page are the structure; the XML sitemap section near the end shows the file that reflects it.

Types of website structure (with examples)

There are four common types of website structure. Each one answers the same question differently: from any page, where can the visitor go next?

Hierarchical (tree)

The homepage sits at the top, sections sit below it, and pages sit below the sections. Every page has one parent, and the visitor moves from broad to specific. This is the structure behind most business sites, stores, government sites, and documentation.

HIERARCHICAL (tree)
Home
+-- Section A
|   +-- Page
|   +-- Page
+-- Section B
|   +-- Page
|   +-- Page
+-- Section C

Best for: any site with more than a handful of pages that fall into natural groups.

Real examples: GOV.UK groups every service under 16 top-level topics such as "Driving and transport", which splits again into "Driving licences" and other subtopics. Apple lists its product lines (Mac, iPad, iPhone, Watch) in the global navigation and the individual products one level below. Both are drawn in full in the real-site section below.

Sequential (linear)

Pages run in a fixed order and each one leads to the next. The visitor is meant to go forward (and sometimes back), not to jump around. Checkouts, sign-up flows, tutorials, and multi-step government services use it.

SEQUENTIAL (linear)
Start
+-- Step 1
    +-- Step 2
        +-- Step 3
            +-- Finish

Best for: tasks with a required order: paying, applying, onboarding, learning a skill one lesson at a time.

Real examples: GOV.UK's Learn to drive a car: step by step page lays the whole process out as seven numbered steps, from "Check you're allowed to drive" through "Get a provisional licence" to "When you pass". MDN's Learn web development lessons end with "Previous" and "Next" buttons that move the reader through the module in order.

Matrix (webbed)

Every page can link to every other page, so there is no single parent and no fixed order. The visitor follows whichever link is relevant. It is the structure of an encyclopedia or a wiki, and of the in-content links inside any large site.

MATRIX (webbed)
Page A
+-- links to B, C, D
Page B
+-- links to A, D
Page C
+-- links to A, B
Page D
+-- links to A, B, C
(no single parent: pages link in every direction)

Best for: reference material where readers arrive at any page and follow their own path.

Real example: Wikipedia. The article on information architecture links out to related articles such as "Card sorting", "Site map", "Tree testing", and "User experience design" in its "See also" list, and each of those links back to others. There is a category system underneath, but readers rarely use it; the links are the structure.

Database (dynamic)

Pages are generated from records in a database, and the visitor reaches them through search, filters, and tags rather than a fixed menu. The structure is defined by the data model, not by a hand-drawn tree. Every large catalog, directory, and listings site works this way.

DATABASE (dynamic)
Home
+-- Search / filters
|   +-- Results page (generated for each query)
|       +-- Record page (one URL per record)
+-- Browse by tag or category (also generated)

Best for: sites with thousands of similar items: products, books, repositories, listings, profiles.

Real examples: GitHub gives every repository the same generated URL pattern (github.com/<owner>/<repository>) with the same set of tabs for issues, pull requests, discussions, and actions, and nobody hand-draws that tree. Open Library builds its results page from a query string and links each result to a record page.

The four types compared

Most real sites mix the types. A store is hierarchical for browsing (Shop, Men, Shirts), sequential at checkout (Cart, Shipping, Payment, Confirm), and database-driven in its search and filters. GOV.UK is hierarchical in its topic pages and sequential in its step-by-step guides. The hierarchical tree is still the one to draw first, because it is the part visitors see in the menu and the part you can plan on paper.

Flat vs hierarchical website structure

Within the hierarchical type, the main choice is how deep the tree goes.

Flat structure: most pages are one click from the homepage. There is little or no nesting.

FLAT
example.com
+-- Home
+-- About
+-- Services
+-- Reviews
+-- Contact
+-- Privacy

Hierarchical structure: pages are grouped into sections, and sections sometimes have their own subsections. Some pages are two or three clicks deep.

HIERARCHICAL
example.com
+-- Home
+-- Services
|   +-- Landscaping
|   +-- Irrigation
|   +-- Hardscaping
+-- Projects
|   +-- Residential
|   +-- Commercial
+-- Blog
+-- Contact

Most real sites sit between the two: a mostly flat site with one or two grouped sections, or a hierarchical site that keeps the top-level menu short. A common rule of thumb is to keep any page within three clicks of the homepage and to keep the top-level navigation to roughly five to seven items.

The page-level layout inside each box of the tree is the wireframe. See the website wireframe example for how each page breaks into header, hero, content, and footer.

Hierarchical website structure examples from real sites

The trees below are drawn from the live navigation, breadcrumbs, and URLs of each site, checked on 2026-11-11. Each tree shows only pages we confirmed, so they are partial by design: a branch, not the whole site. Labels are quoted as the sites spell them.

GOV.UK

The UK government site puts every service under 16 top-level topics. Each topic page lists subtopics, each subtopic page lists services, and the breadcrumb on the subtopic page reads "Home" then "Driving and transport". The service pages themselves have short, flat URLs, which is a useful lesson: the hierarchy lives in the topic pages and breadcrumbs, not in the URL path.

GOV.UK (www.gov.uk)
Home                                                   /
+-- Benefits                                           /browse/benefits
+-- Business and self-employed                         /browse/business
+-- Driving and transport                              /browse/driving
|   +-- Driving licences                               /browse/driving/driving-licences
|   |   +-- Apply for your first provisional driving licence
|   |   |                                              /apply-first-provisional-driving-licence
|   |   +-- Renew your driving licence                 /renew-driving-licence
|   +-- Vehicle tax, MOT and insurance                 /browse/driving/vehicle-tax-mot-insurance
+-- Money and tax                                      /browse/tax
+-- Working, jobs and pensions                         /browse/working
+-- (16 topics in total)

Apple

Apple's global navigation is a list of product lines: Store, Mac, iPad, iPhone, Watch, Vision, AirPods, Home, Entertainment, Accessories, Support. The Mac page then lists the individual Macs. Like GOV.UK, Apple keeps product URLs one level deep (/macbook-air/, not /mac/macbook-air/), so the tree is expressed through navigation rather than folders.

APPLE (www.apple.com)
Home                           /
+-- Store
+-- Mac                        /mac/
|   +-- MacBook Air            /macbook-air/
|   +-- MacBook Pro            /macbook-pro/
|   +-- iMac                   /imac/
|   +-- Mac mini               /mac-mini/
|   +-- Mac Studio             /mac-studio/
+-- iPad                       /ipad/
+-- iPhone                     /iphone/
+-- Watch                      /watch/
+-- Vision                     /apple-vision-pro/
+-- AirPods                    /airpods/
+-- Home                       /home/
+-- Entertainment              /entertainment/
+-- Accessories
+-- Support                    support.apple.com

MDN Web Docs

MDN is the clearest case of a URL that mirrors the hierarchy exactly. The breadcrumb on the page for the HTML anchor element reads Web, HTML, Reference, Elements, <a>, and the URL repeats those five segments in the same order.

MDN WEB DOCS (developer.mozilla.org)
Web                            /en-US/docs/Web
+-- HTML                       /en-US/docs/Web/HTML
|   +-- Reference              /en-US/docs/Web/HTML/Reference
|       +-- Elements           /en-US/docs/Web/HTML/Reference/Elements
|           +-- <a>            /en-US/docs/Web/HTML/Reference/Elements/a
+-- CSS                        /en-US/docs/Web/CSS

Python documentation

The Python docs show a hierarchy that is deeper in the breadcrumb than in the URL. The page for the json module has the trail "3.15.2 documentation" (the version changes with each release), then "The Python standard library", then "Internet Data Handling", then "json". The URL skips the middle level: every module page lives directly under /3/library/. Each page also carries "previous" and "next" links to its neighbours, so a sequential path runs along the bottom of the tree.

PYTHON DOCS (docs.python.org)
3.15.2 documentation                       /3/
+-- The Python standard library            /3/library/index.html
    +-- Internet Data Handling             /3/library/netdata.html
        +-- json                           /3/library/json.html
        +-- mailbox                        /3/library/mailbox.html

Stripe documentation

Stripe's docs split by product at the top (the "Payments" tab) and by task underneath it. The Checkout page has the breadcrumb "Home" then "Payments" and the heading "Build a payments page". This is the docs half of the SaaS tree shown later on this page.

STRIPE DOCS (docs.stripe.com)
Home                                       /
+-- Payments                               /payments
    +-- Accept a payment                   /payments/accept-a-payment
    +-- Checkout ("Build a payments page") /payments/checkout
    +-- Web Elements                       /payments/elements
    +-- Payment Methods                    /payments/payment-methods

This site

Basic Website Example is a small hierarchical site, and because we run it we can show the whole shape. Four category hubs sit under the homepage and every article belongs to one of them. The breadcrumb on an article reads Home, then the hub, then the article. Like GOV.UK and Apple, we keep article URLs one level deep (/restaurant-website-examples/, not /website-examples/restaurant/). The demo sites under /examples/ are the exception: each one is a self-contained small site with its own nested pages, so a demo subpage such as /examples/restaurant/kitchen/ is three levels deep in both the URL and the navigation.

BASIC WEBSITE EXAMPLE (www.basicwebsiteexample.com)
Home                                        /
+-- Website Examples (hub)                  /website-examples/
|   +-- Restaurant Website Examples         /restaurant-website-examples/
|   +-- SaaS Website Examples               /saas-website-examples/
|   +-- Ecommerce Website Examples          /ecommerce-website-examples/
+-- Website Basics (hub)                    /website-basics/
|   +-- Website Structure Examples          /website-structure-examples/  (this page)
|   +-- Website Launch Checklist            /website-launch-checklist/
|   +-- Website URL Examples                /website-url-examples/
+-- Code Examples (hub)                     /code-examples/
|   +-- HTML Website Example                /html-website-example/
+-- Templates (hub)                         /templates/
|   +-- Website Wireframe Example           /website-wireframe-example/
+-- Example sites                           /examples/<industry>/
    +-- Copper Fig (restaurant demo)        /examples/restaurant/
    |   +-- Menu                            /examples/restaurant/menu/
    |   +-- The kitchen                     /examples/restaurant/kitchen/
    |   +-- Private dining                  /examples/restaurant/private-dining/
    |   +-- Reserve                         /examples/restaurant/reserve/
    +-- Ledgerly (SaaS demo)                /examples/saas/
        +-- Features                        /examples/saas/features/
        +-- Pricing                         /examples/saas/pricing/
        +-- Customers                       /examples/saas/customers/
        +-- Contact                         /examples/saas/contact/

Two patterns show up across all six sites. First, the hierarchy visitors experience is carried by navigation and breadcrumbs; whether the URL repeats it (MDN, our demo sites) or flattens it (GOV.UK, Apple, Python, our articles) is a separate decision. Second, no site is purely one type: GOV.UK and Python both run sequential paths through a hierarchical tree, and every one of them has a search box that generates results from a database.

Sitemap tree examples

Each tree below is a complete website structure example you can copy, adapt, and use as the starting point for your own site. They are drawn as plain-text trees; copy the block, replace the page names with yours, and you have a sitemap.

Simple business site (flat)

The flat structure keeps every page one click from home. It suits a small business with a handful of pages, the structure the business website examples page shows in finished form.

SIMPLE BUSINESS (flat structure)
example.com
+-- Home
+-- About
+-- Services
+-- Reviews
+-- Contact
+-- Privacy

Why it works: with six pages there is no reason to bury anything. The homepage, the navigation, and the footer link straight to every page, so nothing is more than one click away.

Most restaurant and cafe sites use this same flat shape, with Menu, Reservations, and Visit in place of Services and Reviews. See restaurant website examples for real ones.

Service business (hierarchical)

When a business offers several services or has a portfolio of projects, the pages group naturally. Related pages live under a section instead of all cluttering the top menu.

SERVICE BUSINESS (hierarchical structure)
example.com
+-- Home
+-- Services
|   +-- Landscaping
|   +-- Irrigation
|   +-- Hardscaping
+-- Projects
|   +-- Residential
|   +-- Commercial
+-- About
+-- Blog
+-- Contact

Why it works: the visitor chooses a broad service first, then a specific one. The navigation stays short (Home, Services, Projects, About, Blog, Contact) while every real page is still only two clicks deep.

Ecommerce store

A store's structure follows the buying path: browse the catalog by category, drill into a subcategory, and land on a product. Support and policy pages hang off the bottom because they are visited rarely. The checkout that follows the product page is sequential, and the search box is database-driven, so this is the clearest example of a mixed structure.

ECOMMERCE (store structure)
example.com
+-- Home
+-- Shop
|   +-- Men
|   |   +-- Shirts
|   |   +-- Jackets
|   +-- Women
|   |   +-- Dresses
|   |   +-- Knitwear
|   +-- Sale
+-- About
+-- Help
|   +-- Shipping
|   +-- Returns
+-- Policies
|   +-- Terms
|   +-- Privacy
+-- Blog

Why it works: product pages are grouped so a shopper and a search engine can both understand the catalog. The ecommerce website examples page shows real stores that follow this pattern.

Portfolio

A portfolio keeps the work visible and the rest minimal. The work grid is one click from home, each project is a page under it, and contact is the closing action.

PORTFOLIO (portfolio structure)
example.com
+-- Home
+-- Work
|   +-- Project: brand refresh
|   +-- Project: mobile app
|   +-- Project: campaign site
+-- Services
+-- About
+-- Contact

Why it works: the client lands on the work in one click and finds the contact path in one more. See the structure in finished form on the portfolio website examples and personal website examples pages.

SaaS or product site

A software product site has three audiences to serve (visitors deciding, customers learning, and users needing help), so it splits into three clean sections: marketing pages, documentation, and a blog.

SAAS (product site structure)
example.com
+-- Home
+-- Product
|   +-- Features
|   +-- Pricing
+-- Docs
|   +-- Getting started
|   +-- Guides
|   +-- API reference
+-- Blog
+-- Support
+-- Login

Why it works: each section has a distinct job and its own audience, which makes both navigation and search understanding predictable. The SaaS website examples page collects real SaaS sites that follow this split, and the Stripe documentation tree above shows the Docs branch at full size.

Blog or content site

A content site groups articles under topic categories. The topic pages are the hubs; individual posts are the leaves.

BLOG (content site structure)
example.com
+-- Home
+-- Topics
|   +-- SEO
|   |   +-- Post: how to structure a website
|   |   +-- Post: XML sitemap basics
|   +-- Design
|   +-- Marketing
+-- Resources
+-- About
+-- Contact

Why it works: a reader can browse a topic or land on a single post, and the topic page links the related posts together. This is the same hub-and-spoke idea behind content clusters, and it is how this site's own hubs work.

The sitemap tree as HTML you can open

The trees above are readable and copyable as text, but you may also want a version you can open in a browser. The file below renders the ecommerce sitemap tree as real nested boxes. Copy it, save it as sitemap-tree.html, and double-click it to open.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Ecommerce sitemap tree - Basic Website Example</title>
<style>
  body { font: 15px/1.5 system-ui, -apple-system, sans-serif; max-width: 620px; margin: 2rem auto; padding: 0 1rem; color: #334155; }
  h1 { font-size: 1.25rem; margin-bottom: 1rem; }
  ul { list-style: none; margin: 0; padding-left: 1.25rem; border-left: 2px solid #cbd5e1; }
  li { margin: 6px 0; position: relative; }
  li::before { content: ""; position: absolute; left: -1.25rem; top: .7em; width: .9rem; height: 2px; background: #cbd5e1; }
  .root { border-left: 0; padding-left: 0; }
  .root > li { font-weight: 600; }
</style>
</head>
<body>
  <h1>Ecommerce sitemap tree</h1>
  <ul class="root">
    <li>Home
      <ul>
        <li>Shop
          <ul>
            <li>Men
              <ul><li>Shirts</li><li>Jackets</li></ul>
            </li>
            <li>Women
              <ul><li>Dresses</li><li>Knitwear</li></ul>
            </li>
          </ul>
        </li>
        <li>About</li>
        <li>Help
          <ul><li>Shipping</li><li>Returns</li></ul>
        </li>
        <li>Contact</li>
      </ul>
    </li>
  </ul>
</body>
</html>

How to structure a website

Six examples give you the shapes; this is the process that produces one:

1. List every page the site needs. Write them all down (every service, product, post, and policy page) before you think about hierarchy.
2. Group pages into sections. Put related pages together and give each group a name. Five to seven top-level groups is plenty; everything else nests.
3. Order top to bottom by importance. The most important sections go at the top of the tree and in the navigation.
4. Check the click depth. Every page should be reachable in three clicks or fewer from the homepage. If a page is deeper, promote it or flatten the tree.
5. Turn the tree into navigation. The top-level sections become the main menu; secondary pages go in drop-downs, the footer, or in-content links.

The outcome is a sitemap tree you can hand to a designer (who will draw the wireframe) or a developer, with every page accounted for and nothing orphaned, meaning no pages left with no links pointing to them. Once the site is built, the website launch checklist is where you confirm the structure survived: every link in the tree works, robots.txt does not block it, and the XML sitemap lists the same pages.

XML sitemap vs information architecture

This distinction is worth its own section because the two are constantly conflated.

• Information architecture (the structure) is the design of how pages relate. It lives in the navigation, the hierarchy, and the internal links, and it is something visitors experience.
• An XML sitemap is a machine-readable file that lists the site's URLs so search engines can discover them. It is a reflection of the structure, not the structure itself.

A real sitemap file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-08-01</lastmod>
  </url>
  <url>
    <loc>https://example.com/services</loc>
  </url>
  <url>
    <loc>https://example.com/contact</loc>
  </url>
</urlset>

Each <url> block lists one address and optional metadata such as <lastmod> (the last-modified date). Search engines read the file to learn which URLs exist. It lists the same pages the tree above shows, but the file itself does not organize them.

A clean structure also helps the website URL examples and the website title examples do their jobs: descriptive paths mirror the hierarchy, and clear titles tell visitors and search engines what each page in the tree is about.

Copyable website structure template

Use this blank sheet to draw your own structure. Copy it, fill in the brackets, and list the pages top to bottom.

# Website structure template

Site name:  [Site name]
Site goal:  [What the site exists to do]
Audience:   [Who visits, in one line]

Top-level sections (five to seven items):
1. [Section 1]
2. [Section 2]
3. [Section 3]
4. [Section 4]
5. [Section 5]

Sitemap tree (draw it here):

example.com
+-- Home
+-- [Section 1]
|   +-- [Subsection]
|   +-- [Subsection]
+-- [Section 2]
+-- [Section 3]
+-- [Footer links: About, Contact, Privacy, Terms]

Checklist before you build:
- [ ] Every page on the list is in the tree (no orphans)
- [ ] Every page is reachable in three clicks or fewer
- [ ] The five-to-seven top-level items match the main navigation
- [ ] Support pages (About, Contact, legal) are linked from the footer

FAQ

Where to go next

The tree is the whole-site map; the pages around it cover the next steps. The website wireframe example shows what each page inside the tree looks like, and the HTML website example turns one page into working code. To see these structures filled in with real content, browse the website examples library, and keep every planning document, including this structure template, in the templates collection. The website audit report example is the tool for reviewing a structure that already exists.