Which WooCommerce Product Data Should You Index?

Index product data according to how shoppers search

For a WooCommerce agency, indexing every available product field is rarely the best approach. Product records often contain duplicated descriptions, HTML fragments, operational metadata, serialized custom fields, and values that change frequently. A useful Weaviate schema should reflect the queries the store needs to answer, not simply mirror the WooCommerce database.

Start by listing the search and recommendation experiences you need to support:

Keyword search for product names, descriptions, brands, and features.
Natural-language discovery such as “waterproof hiking boots under $150.”
Structured filters for price, stock status, categories, attributes, and ratings.
Product recommendations based on descriptions, categories, and compatible items.
Exact lookups by SKU, product ID, slug, or an external catalog identifier.

Each use case determines whether a field should be vectorized, included in the inverted index, configured for filtering, or kept outside the search object entirely.

Fields that usually belong in the product object

Product identity

Index stable identifiers such as the WooCommerce product ID, SKU, slug, and variation ID when those values are used by integrations or result pages. These fields are primarily for exact lookup and result hydration rather than semantic similarity.

Keep identifiers as dedicated properties instead of combining them into the main searchable text. A product ID should not influence semantic similarity, and a SKU generally has no useful relationship to the meaning of a shopper’s natural-language query.

{
  "productId": 4821,
  "sku": "TRAIL-BOOT-BLK-42",
  "slug": "waterproof-trail-boot",
  "parentProductId": 4700
}

Use an appropriate data type for each property. Numeric IDs can be useful for exact filtering or joins, while SKUs and slugs are usually better represented as text fields with exact-match behavior handled by the application or by a filter designed for the configured property type.

Customer-facing text

Include the fields that explain what the product is and why a customer would buy it:

Name: the product title, including important model or style terms.
Description: the long description after removing presentation-only HTML.
Short description: useful when it contains distinct sales or feature information.
Brand: the manufacturer or label.
Features: meaningful feature statements, ideally represented as an array as well as being available to the semantic representation.
Category context: the category path or normalized taxonomy terms.

For vector search, a composed text property is often more predictable than vectorizing many independent properties without a clear plan. For example:

"searchText": "Waterproof Trail Boot. Lightweight waterproof hiking boot with a grippy outsole and insulated lining. Brand: North Ridge. Categories: Footwear > Hiking Boots. Features: waterproof, insulated, slip resistant."

Map the source fields into this text during ingestion. Do not include boilerplate such as “click here,” repeated shipping notices, hidden SEO text, or identical content copied into every product. Those terms can distort both vector similarity and keyword ranking.

Structured catalog attributes

Index attributes that shoppers use as filters or that your application needs to inspect in search results. Common examples include color, size, material, gender, compatibility, style, and product type. Normalize these values before ingestion so that “Navy,” “navy blue,” and “NAVY” do not become unrelated filter values unless that distinction is intentional.

Use arrays for multi-valued attributes:

"colors": ["navy", "black"],
"materials": ["leather", "rubber"],
"sizes": ["40", "41", "42"],
"categorySlugs": ["footwear", "hiking-boots"]

Taxonomy fields should usually be filterable. They may also be included in the composed semantic text when category context improves natural-language discovery.

Fields to configure for filtering and range queries

Filtering requirements should be decided independently from vectorization. A field can be useful for filtering even when it should never be part of the product vector.

Price: store the numeric value used by the customer-facing currency and pricing context. If a store supports multiple currencies, define whether each indexed object has one normalized comparison price or separate currency-specific values.
Stock status: index a normalized boolean or enumerated value such as in_stock, backorder, or out_of_stock.
Quantity: index only if inventory-aware search requires numeric availability checks.
Rating and review count: use numeric properties when sorting or minimum-rating filters are needed.
Published and sale dates: use date properties for time-based campaigns, freshness rules, or sale windows.
Visibility and catalog status: index values such as published, private, hidden, or excluded from catalog.
Store, channel, and language: index these when one Weaviate collection serves multiple sites, markets, languages, or sales channels.

In Weaviate, configure filterable properties for these access patterns. Range-oriented values such as price, rating, quantity, and dates should use the appropriate range-filter configuration where supported by the client and Weaviate version. Do not make an operational filter depend on a natural-language vector match.

Fields that should usually not be vectorized

Identifiers, prices, timestamps, inventory quantities, URLs, image filenames, internal notes, and synchronization metadata generally do not belong in the semantic vector. Including them can make similar products appear related for irrelevant reasons.

Be cautious with these WooCommerce fields:

Raw post content: it may contain duplicated tabs, shortcodes, page-builder markup, or unrelated layout text.
Internal SKUs and supplier codes: retain them for exact lookup, but do not use them as semantic content.
SEO metadata: index it only when it contains useful customer-facing product information not present elsewhere.
Variation records: avoid indexing a parent product and every variation as interchangeable objects unless the storefront can correctly display the selected variation, price, stock, and attributes.
Frequently changing inventory data: keep it in filterable properties or a separate operational source when update frequency makes full re-vectorization wasteful.

Choose an indexing strategy by query type

Semantic search

Vectorize descriptive content: name, brand, category context, use cases, materials, and meaningful features. A query such as “light shoes for rainy city commuting” can then match products whose descriptions express those concepts even when the exact words differ.

Keyword and exact search

Use the inverted index for names, brands, model numbers, category names, and searchable feature text. BM25-style keyword search is particularly important for terms such as product models, technical standards, and unusual brand names that a vector model may not represent precisely.

Hybrid search

Most WooCommerce catalogs benefit from hybrid search: combine semantic similarity with keyword relevance, then apply hard filters for catalog visibility, stock, price, language, and taxonomy. Keep identifiers and transactional fields available for exact filtering instead of expecting hybrid ranking to enforce business rules.

A practical request pattern is:

query: "waterproof trail shoes"
semantic match: searchText
keyword match: name, brand, categories, features
filters: published = true AND inStock = true AND price <= 150
post-processing: apply store permissions, currency rules, and merchandising boosts

Product and variation modeling

Decide whether the searchable unit is a parent product, a purchasable variation, or both. Index variations separately when size, color, stock, or price materially changes the result. In that model, copy the parent’s descriptive context onto the variation object and add variation-specific attributes. Keep a parent product ID so the application can group results on the product page.

Index parent products when shoppers search for the general product concept and variation-level inventory is handled elsewhere. Whichever model you choose, ensure that every returned object can be mapped back to a valid WooCommerce product or variation without an additional ambiguous lookup.

Schema and ingestion checks for agencies

Measure the fields used by real storefront queries before creating the collection.
Normalize taxonomy, attribute, currency, and boolean values in the WooCommerce-to-Weaviate pipeline.
Separate searchable text from filterable operational properties.
Remove HTML, shortcodes, duplicated descriptions, and non-customer-facing metadata from vectorized text.
Configure index settings deliberately rather than relying on defaults for every property.
Test hybrid search with exact SKUs, brand names, natural-language requests, and empty-result cases.
Verify that product updates refresh price, stock, visibility, and taxonomy fields promptly, while descriptive changes trigger re-vectorization when necessary.
Log the source product ID, source modification time, and indexing status so failed or stale records can be reconciled.

The most useful WooCommerce index is not the one containing the most fields. It is the one in which descriptive content supports semantic and keyword retrieval, structured catalog data supports reliable filters, and operational metadata remains accurate without polluting product similarity.

Table of contents :