Semantic search becomes more valuable when a WooCommerce catalog spans multiple product categories. A shopper may search for “a lightweight waterproof option for commuting” without knowing whether the best match is a jacket, backpack, shoe, or accessory. Keyword search usually treats those terms as separate filters, while vector search can compare the meaning of the query with product content across the entire catalog.
Why cross-category search is different
Category-specific search often assumes that the shopper already knows the product type. A query such as “warm layer for cycling to work” can cross category boundaries because the intended solution might be a fleece, softshell jacket, vest, or thermal base layer.
For agencies, this creates two requirements:
- The search index must represent products consistently, regardless of their WooCommerce category.
- The application must preserve useful catalog constraints such as stock status, price range, brand, visibility, and category filters.
Semantic similarity should discover relevant products, but it should not override business rules. A discontinued product should not appear merely because its description is semantically similar.
Designing a product object for cross-category retrieval
A Weaviate collection can store one product representation for all categories. Category information remains available as structured properties rather than being used to create an isolated vector index for every category.
{ "class": "Product", "properties": [ { "name": "productId", "dataType": ["text"] }, { "name": "name", "dataType": ["text"] }, { "name": "description", "dataType": ["text"] }, { "name": "categories", "dataType": ["text[]"] }, { "name": "brand", "dataType": ["text"] }, { "name": "price", "dataType": ["number"] }, { "name": "inStock", "dataType": ["boolean"] }, { "name": "visible", "dataType": ["boolean"] }, { "name": "url", "dataType": ["text"] } ] }The exact schema depends on the Weaviate version and client being used, but the modeling principle is stable: index the searchable product meaning in a shared collection and retain operational attributes as filterable properties.
Building a useful product representation
Embedding only the product name often produces weak results for broad, natural-language queries. A better representation combines the name, category path, attributes, and a concise description. For example:
TrailFlex Waterproof Commuter Jacket. Categories: Clothing > Jackets > Rain Jackets. Features: waterproof shell, breathable fabric, reflective panels, adjustable hood, lightweight construction. Intended use: cycling, walking, and daily commuting.This text gives the embedding model several signals. The product can match “rain jacket for bike commuting” even when the exact words do not appear in the WooCommerce title.
Do not indiscriminately concatenate every field. Internal notes, supplier codes, repeated category labels, and boilerplate shipping text can distort similarity. Build the indexed text from customer-facing information that describes what the product is, who it is for, and how it is used.
Querying across categories
A semantic query can search the shared product collection without requiring the shopper to select a category first. In the Weaviate Python client, a near-text query can be combined with a filter for operational constraints:
response = (client.collections.get("Product") .query.near_text( query="lightweight waterproof gear for commuting by bicycle", limit=12, filters=Filter.by_property("inStock").equal(True) & Filter.by_property("visible").equal(True), return_properties=["productId", "name", "categories", "price", "url"] ))The returned products might include a jacket, backpack, shoe cover, or rain trouser. This is the main advantage of searching across categories: the query expresses a need, while the catalog determines which product types satisfy it.
Adding category filters without losing discovery
Cross-category discovery should not prevent explicit narrowing. If a shopper selects “Bags,” the application can add a category filter while retaining semantic ranking:
category_filter = Filter.by_property("categories").contains_any(["Bags"])</nresponse = (client.collections.get("Product") .query.near_text( query="compact waterproof option for a laptop and cycling commute", limit=12, filters=category_filter & Filter.by_property("inStock").equal(True) ))Use a normalized category identifier when possible, such as a category ID or stable slug. Display names can change, and localized labels may otherwise make filtering inconsistent.
When hybrid search is a better default
Semantic search is strong for intent and paraphrases, while keyword search is often better for exact model numbers, technical standards, sizes, and brand names. WooCommerce catalogs commonly need both.
Hybrid search combines lexical matching with vector similarity. A query such as “USB-C PD 65W charger” contains exact technical tokens that should receive strong keyword weight, while “small charger for a travel laptop” benefits from semantic matching.
response = (client.collections.get("Product") .query.hybrid( query="small USB-C charger for a travel laptop", alpha=0.55, limit=12, filters=Filter.by_property("visible").equal(True), return_properties=["name", "description", "categories", "price", "url"] ))The appropriate alpha value should be evaluated against real searches. A higher vector contribution helps broad intent-based queries; a higher keyword contribution helps exact product terminology.
Handling category intent in the application layer
Some queries contain an explicit category, such as “black running shoes under $120.” The search service can detect or receive that intent separately and apply structured filters for the reliable parts of the request:
- Use semantic or hybrid retrieval for the complete natural-language query.
- Map known catalog concepts such as category, brand, color, and price into structured filters.
- Apply inventory, visibility, and channel restrictions before results reach the shopper.
- Use semantic ranking to order the remaining candidates.
Do not rely exclusively on an embedding to enforce a price limit or stock rule. Those are deterministic conditions and should be represented as filters.
WooCommerce synchronization considerations
A cross-category index is only useful when it reflects the current catalog. Product creation, updates, category changes, visibility changes, and stock transitions should trigger index updates. A typical synchronization flow is:
- Receive a WooCommerce webhook or scheduled change record.
- Load the canonical product and variation data from WooCommerce.
- Rebuild the searchable representation when customer-facing content or taxonomy changes.
- Update structured properties such as price, stock, visibility, and category IDs.
- Delete or deactivate products that are permanently removed from the storefront.
For variable products, decide whether shoppers search for the parent product or individual variations. Index variations separately when attributes such as size, capacity, or color materially affect relevance or availability. Otherwise, index the parent product and expose variation information after retrieval.
Evaluating cross-category relevance
Test with queries that intentionally span product boundaries. Useful examples include:
- “Something warm and packable for a mountain trip.”
- “A gift for someone who makes espresso at home.”
- “Protective gear for commuting in heavy rain.”
- “A compact setup for a small home office.”
For each query, record whether the first results satisfy the underlying need, whether irrelevant categories dominate, and whether unavailable products appear. Measure ranking quality separately for unrestricted searches and filtered searches. Also test exact queries containing SKU fragments, model names, dimensions, and standards to determine whether hybrid retrieval is necessary.
Practical implementation pattern
For most WooCommerce agencies, a robust implementation uses one shared product collection, rich customer-facing text for vectorization, structured filters for catalog rules, and hybrid retrieval for exact terminology. Category navigation can remain conventional, while the search box supports intent-based discovery across the complete catalog.
This approach lets a store answer both “show me hiking jackets” and “what should I wear for a cold, wet day on the trail?” without maintaining separate semantic systems for every category.