Decoding the SharePoint Search Schema: A Guide to Crawled Property Prefixes

If you have ever peered into the Search Schema in SharePoint Online, you’ve likely seen a confusing list of crawled properties that all seem to point to the same column. For a single field like “Document Type” or “Summary of Document,” you might see SummaryofDocument, ows_SummaryofDocument, and ows_r_MTXT_SummaryofDocument.

Choosing the wrong property for your refinable managed properties can lead to broken search experiences or unpredictable data. This guide breaks down exactly what these prefixes mean, where they come from, and which one you should “always” map based on SharePoint’s extraction architecture.

The Multi-Layered Extraction Process

SharePoint’s search engine is exhaustive. When it crawls an item, it extracts metadata from multiple sources to ensure maximum compatibility:

• The File Header: It pulls internal properties directly from the Office document or PDF headers, such as the “Title” field in Word.
• The List Level: It captures columns created locally on a specific list or library.
• The Site Level: It identifies standardized Site Columns and Content Types.

Prefix Reference Map: Where Properties Come From

The prefix is the “fingerprint” of the metadata’s origin. Use this table to identify the source of any crawled property:

Decoding the 4-Letter Type Codes

When you see a prefix like ows_q_ or ows_r_, it is followed by a code that signals the column’s data type. This is vital for the search engine to know if it should treat the data as a string, a date, or a number.

• TEXT: Single Line of Text
• MTXT: Multiple Lines of Text
• CHCS: Choice (Single Select)
• CHCM: Choice (Multi-Select)
• DATE: Date and Time
• NMBR: Number
• CURR: Currency
• BOOL: Yes/No (Boolean)
• USER: Person or Group
• URLH: Hyperlink or Picture
• HTML: Publishing HTML
• INTG: Integer
• GUID: GUID
• CTID: Content Type ID Field

Case Study: Analyzing Common Property Groups

Based on standard search schema behavior, here is how you should handle the properties you frequently see in your tenant:

1. The Choice Column (DocumentType)

In your schema, you likely see ows_DocumentType, ows_q_CHCS_DocumentType, and ows_q_CHCM_DocumentType.

• CHCS appears if the site column is single-select.
• CHCM appears if the site column allows multiple selections.
• Mapping Rule: Always map the raw ows_DocumentType.

2. The Rich Text Column (SummaryofDocument)

You may see ows_SummaryofDocument and ows_r_MTXT_SummaryofDocument.

• MTXT stands for Multi-Text, indicating this column supports multiple lines.
• Mapping Rule: Use ows_SummaryofDocument for your custom refiners to ensure consistent data handling.

3. The Status Field (PrimeClassificationStatus)

You may see ows_PrimeClassificationStatus and ows_q_TEXT_PrimeClassificationStatus.

• Mapping Rule: Map ows_PrimeClassificationStatus to your RefinableStringXX.

Best Practice: Which One Should I Map?

When configuring custom refiners (using RefinableStringXX, RefinableDateXX, etc.), the golden rule is: Always map the ows_ version (the raw property).

Why choose ows_ over ows_q_ or ows_r_?

1. Avoid Conflicts: The ows_q_ and ows_r_ versions are already automatically mapped by SharePoint to “hidden” system managed properties (like DocumentTypeOWSCHCS). Mapping them a second time can cause unpredictable behavior in complex queries.
2. Data Fidelity: The ows_ version provides the rawest form of the metadata. Auto-generated managed properties (the ows_q_ partners) are often forced into a text format, which can break sorting or range-filtering for numbers and dates.
3. Scalability: If you move a column from a local list to a site level, the ows_ prefix remains consistent, ensuring your manual mappings don’t break as your architecture evolves.

By standardizing your search schema around the raw ows_ properties, you ensure a robust, enterprise-grade search experience that is resilient to updates in your information architecture.