SharePoint Site Design and Architecture: Building Well-Structured and Scalable Sites

For the practical step-by-step of actually creating and configuring a site — picking a type, Site Scripts, permissions, accessibility — see A Comprehensive Guide to SharePoint Site Design. This post goes deeper on the architecture layer underneath those decisions: how sites should actually be structured and connected once there’s more than a handful of them.

In this post: The subsite advice that’s now outdated · Flat sites, connected by hubs · When one hub isn’t enough · Site collection strategy · Information architecture before you build anything · Related reading

The subsite advice that’s now outdated

Worth correcting directly, since it’s still common advice floating around: “create a top-level site, then build subsites beneath it for each department” is a genuinely outdated pattern, not a matter of preference. Microsoft has explicitly moved away from subsites in modern SharePoint — they create rigid hierarchies that are hard to reorganize later, complicate permission inheritance (a subsite inherits from its parent by default, which is rarely what you actually want once departments have different access needs), and can’t be moved or managed independently of the site above them. New subsite creation is effectively legacy at this point, not a forward-looking structural choice.

Flat sites, connected by hubs

The current, Microsoft-recommended pattern instead: independent, flat sites — each its own site collection, not nested inside another — connected through hub sites rather than a folder-like hierarchy. A hub gives its associated sites shared navigation, branding, and cross-site search without imposing any parent-child structure between them; any associated site can be reorganized, reassigned to a different hub, or removed without touching the others. For an organization with several departments, that typically looks like a small number of hubs (Corporate, HR, IT, Operations — three to five is a common range) with each department or project getting its own site collection associated to the relevant hub, rather than a deep tree under one root site.

Hubs can also associate with other hubs, not just individual sites — up to 3 levels deep — though that association is scoped specifically to search, not full navigation/branding inheritance the way a direct hub-to-site association is. Worth knowing as a ceiling before planning a hub topology more than a couple of levels deep, rather than assuming it nests indefinitely.

When one hub isn’t enough

Worth planning for before it becomes an urgent problem: while Microsoft’s own documentation states there’s no hard cap on how many sites can associate with a single hub, the practical ceiling before navigation and search rollup performance visibly degrades is commonly closer to 800-1,200 associated sites, well short of any documented limit. A tenant can register up to 2,000 hub sites in total, so there’s real room to grow into a hub-of-hubs model — a master hub associating a smaller number of sub-hubs, each handling its own portion of leaf sites — rather than pushing one hub past the point where it stays fast and usable. Planning where that split happens before a single hub gets unwieldy is a lot less disruptive than reorganizing hub associations across hundreds of already-live sites later.

“Create subsites for each department” is genuinely outdated advice now, not a style preference — flat sites connected by hubs is the current, Microsoft-recommended pattern.

Site collection strategy

The real architecture decision isn’t “how many subsites” anymore — it’s how content gets grouped into site collections and which hub each one joins. A few things worth deciding deliberately rather than defaulting: whether a project genuinely needs its own site collection or fits inside an existing team’s site as a library, who holds Site Collection Administrator on each one (a broader role than a site Owner — it’s what actually controls hub association and storage), and whether the department/hub split mirrors the org chart or the way people actually collaborate day to day. Mirroring the org chart is the default most teams reach for, but cross-functional project sites that don’t map cleanly to one department are common enough to plan for explicitly rather than force into whichever hub happens to be closest. There’s real headroom at the tenant level regardless of how this gets split — a SharePoint Online tenant supports up to 2 million site collections in total, with any individual one able to grow to 25TB — so in practice the constraint is almost never “can we create another site collection,” it’s whether doing so is actually the right structural choice for the content in question.

Information architecture before you build anything

The content layer matters as much as the site layer, and it’s the piece most likely to get skipped under time pressure: a shared metadata scheme — consistent column names and values across sites within a hub — is what actually makes cross-site search and navigation coherent. Without it, every site invents its own “Status” or “Department” column with slightly different values, and hub-wide search ends up technically working but practically useless, since the same concept is tagged three different, incompatible ways across three sites. Deciding this once, before the first few sites get built, is dramatically cheaper than retrofitting a shared taxonomy across a dozen sites that have each already drifted their own way — see SharePoint Metadata Naming Convention for the specifics of getting that consistency to actually stick.

A Comprehensive Guide to SharePoint Site Design — the practical step-by-step this post’s architecture guidance sits above.
Understanding SharePoint Hub Sites — hub sites in depth, including hub-to-hub association and decommissioning order.
Choosing the right SharePoint Online site type — Team Site vs. Communication Site vs. Hub Site, the decision that comes before structure.

Getting the architecture right early is worth the extra planning time — retrofitting structure onto sites that already have real content and real users is a lot more disruptive than deciding it up front. None of the decisions above need to be perfect on day one, but they do need to be made deliberately, with the current flat-plus-hub model in mind, rather than inherited from advice written for a version of SharePoint that no longer reflects how Microsoft recommends building it.