You open the SharePoint admin centre, navigate to Active Sites, and start scrolling. Four hundred results. Then five hundred. Eventually you stop counting and start wondering: how many of these does anyone actually use? How many belong to projects that finished two years ago? How many were created by employees who have since left? Site sprawl is the slow accumulation of answers to those questions, and most Microsoft 365 tenants have it to some degree.
What Is SharePoint Site Sprawl?
SharePoint site sprawl is the state in which a Microsoft 365 tenant contains more site collections than the organisation can effectively govern. The sites are real: they exist in the tenant, consume storage quota, carry permissions, and are included in compliance scope. The problem is that no one actively manages most of them. Owners have moved on or forgotten they own the site at all. The content has not been updated in eighteen months, and permissions still reference groups from a project team that disbanded years ago.
Sprawl is not the same as scale. A large tenant with thousands of genuinely active, well-governed sites is not sprawl. Sprawl is characterised by the ratio of active to forgotten sites. When the majority of sites in the list would not be missed if they were deleted tomorrow, that is sprawl.
Where SharePoint Site Sprawl Comes From
Four mechanisms produce the vast majority of site sprawl in Microsoft 365 tenants. Understanding which ones are active in your environment is the first step toward preventing future accumulation.
Microsoft Teams Auto-Provisioning
Every Microsoft Teams team or private channel backed by SharePoint automatically creates a site collection in the background. This is by design: Teams uses SharePoint Online as its file storage layer. The practical consequence is that every time someone creates a Teams team, a SharePoint site appears in the admin centre, whether the team is used for three days or three years.
In organisations where Teams creation is unrestricted, the number of abandoned Teams-linked sites grows rapidly. A team created for an offsite event, a short project sprint, or a temporary working group may see its SharePoint site persist in the tenant for years after the team is forgotten. The site does not disappear when the team goes quiet. It sits there, consuming quota, appearing in search results, and complicating governance until someone explicitly removes it.
Self-Service Site Creation
By default, any Microsoft 365 user can create a SharePoint communication site or group-connected team site from the SharePoint start page. This is a deliberate design choice by Microsoft to encourage adoption. It also means that site creation outpaces site decommissioning in almost every organisation that does not actively restrict it.
A marketing coordinator creates a site to collect campaign assets. Department managers spin up team sites for quarterly initiatives. When an IT administrator creates a test site to trial a new feature, it rarely gets deleted afterward. None of these actions go through a provisioning approval gate or come with a built-in expiry. They simply exist until someone removes them.
Project Sites Without an Exit Plan
Project-based site creation is one of the most common sources of sprawl, and the problem is not the creation: it is the lack of a defined end state. When a project finishes, the site often enters a state of drift. The project team has disbanded, but the site owner account is still active, so no inactive site policy fires. Eight months without a content update sounds like inactivity, but it falls below the eighteen-month threshold used by Microsoft's built-in policies. Rather than trigger decommissioning, the site just sits there, neither active nor removed, until the tenant accumulates dozens of these half-finished remnants.
Migration Residue
Cross-tenant migrations and consolidation projects frequently leave behind test sites, staging environments, and pre-migration snapshots. These are created deliberately during the migration as working spaces and are then forgotten once the cutover completes successfully. A tenant that absorbed two subsidiaries over the past four years may have thirty migration staging sites still sitting in the active site list, holding old content that was superseded by the migration itself.
How Site Sprawl Costs Your Organisation
The cost of sprawl is diffuse. No single abandoned site causes a visible crisis. The damage accumulates across four areas over time.
Storage costs. Every site collection consumes tenant storage quota. Abandoned sites hold their content, including version history, until they are explicitly deleted. A tenant that is nearing its storage limit may be able to reclaim significant capacity by removing sites that hold content no one is actively using. Purchasing additional Microsoft 365 storage at the current rate per gigabyte becomes less attractive when the alternative is cleaning out sites that are taking up space with content no one will ever access again.
Copilot search quality. Microsoft 365 Copilot indexes SharePoint content to answer questions and generate summaries. A tenant with extensive site sprawl gives Copilot more low-quality, stale, and irrelevant content to draw on. Copilot may surface five-year-old project documents from a decommissioned programme when a user asks about current strategy. The AI does not know that a site is abandoned; it sees accessible content and includes it. Cleaning up the site catalogue before enabling Copilot is one of the most practical steps an admin can take to improve response quality from day one.
Governance surface area. Each site is a permission boundary. Each one may have unique permissions, active sharing links, and groups that reference former employees. The more sites a tenant contains, the harder it is to maintain a current and accurate picture of who has access to what. Compliance audits become more expensive. Entra ID access reviews cover a larger surface. The cost of each permission or sharing cleanup exercise scales with the number of sites in scope.
Admin overhead. Site sprawl does not manage itself. Every ownership reassignment, every inactive-site notification response, every storage report run covers a larger set of sites than would exist in a well-governed tenant. The cumulative overhead of managing a thousand sites rather than four hundred is not trivial.
See how Space Master handles bulk site deletion in ShareMaster
Building a Site Inventory Baseline
You cannot clean up what you cannot see. The starting point for any site sprawl remediation is a complete, current inventory of every site collection in the tenant, with the data needed to make a decision about each one.
The fields that matter most for sprawl analysis are: site URL, site owner, last modified date, last activity date, storage consumed, and whether the site is linked to an active Microsoft 365 group or Teams team. With this data, you can rank sites by inactivity, filter by owner status, and identify clusters of related sites (such as all the project sites created in the same quarter) that can be reviewed together.
The SharePoint admin centre provides some of this data natively through the Active Sites report, but the export format limits what you can do with it. A Report Master export produces a richer dataset that can be filtered and sorted in Excel, making it practical to build a tiered list: sites to delete immediately, sites to archive, sites to investigate further, and sites confirmed as active and compliant.
The guide to identifying inactive SharePoint sites covers the specific signals to look for when classifying sites in this inventory: inactivity thresholds, ownership signals, and how to distinguish a genuinely unused site from one that is read-only but still actively referenced.
Cleaning Up and Keeping the Catalogue Clean
Once the inventory is complete and sites are classified, the cleanup operation itself is fairly direct. The decision most admins delay is the archive-versus-delete question: some sites hold content that has business or legal value even though no one is actively using it. Permanently deleting those sites is wrong, but leaving them in the active site list adds to the governance burden. The right answer is usually to archive them.
The SharePoint archive vs delete decision guide walks through the criteria for each outcome. In brief: sites that need to be retained for compliance or legal hold reasons should be archived or placed in a read-only state. Sites whose content has no ongoing legal or business value can be deleted after a brief review window to allow stakeholders to raise objections.
For sites confirmed ready for deletion, Space Master's bulk delete capability lets you remove dozens of sites at once rather than clicking through the admin centre individually. Deleting sites one at a time through the standard UI is workable for removing five or ten sites. For the thirty or fifty that a typical sprawl cleanup uncovers, a bulk tool makes the operation fast enough to actually do it rather than defer it indefinitely.
After the initial cleanup, keeping the catalogue clean requires a few governance changes that did not need to exist before the sprawl developed:
- Site creation policy. Restrict Teams team creation and SharePoint site creation to approved users or require approval through a provisioning workflow. This does not need to be bureaucratic: a simple approval from a team's manager or department head is enough to add a human checkpoint to site creation.
- Site expiry and renewal. Enable Microsoft 365 group expiry policies so that group-connected sites must be actively renewed. Sites whose owners do not respond to renewal notices are deprovisioned automatically after a grace period. This prevents the accumulation of forgotten project sites without requiring manual cleanup runs.
- Ownership accountability. Configure the inactive site policy in the SharePoint admin centre to notify site owners when their sites have been inactive for a defined period. This shifts some of the cleanup responsibility to the people closest to the content, and ensures that sites do not go unnoticed for years at a time.
- Periodic inventory reviews. A site inventory review once or twice per year, combined with an active use of the inactive site policy, prevents the backlog from rebuilding after the initial cleanup. The maintenance burden is far lower than the remediation cost once sprawl has accumulated over multiple years.
Site sprawl is not a condition that appears suddenly; it builds slowly across every month that site creation outpaces decommissioning. Addressing it is less about a single large cleanup project and more about establishing the lightweight governance habits that keep creation and retirement in balance over time.