Make SharePoint columns searchable: crawled properties, managed properties, and refiners

How do you make SharePoint columns searchable when they are missing from search, filters, or sorting? Usually, the issue is not with the list or the search web part, but with the SharePoint search schema. A field must first be captured by the search service, recognized as a Crawled Property, and then mapped to a matching Managed Property.

Only the Managed Property determines whether a field can be queried specifically, displayed in search results, used as a refiner, or utilized for sorting. After changes to the search schema, the affected content must be reindexed.

Make SharePoint columns searchable: why the index decides

SharePoint search does not operate directly on the current data of a list or document library. Instead, a search query reads from a separate search index. This index is built by a background process that ingests content and metadata from SharePoint.

The simplified data flow looks like this:

1. A user saves a list item or a document with metadata.
2. The SharePoint crawler detects the new or changed content.
3. The found field values are processed as Crawled Properties.
4. The Crawled Properties are mapped to Managed Properties.
5. The Managed Properties are then available for search queries, result display, filters, and sorting.

A newly created column is therefore not automatically immediately available as a filter property. For SharePoint to recognize it in the search schema, at least one item must contain a valid value in this column. After that, the relevant content must be processed by the search service.

Even a column that functions in the list view is not necessarily already usable in the search index. List views access the list data directly. Search web parts, Microsoft Search, KQL queries, and PnP-Search components instead use the search index.

List filters and search filters are two different mechanisms

A filter in a normal SharePoint list view is executed directly against the list. No Managed Property is required for this. A refiner in a search interface works instead with aggregated values from the search index and requires a Managed Property configured as Refinable.

This explains a common error pattern: A column can be filtered easily in the list, but does not appear in the configuration of a search filter.

Crawled properties and managed properties explained clearly

What is a crawled property?

A Crawled Property is a raw property recognized by the search service. It represents a field value that SharePoint read from a page, a document, or a list item during indexing.

For SharePoint columns, the names often contain the internal column name and begin with, for example:

• ows_
• ows_q_TEXT_
• ows_q_CHCS_
• ows_taxId_

The specific name depends, among other things, on the column type, the internal name, and whether a local column or a site column is used.

A column with the visible name Customer Status might have an internal name like Kundenstatus or Kunden_x0020_status. The associated Crawled Property might have a different name than the visible column label.

Therefore, for finding the correct Crawled Property, the internal name is more important than the display name.

What is a managed property?

A Managed Property is the controlled interface between the search index and a search query. It defines how an indexed value can be used.

Important characteristics of a Managed Property are:

These characteristics fulfill different tasks. A characteristic can be queryable without being available as a refiner. Similarly, a value can be output in the search result even though sorting by it is not possible.

Why the assignment is required

The Crawled Property contains the raw value found by the crawler. The Managed Property defines how this value can be used by search solutions. The assignment between both characteristics is called mapping.

A typical mapping looks like this:

Crawled Property:
ows_q_TEXT_Kundenstatus

Managed Property:
RefinableString12

Alias:
KundenstatusSearch

After successful indexing, a search solution can then access the value via the alias or the name of the Managed Property.

Prerequisites for configuration

Before making changes to the search schema, the following prerequisites must be met:

• The SharePoint column has already been created.
• At least one list item or document contains a valid value.
• The internal name of the column is known.
• The appropriate data type for the managed property has been set.
• Sufficient permissions exist for the search schema.

Changes to the tenant-wide search schema require corresponding administrative rights. Changes to the search schema of a site collection can be made by administrators of that site collection. A configuration at the site collection level applies only within that scope.

Tenant-wide mappings are useful when the same column definition is used across multiple sites and search solutions. Local mappings, in contrast, limit the impact and are suitable for clearly defined solutions.

Determine the internal name of a SharePoint column

The internal name is set when creating a column and is not changed later, even if the visible display name is adjusted.

You can determine the internal name via the user interface as follows:

1. Open the settings for the list or document library.
2. Select the relevant column.
3. Check the browser address for the parameter Field=.

For a URL with the following excerpt:

Field=Kunden_x0020_status

The internal name of the column is Kunden_x0020_status.

This name can then be used to search for a matching crawled property in the search schema. Additionally, search for a unique component if the full name does not immediately yield results.

Find the appropriate crawled property

Open the search schema in the SharePoint Admin Center or in the settings of the relevant site collection. Navigate to the view of crawled properties there.

Search for the internal name of the column. Depending on the field type, several similarly named properties may appear.

Check the following:

• the full name of the crawled property,
• the category, often SharePoint,
• the recognized data type,
• existing mappings to Managed Properties.

If the Crawled Property does not appear, first check whether the column actually contains values. Then, you can request a new indexing of the list or library.

Repeated reindexing without populated test data usually does not resolve the issue. The search service must be able to find a usable field value.

Selecting RefinableString and other managed properties correctly

In SharePoint Online, you cannot create arbitrary new Managed Properties with the Refiner or Sort function enabled. For such scenarios, predefined, unused properties are available.

These include, among others:

• RefinableString00 through RefinableString219
• RefinableInt00 and other Integer properties
• RefinableDecimal00 and other Decimal properties
• RefinableDouble00 and other Double properties
• RefinableDate00 and other Date properties

The Managed Property must match the data type and the intended future use.

SharePoint field: Single line of text

Typical Managed Property: RefinableString

Typical use: Filters, output, queries, and sorting

SharePoint field: Choice field

Typical Managed Property: RefinableString

Typical use: Filtering by predefined categories

SharePoint field: Whole number

Typical Managed Property: RefinableInt

Typical use: Numeric filters and sorting

SharePoint field: Decimal number

Typical Managed Property: RefinableDecimal or RefinableDouble

Typical Use: Numeric ranges and sorting

SharePoint Field: Date and Time

Typical Managed Property: RefinableDate

Typical Use: Date filters and chronological sorting

SharePoint Field: Managed Metadata

Typical Managed Property: Depends on label or term ID

Typical Use: Taxonomy filters and hierarchical navigation

A numeric field should not be hastily mapped to a RefinableString property. A textual representation can yield hits, but leads to incorrect orderings during numeric sorting. For example, the value 100 can appear before 20 because strings are sorted alphabetically instead of numerically.

Use an alias instead of the technical name

A predefined Managed Property like RefinableString12 reveals nothing about its business purpose. Therefore, assign a unique alias, for example:

KundenstatusSearch
ProjektphaseSearch
VertragsartSearch
AblaufdatumSearch

Letters and numbers are most robust for property names and aliases. Special characters can be interpreted as operators in search queries and must then be partially masked separately.

A consistent suffix like Search also helps distinguish between the SharePoint field, its Crawled Property, and the Managed Property in use.

Map a SharePoint column to a managed property

The actual mapping occurs in the search schema:

1. Open the Managed Properties.
2. Find an unused property with a matching data type.
3. Open the property for editing.
4. Assign a clear alias.
5. Under the mappings, select the appropriate Crawled Property.
6. Save the configuration.

A Managed Property is considered free only if it is not yet mapped to a Crawled Property. Already used properties should not be reassigned without review. Otherwise, existing search pages, filters, or queries can be changed unnoticed.

Tenant-wide or local mapping?

The configuration level affects maintainability and scope:

• Tenant-Wide Search Schema: suitable for standardized metadata, central site columns, and reusable search solutions.
• Search schema of the site collection: suitable for local solutions with limited scope.

If the same domain-specific column is needed in multiple sites, it should be provided via a unified site column or a centrally managed content type whenever possible. Local columns created independently can generate different internal names and crawled properties even if they have identical display names.

Perform reindexing correctly after changes

Saving the mapping does not retroactively change the existing search index. The affected content must be processed again.

For a list or document library, this is typically done via:

1. Open list or library settings.
2. Select Advanced settings.
3. Run Reindex list or Reindex document library.

The function does not start immediate synchronous processing. It marks the content for a later crawl. When the values actually appear in the search index is determined by the indexing processes managed by Microsoft.

Changes may therefore become visible with a delay. Triggering reindexing again does not normally accelerate this background process.

Do not reindex an entire website prematurely

If only a single list or library is affected, only that area should be reindexed. A full reindexing of a website creates more load and complicates troubleshooting because significantly more content must be processed again.

Reindexing the entire website is mainly useful when:

• the same column is used in multiple lists or libraries,
• a central content type has been changed,
• multiple search schema mappings have been adjusted simultaneously.

Test managed properties with KQL

After indexing, the property should be tested independently of any later search web part. For this, a targeted query using the Keyword Query Language, or KQL, is suitable.

A simple property query looks like this, for example:

KundenstatusSearch:Aktiv

If the value contains spaces, it should be enclosed in quotation marks:

KundenstatusSearch:"In Bearbeitung"

The query can additionally be restricted to a site or a content type:

Path:"https://contoso.sharepoint.com/sites/projekte"
AND KundenstatusSearch:Aktiv

Or to a specific list path:

Path:"https://contoso.sharepoint.com/sites/projekte/Lists/Kunden"
AND KundenstatusSearch:Aktiv

For text fields, it can also be checked whether a value was indexed at all:

KundenstatusSearch:*

The test should be performed with a known list item whose field value is unambiguous. General terms such as New, Open, or Internal can also appear elsewhere and complicate the evaluation.

A sensible test sequence

1. Check whether the known item is found via its title.
2. Limit the search via Path to the affected list or library.
3. Query the Managed Property with an exact test value.
4. Read the Managed Property as a returned property.
5. Only then configure Refiners or sorting in the Search Web Part.

If the KQL query already yields no hits, the issue most likely still lies in the index, the mapping, or the property name used. Investigate the Web Part configuration only after the Managed Property functions correctly at the search level.

Typical errors and their causes

The crawled property is not displayed

Common causes include:

• The column contains no values yet.
• The list or library has not been indexed since the column was created.
• The search is performed using the display name instead of the internal name.
• The actual name includes a field-type-specific prefix.
• The search is executed in the wrong search schema.

As a fallback, store a unique test value in an item and then re-index only the affected list or library.

The query returns an empty hit list

An empty hit list does not automatically mean the mapping is incorrect. Also check:

• whether the test item must be published or released,
• whether the logged-in user has read permission,
• whether the search is restricted to an incorrect path,
• whether the alias was written exactly,
• whether the queried value matches the indexed format.

SharePoint search is security-cleansed. An item can be correctly indexed yet still not appear if the testing user lacks access to it.

The value is found but does not appear in the results

In this case, the property may be queryable but not retrievable. For output in a search result template or a PnP-Search layout, the Managed Property must be available as Retrievable and be requested as a property to return by the respective search client.

The refiner remains empty

A refiner requires a Managed Property that is usable as at least Queryable and Refinable. After mapping, the content must be indexed again.

Additionally, check whether:

• the Managed Property actually contains values,
• the refiner is configured with the correct property name,
• the current search query actually returns results with this property,
• the filter values are not excluded by another query restriction.

Sorting does not work

For sorting, the Managed Property must be available as Sortable. The data type must also match the domain-specific sorting.

Typical problems arise from:

• numeric values in a string property,
• date values in a text property,
• multi-value fields without unique sorting logic,
• empty values in a large portion of the hits,
• confusing an alias with the technical property name.

Multi-values lead to unexpected filters

Multi-select, person, lookup, and taxonomy fields can contain multiple values or additional technical information in the index. For such fields, check which Crawled Property actually represents the desired value.

For managed metadata, either the visible label or a term ID may be relevant. A filter by label is more readable, while a stable ID can be more robust for renamed terms.

The wrong crawled property was mapped

For more complex column types, multiple Crawled Properties with similar names can exist. One may contain the visible text, another an ID, or an internally formatted representation.

In this case, do not change the mapping multiple times on suspicion. A better approach is a controlled test with a unique field value and a check of the returned Managed Property.

Special considerations for individual SharePoint field types

Choice fields

Choice fields are well-suited for refiners because they typically have a limited and controlled number of values. Different spellings, such as In Bearbeitung and in Bearbeitung, should be avoided, as they may appear as separate filter values depending on how they are processed.

Person fields

Person fields can contain display names, email addresses, claim values, or user IDs. Before mapping, you must determine which value will be searched or filtered later.

A filter by display name is understandable but can become unstable if names change. Email addresses or unique user IDs are more technical and usually more unique.

Lookup fields

Lookup fields can contain both the displayed value and an internal element ID. For a visible search filter, the text value is usually needed. For technical relationships, the ID may be more appropriate.

Managed metadata

Taxonomy fields require special attention because SharePoint can index both term labels and term IDs. For multilingual term sets, you should also check which label is displayed in the respective usage context.

Multi-line text fields

Multi-line text fields can be suitable for full-text search but are rarely good refiners. Free text generates many different values and thus creates confusing filter lists. For structured filters, it is better to use a separate choice, taxonomy, or status column.

Calculated columns

For calculated columns, you must check in which data type the calculated result is indexed. A value displayed as a date in the interface may be processed differently in the search index. For business-critical search logic, an explicitly filled column is often more controllable.

Column formatting with JSON

JSON column formatting changes only the visual representation in the list. It does not change the stored field value or automatically the representation in the search index. For search queries, the actual stored value remains decisive.

Document and maintain the search schema

The predefined Refinable Properties are a limited and shared resource. Without documentation, it is difficult to understand later which property was reserved for which purpose.

A simple documentation should contain at least the following information:

Documentation Field: Business Meaning

Example: Customer Status

Documentation Field: SharePoint Column

Example: Customer Status

Documentation Field: Internal Field Name

Example: Customer Status

Documentation field: Crawled Property

Example: ows_q_TEXT_Kundenstatus

Documentation field: Managed Property

Example: RefinableString12

Documentation field: Alias

Example: KundenstatusSearch

Documentation field: Scope

Example: Tenant

Documentation field: Usage

Example: KQL, Refiners, and result display

Documentation field: Responsible Solution

Example: Central Customer Search

Before changing or removing a mapping, check whether the Managed Property is used in the following components:

• PnP-Search Web parts,
• Microsoft Search configurations,
• SPFx Web parts,
• Power Automate flows with search queries,
• individual REST or Graph-based search solutions,
• result templates and sort configurations.

Overwriting an existing mapping can affect multiple search solutions simultaneously. Therefore, test changes first in a test environment or with an unused Managed Property.

Fallback path for a faulty mapping

If a change has unexpected effects, do not immediately rebuild the entire search configuration. A controlled fallback consists of the following steps:

1. Identify the last changed Managed Property.
2. Remove the new mapping or reset it to the previous Crawled Property.
3. Re-index the affected list or library.
4. Re-test the original KQL query.
5. Only then re-enable refiners and sorts.

Since resetting a mapping also only takes effect after a re-index, document the previous configuration before every change.

Practical example: using project status as a search filter

A common example is a project library where documents should be filtered by project status. In the list view, the status filter works immediately, but on a search page, the corresponding refiner remains empty. The cause is usually that the column is saved but not yet available as a refinable Managed Property.

The path from a list field to a search filter can be planned from a business perspective as follows:

Step: Define status values

Decision: Controlled selection instead of free text

Risk without clarification: Unmanageable filter values due to spelling variations

Step: Check internal field name

Decision: Search for the actual Crawled Property

Risk without clarification: Mapping to the wrong or non-existent field

Step: Select Managed Property

Decision: Reserve a free RefinableString property

Risk without clarification: Double assignment with another search page

Step: Trigger re-indexing

Decision: Affected library instead of entire site

Risk without clarification: Long wait times and difficult troubleshooting

Step: Configure refiner

Decision: Use property in search Web part

Risk without clarification: Empty filter despite existing list data

If the column is later used as a facet in PnP Modern Search, it is directly linked to the setup of PnP Search Filters with Refiners and KQL. A clean search schema is therefore the foundation for a stable search interface.

Quality rules for searchable metadata

• Filter columns should contain controlled, recurring values.
• Free text is better suited for full-text search than for refiners.
• Data type and managed property must align with future sorting or filtering logic.
• Multilingual taxonomies require testing with the languages actually in use.
• Each reserved refinable property should be documented in a shared registry.

These rules reduce technical errors and improve content maintenance quality. The clearer the metadata definitions, the more reliable search filters, result displays, and later analyses become.

How to turn a list column into a truly usable search property

Creating a custom SharePoint column does not automatically make it a usable search property simply because it exists in a list. What matters is the complete chain from stored field value, crawled property, matching managed property, correct mapping, and re-indexing.

For a robust configuration, follow this order:

1. Create the column and populate it with unique test values.
2. Determine the internal field name.
3. Re-index the list or library initially if needed.
4. Identify the appropriate crawled property.
5. Select a free managed property with a suitable data type.
6. Assign a clear alias and save the mapping.
7. Re-index the affected content.
8. Test the property first with a limited KQL query.
9. Then configure result display, refiners, and sorting.
10. Document the mapping centrally.

With this approach, you can clearly distinguish whether an error lies in the list data, the search index, the search schema, or the search interface being used.