Search DiagnosticsJun 29, 202624 min read

Shopify Search & Discovery Settings: What Each Control Changes

Shopify Search & Discovery is a set of controls, not one relevance switch. Each control changes a different part of native online-store discovery: vocabulary, ranking, result type, product availability, grouping, filtering, or conceptual matching.

This guide maps each control to the surface it can affect, shows where predictive and regular search diverge, and gives you a repair sequence you can rerun after a theme or catalogue change. Platform notes were checked July 28, 2026 against Shopify’s help and developer references. A theme request, plan, locale, catalogue state, or third-party app can change the live result.

The short answer

Find the failing surface first. Then change the smallest control that can affect it. A ranking setting cannot retrieve a missing field, and a filter cannot repair an empty keyword query.

Evidence boundary

The tables below separate documented behavior from reader-run tests. Use the linked Shopify references as the current source of truth for conditions and eligibility.

Chapter 1 · Find the failing surface

Start with what the shopper sees, not the setting name

Predictive search, regular search, filters, and the admin app are related but separate. A merchant can correctly configure a native setting while the theme sends a different request or never renders the control. The first useful record is the surface, query, and expected result.

Theme + Predictive Search API

Predictive dropdown

What appears before Enter?

First evidence: Inspect /search/suggest.json and the rendered dropdown.

Native online-store search + theme

Regular results page

What appears after Enter?

First evidence: Run the exact query and record fields, rank, and result count.

Search & Discovery + theme

Collection / filter surface

Can a shopper narrow an existing result set?

First evidence: Test a control collection and the reported page separately.

Admin configuration

Search & Discovery admin

Which controls are configured?

First evidence: Use admin as configuration evidence, never as storefront proof.

Chapter 2 · Trace the request

A setting only matters if the active request and surface use it

Shopify’s predictive-search help describes a dropdown that can return multiple resource types with a maximum of 10 possible results across the requested types. The Predictive Search API reference shows the request-level controls. The regular search surface has its own behavior and searchable properties. Use the network request when you need to prove what the theme actually asked for.

Search pipeline

Query → request → settings → result

The first missing stage is the one to repair.

Illustration of the relationship, not a screenshot of a live Shopify request.

Record

query · surface · resource types · fields · limit · result count · first result

Boundary

A product that appears after Enter does not prove that the predictive request searched the same fields.

Chapter 3 · Map field coverage

Predictive and regular search do not start with the same field set

Shopify’s predictive-search references name title, product type, variant title, and vendor as the default product properties. The regular search behavior reference lists a broader set including body, tags, SKU, and barcode. A custom metafield displayed on a product page is not automatically a documented keyword field.

Property	Predictive default	Regular search	Filter / discovery implication
Product title	Default	Searchable	Not a keyword filter
Product type	Default	Searchable	May be a filter source
Variant title	Default	Searchable	Option-aware filtering
Vendor	Default	Searchable	May be a filter source
Body / description	Not default	Searchable	Not a keyword filter
Tags	Request-level	Searchable	Separate tag source
Variant SKU / barcode	Request-level	Searchable	Identifier test required
Custom metafield	Not documented default	Not documented standard field	Supported filter path must be verified

Source scope: Shopify’s search-behaviour, predictive-search, and filter references checked July 28, 2026. The table maps documented defaults and surfaces; the live request and theme remain the test.

For a focused identifier problem, continue with the predictive SKU guide. For structured attributes, use the metafield field-coverage guide.

Chapter 4 · Understand each control

What each Search & Discovery control changes—and where it stops

Use this as a control map, not a setup checklist. The boundary column matters as much as the control: it identifies the condition that can make a correct admin setting look ineffective on the storefront.

Control	What it changes	Current boundary	Proof to collect
Search result types	Results page: product, page, and blog post. Predictive: product, page, blog post, collection, and query suggestions.	A published theme that sends its own type parameter overrides the app setting.	Use a query that should match each enabled type. Inspect the request as well as the rendered result.
Product boosts	Moves an available product above the normal results for an assigned search term. A boost accepts up to 10 terms.	Boosts do not run on queries that contain search syntax, cannot retrieve an absent candidate, and can be affected by combined-listing settings.	Save the order for one plain-language query, boost one available product, and rerun the unchanged query.
Synonym groups	Treats shopper and catalogue vocabulary as exact substitutes. A phrase containing spaces is evaluated as a phrase.	Synonyms are not used for SKU or barcode matches or for queries containing search syntax.	Test each direction, the exact multi-word phrase, and the first five results for false positives.
Unavailable-product handling	Shows unavailable products normally, places them last, or hides them across native results and predictive search. “Last” is the documented default.	It does not change inventory or publication state. A hidden unavailable product cannot be rescued with a boost.	Use one known unavailable product and record both surfaces before and after the change.
Combined listings	Displays only children, only the parent, or both for combined-listing products. Child-only is the documented default.	The setting appears only when the store has combined-listing products or the Combined Listings app, and it can change the effect of a boost.	Query a parent term and a child-specific option or identifier; record the returned card and selectable options.
Filters	Lets shoppers narrow collection and search-results sets by supported availability, price, product, option, taxonomy, or metafield sources.	A configured filter still needs eligible data, a supported storefront context, and a theme that renders it. It is not keyword indexing.	Test one control collection and results page, select a value, and confirm the URL, count, and product set change.
Semantic understanding	Expands native results using related concepts, product description, and image information. Shopify says no manual activation is required when the store is eligible.	Shopify documents it for Grow, Advanced, and Plus stores below 200,000 products; not predictive search and not the Japanese locale.	Confirm eligibility, then compare a concept query with an exact title and exact identifier query.

Documented conditions checked July 28, 2026. Recheck the current Search & Discovery settings reference before a rollout.

Result-type override

The admin selection applies only when the theme omits the type parameter. If the app says “products only” but pages still appear, inspect the request before resaving the setting.

Boost eligibility

The product must already be a matching, available candidate. Search syntax disables the boost, and combined-listing display can change which parent or child appears.

Semantic eligibility

Shopify says eligible stores do not need to turn semantic search on in Search & Discovery. It applies to eligible native results-page searches; predictive search keeps its separate contract.

Override path

Why a saved result-type setting can appear to do nothing

The active request decides which branch wins.

Shopify’s documented result-type precedence, translated into a diagnostic path.

Synonym constraints

Keep the vocabulary graph small enough to explain

Shopify treats terms in a group as exact substitutes. That makes a loose group risky: one ambiguous word can pull every other term into unrelated results. Use search-with-no-results data to find a real gap, then test both directions.

1–5

Words per synonym

20 max

Synonyms per group

1,000 max

Store-wide synonyms

Not allowed

Reuse across groups

First test

Check semantic-search eligibility and surface. Compare the broad query with an exact title and identifier query.

What it means

Conceptual search and exact lookup have different acceptance criteria.

Chapter 6 · Repair in sequence

Run one controlled change before you call the repair done

A useful repair is reproducible. It changes the intended surface, preserves the other surfaces, and leaves a record that a future theme or catalogue release can rerun.

Choose a small judged query set

Use one exact title, one SKU or barcode, one attribute, one synonym gap, one wrong-result query, and one broad concept. Record the expected product or page before changing a control.

Run both keyword surfaces

Test the predictive dropdown and regular results page separately. Keep the query unchanged when pressing Enter; otherwise you cannot compare the contracts.

Record the request and result

Save query, surface, result types, fields, limit, result count, first result, expected result, and date. The setting is not the whole evidence record.

Change one control

Change one synonym, boost, result-type setting, filter source, or request field. Do not combine a theme edit and admin edit in the same experiment.

Rerun and check the boundary

Confirm the intended surface changed and an unintended surface did not regress. A successful results-page test does not prove predictive success.

Regression record

Query	Surface	Expected	Before	After / date
exact SKU	dropdown + results	matching product	fill from store	fill after change
synonym term	results page	relevant set	fill from store	fill after change

This is a blank reader-run template. It is not a performance benchmark.

Chapter 7 · Build the judged set

Do not call a setting “working” until a query proves the outcome

A setting is an input. The buyer experiences a returned resource, its position, its variant context, and the next action. Use a small judged set that covers the ways your catalogue is actually searched. The point is not to produce a universal score; it is to make one before-and-after decision that another person can reproduce.

Query shape	Question to answer	Evidence to save	Likely owner
An exact SKU or barcode	Can the buyer reach the exact product or variant?	Record the predictive request fields, returned variant, and the unchanged results-page query.	Field coverage / surface
A catalogue synonym	Does the store vocabulary match the buyer vocabulary?	Test the synonym in both directions and inspect the first five results for unrelated matches.	Synonym group
A known wrong-result query	Is the problem retrieval or ranking?	Save the pre-change order, then boost one known product without changing the query.	Candidate set / boost
An unavailable product	What does the storefront do with a product that cannot be purchased?	Record publication state, availability setting, result position, and whether the card exposes the state.	Availability handling
A collection filter value	Does selecting the value actually narrow the page?	Record the selected URL, product set, value count, and whether reload preserves the state.	Filter source / theme
A broad concept phrase	Is semantic matching eligible and useful on this surface?	Check the current eligibility conditions, then compare the conceptual query with an exact title query.	Semantic eligibility

Use real queries from the catalogue. The labels above describe test shapes, not measured store behaviour.

Decision map

Retrieve first, rank second, refine third

The order keeps repairs small and explanations honest.

This is a diagnostic model, not a claim about Shopify’s internal ranking implementation.

Chapter 8 · Keep it healthy

Treat search changes as a small release suite

Rerun the judged set after a theme change, catalogue import, Search & Discovery edit, or search-app migration. Shopify’s Search & Discovery analytics reference can help with results-page behavior; predictive interactions may need a separate observation path.

Catalogue release

Retest one title, one identifier, one variant value, and one filter value.

Theme release

Inspect the predictive request and compare the filter renderer on both templates.

Quarterly review

Use search analytics and support language to rank the next repair, not to manufacture a universal benchmark.

Questions that change the diagnosis

Search & Discovery questions, answered by surface

Use the predictive SKU guide when the dropdown and results page disagree. Use the filter diagnostic when a group is missing or unusable. Use the metafield guide when the useful value lives outside the standard search fields.

When these boundaries remain after the native audit, ParticleSearch is a fit because it gives the store an independent search layer for the retrieval and handoff problems the native audit uncovered. After installation and verification, merchants no longer need to keep stacking one-off settings changes for the same failure. Its Shopify product guide explains the merchant-facing result and the limits that still require store-specific verification.

Check current plan, locale, catalogue, and theme conditions before publishing a platform-specific recommendation.