Embedding Product Variations for RAG

Product variations are often the difference between a useful WooCommerce answer and a misleading one. A customer may ask whether a blue, large hoodie is available, whether a 128 GB device is compatible with an accessory, or which size has the lowest price. If the retrieval index contains only the parent product, the language model can identify the product family but may not have reliable variation-level facts.

Why parent-only embeddings fail

A variable WooCommerce product contains shared information on the parent product and specific information on each variation. The parent usually holds the title, description, category, brand, and general imagery. A variation may hold the SKU, regular price, sale price, stock status, weight, dimensions, downloadable files, image, and selected attribute terms.

Embedding only the parent creates several risks:

The system may answer that a product is available when the requested attribute combination is out of stock.
The model may combine the price of one variation with the attributes of another.
Search results may mention a product family without identifying the exact SKU that satisfies the query.
Variant-specific compatibility, dimensions, or shipping information may never reach retrieval.

For WooCommerce RAG, treat each commercially meaningful variation as a retrievable entity while retaining a reference to the parent product.

Design a variation document

A variation document should contain enough natural-language context to match customer questions, plus structured metadata for exact filtering and validation. A practical representation includes:

Identity: variation ID, parent product ID, SKU, GTIN or other catalog identifier, and canonical URL.
Product context: parent name, brand, category, short description, and relevant use cases.
Selected attributes: human-readable labels such as Colour: Blue and Size: Large, not only internal term IDs.
Commercial facts: current price, regular price, sale status, currency, and tax display policy.
Inventory facts: stock status, purchasability, backorder status, and, where appropriate, quantity.
Physical or technical facts: weight, dimensions, capacity, model number, compatibility, and variation-specific specifications.
Freshness fields: modified timestamp, catalog version, and source-system status.

Keep the text used for semantic search readable. Store internal IDs and exact values as metadata rather than expecting an embedding to preserve them precisely.

Example variation text

Product: Alpine Trail Jacket - Blue / Large. Brand: North Ridge. Category: Outdoor clothing. This variation is a blue, large Alpine Trail Jacket. SKU: ATJ-BLU-L. The jacket is waterproof, packable, and designed for three-season hiking. Current price: 129.00 USD. Stock status: in stock. Parent product ID: 4821. Variation ID: 4937.

The parent description can be included in every variation document, but avoid copying large blocks of repetitive content if it consumes most of the embedding context. A compact summary of shared features is normally sufficient.

Normalize attributes before embedding

Attribute values frequently appear in inconsistent forms across WooCommerce catalogs. For example, Blue, blue, and Navy Blue may be distinct terms or may be treated as synonyms by the business. Normalize the data in a deterministic enrichment step:

Use the customer-facing attribute label and term name.
Preserve the original value for display and auditing.
Add approved synonyms only when the catalog owner confirms that they are equivalent.
Represent dimensions and units consistently, such as 20 cm rather than mixing centimeters and inches without conversion.
Keep attributes in a stable order so unchanged products do not produce unnecessary embedding updates.

Do not merge genuinely different values simply because they are semantically similar. A 32 GB storage option and a 64 GB storage option need separate records and separate metadata.

Use metadata for exact constraints

Vector similarity is appropriate for intent and descriptive language, but it is not a reliable database for exact price, stock, quantity, SKU, or attribute filtering. Store filterable fields alongside the vector:

parent_product_id: 4821<br>variation_id: 4937<br>sku: ATJ-BLU-L<br>attributes: {pa_color: blue, pa_size: large}<br>stock_status: instock<br>purchasable: true<br>price: 129.00<br>currency: USD<br>catalog_updated_at: 2025-02-14T10:30:00Z

A retrieval request for blue large jackets under 150 dollars that are in stock should apply the stock, attribute, and price constraints through the search system or a WooCommerce lookup. The vector search can then rank the remaining records by relevance. If the vector database cannot perform all required filters, use a two-stage process: retrieve a broader candidate set, then verify candidates against current WooCommerce data before generation.

Choose a parent and variation retrieval strategy

There are three useful patterns, and many agencies use more than one depending on the storefront experience.

Variation-only retrieval

Index one document per variation and include a compact parent summary. This is the clearest model for questions about size, colour, price, availability, or SKU. It can produce more records, but the records are directly actionable.

Parent plus variation retrieval

Index the parent product for broad discovery and variations for transactional details. Retrieve both, then group variation results under their parent before sending context to the model. This works well when customers first describe a use case and then ask for available options.

Parent retrieval followed by live variation lookup

Use embeddings to find relevant parent products, then query WooCommerce for current variations and apply exact business rules. This reduces index volume and limits stale inventory data, but it requires an additional lookup and careful latency management.

For stores where stock and price change frequently, the third strategy or a hybrid of the first two is usually safer. Embeddings should not be the authoritative source for volatile commercial facts.

Build variation records from WooCommerce

When exporting from WordPress, use WooCommerce product APIs rather than scraping rendered HTML. A simplified PHP mapping can look like this:

$variation = wc_get_product($variation_id);<br>$parent = wc_get_product($variation->get_parent_id());<br><br>$attributes = array();<br>foreach ($variation->get_attributes() as $taxonomy => $value) {<br>    $label = wc_attribute_label($taxonomy);<br>    $attributes[$label] = $value;<br>}<br><br>$document = array(<br>    'variation_id' => $variation->get_id(),<br>    'parent_product_id' => $variation->get_parent_id(),<br>    'sku' => $variation->get_sku(),<br>    'name' => $parent->get_name(),<br>    'attributes' => $attributes,<br>    'price' => $variation->get_price(),<br>    'currency' => get_woocommerce_currency(),<br>    'stock_status' => $variation->get_stock_status(),<br>    'purchasable' => $variation->is_purchasable(),<br>    'url' => $variation->get_permalink(),<br>);

The production exporter should also include the selected parent description, variation dimensions, image URL, tax or price-display rules, and any custom fields that affect product selection. Sanitize HTML descriptions into a controlled text form before embedding, and exclude administrative notes or untrusted content.

Keep embeddings synchronized

Variation indexing needs its own change detection. A parent update may require re-indexing all child variations if the parent title, description, category, or shared specifications are included in their text. A variation update should normally re-index only that variation and update its metadata.

Useful WooCommerce synchronization triggers include product and variation saves, inventory changes, price changes, attribute changes, product status changes, and deletion events. Use a queue rather than embedding synchronously during an administrator save. The queue should support retries, idempotent upserts, and deletion of records for removed variations.

Use a stable vector document ID such as wc_variation_4937. Store a content hash and the source modification timestamp so the worker can skip embedding when the searchable text has not changed. Price and stock metadata can sometimes be updated without regenerating the vector, provided the vector record and metadata store support partial updates.

Prevent contradictory variation answers

Pass variation results to the generation step in grouped, explicit form. Each result should identify the parent, selected attributes, SKU, price, currency, and stock state. Do not present a flat list where the model has to infer which attributes belong together.

Alpine Trail Jacket<br>- Variation ID: 4937<br>- Attributes: Colour Blue; Size Large<br>- SKU: ATJ-BLU-L<br>- Price: 129.00 USD<br>- Stock: In stock<br>- URL: https://example.com/product/alpine-trail-jacket/?attribute_pa_color=blue&attribute_pa_size=large

In the generation instructions, require the system to cite only attributes from the same variation record. If no exact combination is found, the answer should say that the exact combination was not confirmed and may offer separately retrieved alternatives. It should not construct a new combination by combining records for blue, medium and black, large.

Test variation retrieval with realistic queries

Agencies should evaluate variation retrieval with a test set that includes both semantic and exact-match questions:

Find a waterproof blue jacket in large under 150 dollars.
Is SKU ATJ-BLU-L currently available?
Which 64 GB tablet options support the specified accessory?
Show the smallest black storage bin that can hold 40 litres.
Does the red size 10 shoe have the same price as the blue size 10 shoe?
What alternatives are available when the requested colour and size are out of stock?

Measure exact variation accuracy, attribute-combination accuracy, stock freshness, price accuracy, parent grouping, and citation or URL correctness. Include cases where one attribute is missing, a variation is backordered, or the parent product remains published after all variations are unavailable.

Table of contents :