Why website projects benefit from a sitemap diagram

Website projects tend to start in the wrong place. Someone opens a design tool and starts on the homepage, or a client sends a list of pages they want, or the developer copies the old site's navigation and promises to tidy it later. Weeks in, the team discovers that two pages say the same thing, a section nobody planned needs a template, and the navigation has seven top-level items because every stakeholder got one.

A sitemap diagram prevents most of that. It is a tree of pages, drawn before anything is designed, and it forces the structural decisions early, while they are cheap to change. Moving a box on a diagram costs seconds. Moving a page after its template is built and its content is written costs days.

Sitemaps as information architecture

Information architecture is the discipline of deciding how content is grouped, labelled and connected so people can find it. It sounds abstract. On a website it comes down to concrete questions: which pages exist, which section each belongs to, what each section is called, and what appears in the main navigation.

A sitemap diagram is where those answers are written down. Each box is a page. Each line says this page sits beneath that one. The top row beneath the homepage is, nearly always, the main navigation. That makes the diagram the first draft of the menu, the URL structure and the list of templates all at once.

The example above is deliberately plain. Four top-level sections, two services, one team page. It is also what a large share of small business sites should look like, and drawing it first makes it harder for scope to creep in unnoticed.

Hierarchy and depth

Two measurements matter on any sitemap: how wide each level is and how deep the tree goes. Width is the number of siblings at one level. Depth is the number of clicks from the homepage to the furthest page.

• A wide top level means a crowded main navigation. Beyond six or seven items, visitors stop reading and start guessing.
• A deep tree means important pages are hard to reach. If a page that drives enquiries sits four levels down, it will be found mostly by search, if at all.
• Uneven depth is a signal. When one section goes four levels deep and the others stop at two, that section is either much more important or poorly organised.
• A single child under a parent is often a merge waiting to happen. A Services section with one service is just a service page.

The diagram makes both measurements visible without counting. A tree that sprawls sideways or drips downwards looks wrong on the canvas, and that visual discomfort is usually justified.

Not every page needs to sit in the main tree. Footer pages such as privacy, terms and accessibility are better drawn as a small separate group beneath the homepage, so they are accounted for without crowding the sections visitors actually navigate.

Page types and URL labels

A sitemap gets more useful when each box carries two extra pieces of information: what kind of page it is, and what its URL will be. Neither needs much space. A short type label and a path under the page name are enough.

Page types tell the designer and developer how many templates are really needed. A thirty-page site might need only five templates, and the sitemap shows which pages share each one. URL labels do something else: they turn the hierarchy into a decision about permanent addresses. Writing /services/service-a on the diagram is the moment to ask whether that URL will still make sense if the service is renamed next year.

If a redesign changes URLs, write the old path next to the new one on the sitemap. That list becomes the redirect map, and building it from the diagram is far easier than reconstructing it after launch.

Finding orphan and duplicate pages

Most existing websites have pages nobody remembers making. A promotion from three years ago, a landing page for a campaign that ended, a second contact page created when the first one broke. Putting the current site on a diagram, before designing the new one, is the fastest way to find them.

1. Export a list of every URL from the content management system or a crawl of the live site.
2. Draw each page under its parent, using the URL path as the guide.
3. Mark any page that is not linked from the navigation or from its parent. These are orphans.
4. Look for pairs of boxes whose titles mean the same thing: About and Our story, Contact and Get in touch. These are duplicates.
5. Decide for each orphan and duplicate: keep, merge, redirect or delete.

Orphans are not always mistakes. A thank-you page after a form submission is reachable only through the form, by design. The point is to make every orphan a deliberate one. Duplicates are almost always worth merging, because they split search visibility and confuse visitors about which page is current.

Using a sitemap with clients

For agencies and freelancers, the sitemap is one of the most useful documents to agree with a client, and one of the easiest to agree on. Clients who struggle to give feedback on wireframes can usually look at a tree of page names and say what is missing.

• Agree the sitemap before quoting design work. The number of page types is the clearest driver of effort, and the diagram makes it explicit.
• Show it at a size where every label is readable. A sitemap the client has to zoom into will be approved without being read.
• Ask the client to walk through it as a visitor: where would you go to find prices? To book a call? Gaps show up quickly.
• Record changes as new versions of the diagram, not comments in an email chain. The sitemap is the specification.
• Treat additions after sign-off as scope changes. A box added to an agreed diagram is easier to discuss than a page that appeared in a meeting.

A sitemap is not the right tool for showing how a visitor completes a task. That is a user flow: a sequence of screens and decisions, with error paths. The two complement each other. The sitemap shows where pages live; a user flow shows one route through them.

Worked example: redesigning a small services site

Take a consultancy with an eight-year-old website. The brief from the owner is to make it look modern. Before any design, the agency draws the current sitemap.

Step 1: draw what exists

The crawl finds twenty-three pages. Drawn as a tree, the top level has eight items: Home, About, Our story, Services, What we do, Blog, News and Contact. Services has four children, one of them a service the firm stopped offering. What we do has three children that overlap almost entirely with Services. Two landing pages from past campaigns sit at the top level with no links to them.

Step 2: mark the problems

On the diagram, the agency marks the duplicates (About and Our story, Services and What we do, Blog and News), the orphans (the two campaign pages) and the dead page (the discontinued service). Of twenty-three pages, nine are duplicates, orphans or obsolete.

Step 3: draw the proposed structure

The new sitemap has four top-level sections: About, Services, Blog and Contact. About absorbs Our story and gains a Team page. Services keeps the two services that make money, each a detail page from one template. Blog absorbs News. The result is the shape of the website sitemap template shown earlier, plus a privacy page in the footer.

Step 4: map URLs and agree

Every old URL gets a line pointing to its new home, or a note that it will be removed. The owner reviews the diagram in one meeting, adds a case studies section to a later phase rather than launch, and signs off. Design starts with five templates instead of an unknown number, and the redirect list is already written.

The client asked for a modern look. What they also got, before a single screen was designed, was a site half the size with nothing important more than two clicks away.

From sitemap to wireframes and content

Once the structure is agreed, the sitemap becomes a checklist for the next two pieces of work. Each page type needs a wireframe. Each page needs content, and someone responsible for writing it.

Wireframes should follow page types, not pages. If the sitemap shows two service pages built from one template, one wireframe covers both. Keep them low fidelity at first: grey boxes and real headings are enough to test whether the layout works, and anything that looks finished attracts feedback about colour instead.

For content, add a short status to each box on the sitemap: not started, drafted, approved. Late content is one of the most common reasons website launches slip, and a sitemap with status labels shows at a glance which sections are at risk. It also exposes pages that nobody has volunteered to write, which is often a sign the page is not needed after all.

Keep the sitemap current through the build. When a page is added during development, add it to the diagram first. The diagram that was the plan then becomes the record of what was built, which is what the next redesign will need.

Common sitemap mistakes

• Drawing the navigation instead of the structure. A footer link to Privacy is still a page and still belongs on the diagram.
• Mixing pages and sections of a page. A block of client quotes on the homepage is not a page; leave it off or note it inside the homepage box.
• Drawing every blog post. Show the listing and one representative post; the template is what matters.
• Naming pages after internal teams. Visitors look for Pricing, not Commercial.
• Skipping the current-site diagram on a redesign. Without it, orphans and redirects are discovered after launch.

Drawing a sitemap in DiagramDock

DiagramDock includes a sitemap diagram type, a small business sitemap template to start from, and user flow and wireframe types for the next stages. Automatic layout can arrange a large sitemap as a tree, and you choose when it runs. Export to PDF or SVG keeps every page label as selectable text, which helps when a client wants to search a long structure.

Diagrams are stored in your browser rather than on a server, so client work in progress is not uploaded anywhere. There is no shared link for client review; send an exported PDF instead, and keep a workspace backup of the project.