On-Site Search, Predictive Search and External Search Services on Shopify

Definition

The search box, the dropdown and the results page built as a real merchandising surface: multi-type tabs, hidden-SKU suppression, keyword-targeted promo tiles, zero-state panels with popular searches, accessible combobox semantics — and, where Shopify's own search could not express the catalog, a fetch to an external search service rendered client-side inside Liquid.

The Evidence

• Evidence strength: 11 live, Deploi-attributed builds across 2 Shopify storefronts, not 3 — Nudestix 6, Three Ships 5.
• The third storefront isn't here on purpose. LUS Brands runs Dawn's own search stack. It's configured, not engineered, so there is no Deploi-attributed search build to count and we don't count one.
• Split by attribution: 5 Deploi-authored, 6 modifications of vendor theme code — named as such on each build page.
• Evidence quality: seven carry code plus client working records. Four are documented from the code; no client-side record of the decision survives.
• Confidence: 5 strong, 6 moderate.
• One dependency we do not claim: on one storefront the search results come from a service that runs outside the Shopify theme. That service is client infrastructure. Everything on this page is the storefront engineering in front of it.
• Surfaces: the header, the search results template, blog indexes, one collection template.
• Status: Live, verified 2026-09-06. Buy-vs-build verdict: split — see below.

How It's Actually Built

Two architectures sit under this capability, and the difference between them is where the result set comes from.

The native path keeps Shopify's index. On Three Ships, search.liquid drives the whole search template: it walks search.results once to pre-count products, articles and pages, renders a tab bar whose links carry data-type, and lets the theme repaint a tab by re-fetching the section with &type=. Facets and sort come from search.filters and search.sort_options. Products carrying the merchandising team's hidden and #hidden tags are skipped inside the render loop, because Shopify's search object cannot be told to exclude a tag before it counts. Every interactive control has a <noscript> anchor or submit button behind it, so a filtered, sorted, deep-linked search still works with JavaScript off.

The merchandising layer is theme blocks. A promo block on the search section takes a trigger_filter_label — the facet's URL key, not its display label — and renders a promo card only when that facet is active. Liquid has no set-membership test, so the section builds a section-delimited string of active facet keys and asks whether it contains the trigger; a grid-slot counter keeps the tile where the merchandiser put it. The zero-state is merchandised too: search-popdown.liquid takes a unique argument so the same component can be instantiated in the desktop header, the sticky header, the mobile menu and the search page without the combobox aria-owns / aria-controls wiring colliding, and its empty state renders a merchandiser-managed popular-searches list plus two collection carousels, server-rendered.

The external path swaps the data source and keeps everything else. On Nudestix, predictive-search.js retains Dawn's PredictiveSearch-extends-SearchForm shape — the open/close lifecycle, aria-expanded and aria-activedescendant, roving arrow-key selection, one AbortController per query — and replaces only the fetch. Results arrive as JSON rather than as rendered section HTML, so the panel is templated in the browser: predictive-search.liquid is delivered into the page as a <script type="text/x-handlebars-template"> holder by both header-search.liquid and main-search.liquid, with the templating language reconfigured to [[ ]] delimiters so one file is legal Liquid and a legal template. Compiled results are cached per normalised term across every instance on the page. The merchandising slots stay authorable in the theme editor, which is the point of templating in the theme rather than accepting a vendor's panel.

The Buy-vs-Build Position

The corpus's own verdict:

One storefront moved search off Shopify to an external API and kept it; the other two kept native search and built only the merchandising layer on top.

Read that alongside the evidence strip: the verdict counts all three storefronts in the corpus, while the count above only counts gated, Deploi-attributed builds — which is why one of those three has no builds on this page. The verdict is genuinely split, and the split is not about search quality. It's about whether the thing a shopper is choosing is a thing Shopify can rank. Our full reasoning is in the site search decision.

The Builds

Four of the 11 have published pages — three in this batch, one earlier. Five of the rest — the merchandised search popdown described above, the client-side filter over a video library, the article-card forks that give search results their own crop, and the blog card renderer among them — are documented and will follow. Two won't get pages of their own: one duplicates a build page already published here, and the other stopped at editorial review.

Nudestix

• Predictive search moved off Shopify onto an external search API with client-side templating — Dawn's predictive-search element kept and only its data source and render step swapped, with the panel's offer slots still theme-editor settings. High complexity, header and search.
• Shade-level collection grid hydrated from an external faceting service — the other half of the same architecture, on a collection template: the theme renders a shell and the result set arrives from outside it. High complexity, collection.

Three Ships

• Tabbed multi-type search results page with faceted filtering — the premium theme's search section extended with type tabs, native facets and tag-based product suppression. High complexity, search.
• Filter-triggered promo cards inside the search results grid — a promo tile that appears only when a chosen facet is active, placed by grid slot. Medium complexity, search and collection.

What This Rests On

• Liquid section schema and settings — 10 of the 11 builds. Every merchandiser control here is a section setting or a block.
• Predictive Search API — 4 builds; the endpoint and the custom element the panels are built on, including the ones that no longer call it for data.
• Section Rendering API — 4 builds; how a tab repaints and how a results grid is re-fetched.
• Storefront search and storefront filtering — 2 builds each; the native index and the facets the merchandising layer is triggered by.
• Custom elements — the combobox components the themes ship, extended rather than replaced.
• Theme blocks, metafields, metaobjects and the Cart AJAX API — promo blocks, facet-backing data, swatch references and add-to-cart from a result card.
• Handlebars — the client-side templating step on one storefront, running from a template authored in Liquid.

What Varies by Storefront

Theme base decides how much of this is ours. Nudestix runs Dawn 6.0.2, so the search template and the predictive-search element are Dawn's lineage and our work is layered onto them and named that way on each build page. Three Ships runs Palo Alto 5.8.0 by Presidio Creative — a paid premium theme — so its search section is vendor code we extended and have to keep upgrading; what's identifiably ours there is the tag suppression, the promo block system and the merchandised zero-state, not the search template. LUS Brands runs Dawn 15.4.1 with Dawn's search, which is why it isn't counted above.

Catalog shape decides the architecture. Skincare shoppers search ingredients, concerns and how-to content as often as SKUs, so the useful move is to return products and articles and let the shopper separate them — a tab problem, solved inside Shopify. Color cosmetics inverts it: the unit a shopper chooses is the shade, and Shopify ranks and lists products, so a twelve-shade blush is one result. That's the catalog that pushed a result set outside the theme, and it's the only reason we'd defend doing it.

The installed stack sets the last difference. One storefront carries a templating library in the theme to render search results client-side; the other renders every result in Liquid and ships no search JavaScript beyond the theme's own.

Where This Gets Hard

Native search is harder than it looks, and the reason is structural. Shopify's search object returns one flat result set per request and cannot be told to exclude products by tag, so suppression happens inside the render loop after the platform has produced the set. The theme repaints a single-type tab by re-fetching the section rather than holding every type in the DOM, so per-type behavior has to exist in the all-types grid and in the single-type pass. Neither is a bug. That's the shape of the surface, and it's why a search page ends up longer than a collection page.

Moving the result set off Shopify is the largest commitment on this page, and it isn't reversible on a Friday. The storefront depends on an index and an endpoint outside the theme, and that index is a second source of truth that has to agree with Shopify's catalog. Failure behavior is explicit rather than lucky: a non-OK response closes the panel. The templating library is a patched build, so it's a pinned dependency you upgrade deliberately. And ownership moves — when a facet stops returning what a merchandiser expects, that's now someone's job rather than a support ticket.

The merchandising layer has its own coupling. A promo tile triggered by a facet's URL key ties the theme's blocks to the Search & Discovery configuration, so the two have to be changed together. The popdown is instantiated several times on one page, so every id and every ARIA relationship has to be namespaced per instance.

So we advise against building here more often than this page implies. If your catalog is a few hundred products and people search by product name, Shopify's search plus Search & Discovery already answers the question and a custom panel buys you presentation. If you want ranking control and nobody in-house wants to own an index, a hosted search app is the more honest answer than a service you'll under-maintain — and we'd say so before quoting it.

Related Capabilities

• Filters, faceted navigation and progressive grid loading — the same facet objects, on the collection side, and the closest sibling to this page.
• Collection merchandising: rails, tiles and in-grid promotion — where the in-grid promo tile mechanism comes from; the search variant is the simpler fork of it.
• Structured data for AI answers — what a storefront emits so an answer engine can read the same catalog a shopper is searching.
• Mega menu and mobile navigation — the other discovery route out of the header, merchandised by the same team in the same theme editor.

Answers to Help You Make Smart Decisions

Do I need a search app to get good search on Shopify? Usually not. Shopify's own search and Search & Discovery give you an index, facets, sort and a real URL for free, and on two of the three storefronts here that index was kept. What gets built is the surface: type tabs, suppression rules, merchandised empty states and promo tiles. Buy the index when your ranking problem is genuinely an index problem.

Can I hide specific products from Shopify search results? Not before the platform counts them. Shopify's search returns one result set per query and offers no tag exclusion, so a theme has to skip tagged products inside its own render loop. Both storefronts here use the merchandising team's existing tag conventions — hidden, #hidden, no-search — which keeps the rule in the place merchandisers already work rather than in a second admin.

What does it actually cost to move search off Shopify? Ownership. The storefront gains ranking control and loses the ability to shrug when search is wrong. You take on an index that has to stay in agreement with your catalog, an endpoint whose availability is now a storefront concern, and a client-side render step where a Liquid template used to be. We'd only recommend it when Shopify structurally cannot return the unit your shopper is choosing.

Can the search dropdown sell something before anyone types? Yes, and it's cheap. On one storefront here the empty panel renders a merchandiser-managed popular-searches list and two collection carousels, all server-rendered from theme settings and Navigation, so they appear the instant the panel opens with no request. Another carries two limited-time-offer cards inside the results panel. Both are theme-editor controls, not code changes.

Ready to Make Your Search Box Earn Its Place?

Most storefronts treat search as plumbing. It's the one surface where a shopper has already told you exactly what they want. Contact us today and we'll tell you whether your search problem is an index problem or a surface problem — they need very different money.