OpenCart product search

Why OpenCart search returns nothing, and what to do about it

A shopper types the name of a brand you stock and gets an empty page. They type the name of a department that is in your own menu and get an empty page. They mistype one letter and get an empty page. None of this is broken. It is what the code does, and knowing precisely what it does makes the fix obvious.

What OpenCart search matches

It is shorter than people assume. The search term is split on spaces, and each word becomes a substring match against the product name. Those per-word conditions are joined with OR, so any one of them matching is enough.

On top of that, and only that:

  • the description, matched against the whole phrase, and only when the shopper asks for it;
  • the product's tags, per word, again with OR;
  • an exact match on the model, and a prefix match on the other identifier codes.

That list is the whole of it, on OpenCart 4.0.2.0 and on 4.1 alike. The releases differ in where the identifier codes are kept (columns on the product in 4.0.2.0, a separate product-code table in 4.1), and in nothing that a shopper can see.

The two things that are not in that list

Manufacturer names. There is no join to the manufacturer table in the search query at all. A store can have a brand in its navigation, on its product pages and in its advertising, and a shopper who types that brand into the search box gets nothing, because the only place the software looks is the product name, and most shops do not put the brand in every product name.

Category names. Same story. Filtering by a category is done by id from a listing page; searching for the word is not a thing the query does. Somebody typing the name of a department that appears in your own menu gets an empty page from your own search box.

These two account for most of the genuinely empty results in a normal catalogue, and neither is a misconfiguration you can fix in settings.

Why it is noisy and empty at the same time

The OR is the reason a search feels wrong in both directions at once. Type red wool jumper and you get everything red, plus everything wool, plus every jumper: three broad sets glued together, with the thing you wanted somewhere inside. The search did not fail; it succeeded three times.

Then the substring matching adds its own noise from the other end, because a match anywhere in the name counts. Short words are the worst offenders: a three-letter query lands inside plenty of longer words that have nothing to do with it.

And it runs in one direction only. A shopper who types the plural of a word you sell in the singular is looking for a string your product names do not contain, and gets nothing, while the shopper who types the singular finds the plural without trouble. That asymmetry surprises people every time.

Nothing forgives a typo

There is no fuzzy matching anywhere in the query. One transposed letter and the substring is simply not present, so the result is empty rather than degraded or approximate.

This matters more than it sounds, because it is invisible. A shopper who mistypes does not file a support ticket; they assume you do not stock it and they leave, and nothing anywhere in your admin records that it happened.

The fixes, and what each one costs

Put the brand in every product name

Works immediately, because the name is what search reads. It also lengthens every product title on every category page, in your page titles and in any shopping feed you produce, and it has to be maintained for every product you ever add. Plenty of stores do it. Few of them chose to.

Load the tags field

Tags are searched, so synonyms and brand names put there are found. The cost is that tags are per product and per language: an assortment of any size turns this into a maintenance job that gets skipped, and a synonym list scattered across four thousand products is one nobody can read back or change centrally.

Turn on description searching

It is a setting, so it is tempting. It matches the whole phrase against the description, which means it rarely helps with the multi-word queries people type, and when it does help it drags in every product that merely mentions the word in a paragraph of prose. It trades empty results for irrelevant ones.

Replace the search

The real fix, and the one worth being careful about, because search extensions differ enormously in what they take over. The question to ask is whether the thing reorders your results. A relevance-scored search is a different product with different consequences from one that finds a better set and leaves the order alone, and which of those you want is a decision about your catalogue rather than a feature comparison.

First, find out what they typed

Before any of this: nothing in OpenCart records search terms. You cannot tell how often your search comes back empty, or on which words, which means every judgement above is being made blind.

That is the thing to fix first, whichever route you take afterwards. The twenty words your shoppers type and your catalogue cannot answer are a much shorter and much more specific list than any general improvement, and they are usually answerable one by one.

This is what we built Product Search for. Every word has to match, across the name, the tags, the manufacturer and the names of the categories a product is filed under; synonym groups you author; misspellings corrected against your own catalogue's words; products you pin in front of a given search. Then it writes down what shoppers typed and what came back empty. It does not reorder your results: within the set it finds, the order stays OpenCart's own. What Product Search does, and where it stops.