Blog post: 5 minute read but take your time. 😉
Last updated: August 2018
At the recent Microsoft Ignite conference in Orlando, there was a phrase that was bandied about by some people I trust and respect in the SharePoint space. The phrase was “[SharePoint] Subsites are the spawn of the devil!”.
A provocative statement.
The downside of subsites is nothing new for many people working in SharePoint when it comes to certain things, but I had never heard such a negative slant against them until Ignite. There are no doubt thousands of SharePoint environments out there with lots of subsites. I also believe there are people out there (as evidenced by Twitter) who are confused by this statement and want to know more.
I decided to write this post to highlight the pros/cons of a site collection versus a subsite. Although it is my general recommendation to provision site collections instead of subsites, I understand there are organizations out there with many subsites so I will try to present the pros and cons in an unbiased way. Keep in mind I’m not covering off every unique business scenario that may exist and in some cases you may feel a subsite is still the best choice.
If after reading this you have more pros/cons to add, please let me know and I’ll update the post.
[Update January 20, 2018] Twitter comment from Dan Holme regarding this blog post…
“Excellent extension of [my] strong guidance to use site collections, not sub sites. A decade of governance work with clients has *rarely* shown a subsite-based IA to sustain and serve well over time. Moving fwd, sites & hub sites, and graph/search are the way to go!”
[Update August 13, 2018] Updates around subsite creation and who can create a site collection based on recent Microsoft post: Updates to SharePoint self-service site creation.
In this post, I’ll use the word “workspace” to refer to the collaborative space we are wanting to provision whether it be a site collection or a subsite.
If provisioning a site collection, the workspace will live in the top-level root site within it.
Advantages of Subsites
- A subsite can be provisioned by anyone with at least Full Control permission (more specifically, the Create Subsites permission level) on the parent site. I.e. You don’t require a farm or tenant admin to provision one for you. (Although in SharePoint Online, anyone in a specified AD group can provision an Office 365 Group site collection; to provision a standard SharePoint site collection on SharePoint Server requires membership in the Farm Administrators SharePoint group on the machine running the Central Administration website. To provision a Classic SharePoint site collection in Office 365 no longer requires you to be a Global Admin or SharePoint Online administrator; you can now allow users who don’t have permission to create groups to create sites without an Office 365 Group thru the SharePoint UI. The site can be either a team site, communication site or a classic site)
- A subsite can automatically be added to the navigation of the parent site if you have the navigation settings configured that way.
- A subsite can automatically inherit settings from its parent site including permissions, features, and navigation (Ironically this can also be a disadvantage as well as I describe in the section below). You can optionally adjust some of the settings at the subsite level. (for example, decide not to inherit navigation settings)
- This is quick and easy to setup which is attractive for small organizations who don’t have a lot of resources to spend maintaining site collections. (although in SharePoint Online, the provisioning process for an Office 365 Group site collection is very quick and easy, it is not that easy in SharePoint on-premises)
- [Update January 18, 2018] A subsite automatically inherits content types and site columns from its parent site. This is more straight-forward to setup than a Content Type Hub which is what is required to do the same across site collections.
- [Update January 18, 2018] Managed Term sets can easily be shared across all subsites within a Site Collection if the term set is created at the site collection level. Term sets cannot be shared across site collections unless it is created at the farm/tenant level.
Disadvantages of Subsites
- If you have intentionally built a site structure that mimics your organizational heirarchy and there is a re-org, then you may need to move a subsite from one site collection to another or from one parent site to another. Although you can certainly do this, it will require a migration and change the URL to the subsite which may break links, etc.
- A subsite is part of the bigger site collection when it comes to storage allocated and so all subsites housed within a site collection are constrained to what that storage limit for the site collection is.
- URL lengths may get long if you have many nested subsites. There is a URL length limit (as of the time of this writing it is 260 for SharePoint on-premises and 400 for SharePoint Online) that you may bump into. The longer the path to get to your file (will increase as the subsite structure increases), the greater the chance of hitting that limit.
- If you need to use a site feature in your particular subsite, sometimes a site collection feature needs to be enabled/activated in order for the subsite to use it. (Document ID is an example of this). You may not always want to enable a site collection feature if it will affect all subsites.
- The new Retention Labels/Retention Policies are published at a site collection level, not a subsite level. This means if you want to only publish a label for a particular subsite, you can’t.
- If you have a subsite that is no longer being used and it happens to be a parent to another subsite that is being used, you cannot remove the parent subsite.
- If you have a site collection provisioned with the new Modern site experience, you can’t create a modern team site underneath – you can only create a Classic Team site. [Update August 13,2018 – You will soon be able to create a modern team sub site as well!]
- [Update August 13, 2018] Deeply nested subsite structures leveraging dynamic structural navigation can have performance issues due to the load required to make it security-trimmed.
Advantages of Site Collections
- Provisioning a site collection can be limited to a select group of users in your organization. I believe this is a governance advantage as it gives you an opportunity to control site collections being provisioned, provide the appropriate guidance and training and implement the required controls (protection, retention) for the site collection. If you don’t want to limit this to a select group of users, you can also allow users who don’t have permission to create sites without an Office 365 Group. The site can be either a team site, communication site or a classic site. Whether this is an advantage or not will depend on your organization’s appetite for self-service site creation.
- It is a boundary for permissions – when a site collection is provisioned you will have visitors, members, and owners SharePoint groups created for it. These groups do not cross over into other site collections.
- It is a boundary for features – you can enable/activate features at a site collection level so if each discrete workspace is within its own site collection, only the features required for it need to be enabled.
- It is a boundary for storage – the amount of storage is allocated per site collection. You can also configure a site collection to be isolated to its own database (SharePoint on-premises).
- It is a boundary for search although you can extend search results across multiple site collections and target search to a single site within a site collection with search configuration and using the new SharePoint Hub site.
- The new Retention Labels/Retention Policies are published at a site collection level. This means if you want to only publish a label for a particular workspace, then it is best if the workspace is a site collection. Conversely, if you want to exclude a label from showing in a particular workspace, then this can only be done by excluding the site collection.
- You can enable external sharing on a site collection basis.
- You can identify “stale” site collections that aren’t being used. This will give you an opportunity to archive/delete these site collections independent of any other site collection.
Disadvantages of Site Collections
- It is a boundary for navigation which means navigation is not shared across site collections. To visually tie together your site collections in a “virtual hierarchy” (i.e. navigation), you will need to handle this separately. (Code, manually configured, etc.) **See my comment about the new SharePoint Hub site below to address this disadvantage however which will turn this into an advantage where you can ‘plug and play’ your site collections into whatever kind of navigation is required.
- Content types and site columns can be defined at a site collection level but cannot be easily shared across site collections. The Content Type hub is a feature built with the intent of this, but in my experience it has some usability issues, particularly in SharePoint Online.
- If you are a small company, you may find it difficult to manage multiple site collections if you have advanced branding, navigation, feature requirements.
Let’s get back to the quote from Ignite… why are subsites the spawn of the devil?
Generally speaking, it’s hard to argue with the fact that site collections are more flexible. Each site collection can be viewed as a granular ‘unit of work’. They allow you to control permissions, features, storage, branding and target data protection and retention controls at a more targeted level. A flat architecture like this allows you to ‘plug and play’ site collections into whatever kind of navigational hierarchy is required – the announcement of the SharePoint Hub site at Microsoft Ignite is a feature being built to allow you to build this navigation thru the User Interface. You will be able to associate a site collection with a SharePoint Hub by the click of a button and easily move it from one Hub to another if required. This is great news.
From tech community Ignite announcement:
“SharePoint hub sites will let you bring together associated sites to roll up news and activity, to simplify search, and to create cohesion with shared navigation and look-and-feel. Because sites can be re-arranged as your needs change, SharePoint hub sites empower your intranet to evolve with your organization.”
[Update March 21, 2018] Rolling out to targeted release customers in Office 365, you can now identify a SharePoint site collection as a “Hub”. Link: Create a hub site in SharePoint Online. As a result, the saying “Hub before you Sub” was born. 🙂
[Update August 13, 2018] Rolled out to targeted release customer in Office 365, you can now control whether site owners can create subsites from modern sites, classic sites, both, or neither.
The main disadvantage I see of subsites are the rigid nature of where they live. Once created, it is not flexible to move them to another location if required. Additionally, if they are not being used and they are a parent to another subsite that is being used, there is no way to remove the unused site – a huge governance issue. If you’re provisioning subsites, you should understand the pros and cons of that decision.
One key feature I would like to see improved is the Content Type Hub for sharing site columns and content types across site collections. If the recommendation is to favor provisioning of site collections rather than subsites, then it is critical that content types and site columns are shareable across them. Currently, this functionality requires work.
Are there pros and cons to both site collections and subsites? Absolutely, yes. However, I believe site collections set you up better for long-term success. If you’ve already provisioned subsites and want to move to this new structure, it will take time to get there but well worth the effort in my opinion.
Thanks for reading.