Hide SharePoint Sites from Copilot: 5 Limits to Know

Restricted Content Discovery is the setting that hides a SharePoint site from Microsoft 365 search and Copilot without touching a single permission. Microsoft has been rolling out an enhanced version since late July 2026, with completion expected in late September 2026, and it closes the most confusing gap in how the feature used to behave.

The short version of the update: files a user recently accessed no longer surface in Copilot or Microsoft 365 search when the site is covered by a policy, and the AI entry points disappear from the site entirely. That second part catches people out, so it gets its own section below.

In this post: Prerequisites · What it actually does · What it does not do · The licensing surprise · Turning it on · Why nothing happens for a week · Delegating it to site admins · Finding every restricted site · The trade you are making · When would you actually use this? · Related reading

Prerequisites

A qualifying base subscription: Office 365 E3, E5 or A5, or Microsoft 365 E1, E3, E5 or A5, or a GCC, GCC High or DoD tenant.
SharePoint Advanced Management availability, which is the part people get wrong. See the licensing section below, because it is cheaper to satisfy than most teams assume.
SharePoint Administrator or SharePoint Advanced Management Administrator in Microsoft Entra ID. The second role is newer and adds governance capabilities on top of the first, including removing permissions at scale.
The current SharePoint Online Management Shell. Download the latest build before running anything. An older install is the usual reason a cmdlet below reports that a parameter does not exist.

What it actually does

Restricted Content Discovery is a site level property. Switch it on and Microsoft 365 search systems propagate the setting so content from that site stops appearing in organisation wide discovery surfaces: SharePoint home, Office.com, Bing, and Copilot responses that rely on tenant wide discovery. A Restricted tag becomes visible on the site so nobody has to guess whether a policy applies.

Microsoft describes it as a temporary governance control, and that framing matters more than it sounds. The intended use is buying time: you suspect a Finance or HR site is overshared, you need Copilot rolled out anyway, so you restrict discovery while site owners review who actually has access. It is a holding action, not a remedy.

What it does not do

This is the part to be blunt about, because treating the setting as a fix is how organisations end up with a false sense of resolution.

Restricted Content Discovery changes discoverability, not access. Every person who could open that document yesterday can still open it today. Nothing about the permission model moves.

Permissions are untouched. If a site was shared with Everyone Except External Users, it still is. The link somebody pasted into a Teams chat still works.
Content stays in the search index. The setting filters discovery surfaces rather than removing anything, which is why Purview capabilities such as eDiscovery and auto labelling keep working normally.
SharePoint sites only. OneDrive is not supported, so a user hoarding sensitive files in their own OneDrive is outside the scope of this entirely.
Site context search is unaffected. Search from within the site itself still returns results, as do Microsoft 365 Feed and Recommendations.
There is a ceiling of 20,000 sites per tenant. Generous for targeted use, and a hard stop if somebody decides to restrict everything by default.

Microsoft pairs that ceiling with an explicit caution against overuse, and the reasoning is straightforward: every site you restrict is content Copilot can no longer draw on, so the answers it gives get thinner. Restricting broadly to feel safe quietly degrades the thing you bought Copilot for.

The licensing surprise

The common assumption is that SharePoint Advanced Management needs tenant wide Copilot licensing or a paid add on. Neither is necessarily true. You get SharePoint Advanced Management capabilities for Copilot deployment scenarios when at least one user in the organisation holds a Microsoft Copilot licence, and Microsoft states plainly that this user does not need to be a SharePoint administrator.

One licence, assigned to anybody, and your SharePoint administrators get access. The alternative routes are a SharePoint Advanced Management Plan 1 add on (sometimes called the standalone) on top of a SharePoint K, P1 or P2 subscription, or Microsoft 365 E7, the Frontier Suite bundling E5, Copilot, Entra Suite and Agent 365.

The Copilot licence route covers the Copilot deployment features specifically. Some other SharePoint Advanced Management capabilities, restricted site creation among them, still require the Plan 1 add on, so check the feature you want before assuming one licence unlocks everything.

Turning it on

Through the admin centre: expand Sites, select Active sites, pick the site, open the Settings tab and switch on Restrict content from Microsoft Copilot, then save. Through PowerShell, which is the only sane approach past a handful of sites:

# Restrict a site
Set-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/finance" -RestrictContentOrgWideSearch $true

# Lift the restriction once the permissions review is finished
Set-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/finance" -RestrictContentOrgWideSearch $false

# Confirm the current state of a single site
Get-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/finance" | Select RestrictContentOrgWideSearch

Read the parameter name twice. It is RestrictContentOrgWideSearch, not anything containing “Copilot”, even though the admin centre labels the same setting Restrict content from Microsoft Copilot. Searching for a Copilot named parameter finds nothing and sends people off looking for a feature that is already in front of them.

Why nothing happens for a week

Set the property and nothing visibly changes. The setting has to propagate across indexing systems, and how long that takes depends on the size of the site, the number of files in it, and how many other sites are being updated at the same time.

Microsoft puts a number on the bad case: for sites with more than 500,000 items, the update can take more than a week to fully reflect in search and Copilot. If you restrict a large site on Monday and test on Tuesday, seeing results is expected behaviour, not a failure. Plan the review window around that rather than raising a support ticket on day two.

Delegating it to site admins

By default only SharePoint administrators can manage the setting, which becomes a bottleneck the moment site owners start asking for it. Delegation is a tenant level switch:

# Let site administrators manage the setting on their own sites
Set-SPOTenant -DelegateRestrictedContentDiscoverabilityManagement $true

# Check whether delegation is currently on
Get-SPOTenant | Select-Object DelegateRestrictedContentDiscoverabilityManagement

There is a sensible control attached. When a site administrator changes the setting, they are required to provide a justification, and that justification is captured. Enabling, disabling and the justification text all surface as Microsoft Purview audit log activities, so delegation does not mean losing visibility.

Finding every restricted site

Checking sites one at a time does not scale, and a restriction left on after a review finishes is invisible until somebody complains that Copilot ignores their site. There is a dedicated report for exactly this:

# Kick off the tenant report
Start-SPORestrictedContentDiscoverabilityReport

# Check its status and collect the report ID
Get-SPORestrictedContentDiscoverabilityReport

# Download it once it has finished
Get-SPORestrictedContentDiscoverabilityReport -Action Download -ReportId <ReportGUID>

Running this on a schedule is the practical habit. Because the feature is meant to be temporary, the interesting question is not which sites are restricted but which have been restricted for longer than anybody intended.

The trade you are making

This is the part of the September 2026 rollout most likely to generate helpdesk tickets. Restricting a site does not just filter it out of tenant wide search results. It removes the AI entry points from the site itself. Users on that site no longer see the Copilot button, the AI actions menus including agent creation, or Create pages with AI.

From the user’s side there is no explanation attached, just features that were there last week and are not there now. The enhanced behaviour also means files a user recently interacted with stop appearing in Copilot and search, which removes a route people had been relying on without realising it.

Brief the helpdesk before restricting anything visible, and keep a list of restricted sites where support staff can reach it. A ticket that reads “Copilot has disappeared” is much cheaper to close when somebody can check the site against a list in under a minute.

When would you actually use this?

A Copilot rollout is scheduled and a permissions review is not finished. This is the scenario the feature was built for. Restrict the sites under review, ship Copilot, lift the restrictions as each review completes.
A site is known to be overshared and fixing it properly will take weeks. Restricting buys time, but only if somebody owns the actual remediation. Without that, it becomes permanent by accident.
A phased rollout by department. Restrict the departments not yet onboarded so their content does not surface in answers for people who have not been briefed.
Not as a substitute for permissions work. If the concern is that the wrong people can open a file, this setting does nothing about it. Breaking inheritance and correcting the permission model is the fix, and it is a different job.

What you need to know about SharePoint Administration covers where SharePoint Advanced Management sits among the admin roles referenced in the prerequisites above.
SharePoint Permissions: A Comprehensive Guide for Managing Access Control is the actual remedy for the problem this setting only conceals, and the one to read before the review window closes.
SharePoint Compliance Policy and Governance puts Restricted Content Discovery in context alongside the other governance controls it is meant to work with.

Restricted Content Discovery is a good tool used narrowly and a bad habit used broadly. The setting itself takes seconds to apply. The work that makes it unnecessary takes considerably longer, which is precisely why the restriction has a way of outliving the review it was supposed to cover.

How many sites is your tenant actually restricting, and has anyone come close to the 20,000 ceiling in practice? Comments are open.