Act IV: The Joinery
Carrying Weight Shopify Should Have Removed
An hour or two into the discovery workshop, after the cart questions and the catalog questions and the long detour about how returns are supposed to work, the conversation reaches search and merchandising, and the room answers almost before the question has finished leaving anyone’s mouth. We’ll add Algolia. It is said the way you’d name the obvious—the way you’d say you’ll bring an umbrella because it’s raining. Heads nod. Someone writes it on the board. The head of digital, who heard a very good vendor pitch about three weeks ago and has been waiting for a reason to say the name out loud, feels a small private satisfaction at having the answer ready.
Nobody in the room is wrong, exactly. Algolia is a serious product built by serious people, and the brands that run it well do real things with it. But nobody has asked what adding Algolia actually means on Shopify, and the gap between what that phrase sounds like in a workshop and what it turns into in a codebase is the entire subject of this chapter. The phrase sounds like installing an app. It is not installing an app. We will get to what it is. First we have to be honest about the thing the room is trying to escape, because the reflex to escape it is reasonable, and the platform earned the reflex fairly.
Shopify’s native search and merchandising stack is more capable than most brands expect—and less capable than most enterprise brands need. Both halves of that sentence are true at the same time, and holding them at the same time is the only way to make a good decision here. The brands that get this wrong get it wrong by believing only one half. The ones who believe only the first half ship native, hit a wall in month four, and bolt on a vendor in a panic. The ones who believe only the second half—and the head of digital with the fresh vendor pitch is squarely in this camp—skip the native stack entirely, on the assumption that an enterprise brand obviously needs enterprise search, and pay for a workaround to a problem they might not have had.
So before anyone adds anything, it is worth knowing precisely what the native stack is, because precisely is where the surprises live. It has three layers, and each has a real ceiling worth naming by name.
The first layer is Collections, which come in two flavors. Manual collections are exactly what they sound like: you put products in by hand, you drag them into the order you want, done. Smart collections build themselves from conditions—tag equals gift, price under forty, type is olive oil—and keep themselves current as the catalog changes. Smart collections are where the first ceiling lives, and it is a low one. The conditions combine with AND, or they combine with OR, but never both in the same collection; there is no nesting, no these two together and also this third thing. There is no NOT—you cannot say everything in this category except the discontinued line. And a smart collection can decide what goes in, but it cannot decide what order things come out in beyond a handful of preset sorts. Filter, yes. Reorder by your own logic, no. For a brand whose merchandising strategy is put the high-margin gift sets first in November, that last limitation is not a footnote. It is the whole job, and the platform doesn’t do it.
The second layer is Search & Discovery, and it is the most underrated piece of the native stack—underrated mostly because the people reaching for Algolia stopped evaluating Shopify’s search around 2021 and never went back. It has quietly become good. Semantic search works out of the box now, which means a shopper typing something for my dad who likes spicy food lands on the chili oil without anyone having tagged the chili oil with the word dad. Autocomplete surfaces products and collections and blog posts and suggested queries together, in one dropdown, configured rather than coded. Filter facets are built from your metafields and metaobjects, and—this matters more than it sounds—they work natively across multiple languages, so the German storefront’s filters are in German without a translation pipeline you have to own. A surprising number of brands who think they need a search vendor need to spend an afternoon actually configuring Search & Discovery first. Some of them, after that afternoon, discover they were done.
But not all of them, because the native ceilings here are real, and they are exactly the ceilings an enterprise catalog runs into. Synonyms are equivalents-only: you can tell the engine that sneaker and trainer mean the same thing, which is two-way, but you cannot say a search for “gift” should also surface “gift sets” but not the reverse—there is no one-way mapping, no asymmetric weighting. Personalization is zero; the engine shows the same results to the loyal customer and the first-time visitor and makes no use of what either has done before. Analytics are thin—you can see what people searched, but the loop from what they searched to what you should change is mostly yours to build by hand. And the Recommendations API, the third layer, gives you related and complementary products computed from catalog relationships and order history, but it has no concept of context: it cannot look at what is in the cart right now and recommend accordingly. It recommends based on the product, not the moment. For a brand whose entire upsell strategy is what goes with what’s already in the basket, that is the difference between a feature and a decoration.
Now we can say plainly what the head of digital’s vendor was actually selling, and why the workaround exists at all. Because here is the thing that the workshop conversation never reaches, and the thing that determines everything downstream: Shopify has no server-side hook for overriding search results or collection ordering at the platform level. There is no place in the request, before the page renders, where your code gets to say for this query, return these products in this order. The platform decides; you don’t get a turn.
Sit with that, because it is the root of the whole situation and the constraint shapes everything about how the integration works in practice. Every enterprise search vendor on Shopify—Algolia, Nosto, Constructor, the whole category—is a client-side workaround in disguise. They cannot live where the search actually happens, because Shopify won’t let anything live there. So they live alongside it instead: a parallel JavaScript layer that loads in the browser, intercepts the shopper’s query before it reaches Shopify, sends it to the vendor’s own index, gets the vendor’s own results, and paints them over the page Shopify was going to render. The collection page you styled in the theme editor is, on these setups, partly or wholly replaced at runtime by markup the theme editor has never heard of. Search lives outside the theme. It often lives outside the app ecosystem’s normal surfaces too. It is a second storefront, wearing your first storefront’s clothes, stitched on in the browser where Shopify can’t object.

The vendors are not wrong to do this. Let us be very clear about that, because it would be easy to read all of this as the vendors are bad and that is not the argument. They are solving a real problem—enterprise merchandising and relevance that the native stack genuinely cannot deliver—with the only primitives Shopify gives them, which are bad primitives for the job. They did not choose the client-side architecture out of laziness. They chose it because it is the only door that isn’t locked. The weight they’re carrying is weight Shopify should have removed by now, by exposing a server-side hook, and hasn’t. Until it does, the vendors will keep carrying it, and so will you, because once that parallel layer is in your storefront it is yours to maintain, debug, and reconcile with every theme change for as long as it lives there.
There is one product in this category that does not work this way, and it is worth naming for the same reason the others are: specificity is the only honest way to have this conversation. Depict is the exception. Instead of standing up a parallel client-side storefront, it works within Shopify’s native rendering model—it applies merchandising rules to Shopify’s own collections, reordering the products in the collection Shopify is already going to render, rather than replacing the render wholesale. The practical consequence is large: the integration burden that defines the rest of the category largely disappears. Your collection pages are still Shopify’s pages. Your theme still owns them. There is no second storefront painted over the first, no parallel index that can drift, no SDK in the critical path quietly deciding your Largest Contentful Paint.
The cost of that grace is that Depict is doing less. It is a merchandising layer, not a search engine—it makes Shopify’s collections smarter, but it does not bring ML-driven semantic search or behavioral personalization to the table, because those things require exactly the parallel-index architecture it declined to build. So it is not a competitor to the heavy vendors so much as a different answer to a different question. If your gap is I cannot merchandise my collections the way I need to, Depict closes it cheaply and cleanly. If your gap is my search relevance is a revenue problem and I need a real engine, Depict is not the tool, and you are back among the client-side vendors, carrying the weight, because that is where the weight currently has to be carried.
Which gives us, finally, the decision—and it runs in the opposite direction from the workshop. The workshop runs enterprise brand, therefore enterprise search. The decision runs the other way, from the bottom up, and it has three steps.
First, exhaust Search & Discovery. Actually exhaust it—sit down, configure the semantic search, build the facets from your metafields, set up the synonyms you can, and ship it. Live with it on a real catalog with real traffic for long enough to know where it actually fails for your shoppers, not where a vendor’s deck says it fails in general. A meaningful share of brands stop here and are right to.
Second, if where it fails is collection management—if the thing you cannot do is merchandise the way your strategy demands, but your search relevance is basically fine—reach for a Depict-style layer that works inside the native model. You get the merchandising control without buying the entire integration tax.
Third, and only third, go to full enterprise search—and go only when the requirements are real and present-tense. Not we might want personalization someday. Present-tense means: you are running genuinely multi-market and need relevance tuned per market; you have a team that will own the merchandising dashboard as an actual job, not a thing someone touches twice a year; and search relevance is demonstrably a revenue problem you can point at in the analytics, not a feeling. Reach for the heavy vendor because the gap is real, here, now—not as insurance against hypothetical future needs. That is how expensive integrations get greenlit on assumptions that never materialize, and you have heard, by now, what kind of mistake that is: the requirement you inherit is not always the requirement you have, and the requirement a vendor flatters you into imagining is not one you have at all until the analytics say so.

The reason any of this is worth a chapter—the reason it isn’t just read the docs and pick a tool—is that the cost has changed. On a small storefront, a client-side search layer is a manageable indulgence; the traffic is modest, the catalog is small, the maintenance is somebody’s Tuesday. At enterprise scale, the same workaround is a standing line item with a standing owner and a standing performance budget, and the workarounds that simpler storefronts could absorb quietly are now appearing in conversations about platform ROI—the CFO asking, two years in, why the thing that was supposed to simplify the stack added a vendor, a pipeline, and a second merchandising system nobody outside the digital team can use.
So the question to carry out of the workshop is not the one the room reached for. It is not which vendor has the best feature set. It is whether your organization has the business case, the team, and the architectural clarity to absorb a workaround the platform should have made unnecessary by now—and whether, before you sign for the heaviest version of it, you have spent the cheap afternoon finding out how much of your search problem Shopify already solves. You owe yourself the afternoon. The vendor will still be there after lunch.