Why Keyword Search Fails for B2B Product Catalogs

If you manage a B2B product catalog with more than a few hundred SKUs, you've almost certainly watched a customer type a perfectly reasonable question into your search bar and get back something completely useless. Maybe they searched for "pump seal kit" and got results for "seal point door gasket." Maybe they typed "ASTM A36" and found nothing, because your data team labeled that same material "mild steel." Maybe they asked "what's the maximum operating pressure for the 3-inch valve?" and got a wall of product tiles with no answer in sight.

These aren't edge cases. They're the daily reality for distributors, wholesalers, and industrial suppliers who rely on traditional keyword search to help buyers navigate complex catalogs. And the problem isn't the data — it's the fundamental architecture of keyword matching.

How Keyword Search Actually Works

To understand why keyword search fails, you need to understand what it actually does. Traditional full-text search — whether it's Elasticsearch, Solr, SQL LIKE queries, or the built-in search on most e-commerce platforms — works by indexing the words in your product data and matching those exact words (or their roots) against the user's query.

The algorithm, in its simplest form:

1. Tokenize the query: split "hydraulic pump seal" into tokens ["hydraulic", "pump", "seal"]
2. Stem or lemmatize: reduce "pumping" and "pumped" to "pump"
3. Look up each token in the inverted index
4. Score results using something like TF-IDF (term frequency–inverse document frequency) or BM25
5. Return the top-ranked items

This approach is remarkably fast and works well for consumer search where products are described with natural language. But B2B catalogs have four structural properties that make keyword search actively harmful.

Problem 1: The Synonym Catastrophe

Industrial and technical products live in a world of parallel vocabularies. Your sales team calls it a "solenoid valve." Your catalog says "electromechanical flow control." The manufacturer uses "SOV" in the part number. Your customer types "electrically actuated valve." None of these match.

The B2B synonym problem is qualitatively different from consumer search because the alternative terms aren't just informal language — they're official standards, manufacturer codes, industry abbreviations, and regional variations, all referring to the same thing:

• "O-ring" = "orings" = "toric joint" (French standard) = "NBR seal"
• "Allen bolt" = "hex socket screw" = "cap screw" = "SHCS"
• "PVC" = "polyvinyl chloride" = "Type 1 thermoplastic"
• Wire gauge "AWG 12" = "2.05mm conductor" = "3.3mm² cable" (EU spec)

Keyword search can handle some of this with synonym files — manually maintained lists that map equivalent terms to each other. But these files are expensive to maintain, immediately out of date as new products and standards emerge, and impossible to scale across thousands of product families.

The crueler problem: synonym expansion increases noise. If you expand "valve" to include all its synonyms, you return every valve product regardless of relevance. Precision collapses.

Problem 2: Cross-References and Part Number Chaos

A typical industrial distributor carries products from dozens or hundreds of manufacturers. Each manufacturer has their own part numbering system. A customer looking for a replacement bearing for their machine will give you one of: the OEM part number, their own internal code, the manufacturer's catalog number, the superseded legacy part number, or an industry standard designation.

Consider:

• OEM part: SKFBB-6205-2RS
• Customer's ERP code: BEARING-6205
• Manufacturer catalog: SKF 6205-2RSH
• ISO designation: 6205 ZZ
• Competitor equivalent: NSK 6205DDU

Keyword search treats these as completely different strings. The only way to connect them is a manually maintained cross-reference table — which is exactly the kind of data nobody has time to keep current.

Semantic search models, trained on technical corpora, learn that 6205-2RS, 6205 ZZ, and 6205DDU are all variations of a 25mm bore deep groove ball bearing. The embedding space represents meaning, not characters. The 6205 concept clusters together regardless of the exact string.

Problem 3: Query Intent Gets Ignored

B2B buyers rarely search with simple keywords. They ask questions, describe problems, or specify requirements:

• "What fitting connects 1/2 inch NPT to 3/8 inch BSP?"
• "We need a motor that runs on 480V 3-phase and outputs at least 5 HP"
• "What's compatible with the Grundfos CM5-5 pump?"
• "I need a food-grade lubricant that can handle 180°C"

These queries contain intent (find a fitting), constraints (specific thread standards), compatibility requirements, and functional specifications. Keyword search shreds this information into tokens and discards the relational structure. "1/2 inch NPT" and "3/8 inch BSP" become four separate tokens, each contributing independently to recall — but the relationship between them (adapter, conversion, connector) is what the buyer actually needs.

The result: customers get pages of NPT fittings and BSP fittings, not the adapters they were looking for. They give up and call your sales team. Your sales team answers the same question for the fortieth time that week.

Problem 4: Structured Data in Unstructured Search

B2B product data is fundamentally structured: voltage ratings, pressure ratings, temperature ranges, material specifications, compliance certifications, dimensional data. But keyword search treats everything as undifferentiated text.

When a buyer searches "stainless 316L pressure vessel flange ASME Class 300 16 inch," they're actually specifying five independent dimensions: material (316L), standard (ASME), pressure class (300#), nominal pipe size (16"), and product type (flange). Keyword search can't parse these dimensions — it just looks for documents containing some or all of those tokens.

More insidiously, false positives kill trust. A 14-inch flange mentioning "16-inch compatible" in its description will score high on the query. A buyer who orders the wrong size because of a bad search result loses confidence in your platform and picks up the phone instead.

What Semantic Search Actually Fixes

Semantic search, powered by vector embeddings and approximate nearest-neighbor retrieval, attacks these problems at the architectural level.

Instead of matching words, semantic search represents both documents and queries as vectors in a high-dimensional space (typically 768–1536 dimensions for modern embedding models). Documents with similar meaning cluster near each other in this space, regardless of the exact words used.

This is how it addresses each failure mode:

Synonyms: The embedding model learned during pre-training that "solenoid valve," "electromechanical flow control," and "SOV" refer to the same concept. They'll cluster near each other in the vector space. No manual synonym file required.

Cross-references: Part number variants, especially those with shared technical specifications, will cluster near each other if the model was trained on enough technical data. Even zero-shot, a model embedding "SKF 6205-2RSH" and "NSK 6205DDU" will place them closer together than, say, "SKF 6205-2RSH" and "SKF 6309."

Query intent: Embedding models encode sentence-level meaning. "What fitting connects NPT to BSP?" encodes the adapter/conversion intent alongside the thread standard tokens. The query embedding will naturally cluster near adapter product descriptions.

Structured specifications: When combined with metadata filtering, semantic search can respect structured dimensions while using embeddings for the fuzzy matching. Filter on nominal_size: 16 (exact match), then use embeddings to rank the remaining results by semantic similarity.

The Hybrid Approach: When to Use Both

Pure semantic search has its own failure modes. For exact part number lookup, semantic search is overkill — a customer typing SKF-6205-2RSH wants that exact part, and fuzzy matching could surface the wrong item. For regulatory lookups ("ASTM A276 grade 316"), the exact standard number matters and semantic fuzziness could lead to dangerous substitutions.

The production-grade solution is a hybrid retrieval pipeline:

1. Lexical retrieval (BM25 or exact match): High precision for exact part numbers, SKUs, and standard designations
2. Semantic retrieval (vector search): High recall for intent-based, synonym-heavy, and natural language queries
3. Reciprocal Rank Fusion (RRF): Merge the two result sets, giving higher weight to items that rank well in both

This hybrid approach combines the precision of keyword matching with the recall of semantic understanding. It's what production RAG systems like Axoverna use under the hood.

The Practical Test

Here's a quick test to diagnose your current search quality. Take ten real queries from your customer support tickets or sales team — the kinds of questions buyers ask over the phone. Run them through your current search. Count how many return the right product in the top 5 results.

In our experience with B2B catalogs, keyword search typically scores 40–60% on this test. After implementing semantic search with a hybrid pipeline, that number typically jumps to 75–90%. The delta represents customers who were giving up and calling your team — or your competitors.

The math is simple: if your catalog has 50,000 products and 15% of queries fail to find the right item, and each failed query costs you one support call ($15–25 average in B2B) or one lost sale (average B2B order value: $800+), the ROI of better search pays for itself in weeks.

Getting There Without Rebuilding Everything

The good news: you don't need to replace your entire e-commerce platform. Modern semantic search can be layered on top of your existing catalog as a parallel retrieval layer. Your product data stays where it is; the search layer retrieves from the embedding index and either re-ranks or augments your existing results.

The components:

1. Embedding pipeline: Generate vector representations of your product data (title, description, specifications, part numbers)
2. Vector store: Store and index the embeddings (pgvector, Pinecone, Weaviate — see our comparison →)
3. Query processing: At search time, embed the user's query and retrieve nearest neighbors
4. Hybrid merge: Combine semantic and lexical results with RRF
5. Answer generation (optional, for conversational search): Feed retrieved products into an LLM to generate a direct answer

Platforms like Axoverna handle all five steps, with ingestion pipelines for your CSV, API feed, or PDF catalog. The typical time from data to live semantic search is measured in hours, not months.

---

B2B search has been mediocre for decades because the volume of specialised, technical, multi-vocabulary data was too high for manual curation and the tools weren't there to do better. That changed when large language model embeddings became cheap enough to run at catalog scale. The buyers who type "480V 3-phase 5HP motor" into your search bar deserve to find what they need. With semantic search, they can.

Try Axoverna free → Start transforming your catalog search today