How to Plan a Website Sitemap Around the Customer Journey

What questions do your customers arrive with?

Most sitemaps are drawn from the inside out. Someone opens a document, types Home, About Us, Services, Products, Blog and Contact, then arranges the company’s departments underneath. The result is a picture of the organisation. Visitors did not come for the organisation. They came with a question, usually on a phone, usually with somewhere else to be.

So begin with the questions. Ask the people who answer the phone, read the WhatsApp messages and reply to the enquiry inbox what they are asked every week, in the customer’s words rather than yours. Most businesses find the same eight or ten questions returning. Those questions are the first draft of the sitemap.

• Do you do the specific thing I need, for a business or a home like mine?
• What does it cost, or what does the price depend on?
• How long does it take, and what do you need from me to start?
• Have you done this before, and can I see the work?
• Who are you, where are you, and can I come and look?
• What happens if something goes wrong after I pay?
• How do I begin, and who will I actually be dealing with?

Which journeys does the site need to serve?

The same website is read by people on very different errands. A first-time buyer from search wants proof you handle their case. Someone sent by a friend wants reassurance and a rough price. A customer of three years wants a spare part and a phone number. Each needs a different first page and a different next step, and a sitemap built only for the first-time buyer sends everyone else hunting through the menu.

Write out three or four journeys before you draw any structure. Not personas with invented names and stock photographs: just an audience, what brought them, what they must find, and the step you would like them to take.

Journeys also show what does not need a page of its own. If no journey calls for the founder’s letter, it can live inside the About page.

Give every page one job

A page with one job is easy to write, easy to name and easy to find. A page with four jobs reads like a brochure assembled by committee, and it is the page people leave. Before anything is designed, write the job of each page in a sentence: “This page convinces a factory owner in Coimbatore that we can service their machine within a day, and gets them to request a visit.”

• One question answered, one audience served, one next step offered.
• If two pages answer the same question, keep the better one and redirect the other.
• If a page exists only for a search phrase, it will read that way to people too.
• If a page cannot be described in one sentence, it is probably two pages.
• If nobody in your team can say who a page is for, it is a candidate for removal.

The exercise usually shrinks the sitemap, which is the point. It also finds the missing pages: the basis on which you price, the areas you deliver to, the page a returning customer has never had.

Label the navigation in your customers’ words

Navigation labels are the shortest and most-read copy on a website, and clever ones are expensive. “Our Universe” and “Capabilities” sound better in a brand presentation than on a phone. The test is simple: read a label on its own and see whether a stranger could guess what sits behind it.

Search engines apply a similar test. Google’s link best practices say good anchor text is “descriptive, reasonably concise, and relevant to the page that it’s on and to the page it links to”, and give “click here”, “read more” and “website” as examples of text to avoid. Menu labels, in-page links and buttons all benefit from the same discipline: name the destination, not the gesture.

Use the words your customers use, even when they are duller than your internal vocabulary. “Spare parts” beats “Aftermarket”. “Prices” beats “Investment”. “Book a table” beats “Reserve your experience”. Our own Solutions page is grouped this way, around the problem someone arrives with rather than the systems we build.

How deep should the structure go?

The rule that everything must sit within three clicks is folklore. People will take four steps when every step obviously leads somewhere useful, and abandon two when the labels are vague. Depth is not the problem; unclear paths are. Breadth has its own cost: a menu of fourteen items is a list nobody reads.

What does matter is that pages can be reached. Google’s guidance is blunt: “Every page you care about should have a link from at least one other page on your site.” For catalogues, its ecommerce structure guidance adds that if category pages do not link directly to all the products in a category, the crawler may never find them. Pages that exist only behind a filter, a search box or a link inside a PDF are hard for people to find and hard for search engines to see.

• Every page reachable by an ordinary link, not only through search or a filter.
• Section pages that describe the section, not just list what is under it.
• Menus of five to seven items, with the detail one level down.
• Links inside the text of a page: a category page that names its products.
• A footer that carries what people look for last: hours, address, careers, policies.

Where do the conversion points belong?

A conversion point is any place a visitor can act: an enquiry form, a WhatsApp button, a phone number, a booking, a download. They belong where the question has just been answered, not only at the foot of the page. Someone who has just read that you service their machine model is ready; someone scrolling past a wall of text to find a form is not.

Give each page one primary action, named for what it does, with a quieter alternative for people who will not fill in a form. Then decide the unglamorous part: which inbox each form reaches, who owns it, and how quickly a reply is promised. A sitemap that plans nine forms into one unread mailbox has planned nine disappointments.

Is an XML sitemap the same as your site structure?

The word does two jobs, and mixing them up wastes meetings. The planning sitemap is the diagram your team argues over. The XML sitemap is a file for search engines. Google describes it as a file where you provide information about the pages, videos and other files on your site, and the relationships between them.

It is useful, and it is not a substitute for structure. Google says you might need one if your site is large, is new with few links pointing to it, or carries a lot of rich media; and that you might not need one if your site is small, meaning about 500 pages or fewer, and is comprehensively linked internally. It also says plainly that a sitemap “doesn’t guarantee that all the items in your sitemap will be crawled and indexed”. Most content systems generate the file. Submit it, then spend your planning time on the human sitemap.

How do you test a sitemap before anything is designed?

A structure can be tested with nothing but a list of page names, which is the cheapest testing you will ever do. Give five people three real tasks and ask them where they would tap. You will hear which labels mean nothing within minutes, and before a designer has drawn a screen.

1. Write the page names as a plain list or on cards, with no design and no logo.
2. Ask five people outside the business to complete three tasks a real customer would.
3. Watch where they hesitate, go back or ask you a question. Do not help them.
4. Rename whatever confused two or more people. Move whatever nobody found.
5. Run it once more with the revised list. Two small rounds catch most of it.

Once the site is built, keep the navigation where people left it. WCAG 2.2 asks, at Level AA, that navigational mechanisms repeated across pages occur in the same relative order each time, unless the user changes them. That helps people using magnification or a screen reader, and it helps everyone else remember where things are.

Structure is the cheapest thing to change now and the most expensive to change later. It is why our Website Design & Development work agrees the sitemap, the journeys and the copy before any page is designed, and why we argue for strategy before screens.