Copilot grounding vs SharePoint search
By Emil Björk · Microsoft ecosystem consultant, Gothenburg
Why Copilot finds documents that SharePoint search doesn't (and vice versa) — the semantic index, how retrieval for Copilot differs from Microsoft Search, what that means for oversharing, and the controls that shape what Copilot can reach.
A recurring surprise in Copilot pilots: a user asks Copilot about a project and it quotes a document they'd never have found through the SharePoint search box — sometimes one they didn't know they had access to. The instinct is to assume Copilot has bypassed something. It hasn't. What it has done is retrieve differently, and understanding that difference is the key to both the delight and the anxiety. This guide explains how Copilot grounds its answers, how that compares to classic SharePoint and Microsoft Search, and which controls actually shape the result.
Two retrieval systems, one permission model
Microsoft Search (which powers the SharePoint search box, the Office.com search bar, and Bing for work) is a lexical search engine with a lot of intelligence on top: it matches terms, weights titles and metadata, and ranks with signals from the Microsoft Graph — who you work with, what you've opened, what's trending near you. It returns a list of results. It is very good at "find the document called X" and reasonable at "find things about Y" when Y is a word that appears in the documents.
Copilot grounding starts from the same index but adds a semantic index — vector representations of content that let the system match on meaning rather than terms. When you ask Copilot a question, the orchestrator turns it into retrieval queries against Microsoft Search and the semantic index, pulls back the most relevant chunks of content (not whole documents), and feeds those chunks to the model as context. The model then writes an answer citing the sources it used.
Both systems enforce the same permission trimming: you only get results you could open yourself. There is no separate Copilot permission model, no elevated service account reading everything, and no "Copilot can see it but you can't." What's different is reach and recall. Copilot will surface a document you could always open but would never have found, because your question matched its meaning and Search's ranking never put it on page one.
That's the whole oversharing story in one sentence: Copilot doesn't create access; it makes existing access discoverable.
The semantic index, briefly
The semantic index is built automatically for tenants with Copilot licences — there's nothing to turn on. It covers content the user interacts with and content shared broadly, at the user level (their own mail, files, chats) and the tenant level (SharePoint content the user can reach). It updates as content changes, with a lag, and it respects the same crawl rules as Microsoft Search: content that's excluded from search (a library with search excluded, a site with NoCrawl, an item behind a sensitivity label that blocks extraction) is excluded from grounding too.
What it doesn't do: it doesn't index content the user can't see, it doesn't leave the Microsoft 365 boundary, and it isn't a model training set. The semantic index is retrieval infrastructure, and Microsoft's Copilot privacy documentation is explicit that prompts and grounding data aren't used to train foundation models.
Why results differ in practice
| Situation | Search box | Copilot | |---|---|---| | Document uses different words from the query | Often missed | Usually found (semantic match) | | Exact title or file name | Excellent | Fine, but may paraphrase | | Very recent change | Indexed within minutes to hours | Same index, similar lag; semantic index can lag further | | Old, never-opened document in a broadly shared site | Buried on page 4 | Cited if it's the best semantic match | | Content in a chat or meeting transcript | Findable in Teams search | Grounded across Teams, mail, and files at once | | Ambiguous question | Returns a list to browse | Picks an interpretation and answers confidently |
The last row is the important one. Search fails by returning nothing useful; Copilot fails by answering something — possibly from the wrong document — with citations that look authoritative. Users need to click citations.
The controls that shape grounding
Because grounding inherits the search surface, the controls are mostly search and sharing controls:
Fix sharing first. Sites shared with Everyone except external users, libraries with inherited broad permissions, and "anyone with the link" files are the source of nearly every "Copilot showed me something it shouldn't" report. SharePoint Advanced Management's oversharing reports and the site-access reviews exist for this.
Restricted SharePoint Search is the blunt instrument: an allow-list of up to a hundred sites that org-wide search and Copilot may ground on, with everything else invisible except content the user has directly touched. It's a bridge while you clean up, not a destination — it degrades both search and Copilot for everyone.
Restricted Content Discovery is the sharper one: per-site, keep the site out of tenant-wide search and Copilot grounding while leaving direct access alone. This is the right tool for the ten sites you know are over-shared but can't re-permission this quarter. The Restricted Content Discovery guide covers it.
Sensitivity labels with extraction restrictions prevent labelled content from being used in Copilot responses, and labels flow into Copilot outputs. Labels are the durable answer for sensitive content; the search-scoping controls are for sprawl.
Search schema and exclusions — marking a library or site as excluded from search results — also remove it from grounding. That's an old SharePoint control doing a new job.
Web grounding is separate: whether Copilot may also use Bing results is a tenant switch and a per-user toggle. It doesn't affect what Copilot sees in the tenant, only whether it adds public web content.
What this means for search strategy
Organisations that had given up on SharePoint search — never tuned managed properties, never curated result types — often find Copilot works better than search ever did, because semantic retrieval forgives sloppy metadata. That's real, and it's also a trap: the classic search improvements (good titles, populated metadata, verticals for key content types, bookmarks and Q&A in Microsoft Search) still improve Copilot's precision, because Copilot draws on Microsoft Search's ranking too. The two are not alternatives. The ranked list and the grounded answer are two views of the same corpus, and fixing the corpus fixes both.
The practical sequence: run the oversharing reports, label what's sensitive, restrict the few sites you can't fix yet, and keep improving metadata for the content that matters. Then let Copilot find things. It's supposed to.
Further reading
Spot something wrong or want a topic covered? Send it through the contact form.