SharePoint Structure · Site Architecture

A Guide to SharePoint Site Structure: Hub Sites, Sites & Best Practices

Last updated: July 2026 Reading time: 13 minutes By: Liza Tinker

Most SharePoint messes I’ve been called in to fix started with the same problem: no thought given to the site structure before the first site was created. By the time anyone noticed, there were dozens of unconnected sites, no clear ownership, and nobody willing to admit they didn’t know what half of them were for.

Site structure is the invisible framework everything else in SharePoint hangs from. Get it right and search works, permissions make sense, navigation is intuitive, Copilot returns useful answers, and new starters can find things without asking. Get it wrong and you’re still cleaning up in five years.

After twenty years of SharePoint consulting, I can tell you with certainty: site structure is the single decision that determines whether SharePoint feels like a working tool or a source of daily frustration. This guide walks through the fundamentals — hub sites, team sites, communication sites — and shows you what good and bad site structure actually look like in real organisations.

What is SharePoint site structure?

SharePoint site structure describes how the sites in your Microsoft 365 tenant are organised and how they relate to each other. It covers the types of sites you use, how they’re associated together, how navigation flows between them, who owns each one, and how content is grouped across the environment.

Modern SharePoint doesn’t use the old top-down site collection hierarchies. Every site is now a flat, standalone site, and structure is created through hub sites — special sites that act as centres for related content and navigation. This is a huge shift from the classic SharePoint experience, and it’s why a lot of older training material is misleading.

Site structure is not about drawing a pretty diagram. It’s about answering the questions that determine whether SharePoint works: where does content live, who owns it, how do people find it, what belongs together, and how does it all scale as the organisation grows?

Why site structure matters more than almost anything else

Site structure is where every other SharePoint decision gets locked in. Permissions inherit down from sites. Governance operates at the site level. Navigation is built from site associations. Search results are grouped by site. Copilot understands which content belongs together based on site relationships.

If your structure is right, everything downstream works with less effort. If it’s wrong, every downstream problem — search failures, permission mistakes, orphaned content, Copilot confusion — traces back to it.

What good SharePoint site structure actually looks like

Let me show you what a well-designed SharePoint environment looks like, because most beginners have never seen one in the wild.

A structure that scales looks like this:

• A corporate hub as the tenant home — company news, policies, staff resources, intranet landing page.
• A Clients hub with a separate team site per major client, all associated to the hub.
• A Practice Areas hub connecting knowledge management sites for each service line.
• A Projects hub for cross-client project sites with a defined lifecycle.
• A Departments hub connecting HR, Finance, Legal, IT, and Marketing sites.

Every site has a named owner, a documented purpose, a defined lifecycle, and a consistent set of metadata columns. Every site is associated to exactly one hub. Site names follow a consistent pattern. New sites inherit their hub’s template and standards, so consistency doesn’t depend on anyone’s memory.

Here’s what that buys you: cross-site search that works. Navigation people can follow on their first day. Audits that take hours instead of weeks. And when AI features arrive in your tenant, structured content and clear site relationships for them to read. Nothing orphaned, nothing duplicated, nothing hidden.

This is what “SharePoint scales with us” looks like. It’s not sophisticated. It’s just structured deliberately from day one.

What bad site structure looks like — and what it costs

Now the opposite — the pattern I get asked to fix, and it’s nearly always the same shape: years of sites created ad-hoc by whoever needed one. No hub structure. No consistent naming. No documented ownership. Nobody designed anything — the structure just accumulated, one reasonable-seeming site at a time.

Here’s what that accumulation does, mechanically, over time:

• Duplicate sites multiply. Different teams create their own version of the same thing — unaware the others exist — and people pull answers from whichever one search surfaces first.
• Orphans accumulate. Sites outlive their owners and their purpose, still holding content, still accessible, reviewed by no one.
• Sensitive content drifts. Files land in sites with the wrong permissions and sit there quietly — technically accessible, never noticed — until an audit finds them, or an AI feature surfaces them.
• Search and AI degrade. Multiple outdated versions of the same policy across unconnected sites means search returns noise — and Copilot returns contradictions.
• Navigation collapses. With no hub structure, finding anything depends on knowing URLs or asking around. New starters inherit the confusion.

And the fix is always the same shape: audit every site, assign owners, design the hub architecture that should have existed from day one, migrate content, retire the rest. That’s months of work at minimum — for something a day of structural design at the start would have prevented.

SharePoint Site Planning Kit

Plan your SharePoint site with confidence. Learn how to structure sites, navigation, libraries and pages before you start building.

Get the Site Planning Kit →

The three types of SharePoint sites you need to know

Modern SharePoint has three site types. Each one serves a different purpose. Almost every structural mistake I see starts with using the wrong type for the wrong purpose.

Hub sites

Hub sites are aggregators. They don’t hold content of their own. Their job is to connect related sites, unify navigation across them, roll up content and news from associated sites, and share a consistent visual identity across a family of related sites.

Every organisation should have a small number of hub sites — typically between three and eight — each representing a major grouping of related content. Think Clients, Projects, Departments, Practice Areas, Knowledge, Corporate. Each hub becomes the front door for its family of sites.

Team sites and communication sites can be associated to a hub. When they are, they inherit the hub’s navigation, appear in the hub’s search, and can roll their content up to the hub’s landing page. This is the mechanism that creates structure in modern SharePoint.

Team sites

Team sites are the workspaces where teams actually do work. They’re designed for collaboration — sharing files, tracking tasks, managing information, having conversations in Teams (every Microsoft Team has a team site behind it). Most SharePoint sites in most organisations are team sites.

A team site should have a defined purpose, a small number of named owners, a specific team or project it serves, and a clear lifecycle. When the team disbands or the project ends, the site should be archived or retired. Not left behind.

Communication sites

Communication sites are for broadcasting — one-to-many publishing where a small number of people create content that a large number of people read. Intranet home pages. Department landing pages. Policy libraries. News hubs. Handbook sites.

Communication sites look different from team sites. They’re visual, page-driven, designed for readers rather than editors. If your users are primarily reading rather than editing, you probably want a communication site.

The hub-and-spoke architecture that actually works

Once you understand the three site types, the pattern that scales is what’s called hub-and-spoke architecture. It’s how Microsoft designed SharePoint to be used, and it’s what every well-designed environment I’ve built for organisations looks like.

The pattern:

• A small number of hub sites — typically five to eight — each representing a major area of the organisation.
• Team sites and communication sites associated to exactly one hub. Not two. Not zero. One.
• Each hub has its own consistent branding, navigation, and metadata standards.
• The corporate hub sits at the centre as the tenant home, with the other hubs linked from it.
• Search is scoped by hub. Users see relevant content without noise from unrelated areas.
• Governance operates at the hub level. Owners and standards are defined per hub, not per site.

This is the mental model to design around. Not “how many sites do we need?” — that question comes later. Design the hubs first. Everything else flows from there.

SharePoint site structure best practices

After twenty years designing structure for organisations of every size, these are the practices that separate environments that scale from environments that collapse under their own weight.

1. Design the hub structure before creating any sites

This is the single highest-leverage decision in SharePoint. Spend real time on it — a workshop with senior stakeholders, a mapping exercise, a review of how content actually flows through the organisation. Get it approved. Document it. Then build to it.

2. Every site belongs to exactly one hub

Unassociated sites become orphans. Sites associated to multiple hubs (which Microsoft doesn’t actually support well) create confusion. One hub per site, always. If a site could belong to two hubs, the hub structure needs rethinking.

3. Every site has a named owner

Every SharePoint site should have a person accountable for it. Not a group. Not “the team.” A named individual. When that person moves roles, ownership transfers explicitly. Sites without named owners become orphans. Orphans become risks.

4. Consistent naming across every hub

Naming is not “just cosmetic.” It’s how people find sites, how permissions get audited, how search results make sense. Every hub should have a naming convention. Every site should follow it. I’ve written about why traditional naming conventions don’t work in modern SharePoint — read that before designing yours.

5. Every site has a defined lifecycle

Sites should be created for a purpose and retired when the purpose ends. Projects have completion dates. Teams disband. Content becomes outdated. Sites without a defined lifecycle accumulate forever. Build the lifecycle into the site design from the start.

6. Governance from day one, not retrofit later

The biggest SharePoint disaster stories all start with “we’ll add governance later.” Later never comes until the mess is expensive to fix. Governance from day one: naming, ownership, lifecycle, permissions, metadata standards. Documented. Enforced. Reviewed.

7. Use templates for consistency

Every hub should have a template for the sites within it. Team sites in the Clients hub use the same template. Team sites in the Projects hub use a different template. Templates ensure consistency without requiring users to remember every standard.

Common site structure mistakes and their consequences

These are the patterns I see over and over. Each one has a real cost — measured in hours wasted, projects delayed, content lost, or budgets spent on cleanup that should have been prevented.

Creating sites ad-hoc without planning

The most common mistake. Someone needs a site, so they create one. Nobody stops to ask whether it belongs in an existing hub, whether it duplicates something already built, or whether it has a defined lifecycle. Repeat this pattern for five years and you have an unmanageable mess.

Not using hub sites at all

Some organisations skip hubs entirely because “we don’t need them” or “they seem complicated.” Then they end up with hundreds of unconnected sites and no way to navigate between them. Hub sites are how modern SharePoint scales. Skipping them is skipping the architecture.

Using the wrong site type for the job

Team sites used as intranets. Communication sites used as project workspaces. Every time this happens, the site fights against the users. The interface doesn’t match what they’re trying to do. Adoption suffers. Content gets misplaced.

No hub associations

Sites created but never associated to a hub. Every one of these is a small orphan. They don’t appear in the hub’s navigation. They don’t roll up to the hub’s search. They exist in isolation. Every time you find one, associate it (or archive it).

No lifecycle planning

Sites created without any end date. Sites for finished projects still active five years later. Sites for teams that no longer exist. Every one of these adds noise to search, permissions surface area to audit, and content to sift through. Lifecycle planning solves this from the start.

Skipping governance until it’s too late

“We’ll add governance later” is where most SharePoint disasters begin. Governance from day one is much cheaper than governance retrofitted after the fact. Document naming standards, ownership requirements, and lifecycle expectations before you create the first site.

What’s changed in SharePoint site structure for 2026

If you haven’t looked at modern SharePoint in a year or two, here’s what matters for structure — without the roadmap hype.

Site creation keeps getting easier

Microsoft keeps lowering the barrier to creating sites — and AI-assisted creation will lower it further as those capabilities reach more tenants. That’s useful and dangerous at the same time. Easier creation means faster sprawl if there’s no hub architecture and governance for new sites to land in. Design the structure first, then let people build within it.

AI features read your structure

The AI capabilities Microsoft is progressively adding across SharePoint and Microsoft 365 work from the content and relationships you’ve built — permissions, metadata, and how sites connect. Well-associated, well-owned sites give AI features context to work with. Orphaned, unstructured sites are noise at best and exposure at worst. Exactly which AI features are available in your tenant depends on licensing and rollout — I keep a plain-English, regularly updated breakdown in my complete guide to AI in SharePoint.

The structural point that doesn’t change

Whatever ships next, hub-and-spoke architecture, named ownership, and consistent metadata are the things every new feature is built on top of. Structure first. Features second.

Where to go from here

Site structure is where SharePoint gets designed. But it connects to everything else in the platform. If this article has been useful, these are the natural next steps.

Frequently asked questions

What’s the difference between a hub site, a team site, and a communication site?

A hub site is an aggregator that connects related sites and provides unified navigation. A team site is a workspace where teams collaborate on files and content. A communication site is a publishing site for broadcasting content to a wider audience. Team and communication sites associate to hub sites to form your site structure.

How many hub sites should my organisation have?

Typically five to eight is the right range for most organisations. Fewer than five and you’re forcing too many unrelated sites together. More than eight and users lose track of what belongs where. Each hub should represent a major area of the organisation — Clients, Projects, Departments, Practice Areas, Knowledge, Corporate — with clear boundaries between them.

Can a SharePoint site be associated to more than one hub?

Technically no — each site can only be associated to one hub at a time. If a site logically belongs to two hubs, the hub structure probably needs rethinking. Consider whether the site’s purpose is genuinely split, whether it should be two separate sites, or whether the hub definitions themselves need to change.

Should every SharePoint site have a named owner?

Yes. Every site should have one named individual accountable for it. Not a group, not “the team,” not “IT.” A person. When that person moves roles, ownership transfers explicitly. Sites without named owners become orphans, and orphans become governance risks.

How do I fix a SharePoint site structure that’s already a mess?

Start with an audit — inventory every site, identify owners, assess content, and map current relationships. Design the target hub structure separately. Then migrate content site-by-site into the new structure, decommissioning the old sites as you go. This is genuinely difficult work — the File Sanity Kit gives you the Container Method™ and templates to run through it systematically.

Does site structure affect Copilot and AI in SharePoint?

Yes, significantly. AI in SharePoint uses hub associations to understand how content is related. Sites associated to the correct hub get their content properly contextualised. Orphaned sites are effectively invisible to AI. This is one of the strongest arguments for designing structure properly before enabling AI features — structure determines what AI can see and understand.

Final thoughts: Design the structure. Then build the sites.

SharePoint site structure is the single decision that determines whether your environment works or fights you. Get it right at the start and every downstream feature — search, permissions, governance, AI — works better. Get it wrong and you spend years cleaning up what should have been an afternoon’s design work.

The pattern that scales is simple: five to eight hub sites, each with clear purpose. Team and communication sites associated to exactly one hub. Named owners. Consistent naming. Defined lifecycles. Governance from day one.

None of this is complicated. Almost nobody does it. That gap is why my job exists.

Copilot doesn’t fix structural mess. It amplifies it — visibly, to everyone with access. There is no AI without IA. The site structure is where information architecture starts.