How to Plan a Website Sitemap Before Design Starts

A website sitemap — the planned hierarchy of pages and relationships between them — decides what deserves a destination, how services are grouped and how a visitor moves from an initial question to useful detail and action. (This is not the XML file submitted to search engines; that shares the name but serves a different job.)

A weak sitemap forces design to compensate for structural problems: overloaded pages, vague navigation labels, buried services. A strong sitemap gives every later decision a stable frame.

Start with project constraints

Before listing pages, define what the website must support. A five-person consultancy should not copy the sitemap of a national firm with separate practices, locations and recruitment teams.

Capture priority services and audiences, geographic scope, lead-generation goals, languages, existing organic traffic and valuable URLs, compliance content, available expertise, content owners, publishing capacity and planned integrations.

These constraints prevent two common failures: a sitemap based only on the current navigation, and a wishlist the organization cannot write or maintain.

Inventory what already exists

For an existing site, crawl the domain, export indexed pages from Search Console where available and add important campaign landings that may sit outside navigation. For each URL, note title, traffic, backlinks, conversion value, content quality and a proposed action: keep, improve, merge, redirect or remove.

For a new website, build the equivalent inventory from sales materials, proposals, onboarding documents, recurring questions and knowledge held in people’s heads. Identify existing knowledge, not only existing web pages.

Map audiences, offers and intent

List the audiences the business actually serves and what each is trying to understand or accomplish. Overlapping services do not automatically require separate audience sections — only meaningfully different content does.

Group intent practically:

1. Orientation: What does this firm do, and is it relevant?
2. Service evaluation: What is included, who is it for, how does it work?
3. Evidence: Has the firm handled a situation like mine?
4. Risk reduction: What will this require, cost or disrupt?
5. Action: What is the appropriate next step?

This keeps the sitemap from mirroring the org chart. Buyers care whether they can find the right answer — not which department owns it.

Define the service architecture

Challenge the service list against how the business sells and how clients ask for help.

A service usually deserves a dedicated page when it has distinct buyer intent, unique scope, process and proof, commercial importance, a specific conversion path, and independent search or navigation demand. Combine services when separate pages would repeat the same message with slightly different labels.

Use parent hubs to orient and route — not merely because a dropdown needs a heading. If two closely related offers exist, direct links may be clearer than an empty layer.

Identify supporting content

Service pages handle core evaluation; they do not need every comparison or technical digression. Supporting content — approach articles, process guides, case studies, use-case pages, deep FAQs — answers narrower questions and links back to the relevant service.

Assign every proposed article a reason: which audience question it answers, which commercial page it supports and what useful next destination it offers.

Draft the hierarchy from intent

Arrange pages in levels, but derive the structure from the intent map — not from a default brochure outline. If intent-to-page-type mapping is still fuzzy, clarify it first in search intent and how it should change your website.

A professional services firm that sells three distinct engagements and wins work through referrals and search might look more like:

• Home (orientation + routing to priority services)
• Service hub → Service A / B / C (evaluation + proof + next step)
• Work (evidence for high-intent visitors)
• Insights that support specific service objections
• About / team only where people affect the decision
• Contact / assessment
• Required legal and utility pages

Add industry, location or resource hubs only when they solve real navigation and content needs. Keep the hierarchy shallow enough that important pages are easy to reach, but do not flatten everything into the primary header — hierarchy communicates relationships.

Give each page a working purpose statement. If two proposed pages share the same purpose, combine or differentiate them.

Test navigation language

The sitemap can contain dozens of pages; the header should expose only the choices most visitors need. Prefer labels people understand without company context. Specific service names usually beat “Capabilities” or “Solutions.”

Test with simple tasks: Where would you learn whether the firm offers a specific service? Where would you evaluate experience? Where would an existing client find a resource? Where would someone make contact? Ask someone outside the project. Their hesitation is more useful than a stakeholder vote on preferred labels.

Turn the sitemap into a production plan

Once the hierarchy is stable, fold SEO, conversion and migration into the same working document — not as afterthoughts.

Map one primary topic and related questions to each important page. Watch for cannibalization (several pages explaining the same service) and the opposite problem (one general page expected to rank for several substantial services). Plan internal links at the relationship level: hubs to children, services to proof and guides, articles back to the service they help evaluate, case studies to demonstrated capabilities.

Assign a primary action to each page type and note where forms, calendars or phone links appear. Document keep / merge / redirect / remove for every important current URL. Do not redirect every retired page to the homepage — that obscures migration mistakes. Preserve strong URLs where only design and content are changing. The redirect map is a launch requirement, not a note for after go-live.

Add operational columns to the approved sitemap: URL, purpose, audience and intent, content owner, existing source, required proof, primary action, template needs, SEO topic, migration action and status. That document becomes the shared source for content, wireframes, development and launch QA. When six new pages appear, the writing, proof, design and build work attached to them becomes visible.

What to approve before design starts

The sitemap does not need final copy. It should be stable enough to support real page decisions:

1. Page hierarchy and priority services
2. Purpose and audience for each core page
3. Navigation labels and important utility links
4. Content owners and known gaps
5. Primary conversion paths
6. Keep, merge and redirect decisions for valuable URLs
7. Required page types and unusual functionality

Then begin wireframes with representative content. Designing a service page with placeholder paragraphs delays structural decisions until copy production, when changes cost more.

The best sitemap is not the largest

For most service businesses, the best sitemap is the smallest structure that gives every important intent a useful destination, supports future content and remains realistic to maintain.

Once approved, use it to drive navigation, page briefs, wireframes, content assignments, internal links, redirects and quality assurance. That continuity prevents a collection of individually approved pages with no coherent journey.

When the hierarchy is sound, service pages can carry buyer clarity and SEO structure. Summitstone plans that structure as part of web design — before visual concepts lock in the wrong assumptions.