How Advanced Search Works in SharePoint Online
Advanced search in SharePoint Online is controlled by the search schema: a set of crawled properties that the crawler extracts from your content, and managed properties that decide what goes into the search index and how users can query it. You configure it in the SharePoint admin center under More features, Search, Manage Search Schema, or per site collection under Site settings, Search Schema.
The single most useful thing to understand is this: search only finds what is in the index, and only shows results the user has permission to see. If content is not returning, the cause is almost always that a property is not mapped, not searchable, or the library has not been re-crawled since you changed something.
If you have worked with SharePoint Server, set aside the Search Service Application model, and be wary of guides that still lead with it. A Search Service Application is a farm construct: you create and manage it in Central Administration, under Manage service applications. SharePoint Online has no Central Administration and therefore no SSA to administer. Microsoft runs crawling for you on an automatic schedule, and your control surface is the search schema in the SharePoint admin center plus manual re-indexing.
Crawled Properties and Managed Properties
These two terms cause most of the confusion, so it is worth being precise.
When search crawls an item, everything it discovers, content and metadata, becomes a crawled property. Not all of that is useful, so the schema maintains a list of managed properties, and only content and metadata from managed properties goes into the index.
- Search ships with sensible defaults already mapped. Crawled properties relating to author map to a managed property for author, and so on.
- If you create a managed property, you must map it to a crawled property, or nothing reaches the index.
- After the site, library or list is crawled, users can search the content of the new or changed managed properties.
A single crawled property can map to several managed properties, and several crawled properties can map to one. Where several map to one, the value used is the crawled property highest on the mapping list that has a value.
The four settings that decide behaviour
Each managed property carries settings that determine how it can be used:
| Setting | What it does |
|---|---|
| Searchable | Content is added to the full-text index. A query for "Smith" returns items containing the word and items whose author property contains it. |
| Queryable | Enables property-scoped queries, so users can search author:Smith to match only that property. |
| Retrievable | Allows the value to be returned in results. Disable it to keep a property out of search results. |
| Refinable | Allows use as a refiner on the results page. Classic search only, see below. |
Classic and Modern Search Are Both Running
Before configuring anything, know which experience your users are actually on, because it changes what your settings do.
SharePoint in Microsoft 365 runs both a classic and a modern search experience, and Microsoft Search in SharePoint is the modern one. As a search admin you cannot enable or disable either. Both are on by default, and critically, both use the same search index.
Which one a user gets depends on where they are:
| Experience | Where users get it |
|---|---|
| Classic | Publishing sites, classic team sites, and the Search Center |
| Microsoft Search (modern) | The SharePoint start page, hub sites, communication sites, and modern team sites |
Because both draw on the same index, any change you make to the search schema applies to both experiences. But three schema settings have no effect on Microsoft Search:
- Sortable
- Refinable
- Company name extraction, deprecated since 15 November 2019
This is the single most common source of "I configured a refiner and nothing happened". Microsoft Search does not support building refiners based on metadata or changing the sort order of results. If your users are on a communication site or a modern team site, a refinable managed property will not give them a refiner no matter how correctly it is configured.
Two related differences worth knowing:
- Administration is split. You use the SharePoint admin center to manage classic search, and the Microsoft 365 admin center to manage Microsoft Search.
- Promoted results versus bookmarks. Classic lets admins define promoted results; Microsoft Search uses bookmarks for the same job. If you want the same item to appear at both organisation and site level, you have to create both a tenant bookmark and a promoted result for the sites concerned.
Microsoft Search is also personal: results differ between users searching the same words, based on their activity and trending content, and they update as the user types.
The Managed Property Limitation Everyone Hits
This is the part that catches people out, and it is specific to SharePoint Online.
Custom managed properties you create in SharePoint Online can only be of type Text or Yes/No, and cannot be refinable or sortable. Refinable managed properties cannot be created at all.
The workaround is built in. SharePoint ships a large pool of unused, pre-built managed properties that already have the right characteristics, and you claim one by giving it an alias:
| Type | Available range | Count |
|---|---|---|
| String | RefinableString00 to RefinableString219 | 220 |
| Integer | RefinableInt00 to RefinableInt49 | 50 |
| Date | RefinableDate00 to RefinableDate19 | 20 |
| Decimal | RefinableDecimal00 to RefinableDecimal09 | 10 |
| Double | RefinableDouble00 to RefinableDouble09 | 10 |
So if you create a site column called "NewColors" and want it available as a refiner, you do not create a managed property called NewColors. You take an unused RefinableString00, set its alias to NewColors, and map it to the relevant crawled property.
One caution from Microsoft worth repeating: if you add an alias, make sure no managed property with that name already exists. Aliased properties take precedence during search, and Microsoft 365 experiences that depend on specific properties can break as a result.
Why Your Changes Have Not Taken Effect Yet
Schema changes do not apply retrospectively on their own. Changes to managed properties only take effect after the content is re-crawled, and because your change was made in the schema rather than to the site itself, search does not know to re-crawl.
You have two options, depending on how wide the change was.
To re-index a single document library or list:
- Go to the list or library you want to re-index.
- In the upper right corner, select Settings, then Library Settings or List Settings.
- On the Settings page, under General Settings, choose Advanced settings. If you do not see the Settings page, you may need More library settings or More list settings first.
- Scroll to Reindex Document Library or Reindex List and select the button, then confirm at the warning.
To re-index a whole site:
- On the site, select Settings, then Site settings. If Site settings is not there, choose Site information, then View all site settings.
- Under Search, select Search and offline availability.
- In the Reindex site section, select Reindex site.
- Tick the acknowledgement box and select Reindex site again to confirm.
In both cases the content is picked up and re-indexed during the next scheduled crawl, not immediately. Microsoft's warning is worth taking seriously: re-indexing a site can cause a massive load on the search system, so make all your schema changes first, then re-index once, and prefer the library or list scope over the whole site where you can.
Tenant Level or Site Collection Level
You can change the schema for the whole tenant or for a single site collection. The site collection schema is based on the tenant schema, so the sensible order is tenant first, then site collection for exceptions. Changes made at site collection level apply only there.
Microsoft's recommendation for the built-in refinable properties is to map them at tenant level. It is easier to manage, gives users a consistent experience, and performs better over time.
Scope precedence runs Site Collection, then Tenant, then System, with the lower scope overriding the higher. An overridden property appears greyed out and can only be changed at the scope where it was created.
Things That Quietly Do Not Get Indexed
A few behaviours that explain otherwise baffling "why can't I find this" tickets:
- Numeric data in Excel files is not indexed. The number
123456789is not indexed, but the stringPO123456789is. - Auto-generated managed properties are case-sensitive. If you access one through a REST query with the wrong casing, no value is returned.
- Modifying an auto-generated mapping breaks it. If you map an auto-generated crawled property to a different explicit managed property, the implicit mapping is disrupted, and after a re-index both auto-generated properties are removed.
- Special characters in property names cause query problems. Hyphens, dots and underscores are legal but several act as query operators, a hyphen means negation, so names need quoting. Stick to letters and digits.
Tokenization: When Search Cannot Match What Is Clearly There
If your content contains product codes, part numbers or multilingual metadata, this is usually the culprit.
Search breaks text into tokens before indexing, and it does so according to the detected language of the document. A product identifier like 11.132-84-115#4 in a Chinese datasheet is tokenized as Chinese text; the same identifier in an English datasheet is tokenized as English. When a user searches, their query is tokenized according to the language of the site they are on. If those do not agree, there is no match and no result.
Two settings fix this:
- Language neutral tokenization on the managed property, so the identifier tokenizes the same way regardless of document language. Map the code to a managed property such as
ProductIDand have users queryProductID:"11.132-8". - Finer tokenization, which breaks queries into smaller parts so partial queries like
ProductID:"132-884"can match. It makes no difference to users who type the full identifier.
Search and Archived Content
Search architecture matters more once content starts leaving SharePoint, because an archive that is invisible to search is an archive nobody trusts.
When Squirrel archives inactive SharePoint content to Azure Blob Storage in your own subscription, it leaves a stub in place of the original file. The stub keeps the original filename, metadata and dates, and inherits permissions from the parent library, so the item still appears in the library and remains a normal, indexable SharePoint object. Restoring brings back the original file with its version history intact.
For organisations using Microsoft Copilot, findability has a second dimension: content that Copilot cannot ground against is content it cannot answer from. Nutshell AI generates summaries of archived documents so that archived content stays available to Copilot grounding rather than dropping out of the picture when it is archived.
The wider archiving strategy is in SharePoint archiving: the complete enterprise guide, and the storage side in how to reduce SharePoint Online storage.
Frequently Asked Questions
Is there a Search Service Application in SharePoint Online?
No. The Search Service Application is a SharePoint Server concept. In SharePoint Online, Microsoft manages crawling on an automatic schedule, and administrators work through the search schema in the SharePoint admin center under More features, Search, Manage Search Schema, or per site collection under Site settings, Search Schema.
What is the difference between a crawled property and a managed property?
A crawled property is anything the crawler discovers in an item, content or metadata. A managed property is an entry on the list of things worth putting in the search index. Only content and metadata from managed properties reaches the index, and a managed property returns nothing until it is mapped to a crawled property.
Why can I not create a refinable managed property in SharePoint Online?
Custom managed properties in SharePoint Online can only be of type Text or Yes/No, and cannot be refinable or sortable. Instead, take one of the built-in unused properties such as RefinableString00 or RefinableInt00, give it an alias with the name you want, and map it to your crawled property. Searching for "Refinable" in the schema shows all the usable ones.
Why does my refiner not show up in search results?
Almost always because the users are on a modern site. Refinable and Sortable are schema settings that do not affect the Microsoft Search experience, which does not support building refiners from metadata. Refiners work on publishing sites, classic team sites and the Search Center. Both experiences share the same index, so the rest of your schema work still applies.
Why have my search schema changes not appeared?
Because the content has not been re-crawled. Schema changes only take effect after a re-crawl, and changing the schema does not automatically trigger one. Request re-indexing on the specific library or list through Library settings, Advanced settings, Reindex Document Library.
Why does search not find numbers in my Excel files?
Numeric data in Microsoft Excel files is not indexed. A pure number such as 123456789 will not be found, but a string such as PO123456789 is indexed normally.
Should I change the search schema at tenant or site collection level?
Start at tenant level, then make site collection exceptions if you need them, because the site collection schema is based on the tenant one. Microsoft specifically recommends mapping the built-in refinable properties at tenant level, as it is easier to manage, more consistent for users, and performs better long term.
Does archiving SharePoint content remove it from search?
It depends on the archiving method. Squirrel leaves a stub in the original library that keeps the filename, metadata and dates and inherits the library's permissions, so the item remains a normal indexable SharePoint object rather than disappearing from search.
Related reading
Mark Smith co-founded SmiKar Software in 2015 and has spent the past decade helping organisations solve Microsoft 365 data management challenges. He works with the SmiKar team to build solutions for SharePoint archiving, storage optimisation, governance and compliance, supporting customers from growing businesses through to Fortune 500 enterprises.
More about SmiKar
