Copilot is only as useful as the content it finds. Enable it on a SharePoint tenant with years of uncleaned version history, empty folders, and inactive sites, and it will surface outdated documents and redundant files right alongside the relevant ones. The preparation work is not glamorous, but it determines whether your users trust what Copilot returns.
What Copilot Searches in Your SharePoint
Microsoft 365 Copilot draws from the content you have access to across SharePoint Online, OneDrive for Business, and Teams-connected libraries. It indexes documents, list items, and site pages across all sites where you have at least read access. That scope is also its limitation: Copilot has no way to distinguish between a current, approved document and a draft from three years ago sitting in the same library.
Why stale content matters more than you think
Every outdated policy document, every redundant version of a project file, and every abandoned draft in a shared library is a candidate result when a user asks Copilot a question. Copilot ranks results by relevance signals including recency, but old content does not disappear from its reach. A tenant where version history was left uncapped across hundreds of libraries may have tens of thousands of historical file versions that Copilot treats as potentially relevant content. Cleaning that up before enabling Copilot produces measurably better results from day one.
What Copilot cannot reach
Two categories of content are excluded from Copilot: sites in the Microsoft 365 Archive tier (they are removed from the search index when archived), and content the user does not have permission to access (Copilot strictly respects existing SharePoint permissions and will not surface a document to someone who cannot already open it). Those exclusions are useful anchors for the cleanup strategy: archiving a site removes it from Copilot scope cleanly, and you do not need to delete content that is simply permission-restricted.
Step 1: Build a Storage Inventory First
Before touching anything, know what you have. A site-by-site storage report tells you where version history is deepest, which libraries have grown the most, and which sites have been inactive long enough to consider archiving. Cleaning without this data means you will spend effort on sites that barely register on the total quota while missing the few that account for the majority of the bloat.
| Signal to look for | What it indicates |
|---|---|
| Sites consuming more than 5 GB with no recent activity | Strong candidates for archiving or decommission before Copilot is enabled |
| Libraries with version counts above 200 per document on average | Versioning was left uncapped; version trimming will recover significant storage |
| High proportion of zero-byte folders or folders with no documents | Folder structure has grown without cleanup; empty folder removal is appropriate |
| Sites last accessed more than 12 months ago | Inactive site policy candidates; consider archiving rather than keeping in active Copilot scope |
Report Master can export a storage utilisation report to Excel across all site collections, giving you version counts, last activity dates, and storage per site in a single workbook. That output becomes the working document for your Copilot prep. To understand which sites qualify as inactive, see how to identify inactive SharePoint sites before running the cleanup steps below.
Step 2: Trim Version History at Scale
Version history is almost always the single largest storage consumer in a SharePoint tenant that has been running for more than a few years. A library where versioning was turned on at creation and never capped will accumulate hundreds of versions per document as users co-author and save regularly. Across thousands of libraries, that adds up fast. The result is a bloated tenant quota and a Copilot content pool cluttered with historical copies no active user needs.
There are two aspects to addressing version bloat. The first is setting a limit that prevents future accumulation. In the SharePoint admin center under Settings, you can configure a default version limit that applies to all new libraries going forward. Options include a count limit (for example, keep the 50 most recent major versions) or an automatic mode that Microsoft manages based on usage signals.
The second, and more time-consuming, task is trimming the existing backlog on libraries already in production. A library created five years ago may have accumulated thousands of versions that the new default setting will not retroactively remove. You need a tool that can work across all libraries tenant-wide rather than one library at a time.
Trimming SharePoint version history covers the full process in detail, including setting count and age limits and confirming what is safe to remove. For tenant-wide trimming at scale, Space Master's Version Trimmer removes versions above a count threshold or older than a set age across all sites in one pass, without requiring manual library-by-library work.
See how Space Master handles tenant-wide version trimming
Step 3: Remove Empty Folders and Stale Libraries
Empty folders do not consume meaningful storage, but they matter for Copilot in a different way: they inflate the folder hierarchy that the search index and sync clients must traverse, and they add visual noise in search results when Copilot lists locations rather than specific files. The noise compounds at scale. A tenant with thousands of empty folders - common after migrations or OneDrive sync issues - produces noticeably noisier Copilot results than one with a clean folder structure.
The scale of empty folder cleanup is what makes manual removal impractical. A single SharePoint migration or OneDrive sync issue can leave hundreds of empty folder stubs across a library. Tenant-wide, the count can be in the thousands. Space Master's Empty Folder Remover scans libraries across all selected sites and removes folders that contain no files, including nested chains of empty subfolders, in a single operation.
Alongside empty folders, look for libraries that were created for a project or purpose that no longer exists but still appear in search results. An empty library with a descriptive name ("Q3 2021 Campaign Assets", for example) will appear as a Copilot result when a user searches for campaign content. If the library genuinely has nothing in it, deleting it removes it from Copilot scope entirely.
Step 4: Archive or Delete Inactive Sites
Inactive sites are one of the cleanest wins in a Copilot preparation project. A site that has had no meaningful activity for 12 months or more is a candidate to either archive (moving it to the Microsoft 365 Archive tier and removing it from Copilot's index) or delete outright (if the content has passed any required retention period and is no longer needed).
The distinction matters for Copilot specifically because archived sites drop out of search indexing immediately. Users asking Copilot about a topic will not see results from archived sites, which reduces the chance of outdated content appearing in Copilot responses. By contrast, a site that is simply permission-restricted but still active will continue to appear in results for users who have access to it.
The decision between archiving and deleting comes down to retention requirements and whether the content might be needed for reference. For the detailed process, see the guide on archiving a SharePoint site with Microsoft 365 Archive. If your goal is Copilot scope reduction rather than record-keeping, archiving is almost always the right choice: content is preserved, it is excluded from Copilot, and reactivation is available if something turns out to be needed.
A final area to address before enabling Copilot is content access. Copilot respects SharePoint permissions strictly, so any files that are overshared (accessible to "Everyone" or to a broad external audience) will appear in Copilot results for all those users. See the SharePoint permissions audit guide for the steps to identify and remediate overshared content before your Copilot rollout.
Frequently Asked Questions
Does trimming version history remove files that Copilot uses?
No. Version trimming removes old copies of a file, not the current version. The most recent version of every document stays untouched, and Copilot continues to index it normally. Trimming only affects how far back in history a user can restore.
How many versions should I keep before enabling Copilot?
Microsoft does not publish a Copilot-specific version count target. A sensible starting point is 50 to 100 major versions for standard document libraries, and a lower count or time-based limit (for example, versions older than 12 months) for libraries with high edit frequency. Consistency across the tenant matters more than the precise number.
Does Copilot index the content of archived SharePoint sites?
No. Sites moved into the Microsoft 365 Archive tier are removed from the active search index. Copilot cannot surface content from an archived site. Teams that need Copilot to find documents in a particular site must keep it in the active tier.
How long does a full SharePoint cleanup take for a large tenant?
It depends on site count and version depth. A tenant with a few hundred sites and moderate version history can typically be cleaned over a weekend using automated tools. A tenant with thousands of sites where versioning was uncapped for years may need several passes across a few weeks to work through systematically without affecting active users.