Why Copilot can't find your SharePoint files (and the five-minute fix for each cause)

Copilot is not broken. It is doing exactly what you asked, against exactly the SharePoint you gave it. The problem is that your SharePoint is unclear, and an unclear SharePoint produces unclear answers.

I have done this conversation in client tenants every week for the last eighteen months. The reframe matters because it changes what you fix. Stop tuning prompts. Stop asking Microsoft for a better model. Look at the five things below. One of them is almost certainly the cause.

The pattern: "Copilot is wrong" almost always means "SharePoint is unclear"

The diagnostic conversation goes like this. Someone asks Copilot for the latest parental leave policy. It quotes a draft from 2022. They forward me the screenshot and ask whether Copilot is hallucinating. It is not. There is a draft from 2022 in their tenant, sitting in a library with no Document Status column and no version control, and Copilot found it because it was the highest-text-match result.

Copilot reads what is in your SharePoint and ranks it by signals it can see. If you give it a clean, well-tagged library with one source of truth per topic, it answers correctly. If you give it five copies of the same policy across three sites with no metadata, it picks one and you get whichever version it picked.

Below are the five most common causes I see. Each comes with a five-minute fix you can do today and a deeper systemic fix for later.

Cause 1: The document doesn't have the metadata Copilot needs to find it

What it looks like: Copilot returns "I couldn't find that information" or gives a generic answer when the document clearly exists in the tenant.

Why it happens: Copilot's retrieval is heavily weighted by metadata signals. A document with no Document Status, no Owner, and no Document Type lives in the index as text-only. The model can find it on a strong text match, but it deprioritises documents with thin metadata in favour of documents that are clearly tagged. If everything in your library is thin, the cleanest-looking document wins, and that is often not the one the user wants.

The five-minute fix: Open the library, tag the specific document the user asked about. Add Document Status (Approved), Document Type (Policy or whatever fits), and Owner. Re-run the same Copilot query in five minutes. The answer should be different.

The systemic fix: Add the five Copilot-ready columns to the library and bulk-tag the top fifty most-viewed documents. Set library defaults so new documents are tagged on creation.

Cause 2: Permissions aren't what you think they are

What it looks like: Copilot says "I couldn't find that information" or returns nothing, but you can clearly see the document when you go look in SharePoint directly.

Why it happens: Copilot only surfaces content the asking user has permission to read. If the user has access to the site but not to the specific library or folder where the document lives, Copilot will not return it. The most common cause is that someone broke permission inheritance on a library or folder years ago and forgot. The user appears to "have access to SharePoint" because they can hit the site, but the document is sitting in a sub-section they cannot read.

The five-minute fix: Go to the library, open Library Settings, and check "Permissions for this document library". If it shows "This library has unique permissions", you have your answer. Compare the permission list to the site permissions and identify who is missing. Either grant the missing access or move the document to a library with inherited permissions.

The systemic fix: Audit your tenant for libraries with unique permissions and consolidate where possible. The deeper version is in SharePoint permissions and Copilot oversharing. Start with the libraries that get the most Copilot queries.

Cause 3: There are two versions of the document and Copilot can't tell which is real

What it looks like: Copilot quotes content that contradicts the current published version. Or it cites two different documents in the same answer with conflicting information.

Why it happens: Most tenants have shadow copies. The original document lives in the Policies library. A copy got dropped into a project site three years ago when someone needed it for a one-off. Both are still there. Both are indexed. Both are valid candidates for retrieval. Copilot picks the one that matches the query text best, which is often whichever version uses the user's exact wording.

The five-minute fix: Search the tenant for the document name. SharePoint Search will surface the duplicates. Pick one as the source of truth. On the others, either delete them, mark them with Document Status of Archived, or move them to a clearly-labelled archive library.

The systemic fix: Designate canonical libraries for content that ships organisation-wide (HR policies, finance procedures, IT standards). Anything that lives outside the canonical library should be a link to the canonical version, not a copy.

Cause 4: The library uses folders, and Copilot reads metadata

What it looks like: Copilot answers correctly for documents at the top level of a library but misses documents that live three folders deep.

Why it happens: Folders are metadata that lives outside the document. A document in /Library/Policies/HR/Active/parental-leave-policy.docx has the words "Policies" and "HR" and "Active" only in its folder path. Copilot reads the document's content and metadata columns. The folder path is a weaker signal than a properly tagged column. The deeper the folders, the weaker the signal.

The five-minute fix: For the specific document the user asked about, add a Document Type column and a Department column directly on the file. The information that was implicit in the folder path becomes explicit metadata.

The systemic fix: Flatten the library. Add a Document Type column, tag every document, then delete the folder structure. Use views and filters to give humans the visual sense of grouping without the folders. The full pattern is in how to set up a SharePoint document library.

Cause 5: The document hasn't been re-indexed since you fixed it

What it looks like: You made changes to a document or its metadata, ran a Copilot query, and got the old answer.

Why it happens: The semantic index is not instant. When you change a document or its metadata, it takes time to reflect in Copilot's retrieval. For most changes, the lag is minutes to a few hours. For permission changes or large bulk updates, it can be longer. If you tested Copilot immediately after a fix and saw no change, this is usually why.

The five-minute fix: Wait. Ten to fifteen minutes is usually enough for metadata changes to propagate. For permission changes, give it an hour. Then re-test.

The systemic fix: When you do bulk metadata or permission changes, plan a verification window the next day rather than the same hour. The index needs time. The Microsoft Learn page on semantic indexing for Copilot covers the data flow if you want to dig deeper into the mechanics.

The 30-minute audit you can run today

If Copilot is consistently off in one library, run this audit. It identifies which of the five causes is at play in roughly thirty minutes.

1. Pick three real questions a user has asked Copilot about content in this library. Real ones, not tests. The ones where the answer was wrong.
2. For each question, find the document the user expected Copilot to cite. Open it. Note the metadata: does it have Document Status, Owner, Document Type, Department? If most are blank, you have Cause 1.
3. Check the document's permissions. Is it in a library with unique permissions, or with inherited permissions? Does the user who asked the question have access to the library? If the user does not have access, you have Cause 2.
4. Search the tenant for the document title. Are there other copies in other sites? If yes, you have Cause 3.
5. Look at where the document lives in the library. Top level or three folders deep? If folders, you have Cause 4.
6. Check when the document or its metadata was last modified. If it was within the last hour, the index may not have caught up. Wait fifteen minutes and re-test. If the issue persists, you have one of the first four causes, not Cause 5.

Most libraries have more than one cause running at the same time. The audit tells you which ones, in priority order.

When to call it: signs your Copilot problems are bigger than housekeeping

Sometimes the issue is not housekeeping. Three patterns I look for that suggest a deeper problem.

The library has more than fifty thousand items. SharePoint has indexing constraints above this size that affect Copilot retrieval beyond what column tagging can fix. The right answer is usually to split the library, not to tag harder.

Permissions are inconsistent across more than half the libraries in a site. This is a structural problem that no amount of single-library cleanup will solve. Deal with the site permissions before the library content.

Users report that Copilot answers correctly today but wrong tomorrow with the same query. This usually points to content drift, where someone is uploading new documents (often duplicates) faster than the existing ones can be tagged. Treat the upload pipeline before treating the library.

If any of these match, the work is bigger than this article. The full sequence is in how to prepare SharePoint for Microsoft Copilot.

Frequently asked questions

Why does Copilot return wrong documents?

Almost always because either the right document is not the strongest match (thin metadata, no Document Status), or there are duplicates and Copilot picked the wrong one. Less often, permissions or folder structure are hiding the right document from retrieval. Run the thirty-minute audit above to identify which.

Why does Copilot quote outdated content?

Two common causes. First, the old version is still in the library because nobody marked it as Archived or deleted it. Second, you have minor versions enabled and the index is reading draft versions. The fix for the first is a Document Status column. The fix for the second is to disable minor versions in Library Settings.

Why does Copilot say 'I don't know' when the document exists?

Either the asking user does not have permission to read the document (the most common cause), or the document is sitting in a library or folder with thin metadata and Copilot deprioritised it in favour of higher-confidence matches. Check permissions first, then metadata.

How long does it take for SharePoint to re-index a fixed document?

For metadata changes, usually ten to thirty minutes. For permission changes, up to an hour. For large bulk updates across many documents, several hours. Plan verification testing the day after a bulk update, not the same hour.

Does Copilot read draft versions?

Only if you have minor versions enabled on the library. By default, the semantic index reads the latest published version. If minor versions are turned on, drafts can surface in retrieval, which is the cause of most "Copilot quoted a draft" complaints. Disable minor versions unless you have a publishing workflow that really needs them.

How does Copilot decide which document to cite?

A combination of text match, metadata signals, recency, and the user's permissions. Documents with strong metadata (Document Status, Owner, Type) and recent dates score higher. Documents in libraries with broad permissions also score higher because they are seen as more authoritative. The exact ranking is opaque, but the inputs are knowable.

Can I see what Copilot can and can't access?

Copilot's responses include the citations it used, which tells you what it could find for a specific query. There is no tenant-level dashboard that shows "everything Copilot can see for user X", but a citation review across a few representative queries gives you a good practical picture. SharePoint Search is a useful proxy: anything a user can find via search, Copilot can ground in.

What happens if a document is in two libraries?

Both copies are indexed. Both are valid candidates for retrieval. Copilot picks whichever scores higher on the query, which depends on text match, metadata, and library context. The result is unpredictable from the user's perspective, which is why duplicate management is a foundational fix.

Does Copilot use the file name or the metadata?

Both, plus the document content itself. The file name carries weight, especially if it is descriptive. Metadata columns provide context and filtering signals. The document content is the primary text source for the answer. A good filename, good metadata, and clear content together produce the best retrieval. Any one of those weak hurts accuracy.

How do I test Copilot retrieval without rebuilding everything?

Pick three real questions users have asked. Note the current answer. Make one targeted change (add Document Status to the right document, archive a duplicate, fix a permission). Wait fifteen minutes. Re-run the same query. Compare. The before-and-after pattern is a fast feedback loop and you do not need to fix the whole tenant to see whether your fixes are working.