Website Structure and Sitemap: How to Plan Your Pages
Site structure is the arrangement of your pages and the paths between them. It decides whether a visitor finds what they came for in one click or three, and it is one of the strongest signals a search engine has about what your site is about and which pages matter.
This guide covers how to plan a structure, how deep is too deep, how to name URLs, and the mistakes that are cheap to avoid now and expensive to fix after launch.
Group by task, not by org chart#
The most common structural mistake is a navigation that mirrors how the organisation is arranged rather than what visitors came to do. Nobody arrives looking for your Solutions Division.
Start from the questions visitors actually ask, group the pages that answer each one, and name the group in the words they would use — which are almost never your internal words.
- Write each page on its own line, then group lines that answer the same question.
- Name each group in visitor language: "Pricing", not "Commercial Framework".
- Aim for five to seven top-level sections; more than that and the navigation stops being scannable.
- If a page does not fit any group, it is usually either unnecessary or a new group of one — decide which.
Keep important pages shallow#
Depth is the number of clicks from the homepage. Pages that matter should be reachable in two or three; anything at depth five is rarely found by visitors and is crawled less often by search engines.
Depth is not the same as URL length. A page at /guides/seo/technical-seo can still be one click from the homepage if something links to it directly. What matters is the link path, not the slashes.
| Depth | Typical pages | Treatment |
|---|---|---|
| 0 | Homepage | Links to every top-level section and the primary action |
| 1 | Section hubs, key landing pages | In the main navigation |
| 2 | Individual articles, products, services | Linked from hubs and from related content |
| 3 | Variants, deep reference pages | Linked from their parent and from search |
| 4+ | Archives, old campaigns | Question whether they should be indexed at all |
The homepage is not the main entrance for most sites. Search traffic lands deep, so every page needs to say where it is and offer the next step.
URL patterns worth deciding once#
URLs are cheap to get right at the start and painful to change afterwards, because changing them means redirects, lost signals and broken external links. Decide the pattern before the first page exists.
- Lower case, words separated by hyphens, no underscores or spaces.
- Short and descriptive: /guides/website-planning-guide, not /p?id=4821.
- One consistent decision on trailing slashes, enforced with a redirect to the canonical form.
- Include the section when it adds meaning; do not stack every ancestor into the path.
- No dates in URLs unless the content is genuinely time-bound — they make evergreen pages look stale.
- For multilingual sites, decide the language pattern now: /de/… prefixes are the simplest to reason about.
Two sitemaps, two audiences#
The word covers two different things. A planning sitemap is the diagram you draw before the build — pages and their relationships. An XML sitemap is a file at /sitemap.xml that lists your indexable URLs for search engines.
You need both, and they serve different readers.
| Planning sitemap | XML sitemap | |
|---|---|---|
| Audience | Your team and the developer | Search engines |
| When | Before design starts | Generated automatically after launch |
| Contains | Every planned page and its parent | Every canonical, indexable URL |
| Format | A diagram or a nested list | XML, split by section on larger sites |
| Maintenance | Updated when scope changes | Regenerated whenever content changes |
An XML sitemap should list only pages you want indexed. Including filtered, paginated or noindex URLs wastes crawl budget and sends contradictory signals.
Frequently asked questions
How many top-level navigation items should I have?
Five to seven for most sites. Beyond that the bar stops being scannable and starts being a list people read rather than glance at — and on a phone it becomes a menu nobody opens. If you genuinely need more, the usual fix is that two of your sections are actually one.
Do URLs need to match the navigation?
They should be consistent but they do not have to mirror it exactly. What matters is that the URL is predictable and stable. Deeply nested paths that stack every ancestor are fragile: move one section and every URL underneath changes, and you inherit a redirect map you have to maintain forever.
What happens to my old URLs in a redesign?
Every old URL that had traffic or links needs a 301 redirect to its closest equivalent. Not to the homepage — that tells a search engine the page is gone and loses the accumulated signals. Map the redirects before launch, from a crawl of the old site plus your analytics, and test them the day you go live.
Should every page be in the navigation?
No. Navigation is for the pages most visitors need; the rest are reached through hubs, related links, search and the footer. A page that is in no navigation and linked from nowhere is orphaned, though — it will barely be crawled and rarely found. Every indexable page needs at least one internal link from somewhere.
website structuresite architecturewebsite sitemapurl structurewebsite navigationinformation architecture
