Noam Naveh
CEO @Stylib
Somewhere between 20 and 30% of searches on a textile manufacturer’s site are for a string that already exists in the catalogue. A collection name, a pattern, a code. Text matched against text, right page returned.
The rest are searches the site has no field for. Teal, when the fabric is called Lagoon. 100,000 rubs, when the field is called Martindale. Match protection, when the attribute is called Crib5.
The customer can name what they want perfectly well. The site just has nothing to match it against.
Where the data sits tells you when the site was designed
Open a manufacturer site and look for composition, rub count, fire rating, cleaning code.
If they are attachments hanging off a product page, a spec sheet, a downloadable table, a line of small print under the swatch, then that site was built to display a catalogue rather than to interrogate one. The technical layer arrived later. It was added because it had to be available, for compliance, for tender packs, for the customer who asks. Nobody expected it to become the way in.
That is a design decision, though I doubt it felt like one at the time. The site was structured around collections because collections are how the business is organised internally. Product data followed the org chart.
And this isn’t a textiles quirk. Baymard Institute’s benchmark found 38% of e-commerce sites still don’t offer filters for information they already display in their own product listings. In 2015 it was 42%. Nearly a decade, four points. The data is right there on the page. The site just can’t be asked about it.
Meanwhile the person arriving changed what they came for
The lookup assumption was reasonable, once. A rep had left a folder. A sample had been approved on a previous project. The website was where you confirmed a decision that had effectively been made elsewhere.
That’s not the trip any more. CADdetails’ 2026 survey of AEC professionals found most begin product research on manufacturer websites, and that performance and spec compliance sit alongside budget as the dominant decision factors. Read those two findings together and you have the whole problem in a sentence. People arrive early, and they arrive with criteria rather than names.
So the query turns up as a combination. Mid-weight upholstery, contract abrasion, passes Crib 5, close to this teal, available in Europe on a sane lead time. Five conditions, not one of them a product name, at least three of them living in a PDF.
Two reasons this keeps happening
The first is a vocabulary assumption. Someone decided, reasonably, that customers would search using the words the company uses. So the synonym list is thin, or there isn’t one, because why would you need to map language a customer surely already speaks?
They don’t speak it. And the search engine underneath doesn’t either, which is the part I find more interesting. Almost every site search on a manufacturer site is a general purpose, industry agnostic engine. It has no idea what Crib 5 is. It doesn’t know that EN 1021 and BS 5852 are answers to related questions, that Martindale and Wyzenbeek measure the same property on different scales, that “wipe clean” and a bleach cleaning code are the same enquiry from two different people. To an agnostic engine those are just strings. To a specifier they’re the entire enquiry. Vertical knowledge isn’t a nice-to-have here. It’s the difference between matching characters and understanding a question.
The second reason is more basic, and it’s usually the real one. The product data isn’t structured. In a lot of cases it doesn’t meaningfully exist on the site at all. It’s in the PDF, the swatch card, the ERP, the technical manager’s spreadsheet, someone’s head. Nothing to filter, nothing to rank, nothing for even a very good search engine to work with.
Which is why better keywords only ever get you so far. A synonym can only match a field that exists. If the rub count is a number inside an attachment, no amount of query rewriting turns it into something searchable. You’re improving the interpretation of a question the system still can’t answer.
The uncomfortable version: most manufacturers don’t have a search problem. They have a product data problem that only becomes visible at the search box.
And nothing about it looks broken. The customer types something, gets thin results, falls back to browsing collections, finds something reasonable. No error, no complaint, no bounce you’d flag. What they never see is the fabric two collections over that met every condition and simply never surfaced.
The data is nearly all there. It's sitting one layer below the thing doing the searching.
That gap is what we work on at Stylib. Getting the technical data into a state the site can actually use, and putting search on top of it that understands what a specifier is asking, so more than a fifth of the queries come back with something worth clicking.
Sources: Baymard Institute, filter list design benchmark; CADdetails 2026 AEC survey
With visual search built into your website, clients can upload a reference image- a texture, colour, or product photo and instantly see the most visually similar items from your catalogue. It’s a faster, more intuitive way for architects and designers to explore your range without relying on perfect keywords.
SearchTech understands what people mean, not just what they type. Whether a user searches for “warm-toned outdoor tile” or “eco-certified wall panel,” the system interprets intent and delivers accurate, relevant results, even when product titles or tags don’t match exactly.
SearchTech integrates directly into your site, using your existing product data. There’s no need for redirects or external logins, just a fast, branded search experience that keeps users on your site, engaged, and closer to specifying your products.
