Helpdesk: "Priya uploaded the Q3 budget workbook to the Finance site two hours ago and search still can't find it — not in This site, not in Everything. Marcus says SharePoint search isn't working for him at all on the Contoso Project site, but Alex finds the same files fine. Jordan's 'This site' search on HR returns nothing while Everything still finds HR docs. Can you just reindex the whole tenant, or rebuild the Search Center?"
Don't reindex the tenant yet. SharePoint Online search "not working" is usually one broken layer in a documented chain, not a missing Search Center: the user can't see the item (security trimming) → the site or library is set not to appear in search → drafts / pending items aren't crawled for readers → ASPX / fine-grained permission indexing hid pages → "This site" is pointed at the wrong result source while Everything still works → crawl hasn't picked up a brand-new or schema-changed library yet. Microsoft's missing-results, searchability, reindex, group-owner, and large-SharePoint-group articles are the sources for that chain — not a tip that says "turn search off and on."
If the real problem is that guests can't open shared links, start with SharePoint External Sharing Not Working. If the file is gone (deleted / recycle bin), use Restore a Deleted SharePoint Site, OneDrive, or File. If OneDrive desktop sync paths are wrong, that's Intune OneDrive Known Folder Move Not Working, not the search index. This post covers "the file is there, but search won't return it" — for one user, for a site, or for a whole library.
TL;DR
- Search results are always security trimmed. Microsoft: users only see content they have permission to see. Search settings decide what enters the index; permissions decide who sees indexed hits. If Marcus can't open the file URL while Alex can, search is doing its job.
- Site and library can each opt out of search. Allow this site to appear in Search results and Allow items from this document library to appear in search results? must both be Yes (defaults are Yes). A site set to No makes library-level settings irrelevant.
- Draft / pending items often never crawl for readers. With content approval or major/minor versioning and restrictive Draft Item Security, drafts stay invisible to general readers and to crawl. Approve / publish, or set Draft Item Security to Any user who can read items only if policy allows.
- "This site" empty, Everything works → check result sources. Microsoft's "doesn't return search results" article: set Local SharePoint Results as Default at site collection and site level. Custom / Bing result sources break site-scoped search without touching Enterprise/Everything search.
- Reindex queues the next crawl — it is not instant. After schema or visibility changes, use Reindex site / Reindex library; content is picked up on the next scheduled crawl. Hedge: Microsoft documents continuous crawl with no admin-controlled full-crawl SLA; wait measured in hours (commonly up to about a day for catch-up), not minutes, before declaring failure.
- Two Microsoft-specific permission traps: (1) M365 group owner who is not a member can't search group content; (2) a SharePoint group over 2,000 users used ACL-side can hide that resource from search — nest a Microsoft 365 security group instead.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Scope (Everything / This site / library Find a file), who fails, new vs all content, Service Health checked | "Search broken" with no scope or comparison user |
| 2. User can open the item | Direct URL works for the complaining user | Search empty for Marcus; Alex opens the same link |
| 3. Site allowed in search | Search and offline availability = Yes | Whole site missing from Everything and This site |
| 4. Library/list allowed | Advanced settings allow items in search = Yes | One library missing; other libraries on the site work |
| 5. Not stuck as draft/pending | Published/approved major version; draft security understood | Author sees file in library UI; readers + search don't |
| 6. ASPX / srchvis sane | Fine-grained sites not hiding all Web Parts unintentionally | Pages missing; documents OK (or opposite) |
| 7. This site result source | Local SharePoint Results is Default | This site / Find a file empty; Everything works |
| 8. Crawl / reindex waited | Change queued; enough wait for next crawl | Brand-new upload "never indexed" after 20 minutes |
Step 1: Capture the exact symptom (read-only)
Write four facts on the ticket before touching Reindex:
| Fact | Why it matters |
|---|---|
| Scope | Everything (Microsoft Search / tenant) vs This site vs library Find a file |
| Who | One user, one department, or everyone including SharePoint admins |
| What | One new file, one library, one site, or all SharePoint/OneDrive |
| When | Never worked vs worked yesterday vs "uploaded an hour ago" |
Then compare:
- Can the failing user open the item URL in a private window while signed in as themselves?
- Does a second licensed user with known access get the hit?
- Does Everything find it when This site does not (or the reverse)?
- Check Microsoft 365 Service Health for SharePoint / Microsoft Search incidents before you burn an afternoon on site settings.
| Pattern | Likely layer |
|---|---|
| One user fails; peers succeed; opener URL fails for them | Permissions / group membership (Step 2) |
| Everyone fails for one site or library; URLs work | Site or library search visibility (Steps 3–4) |
| Author sees it; readers don't; search empty for readers | Draft / approval (Step 5) |
| This site / Find a file empty; Everything works | Result sources (Step 7) |
| Brand-new file only; older files on same library search fine | Crawl timing (Step 8) |
| Tenant-wide empty including admin | Service Health / widespread incident first |
Step 2: Security trimming and "I should see this" (read-only)
Microsoft's searchable-content guidance is explicit: search results are always security trimmed. The index can contain the item; the query still filters to what the signed-in user may open.
| Check | How |
|---|---|
| Direct open | Paste the file or page URL while signed in as the ticket user |
| Unique permissions | Library → Manage access / Advanced permissions; look for broken inheritance on the folder or file |
| SharePoint vs Entra group | Confirm the ACE is the group you think it is (SharePoint group vs Microsoft 365 / security group) |
| M365 group owner ≠ member | Microsoft: owners who are not members fail to get group content in Microsoft 365 search, Search Center, customized web parts, and CSOM/REST search APIs |
Owner-not-member (documented): When an admin creates a Microsoft 365 group from some admin-center dialogues, the owner is not always added as a member. Outlook/SharePoint-created groups usually add the creator as a member. Fix: add the owner as a member (Microsoft's resolution). Ownership alone does not satisfy search security trimming.
SharePoint group > 2,000 users (documented): If a SharePoint group used on the resource's permissions has more than 2,000 users, Microsoft says search results for that resource aren't available. Mitigation: create a Microsoft 365 security group, add that security group to the SharePoint group, and put users in the security group — don't keep growing the SharePoint group with individuals.
Do not "fix search" by granting Everyone or Everyone except external users on a sensitive library. That is a permissions change with blast radius — see SharePoint Everyone Except External Users Not Working for how that claim actually behaves.
Step 3: Allow this site to appear in Search results (read-only, then one change)
Path (site owner / site collection admin):
- Site → Settings → Site information → View all site settings (or Site settings).
- Under Search, open Search and offline availability.
- Allow this site to appear in Search results → Yes.
Microsoft: after Yes, the site is indexed during the next scheduled crawl. Same page exposes Reindex site (Step 8).
Also verify the classic visibility page Microsoft calls out:
https://<tenant>.sharepoint.com/sites/<site>/_layouts/15/srchvis.aspx
(or /_layouts/srchvis.aspx depending on the doc path) and confirm the site is allowed to appear in search results.
| Setting | Effect |
|---|---|
| Site = Yes (default) | Site content can enter the index (still trimmed per user) |
| Site = No | Site content stays out; list/library/column search settings on that site don't help |
Site owners need Manage Permissions (included in the site Owners group) to change this.
Step 4: Allow library / list items in search results (read-only, then one change)
For the library that "never shows up":
- Library → Settings → Library settings → More library settings if needed → Advanced settings.
- Allow items from this document library to appear in search results? → Yes.
- Optional: Reindex Document Library on the same Advanced settings page after you change it (Step 8).
| Site setting | Library setting | Result |
|---|---|---|
| Yes | Yes | Normal (defaults) |
| Yes | No | That library omitted; other libraries on the site still searchable |
| No | Yes or No | Whole site omitted; library toggle is moot |
Same pattern exists for lists (Allow items from this list…).
Excluded columns: On publishing-enabled classic sites, Searchable columns (or /_layouts/15/NoCrawlSettings.aspx) can exclude column values from the index. That rarely explains "title search finds nothing," but it does explain "we search on a custom metadata field and get zero hits" after someone excluded that column.
Step 5: Drafts, pending approval, and unpublished pages (read-only)
Microsoft's missing-results article tells you to verify draft items are crawled. Practical triage:
| Library setting | What readers + search usually see |
|---|---|
| No content approval; major versions only | Checked-in current version |
| Major + minor (draft) versions; restrictive draft security | Readers see last major; drafts stay with author/approvers |
| Require content approval = Yes; draft security = authors + approvers | Pending items hidden from general readers and typically not useful in search for those readers |
| Draft Item Security = Any user who can read items | Readers can see drafts; crawl can see them too (policy trade-off) |
Checks:
- Library → Versioning settings → content approval + Who should see draft items.
- Is the page Published / item Approved, or still Draft / Pending?
- Can a reader open it in the library UI without being the author?
If the business needs drafts hidden, don't loosen Draft Item Security just to make search pretty — publish/approve instead. If drafts must be findable for all readers, loosening draft security is a deliberate content-exposure change.
Step 6: ASPX pages and fine-grained permissions (read-only)
On Search and offline availability, Indexing ASPX Page Content offers:
| Option | Meaning (per Microsoft) |
|---|---|
| Do not index Web Parts if this site contains fine-grained permissions (common default behavior) | If ASPX permissions differ / fine-grained perms exist, ASPX/Web Part content on the site may be omitted from search so restricted Web Part data isn't leaked in snippets |
| Always index all Web Parts on this site | Index ASPX content even when fine-grained permissions exist (users still can't open docs they lack rights to) |
| Never index any Web Parts on this site | Hide all ASPX content from search |
Microsoft's missing-results note: if a subsite doesn't inherit permissions, .aspx pages may not appear until you set Always index all Web Parts on this site (and/or restore inheritance). Use this when pages are missing but documents in libraries are fine — or when someone flipped Never index during a lockdown and forgot.
Step 7: This site / Find a file empty, Everything works (result sources)
Microsoft article SharePoint Online doesn't return search results: site-scoped search uses the site collection and site result sources. If the default isn't Local SharePoint Results (for example a custom or Bing result source), you get empty results, wrong sources (tags-only / Internet), or "Sorry, something went wrong" on This site / library Find a file — while Everything (Enterprise Search) still works.
Site collection:
- Site settings → Site Collection Administration → Search Result Sources.
- Confirm Local SharePoint Results has the Default check mark.
- If not: drop-down → Set as Default.
Subsite:
- Subsite Site settings → Search → Result Sources.
- Same Default check for Local SharePoint Results.
| Scope | Broken default result source? |
|---|---|
| This site / Find a file | Yes — fix Local SharePoint Results |
| Everything / Microsoft Search box (tenant) | Usually unaffected by that site-level misconfig |
Step 8: Crawl timing and Reindex (change carefully)
SharePoint Online crawls on a continuous / scheduled model. Admins request reindex; they do not run an on-prem-style "full crawl now" with a progress bar.
When Microsoft says to reindex:
- After managed property / crawled→managed mapping changes in the search schema (crawler won't notice schema-only edits otherwise).
- After you flip site/library visibility and want the change picked up on the next crawl.
- When a specific library looks stale compared with peers.
Reindex a site:
- Site settings → Search → Search and offline availability.
- Reindex site → acknowledge the warning → confirm.
- Content is reindexed during the next scheduled crawl.
Reindex a library or list:
- Library/List settings → Advanced settings → Reindex Document Library / Reindex List → confirm.
Microsoft caution: reindexing a site can put massive load on search — don't reindex unless you need all items reindexed (prefer library-level when the blast radius is one library).
Timing hedge (important for tickets): Microsoft does not publish a single guaranteed "your file is searchable in N minutes" SLA for SharePoint Online. Continuous crawl means some items appear quickly and large libraries or migrations can take many hours (community and Q&A guidance often cites waiting on the order of up to ~24 hours after a reindex request before escalating). Treat "uploaded 30 minutes ago" as too early to declare the index broken if older content on the same library searches fine.
Optional admin read-only: SharePoint admin center → More features → Search → Open (classic search admin) for schema, result removal, and related tools. Prefer documented UI over undocumented "force crawl" scripts.
PowerShell is optional for inventory (SharePoint Online Management Shell). Examples below were not executed in this environment (no pwsh here) — verify against your module version:
# Connect-SPOService -Url 'https://contoso-admin.sharepoint.com'
Get-SPOSite -Identity 'https://contoso.sharepoint.com/sites/finance' |
Select-Object Url, Title, LockState, SharingCapability
# Mentions of search visibility are primarily site UI (Search and offline availability).
# Prefer the UI toggles in Steps 3–4 over inventing undocumented Set-SPOSite switches.
For a one-item "hide from search right now" emergency (canceled invite PDF still in results), SharePoint admin center → More features → Search → Remove Search Results: paste full URLs (no wildcards), Remove Now. Microsoft: temporary — items return after the next crawl unless you delete them or change permissions.
Step 9: Change one thing, then retest
Pick the single highest-confidence fix from the table below. Retest with:
- The original failing user (private window).
- A control user who should have access.
- Both This site and Everything scopes.
- The direct item URL (proves permissions independently of search).
| Finding | Prefer | Avoid |
|---|---|---|
| User can't open the URL | Fix permissions / membership | Reindex |
| M365 group owner not member | Add owner as member | Granting tenant-wide search admin rights |
| SharePoint group > 2,000 on the ACL | Nest a Microsoft 365 security group | Adding more individuals to the SharePoint group |
| Site Allow appear = No | Set Yes; wait for next crawl; reindex site if needed | Rebuilding Search Center |
| Library Allow items = No | Set Yes; reindex library | Tenant-wide reindex |
| Draft / Pending only | Publish/approve (or deliberate draft-security change) | Excluding the library from search |
| This site empty; Everything OK | Set Local SharePoint Results Default | Changing org-wide Microsoft Search verticals first |
| Schema / managed property change | Reindex affected site or library; wait | Assuming UI change is live in the index immediately |
| Sensitive URL must vanish now | Remove Search Results (temporary) + delete or lock down perms | Hoping reindex alone removes it forever |
| Brand-new file; peers search fine | Wait for crawl; reindex library only if still missing after a long wait | Declaring "search down" after 20 minutes |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Mis-set search visibility | Flip the site or library toggle documented above | Creating a second Search Center "because search is broken" |
| Wrong result source on This site | Local SharePoint Results as Default | Deleting custom result sources you don't own without change control |
| Owner can't search group files | Membership fix | Disabling security trimming (you can't, and shouldn't try) |
| Need drafts findable for all readers | Draft Item Security = any reader (policy-approved) | Publishing every draft to major versions without review |
| Schema mapping changed | Reindex site/library per Learn | Nightly tenant-wide reindex jobs |
| File must leave results today | Remove Search Results + real remediations | Only Remove Search Results with no follow-up |
FAQ
Why is SharePoint search not working?
In order of how often helpdesk sees it: the user lacks permission (security trimming); the site or library is set not to appear in search; the item is still draft/pending under restrictive draft security; "This site" points at a non-default result source; or the crawl hasn't indexed a new change yet. Read open-URL access and Search and offline availability before you reindex.
SharePoint search not working for one user — what next?
Have them open the item URL. If that fails, fix access (unique permissions, group membership, owner-not-member). If the URL works but search fails only for them, compare scopes, try a private window, and check whether a large SharePoint group (>2,000) or delayed membership expansion is in play. Peers succeeding is your control sample.
Why does This site search return nothing but Everything works?
Follow Microsoft's result-sources article: set Local SharePoint Results as Default at the site collection and, if needed, the subsite. Custom or Bing result sources commonly break site-scoped search only.
How long after upload or Reindex until search works?
Microsoft documents that content is picked up on the crawl schedule / next scheduled crawl after a reindex request — not instantly. There is no single public minute-level SLA. If older files in the same library search fine, wait for continuous crawl (often measured in hours, sometimes approaching a day for catch-up) before escalating.
Does reindexing delete or rebuild the Search Center?
No. Reindex site / Reindex library marks content to be crawled again. Remove Search Results is a separate, temporary admin tool for specific URLs. Neither replaces fixing visibility, permissions, or draft state.
Related posts
- SharePoint External Sharing Not Working (guests and sharing links — different stack from search visibility)
- SharePoint Everyone Except External Users Not Working (EEEU claim / People Picker — don't use it as a search "fix")
- Restore a Deleted SharePoint Site, OneDrive, or File (when "search can't find it" means it's in the recycle bin)
- Intune OneDrive Known Folder Move Not Working (desktop sync / KFM — not the SharePoint search index)
- An Offboarding Checklist for M365 + Intune Admins (access removal that correctly disappears from search after permissions change)
Free checklist
Search tickets often show up the same week someone tightens sharing or rolls Conditional Access for SharePoint/OneDrive. Before the next "lock down external access" change locks the wrong people out of results and sign-in, keep break-glass, pilot groups, and report-only review on one page with the free Conditional Access pre-enforcement checklist:
If you want the Intune and Microsoft 365 admin runway (assignment, compliance, and day-2 ops checklists) in one pack for the next wave of "make SharePoint and devices match policy" work, the Intune & M365 Admin Starter Pack is here: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=sharepoint-search-not-working
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 are primarily read-only (Service Health, open URL, site/library search settings, versioning, result sources, srchvis). Reindex site/library, flipping Allow appear / Allow items, Draft Item Security, ASPX indexing options, result-source Default, Remove Search Results, and ACL/membership changes are deliberate changes. Make one change, retest with the failing user and a control user on This site and Everything, and check current Microsoft Learn for portal labels. PowerShell samples were not executed here.
Top comments (0)