The SearchStax Site Search solution’s Crawler lets us set up custom index fields to contain content from various HTML elements in the target documents. See Crawler for more information.
The available field types are Boolean, Date, Float, Integer, String, and Text. This affects how the data interacts with Solr and Site Search features.
Boolean
Boolean (True/False) fields are straightforward. Our clients often use Booleans for include/exclude lists and for conditional display in their custom front-end interface. For instance, a Boolean field could be used to display an icon beside search results that require authentication before viewing.
Date
Date fields are useful for sorting search results. They follow the ISO 8601 standard format, such as 2025-02-11T18:13:18Z. If you want to search by date, you’ll have to break this up and insert the values as meta tags in the website page HTML. Then extract the meta values through Crawler.
Float
Site Search clients don’t seem to use floats in website search applications. Floats are more often seen in the context of product search.
Integer
Integers can be helpful if you want to do sorting, or ranking based on mathematical functions. For instance, sorting by month as an integer is much more useful than sorting months alphabetically.
Again, one would insert the values in the web page as meta tags, and then map them into Site Search through the Crawler.
String and Text
The string and text field types are a special case because sometimes you need the same value rendered both ways at once.
- String: You cannot do keyword matching on a string field. The query must exactly match the entire string for a match to take place. This is a good field type for facets.
- Text: A text field breaks up a string into single-word tokens that are indexed as multiple independent values. Any one of them can match a keyword in a query.
For instance, we can set up the Crawler to extract the value of a page’s Product meta field, but do we want “string” or “text?” Crawler lets us try it both ways at once.
After making both fields searchable, we can proceed to the Faceting Tab to set up both fields as facets. After regenerating the Search UI App, we can see that the two resulting facet lists are not the same.
The “string” facet uses the entire content of the field, producing readable labels for the user to select. In contrast, the “text” facet displays single-word tokens that have been subjected to stemming before indexing. Although these facet values are functional, they don’t convey the true meaning of the field value to the user.
The example above also explains why sorting results on a string field works as expected, but an alphabetic sort on a text field produces jumbled results.
Questions?
Do not hesitate to contact the SearchStax Support Desk.