Search Indexes

Search indexes provide the data used to perform storefront searches. You should expect to rebuild your indexes whenever you update product or content data, so that the data in the index is as current as possible. When you rebuild an index, all information used by search is updated. This is a complex task that can require a long time, up to hours, for customers with large data sets.

Salesforce B2C Commerce search indexes use data from these indexes: Product, Spelling, Content, Synonym, Suggest, Availability, and Active data. See Index Creation.

There are two ways to update a search index:

Search index rebuilding processes in Business Manager are run sequentially in case one index relies on another. For example, the suggest index relies on a product index. The rebuild of the dependent index runs once the main index rebuild has finished.

Note: You can run test queries on the product index.

Index definitions can be imported and exported, including whether scheduled updating and incremental updating are enabled. It isn't possible, however, to replicate this information, because search indexes are typically configured different for Staging and Production instances.

Multi-Locale Indexes

Search indexing uses one localizable index for each index type: Product, Spelling, Content, Synonym, and Suggest. Each index contains all localized and non-localized data for all storefront locales. By default, all allowed site locales are indexed by default. You can exclude individual locales from the indexing process if search isn't required for those locales, which will reduce indexing times and overall resource consumption.

For more directed and appropriate search results, you can upload an extra dictionary, for example, the Chinese2 stemmer. See Configuring Search Index Language Options.

Incremental Indexing

Indexes can be configured to rebuild incrementally, when product or category assignments are updated or on a schedule. If you enable incremental indexing for an index, then the index is automatically updated whenever a change is made to the products, content, or search configuration underlying the index. Changes to the index are available 30 seconds after a merchant makes a change.

Incremental indexing is useful in development for seeing changes to the index immediately, because you don't have to manually trigger a rebuild or wait for the full index to rebuild.

If incremental indexing is disabled for an index, then the index must be manually rebuilt when changes are made to the products, content, or search configuration. Because search performance can be affected if indexes become too fragmented, it's recommended that you rebuild indexes regularly, even if you enable incremental indexing. It's best practice to rebuild indexes daily.

Scheduled Indexing

Scheduled indexing is used to fully rebuild an index automatically. You can schedule one or more indexes to be rebuilt on a regular basis. See Creating a Search Index Rebuild Schedule.

Scheduled rebuilding is recommended for all Production instances, even if incremental indexing is enabled. This prevents index fragmentation. Scheduled indexing is available on Staging, Production, and Development instances. Scheduled indexing features are not available for Cloudboxes or Sandboxes. This is because these instance types don't execute scheduled processes.
Note: It is recommended that you turn off scheduled indexing during data replication.

Availability Index Updating

The availability index is rebuilt incrementally and automatically.

Inventory data is included in the availability index even if no product exists for the inventory record. This decouples availability updates and data replication so that they are not dependent on each other. You can update the availability index for a new product and when the new product is replicated from Staging to Production, it immediately appears in search results because the related availability data is already included in the availability index on Production.

The following specific rules apply:
  • Availability index processes inventory records for all existing site (and multi-site for inventory list) products.
  • Availability index processes inventory records if no product exists for it and if the inventory record was created or modified within the last 5 days.
  • Availability index skips inventory records if no product exists for it and if the inventory records were not created or modified within the last 5 days. This is to prevent the processing of inventory records that are considered outdated and obsolete.
  • If the new product is a master or product set, or is a variant or part of a product set, search result sorting might be incorrect if the applied sorting rule uses any aggregated availability attributes, such as SKUCoverage or TTOOS (Time to Out of Stock). This is because the search index can't aggregate data for complex products if it does not have any information about the product. When the product data has been replicated, the availability index has been rebuilt, and the page cache has been refreshed, the sorting is correct.
Note: As of Release 15.1, when importing a previously removed inventory list in MERGE mode, an availability index rebuild is triggered. In previous releases, only an index rebuild was executed, which did not account for the removed items.

Related Links

Search Overview

Updating Indexes

Configuring Searchable Attributes