A sitemap drawn after the design is often a record of decisions that have already been made. A useful site structure starts earlier: it connects visitor tasks to pages, content types, navigation, and the work needed to launch each part.
The output should be understandable to a designer, developer, content editor, and project owner. It need not begin as a polished diagram. A shared table, a simple hierarchy, and a few realistic task flows can expose missing content and confusing labels before they become expensive to change.
Separate the artifacts
These pieces describe different aspects of the same site:
- A page inventory records what exists or is planned, why it exists, who owns it, and its status.
- A hierarchy groups pages and shows their primary relationships.
- Navigation and contextual links show how a person can move between pages.
- A content model describes recurring objects and fields, such as services, products, or articles.
- URLs and migration mappings identify addresses and record what should happen when an existing address changes.
A working page map is not the same artifact as an XML sitemap used by search engines. Also, an item's URL path does not need to reproduce every menu relationship. Agree on each artifact deliberately rather than using one diagram to answer every question.
Start with journeys, not department names
Write the organization's objective and the visitor's task separately. “Receive inquiries” is a business objective. “Understand the repair options and find a way to book” is a visitor task.
List the information needed to complete each task and the likely starting points. Someone may enter on a specific service page from a search result, arrive at the homepage from a recommendation, or return directly to a contact page. A design that only works when everyone starts at the homepage will miss those other routes.
Use actual questions from customer support, interviews, site search, or existing analytics when available. If those sources don't exist yet, record assumptions as assumptions. Ask stakeholders what they need the site to support, then validate the language and paths with representative users.
Build an inventory with purpose and ownership
The following is a fictional example for a bicycle workshop. It illustrates a planning method; it does not describe a real business or measured behavior.
| ID | Page | Visitor task | Related page | Launch? |
|---|---|---|---|---|
| P01 | Home | Understand the offering and choose a path | Services and contact | Yes |
| P02 | Services | Compare available work | Individual services | Yes |
| P03 | Bike inspection | Understand scope and terms | Booking | Yes |
| P04 | Maintenance | Choose an appropriate service | Booking | Yes |
| P05 | Booking | Select a way to contact the workshop | Services and contact | Yes |
| P06 | Contact | Find location and hours | Main navigation | Yes |
| P07 | Care guides | Learn to maintain a bicycle | Related services | Later |
Add the content owner, source materials, dependencies, and acceptance criteria to your real inventory. For an existing site, include the current URL and a proposed decision: keep, update, merge, or remove after review.
Ask a simple question of every row: who needs this page, and what will they do after reading it? A page with no clear purpose or owner might be unnecessary in the first release. On the other hand, a small but essential page may be missing from a diagram built only around marketing sections.
Group by visitor language
Organize content according to tasks and concepts your audience recognizes. Internal reporting lines may not be useful navigation labels. “Services,” “Delivery,” and “Contact” may be clearer than an organization's internal team names, but the right words should be checked with the people who will use them.
For the fictional workshop, one possible primary hierarchy is:
- Home
- Services
- Bike inspection
- Maintenance
- Booking
- Contact
- Care guides, in a later phase
The tree describes primary relationships, not all permitted journeys. A service page can link directly to booking, and a guide can link to a relevant service where appropriate. Do not add levels merely to make a diagram symmetrical, and don't treat a particular number of clicks as proof of usability. Test whether the available choices make sense for the task.
Design paths beyond the menu
Take three important tasks and write the route from a plausible entry page to a result. For example:
- A visitor lands on “Bike inspection.”
- They can see the actual scope and terms.
- They follow a clearly labeled link to booking.
- They choose an available contact method.
- The system explains what happened after submission or what to do if it failed.
Now try the same task from the services listing and the contact page. Can the visitor return to compare services without losing context? Are there pages with no sensible onward route?
Main navigation should expose the stable major directions. Contextual links support a specific task within a page. Search and filters can help with larger collections, but they don't repair unclear category names or incomplete content. On narrow screens and with keyboard navigation, preserve access to the same important destinations and check the labels and focus order.
Define page types before estimating templates
A “service” might contain a title, summary, work included, terms, relevant images, and a booking link. A “product” might require a name, price, images, availability, and attributes used in filters. An “article” might have a title, body, author when applicable, date, and related content.
For every field, record whether it is required, who can edit it, where the information comes from, and what happens when it is missing. A template can serve many pages without making their content identical. List relationships too: for example, which service a guide refers to, or which categories can contain a product.
This model reveals dependencies. A category filter cannot be designed responsibly before someone agrees on the underlying product attributes. A service page may depend on approved terms. An import may require existing records to be cleaned up before development can be estimated.
Set URL rules and plan a migration
Agree on readable, stable addressing rules for new pages and on who can change them. For an existing site, prepare a mapping from old addresses to their intended new destinations. Decide which pages remain, merge, or retire; implement suitable redirects where appropriate and test the final destinations and internal links.
Similar or filtered URLs deserve a decision rather than an automatic proliferation of pages. Identify which variations have a user purpose and coordinate search requirements with the navigation design. Search visibility is one consideration; it should not override the need for a coherent visitor journey.
Test the structure before visual design is final
Give participants who resemble the intended audience a task such as “Find the conditions for a bike inspection.” Let them choose among the proposed labels without coaching them. A text-only hierarchy or simple clickable prototype is enough to reveal many naming and grouping problems.
Record where a participant starts, which labels they choose, and what they expected to find. If several people look in the same unexpected place, consider whether the label, grouping, or missing cross-link caused the confusion. Revise the specific issue and test again.
A small qualitative session helps uncover problems; it is not statistical proof that every visitor will behave the same way. Include real content lengths, narrow screens, and keyboard use when checking a more complete prototype.
Hand off a maintained decision set
Before development begins, provide the team with:
- An agreed page inventory and hierarchy with stable identifiers.
- Key tasks, entry points, links, and expected results.
- Content types, required fields, relationships, and editing responsibilities.
- URL conventions and a migration map when replacing an existing site.
- Content sources, external dependencies, and the scope of the first release.
- Acceptance tasks for navigation, search, forms, and smaller screens.
Assign an owner for the map and a process for new pages after launch. A structure can evolve, but unreviewed additions should not quietly create duplicate sections or leave important content unlinked.
Start with one page inventory and three real visitor tasks. A clear route through a modest first release is more useful than a large diagram whose pages have no content owner or purpose.
Original Russian article: https://morlix.ru/blog/kak-sproektirovat-strukturu-sayta-do-nachala-razrabotki
Top comments (0)