Hub sites and navigation architecture

The flat-vs-nested decision (settled)

Classic SharePoint built hierarchy with subsites — sites nested inside sites, sharing a permission and URL tree. Modern SharePoint deprecates that pattern: every site should be a top-level site collection, and relationships are expressed by associating sites to a hub, not by nesting. The reason is lifecycle — a subsite can't be moved, re-permissioned or retired independently of its parent, whereas associated sites stay autonomous and can leave the hub cleanly.

What a hub gives its family

Register a site as a hub (an admin action), then associate other sites to it. Association confers:

• Shared top navigation — the hub's nav bar appears across all associated sites.
• Shared theme/branding — a consistent look rolls down (associated sites can be locked to it or allowed to vary).
• Rolled-up content — news and activity from associated sites surface on the hub (via Highlighted Content / News web parts).
• A common search scope — searching from the hub searches across the family.

Crucially, association does not change permissions — each associated site keeps its own access model. A hub is an organisational and navigational overlay, not a security boundary.

Limits and structure

• A site associates to one hub at a time.
• Hubs can be nested (a hub associated to a parent hub) to a limited depth, enabling a shallow tier of navigation without subsites.
• There's a tenant ceiling on the number of hubs (in the low thousands) — plan hubs around real organisational divisions, not every team.
• The home site (intranet root, previous concept) is typically also a hub.

The failure modes

• Still building subsites. New subsites inherit the parent's fate and can't be independently governed, archived or moved — a debt that surfaces at retirement.
• Association ≠ permission. Admins assume joining a hub grants access to member sites; it doesn't. Access is still per-site (permission-model concept).
• Who can associate. By default hub registration/association can be restricted to named principals; leave it open and the hub's nav becomes a free-for-all.
• Theme lock-in surprises — associating can override a site's branding if the hub enforces its theme; site owners are caught out.
• Deleting/unregistering a hub orphans the navigation and rollups of every associated site at once — a high-blast-radius action.

What to watch (proofs)

• Hub inventory: Get-SPOHubSite — every registered hub, its ID and permissions (who may associate).
• A site's hub membership: Get-SPOSite <url> | fl HubSiteId — which hub it belongs to (all-zero GUID = not associated).
• Association control: the hub's associable-principals list (Get-SPOHubSite <hub>) — is joining restricted, or open to anyone?
• Structure audit: any surviving subsites (Get-SPOWeb under a site) — the legacy nesting to unwind toward flat + hub.