What a sitemap is

A sitemap is the list of every page a website will have and how those pages relate to one another as parents and children. It is agreed before anything is designed, and it is the document a quoted page count is derived from.

Two entirely different documents share the name. The one described above is a planning artefact for people. The other is an XML file listing published URLs so that search engines can discover them. They are not versions of each other and neither can be substituted for the other. This page is about the first; the second is covered in the search readiness guides.

What the planning sitemap contains

At minimum, one row per page, with three columns.

Column	What goes in it	Why it matters
Page	The working name of the page	Becomes the navigation label and usually the URL
Parent	The page it sits under, or “top level”	Defines depth and the breadcrumb trail
Purpose	One sentence on what the page is for	The test for whether the page should exist

The purpose column is the one that gets dropped and the one that does the work. A page whose purpose sentence is “to have a page about that” is a page that will be written badly, because nobody can tell when it is finished.

Some suppliers add a fourth column for the content owner: the named person who will supply the words and images for that page. That single addition prevents the most common cause of a stalled build, which is content that everyone assumed somebody else was writing.

What it is used for

Pricing. Scope on a website project is expressed as pages and features. The sitemap turns a vague brief into a countable list, and the count is what most quotes are built on. This is also why a page added after the sitemap is agreed is a variation rather than a favour.

Content planning. Each row becomes a writing task with an owner and a deadline.

Design. A sitemap reveals how many distinct page types exist. Twelve pages using three templates is a smaller design job than twelve pages using nine.

Navigation. The top level of the sitemap usually becomes the main menu. If the top level has eleven items, the menu will have eleven items, and that is a decision worth making deliberately rather than by accident.

The order it is built in

A sitemap is derived, not invented. The sequence that produces a defensible one runs backwards from the business rather than forwards from the pages.

1. List what the business sells or does. Services, products, programmes.
2. List who buys each one. If two audiences need different information about the same service, that is a candidate for two pages.
3. List what a buyer needs to know before they act. Proof, price, process, location, credentials.
4. Group those needs into pages. A page is a group of related needs, not a topic.
5. Nest the groups. What is a top-level item and what sits beneath it.
6. Name each page in the words a customer uses.

Steps 1 to 3 are business knowledge and cannot be outsourced. Steps 4 to 6 are the supplier’s craft. A supplier who starts at step 4 without doing 1 to 3 with you is building a structure from a template, and it will fit the template rather than the business.

The sitemap is the cheapest document in the project to change

Changing a row in a sitemap costs a keystroke. Changing the same decision after design costs a redraw. After build, it costs a redraw and a rebuild. After launch, it costs a redraw, a rebuild, a redirect and a period during which links pointing at the old address are broken.

That cost curve is the whole argument for spending an hour on the sitemap. It is also the reason a supplier who wants sign-off on the sitemap before starting design is protecting both parties rather than being bureaucratic.

What a good one looks like when you read it

Read the sitemap you are given against four questions.

• Can you say what each page is for in one sentence? If not, the page is unfinished as a decision.
• Is any page’s purpose the same as another page’s? Two pages competing for the same job will both be thin, and on a live site they compete in search results as well.
• Is anything at the top level that is not a thing a customer wants? Awards, values statements and history are usually not top-level items.
• Is anything missing that a customer would look for and not find? Price information, service areas, and how to get in touch are the three most commonly absent.

What it does not decide

A sitemap does not decide what the pages look like, how long they are, what they say, or which of them a person will land on first. It decides only what exists and where it sits. Suppliers occasionally present a sitemap as though it settles the design; it does not, and treating it as a design deliverable is how a project ends up with an approved structure and no approved content.

It also does not decide URLs, although it strongly suggests them. That decision has its own consequences and is covered on URL structure.

How this fits the rest of a project

The page count that comes out of a sitemap is one of the main drivers of a quoted figure, and the relationship between the two is not linear — nine similar pages cost less than five different ones. The drivers are set out on what drives the cost of a website, where every figure states its GST treatment.

If you have not yet written anything down, write a brief any supplier can quote against produces a document that contains a first draft of the sitemap along with everything else a supplier needs in order to quote against the same scope as their competitors.

What to do next

Write your own sitemap before you receive one. It will be wrong in places, and that is the point: the places where it differs from the supplier’s version are the conversation worth having. The page count question is the next decision, and which pages a business site needs is the standing list to check yours against.