Skip to main content

Crawled Properties

Crawled properties are the raw metadata fields the SharePoint search crawler extracts automatically during indexing - every column value, document property, and piece of body text from every list item, file, and page. On their own they are invisible to users; their job is to feed managed properties, the refined fields that power keyword queries, refiners, and custom search experiences. Understanding crawled properties is the first step in fixing or building anything search-related.
Related
KQL, Managed Properties, Search Schema

Common Use Cases

  • Source for custom managed properties: identify the crawled property for a site column, such as ows_DocumentType, and map it to a custom managed property so it becomes searchable and refinable
  • Search schema troubleshooting: when a column is not appearing in refiners, checking the crawled property confirms whether data is being indexed
  • New column discovery: after adding a site column and populating items, the crawled property appears in the schema after the next crawl, confirming it is ready to be mapped
  • Custom search solution development: search architects examine crawled properties to understand available data before designing managed property mappings and KQL queries
  • Refiner and filter enablement: map a column’s crawled property to a RefinableString alias so search results pages and verticals get working refiners
  • Content rollups across sites: confirm the right crawled property feeds the managed properties used by the Highlighted Content web part before building cross-site rollups

Benefits

  • Fully automatic: every column, document property, and system field is discovered and surfaced as a crawled property without manual configuration
  • Comprehensive coverage: crawled properties capture data from SharePoint columns, Office file properties, PDF metadata, and content body text
  • Foundation for the search schema: without crawled properties, there are no managed properties, and without managed properties, there is no structured search experience
  • Useful for diagnostics: when search is not working, the crawled property list is the first place to verify whether the underlying data is being captured at all
  • Reflects actual stored data: crawled properties show raw indexed values, helping verify data is stored and indexed correctly before building search-dependent features
  • Supports all column types: SharePoint, people, date, choice, managed metadata, and calculated columns all generate corresponding crawled properties automatically

Details

  • Feature Category: Search & AI

How It Works

  • Mapping is everything: crawled properties only become useful when mapped to managed properties, the queryable fields that KQL, refiners, and search web parts actually use
  • Automatic managed properties: many site columns get one created for them, so a text column named DocumentType produces DocumentTypeOWSTEXT, searchable but not refinable or sortable
  • Refinable properties unlock filters: mapping a crawled property to a prebuilt reusable property such as RefinableString00, or the RefinableDate, RefinableInt, RefinableDecimal, and RefinableDouble families, makes the column refinable and sortable under a friendly alias
  • Names follow a pattern: crawled property names encode the column’s internal name plus a type prefix, such as ows_DocumentType, ows_q_TEXT_, and ows_taxId_, so knowing the internal column name is half the battle
  • Reindexing completes the job: mapping changes apply only to content crawled after the change, so a reindex request is what makes existing items pick up the new schema
  • Tenant or site scope: the search schema can be managed for the whole tenant or for a single site collection

Limits and Nuances

  • Read-only by design: crawled properties cannot be created, edited, or deleted; the crawler generates them entirely on its own
  • Expect duplicates: the same logical column can produce several crawled properties depending on column type and content type, so map the one that actually carries the data
  • Empty columns are never indexed: a new column has no crawled property until the crawler indexes at least one item with a value in it
  • Only managed properties are queryable: KQL queries and refiners cannot touch crawled properties directly; they are strictly an administrative tool
  • Indexing delays apply: crawled properties can take hours to appear after new columns or content are added, and Microsoft controls the crawl schedule in SharePoint Online
  • Automatic properties have limits: managed properties like DocumentTypeOWSTEXT are searchable but never refinable or sortable; map to a RefinableString alias when you need refiners
  • Schema changes skip existing items: request a reindex of the affected library or site, or the new mapping will appear to do nothing
  • Map at the tenant level where possible: site-level mappings fragment the schema and make troubleshooting much harder

Common Questions About Crawled Properties

What are crawled properties in SharePoint?

Crawled properties are the raw metadata fields the SharePoint search crawler extracts automatically while indexing content – every column value, Office document property, and piece of body text becomes one. They are generated without any configuration and cannot be edited. Their sole purpose is to be mapped to managed properties, which are the fields that search queries, refiners, and search web parts actually consume.

What is the difference between crawled and managed properties?

Crawled properties are raw and automatic – the crawler creates one for every piece of metadata it finds, and they cannot be queried or edited. Managed properties are the curated layer on top: they have attributes like searchable, queryable, refinable, retrievable, and sortable, and they are what KQL queries and refiners use. The mapping between the two lives in the search schema and is fully configurable.

Why is my SharePoint column not showing up in search results?

Work through the chain: first confirm the crawled property exists in the search schema, which requires at least one item to have a value in that column and the crawler to have processed it. Then check it is mapped to a managed property with the right attributes – searchable for keywords, refinable for filters. Finally, reindex the library so existing items are recrawled with the new mapping.

What are RefinableString managed properties used for?

SharePoint Online does not let you create new refinable managed properties from scratch, so Microsoft pre-provisions empty reusable ones – RefinableString00 through 199, plus RefinableDate, RefinableInt, RefinableDecimal, and RefinableDouble families. You map your column’s crawled property to an unused one, set a readable alias, and reindex. The property is then usable as a refiner, a filter in KQL queries, and a sort field.

How long does it take for a crawled property to appear?

It depends on the crawl, which Microsoft schedules in SharePoint Online – new columns and content typically surface within hours, occasionally longer. The column must hold data in at least one indexed item before its crawled property exists at all. After mapping changes, request a reindex from Library settings, Advanced settings, or Site settings, Search and offline availability to speed up the pickup.

Can I create or edit crawled properties myself?

No – crawled properties are generated entirely by the crawler and are read-only. What you control is everything around them: which managed properties they map to, aliases, and the search schema at the tenant or site level. That mapping work is where search projects are won or lost, and it is a core part of the search tuning Greg does when building findable, metadata-driven intranets.