Business boundary
Department, region, product, community, program, or enterprise outcome with explicit inclusion and exclusion criteria.
SharePoint intranet and information architecture
SharePoint Hub Site Architecture Guide
Design hub sites as durable business connections between independent SharePoint sites—not as permission containers or a rigid subsite hierarchy. Define the business boundary, home destination, association authority, shared experience, search scope, ownership, change process, and lifecycle before registering or moving sites.
Business domains, regions, functions, and communities
Navigation, branding, news, content rollups, and search
Independent permissions, movable associations, and lifecycle
Navigation, branding, news, content rollups, and search
Independent permissions, movable associations, and lifecycle
Architecture objective
Model relationships as links, not ownership
Modern SharePoint uses separate site collections for individual units of work. Hub sites connect families of team sites and communication sites with shared navigation and branding, content and news rollups, scoped search, and a home destination. The sites remain independent so they can use different owners, memberships, sensitivity, sharing, retention, storage, and lifecycle.
This flexibility is the point: a project site can move from one business hub to another after a reorganization without migrating its content into a new subsite tree. The architecture record must therefore explain why sites belong together, who may change associations, what users should discover across the family, and which controls are intentionally not inherited.
Minimum hub architecture record
- Business outcome, audience, scope boundary, excluded scope, and expected longevity.
- Hub site URL/ID, type, display name, description, logo/theme, home-page purpose, and owners.
- Approved site-association principals, request/approval route, and emergency change owner.
- Associated-site inventory with site ID, URL, owner, purpose, label, sharing, hub ID, and review date.
- Navigation owner, taxonomy, news/content rollup rules, search expectations, and hub-to-hub relationship.
- Site template on association, Multi-Geo limitations, permission-sync decision, validation evidence, and rollback.
Permission boundary: associating a site with a hub does not grant access to the hub or the associated site and does not merge their permissions. Hub navigation or search can surface a title or link that a user cannot open. Design audience and access intentionally, and never use hub association as a substitute for group, site, or item permissions.
Six architecture layers
Define the hub experience from business boundary to failback
A technically registered hub is not automatically a coherent intranet architecture. Each layer needs an owner, decision, and measurable result.
Hub home
A durable communication or modern team site that represents the family and hosts landing, navigation, news, and guidance.
Association authority
Named users or security groups allowed to join sites, plus request, approval, exception, and reassignment workflow.
Shared experience
Hub navigation, brand/theme, logo, approved association template, news/content aggregation, and audience behavior.
Discovery model
Search scope, result boundaries, hub-to-hub relationships, metadata, navigation, and access-aware user expectations.
Lifecycle and evidence
Inventory, owner review, association changes, redesign, unregister/disassociate behavior, validation, cleanup, and rollback.
| Hub pattern | Good fit | Boundary to preserve | Evidence to review |
|---|---|---|---|
| Business function hub | HR, Finance, Legal, Sales, IT, Operations, or another durable function with multiple publishing and collaboration sites | Do not assume every departmental site has the same audience, sharing level, or retention; confidential work may require a separate association or no hub | Function owner, associated-site purpose, owners, sensitivity, navigation and rollup inclusion, annual architecture review |
| Regional hub | Geographic intranet, offices, country operations, language or regulatory boundary | Geo, language, legal, data-residency, local communications, Multi-Geo, and cross-region search requirements | Geo location, regional sponsor, language/navigation, associated-site geo, template compatibility, support and failover |
| Product or program hub | Long-running product family, transformation program, client portfolio, or cross-functional initiative | Distinguish durable product knowledge from temporary project work; define archival and handoff when the program ends | Sponsor, product/program stage, active projects, lifecycle date, owner changes, retired-site and archive list |
| Community or knowledge hub | Practice, role, center of excellence, policy library, learning community, or topic-based knowledge | Separate authoritative publishing from open contribution and protect sensitive or regulated knowledge spaces | Editorial owner, content authority, contributor model, freshness, search/metadata quality, restricted source sites |
| Enterprise/home hub | Organization-wide landing and wayfinding layer that connects major hubs and common resources | Keep global navigation understandable; avoid forcing every working site into one huge flat family | Executive/intranet owner, top tasks, global navigation, hub-to-hub map, search scope, accessibility and analytics |
Registration and association runbook
Build and change hubs in a controlled sequence
Inventory the current site landscape
Export active sites, existing hubs, parent-hub associations, associated sites, site types, owners, activity, sensitivity, sharing, storage, Teams/group relationship, geo, and current navigation. Identify duplicate families and orphaned hubs before creating another.
Define the business and search boundary
Document who the hub serves, the decisions and content it should help users discover, sites that belong, sites that must stay out, and whether a parent-hub relationship is needed. Avoid mirroring a temporary org chart without testing user tasks.
Select a durable hub home site
Microsoft recommends a communication site or modern team site. Prefer a site with a durable URL, appropriate owners, accessible design, limited author population, clean permissions, and a clear landing-page purpose. A site already associated with another hub cannot be registered as a hub.
Approve owners and association principals
Assign hub owners, content/navigation editors, sponsor, support route, and backup owner. Specify the users or security groups allowed to associate sites. Leaving the association-principals field empty permits any user to associate a site they control.
Register and record the hub
Register the selected site through the SharePoint admin center or approved automation. Capture hub site ID, URL, display name, description, logo, site type, registration time, admin, allowed association principals, existing permissions, and before/after state.
Design navigation and brand
Build task-oriented hub navigation, owner/editor standards, audience targeting where appropriate, logo/theme choices, and link review. Keep labels stable and understandable. Test keyboard, mobile, contrast, localization, and the experience for users without access to every site.
Configure association behavior
Decide whether a hub site template should run when sites join, scope who may view/apply it, and document partial failure or reapplication. In Multi-Geo, a hub association template works only when the joined site is in the same geo as the hub.
Pilot representative sites
Associate a communication site, group-connected team site, sensitive/restricted site, and high-content site as applicable. Validate hub navigation/theme, rollups, search, template actions, permissions independence, audience experience, and admin/site-owner responsibilities.
Migrate associations in waves
Move sites by owner-approved waves. Record old/new hub IDs, change window, expected navigation/search impact, template actions, user communication, validation, exception, and rollback. A site can associate with only one hub at a time.
Operate and review the architecture
Reconcile new/removed sites, owner changes, stale navigation, broken links, overbroad association rights, rollup quality, search feedback, site lifecycle, reorganization requests, and parent-hub design. Review quarterly and after material organizational change.
Shared experience versus independent control
Document what a hub changes—and what it does not
| Capability | Expected hub behavior | Does not replace | Validation evidence |
|---|---|---|---|
| Navigation and brand | Associated sites display hub navigation and can inherit the hub look/theme; owners manage the shared experience | Site information architecture, local navigation, accessibility review, audience-specific links, or content ownership | Desktop/mobile navigation, theme/logo, target audiences, broken-link scan, owner/edit rights, change log |
| Content and news rollups | Hub-aware web parts can aggregate news, events, sites, and highlighted content from the associated family | Metadata quality, publishing approval, authoritative-source decisions, sensitive content controls, or freshness ownership | Web-part scope, source sites, user access behavior, missing/duplicate content, metadata and editorial review |
| Search | Hub search scopes discovery to the hub family; hub-to-hub association can expand related search across up to three levels | Permissions, Restricted Access Control, sensitivity, retention, search schema, or content-quality governance | Search personas, accessible/inaccessible result behavior, breadcrumb, expected sites/content, parent/child hub boundaries |
| Site association | Creates a logical relationship and shared hub experience; one associated site can move between hubs | Site ownership, Microsoft 365 group/Team membership, external-sharing policy, sensitivity, DLP, storage, or lifecycle | Hub ID, site ID, old/new association, approver, allowed principal, effective settings and rollback |
| Hub site template | Can apply site-script actions when a site associates with the hub | Immutable policy enforcement, complete rollback, current-state assurance, or cross-geo action in Multi-Geo | Template/script ID/version, geo, action results/errors, before/after configuration, remediation and owner notification |
| Permissions | Hub and associated sites retain independent permissions; any optional viewer-access alignment must be explicitly designed and tested | Group/site/item permissions, guest governance, owner recertification, restricted access, or sharing-link controls | Owner/member/visitor/guest personas, direct permissions, group IDs, optional sync state, denial and access tests |
Cross-control guidance: use the site owner access recertification guide for permissions accountability, the sensitivity labels guide for container protection, and the sharing security guide for external collaboration. Hub membership does not settle those controls.
Hub-to-hub and reorganization design
Connect search without recreating a rigid hierarchy
Parent and child hubs
Hub-to-hub association expands search across related hub families. Microsoft documents search up to three association levels. Record the parent-hub intent, expected peer discovery, and every child hub; do not assume deeper levels will appear.
What does not roll up
Hub-to-hub association does not change permissions, and ordinary web parts configured for “all sites in this hub” continue to use the original parent hub rather than automatically aggregating every associated hub. Navigation links to parent/child hubs are optional.
Reorganization path
Move site associations based on business purpose, owner approval, audience, search, navigation, and lifecycle—not only reporting-line changes. Preserve site IDs and an old/new hub map so scripts, integrations, support, and rollback do not depend on the URL alone.
Unregister caution: unregister a hub before deleting it. Associated sites do not automatically disassociate when the hub is unregistered. Removing an association removes the hub navigation, but an inherited look and changes made by a hub template—such as navigation nodes, lists, or columns—can remain. Plan cleanup and verify each site rather than assuming unregister is a complete rollback.
Top architecture risks
Common hub designs that confuse users or weaken governance
A polished hub can still be architecturally wrong. Treat these as boundary, ownership, or evidence defects rather than cosmetic issues.
Org chart copied literally
Every reporting line becomes a hub even though user tasks and content relationships cross the hierarchy and reorganizations happen frequently.
Hub mistaken for permissions
Owners assume association grants access or that navigation visibility proves users can open every associated site.
Association rights left open
The allowed-principals field is empty, so any site owner can join the hub without architecture, owner, sensitivity, or lifecycle review.
One giant enterprise hub
Thousands of unrelated sites create noisy navigation, weak rollups, broad search expectations, unclear ownership, and no meaningful family boundary.
Hub proliferation
Teams create new hubs for campaigns or short projects when an associated site or temporary workspace would be simpler and easier to retire.
Sensitive site surfaced broadly
Navigation, news, events, or search exposes a confidential title or context even though the user cannot open the underlying content.
Navigation without an owner
Links, labels, audience targeting, localization, and accessibility drift because nobody is accountable for the shared experience.
Rollup without metadata
News and content aggregation becomes duplicate, stale, or irrelevant because publishing authority and metadata standards were never defined.
Hub-to-hub overreach
Architects expect permissions or web-part rollups to flow through nested hubs, or design beyond the documented three-level search behavior.
Template side effects ignored
Association applies lists, navigation, or other actions, but disassociation does not remove them and the owner is not warned.
Multi-Geo assumption
A hub association template is expected to apply across geographies even though Microsoft limits that behavior to the hub’s geo.
Unregister without map
A hub is removed or deleted before associated sites, inherited look, navigation, search, scripts, and support dependencies are inventoried.
Validation and operating evidence
Prove the experience with different access personas
Architecture inventory
Export hub IDs, URLs, titles, parent hubs, association principals, owners, site-design IDs, and all associated sites with site IDs, labels, sharing, group/Team relationships, geo, and lifecycle state.
Navigation and brand
Test desktop and mobile hub navigation, theme/logo, audience targeting, localization, accessibility, broken links, editor rights, associated-site consistency, and the experience after moving or disassociating a site.
Search and rollups
Use owner, member, visitor, restricted internal user, and guest personas. Validate hub search, parent/child search, breadcrumbs, news/events/content rollups, metadata quality, and inaccessible-result behavior.
Permissions independence
Confirm association does not grant unintended access. Review hub and site owners/members/visitors, Microsoft 365 group membership, direct permissions, sharing, restricted access, and any optional access-alignment behavior.
Template and geo
Record the hub site-template ID/version, actions, results, errors, joined-site geo, after-state, cleanup requirement, and owner notification. Test same-geo behavior in Multi-Geo before scaling.
Change and failback
Preserve old/new hub IDs, associated-site list, navigation export, theme/logo, parent-hub map, search/rollup tests, template effects, approval, user communication, and exact disassociate/unregister cleanup steps.
Operating cadence: reconcile association changes monthly, review navigation and rollup quality quarterly, recertify hub owners and association principals at least quarterly, and perform a full architecture review annually or after merger, reorganization, major intranet redesign, Multi-Geo expansion, or sensitive-data program change.
Related IT Perfection support
Design a hub map that can survive organizational change
IT Perfection can help Orange County and Southern California organizations inventory SharePoint sites and hubs, model business and search boundaries, define association authorities, design navigation and content rollups, validate permissions independence, plan hub-to-hub relationships, govern templates, and establish change/failback evidence as part of Microsoft 365 managed services or a focused SharePoint architecture project.
Use the SharePoint site governance guide for the broader operating model and the Microsoft 365 resource center for the surrounding ecosystem. Learn about the experience behind these guides on Ali Hassani’s profile.
Authoritative Microsoft references
Frequently asked questions
SharePoint hub site architecture FAQ
Does associating a SharePoint site with a hub change its permissions?
No. Hub association does not change the permissions of the hub or associated site. Users still need appropriate access to each site. Design hub navigation, search, rollups, and any optional access-alignment behavior with explicit persona testing.
Can one SharePoint site belong to more than one hub?
An associated site has one direct hub association at a time. It can be moved to a different hub through a controlled change. Hub sites themselves can be associated to a parent hub to expand search across related hub families.
What does hub-to-hub association change?
It expands search across related hubs and can display parent/child hub breadcrumbs and optional navigation links. It does not change permissions. Microsoft documents search through up to three association levels, while ordinary hub-scoped web parts continue to use the original parent hub.
Who should be allowed to associate sites with a hub?
Use named users or security groups representing approved SharePoint/intranet administrators or delegated business architects. If the association-principals field is left empty when registering a hub, any user can associate a site they control, which is usually too broad for a governed architecture.
Does unregistering a hub fully reverse its effects?
No. Associated sites do not automatically disassociate, and the inherited look or actions applied by a hub site template can remain. Inventory associations and template effects, disassociate or reassign sites deliberately, unregister the hub, and validate navigation, theme, search, web parts, and cleanup.
Can IT Perfection help design or repair a hub architecture?
Yes. IT Perfection can inventory hubs and associated sites, model business/search boundaries, define association rights, design navigation and rollups, validate permissions, plan hub-to-hub relationships, document lifecycle, and execute a reversible migration or cleanup plan.
Connect experiences without collapsing security boundaries
Build a SharePoint hub architecture that can move with the business
IT Perfection can reconcile existing hubs and sites, define durable families, control association rights, design navigation and search, validate rollups and independent permissions, govern templates, and document reversible reorganization and lifecycle procedures.
This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal/privacy review, records-management decision, accessibility review, or tenant-specific Microsoft engineering engagement. Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, Microsoft infrastructure, networking, and business technology experience.
