WooCommerce chatbot with variations: why most bots get it wrong

Most WooCommerce chatbots cannot answer a basic variation question correctly. Ask "do you have this in blue, size L, and is it in stock?" and the typical chatbot either says "yes" (wrong — it read the parent product page), "I don't know" (useless), or redirects you to a category page (worst of all). The problem is structural: these bots scrape your product pages instead of reading your WooCommerce catalog. Here is what that means, why it matters, and how to fix it.

Key takeaways

• WooCommerce stores variable products as parent → variation → attribute → stock. Most chatbots only see the parent.
• A page-scraping chatbot cannot tell the difference between an in-stock variation and an out-of-stock one — it sees the same product page either way.
• Storebird reads wp_posts, wp_postmeta, and wp_wc_product_meta_lookup directly, so it answers variation questions from live data.
• You can test any chatbot in five minutes with the five-question checklist in this article.
• Price differences between variations, backorder status, and attribute-level stock are the three edge cases that expose every scraper.

Written by the Storebird team. Last updated: April 12, 2026.

How WooCommerce actually stores product variations

Before we talk about chatbots, you need to understand how WooCommerce structures variable products. This is the part most chatbot vendors skip — and the reason their tools break.

A variable product in WooCommerce is not one row in a database. It is a parent-child hierarchy:

1. Parent product — a wp_posts entry with post_type = product. This is the product page your customers see. It holds the product title, description, images, and global attributes (like "Color" and "Size").
2. Variations — each combination of attributes (Blue / L, Blue / M, Red / L, Red / M) is a separate wp_posts entry with post_type = product_variation. Each variation is a child of the parent product.
3. Attributes — stored in wp_postmeta as serialized term relationships. Each variation has its own attribute values.
4. Stock per variation — each variation has its own _stock and _stock_status in wp_postmeta. A product can have 12 variations where 8 are in stock, 3 are out of stock, and 1 is on backorder.
5. Price per variation — each variation can have its own _regular_price and _sale_price. The parent product shows a price range; the variation has the exact number.

WooCommerce also maintains a lookup table — wp_wc_product_meta_lookup — that flattens price and stock data for fast queries. This is the table that powers WooCommerce's own filtering and sorting. It is also the table a chatbot should be reading.

The WooCommerce REST API documentation for product variations exposes this structure. Each variation is a separate API endpoint under /wp-json/wc/v3/products//variations. The data is there. The question is whether your chatbot uses it.

For a broader look at what a WooCommerce chatbot should do beyond variations, see our WooCommerce chatbot guide.

Why page-scraping chatbots fail on variations

Most chatbot vendors — Tidio, Chatway, WoowBot, and the dozens of generic "AI chat for WordPress" plugins — use one of two approaches to learn about your products:

Approach 1: Page scraping. The chatbot crawls your product pages and converts HTML to text. It sees "T-Shirt — Blue, Red, Green — $29–$49" and stores that as a flat document. It does not know that Blue/L costs $35, Red/L is out of stock, or Green/M is on backorder.

Approach 2: Knowledge base only. The chatbot answers from FAQ content you write manually. It can repeat "We carry the Classic T-Shirt in Blue, Red, and Green" but cannot tell you whether Blue/XL is currently in stock.

Both approaches share the same flaw: they treat a variable product as flat text instead of structured data.

Here is what happens in practice:

• Customer asks: "Do you have the Classic Tee in blue, size L?"
• Page-scraping bot: "Yes, we carry the Classic Tee in blue." (True that blue exists as an option. No idea whether size L in blue is actually in stock.)
• Knowledge-base bot: "I'll need to check with the team on availability. Can I take your email?" (A polite way of saying "I don't know.")
• What the customer wanted: "Blue / L is in stock. $35. Ships in 2-3 days."

The gap between what the customer expects and what the chatbot delivers is the conversion you lose. According to Forrester Research, 53% of online shoppers abandon a purchase if they cannot find a quick answer to their question. On a WooCommerce store with variable products, the "quick answer" is almost always about a specific variation.

If you are evaluating chatbots right now, our best AI chatbot for WooCommerce in 2026 roundup covers the full landscape — but this page goes deeper on the variation problem specifically.

What a variation-aware chatbot actually does

A chatbot that reads your WooCommerce catalog directly does not guess. It queries.

Customer message: "Do you have the Merino Wool Sweater in charcoal, size M?"

What a variation-aware chatbot does:

1. Identifies the parent product by name.
2. Queries child variations for the matching attribute combination (color = charcoal, size = M).
3. Reads _stock_status and _regular_price / _sale_price for that specific variation.
4. Returns: "The Merino Wool Sweater in Charcoal, size M is in stock. Currently €89 (regular price €109). Want me to add it to your cart?"

That is a database query against your live WooCommerce data — the same tables WooCommerce uses to render the product page. No scraping, no middleware, no manual FAQ entries for every color-size combination. For the technical details on how this sync works, see our product intelligence feature page.

The practical effect: your chatbot becomes the fastest path to a purchase decision. The customer does not need to navigate to the product page, select attributes from a dropdown, and check stock themselves. They ask, they get a real answer, and they buy — or they learn the variation is out of stock and get pointed to one that is available.

The three edge cases that break every scraper

If you want to know whether your chatbot actually reads variations, test these three scenarios. They are the cases where page scrapers always fail.

Edge case 1: Out-of-stock variations on an in-stock product

A product with 20 variations might have 17 in stock and 3 out of stock. The product page still shows "In Stock" because WooCommerce displays the parent-level status. A page scraper sees "In Stock" and tells the customer the product is available — even if the specific variation they asked about is sold out.

What should happen: The chatbot checks the variation-level _stock_status, confirms it is out of stock, and suggests the closest in-stock alternative. "Charcoal / M is currently out of stock. Charcoal / L and Navy / M are both available — would either of those work?"

That suggestion requires knowing which other variations exist and which are in stock. A scraper cannot do this.

Edge case 2: Backorder-enabled variations

WooCommerce lets you enable backorders per variation. One variation might be set to "Allow backorders" while another is set to "Do not allow." This is stored in _backorders in wp_postmeta — variation by variation.

A customer asks: "Can I still order the red/XL even though it shows out of stock?"

A page-scraping chatbot does not know the answer. A variation-aware chatbot checks _backorders for red/XL and responds: "Red / XL is out of stock, but backorders are enabled. You can order now and it will ship when restocked — usually within 2 weeks."

Edge case 3: Price differences between variations

Many WooCommerce stores charge different prices for different variations. A larger size might cost more. A premium fabric might carry a surcharge. The parent product page shows a price range — "$29–$49" — but the customer wants to know the exact price for their combination.

A page scraper can only repeat the range. A variation-aware chatbot returns the exact price: "The Classic Tee in Blue / XL is $42."

If your store uses AI-powered product recommendations, getting the price right per variation is even more critical — a recommendation is useless if the quoted price is wrong.

How Storebird handles WooCommerce variations differently

Storebird is built on the WooCommerce data model. It does not scrape pages and it does not rely on a knowledge base to answer product questions.

Direct catalog sync: The Storebird WordPress plugin syncs your product catalog — parents, variations, attributes, stock, prices, categories, tags — using WooCommerce's own data layer, not a REST API crawl. The chatbot has the same view of your catalog as your WooCommerce admin panel.

Variation-level resolution: When a customer asks about a specific attribute combination, Storebird resolves it to the exact variation record. It queries the child variation, checks stock, checks price, and returns a direct answer.

Stock-aware suggestions: If a variation is out of stock, Storebird checks which other variations are available and suggests them — keeping the conversation moving toward a purchase instead of a dead end.

Backorder and pricing accuracy: Storebird reads _backorders per variation (so it can tell a customer whether they can still order a sold-out SKU) and returns per-variation pricing — the exact amount, not the parent's range. If a variation is on sale, it shows both prices.

Real-time data: The sync is not a one-time import. Update stock at 2pm and the chatbot knows at 2pm. Change a price and the chatbot quotes the new number. No cache lag, no manual refresh.

For a look at how this compares to other tools, see our full chatbot comparison for WooCommerce. No other WooCommerce chatbot currently reads variation-level data this way.

The five-question variation test (run this on day one)

You can test any WooCommerce chatbot — Storebird or not — with five questions. Run these on day one and you will know immediately whether your chatbot understands variations or is faking it.

1. "Do you have [product] in [color], [size]?" — The chatbot should confirm or deny based on the specific variation's stock status, not the parent product.
2. "Is [specific variation] in stock?" — Same test, different phrasing. The chatbot should check _stock_status for the variation, not the parent.
3. "How much does [product] cost in [size/color]?" — The chatbot should return the per-variation price, not the parent's price range.
4. "What sizes are available for [product] in [color]?" — The chatbot should list only the in-stock sizes for that color, not all sizes the product theoretically comes in.
5. "Can I backorder [out-of-stock variation]?" — The chatbot should check the variation's _backorders setting and give a direct yes or no.

If your chatbot answers all five correctly from live data, it is reading your WooCommerce catalog. If it answers one or two with vague hedging ("Let me check with the team" or "Please visit the product page"), it is scraping.

This test takes five minutes. Do it before you commit to any annual plan.

If you are still choosing between tools, Storebird's pricing page has a 14-day free trial on the Pro plan — no credit card, full variation support. Install from WordPress.org, run the five questions, and decide.

When Storebird is not the right choice

Not every store needs a variation-aware chatbot. Here is when this capability does not matter and you should look elsewhere:

• You sell simple products only. If your WooCommerce catalog is entirely simple products (no variations), the scraping problem does not apply. A generic chatbot is probably fine. Most WooCommerce stores do use variable products, but if you are the exception, you do not need Storebird for this reason.
• Your variations rarely go out of stock. If you carry deep inventory on every variation, the "is it in stock?" question is always "yes" and the chatbot's accuracy on stock matters less. You still benefit from per-variation pricing accuracy, but the urgency is lower.
• You need multichannel inbox features. Storebird is a web chatbot. If you need consolidated email, Messenger, Instagram DMs, and WhatsApp in one dashboard, tools like Crisp or Tidio cover that better — even though they lack variation awareness.
• Your budget is zero. Storebird starts at EUR 39/month. If you need a free chatbot, WoowBot has a free tier — just know it does not handle variations accurately.

That is the honest list. If your store does use variable products, your customers ask variation questions, and you want a chatbot that answers correctly, keep reading.

Setting up variation-aware chat on your store

Getting Storebird running with full variation support takes about 10 minutes:

1. Install the plugin from WordPress.org. Activate it in WordPress.
2. Connect your Storebird account. Enter your license key. The 14-day Pro trial starts automatically — no credit card.
3. Wait for the initial sync. Storebird reads your entire product catalog — all variations, attributes, stock levels, and prices. On a store with 5,000 products and 30,000 variations, this takes under two minutes.
4. Run the five-question test from the checklist above. Open a private browser tab, start a chat, and verify the answers match your WooCommerce admin.
5. Add your knowledge base. Feed in your return policy, shipping info, and FAQs. The chatbot uses this alongside your catalog for non-product questions.
6. Go live. Monitor conversations from the Storebird dashboard for the first week.

If you are migrating from another chatbot, run both side by side for a week before deactivating the old one. See our WooCommerce chatbot guide for the full migration process.

Frequently asked questions

Why do most chatbots fail on WooCommerce product variations? They scrape rendered HTML. A variable product page shows a dropdown, not structured data. The scraper sees "Blue, Red, Green" but cannot tell which combination is in stock or what each variation costs. Only a chatbot that reads the WooCommerce database directly can answer variation questions accurately.

What is the WooCommerce data model for product variations? A parent post (post_type = product) with child posts (post_type = product_variation). Each variation has its own SKU, price, stock quantity, and attribute values in wp_postmeta. The wp_wc_product_meta_lookup table provides a flat index for fast queries.

Can Tidio or Lyro answer variation questions? No. Lyro is trained on FAQ content and website pages, not your WooCommerce product database. It cannot check whether a specific size-color combination is in stock.

How does Storebird handle WooCommerce product variations? It syncs directly with the WooCommerce database — parent products, child variations, attribute values, per-variation stock, per-variation pricing, and backorder status. When a customer asks "do you have this in blue, size L?", Storebird checks the live variation record and returns a real-time answer.

What happens when a customer asks about an out-of-stock variation? Storebird confirms the variation is out of stock, checks whether backorders are enabled, and suggests in-stock alternatives. A page-scraping chatbot typically says "yes, we have that product" because the parent page exists.

Do WooCommerce variations have different prices? Yes. Each variation can have its own regular and sale price. A chatbot reading only the parent sees a price range. Storebird reads per-variation pricing and returns the exact amount.

How do I test whether my chatbot understands variations? Ask five questions: (1) Do you have [product] in [specific attributes]? (2) Is [specific variation] in stock? (3) How much does [product] cost in [size/color]? (4) What sizes are available in [color]? (5) Can I backorder [out-of-stock variation]? If your chatbot hedges on any of these, it is scraping pages.

Is Storebird the only chatbot that reads WooCommerce variations directly? As of April 2026, yes. Other tools scrape pages, rely on manual FAQ content, or use the REST API without handling the parent-variation relationship. If another tool ships this, we will update this page.