Understanding SharePoint Hub Sites: Concepts and Practices

SharePoint Hub Sites connect multiple sites into one structure — shared navigation, shared branding, and search that spans the hub and everything associated with it. Useful for grouping sites by department, project, or business unit without merging them into one giant site.

In this post: What the structure looks like · Key concepts · Setting it up with PowerShell · When would you actually use this? · Best practices · Hub-to-hub association and the real limits · Decommissioning a hub: the right order · Related reading

What the structure looks like

A hub site is the parent; associated sites inherit its navigation bar and branding automatically. For example, a “Corporate HQ” hub might connect a Marketing team site, a Sales team site, a company-wide communication site, and a project site for a specific initiative — each keeps its own content and permissions, but shares the same top-level navigation and search scope.

Key concepts

Association: team/communication sites link to a hub to join its framework.
Navigation: a unified nav bar gets added to associated sites automatically.
Branding: shared theme and logo across every linked site.
Search scope: search spans the hub and all associated sites together.
Flexibility: sites can be reassociated to a different hub later if org structure changes.

Setting it up with PowerShell

Registering a hub requires SharePoint Administrator or Global Administrator rights — a regular site owner can’t turn their own site into a hub, though they can request to associate an existing site with one if the hub’s owner has allowed join requests. The actual setup is three commands:

Connect-SPOService -Url https://contoso-admin.sharepoint.com

# Register a site as a hub
Register-SPOHubSite -Site https://contoso.sharepoint.com/sites/CorporateHQ

# Associate another site to that hub
Add-SPOHubSiteAssociation -Site https://contoso.sharepoint.com/sites/Marketing -HubSite https://contoso.sharepoint.com/sites/CorporateHQ

# Check what's currently associated with a hub
Get-SPOHubSite | Select-Object Title, SiteId, ID

Reassociating a site later just means running Add-SPOHubSiteAssociation again pointed at the new hub — there’s no need to remove the old association first, the site simply moves.

Hub-to-hub association expands search scope across hubs, up to three levels — but it doesn’t touch permissions, and it’s not the same thing as merging hubs into one navigation structure.

When would you actually use this?

Multiple department sites need consistent branding and cross-site search without merging into a single unwieldy site.
Users are complaining they can’t find content that they know exists somewhere in “one of the team sites” — hub-scoped search fixes exactly this.
A new initiative needs its own site but should still feel connected to the parent department’s site, not orphaned.

Best practices

Give each hub a clear, specific purpose — a department or a defined initiative, not “everything.”
Don’t over-create hubs — too many dilutes the point of having a unified structure in the first place.
Set governance rules for who can create/associate sites before it sprawls.
Check hub analytics periodically to see whether the structure still matches how people actually use it.

Hub-to-hub association, and the real limits

Worth correcting explicitly, since it’s a common assumption: SharePoint hubs aren’t strictly flat and single-level anymore. Hub-to-hub association lets you link one hub as a parent to another, which expands search scope across them — content from an associated child hub’s sites shows up when searching from the parent, up to three levels of association deep. It’s specifically a search-scope feature, though, not a navigation merge: each site still only joins one hub for navigation and branding purposes, and hub-to-hub association doesn’t change permissions on anything.

The numbers that actually matter for planning at scale: a tenant supports up to 2,000 hub sites, and while there’s no hard cap on associated sites per hub, navigation and search rollup performance noticeably degrade somewhere in the 800-1,200 range for a single hub in practice — treat that as the real ceiling, not the documented ceiling. And reassociating a site to a different hub can temporarily disrupt navigation for anyone using it while it propagates — plan that kind of change for low-traffic hours, not the middle of a workday.

Setting up a hub-to-hub association requires the same SharePoint Administrator or Global Administrator rights as registering a hub in the first place — it isn’t something a regular hub owner can do unilaterally, which is by design. If you’re planning a multi-hub structure (a top-level “Corporate” hub with department hubs underneath it, for example), decide the hierarchy and who owns each hub before wiring the associations together, since undoing a hub-to-hub link and rebuilding it differently means redoing the search-index propagation, not just flipping a setting back.

Decommissioning a hub: the right order

Everything above covers creating and growing a hub structure — worth covering the other end too, since retiring one gets this backward more often than it should. Unregistering a hub site does not automatically disassociate the sites that were joined to it — they stay visually and functionally tied to the now-former hub (navigation bar, inherited branding, any hub-specific web parts) until someone explicitly removes each association. Microsoft’s own guidance is explicit about the sequencing: unregister the hub before deleting it, never the other way around, since a hub site collection that’s already been deleted can’t cleanly be unregistered afterward.

Connect-SPOService -Url https://contoso-admin.sharepoint.com

# Disassociate every site from the hub first
Remove-SPOHubSiteAssociation -Site https://contoso.sharepoint.com/sites/Marketing
Remove-SPOHubSiteAssociation -Site https://contoso.sharepoint.com/sites/Sales

# Then unregister the hub itself
Unregister-SPOHubSite -Site https://contoso.sharepoint.com/sites/CorporateHQ

# Only after both of the above -- if the hub's own site is actually being retired
Remove-SPOSite -Identity https://contoso.sharepoint.com/sites/CorporateHQ -Confirm:$false

Running Remove-SPOHubSiteAssociation against every associated site first, rather than leaving that to happen implicitly, avoids the “orphaned” state where sites keep the old hub’s navigation and inherited design elements indefinitely with nothing actually managing them anymore — a real, if cosmetic, mess that’s easy to create by unregistering a hub casually and assuming everything downstream sorts itself out.

A Comprehensive Guide to SharePoint Site Design — where hub sites fit into the broader site design picture.
Choosing the right SharePoint Online site type — decide the site type before deciding whether it should join a hub.

Hope that was useful — comment below if you hit any snags.