Sitemaps & IA Documentation

The full lesson

Before anyone designs a navigation menu, the team needs to answer a deceptively hard question: what pages exist, how are they grouped, and how does a person move between them?

Sitemaps and IA documentation answer that question. They act as a shared contract between researchers, designers, developers, and content strategists — a stable reference that survives handoffs, pivots, and new team members.

Getting this documentation right early pays off in a big way. When IA is unclear at the start, teams build navigation for a structure that keeps shifting under them, content gets orphaned, and launch week turns into a scramble. When it is clear, every downstream decision has a solid foundation.

What a Sitemap Actually Is

A sitemap is a hierarchical diagram that shows every section, page, and major state of a product, along with the parent-child relationships between them.

It is not a wireframe (no layout detail), not a flowchart (no task paths), and not a navigation menu (it is a design input, not a design output).

The standard visual convention uses rectangular nodes connected by lines:

• Level 0 — the root (homepage or app shell)
• Level 1 — primary sections (what the main navigation reflects)
• Level 2 — sub-sections or category pages
• Level 3+ — individual content or feature pages

Each node carries a unique page ID (commonly “1.0”, “1.1”, “1.1.1”), a page title, and optionally a one-line description. The ID system lets every other document — wireframes, content inventories, tickets — reference a page without any ambiguity.

Visual sitemaps vs. spreadsheet sitemaps

Both formats live side by side in professional practice and serve different audiences:

For most products under roughly 100 pages, a visual diagram in Figma — with a linked Notion or Airtable sheet for metadata — is the modern default. Keeping the Figma file in the same workspace as wireframes and prototypes reduces context-switching during handoff.

Sitemap Conventions Worth Knowing

A handful of symbols have become nearly universal. Teams that skip them produce diagrams that need interpretation every time someone reads them.

• Solid line — standard parent-child relationship (user navigates down the hierarchy)
• Dashed line — cross-link (a page reachable from multiple parents without being a child of both — a polyhierarchy shortcut)
• Double border or badge — template page (this node represents a repeating pattern, e.g., a product detail template used across 300 products)
• Lock icon or badge — authenticated-only page
• Globe or language badge — localized variant
• Archive/off icon — planned for deprecation

IA Documentation Beyond the Sitemap

The sitemap is the centerpiece, but it rarely travels alone. A complete IA documentation package for a mid-to-large project typically includes these four artifacts.

Content inventory

A content inventory is a structured spreadsheet that lists every existing page or content item. Typical columns include URL, page title, content type, owner, last-updated date, and a recommended action (keep, rewrite, merge, delete, redirect).

A content inventory is the foundation of any migration or redesign — you cannot design a new IA without knowing what content you already have.

In modern practice, teams pair the inventory with a content audit. The inventory tells you what exists; the audit tells you how good it is — accuracy, freshness, and alignment to user needs. Running both as a combined Airtable or Notion spreadsheet lets the IA feed directly into editorial planning.

Navigation schema

The navigation schema maps IA nodes to actual navigation UI. It answers questions like: which Level 1 nodes appear in the primary nav? Which appear only in the footer? Which are accessible only via search or contextual links?

This is where IA structure and UI design meet. A navigation schema prevents the common mistake of treating the sitemap as a menu.

URL and metadata schema

For web products, each IA node should have a proposed URL pattern. Document this early — URL structures are expensive to change after launch because of redirects, SEO equity, and bookmarks.

A simple table mapping page IDs to URL patterns and meta-description templates is enough. Agree on slug conventions with the dev team before anyone starts writing content.

Redirect map

On any redesign or migration, a redirect map — old URL to new URL, with a note when there is no equivalent destination — is a first-class deliverable. It belongs in the IA documentation package, not as a last-minute dev task.

Living Documentation: Keeping Sitemaps Current

The most common failure mode for IA documentation is simple: it gets created, reviewed, and then abandoned. Three months into development, the sitemap reflects the original design while the actual product has moved on. Teams stop trusting it and navigate by memory and tribal knowledge.

The fix is treating the sitemap as a living document with a lightweight change protocol:

1. Single source of truth — one file, one URL. Not “sitemap v3 final FINAL (2).fig.”
2. Version history — use Figma version history or git-tracked files (Miro also supports version snapshots). Give every significant structural change a named version, such as “Post-tree-test revision, 2026-03-12.”
3. Change log section — a dedicated page in the Figma file or a sheet tab that records what changed, why, and who approved it.
4. Linked to tickets — when a structural change is approved in a design review, the relevant Jira or Linear ticket links to the sitemap version that reflects it. This creates a traceable audit trail.
5. Review cadence — schedule a lightweight sitemap review at the start of each sprint or milestone, not just when something breaks.

Connecting Sitemaps to Research

A sitemap is a hypothesis about how users expect content to be organized. Treat it as one until research validates it.

The two methods most directly tied to IA validation are card sorting (which shapes the initial structure) and tree testing (which validates it). A well-documented IA workflow looks like this:

1. Conduct an open card sort → identify mental model clusters
2. Draft sitemap v1 based on those clusters
3. Run tree testing on v1 → identify findability failures
4. Revise the sitemap → document what changed and why
5. Run a second round of tree testing if the failure rate was high (above 15–20% on key tasks)
6. Lock the structure → hand off to navigation UI design

Capture each round of changes — and the research that motivated them — in the IA documentation. A note like “We moved Billing from Account Settings to a top-level node because tree testing showed 60% of users looked there first” is worth preserving. It stops future team members from undoing validated decisions without understanding what that decision cost.

Handoff: From IA Documentation to Design and Dev

IA documentation is only valuable if the people building the product actually use it. Handoff discipline matters.

To UI designers: the sitemap defines what pages exist and their hierarchy. Wireframes should reference page IDs in their file names and annotations. When a wireframe shows a navigation component, it should link back to the navigation schema — not reinvent the structure from scratch.

To content strategists: the IA node list drives the content brief backlog. Each node at Level 2 and below needs a content brief that specifies the page’s purpose, audience, key messages, and SEO target. Number the briefs to match IA node IDs so the content pipeline stays organized.

To developers: the URL schema and redirect map are the developer-facing IA deliverables. Modern handoff via Figma Dev Mode or Storybook handles component-level detail well — but IA-level structure (routing, page templates, dynamic route patterns) needs its own document: a technical IA spec, which can be as simple as a Markdown file or Notion page.

What to include in a technical IA spec

• Route patterns (e.g., “/products/[category]/[slug]”)
• Template assignments (which pages share a layout template)
• Authentication requirements per page
• Dynamic vs. static page designation
• Pagination or infinite-scroll behavior per list page
• Search indexability notes (noindex pages, canonical signals)

Common Mistakes and How to Avoid Them

Conflating navigation with IA. Design the sitemap before designing the navigation UI. Building menus first and deriving structure from them produces navigation that reflects designer convenience, not user mental models.

Over-deep hierarchies. Evidence consistently shows that users prefer breadth over depth. A structure four levels deep is almost always better served by flattening to three levels and improving labeling. Every extra level adds cognitive overhead and navigation cost.

Undocumented polyhierarchy. Cross-linking the same content under multiple parents is sometimes the right call — for example, a product that fits in two categories. But if it is not explicitly documented with dashed-line conventions and a note in the IA spec, developers will create duplicate pages and SEO will suffer from competing canonical signals.

Treating the sitemap as a client-approval deliverable rather than a working document. Polishing a sitemap for a client review and then never updating it is cargo-cult IA. The document exists to coordinate the team, not to collect sign-off theater.

Skipping the redirect map on redesigns. Every missed redirect is a broken link, a 404, and a lost SEO signal. On large migrations, automated crawl tools (Screaming Frog, Sitebulb) can generate the old-URL inventory — but the mapping logic still requires human IA judgment.