SharePoint information architecture

SharePoint information architecture is the practice of designing how content is organised across sites — what becomes its own site, how sites relate via hubs, how navigation works, where common content lives. Done well, users find things. Done badly, the intranet feels chaotic and useless.

The modern building blocks

Modern SharePoint Online is built from a few units:

• Sites — each its own site collection in modern SharePoint, with isolated permissions, lifecycle, and quota.
• Hub sites — sites others can associate with, getting shared navigation, theme, and search scope.
• Home sites — the tenant's designated landing page, often with Viva Connections integration.
• Navigation — global (Viva Connections / home site), hub-level, and per-site navigation.

The older nested-subsite pattern is deprecated for new content.

A typical IA pattern

A common shape that scales for most organisations:

Home site (corporate intranet)
├── HR hub
│   ├── HR team site
│   ├── HR communication site (HR portal)
│   ├── HR policies communication site
│   └── HR projects team sites
├── IT hub
│   ├── IT service catalog (communication site)
│   ├── IT operations (team site)
│   └── IT documentation (communication site)
├── Engineering hub
│   ├── Engineering team site
│   ├── Engineering documentation
│   └── Project sites
├── Sales hub
│   └── ...
└── Other functional hubs

Each hub has its own navigation, theme, and search scope. Sites associate to one hub. The home site provides global navigation across the whole intranet.

Designing hubs

A few principles for hub design:

• One hub per logical business unit — department, function, business unit.
• Avoid hub sprawl — too many hubs (>30) make global navigation cluttered.
• Hub-to-hub associations — for very large intranets, hubs themselves can associate to parent hubs (two levels deep typically).
• Naming consistency — HR Hub, IT Hub, Engineering Hub is clearer than mixed naming.

Communication sites vs team sites

• Communication sites — broadcasting information to wide audiences. Polished page layouts. Used for hub centres, departmental portals, intranet news hubs.
• Team sites — workspaces for collaborating groups. Backed by Microsoft 365 Groups (and often Teams teams). Used for project work, department workspaces, working files.

A typical hub combines both: a communication-site hub centre plus many team sites associated to it.

Permissions design

• Group-driven — site members come from Microsoft 365 Group membership for team sites.
• Audience-targeted — communication sites visible to broader audiences with restricted edit rights.
• Sensitivity labels at the container level set sharing posture per site.
• Avoid item-level permissions — they create audit nightmares.

Common pitfalls

• Over-engineering early — designing for 1,000 sites when you have 5. Start simple, evolve.
• Building a tree of subsites — modern SharePoint doesn't reward this. Use flat hub structures.
• Inconsistent naming — HR Department, Human Resources, and HR Team all referring to the same thing.
• No ownership — sites need accountable owners; orphaned sites accumulate.
• Skipping global navigation — users get lost without it.

Migration considerations

When migrating from legacy SharePoint or file shares:

• Don't replicate folder structure 1:1 — flatten and use metadata where possible.
• Identify natural site boundaries — usually department-aligned.
• Plan navigation up front — restructuring later is painful.
• Communicate the new structure before, during, and after migration.

For an organisation building or rebuilding its Microsoft 365 intranet, IA design is the most consequential decision. Spend time on it; document it; revisit annually.

A worked example: a 400-user professional services firm

A 400-user consultancy on Microsoft 365 E3, historically all "Everyone except external users" on the tenant root site with permissions granted per folder. Post-cleanup the IA looks like this:

• Intranet — one communication site (Comms), author group ~5, everyone reads. No collaboration happens here.
• Company-wide collaboration — one hub site (HQ) with spokes: HR, Finance, IT, Legal, Marketing, Operations. Each spoke owned by that function's Microsoft 365 Group.
• Client work — one hub (Delivery) with a spoke per active client (typically 40–80 sites). Each spoke is owned by the client's engagement Team. Provisioning is automated: a Power Automate flow triggered from CRM creates the site with a site template that pre-seeds four libraries (Contracts, Deliverables, Working Files, Correspondence), sensitivity labels applied at container level, and access limited to the delivery team.
• Personal drafting — OneDrive. As soon as a document goes to a second person it moves to the appropriate SharePoint library.
• Retention — a retention label auto-applied to Contracts (7 years from last-modified), Deliverables (10 years from client-offboarded event), everything else on the standard 3-year rolling policy.

The unglamorous work: renaming and remapping ~200 old sites into the new IA, mostly by cloning documents into their new home rather than migrating in place — anything that broke on the way over stayed broken.

Decision matrix: hub, spoke, or standalone

| Situation | Structure | | --- | --- | | One organisation-wide news feed everyone reads | Hub with communication-site homepage; every other site associates to it | | A department or function that collaborates internally and publishes some content out | Spoke team site associated to the HQ hub | | A cross-functional programme spanning many departments | New hub (Programme hub) with the participating team sites associated to it | | A single-purpose short-lived team (a project, a bid, a task force) | Team site provisioned from a template, no hub required | | Confidential board or M&A material | Standalone team site with restricted membership, sensitivity-label container control, no hub association | | Personal working files | OneDrive — until they leave that user's control |

When to stop redesigning

• You have three or fewer working hubs. Do not add a fourth hub because the org chart grew a new column. Hubs work when they represent enduring content domains, not project-based groupings.
• Users are creating standalone sites. This is a symptom of provisioning friction — fix the provisioning flow (self-service through a governed template) before adding another layer of IA.
• Search returns the right result on the first try for 80% of queries. IA changes have diminishing returns; invest the next hour in labels, templates, and search promotions instead.
• You cannot describe the IA in three sentences. Neither can anyone else, which means it will not survive the next reorg.

MSP checklist

• Standard template per client size band. SMB clients get one hub + spokes-by-department; mid-market gets internal hub + delivery hub + confidential-standalone pattern.
• Provisioning is code, not clicks. Site templates + a Power Automate or Graph API–driven provisioning flow, source-controlled. Manual site creation is the operational anti-pattern that grows into next year's cleanup project.
• Hub-association reports. Monthly per-client report of sites not associated to any hub (with reason: standalone by design, or drift). Drift gets a follow-up.
• Sensitivity-label baseline applied at container creation, not left to users. Public / General / Confidential / Highly Confidential is the working default across small clients.
• External-sharing posture documented per site classification. Standalone confidential = organisation-only; standard client site = new-and-existing guests with expiration.