How SharePoint search works

The pipeline

Three stages:

1. Crawl. SharePoint Online uses continuous crawling — there is no crawl schedule to manage as there was on-prem. Content and metadata changes are picked up automatically and near-continuously.
2. Index. Crawled text and managed properties land in a unified, tenant-wide index. This index — not the live files — is what queries hit.
3. Query + security trimming. At query time, results are trimmed to the asking user's permissions: the index stores each item's ACL, and the query engine drops anything the user can't open before returning results.

Security trimming is the load-bearing safety net

Search would be a disaster without trimming — one query would return the whole tenant. Trimming means a user only ever sees what they can access. But note what that implies: search enforces access, it doesn't grant or restrict it. If a user has effective access (via a sharing link, an "Everyone except external users" grant, broken inheritance — the permission-model concept), trimming will happily return it. This is the exact mechanism the oversharing runbook is about, because Copilot grounds on this same index under this same trimming — it can surface anything the asker's permissions let search surface.

Why new / just-shared content lags

• Indexing latency. Continuous crawl is fast but not instant — a brand-new file can take minutes (occasionally longer under load) to become findable.
• Permission-change latency. When you tighten or broaden access, the index's stored ACL must catch up. This is the trap: security trimming can act on a slightly stale ACL, so right after a permission change search results may not reflect it for a short window — "I removed their access but they still found it".
• Schema changes need a reindex. New managed properties, or making a column searchable/refinable, don't apply retroactively until the affected content is recrawled — you can force it by requesting a reindex of the list/site.

The failure modes

• "My file isn't searchable." Usually indexing latency, an unindexed column, or content in a location excluded from search (a site set to not appear in search results — NoCrawl).
• Stale ACL after a permission change — see above; the fix is time (reindex), and meanwhile Restricted Content Discovery keeps a site out of Copilot/search regardless (governance module).
• Site excluded deliberately. A site or library can be flagged to not be indexed; content there is invisible to search AND Copilot — sometimes intended, sometimes an accidental findability hole.

What to watch (proofs)

• Site searchability: Site settings → Search and offline availability — is the site allowed to appear in search results, or excluded (NoCrawl)?
• Force a refresh: Library settings → Advanced → "Reindex" — the lever when a schema or permission change hasn't propagated.
• Trimming proof: have two users with different access run the same query — the result sets differ exactly by their permissions; that IS security trimming.
• Copilot alignment: what a user can find in SharePoint search is the ceiling of what Copilot can ground on for them — test sensitive terms as a pilot user.