process & strategy
Sitemap
What is a sitemap in UX?
A sitemap is a diagram of a product's structure - its pages or screens arranged in a hierarchy that shows how they group and nest and how they relate to each other. It makes a site's information architecture visible at a glance, so you can see the whole organisation, judge whether it's logical, and spot where things are buried, duplicated or in the wrong place.
Also known as: sitemap, site map, site structure
Prefer to watch?
Watch the recap 1:04
The demo
The same pages of a shop's site, two ways: a flat list, and a sitemap. One hides the structure; the other makes it obvious - including a page that's buried too deep. See which lets you judge the IA.
What this demo shows (text version)
The same set of a shop's pages is shown two ways. As a flat alphabetical list you can read the page names but can't tell how the site is organised - what groups under what, how deep things go, or whether the structure is sensible. As a sitemap, the same pages appear as a hierarchical tree showing groups and nesting, which makes the information architecture obvious - including a page ("Returns") buried several levels deep where users won't find it.
That's a sitemap: a diagram of a product's structure that makes its information architecture visible, so you can judge the grouping, spot pages that are buried, duplicated or orphaned, and fix the structure on paper before it's built. It underpins navigation and is far cheaper to rearrange as a diagram than as a live product.
A sitemap turns invisible structure into something you can see and critique. By laying out all the pages and how they nest, it reveals the information architecture: whether the grouping makes sense, whether the hierarchy is too deep (things buried) or too flat (everything competing), where content is duplicated or orphaned, and whether the labels match how users think. It's a planning and communication tool - cheap to draw and rearrange before anything is built - and it underpins navigation, because the structure people have to move through is the structure the sitemap describes. Design the structure on a sitemap first; fixing IA after launch is far costlier.
As a flat list of pages, you couldn't tell how the site was organised or whether it made sense. As a sitemap, the structure - the groups, the hierarchy, the buried page - is obvious at a glance. That's what a sitemap is for: making information architecture visible so you can judge and fix it on paper, before it's expensive to change in a built product.
A sitemap visualises information architecture - the way content is grouped, labelled and nested into a hierarchy. It's typically a tree of pages/sections showing parent-child relationships and depth, built early in a project to plan structure and align the team, and sometimes maintained as documentation. (This is distinct from the XML sitemap used by search engines, which lists URLs for crawling rather than communicating structure to people.)
Seeing the whole structure at once surfaces problems that are invisible page by page: a hierarchy too deep (important content buried several clicks down), too flat (no grouping, everything competing), illogical or inconsistent grouping, duplicated content, orphaned pages with no clear home, and labels that don't match users' mental models. Methods like card sorting and tree testing feed and validate the structure a sitemap captures.
Sitemaps are a cheap, high-leverage planning tool: rearranging boxes on a diagram is trivial compared with restructuring a built product, where IA changes ripple through navigation, URLs, content and links. They directly underpin navigation design - the menus and paths people use reflect the sitemap's structure - so getting the structure right on a sitemap, validated against how users actually categorise things, prevents costly findability problems later.