"It's on SharePoint, I know it's there, and search just won't find it." It's one of the most common tickets a Microsoft 365 admin gets, and it's also one of the most frustrating, because Microsoft Search genuinely looks like it should just work: type a few words, get the file. When it doesn't, the instinct is to assume search itself is broken. In the large majority of cases it isn't broken, it's behaving exactly as designed, and the file simply doesn't meet one of several conditions search quietly requires before it will surface a result.
This guide runs through the real causes, in the order worth checking them, so a missing search result can be diagnosed in a few minutes rather than written off as 'search is unreliable', which is rarely the actual problem.
Start with the obvious: is the person actually looking in the right place?
Before anything technical, it's worth ruling out the simplest explanation. Microsoft Search behaves differently depending on where it's launched from. Search run from within a specific SharePoint site defaults to a scope of that site, while search run from the Microsoft 365 app launcher or Bing at Work searches more broadly across the tenant. A file that lives on a different site to the one someone is searching from can be genuinely missing from a site-scoped search while sitting perfectly findably in an org-wide search, and the fix is nothing more than searching from the right starting point, or widening the scope, not a configuration change.
The ordered diagnostic
Once the obvious scope question is ruled out, work through these in order. Each one is genuinely more likely to be the cause than the next, so checking them in sequence avoids chasing an unlikely explanation while an obvious one goes unchecked.
- 1Check the file was actually saved where it's expected to be, not in a personal OneDrive folder, a local desktop copy, or an email attachment that was never uploaded, since search can only index content that's actually in Microsoft 365
- 2Check who can see the file. Search results are permission-trimmed, meaning search will only ever show a person results for content they already have access to, so a file with restricted or broken permissions genuinely will not appear for someone without access, even though it exists and even though a colleague with access can find it instantly
- 3Check how recently the file was created, uploaded or changed. New and recently modified content isn't available to search the moment it's saved, there's a processing delay before it's crawled and added to the index, and for a file uploaded minutes ago that delay alone explains a failed search
- 4Check the file type and, for scanned documents or images, whether it actually contains searchable text. A scanned PDF or a photographed document with no OCR (optical character recognition) layer has no extractable text for search to index against, search can find it by file name but not by words that only exist visually inside the image
- 5Check whether the search term matches metadata rather than file content. If people are searching by a client name, project code or reference number that only exists in a metadata column and not in the file's name or body text, search needs that column configured to be searchable before it can match on it
- 6Check the site or library itself isn't excluded from search. Sites can be deliberately removed from search results at the admin level, and a library can also be configured to not appear in search, both legitimate settings that occasionally get applied more broadly than intended
- 7As a last step, check tenant-wide search health rather than assuming the fault is specific to one file, since a genuine indexing or search service issue, while rare, does happen and is worth ruling out through the Microsoft 365 admin centre's service health page before spending more time on one document
Why permission trimming exists, briefly
It's worth understanding why this behaviour exists rather than treating it as an inconvenience. Search results being trimmed to what each individual searcher can access is a deliberate security control, not a limitation, it's what stops search from becoming a way to discover the existence and content of files a person was never meant to see. The trade-off is that search failures and permission gaps look identical from the user's seat, which is exactly why the diagnostic above puts the access check early rather than last.
Recently changed or moved content
Content that has just been uploaded, edited or moved to a new location goes through a processing step before it's reflected in search, and that includes files that were moved between libraries or sites, not only brand-new uploads. A file moved yesterday from one library to another can genuinely return a stale or missing result for a short window while the index catches up with its new location. This is usually the explanation when a file 'used to show up in search and now doesn't', after being reorganised as part of a library clean-up.
Content search can't read
Search indexes text. A native Word, Excel or PDF document with a proper text layer is straightforward. A scanned paper document saved as a PDF or image, or a photo of a printed page, has no text layer at all unless OCR has been run over it, so search can only ever match it by its file name, author or other metadata, never by a word that appears only visually on the page. This is one of the more common reasons a document someone knows exists, and can even open and read, never turns up in a text search, and it's worth checking specifically for scanned contracts, forms and paper-originated records rather than assuming every PDF behaves the same way.
A well-indexed library also makes Copilot answers better
Microsoft 365 Copilot answers questions by retrieving from the same search index this guide has been describing, so every cause above that stops a file surfacing in a manual search also stops Copilot from finding and citing that file in an answer. A scanned document with no OCR text, content sitting in a site excluded from search, or a file a user technically shouldn't see, all behave the same way for Copilot as they do for a person typing into the search box. Getting search working reliably for people is largely the same work as getting it working reliably for Copilot.
When to escalate rather than keep checking
If a file has been confirmed to exist in the expected location, the searcher has confirmed access via someone else finding it successfully, the content has been stable (not recently moved or edited) for more than a day or two, and it has genuine extractable text, that's the point to raise it as a support case rather than keep troubleshooting manually, since those checks rule out the common causes and point toward something that needs an administrator looking at the search configuration or index directly.