August 20, 2026·7 min read·Updated September 5, 2026

Who Owns the Sitemap?

Kaung Ye Marn

Published August 2026 and updated on 5 September 2026. Two section headings were shortened and a link added to a related piece on audit scoring. Nothing in the original argument has changed.

Ask who owns the sitemap and you will be pointed at a developer. That answer is the whole problem, and it survives every rebrand because nobody thinks to question it. A developer can build any structure you name. Naming it is not their job. What happens instead is that the structure gets inherited. The new site launches with a fresh typeface, a better hero image, and the same navigation, because the only version of the structure anyone had was the old one and rebuilding it was faster than reopening an argument that had already been settled by attrition. The visual identity moves on. The argument the site makes about what the company does stays exactly where it was three years ago, and nobody notices, because everyone inside the company already knows their way around. That argument is what a sitemap actually is. Every grouping decision says these things belong together and those do not. Every top-level item says this is one of the small number of things we do. A visitor reads all of it before they read a single word of copy, and they act on it whether or not anyone meant them to.

Read the page names

You can spot an inherited structure in about a minute. Look for a top-level item named after a department rather than a problem. Look for a page called Solutions, which is where things go when nobody could decide what they were. Look for a services page that lists divisions, each with its own sub-page, in the order those divisions appear on the internal org chart. None of that is a naming mistake. It is the org chart, published. The reason it fails is not that the words are ugly. It is that a visitor has no idea how your company is organised internally, and no reason to care. Somebody arriving with a problem is holding one question and looking for the page that answers it. When your structure is arranged by who does the work rather than by what the work solves, that person has to reverse-engineer your staffing before they can find anything, and most of them will not. They will go back to the search results, which are full of competitors, and the page you spent a month writing will never be read.

Build it from the question

The move is to write down every service the way a buyer would ask for it, in their words, out loud. Then group those by the problem being solved rather than by the team that solves it. Navigation comes last, after the groups exist, because a nav is a summary of a structure and you cannot summarise something you have not built yet. The first step is less obvious than it sounds, because internal names are sticky. A service acquires its name in a meeting, then that name goes on a slide, then into a proposal template, and after two years everyone has forgotten that no customer has ever used it. The gap looks like this:

What it is called inside	What the buyer actually asks for
Enterprise Risk Advisory	"Someone to tell us what could go wrong"
Managed Services	"Can you just run it for us?"
Digital Transformation	"Our systems do not talk to each other"
Strategic Communications	"We need to say something about this by Friday"

Neither column is wrong. They are two different jobs. The left column exists so a proposal can be priced and a team can be staffed, and it does that job well. The right column is what someone types into a search box at eleven at night, and a site organised around the left column will never meet them. Grouping by problem is where the real work sits, and it is uncomfortable, because problems cut across teams. One buyer question will pull in two departments that do not currently share a page, or a slide, or a manager. The structure is telling you something true about the business at that point. Most people flinch and reorganise around the departments again, which is how you end up back where you started with a nicer font. Doing the navigation last matters more than it seems. When the nav is decided first, every subsequent decision is a negotiation about which existing box a thing fits into, and the boxes were the problem. Build the groups, live with them for a week, and the nav mostly writes itself, usually with fewer top-level items than anyone expected to defend.

Who has actually done this

Exera is a security and risk management firm that rebuilt its website around a new brand identity. The structure it had was not designed. It had grown organically over years, one page at a time, each addition reasonable when it was made, until it no longer matched how the business organised its services at all. Visitors could not reliably find the right page, and the brand could not tell a coherent story about itself, which are the same failure described from two directions. The revamp treated the sitemap as the first deliverable rather than a technical artifact handed over at the end. The information architecture was restructured to match the rebrand, page-level content was rewritten against the new positioning, and the site's structure was mapped to how visitors actually search for security and risk management services rather than how the org chart happened to be arranged internally. The writing came after that, which is the part most projects get backwards. There is a detail in that engagement worth stealing regardless of what you sell. The rebrand made the restructure possible. Nobody in a stable organisation wants to renegotiate who owns which page, but a rebrand is already a period where every assumption is on the table, and the structure can be reopened without it becoming a political event. If you are planning a visual refresh and you know the structure is wrong, that window is the cheapest one you will get. A technical audit will catch the downstream symptoms of all this, scoring an absent sitemap or one that robots.txt never references as deductions against the site. What no audit records is that the cause was a vacancy rather than a defect, which is one of several things a score quietly leaves out, covered in the denominator nobody checks.

Your turn

This takes twenty minutes and needs nothing but a text file. Open your site and write down every service exactly as the navigation names it. Do not tidy the wording. Then open your last five enquiries, whatever form they arrived in, and write down how each person described what they wanted, in their words, including the vague ones. Put the two lists side by side. Where the words match, the structure is doing its job. Where they do not, you have found a page that only makes sense to someone who already works there, and the fix is not a better headline on that page. It is that the page is in the wrong group, or the group should not exist. Do that before you approve a design, because after the design is signed off, the structure is settled whether or not anyone decided it.

Share this post:

Who Owns the Sitemap?

Read the page names

Build it from the question

Who has actually done this

Your turn

Recent posts