Choose Field Types for Site Search Features

Updated

Configure Site Search fields based on what each feature needs the field to do, not just where the data came from.

A field that works well for keyword matching may be a poor choice for faceting, sorting, or URL handling. In some cases, the same source value works best as two fields: one for tokenized search behavior and one for exact-value behavior.

This guide focuses on the field-type decisions that most often affect feature behavior. It isn't a full schema reference.

Before You Begin

Before you start, make sure you have:

  • a SearchStax Site Search account
  • a Search App with content already indexed
  • access to your indexed fields
  • a basic understanding of the Site Search features you plan to configure

Use This Guide When You Need to Answer Questions Like These

  • Which field type should you use for this feature?
  • Why does a field work in one feature but not another?
  • Why doesn't a field appear as a sorting option?
  • Why do you need two versions of the same value?
  • Why does a field display correctly but behave poorly in search or faceting?

This article focuses on the field-type decisions that most often affect feature behavior.

Field Behavior and Source Context

This article focuses on the field distinctions that most often affect feature behavior:

  • text vs. string
  • date, numeric, and boolean fields
  • single-valued vs. multi-valued fields
  • exact-value vs. tokenized behavior

In this article, text means a tokenized field used for keyword matching. String means an exact-value field that isn't tokenized.

If you use Drupal, prefixes can help identify field behavior. For example, t_, tm_, and ts_ are tokenized text fields, while s_, sm_, and ss_ are string fields. Date fields commonly use prefixes such as dt_ and dts_.

These are Drupal-specific naming conventions. Crawler, API, and other ingestion methods may use different field names, even when the underlying field behavior is similar.

If you use Sitecore, source-side fields often use template or content-model field names rather than Drupal-style prefixes. Suffix-based naming is also common. These conventions differ from Drupal-style prefixes. Common examples include Title, Navigation Title (NavigationTitle), and Meta Description. These are examples, not universal Sitecore naming conventions, and SearchStax field behavior depends on how each source field is mapped or indexed.

If you use crawler-based indexing, choose field types in Crawler Field Map. If you use API or other custom ingestion, define and populate the fields yourself.

Some field changes can't be made in the Site Search UI alone. Depending on the ingestion path, you may need to change the source-side field definition or crawler field mapping, then rerun the crawl or reindex so the updated field behavior is reflected in your Search App.

Feature-to-Field Guide

Start with the feature, then confirm the field characteristics that matter most, such as whether the field is tokenized, exact-value, single-valued, or multi-valued.

Feature Use Avoid Example fields to use
Search Fields Text fields String fields program_name_txt_en, provider_specialty_txt_en, content_body_txt_en
Results Fields Fields that can be returned in results and display cleanly Fields that aren’t returned in results or need heavy UI-side cleanup title, summary, publish_date, page_url, thumbnail_url
Faceting String fields Text fields department_name_s, campus_sm, specialty_sm, content_type_s
Sorting Single-valued string, date, numeric, or boolean fields Multi-valued fields and text fields publish_date_dt, is_accepting_patients_b
Ranking Text, date, or numeric fields String fields title_txt_en, description_txt_en, content_body_txt_en, publish_date_dt
Rules Text fields for keyword rules; string, date, or numeric fields for exact-value rules Fields that don’t support the kind of match the rule needs content_type_s, publish_date_dt, program_name_txt_en
Spell Check Text fields with terms users are likely to search for String fields and heavily processed text fields (for example, stemming such as running → run) text_spellcheck, title_txt_en, content_body_txt_en
Location Fields using a geospatial latitude/longitude field type, such as LatLonPointSpatialField Fields that only store place names or addresses location_ll, office_location_ll, campus_location_ll

A field can be a good choice for one feature and a poor choice for another. If one source value needs to support search, faceting, sorting, display, or spell check in different ways, create separate fields for those uses.

Understand the Main Field Distinctions

Text vs. String

This is usually the first distinction to check for most Site Search features.

A text field helps users find content based on words inside a value. For Search Fields, this is usually the better default.

A string field keeps the full value intact and behaves more strictly. It's usually a better choice for exact-value behavior such as faceting, filtering, sorting, or URL mapping.

For sorting, use a field that Site Search shows in the Sorting field list. String, date, numeric, and boolean fields are common choices.

Examples:

  • Higher education: Use a text field for program_name if users should be able to find nursing inside Bachelor of Science in Nursing.
  • Healthcare: Use a string field for specialty if you want a facet value like Primary Care to stay intact.

If users need both behaviors, keep both field versions.

In Sitecore, a source field such as Title may map to a tokenized search field for keyword matching, while fields used for display or stable exact values should be mapped according to the intended Site Search behavior.

Date, Numeric, and Boolean Fields

Use structured field types when a feature depends on stored values rather than keyword matching.

These field types are usually the right choice for tasks such as:

  • chronological sorting
  • numeric comparison or filtering
  • true/false filtering
  • function-based ranking logic based on dates or values

Examples:

  • Higher education: Use application_deadline_dt for a date such as 2026-01-15 and is_online_b for a true/false value such as true.
  • Healthcare: Use publish_date_dt for a date such as 2026-03-01, estimated_wait_time_i for a value such as 12, and accepting_new_patients_b for a true/false value such as false.

Single-Valued vs. Multi-Valued

This matters most for sorting and for any feature that expects a single stable value per document.

Use a single-valued field when each document should store a single canonical value.

Use a multi-valued field when a document can legitimately contain multiple values for the same field.

Examples:

  • Single-valued: Use publish_date when each document has one publish date, program_level when each program has one level, and appointment_type when each page represents one appointment type.
  • Multi-valued: Use department_tags when a page belongs to multiple departments, specialties when a provider has multiple specialties, and campus_locations when a program is available on multiple campuses.

Multi-valued string fields are often a good fit for faceting and filtering.

If you want to sort on a field, first make sure Site Search shows that field in the Sorting field list.

In Sitecore-based implementations, a field such as Navigation Title is typically single-valued.

When to Create a Second Field

Create a second field when a source value needs to support more than one behavior.

A common pattern is to keep one field for search behavior and one field for exact-value behavior.

This is common when the same value needs to be:

  • searched as keywords
  • used as an exact label for faceting
  • used as a stable value for sorting
  • displayed cleanly in results
  • stored in a machine-usable form and a human-readable form

In those cases, don't force one field to do everything. Keep separate fields for separate uses. For example, keep a text field so users can find the value by keywords, and keep a string field so the same value works cleanly for facets or filters.

The same pattern applies to Sitecore source fields. For example, a source field such as Title may need one indexed version for keyword matching and another indexed version for exact-value or display behavior, depending on how it is used in Site Search.

The most common patterns are:

  • Search + Facet
  • Search + Sort
  • sort/filter value + display value
  • URL destination + separate display text when needed

Examples:

  • Higher education department name: Use department_name_s for faceting and filtering, and department_name_txt_en for keyword matching.
  • Healthcare specialty: Use specialty_sm for faceting, and specialty_txt_en for search and ranking.
  • Publication or event date: Use a date field for sorting, filtering, or ranking. If you also want to show a date on the result card, add the appropriate field in Results Fields.

How This Differs by Ingestion Path

  • Drupal: You may already have parallel field variants through Drupal-specific prefixes and suffixes.
  • Crawler: Create the second field intentionally in crawler field mapping when one extracted value needs two different behaviors. For example, a content date may need one date field for sorting and filtering, while the field you want to show on the result card is added in Results Fields. If an older crawler setup created the date as multi-valued, you may need to update the field configuration and rerun the crawl before it becomes usable for Sorting.
  • API or other custom ingestion: Create and populate both fields in the documents you send to the index.

Common Symptoms and What to Check First

Use these symptoms as starting points, not hard rules. The same symptom can have multiple causes.

Facet Values Look Broken, Split, or Truncated

Likely field issue: You used a tokenized text field for faceting.

What to change: Use an exact-value string field instead.

A Field Doesn't Appear in Sorting, or the Sort Behavior Is Unreliable

Likely field issue: The field isn't available for Sorting in Site Search, or the field list needs to be refreshed after a schema change.

What to change: Use a field that appears in the Sorting field list in Site Search. If you recently added or changed the field, use Reload Schema. In crawler-based setups, a custom date may still be unusable for Sorting if the current field is multi-valued. If the source value is truly single-valued, update the field configuration to use a single-valued date field for the canonical sort value, then rerun the crawl so the updated field is reflected in the index.

A Title or Label Field Displays Correctly in Results but Doesn't Behave Well in Search

Likely field issue: The display field isn't the right field for keyword matching, or it isn't in Search Fields.

What to change: In the Site Search UI, make sure Search Fields includes the search-oriented version of that value, not only the display-oriented or exact-value version. Keep a separate display field for result cards when needed.

Search by Title or Label Works Only in Limited Cases

Likely field issue: The field was indexed in a way that doesn't support the kind of text matching you expect, or the field wasn't added to Search Fields.

What to change: If users need broader matches, add a search-oriented Text field to Search Fields instead of relying only on an exact-value field. This is especially common with title-like fields. A field can appear in results and still be the wrong field for broader search behavior.

Synonyms Don't Change Results the Way You Expect

Likely field issue: The matching terms may be indexed only in Search Fields that aren't full-text fields, so synonym expansion isn't helping the way you expect.

What to change: Review which fields are included in Search Fields. If the terms users search appear only in exact-value fields, move to a search-oriented text field for matching and retest the affected queries.

Singular, Plural, or Possessive Versions of the Same Query Return Different Results

Likely field issue: Your Search Fields may be using a text field that doesn't support the stemming or possessive handling you expect.

What to change: First confirm that Search Fields includes the main search-oriented fields for titles, descriptions, or body content. If search still feels too strict after that, review whether the search field type is the right Text field for your content, then reindex or rerun the crawl and retest those queries.

Hit Highlighting Changes the Result Snippet in Ways You Didn't Expect

Likely field issue: This may not be a field-type problem. Hit Highlighting changes how the result snippet is displayed around matching terms.

What to check: Review the field mapped to the result Description and the Hit Highlighting setting before treating this as a Ranking issue or an indexing problem.

Result Links or Smart Answers Source Links Are Wrong

Likely field issue: The field mapped to the result destination does not contain the full URL value you want to use.

What to change: Use a clean URL field that stores the full URL value, then map that field to Url in Results Fields. If you changed the source field or mapping, reindex or rerun the crawl so the updated values are stored.

Smart Answers Feels Weak or Cites the Wrong Kinds of Pages

Likely field issue: The problem may not be Smart Answers itself. Smart Answers depends on the best matching documents returned by search and the content available in those documents.

What to change: Review Search Fields first, then Ranking, Content Exclusions, and source content quality. Do not use Smart Answers as a substitute for missing baseline configuration. For more on Smart Answers behavior and configuration, see Smart Answers.

A New Field Doesn't Appear Where You Expect to Configure It

Likely field issue: The field may not be fully available in the App yet, the schema view is out of date, or a selected field type filter is hiding the field.

What to change: Confirm the field is actually being indexed, confirm that the selected field type matches the field you need, publish or rerun the crawl or reindex as needed, and then reload the schema.

Articles in this section