Optimizing product data for search and browsing

• Although they might seem like obvious locations to search, the product name and short description should be considered more for display purposes only. They can be use for searching, but to enhance the accuracy of the search result or perform additional relevancy fine tuning, it is better to attach descriptive keywords into the "keyword" field of the corresponding catalog entry indexed document. The CATENTDESC.KEYWORD database field maps to the "keyword" field in the product index. This is used for text searching, so using this field improves the relevancy of the search result.
• Keep product name as short and precise as possible. Avoid adding non-descriptive metadata, such as part number, model number, or attribute values, into the product name or short description. Doing this may impact the relevance of the search result as these metadata could be tokenized or normalized into another irrelevant form which may affect the search result. For example, an attribute or its value added to a product name can cause this product to be returned in the response even though the actual attribute is not marked as searchable.
• Re-useable properties of a product or an item should be loaded into an attribute in the Attribute Dictionary. This way, additional search related configurations can be associated with these data, such as "defining attribute", "descriptive attribute", "searchable", "facetable", or "merchandisable". The search runtime can more accurately determine the usages of this property when performing searches at the storefront.
• Attributes have a significant overhead when used in searches. To maintain optimal response times when performing searches at the storefront, it is important to understand the purpose and implied overhead of each property of an attribute. For example, if an attribute is only for display and is not needed for browsing or navigation, you should disable the "Show facet in Search result" (keyword searchable) and "Use in faceted navigation" (facetable) properties.
  Note: Even though this attribute is not facetable, it is still possible to make it searchable. The overhead of indexing searchable attributes is less than when making it facetable. For more details on what each attribute property means, see Creating attributes in the attribute dictionary.
• Organize products and items into appropriate categories and subcategories. The category name should be specific to what has been grouped within it. Doing this will help improve the relevancy of the result when the customer searches for products by category name. Following is a list of practices that are also recommended:
• • Avoid combining multiple category names together using separators such as &, or +.
  • Avoid using special characters, such as | or ||, in the name of a category.
  • Avoid combining leaf category names in their parent category name.
  • Use unique names and specific names for each category.
• Certain catalog related data, such as inventory statuses, prices, or customer rating may require more frequent updates. Store and maintain this data in a separate location (both inside of the search index or in the database in case it needs to be persisted there) so that it can be updated more efficiently. For example, instead of adding this kind of volatile data into the Attribute Dictionary, it is better to make use of custom index fields to populate those details wherever possible. In general, incrementally updating Attribute Dictionary Attribute Value is an expensive operation and should be kept to a minimum.
• Each index field in the Attribute, Category, and Product indexes is designed for a specific set of query time usages, such as searching, browsing, faceting, filtering, or sorting. Understanding what kind of data is indexed into which index field is important when designing the catalog. By default there are multiple Ingest default stages involved during an indexing operation and each stage is designed to perform a specific set of operations. For more about how each Ingest stage is mapped to the underlying database fields, see Ingest Product index pipeline.
• Not all index fields are treated equally. Some are considered to be more relevant than others. There is a global configuration to control the weighting of these index fields which will then be used for boosting at query time.

Finally, when it comes to updating the search indexed data, avoid updating the product indexes directly when the data feed comes in bulk and updates most of the products in a catalog. In such a case it is better to load them into a separate index. If there is a business requirement where this data needs to be used with the Product index, such as searching, filtering, sorting, or faceting, then place them into an index field with a data type that is designed for that particular usage. Do not load this kind of data into the attribute dictionary.