Product Titles, Descriptions, Attributes and Variations

WooCommerce agencies often start product search projects by embedding only the product name. That is rarely enough. A product title may identify the item, while the description explains use cases, attributes define constraints, and variations determine purchasable combinations such as size, color, capacity, or finish. A Weaviate implementation should represent these fields deliberately so semantic retrieval improves discovery without weakening exact catalog filters.

Separate searchable text from structured product data

Use a single combined text value for semantic similarity, but retain the original fields as typed properties. The combined value can contain the product title, short description, long description, category context, and important attribute labels. Structured properties should hold values needed for filtering, sorting, synchronization, and display.

A practical product record might contain properties such as wooId, sku, title, shortDescription, description, categories, brand, attributes, searchText, stockStatus, and price. Keep identifiers and operational values independent from the prose used for vectorization.

{"wooId": "4821", "sku": "TRAIL-JKT", "title": "Waterproof Trail Jacket", "shortDescription": "Lightweight rain shell for hiking and travel.", "attributes": {"material": "3-layer recycled nylon", "fit": "regular", "waterproofRating": "20,000 mm"}, "searchText": "Waterproof Trail Jacket. Lightweight rain shell for hiking and travel. Regular fit, 3-layer recycled nylon, 20,000 mm waterproof rating."}

For frequently filtered values, prefer dedicated properties with predictable types. For example, store a numeric waterproof rating separately from the display string, and store a normalized brand slug separately from the brand label. This allows a query to combine semantic similarity with exact constraints.

Titles should carry identity, not every possible keyword

Product titles are strong retrieval signals because they usually contain the product type, model, and primary differentiator. Avoid generating titles packed with repeated keywords or every variation value. A title such as “Women’s Waterproof Trail Jacket” is more useful than a title containing every available color and size.

During synchronization, preserve the WooCommerce title as the canonical display field. If the agency needs a richer embedding input, build searchText separately. This prevents search-oriented enrichment from changing storefront copy or creating unnecessary product updates.

Descriptions add intent and use-case context

Descriptions should explain what the product is, who it is for, and how it differs from related products. These details help a vector search match queries such as “light rain gear for weekend hikes” even when the query does not repeat the exact product title.

Strip presentation-only markup before constructing the embedding input, then preserve the original HTML in a separate field if it is needed for rendering. Remove navigation fragments, shipping notices, duplicated tabs, and boilerplate text. Repeated boilerplate can make unrelated products appear artificially similar.

A useful normalization pipeline is:

1. Read the WooCommerce title, short description, long description, categories, and selected attributes.
2. Convert HTML descriptions to clean text while retaining meaningful headings and sentences.
3. Normalize whitespace, units, and common synonyms such as “water-resistant” and “weather resistant” where appropriate.
4. Build a stable searchText value with labeled sections.
5. Re-vectorize the object only when relevant source fields change.

Attributes need both labels and values

Attribute values without their labels lose meaning. “Regular” could describe fit, voltage, or roast level. Build text such as Fit: regular. Material: recycled nylon. Waterproof rating: 20,000 mm. rather than joining values into an unlabeled string.

For WooCommerce global attributes, store a normalized representation that is consistent across products. A taxonomy term slug is useful for filtering, while the human-readable label belongs in display and embedding text. Handle custom product attributes using the same convention so a query does not behave differently depending on how the merchant created the attribute.

Do not rely on vector similarity for hard requirements. A query for “black size medium” should use semantic retrieval to identify relevant products, then apply exact filters for color and size where those values are available. If a user says “under 100 dollars,” apply a numeric price constraint rather than expecting the embedding model to enforce the limit.

Model variable products and variations deliberately

WooCommerce variable products have a parent product and individual variations. The parent usually contains shared copy, while each variation has its own SKU, price, stock state, image, and selected attribute combination. Treating every variation as an unrelated product can produce duplicate search results, but indexing only the parent can hide important differences.

For most storefront search experiences, index the parent as the primary searchable object and include variation summaries in its searchable content. For example, add “Available in black, navy, and olive; sizes small through extra large” to the parent’s searchText when those options are actually purchasable.

Use a separate variation collection when agencies need variation-level inventory, SKU lookup, price filtering, or direct links to a preselected option. Each variation can contain a reference to its parent or a parent ID, but it should also retain denormalized fields needed for fast retrieval. A variation record might include parentWooId, variationId, sku, attributes, price, stockStatus, and searchText.

When variation data is indexed separately, group results by parentWooId before presenting them in the storefront. Select the best matching variation or show the parent once with the matching options. This avoids displaying twelve nearly identical cards for twelve sizes.

Use hybrid retrieval for catalog queries

Semantic search is valuable for intent, while keyword search is often better for exact model names, SKUs, and technical terms. Weaviate hybrid search combines both approaches. A query such as “lightweight black hiking shell” can benefit from semantic matching, while “TRAIL-JKT-M-BLK” should strongly favor exact token matches.

Apply filters alongside the search operation for fields such as publication status, catalog visibility, category, stock status, price range, brand, and variation attributes. A typical request flow is:

1. Parse the customer query for explicit constraints such as size, color, brand, and price.
2. Send the remaining descriptive intent to hybrid or vector search.
3. Apply structured filters for the extracted constraints.
4. Group variation hits by parent product when the user experience is product-level.
5. Fetch current WooCommerce pricing and availability before checkout-related actions.

Stock and price are mutable commerce data. They can be indexed for discovery, but the WooCommerce or order system remains the authority at add-to-cart and checkout time. This prevents stale vector database values from becoming purchasing decisions.

Keep synchronization idempotent

Use stable object identifiers derived from WooCommerce IDs rather than generating a new Weaviate object on every webhook. A product update should replace the affected record, and a variation update should update the variation plus any parent search text that summarizes available options.

Track changes to titles, descriptions, attributes, variation combinations, and visibility separately from changes to price or stock. Text changes generally require re-vectorization; a price-only update may require only a property update. On deletion or unpublishing, remove the object or mark it unavailable according to the agency’s retention and audit requirements.

Test retrieval with real catalog language

Build an evaluation set from actual support tickets, onsite searches, and merchandising requirements. Include exact SKU searches, attribute combinations, use-case queries, misspellings, and impossible combinations such as a color-size pair that is not sold. Check whether the returned parent product is correct, whether the matching variation is purchasable, and whether hard filters are respected.

For agencies managing multiple stores, keep the data contract explicit: define which fields are canonical, how attributes are normalized, whether variations are independently searchable, and which values must always be filtered rather than inferred. That contract makes the Weaviate integration predictable as WooCommerce catalogs grow.