In several recent projects I've run into the same Copilot governance problem. As Microsoft 365 Copilot and the Copilot Chat app reach more users, a lot more content starts turning up in organisational search and Copilot answers than admins had expected. Teams want their SharePoint sites to stay accessible to the people who actually need them, but they don't want those sites surfacing in Copilot or global search for casual or new users. That's the gap restricted content discovery (RCD) from SharePoint Advanced Management is meant to fill. It's a site-level switch that keeps sensitive or special-purpose sites visible only to people who work with them regularly, and it does this without changing permissions or disrupting how people collaborate.

Restricted content discovery hides sites from search without touching access

RCD isn't a security feature in the traditional sense. Anyone with access to a site keeps access to everything in it. What changes is visibility: with RCD enabled, the site no longer appears in organisation-wide Microsoft 365 search or in Copilot responses for most users, unless they count as "frequent users". Microsoft defines this by interaction. If you visit or work in a site regularly, you stay a frequent user and the site remains discoverable for you. For everyone else it effectively disappears from global search and Copilot, although direct links and APIs still work.

The permission structure stays exactly as it was. That's why RCD suits departments like HR, M&A or executive teams, who need to keep working together internally but want to avoid accidental discovery or oversharing through Copilot or search. The setting lives in the SharePoint admin center under Sites → Active sites → select site → Settings → Restricted content discovery. You can also set it with PowerShell:

# SharePoint Online Management Shell, requires admin rights over the site collection
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/finance" -RestrictContentOrgWideSearch $true

After you turn it on, a full reindex can take several hours or even days, especially on large sites. In the biggest environments I've worked in, it has occasionally taken more than a week. You won't see any effect in Copilot or search until that's finished, so plan for the wait.

RCD differs from restricted SharePoint search and access control

People often ask me how restricted content discovery relates to the other features that control discovery and search. The differences are significant:

  • RCD is site-level: You include or exclude each site individually. Users who aren't frequent users simply won't see it in Copilot or org-wide search.
  • Restricted SharePoint Search is a tenant-wide allow list (Microsoft's documentation): only approved sites ever appear in Copilot or search. It's stricter and gives admins more central control, which is why regulated sectors tend to use it.
  • Permissions stay unchanged in both models. RCD is explicitly not a security boundary. It controls discoverability, not access.

If you want a hands-on deployment guide for restricted search, have a look at my post Restricted SharePoint Search: Copilot pilots done right. For Copilot oversharing governance more broadly, I've written up a practical plan in Copilot oversharing: Deployment blueprint. Microsoft covers the background and configuration in its SharePoint Advanced Management and restricted content discovery documentation.

Most RCD deployments follow a few familiar scenarios

When organisations want to pilot Copilot in a few departments or with a limited group, RCD is usually where they start. The cases I see most often are:

  • HR or finance sites that should only be discoverable for their core teams
  • M&A or other sensitive project sites that need tighter discovery controls but remain open to specific users
  • Executive or leadership sites where only the inner circle qualifies as frequent users

Practical tip: Once you've enabled RCD on a site, give the reindex time to finish, then check visibility in both Copilot and Microsoft Search with accounts from different user roles. You can switch the setting back at any time, but the index won't update straight away.

I always make a point of this: even with RCD in place, frequent users and anyone with a direct link can still search for or open the content. RCD doesn't block API calls, Graph queries or integrations either. It is purely a discoverability filter and doesn't replace classic permissions or Microsoft Purview sensitivity labels. For more on data classification and labelling, see Microsoft Purview Information Protection: Building a pragmatic sensitivity label taxonomy.

The evaluation logic behind RCD is simple

There isn't much to it. For every search or Copilot query, Microsoft checks whether the site has RCD enabled and, if it does, whether the user is a frequent user. This flowchart shows the basic sequence:

flowchart TD
  A["User submits search or Copilot prompt"] --> B["Site marked for RCD?"]
  B -->|"Yes"| C["User is frequent user?"]
  C -->|"Yes"| D["Site appears in search/Copilot"]
  C -->|"No"| E["Site hidden from results"]
  B -->|"No"| D

Figure: How restricted content discovery is evaluated for search and Copilot queries

I see RCD as pragmatic rather than magical

Restricted content discovery does what it says and nothing beyond that. It's a useful governance tool for the awkward cases where you need something between "wide open" and "completely locked down". Just don't mistake it for a security control. If you need real access control or information protection, pair RCD with permission reviews, Purview sensitivity labels and stricter discovery options such as restricted SharePoint search. The governance question underneath it all doesn't change: who needs access to a site, and who should be able to find it? I go into Copilot governance and access controls with SharePoint Advanced Management in more detail in SharePoint Advanced Management: Real Copilot readiness controls.