This is Part 2 of our SharePoint search series. Part 1 covers the user-facing search experience — scoping, permissions, and why content sometimes doesn't appear.
Search in SharePoint Online is significantly more configurable than most organisations realise. The out-of-the-box experience works, but understanding the configuration layers beneath it — and knowing when and how to adjust them — is what separates a search experience that frustrates users from one they actually trust.
This post covers the full administrator picture: the search schema, library-level settings, result sources, result types, query rules, KQL, and how everything connects to PnP Modern Search and Microsoft 365 Copilot.
Part 1 — The Search Schema: Crawled Properties and Managed Properties
Everything in SharePoint search begins with the schema. Understanding how the schema works is the foundation for everything else in this post.
How SharePoint Indexes Content
When SharePoint crawls content — documents, list items, pages — it extracts information and stores it as crawled properties. A crawled property is a raw piece of metadata detected during the crawl. The title of a document, the author, a custom column value — all of these become crawled properties with names like ows_Title, ows_Author, or ows_MyCustomColumn.
Crawled properties on their own are not searchable or retrievable in queries. They need to be mapped to managed properties before they can be used in search.
Managed Properties
A managed property is a named, configured search property that queries can use. Managed properties are what you reference in KQL queries, result sources, and PnP Modern Search slot mappings. The managed property Title maps to the crawled property ows_Title. The managed property Author maps to the crawled property ows_Author.
For standard SharePoint columns, the mapping is done automatically. For custom columns — site columns you've created — you need to map the crawled property to a managed property manually.
The RefinableString Convention
SharePoint Online provides a set of pre-created managed properties specifically designed for custom mappings:
RefinableString00throughRefinableString99— for text valuesRefinableDate00throughRefinableDate19— for date valuesRefinableInt00throughRefinableInt49— for numeric valuesRefinableDecimal00throughRefinableDecimal09— for decimal values
These properties are already configured as Queryable, Retrievable, Refinable, and Sortable — meaning they can be used in queries, returned in results, used as filters, and sorted. Mapping your custom crawled properties to these saves you from creating and configuring your own managed properties from scratch.
For example: your MessageStatus column generates a crawled property ows_MessageStatus. You map that crawled property to RefinableString100. Your KQL query can then filter on RefinableString100:"Active".
The Four Managed Property Flags
When configuring a managed property, four flags determine how it can be used:
| Flag | What it means |
|---|---|
| Queryable | Can be used in KQL queries as a filter — PropertyName:value |
| Retrievable | Can be returned in search results and read by templates |
| Refinable | Can be used as a search filter/refiner in the UI |
| Sortable | Results can be sorted by this property |
The RefinableString properties have all four flags set. Custom managed properties you create have none set by default — you need to enable the ones you need.
Aliases
A managed property can have multiple crawled properties mapped to it. This is useful when the same logical piece of information appears in different column types — for example, a Title column might generate different crawled property names depending on whether it's on a list or a document library. Mapping both crawled properties to the same managed property means your query works regardless of which content type returns the result.
When to Reindex
After creating or modifying managed property mappings, the changes don't take effect immediately. SharePoint needs to re-crawl the content to populate the new managed property with values.
- Library-level reindex — the fastest option for a specific library. In the library settings → Advanced settings → Reindex Document Library. Triggers a crawl of that library only on the next scheduled crawl cycle.
- Site collection reindex — in Site Settings → Search and offline availability → Reindex site. Triggers a crawl of the entire site collection. Use this sparingly — it generates significant crawl load and on large sites can take hours.
- List/library column indexing — separate from search indexing. Adding an index to a column (List Settings → Indexed columns) improves filter and view performance on large lists with 5,000+ items. This is a list performance setting, not a search setting, but often confused with search reindexing.
Part 2 — Result Sources, Result Types, and Query Rules
With the schema configured, the next layer is controlling what search returns and how it's presented.
Result Sources
A result source is a saved search configuration — a scope and a query template — that defines a specific pool of content to search against.
SharePoint Online comes with several built-in result sources including:
- Local SharePoint Results — all content in the tenant
- Documents — document libraries only
- Items matching a content type — filtered by content type
- Items matching a tag — filtered by managed metadata
You can create custom result sources to scope search to specific sites, libraries, content types, or any combination of KQL conditions. A result source for "all active policies" might scope to the policies library and filter on RefinableString100:"Active".
Result sources are used in two ways:
- In the search results web part — to scope what a search box returns on a specific page
- In PnP Modern Search — as the data source for a results web part, combined with a custom Handlebars template
SharePoint Search vs Microsoft Search result sources: Result sources configured in the SharePoint Admin Center apply to the classic SharePoint search experience and PnP Modern Search. Microsoft Search (the search bar at the top of Microsoft 365 apps) has its own admin surface in the Microsoft 365 Admin Center with separate configuration for verticals, result types, and promoted results.
Query Rules
Query rules allow you to change what search returns based on specific conditions — without changing the underlying content or schema.
A query rule has three parts:
Condition — when does this rule fire?
- When the query matches a specific keyword or phrase ("staff directory", "IT helpdesk")
- When the query returns results from a specific result source
- When the query matches a specific content type
Action — what happens when the condition is met?
- Promoted result — a specific item appears at the top of results, above the ranked list
- Result block — an additional set of results appears alongside the main results, pulled from a different result source
Example: A query rule that fires when someone searches for "holiday" — condition: query contains "holiday" — action: promote the HR Leave Policy page to the top of results. Anyone searching for holiday-related information sees the policy immediately without having to scan through results.
Query rules are powerful for surfacing the right content for common searches, but they need maintenance. A promoted result that becomes outdated is worse than no promotion at all.
Result Types
Result types control how individual search results are displayed — what card layout, what information is shown, and in what format.
A result type has two parts:
Condition — which results does this type apply to?
- Content type equals "Policy"
- File extension equals "pdf"
- A managed property contains a specific value
Display template — how should matching results be rendered?
- A custom card layout showing specific properties
- A different colour or icon for specific content types
- Additional metadata fields relevant to that content type
In PnP Modern Search, result types connect to Handlebars templates. You define a result type condition (content type = Policy) and a corresponding Handlebars template that renders policy results differently from general document results — perhaps with the review date and owner prominently displayed.
Result types are the configuration layer that makes search feel tailored to your content rather than generic.
Part 3 — KQL, PnP Modern Search, and Copilot
KQL — Keyword Query Language
KQL is the query language that powers SharePoint search. Understanding the basics makes result sources, query rules, and PnP Modern Search significantly more powerful.
Basic syntax
searchterm — full text search
"exact phrase" — exact phrase match
term1 AND term2 — both terms must be present
term1 OR term2 — either term
NOT term — exclude term
term* — wildcard (starts with)Property restrictions — the most useful KQL feature
ContentType:Policy — filter by content type
Author:"Cameron Griffiths" — filter by author
FileExtension:pdf — filter by file type
Path:"https://tenant.sharepoint.com/sites/hr" — scope to a site
RefinableString100:"Active" — filter on a mapped managed property
Modified>=2024-01-01 — date range filterCombining conditions
ContentType:Policy AND RefinableString100:"Active"
ContentType:Policy AND Modified>=2025-01-01 AND NOT Author:"John Smith"The path restriction is particularly useful for scoping PnP Modern Search web parts to specific lists or libraries without creating a separate result source:
{searchTerms} ContentType:Policy Path:"https://yourtenant.sharepoint.com/sites/hr/Shared Documents/Policies"Custom Search Filters and Refiners
Filters (refiners) in the search results UI allow users to narrow results by specific properties — file type, author, date, managed metadata. Configuring useful refiners requires:
- The managed property is marked as Refinable
- The refiner is added to the search results web part configuration
In PnP Modern Search, refiners are configured as a separate Filters web part connected to the Results web part. Each filter maps to a managed property and can be configured as a checkbox list, a date range slider, or a multi-select dropdown.
For a content-type rich intranet, useful refiners typically include:
- Content type (Policy, Procedure, Guideline, News)
- Department
- Topic or subject area (from managed metadata)
- Date modified or review date
- Language (for multilingual environments)
Microsoft Search Configuration
Microsoft Search — the search experience in the Microsoft 365 search bar — has its own admin surface at admin.microsoft.com → Search & intelligence.
- Acronyms — define what acronyms in your organisation mean. When users search for an acronym, an answer card appears with the definition.
- Q&As — question and answer pairs that surface as answer cards for specific searches.
- Verticals — scoped search tabs in the Microsoft Search results page. The default verticals are All, Files, Sites, People. Custom verticals can scope to specific content types or result sources — for example, a Policies vertical that searches only the policies library.
- Floor plans and locations — for organisations that want to show office layouts and room locations in search results.
Microsoft Search configuration is separate from the classic SharePoint search admin and applies to the Microsoft 365 search bar experience across all apps.
PnP Modern Search — When Out of the Box Isn't Enough
PnP Modern Search is a free, open-source set of SharePoint web parts that replace and extend the built-in search web parts. It's the right choice when you need:
- Custom card templates for search results (Handlebars-based)
- Different card layouts for different content types (result types with custom templates)
- Styled filter panels with multilingual support
- Search verticals with independent query configurations
- External template files stored in Site Assets rather than inline in the web part
- Fine-grained slot mapping between managed properties and template variables
PnP Modern Search uses the same underlying SharePoint search index, result sources, and managed properties — it's a presentation and configuration layer, not a separate search engine. The investment in schema configuration pays off in both the standard search experience and PnP Modern Search.
Search, Metadata Quality, and Copilot
The connection between search schema and Microsoft 365 Copilot is direct and significant.
Microsoft 365 Copilot accesses your organisation's content through Microsoft Graph, which uses the same underlying index as SharePoint search. The quality of your metadata — whether key properties are mapped, whether content is consistently tagged — directly affects Copilot's ability to find and reason over the right content.
Good search schema = good Copilot answers. Poor schema = Copilot falling back to full text search and returning imprecise results.
The practical implication: any investment you make in managed property mapping, content type metadata, and search configuration directly improves both the traditional search experience and Copilot's ability to reason over your content. They share the same foundation.
The SharePoint.md context file for Copilot in SharePoint can also describe your content structure — which libraries contain what, what metadata fields are used, what naming conventions apply. This gives Copilot site-level context that helps it construct better queries and interpret results more accurately.
Where to Start
If your organisation's search is underperforming, the highest-impact improvements in order:
- Audit your managed property mappings — are your key metadata columns mapped and queryable?
- Check your content types — is content consistently tagged with the right type?
- Reindex after schema changes — don't wait for the scheduled crawl
- Add refiners for your most common filter needs — content type, department, date
- Set up a Microsoft Search bookmark for your most common searches
- Consider PnP Modern Search if you need custom card layouts or complex filter configurations