Start with the decisions a sitemap should support
A sitemap is a list or diagram showing the pages a website will contain and how they relate to one another. It is not a page design or a complete navigation menu. Making one first helps a small team agree on the site’s scope before time is spent choosing layouts, writing polished copy or building templates.
Begin by naming the website’s main purpose and the actions visitors should be able to take. A community organization, for example, might need people to understand its programs, check eligibility, find an event and get in touch. Those tasks are more useful starting points than a list of departments. Write down the audiences and their likely questions, then keep the list nearby as you plan pages.
Inventory what you already have
If the organization has an existing site, make a simple spreadsheet with one row per page. Record the page title, its location, its intended audience, its purpose and what should happen to it: keep, revise, combine or remove. Include useful documents and forms that visitors reach through the site. You do not need perfect analytics to spot obvious problems, such as several pages answering the same question differently.
For a new site, inventory the information held elsewhere: brochures, frequently answered emails, event details and staff contact information. Separate material visitors need from material the organization merely has. A long internal history may be valuable to preserve, but it may not need a prominent page. Flag anything whose owner or accuracy is uncertain rather than carrying it into the new site without review.
Group pages around visitor tasks
Put each proposed page on a card or spreadsheet row, then group related pages under plain-language headings. For the community organization, a first pass might be Home, Programs, Events, About and Contact. Under Programs, each distinct service could have its own page if it needs a clear description, eligibility details or a different next step. If two topics can be explained well together, one page may be easier to maintain than two thin pages.
Give each page a job. A program page might explain who it serves, what to expect and how to ask for help. An events page might help visitors find upcoming activities and practical attendance details. This exercise often reveals gaps: perhaps the site invites people to volunteer but provides no explanation of the commitment or way to enquire. Add missing pages because they serve a real task, not because a menu looks too short.
Keep labels recognizable to people outside the organization. Visitors may not know an internal program name or departmental abbreviation. You can still use those names in the page content while choosing navigation labels that describe what people will find.
Sketch the hierarchy, then walk through it
Draw the home page at the top and place major sections beneath it. Add individual pages under the section where a visitor would most naturally look for them. Start with one likely home for each page; links within the content can connect related pages across sections later. Avoid adding levels simply to make the diagram tidy. If an important answer sits behind several vague labels, reconsider the grouping.
Test the draft with a few realistic prompts: “Where would I find out whether I can use this service?” or “How do I contact someone about an event?” Ask someone who did not build the sitemap where they would look first, and notice any hesitation. This is a check of the structure, not a test of the person. If several routes seem equally plausible, clarify the labels or decide where the primary answer belongs.
Make sure essential routes do not depend on a visitor seeing a visual cue alone. Clear page names and a predictable hierarchy will also make later decisions about navigation, headings and accessible links easier.
Turn the sitemap into a workable page plan
Once the structure is settled enough to proceed, add a short brief beside each page: its audience, main question, desired next step, content owner and material still needed. Mark which pages must launch and which can wait. This turns the sitemap into a practical sequence for writing and design, rather than a diagram that is filed away after a meeting.
Before designing templates, look for recurring page types. Several program pages may share a structure, while Contact and Events need different information. Also note where a form will collect information, who will maintain it and whether a simpler contact route would do. After launch, the sitemap can remain a reference for reviewing confusing navigation paths or pages that no longer serve a clear purpose. It should be stable enough to guide the build, but flexible enough to change when visitor needs become clearer.
