Site Map Diagram Guide: Planning a Website or App Structure

A site map diagram is a bird's-eye view of an entire website or app - every page or screen, arranged to show the hierarchy and the connections between them. Where a wireframe zooms into one screen and a flow follows one journey, a site map steps all the way back to show the whole thing at once. It is the artifact that lets a team agree on scope and structure before building, because you cannot argue productively about what to build until everyone can see the same map of what exists.

This guide covers creating site maps that are genuinely useful for planning: what to include, how to show hierarchy and navigation, and how to keep the map current as the product grows. The workflow uses Atlas Diagram Studio at /diagrams and the wireframe tool at /diagram-tools/wireframe-tool for when you want to connect the map to screen-level structure. A site map is closely tied to information architecture and to the paths in the product-user-flows use case at /diagram-tools/use-cases/product-user-flows, so it rarely lives in isolation.

What a site map shows and why it helps

A site map represents each page or screen as a node and arranges them into a hierarchy - the home or entry point at the top, top-level sections below it, and deeper pages nested under those. The connections show how sections relate and, in richer maps, the primary paths users take between them. The result is a single diagram that answers "what is in this product and how is it organized" at a glance, which is exactly the question stakeholders, developers, and content teams all need answered.

The value is shared understanding and early problem-finding. When the whole structure is visible, gaps and redundancies jump out - a section with no way to reach it, two pages that clearly do the same job, a hierarchy that has grown lopsided. It also makes scope real: a site map with sixty pages tells everyone something a project brief never conveys. Building it in Atlas Diagram Studio at /diagrams means the map is editable and shared, so it becomes the reference the whole team plans against rather than a drawing that ages in a folder.

How to build a clear site map

Start from the information architecture, if you have one, since the site map is largely a visual expression of the IA hierarchy. List the pages, group them under their sections, and arrange them top-down so the hierarchy reads clearly. Keep the labels in the users' vocabulary and consistent, because the site map often becomes the reference everyone uses to name pages. Resist cramming screen-level detail into the map - its job is structure and relationships, and detail belongs in the wireframes it points to.

A few conventions keep site maps readable as they grow. The checklist below captures the ones worth applying consistently.

• Put the home or entry point at the top and let hierarchy flow downward.
• Group pages under their parent section so the levels of the hierarchy are visually obvious.
• Use consistent shapes and a legend so page types - standard page, external link, dynamic template - are distinguishable.
• Label every node in the users' vocabulary and keep naming consistent across the map.
• Show primary navigation connections without drawing every possible link, which would create a tangle.
• Mark pages that need special treatment, like gated, dynamic, or not-yet-built, so scope is clear.
• Keep the map to structure and relationships; leave screen content to the wireframes it references.

Site maps for planning versus existing products

Site maps serve two distinct purposes, and knowing which you are making sharpens it. A planning site map is aspirational: it lays out the structure of a product you intend to build, and its job is to align the team on scope and organization before work starts. Here the map is a design artifact, and you iterate on it - trying different groupings, questioning whether a section earns its place - exactly as you would iterate a wireframe.

An audit site map documents a product that already exists, mapping what is actually there so you can find problems: orphaned pages, redundant sections, structure that has drifted from how users think. This is the first step in a redesign or reorganization, because you cannot fix a structure you have not mapped. Both kinds live comfortably in Atlas Diagram Studio at /diagrams, where you can build the current-state map and then fork it into a proposed future-state map, comparing the two side by side to plan the migration.

Keeping the map alive

A site map is most useful when it stays current, and products add pages constantly. A map drawn once at kickoff and never touched becomes fiction within months, and a fictional map is worse than none because people plan against it. The fix is to treat the site map as a living document - updated as pages are added or restructured - rather than a one-time deliverable. When it lives in an editable, shared tool, keeping it current is a quick edit that anyone on the team can make.

Connect the site map to the artifacts below it. Each node can point to the wireframe for that screen, built with the wireframe tool at /diagram-tools/wireframe-tool, so the map is a navigable index of the design, not just an outline. Together with the information-architecture work it visualizes and the flows it structures, the site map becomes the top of a coherent set of UX artifacts. The user-flow diagram guide at /guides/user-flow-diagram-guide and the wireframing beginner guide at /guides/wireframing-guide-for-beginners cover the levels below the map.