How to plan a website sitemap your client will approve

The sitemap is the highest-leverage half hour in a web project. Every decision downstream — what gets written, what gets designed, what gets built, what gets found on Google — inherits its shape. Get it right and the project has rails; get it wrong and you'll be relitigating structure inside design reviews for months.

Yet most sitemaps are made the worst possible way: by copying the old site's structure, adding whatever the loudest stakeholder asked for, and drawing it as boxes in a slide nobody can edit. Here's a better method.

Start from questions, not pages

A website is a machine for answering visitors' questions in order. So before drawing any tree, list the questions: What do you do? Is it for someone like me? Can I trust you? What does it cost? What happens if I get in touch?

Each question needs a home. Some share a page; the big ones earn their own. Working this way surfaces the real structure — and it kills the classic vanity pages ("Our Values") that answer questions nobody asked.

The earn-your-place test

Every page in the tree must pass three checks:

It answers a question a real visitor has. Not a question the company wishes visitors had.
Someone will maintain it. A page nobody owns rots, and a rotting page is worse than no page — it's proof the company doesn't notice details.
It has a next step. Every page should have an obvious "and now…" — a link deeper, a contact action, a related service. Dead-end pages leak visitors.

Fail any check and the content belongs as a section on another page, not a page of its own. Most bloated sitemaps are just sections wearing page costumes.

Depth: three clicks is a smell, not a rule

Hierarchy should mirror how visitors think about the offer, not the org chart. Services grouped the way customers shop for them, not the way departments are structured internally — the most common structural mistake in B2B sites.

Depth heuristics that hold up in practice:

Money pages sit shallow. Anything that converts — services, pricing, contact — lives one or two levels down, never three.
Depth is fine for genuine libraries. Guides, case studies and documentation can nest; visitors inside a library expect to dig.
If a parent page exists only to link its children, question it. "Services" with nothing to say beyond a menu of services might just be a nav dropdown, not a page.

Navigation is not the sitemap

The tree and the nav are related but different artefacts. The sitemap holds everything; the navigation is an edit of it — the six or seven items a visitor can hold in their head, with the rest reachable through page-level links and the footer.

Plan them together but separately. A mega menu can surface twelve destinations beautifully; a header nav cannot. And decide the labels now, not in design: "What we do" versus "Services" is a content decision with SEO consequences (people search for "services", not for your clever alternative).

Make it reviewable — and then make it real

A sitemap in a slide deck gets nodded at, not reviewed. Clients approve tree diagrams without understanding them, because boxes with titles carry no sense of what each page actually is. Then the first designed page appears and the structural feedback starts — precisely when it's most expensive.

Two practices fix this:

First, review the tree as a living thing, not a picture. Walk the client through it top-down asking one question per page: "someone lands here — what do they need to see to take the next step?" Rearrange live, in front of them. A structure the client helped drag into shape is a structure they've already half-approved.

Second, put a skeleton on the bones before final sign-off. A sitemap where each page shows its sections — hero, proof, offer, CTA — with even rough working titles is dramatically easier to evaluate than boxes. This is where sitemap planning hands over to the content-first process: structure, then skeleton, then words, with the sitemap staying editable the whole way.

When the structure settles, get it approved properly — recorded, versioned, attached to the actual tree rather than a screenshot of it. Structural sign-off is the cheapest insurance in the project: every "shouldn't this be its own page?" conversation after design starts costs ten times what it would have cost at the tree stage.

The checklist

Built from visitor questions, not the old site or the org chart
Every page passes earn-your-place (real question, real owner, real next step)
Money pages ≤ 2 levels deep; libraries may nest
Navigation designed as an edit of the tree, labels decided with search in mind
Reviewed live as a tree, then as wireframe skeletons — never as a static diagram
Approved on the record before design begins

We built Blocky so this whole phase — the draggable tree, the wireframe skeletons, the words and the recorded approvals — lives in one place instead of a diagram, nine documents and an email thread. However you run it, hold the line on the sequence: structure first, approved early, changed while it's still cheap.