Magento 2 search relevance comes from three levers: synonym groups you manage in the admin, stopword lists that live in the codebase, and per-attribute search weights set on each product attribute. Tune all three, reindex the catalogsearch_fulltext index, and OpenSearch returns the products shoppers actually mean instead of near misses.
Most teams running Magento and Adobe Commerce treat on-site search as a solved problem the moment OpenSearch is connected and the index is green. It is not. The default configuration ships generic analyzers, no synonyms, and flat attribute weighting, so a store that sells “sneakers” returns nothing when a shopper types “trainers,” and a search for a SKU fragment buries the exact match under description matches. This guide covers the three native relevance controls, how they map onto OpenSearch, and the order of operations that keeps your changes from silently reverting on the next reindex.
How Magento search actually reaches OpenSearch
Since version 2.4.4, Adobe Commerce requires either Elasticsearch or OpenSearch as the catalog search engine, and OpenSearch is the engine most on-premises and self-hosted stores run today. Magento does not expose the raw query DSL to merchants. Instead, three layers of configuration compile down into the index and the query that OpenSearch receives:
- Synonym groups, managed entirely in the admin, expand the shopper’s query before it hits the index.
- Stopword lists, stored as CSV files in the module code, strip low-value tokens during analysis.
- Attribute search weight, set per product attribute, becomes a field-level boost at query time.
The fulltext index (catalogsearch_fulltext) is what ties these together. A full reindex builds a new versioned index, applies the current analyzer and mapping settings, and atomically swaps the alias so shoppers never hit a half-built index. That atomic swap is also why a stopword or analyzer change does nothing until you reindex: the live index keeps the settings it was built with.
If you are weighing native OpenSearch against a managed alternative, our breakdown of OpenSearch versus Elasticsearch tuning for Adobe Commerce covers the engine-level decision. This article assumes you are staying on native OpenSearch and want it to perform.
Synonym groups: the fastest relevance win
Synonyms are the one lever you can change without touching code, and they usually deliver the biggest recall improvement for the least effort. Go to Marketing > SEO & Search > Search Synonyms, click New Synonym Group, and enter comma-separated terms that should be treated as equivalent, such as sneakers, trainers, kicks.
Two settings decide how a group behaves:
- Scope. A group can apply to All Store Views or a single store view. Keep brand-specific or locale-specific synonyms scoped to the right view so a UK store’s “trainers” mapping does not pollute a US catalog.
- Merge behavior. When a shopper’s query matches terms in more than one group, Magento can merge the groups. This is powerful and risky: overlapping groups can quietly chain unrelated terms together, so keep groups tight and review them against real query data.
Pull synonym candidates from your actual search logs, not from a brainstorm. The queries that return zero results or have high exit rates are your synonym backlog. Adobe’s search configuration documentation describes the native settings, and the practical walkthrough at MGT Commerce shows the group editor in context.
One clarification that trips up teams: Search Synonyms is not the same as Search Terms (Marketing > SEO & Search > Search Terms). Search Terms manages popular queries and landing-page redirects. Synonyms change what the engine matches. You will often use both.
Stopwords: the setting hiding in the codebase
Stopwords are common, low-meaning tokens such as “the,” “a,” and “of” that get stripped from both the indexed content and the query so they do not dilute matching. There is no admin screen for them. Magento ships the default list as a CSV inside the search module, and the module is still named after Elasticsearch internally:
app/code/Magento/Elasticsearch/etc/stopwords.csv
Per-locale lists follow the pattern stopwords_<locale>.csv, for example a French Canadian list at stopwords_fr_ca.csv. If your catalog serves a locale without a tuned list, or your products contain words the default list wrongly discards, you have two safe options:
- Override through a custom module. Point the stopwords config at your own CSV via
di.xmlin a custom module rather than editing the vendor file. Editing core is overwritten on the next upgrade. - Ship a locale file. Add
stopwords_<locale>.csvthrough your module so the engine picks up the right list per store view.
Never edit the file in app/code/Magento or vendor directly on a production store. That change is unversioned, invisible to the next developer, and gone after composer update. After any stopword change, rebuild the fulltext index:
bin/magento indexer:reindex catalogsearch_fulltext
A common symptom that points at stopwords: a model number or product line that contains a short common word (say, “In Stock Pro”) returns noisy results because the common token was stripped and the engine matched on the remainder. Adobe’s indexer management reference covers the reindex commands and modes in full.
Attribute search weight: making the right fields win
Search weight tells OpenSearch which fields matter most when the same term appears in several attributes. Set it per attribute at Stores > Attributes > Product, open the attribute, go to Storefront Properties, set Use in Search to Yes, and set Search Weight on a scale of 1 to 10.
The weight becomes the field’s boost at query time, so a term found in a highly weighted field ranks the product above a product that only matched a low-weighted field. Sensible starting values for most catalogs:
| Attribute | Search Weight | Rationale |
|---|---|---|
| Name | 8 to 10 | A term in the product name is almost always the intended match |
| SKU | 6 to 8 | Shoppers and B2B buyers paste partial SKUs and expect exact hits on top |
| Short Description | 3 to 5 | Useful signal, secondary to name and SKU |
| Description | 1 to 2 | Long body copy matches everything; keep it from dominating |
Two technical caveats worth knowing. First, an attribute is only searchable if Use in Search is enabled, so a weight on a non-searchable attribute does nothing. Second, mapping-level field boost is deprecated in OpenSearch 2.x, so while the Magento mapping may still emit a boost value, the effective weighting is applied in the query. The practical takeaway is unchanged: set weights in the admin and let Magento translate them.
The three levers side by side
| Lever | Where you set it | Reindex needed | Changes what |
|---|---|---|---|
| Synonym groups | Admin: Marketing > SEO & Search > Search Synonyms | No | Query expansion (recall) |
| Stopwords | Codebase: stopwords.csv via custom module |
Yes | Tokens kept or dropped (precision) |
| Attribute search weight | Admin: Stores > Attributes > Product > Storefront Properties | Yes to rebuild mapping | Field ranking (ordering) |
Synonyms raise recall by matching more of what shoppers mean. Stopwords and weighting raise precision and put the best matches first. You want all three working together, not one in isolation.
The order of operations that keeps changes live
Relevance work goes wrong when changes are made in the wrong order or without the reindex that commits them. A reliable sequence:
- Pull the last 30 to 90 days of search queries, sorted by volume and by zero-result rate.
- Add synonym groups for the zero-result and low-conversion queries. Test in a staging store view first.
- Audit attribute search weights. Confirm Name and SKU outrank Description, and that no stray attribute is both searchable and over-weighted.
- Review stopwords only if a specific term is being wrongly stripped. Change them through a module, never in core.
- Run
bin/magento indexer:reindex catalogsearch_fulltext, then confirm the alias points at the fresh versioned index. - Re-run your problem queries and record before-and-after result counts and positions.
Treat this as a monthly loop, not a one-time setup. Catalogs change, seasons change, and the language shoppers use changes with them.
When native tuning is not enough
Native synonyms, stopwords, and weighting cover the majority of relevance problems on a mid-sized catalog. There are two points where teams outgrow them:
- Scale and merchandising control. On very large catalogs, or when merchandisers need rule-based boosting, pinned results, and redirects without a developer, a dedicated search layer pays off. Algolia on Magento and Hyva is one route, and Adobe Commerce Live Search is the native SaaS option with semantic ranking.
- Faceted filtering performance. Relevance and filtering are different problems. If result quality is fine but filtering is slow, see our guide to layered navigation performance on Hyva.
A fast, modern storefront amplifies all of this. The Hyva frontend renders search results and autocomplete without the Luma JavaScript overhead, so the relevance you tune in OpenSearch reaches shoppers in a responsive interface. Bemeir runs the same search and merchandising playbook across Shopify, BigCommerce, and Shopware builds, but the deepest control lives in the Magento and OpenSearch stack described here.
FAQ
Do I need to reindex after adding a synonym group?
No. Synonym groups are applied at query time, so a new or edited group takes effect without a fulltext reindex. Stopword changes and attribute mapping changes do require a reindex, because they affect how content is analyzed and indexed.
Why does my exact SKU search not show the exact product first?
Usually because SKU is either not set to Use in Search, or it is weighted the same as or lower than Description. Raise the SKU search weight above Description, confirm Use in Search is Yes, and reindex. If partial SKU fragments still fail, the fragment may be shorter than the engine’s minimum query length.
Where is the stopword list and is it safe to edit?
The default list is app/code/Magento/Elasticsearch/etc/stopwords.csv, with per-locale files named stopwords_<locale>.csv. It is not safe to edit in place on production. Override it through a custom module so the change is versioned and survives upgrades, then reindex catalogsearch_fulltext.
Does OpenSearch change any of this compared to Elasticsearch?
The admin workflow for synonyms, stopwords, and search weight is identical. The main difference is that mapping-level field boost is deprecated in OpenSearch 2.x, so weighting is applied at query time rather than baked into the mapping. Your admin settings still work the same way.
How often should we revisit search relevance?
Monthly for an active catalog. Search behavior shifts with new products, seasonality, and campaigns. A short recurring loop of pulling query logs, adding synonyms, and checking weights keeps zero-result rates down without a large project each time.
Getting the relevance you paid for
OpenSearch gives Magento a capable search engine, but it ships neutral. The stores that convert on search are the ones that add synonyms from real query data, keep stopwords versioned and locale-aware, and weight Name and SKU above body copy, then reindex so the changes actually land. If you want a team that has shipped this work on real Adobe Commerce and Hyva stores, learn more about Bemeir and the technology partners we integrate across the search and merchandising stack.
