--- title: Limitations of Commerce Search v3 slug: commerce-composable-modules/search-v3/limitations-of-commerce-search-v3 docTags: createdAt: 2026-08-05T19:35:40.106Z --- Commerce Search v3 for Optimizely Configured Commerce does not support some features, while other features are supported with limitations. ## Unsupported features Commerce Search v3 does not support the following features: - **Customer-specific part number search** – Google Vertex AI does not currently support searches with [customer-specific part numbers](docId\:A8rAckq8kZcCvuk3C0k3T) assigned at the customer level. However, customers can still use Quick Order to search for customer-specific part numbers because Quick Order uses a different API intended to be a part number ordering system, instead of a relevancy search. - **Search within** - **Instant attributes sync** - **Mobile App (will be supported in the future)** - **Partner local development**– Commerce Search v3 does not currently support local development and comes with certain limitations. Work is underway to explore options that may enable limited local testing against sandbox instances; however, the overall feasibility is still under review. You and your partner should use sandbox environments for testing and development purposes at this time. - **Sponsored or pinning products** ## Supported with limitations The following features are supported with limitations: - **Child product and variant restrictions** – When Commerce Search v3 is the search provider, the **Hide selected products** restriction, when applied to a variant, automatically applies to its primary or parent product by design. As a result, this restriction cannot be managed at a granular level for variants. You should not use this restriction on variants, and if necessary, apply it only to the parent product. - **Attributes (facets)** – The **Enable Dynamic Facets** setting in **Search System settings** controls how attribute filters appear on the **Search Results** page. When enabled, the storefront displays AI-curated dynamic facets from indexed product attribute data and real user search behavior. A maximum of up to 50 dynamic facets are generated and each facet lists up to 50 values. When disabled, Commerce generates static attribute filters for category browsing only (not search queries). Static attribute filters display up to 300 values per attribute. To learn more about Commerce facets and dynamic facets cold start, see the Facets section in [Test Commerce Search v3](docId\:KC6Ob7zWuIBLxnqcffs7v). **Facet limits:** | Name | Limit | | --------------------------------------------------------------------------------- | ----- | | Maximum number of facets (including up to 150 static and up to 50 dynamic facets) | 200 | | Maximum values per static facet | 300 | | Maximum dynamic facets (product attribute filters) | 50 | | Maximum values per dynamic facet | 50 | - **AI training and pre-warming** – Dynamic facets, behavior-based search relevance, and autocomplete suggestions depend on user event data. A newly migrated catalog does not have that data. Dynamic facets and autocomplete suggestions may return limited or no results until enough user events accumulate and the model processes them. Basic product search works with catalog-based relevance; behavioral data improves ranking over time. You cannot pre-train the model directly. You should run in shadow mode before you switch providers. See [Shadow mode](docId\:DS5VzU1Fd9TiG8TLG0SGU) in *Enable Commerce Search v3 in production*. - **Boosting by purchase history** – This should be supported by having Google Vertex Al learn from user events. More testing is necessary to validate this. - **Product specifications** – This requires crawlers to pick up specs from Product Detail pages and Google Vertex Al to know these product specifications. - **CMS** – Only Spire sites are supported. Classic sites are not supported. - **Autocomplete** – Autocomplete does not provide suggestions for specific products or website content. Instead, it supports returning the following types of suggestions: - **Search term suggestions** - **Categories** – Popular and suggested categories - **Brands** – Popular and suggested brands :::Paragraph{indent="1"} If your users expect product names or website content in autocomplete, you would need to implement a custom solution, which could be outside of Google's recommended flow. ::: ## Regional availability Commerce Search v3 is currently hosted from the North America region. Support for non-North America regions is not available at this time. Expansion to additional regions is under consideration for future updates. ## Rate limits This following sections describe how Configured Commerce handles rate limits and service outages for search and autocomplete. Understanding this behavior helps you anticipate storefront impact and take appropriate action when rate limits are reached. ### Commerce Search v3 When Commerce Search v3 requests exceed the rate limit, the platform falls back to Commerce Search v2 automatically to maintain storefront functionality. Because of this fallback, storefront visitors do not see errors during temporary rate limit spikes. However, search results may differ from those returned by Cloud Retail Search. Commerce Search v3 also falls back to Commerce Search v2 when a search request fails outside of rate limiting. Storefront visitors see results instead of errors, so search stays available while you resolve the problem. Switching back to Commerce Search v2 by hand is no longer necessary. Monitor the application logs for fallback errors, then resolve the underlying Commerce Search v3 problem to restore Commerce Search v3 results. Submit a [support](https://support.optimizely.com/hc/en-us) request to Optimizely when the errors continue. The application log records the fallback as `Google Cloud Retail Search or the Search Service may be unavailable or experiencing issues, causing search requests to fail. Falling back to Elasticsearch for search results.` Commerce Search v2 runs on Elasticsearch, which is the name the log uses. ### Autocomplete When autocomplete requests exceed the configured rate limit, the platform returns empty autocomplete suggestions silently, so storefront visitors can continue to the search results page without interruption. No error is surfaced to the end user during temporary rate limit spikes. If an autocomplete service failure occurs outside of rate limiting, suggestions do not appear, but no error is shown to storefront visitors. Errors are logged so customers can identify persistent issues and open a support ticket if needed. ### Best practices for partners and customers Page design and customizations can influence search and autocomplete usage and may increase the likelihood of reaching rate limits. Consider the following recommendations: - Avoid triggering search or autocomplete requests unnecessarily, such as on every keystroke without debouncing. - Review front-end implementations to ensure search calls are not duplicated or fired excessively. - Contact Optimizely Support early if usage patterns suggest rate limits may be approached, so quota increase requests can be submitted proactively.