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 duplicate copy 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. Note what that does and does not include: search returns files, not each file's old versions, so version history is a storage problem rather than a Copilot-results problem. The clutter that changes answers is stale current files, duplicates and abandoned sites, and that is what the steps below aim to remove.
What Copilot cannot reach
Three categories of content are kept out of Copilot: content archived with Microsoft 365 Archive (Microsoft states archived content isn't used by Copilot), sites an admin has hidden with Restricted Content Discovery in SharePoint Advanced Management, and content the user does not have permission to access (Copilot 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 takes it out of 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 |
ShareMaster's Tenant Storage Metric report (in Reports, part of Report Master; it needs the SharePoint Administrator role) walks every site and writes each document library's total size, current file size and the amount trimming versions would save to Excel, with a sheet of the largest files. It does not include activity dates, so pair it with an export of the Active sites list in the SharePoint admin centre, which carries last activity per site. Together they become 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. It does not make Copilot's answers worse, but a Copilot project is often the moment the storage bill gets looked at, so it belongs on the same list.
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, version history limits set the default for all new libraries going forward. Options are an automatic setting that Microsoft manages, or a manual count limit (the admin centre will not accept fewer than 100 major versions) with an optional expiry period.
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. Microsoft lets site admins queue trim jobs for existing versions through PowerShell, and versions removed that way are deleted permanently, bypassing the recycle bin.
Trimming SharePoint version history covers the full process in detail, including setting count and age limits and confirming what is safe to remove. For trimming many sites at once, Space Master's Bulk Version Trimmer works through every document library on the sites you select, keeping the number of versions you set and, optionally, deleting only versions older than a date you choose. Run it as a report first to see what it would remove.
See how Space Master handles tenant-wide version trimming
Step 3: Remove Empty Folders and Stale Libraries
Empty folders do not consume meaningful storage, and they hold nothing for Copilot to quote. Their cost is to people: they clutter the folder trees users browse and sync, and a cleaner structure makes it easier to judge where content should live before you start archiving.
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. Space Master's Empty Folder Remover works through a document library or folder you choose and sends every folder that holds no files and no subfolders to the recycle bin, including nested chains of empty subfolders. An optional date keeps folders modified after it.
Alongside empty folders, look for libraries that were created for a project or purpose that no longer exists. An empty library with a descriptive name ("Q3 2021 Campaign Assets", for example) still turns up when people browse or search for that topic. If the library genuinely has nothing in it, deleting it removes the dead end.
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, which takes it out of Copilot's reach) or delete outright (if the content has passed any required retention period and is no longer needed).
The distinction matters for Copilot specifically because Microsoft states that archived content isn't used by Copilot. Users asking Copilot about a topic will not get answers built from archived sites, which reduces the chance of outdated content appearing in Copilot responses. Archived sites also stop being directly accessible to users until an admin reactivates them, so tell the owners first. 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. In the SharePoint admin center the lowest manual limit you can set is 100 major versions (or a 30-day expiry), and the automatic setting manages the count for you. For libraries with high edit frequency, adding a time-based limit (for example, versions older than 12 months) is a sensible extra. Consistency across the tenant matters more than the precise number.
Does Copilot index the content of archived SharePoint sites?
No. Microsoft states that archived content isn't used by Microsoft 365 Copilot. Archived sites also stop being directly accessible to users until an admin reactivates them. 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.