Every structural decision you make on your intranet comes down to the same question: where should this content live? 

When there's no clear and shared understanding of an answer, content ends up in the wrong place, patterns become inconsistent, and employees stop trusting the intranet to help them find things.

In this article, we share the principles that give you a consistent way to answer that question. Whether it's the start of a project, or whenever your intranet grows or changes.

Put your users at the center

Good information architecture starts with how your employees think, not how your organization is organized internally. Content needs to be stored where users would expect to find it, not just where it's easiest to put it or where the owning team sits.

Before deciding where something lives, set aside questions about which team manages the content and focus on navigation. An employee who needs this information: where would they go first?

❓ Ask yourself: "If an employee needed this content, where would they look for it, and does our current structure match that expectation?"

Organize around subject areas

Departments, locations, and business units are natural starting points, and they're relevant. But a structure that maps directly onto your org chart creates problems over time. The most obvious one: organizations change. When your intranet structure mirrors your org chart, every reorganization requires structural updates.

The more resilient approach is to organize by subject rather than by units. Every department might have a page, but not all content that belongs to a department needs to live there. Onboarding, for example, might span HR, IT, and Locations. It makes more sense as its own area rather than a buried section within each of those departments.

The more your structure reflects stable subject areas, the less maintenance it will need as the organization changes around it.

❓ Ask yourself: Is this content tied to a team or unit, or to a wider subject area that employees would search for regardless of who owns it? Would this decision still make sense if that team were restructured tomorrow?

Choose the right level for each subject area

When deciding where content belongs, remember you have more than two options. Haiilo's structure has multiple levels: pages, communities, apps, and widgets. The right level for a subject area isn't always a new page.

Something you initially plan as a standalone page might fit better as an app group within an existing one, if the content logically belongs alongside what's already there. 

Conversely, an app group that keeps growing might eventually need its own page, or even a set of pages under a dedicated category. Placing content at the right level keeps the overall structure lean and avoids unnecessary navigation layers.

❓ Ask yourself: How much content does this subject area have, and how closely related is it to what already exists? Could it live inside an existing page or community, or has it grown large enough to need its own?

Choose the right format for the right purpose

The choice between a page and a community shapes how employees experience an area. The key distinction is what organizes the space: a subject area with a responsible team, or a group of people with a shared interest.

• Pages are organized around a subject area with a clear owner: a team responsible for the content, and an audience that comes to that page for it. Communication on a page is directed: a department pushes out policy updates, or an employee asks a question relevant to the full audience. It's always oriented around the subject of the page. That clarity of ownership and subject is what makes a page feel structured and reliable.
• Communities are organized around the members themselves. Communication circulates within the space: people post, respond, and build on each other's contributions without a single team or person acting as the authoritative source. A community doesn't need to push content out to an outside audience; the conversation stays within the group, and the group is the point.

A community that functions like a page discourages participation. A page that functions like a community creates noise where there should be clarity.

❓ Ask yourself: Is there a team responsible for a defined subject area with an audience that comes to them for it, or is this a group of people communicating among themselves, with the members as the audience?

Treat categories as labels

Categories let employees filter pages and communities by topic to find what they need more quickly. A page doesn't live in a category the way a file lives in a folder; it's tagged with one so it appears when employees filter by that topic. A page and community can be tagged with multiple categories.

This means categories only work when they're applied consistently. A category that appears on some relevant pages and communities, but not all of them, stops being a reliable filter. Before creating a new one, make sure it's something you'll apply consistently everywhere it logically belongs.

❓ Ask yourself: Does this category make sense as an overarching topic, and will it be applied consistently across all pages and communities where it applies?

Find a clear home for every content piece

Categories describe; pages and communities house. A category signals what kind of content you'll find somewhere. A page or community is where that content actually lives.

Keeping this distinction clear helps avoid two related problems:

1. The catch-all page: A General page that exists because nobody decided where certain content actually belongs, so it's just placed somewhere.
2. The catch-all category: A Miscellaneous label that gets applied when no existing category fits, rather than asking whether the structure needs a real decision on a new category or broader existing category.

Both are symptoms of the same thing: a structural choice that was deferred instead of made. Catch-all areas and labels accumulate quietly, are rarely maintained, and become the parts of the intranet that employees trust least.

❓ Ask yourself: Does this piece of content have a specific page or community it belongs to, and does that area have a category that accurately describes it, or are we creating a catch-all because we haven't made the real decision yet?

Follow your defined patterns

When similar areas follow the same structure, employees learn the pattern once and apply it everywhere. When every area is different, every visit requires re-orientation.

If one department has a page, every department should. If departments distribute news via their page, that approach should be consistent across all of them. 

Document structural decisions as you make them, not as a formal governance process, but as a simple shared reference. A single agreed sentence like "department areas get a page for official communication and a community for internal exchange" prevents many inconsistent decisions later.

❓ Ask yourself: Does this decision follow the pattern we've already established, and if we're making an exception, is there a real reason for it?