Information architecture vs sitemap: what the difference means for government websites

A sitemap lists the pages on a website. Information architecture is the reasoning that decides which pages should exist, what they are called, and how a person gets from a need to the right one. That is the whole of the information architecture vs sitemap distinction, and it is not academic. It is the difference between a website organised around the agency and one organised around the reader.

Watch someone try to pay an infringement notice on a site whose top menu reads "About us, Our Minister, News, Services A to Z, Contact". Every word is accurate. None of them is the thing the person came to do.

That is a structure built from a sitemap and presented as navigation, and it is the most common findability failure on Australian government websites. A sitemap can tell you the payment page exists. It cannot tell you whether anyone will ever reach it.

Across the government sites I have audited and helped consolidate, the pattern repeats: the menu mirrors the org chart, and the user has to work out the org chart before they can work out their task.

What a sitemap actually is

A sitemap is an inventory of pages. In most agencies it is generated straight from the content management system: every published URL, arranged by folder, often exported as an XML file for search engines.

That is genuinely useful. You need it for a migration audit, a redirect plan, or to tell a search engine what exists.

A sitemap answers one question well: what pages do we have? It says nothing about whether that set of pages makes sense to the person using it.

What information architecture actually is

Information architecture is the practice of organising, structuring, and labelling content so people can find what they need and understand where they are. It covers three decisions a sitemap never records: what to call things, how to group them, and what path someone follows from a task to a page.

A sitemap can tell you a page called "Concessions and rebates" exists. Information architecture asks whether a person trying to lower their power bill would ever click those words, where that page should sit, and what belongs beside it.

Information architecture answers the harder question: how does a person reason their way to the right page? That is a design decision, not a system export.

Why treating the sitemap as the IA fails

When a team builds navigation directly from the sitemap, the structure inherits the shape of the organisation. Divisions become top-level menu items. Programs become sections. The result reflects who owns the content, not what anyone came to do.

Users do not think in divisions. Someone renewing a licence does not know, and should not need to know, which branch administers it.

A structure that mirrors the organisation forces the user to understand the organisation before they can use the website. That is the tax a sitemap-as-navigation quietly charges every visitor.

The three mistakes this produces

The top navigation is the org chart

If your main menu names departments, teams, or programs, it was built from a sitemap. Rewrite the top level around the small number of things people actually come to do.

Every program has its own front door

Duplicated entry points are the classic symptom. Three teams each publish a "how to apply" page for overlapping services, and the reader meets three near-identical pages with no way to tell which one is theirs. Information architecture decides there is one authoritative path.

Labels are written for the agency, not the user

"Client service portal" and "Community access framework" are names the organisation uses about itself. Information architecture replaces them with the words the reader would actually type or say.

Information architecture vs sitemap: the test that tells them apart

Here is a test you can run this week. Ask someone who has never used your service to predict, from your top-level labels alone, where they would find a common task.

If they can only guess correctly by already knowing which part of the agency owns it, you have published a sitemap and called it navigation.

The Digital Service Standard expects services to be built around user needs, and the Style Manual's guidance on structuring content sets out how to group and label content so people can find it. Neither is satisfied by a tidy list of pages.

Before your next redesign, ask one question: does our navigation describe how we are organised, or how our users think? A sitemap can only ever answer the first.

Photo by Shomitro Kumar Ghosh on Unsplash.