Keyword search works well when shoppers know the exact product name, SKU, or attribute value. It becomes less effective when they describe an intent, use unfamiliar terminology, or search with a phrase such as “a lightweight jacket for wet city commutes.” Meaning-based search addresses this gap by representing product content and shopper queries as vectors, then retrieving products whose meanings are close in the vector space.
What meaning-based product search does
A semantic search workflow converts both product records and search queries into embeddings. An embedding is a numerical representation of text generated by a model. Products with related descriptions tend to have vectors that are close together, even when they do not share the same words.
For example, a catalog may contain a product titled “Water-Resistant Urban Shell,” while a shopper searches for “rain jacket for cycling to work.” A keyword query may find only the words that overlap. A vector query can identify the relationship between rain protection, commuting, and the product description.
For WooCommerce, the searchable representation should normally include the product name, long description, short description, categories, tags, attributes, and carefully selected custom fields. Combining these fields gives the embedding enough context to represent the product accurately.
Preparing WooCommerce product content
Do not send raw HTML, repeated boilerplate, or every internal field into the embedding model. Build a normalized document for each product and make the content predictable.
Product: Lightweight Waterproof Commuter Jacket
Category: Jackets
Attributes: Packable, breathable, reflective details
Description: A waterproof shell designed for cycling and walking in wet weather.
Use cases: Urban commuting, travel, spring and autumn rainProduct availability, price, stock status, brand, and taxonomy terms are usually better stored as structured properties rather than embedded only in the text. This allows the search query to apply exact filters after or alongside semantic similarity.
Remove duplicated descriptions, navigation text, tracking parameters, and markup that does not describe the product. If variable products have materially different sizes, materials, or use cases, decide whether to index the parent product, each variation, or both. Indexing variations can improve precision, but it increases synchronization and deduplication work.
Defining a Weaviate collection
A collection can contain the product text used for semantic search together with metadata used for filtering and display. The exact client syntax depends on the Weaviate SDK version, but the conceptual schema is similar to the following:
Product {
wooCommerceId: int
name: text
content: text
slug: text
productUrl: text
categories: text[]
brands: text[]
price: number
inStock: boolean
visibility: text
imageUrl: text
}Configure vectorization for the field or fields that represent the product. Keep the WooCommerce product ID and other operational identifiers as properties so a result can be mapped back to the canonical store record. If your architecture manages vectors externally, store the resulting vector with the object instead of relying on Weaviate’s automatic vectorizer.
Running a semantic query
A nearText query searches for objects close to the meaning of the supplied concept. A distance or certainty threshold is important because the nearest products are not automatically relevant enough to show. The appropriate threshold should be measured against real catalog queries rather than selected arbitrarily.
const response = await collection.query.nearText('lightweight clothing for cycling in heavy rain', {
limit: 12,
returnProperties: ['name', 'productUrl', 'price', 'inStock', 'imageUrl'],
filters: collection.filter.byProperty('inStock').equal(true)
});Use the SDK and query syntax that match the Weaviate version deployed by your agency. In production, validate every generated query and avoid passing unchecked user input into filters or other query options.
Combining meaning with WooCommerce filters
Semantic similarity should not replace deterministic commerce rules. A shopper searching for “black running shoes under £120” expects both conceptual relevance and exact constraints. Store colour, size, price, stock, brand, and category as filterable properties.
const filter = collection.filter
.byProperty('inStock').equal(true)
.and(collection.filter.byProperty('price').lessThanEqual(120))
.and(collection.filter.byProperty('categories').containsAny(['Running Shoes']));
const response = await collection.query.nearText('black running shoes', {
filters: filter,
limit: 24
});Whether a colour should be a structured property or remain in the text depends on catalog quality. For important facets, structured data is safer. A product can be semantically related to “black shoes” because its description mentions black as an alternative colour, even when the selected variation is not black. Variation-aware filtering prevents this type of mismatch.
Using hybrid search for exact terms
Vector search is strong at intent and paraphrases. Keyword search is strong at SKUs, model numbers, technical codes, and exact brand names. Hybrid search combines both signals and is often the best default for a WooCommerce catalog.
For example, “AB-400 waterproof commuter bag” contains an exact model identifier and descriptive intent. A hybrid query can match the identifier lexically while using vector similarity to rank related product language. Tune the balance between the keyword and vector components with representative searches from the store’s analytics data.
const response = await collection.query.hybrid('AB-400 waterproof commuter bag', {
alpha: 0.65,
limit: 12,
filters: collection.filter.byProperty('inStock').equal(true),
returnProperties: ['name', 'productUrl', 'price', 'imageUrl']
});The meaning of alpha and the available options can vary by Weaviate release and client library. Test the deployed version’s behavior and document the chosen weighting for the project.
Keeping vectors synchronized with WooCommerce
Indexing is an integration problem as much as a search problem. A practical synchronization process should:
- create or update the Weaviate object when a product becomes searchable;
- re-embed the product when searchable text, taxonomy, or important attributes change;
- update filter properties when price, stock, visibility, or categories change;
- remove or mark products unavailable when they are deleted, trashed, hidden, or excluded from the catalog;
- record the Weaviate object ID and embedding version for troubleshooting and reindexing.
WooCommerce webhooks or WordPress actions can trigger updates, but the handler should enqueue a background job rather than block the admin save request while an embedding is generated. Use an idempotent job keyed by the WooCommerce product ID. If several edits occur quickly, coalesce them so the final product state is indexed once.
Designing the storefront search flow
At request time, normalize the query, identify explicit constraints where appropriate, and send the remaining natural-language intent to Weaviate. Apply hard catalog filters before returning results. Then fetch or verify the current WooCommerce presentation data if price, stock, or promotions can change more frequently than the index.
Return a useful empty state when no result passes the relevance threshold. Do not silently display unrelated products merely because the query returned a nearest neighbor. A fallback can offer keyword search, broader category results, or a request to remove a constraint, but it should be visible to the shopper.
Cache repeated anonymous queries for a short period, while ensuring that cache keys include the site, language, currency, customer context, and active filters. Never cache one customer’s restricted pricing or catalog visibility for another customer.
Measuring relevance
Evaluate semantic search with real WooCommerce queries rather than judging a few visually appealing results. Build a test set containing vague intent searches, exact product searches, misspellings, brand queries, facet-heavy searches, and queries that should return no results.
Useful measurements include recall at a chosen result count, precision of the first few results, zero-result rate, click-through rate, add-to-cart rate, and conversion rate. Review failures by category:
- Missing product: the product content or taxonomy was not indexed correctly.
- Wrong intent: the embedding content contains ambiguous or misleading copy.
- Facet failure: a constraint was embedded as text instead of applied as a structured filter.
- Stale result: the synchronization process did not update stock, price, or visibility.
- Exact-term failure: vector-only search was used where hybrid retrieval was needed.
Relevance improves when product content is specific and maintained. Search logs can reveal the language shoppers use, which may differ substantially from merchandising copy. Use those findings to improve product fields, query interpretation, and ranking rules rather than adding unrelated text solely to influence embeddings.