When an organisation decides to implement SharePoint, the temptation is to start creating sites and libraries immediately. It seems straightforward — you create a site, create some folders, start uploading documents. The problem is that without a well-thought-out information architecture, six months later you have the same chaos you had before, just in the cloud.
Information architecture is the blueprint for your SharePoint before you build it.
What is information architecture?
It's the structure that defines how content is organised, classified, and connected in your SharePoint environment. It's not just "where documents go" — it's a design that affects:
- How users find what they need
- How you control who has access to what
- How search works
- What can be automated with Power Automate
- How Copilot AI responds when someone asks a question about company content
A well-designed architecture makes all of the above work well. A poorly designed architecture makes all of the above a problem.
The building blocks
Sites
A site is the main container in SharePoint. Each department, team, or business area typically has its own site. Sites have their own navigation, permissions, and content.
Examples: HR site, Finance site, Projects site, General intranet.
There are three types of site in SharePoint, each with a distinct purpose:
- Team site with Microsoft 365 group — the standard type when you create a team in Teams. Includes a mailbox, calendar, and Planner space. Ideal for teams working together on projects or departments.
- Team site without Microsoft 365 group — lighter, without the additional apps. Useful when you only need a site for documents and permissions without the overhead of a full group.
- Communication site — designed to publish content to a broad audience. Ideal for intranets, company portals, and policy and procedure pages that the whole organisation needs to consult but not edit.
Choosing the right site type from the start saves a lot of reconfiguration work later.
Hub Sites
A Hub Site connects several related sites under a common umbrella — shared navigation, unified search, consistent branding. For a company with multiple departments, the Hub Site is the intranet that connects them all.
Document libraries
Within each site there are libraries — specific containers for documents. A library is not just a large folder — it has its own metadata columns, views, permissions, and versioning.
Example: within the Finance site you might have an Invoices library, a Contracts library, and a Budgets library.
Lists
Lists are for structured data that isn't documents — client records, task tracking, inventory, incidents. They're the equivalent of a database table but accessible to any user without technical knowledge.
Metadata and content types
Metadata columns describe documents — client, date, status, department. Content types group sets of columns for different kinds of documents. They're the layer that makes search and filtering genuinely work.
Navigation
Navigation connects sites and content so that users can move around intuitively. Good navigation architecture reflects how users think, not how the company is organised internally.
The fundamental principle — blueprint before build
The most important decision in information architecture is how many sites you need and how they relate to each other. Creating too many sites fragments content and complicates search. Creating too few means everything ends up in one giant site that's hard to manage.
A practical guide for deciding how many sites:
- One site per department if departments have clearly different content and distinct permissions
- One site per large project if projects have their own teams and documentation
- One shared site for content the whole company needs — policies, procedures, forms
The permissions rule
Information architecture and permissions go hand in hand. If you need HR content to be visible only to the HR team, that content needs its own site with restricted permissions. You can't sustainably control access at the folder level — the correct solution is to separate content into distinct sites from the start.
The impact on search and Copilot
SharePoint has a powerful search engine — but it's only as good as the metadata behind it. A document without metadata is practically invisible to advanced search.
With Copilot AI, this matters even more. When an employee asks "which contracts are expiring this quarter?", Copilot searches the SharePoint content that user has access to. If the contracts don't have an "expiry date" column with data, Copilot can't answer. Information architecture directly determines what Copilot can and cannot do.
A simple architecture example for a mid-sized organisation
Hub Site — General Intranet
│
├── Company Site
│ ├── Library: Policies and Procedures
│ ├── Library: Corporate Templates
│ └── List: Employee Directory
│
├── Finance Site
│ ├── Library: Invoices
│ ├── Library: Supplier Contracts
│ └── Library: Budgets and Forecasts
│
├── HR Site (restricted access)
│ ├── Library: Employee Contracts
│ ├── Library: Payroll
│ └── List: Holiday Register
│
└── Projects Site
├── Library: Proposals
├── Library: Project Documentation
└── List: Project Tracker
This structure isn't the only correct one — every organisation is different. But it illustrates how sites, libraries, and permissions work together to create an ordered and secure environment.
When you need help with architecture
If your organisation has more than 20 employees, several business areas with different needs, or sensitive documentation that requires granular permissions, information architecture design is the most important step before implementing SharePoint.
An architecture mistake at the start is very costly to fix later — it means moving content, reconfiguring permissions, and retraining users. It's worth getting it right from day one.