Skip to main content

Search Schema

The search schema is the configuration layer behind SharePoint search. It holds the full list of crawled properties discovered during crawls, the managed properties that live in the search index, the mappings between the two, and the attributes that control how each property behaves in queries and results. Administrators can adjust the schema for the whole tenant or override it on a single site collection, which makes it the foundation for custom search experiences, metadata filters, and search verticals across the intranet.
Related
Crawled Properties, KQL, Managed Properties, Search Verticals

Common Use Cases

  • Metadata driven search: expose site columns like Document Type or Region as queryable properties for precise KQL searches
  • Refiners and filters: alias reusable refinable properties so users can narrow results by your own metadata
  • Scoped search verticals: give vertical tabs KQL queries built on schema properties so each shows the right slice of content
  • Title and author control: decide which of several crawled values wins through mapping order on a managed property
  • Identifier friendly search: tune tokenization so product codes and part numbers with special characters match reliably
  • Site specific experiments: override the tenant schema on a single site collection without affecting the rest of the intranet

Benefits

  • One configuration, every experience: search boxes, verticals, filters, and roll up web parts all consume the same schema
  • Sensible defaults: SharePoint ships with crawled properties already mapped to managed properties, so basic search works untouched
  • Automatic column onboarding: new site columns generate crawled and managed properties on their own during crawls
  • Layered control: tenant level settings keep things consistent while site collection overrides allow local flexibility
  • Out of the box: the entire schema is configuration, with no code or third party tools required
  • Metadata investment pays off: clean site columns flow straight through the schema into better search for everyone

Details

  • Feature Category: Search & AI

How It Works

  • Crawl to index pipeline: the crawler extracts crawled properties from items, and only those mapped to managed properties enter the search index
  • Two scopes: the tenant schema applies everywhere, and each site collection schema layers its own changes on top of it
  • Flexible mappings: many crawled properties can feed one managed property, one crawled property can feed several, and mapping order decides which value is used
  • Override precedence: when same named crawled properties exist at multiple scopes, site collection beats tenant, which beats system
  • Recrawl applies changes: schema edits affect content only after it is crawled again, and reindexing can be requested per list or library
  • Configurable attributes: managed properties carry searchable, queryable, retrievable, refinable, and sortable settings, aliases for reusable built-ins, crawled property categories, and tokenization controls for special characters

Limits and Nuances

  • Recrawl required: no schema change is visible in results until affected content is reindexed
  • Custom property limits: new managed properties support only Text and Yes/No and cannot be refinable or sortable
  • Fixed refinable inventory: refiner scenarios reuse the pre created RefinableString, RefinableDate, RefinableInt, RefinableDecimal, and RefinableDouble properties via alias
  • Leave built-ins alone: Microsoft advises against remapping existing built-in managed properties, since Microsoft 365 experiences depend on them
  • Auto generated quirks: properties generated from site columns are case sensitive, and editing them converts them to regular managed properties
  • Security is separate: the schema controls what gets indexed, while permissions always trim what each user sees in results
  • Excel numeric data: plain numbers inside Excel files are not indexed, while alphanumeric strings are

Common Questions About the Search Schema

What is the search schema in SharePoint?

The search schema is the configuration behind SharePoint search. It lists every crawled property the crawler has discovered, every managed property in the search index, the mappings between them, and the attributes such as searchable, queryable, retrievable, refinable, and sortable that govern each managed property. Changing the schema changes what users can find, how they can query it, and how results can be presented.

What is the difference between the tenant schema and the site collection schema?

There is one schema for the whole tenant, managed by SharePoint administrators, and each site collection has its own schema layered on top of it, managed by site collection administrators. Site level changes apply only to that site collection. Microsoft recommends making shared changes, like refinable property mappings, at the tenant level first so the search experience stays consistent everywhere.

How do site columns get into the search schema?

Automatically. When a list or library containing a site column is crawled, SharePoint generates a crawled property, typically prefixed with ows, plus a matching managed property and the mapping between them. These auto generated entries appear in grey in the schema. They are case sensitive, and editing their settings converts them into regular managed properties, so review every setting carefully before changing one.

How long do search schema changes take to show up?

Schema changes only affect content that is crawled after the change. SharePoint Online crawls continuously on its own schedule, but changing the schema does not trigger a recrawl by itself. Requesting reindexing of the affected list or library marks its content for the next crawl. Plan for hours rather than minutes, and make all related schema changes before requesting the reindex.

Can I make my own column a refiner or filter?

Yes, by reusing one of the unused built-in refinable managed properties. New managed properties created in SharePoint Online support only Text and Yes/No and cannot be refinable or sortable, so you alias a property such as RefinableString00 to a friendly name, map it to your column’s crawled property, and reindex. The aliased property can then power filters, sorting, and KQL queries.

Do I need to touch the search schema for a basic intranet?

For everyday search, no. SharePoint indexes content and standard metadata automatically, and most users never notice the schema working behind the scenes. It becomes essential the moment you want metadata driven experiences, such as filtering search by Document Type or scoping verticals with KQL. On LookBook 365 intranets, Greg Zelfond configures the schema as part of search setup, entirely with out of the box tools.