Most teams assume that if a product exists in the catalog, search will eventually surface it. In practice, that assumption breaks down fast once a catalog crosses a few hundred thousand SKUs. Web Squalix took on a headless Adobe Commerce implementation with well over 300,000 SKUs and roughly 4,500 daily orders, and the first thing our engineering team noticed while reviewing search logs was a pattern that showed up again and again: customers with strong, obvious purchase intent were landing on empty result pages. They knew the part they needed. The platform just could not understand what they were asking for.
Why Search Breaks Down in Large Adobe Commerce Catalogs
Search feels simple from the outside, which is exactly why it gets underestimated during platform planning. A small catalog can survive on basic keyword matching because there is not much room for ambiguity. Once a catalog grows past a hundred thousand SKUs, product naming conventions multiply, manufacturer codes stop matching internal SKU formats, and customer search behavior becomes far more varied than any single indexing strategy anticipates. Web Squalix approaches search as its own discipline within ecommerce architecture, not a checkbox feature bolted onto the storefront, because at scale it behaves less like a lookup tool and more like a translation layer between how customers think and how the catalog is actually structured.
The Three Search Failures Costing Ecommerce Businesses Revenue
When Web Squalix audited the client's search logs against the /catalogsearch/result page in Google Analytics, three distinct failure patterns kept surfacing. Each one looked different on the surface, but all three shared the same root cause: the default Elasticsearch configuration inside Adobe Commerce was built for exact and prefix matching, not for the messy, human way people actually search.
Partial SKU Searches That Return Nothing
Customers rarely type a full manufacturer SKU. A shopper searching for 452XYZ has no way of knowing the catalog stores that same product internally as MFG-452XYZ. To a person, those are obviously the same item. To a default Elasticsearch index relying on prefix logic, they are two unrelated strings, and the search simply fails. This is one of the costliest failure modes in ecommerce search because a shopper typing a partial SKU has almost certainly already decided to buy. Losing that query is not a minor inconvenience, it is direct revenue leakage at the exact moment a customer was ready to check out.
Compatibility Queries Elasticsearch Was Never Built to Interpret
Automotive and parts catalogs introduce a layer of complexity that generic ecommerce search was never designed to handle. A query like ford fiesta oil filter reads as one coherent request to a human being, but a standard Elasticsearch setup tokenizes it into four independent keywords and matches each one separately. The result is a page full of generic oil filters with no regard for whether they actually fit a Ford Fiesta, even though the compatibility data existed in the catalog the entire time. The information was there. It just was not structured in a way the search engine could use to reason about fitment.
Fuzzy, Misspelled, and Inconsistently Typed Search Terms
Real customers do not type like a product manager filling out a spreadsheet. The same product might be searched as brakepad, break pads, or breakpad within the same hour, and a rigid keyword index treats each variation as a completely different query. Traditional configurations struggle badly here, and the outcome is predictable: a customer who knows exactly what they want hits a zero result page and assumes the store simply does not carry it.
Why Elasticsearch Alone Could Not Solve This
The first instinct on most engineering teams is to patch the problem with wildcard queries, something like *452XYZ*, and that does technically solve partial SKU matching. Web Squalix tested this approach early and ruled it out for production use once the performance implications became clear. Wildcard queries force the search cluster to scan a much larger portion of the index for every single request, and across a catalog with hundreds of thousands of SKUs and thousands of daily searches, that load becomes unsustainable. There was a second, quieter problem too: Elasticsearch on its own offered almost no behavioral analytics, which meant the team had no visibility into which queries were failing, which searches converted, or where customers were dropping off. Improving relevance under those conditions meant manual log analysis every single time, which does not scale as a long term strategy.
- Wildcard search patches partial matching but multiplies compute cost across the entire index.
- Standard Elasticsearch configurations offer no native view of zero result searches or search driven conversions.
- Without behavioral data, every relevance improvement becomes a guess rather than a measured decision.
- Compatibility logic requires structured, cacheable attributes, not raw text tokenization.
How Web Squalix Engineered a Smarter Search Layer With Adobe Live Search
Rather than continuing to extend Elasticsearch with workarounds, Web Squalix moved the client onto Adobe Live Search and rebuilt the surrounding architecture to actually take advantage of it. Live Search brought flexible token matching and fuzzy resolution as native capabilities, which meant a query like 452XYZ could correctly resolve to MFG-452XYZ without the cost of wildcard scanning. That single change alone recovered a meaningful share of previously failed high intent searches. But Web Squalix treats platform migration as an opportunity to fix the surrounding system design, not just swap one search engine for another, so the team also restructured how compatibility data and merchandising rules fed into the new search layer.
- Migrated the search backend to Adobe Live Search with fuzzy and flexible token matching enabled by default.
- Modeled vehicle make, model, and variant data as dedicated, cacheable product attributes exposed directly to search.
- Introduced a hybrid ranking strategy, using default Live Search relevance globally and pinned results only for high value categories.
- Instrumented the Live Search dashboard to give the client's team ongoing visibility into top queries, zero result searches, and product engagement.
Solving Compatibility Search Without Rebuilding the Catalog
One constraint the client was firm about from the start was that a full catalog rebuild was off the table. Web Squalix designed the compatibility fix to work with the existing data model instead of against it. Vehicle make, model, and variant information already existed in the catalog, so the team exposed it as structured attributes to the Live Search layer and cached that data aggressively, since compatibility information rarely changes day to day. Once that was in place, a query like ford fiesta oil filter stopped returning generic results and started returning products actually compatible with that vehicle. It is a good example of what we mean when we say Web Squalix solves problems with the data a business already has, rather than pushing clients toward expensive re-platforming just to fix a search relevance issue.
Fixing Product Ranking So Best Sellers Do Not Get Buried
Once Live Search started returning broader, more relevant results, a second and less obvious problem appeared. A query like engine oil now returned technically correct results, but the store's best selling, highest margin SKUs were often buried several rows down the page, well below products that were relevant but far less likely to convert. Configuring ranking rules across hundreds of categories individually was not realistic from a maintenance standpoint, so Web Squalix adopted a hybrid approach instead: default Live Search relevance handled the long tail of the catalog automatically, while pinned and boosted results were reserved specifically for the categories that mattered most to revenue. This kept the system scalable without sacrificing control over the products that actually moved the business forward.
"Relevant results are only half the job. If your best selling SKU is buried on row four, the search engine technically worked and the business still lost the sale."
The Business Results After Web Squalix Deployed Live Search
Adobe Live Search went live on December 17, 2025, and Web Squalix tracked performance closely in the following weeks using the Live Search dashboard alongside Google Analytics. In the eight weeks after launch, the platform recorded 531,327 unique searches, a click through rate of 75.56 percent, and a zero result rate of just 1.99 percent, a sharp drop from where the store had been operating before. Comparing the window before and after deployment made the impact even clearer.
- Search result page views grew from 613,719 to 858,033, an increase of roughly 40 percent in overall search engagement.
- Search session key event rate improved from 1.47 percent to 1.68 percent, a relative gain of about 14 percent in conversions tied directly to search.
- Zero result searches dropped to 1.99 percent across more than half a million unique queries during the observation window.
- Click through rate on search results reached 75.56 percent, indicating that customers were finally finding what they typed in for.
Inside the Headless Architecture Web Squalix Built Around Live Search
None of these gains would have held up under real traffic without solid architecture behind them. The platform runs headless, with a React frontend communicating to Adobe Commerce through GraphQL. Web Squalix built a dedicated LiveSearchProcessor that a custom resolver routes every search request through, and the processor checks cache before doing anything else. A cache hit returns results immediately. A cache miss triggers a call to the Live Search API, and that response gets cached for future requests, which keeps repeat queries fast without hammering the API on every page load.
From there, the system layers in everything a raw search response is missing: category data, brand tier information, product breadcrumbs, and any active coupon pricing. Each of these is checked against its own cache before falling back to a database call, and all of it is merged before the final ProductSearchResponse goes back to the frontend, fully enriched with product data, brand information, special pricing, and breadcrumb context. Web Squalix designed this specifically so that none of these supplemental lookups block the primary search response, because a slow secondary call should never be the reason a customer waits on a results page.
- GraphQL request enters through a custom resolver that routes it into the LiveSearchProcessor.
- Cache is checked first, with a miss triggering a Live Search API call and caching the result for reuse.
- Category, brand tier, and breadcrumb data are each checked against cache independently before falling back to the database.
- All enriched data is merged and returned as a single, complete response to the React frontend.
Engineering Lessons Web Squalix Applies to Every Large Catalog Project
Every ecommerce search project teaches something reusable, and Web Squalix carries these lessons forward into every large catalog engagement we take on afterward. Search analytics have to be reviewed on a regular cadence, not just checked when a client complains, because high impression, zero result keywords represent ongoing revenue leakage that compounds quietly month after month. Attribute data has to be clean and well structured before boosting or pinning rules can do anything meaningful, since ranking logic is only as good as the data feeding it. And supplemental data calls, things like brand tiers or coupon pricing, should never be allowed to sit on the critical path of a search response, because customers will not wait around for a slow secondary lookup when the primary result is what they came for.
- Review search performance reports on a monthly cadence to catch high impression, zero result queries before they compound into lost revenue.
- Keep product attribute data clean and consistent so merchandising rules like boosting and pinning behave predictably.
- Never let supplemental data calls block the delivery of core search results to the customer.
- Treat search as a measurable, ongoing discipline with real KPIs, not a one time configuration task.
Why Businesses Choose Web Squalix to Fix Ecommerce Search
Search relevance problems rarely announce themselves loudly. They show up as a slow erosion in conversion rate, a rising bounce rate on the results page, and customer support tickets asking why a product is not in stock when it actually is. Web Squalix specializes in diagnosing exactly this kind of problem inside large scale Adobe Commerce platforms, using real behavioral data instead of guesswork, and engineering fixes that hold up under production traffic rather than looking good only in a demo environment. Whether the underlying issue is search, catalog architecture, checkout performance, or the broader headless commerce strategy behind a storefront, our team builds solutions around the business outcome first, the technology second, which is exactly why clients bring us in when generic platform defaults stop being good enough.
Manpreet drives the company’s vision, strategy, and growth, building strong teams and partnerships while helping clients turn ambitious ideas into innovative, scalable digital solutions.
