SharePoint Search Not Working? 20-Symptom Diagnostic Guide

"Search is broken." That is the ticket. It arrives from an executive who cannot find last week's deck, from a compliance officer who cannot locate a policy, from a project manager whose deliverable no longer appears when they search their own file name. The tenant admin runs the same query, gets the correct result, and closes the ticket "cannot reproduce." Six weeks later the pattern repeats. This diagnostic guide is the 20-symptom matrix our team runs against a "search is broken" ticket. It groups symptoms into five root causes, gives the diagnostic step for each, and draws a boundary between what a site owner can fix and what belongs to a Microsoft ticket.

The five root causes

Almost every search issue in modern SharePoint traces to one of five roots.

• Permission trim — the user does not have permission to see the item, and search hides it.
• Crawl freshness — the item exists but has not been indexed yet, or the index is stale.
• Schema drift — a managed property, crawled property, or content type mapping is misconfigured.
• Result-source misconfiguration — a search web part or page is scoped to the wrong result source.
• Query-rule conflict — a query rule at the site, hub, or tenant level is rewriting or promoting results.

When a user says "search is broken," start by classifying the ticket into one of these five before touching a single setting. The diagnostic path below does that classification quickly.

The 20-symptom matrix

Group I is *permission trim* (symptoms 1-4). Group II is *crawl freshness* (5-9). Group III is *schema drift* (10-14). Group IV is *result-source misconfig* (15-17). Group V is *query-rule conflict* (18-20).

Group I: permission trim

| # | Symptom | Diagnostic step | Fix |

|---|---------|----------------|-----|

| 1 | User A finds the file; User B does not, on the same query | Compare access — can User B open the file's URL directly? | Grant User B access via the correct site group |

| 2 | An entire library disappears from search for one user | Check user's site permissions; check library-level unique permissions | Restore inheritance or add the user's group |

| 3 | Guest user cannot find any files despite being invited | Confirm guest sharing is enabled at the tenant AND site level | Enable in tenant admin center (see escalation below) |

| 4 | An admin sees results a delegated support user cannot | Confirm the support user is in an admin role that includes search-trim override | Adjust role assignment |

Two-thirds of "search is broken" tickets that reach the tenant admin turn out to be Group I. The user is not missing files — the user is being trimmed correctly, and no one taught them the rules.

Group II: crawl freshness

| # | Symptom | Diagnostic step | Fix |

|---|---------|----------------|-----|

| 5 | A file uploaded 10 minutes ago is not searchable yet | Wait — modern search indexes typically within minutes but can take up to a few hours under load | No action; document the SLA |

| 6 | A file uploaded 48 hours ago is still not searchable | Confirm the library has search included (not "Exclude from search") | Toggle back to include, then re-index the library |

| 7 | Renaming a file does not update its search title | Verify the file is not on a legal hold that blocks index update | Escalate to Compliance if held; otherwise reindex library |

| 8 | Deleting a file leaves it in search results for days | Confirm the recycle bin was actually emptied vs still holding | Empty recycle bin, wait for reindex |

| 9 | A whole subsite returns zero for known content | Check that the subsite is not orphaned from search — reindex from site settings | Reindex, then verify next-day |

Item 6 is the quiet villain. Someone flipped "Exclude from search" on a library six months ago during a governance drill and no one wrote it down. Every file in that library is invisible to search. Every ticket gets closed as "cannot reproduce" because the tenant admin was searching a different site. Check every library's search inclusion first.

Group III: schema drift

| # | Symptom | Diagnostic step | Fix |

|---|---------|----------------|-----|

| 10 | A managed metadata column does not filter refiners | Confirm the crawled property is mapped to a managed property with "refinable" set | Map to a refinable managed property in tenant search schema |

| 11 | A custom content type does not surface in results | Confirm crawled property for its unique fields is mapped | Map via search schema, run a reindex |

| 12 | Modern search does not show file previews for certain types | Confirm the file type is on the crawlable file types list | Add via CSOM or Microsoft support ticket |

| 13 | Sort by a custom column does not work in search results | Confirm the managed property is "sortable" | Reconfigure managed property, retest |

| 14 | Search returns the wrong title for pages | Check if a custom title field was mapped instead of Title | Adjust mapping order in the search schema |

Schema fixes at the tenant level require patience — after mapping a new crawled-to-managed property, reindex the affected site and expect up to a day for the new mapping to appear in results. The manage search schema documentation is the canonical reference for the property model.

Group IV: result-source misconfiguration

| # | Symptom | Diagnostic step | Fix |

|---|---------|----------------|-----|

| 15 | A department search page returns zero results | Check the result source scoped on the search page or web part | Correct the result-source URL or scope |

| 16 | Results from one site "leak" onto another site's search page | Same — the result source is too broad | Narrow the result-source path template |

| 17 | Federated search (external content) returns nothing | Confirm the connector or Graph connector is running and authorized | Check connector status; escalate if broken |

Modern search pages inherit tenant-wide result sources by default, but custom PnP search web parts can scope more tightly. When a custom page returns zero, the first check is always: which result source is this page pointing to.

Group V: query-rule conflict

| # | Symptom | Diagnostic step | Fix |

|---|---------|----------------|-----|

| 18 | The same query returns different top results on different days | Check for a scheduled or triggered query rule | Adjust or remove the rule |

| 19 | A high-authority hub is promoting outdated content | Query rule at hub level | Update or expire the rule |

| 20 | A "promoted results" pinned answer is stale | Check the promoted results list for the query | Remove or refresh the promoted result |

Query rules and promoted results are helpful when governed, and confusing when not. Every query rule should have an owner, a purpose, and an expiration date. When they do not, they become inherited technical debt.

A worked example: "search finds nothing for 'travel policy'"

The ticket: three executives cannot find the current travel policy. Two others can.

• Step 1 (Group I check): confirm the two who can find it have HR site membership; the three who cannot are in Sales. Yes — permission difference. Not a search bug; the Sales team was never granted read on the HR site's Policies library. Fix: grant Sales the correct HR "read policies" group. Ticket resolved in six minutes.
• If that failed, next would be Group II: verify the file's modified date is >24 hours ago and the library does not exclude search.
• If that failed, Group III: verify Title mapping.
• Only if all four failed would the ticket become tenant-admin escalation.

When to open a Microsoft ticket

Draw the boundary hard, or you will burn cycles on things Microsoft owns.

Site owner and tenant admin can resolve:

• All Group I permission issues.
• Library-level "Exclude from search" toggles.
• Reindex a site or library.
• Result source scope on custom web parts.
• Query rules on their own sites.
• Managed metadata refinement (when they own the term store).
• Managed property mapping (tenant admin only).

Escalate to Microsoft support:

• Search returns errors (correlation ID logged, indexer failure).
• Reindex request has been submitted but no reindex has occurred after 72 hours.
• File type is not being indexed and cannot be added via search schema.
• Federated / Graph connector shows persistent authorization errors.
• Search limits are being hit (see the search limits documentation) and expansion is required.
• Tenant-wide search outage — check the M365 admin center service health first.

A search-schema audit script

Run this quarterly against the tenant to catch schema drift before users file tickets.

```powershell

Connect-PnPOnline -Url "https://-admin.sharepoint.com" -ClientId "" -Interactive

# Export the current managed property configuration

$props = Get-PnPSearchConfiguration -Scope Site -OutputFormat XML

Set-Content -Path ".\search_schema_$(Get-Date -Format yyyyMMdd).xml" -Value $props

# Compare to prior snapshot with Compare-Object on the XML strings

$prior = Get-Content ".\search_schema_prior.xml" -Raw

$current = Get-Content ".\search_schema_$(Get-Date -Format yyyyMMdd).xml" -Raw

if ($prior -ne $current) {

Write-Warning "Search schema has drifted since prior snapshot"

}

```

The XML diff is not pretty, but it catches unauthorized mapping changes fast. Save one snapshot per quarter; a governance auditor can then see what changed and when.

The two-hour rule

Almost every "search is broken" ticket can be diagnosed to one of the five root causes within two hours of structured investigation. Longer than that means either the wrong tier is investigating, or the ticket is a symptom of a larger tenant-level issue (indexer error, service degradation, wholesale schema misconfiguration) that needs a Microsoft support ticket. Do not sit on it past two hours.

If your team is investigating recurring search complaints across multiple sites and does not have the schema-audit workflow set up, our SharePoint support practice runs a search health engagement that identifies drift, tunes the schema, and hands your admins a repeatable diagnostic runbook.

FAQ

Expert help from our SharePoint consultants

Search issues appear simple ("just make it find the file") but the resolution lives in a mesh of permissions, index freshness, schema, result sources, and query rules — and each layer has different owners. Our SharePoint consulting team runs a search health audit that catalogs your current schema, identifies drift, and hands your team a written runbook. Reach out via our contact page and we will scope an engagement.