10 problems with subsite architecture in SharePoint
Table of contents
Although most Microsoft 365 customers have a flat SharePoint Architecture, my consulting experience has revealed a surprising number of customers don’t have one. This post will address the downstream effects this causes across Microsoft 365.
Flat SharePoint architecture explained: Why Microsoft recommends it
It’s the preferred architectural model from Microsoft (and me) where all sites in your SharePoint environment are top-level sites (formerly referred to as site collections) with no subsites created underneath. All the ways to create sites within the Microsoft 365 UI today (SharePoint, OneDrive, Teams, Planner, etc.) automatically enforce a flat SharePoint Architecture because they all create (top-level) sites, not subsites.
You may be asking… why are organizations still using subsites? There are a few reasons I still see subsites in a fair number of my customers’ SharePoint environments:
- Third-party solutions have been integrated into SharePoint and the solutions automatically create subsites as part of their function. An example of this for a recent customer was a legal software app that created a new subsite for each new legal matter. Hundreds of subsites.
- Project Online can be configured to create a subsite for each new Project in the Project Web App settings. I have customers that have done exactly this resulting in hundreds of project subsites.
- Legacy processes may remain from years past. For example, someone on the Vendor Management team creates a new subsite for each new vendor. Carry-over processes are quite common to see in organizations that have been in SharePoint a long time and/or have migrated from a SharePoint on-prem environment into SharePoint Online and have retained these legacy processes.
- End users (site owners) have discovered the New… Subsite button and have created subsites to self-organize their content. It conveniently inherits permissions, content types, navigation and it’s quick. There’s no waiting for IT to approve a request if there is a time-consuming process to do so.
Preventing subsite sprawl: How to disable subsite creation in SharePoint
Over time, organizations should look at addressing all 4 reasons above, but at a minimum, my top-level guidance is to disable the option for end users to create subsites in the first place (reason 4). End users will see the option to create a new subsite on the SharePoint Site contents page under the New button. Unfortunately, organizations must explicitly turn OFF the ability for users to create subsites as that feature is ON by default (even in new tenants).
A SharePoint administrator can set this in the classic settings page in the SharePoint Admin Center (https://<domain>admin.sharepoint.com/_layouts/15/online/TenantSettings.aspx).
10 major drawbacks of SharePoint subsites you can’t ignore
An environment containing subsites may, over time, start to see some undesirable downstream effects. Here’s my top 10…
1. Site storage quota limitations: A hidden cost of SharePoint subsites
The storage quota is shared between all subsites and the top-level site. There is a hard limit on this space, so you may encounter this issue at some point. Compounding this issue is the fact that many Purview controls use a special (hidden) library on the top-level site (and subsites if you have them) called the Preservation Hold Library (PHL) to retain content. All of this contributes to the site storage quota. Beware!
Link: https://learn.microsoft.com/en-us/sharepoint/manage-site-collection-storage-limits
2. The pain of reorganizing subsites: Breaking links and migration headaches
If you ever need to *move* a subsite from one parent site to another, it will require a migration (either manual or automated) which will change the subsite’s URL as a result causing links to break. An example of this is if you have built a subsite structure to mimic your organizational hierarchy, a common approach I see in legacy SharePoint environments particularly in small organizations.
The modern way of establishing a virtual hierarchy across sites is to identify a site as a SharePoint Hub and connect other sites to it—no subsites are required.
Link: https://learn.microsoft.com/en-us/sharepoint/planning-hub-sites
3. How SharePoint subsites lead to URL limitations and broken links
Subsites add to the length of a URL. Exacerbating this is the fact that subsites can also be nested. The combination of the folder path (includes the site and subsites) and file name can therefore become a constraint (400 characters as of June 2025). Different apps and Office versions also have different limits.
Note: URL lengths can also be a problem in a flat SharePoint architecture if there are many nested folders in a document library causing the final URL length to a file to exceed the limit.
Link: Restrictions and limitations in OneDrive and SharePoint – Microsoft Support
4. The challenges of subsite lifecycle: Why governance fails in non-flat SharePoint
Most sites, particularly collaboration sites, have a start, a middle active period, and an end. Governance processes put in place across these lifecycle stages is critical for ensuring the content within is appropriately protected and retained and, in some cases, deleted when it is safe to do so. Having a well-established site lifecycle process in place can significantly reduce an organization’s data risk while ensuring they remain compliant.
Many features in Microsoft 365 can help manage a site’s lifecycle, but they are all built with the assumption of the lifecycle of a site and not a subsite. A few examples that help with the middle active period and the end:
- Data Access Governance reports (Sharing links, Content shared with ‘EEEU’, etc.) in the SharePoint Admin Center all provide reports by site (not subsite) and are sent to the site owner (not the owner of the subsite).
- Site lifecycle management reports (Inactive site policies, Site ownership policies) are a great way of ensuring all sites have owners (an important role) and who can decide what to do with content when the site is no longer active. Note that these reports require a SharePoint Advanced management subscription.
Applying the appropriate protection and retention controls to content during the middle active period of a site involves integrating some Microsoft Purview solutions, which brings me to the remaining downstream effects of subsites.
Why flat SharePoint architecture is crucial for Microsoft Purview effectiveness
These effects are perhaps the biggest ones to be aware of and may be the tipping point to moving toward a flat architecture if you don’t already have one. Many organizations are looking to improve their data security posture across their Microsoft 365 environment, and by not having a flat SharePoint Architecture, they may struggle implementing some of these compliance controls targeting SharePoint in a flexible and scalable way.
Simply put, Purview works best with a Flat SharePoint architecture. Here are some effects to demonstrate.
5. A compliance risk: SharePoint subsites undermine container sensitivity labels
A Purview container sensitivity label controls important site data security controls such as external sharing, guest access, site privacy, and numerous conditional access controls. They are a critical part of an organization’s holistic data security strategy. These sensitivity labels are applied at a site level and will automatically include any subsites that may exist under it. Although this may be what you want at times, it may not always have the desired effect.
Example where subsites may be a challenge for container sensitivity labels: in the Legal subsite example I gave earlier, there may be cases where you want to collaborate with an external law firm on some of the legal matter subsites. You can control external sharing and guest access at a site level to accomplish that requirement; however, you CANNOT control external sharing and guest access at a subsite level. All subsites within a site will always adhere to the settings configured on the top-level site’s container sensitivity label if there is one.
Link: https://learn.microsoft.com/en-us/purview/sensitivity-labels-teams-groups-sites
6. SharePoint subsites hinder granular DLP policy enforcement
A DLP policy can target SharePoint as a location and even specific sites (not subsites) for more granular control.
Example where subsites may be a challenge for DLP policies: With a DLP policy, if you wanted to block sensitive information from being shared externally from all sites while allowing it for 1 subsite if users of that subsite had a legitimate business reason to share certain sensitive information, you couldn’t do this.
Link: https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp
7. SharePoint subsites disrupt effective retention policies and data governance
Retention policies retain/delete content and can only be published to a site and not a specific subsite. If there is a retain component to the retention policy, it will also use the PHL to retain changes and deletions on the site. This means there is a dual negative side effect to a subsite structure.
Example where subsites may be a challenge for Retention policies: If you had a retention policy configured to Retain for 7 years then automatically delete and published to a site that had subsites, the retention would holistically apply to everything including all content on the subsites, no exceptions. There is no way to exclude it. This also has the effect of contributing to the site’s storage quota which may be problematic if there is high data volume and activity on the site and subsites within.
Link: https://learn.microsoft.com/en-us/purview/create-retention-policies?tabs=teams-retention
8. Why published retention labels struggle with SharePoint subsite structures
Like a retention policy, retention labels can also retain/delete content, but they do it at an item level. They can be applied to content in many ways, but the most common ways are to either publish the labels to sites so they can be defaulted/manually applied to content within or auto-apply the label to items on sites.
An example of where subsites may be a challenge for published Retention labels is that they can only be published to sites and not subsites, so all subsites will receive the same published retention labels. This may be the desired effect; however, if you had one subsite that needed to have a different set of published retention labels, this is not possible.
Note: The good news for subsites is an auto-applied retention label will find matching content in the parent site as well as all subsites under it by simply targeting the parent site.
Link: https://learn.microsoft.com/en-us/purview/create-retention-labels-data-lifecycle-management
9. The challenge of prioritizing high-risk content in SharePoint subsites for IRM
Purview’s Insider Risk Management (IRM) solution can prioritize specific sites as holding higher risk content than others by increasing the risk score for activity done on that site. The identification of these SharePoint sites does not allow for a specific subsite to be specified.
Example where subsites may be a challenge for identifying priority content in IRM: If there was a single subsite that had higher risk content than others (a sensitive project subsite, for example), the subsite cannot be singled out in IRM as a priority site when checking for risky activity. The entire parent site is the only option when targeting SharePoint. There are other ways to prioritize content that may need to be considered, such as sensitive information types, trainable classifiers, sensitivity labels, or file extensions.
10. SharePoint subsites drive up costs for on-demand data classification
This is a relatively new but very important Purview feature that allows for the classification of historical data in SharePoint sites. The effect of executing an on-demand classification is to ensure the content within the SharePoint site (and all subsites within) are reclassified with the built-in and custom sensitive information types (SITs) that are currently defined in your tenant. This then allows for policies to take effect on this content: DLP policies, IRM policies, Sensitivity label auto-labeling policies, and Retention label auto-apply policies.
One very important thing to know about on-demand classification is the additional cost associated with it (a Pay-as-you-go service). The more files that are evaluated and classified, the more it’s going to cost you.
Example where subsites may be a challenge for on-demand classification: If you have a subsite structure and you need to reclassify only 1 subsite under the parent site, you will not be able to do this. You would have to classify the entire site which would automatically include all subsites within (see the cost comment above). Although there is an option to only classify content for a date range, this will still apply to all subsites as well if there are any.
Link: https://learn.microsoft.com/en-us/purview/on-demand-classification
Embracing a flat SharePoint architecture: Your path to better governance and compliance
It’s hard to argue with the advantages of a flat SharePoint architecture. They provide the most flexibility and granularity for permissions, features, storage, lifecycle management and Purview features.
Depending on the number of subsites and the complexity of the structure, moving from a subsite to a flat architecture can vary from a minor to a major effort and, in some cases, can be a full-on migration project.
Hopefully, this post has provided some sound reasoning for moving away from subsites as soon as possible so you can take advantage of the capabilities of a flat architecture.
