Documents that will not show up in SharePoint search, and the four reasons why

Somebody uploaded a document, somebody else cannot find it, and the ticket says search is broken. Search is usually not broken. There are four separate reasons a document does not come back in results, and only one of them is an indexing problem.

The order below matters, because the first two are free to check and the last two involve waiting or administrative change. Working from the bottom up is how an afternoon disappears.

Work out which kind of failure this is

One question splits the problem in half: does anybody else get the document back? Ask a site owner to run the same query.

• Nobody can find it. The document is genuinely not in the index, or the container is excluded from search. Read on from the crawl section.
• One person cannot find it, others can. This is not an indexing fault at all. It is permissions, and the sections below on security trimming apply.
• It comes back but with the wrong title or missing from filters. The document is indexed. What is missing is a mapped property, which is the last section.

Search results are trimmed to what you are allowed to see

This is the cause most often misdiagnosed as an index problem, because the symptom is identical: you type a term you know is in a document and get nothing. Search results are security trimmed, so a document you cannot open is a document you cannot find. There is no message explaining the omission, because telling you that a result exists but is hidden would itself leak information.

The test is direct. Get the document's link from whoever can see it and try to open it. If the link fails, the search behaviour is correct and you have a permissions ticket. If the link opens and search still returns nothing for that person, then it is worth looking at the index.

The container may be excluded from search on purpose

Both sites and libraries carry a setting controlling whether their contents appear in results, and both default to appearing. Somebody may have changed either one deliberately, often years earlier for a site holding HR or finance material, and the exclusion is invisible unless you go and look at it.

1. On the site, open Site settings, then Search and offline availability, and check whether the site is allowed to appear in search results.
2. On the library, open Library settings, then Advanced settings, and check the same permission for that library's items.
3. If either is set to exclude, changing it back does not restore results immediately. The content has to be crawled again before it appears.

   This is the one case where requesting a reindex is genuinely the right next action rather than an act of hope.

4. Check whether the document is a draft or a minor version. Where a library requires approval, content awaiting approval is not treated as published and behaves accordingly in results.

Why a new document is not findable straight away

SharePoint Online crawls continuously rather than on a schedule you control, which is better than the old model but has the same consequence for the person waiting: content becomes findable some time after it is saved, not at the moment it is saved. On a busy tenant with a large amount of change, that gap is longer.

The reindex control is where people go next, and it is worth being precise about what it does. It does not index the library. It marks the library so that the next crawl picks up everything in it, which puts it in a queue. Pressing it again does not raise its priority. It adds the same request again, behind work that is already there.

So the correct use of reindex is once, deliberately, after a change that requires it: a permission change that should newly expose content, a corrected setting, a schema change. Using it as a response to impatience is the one action here that measurably slows down the outcome you want.

When the document is indexed but does not behave

A separate class of problem, and the reason a document can be findable by its filename and invisible to every filter on the page. Custom columns in a library are not automatically available to search as something you can query, sort or refine on. They have to be mapped to a managed property, and until they are, the column exists in the library and does not exist to search.

This is the cause behind most of the complaints that a search page's filters do not work, or that a document library's carefully designed metadata is useless once you leave the library. The metadata is fine. Nothing has been mapped.

• Newly created columns need a crawl before they even appear as crawled properties available for mapping.
• Mapping is done in the search schema, either for the whole tenant or for a single site.
• After mapping, the content needs crawling again before the property holds values for existing documents.

Each of those three steps waits on a crawl, which is why metadata work in SharePoint search is measured in days rather than minutes, and why doing it in one deliberate pass is much faster than discovering it piecemeal.

If it is SharePoint Server rather than Online

Most of the above still applies, with one significant addition: on Server you own the crawl. There is a search service application with its own health, its own content sources and its own crawl schedules, and a stalled or failing crawl is a real possibility in a way it is not in the service. If the environment is Server, checking that the crawl is actually running belongs near the top of the list rather than at the bottom.