Most people’s first reaction to the new WooCommerce AI Product Advisor is some version of “so AI writes product descriptions now.” I think that misreads the plugin. Writing was never the expensive part of a messy catalog. The cost is knowing which of two thousand products deserve attention first, and being able to undo a change when a suggestion turns out worse than what was there before. This beta is built around those two problems, triage and reversibility, and they’re why I’d test it instead of dismissing it.
The announcement is on the WooCommerce developer blog, and it’s upfront about the plugin being experimental, released early so real stores can shape it. You download a ZIP from GitHub rather than installing from the plugin directory, which tells you how finished it is. Run it on staging first.
What the WooCommerce AI Product Advisor does
Onboarding analyzes your existing store content and builds a tone profile, so suggestions are meant to match your brand voice rather than generic AI copy. From there it generates field-level suggestions across titles, descriptions, short descriptions, categories, tags, and variation details. Everything happens in three admin screens:
- Overview, with pending suggestions, approval rate, weekly usage, and a local lift/dip indicator that shows whether orders moved after you applied changes.
- Suggestions, a ranked queue of improvements with a side-by-side diff and inline editing per product.
- History, a full audit log where every accepted change can be reverted.
The ranked queue is the part I care about. Most stores I see with catalog problems don’t have uniformly bad data. They have a long tail: a chunk of products that migrated badly, imports with no descriptions, variation attributes nobody named consistently. A queue that scores the catalog and puts the worst offenders first saves the kind of audit work that usually eats an afternoon and then gets abandoned. I made a similar argument about AI workflows on store data, where the payoff came from asking better questions about the data you already have.
Onboarding asks you to connect your store, and suggestions are generated through that connection to WordPress.com, not locally. So the plugin is really a client for a remote service, which is why the first failure you hit probably has nothing to do with products.
The connection is where it breaks first
The first comment thread under the announcement is a good example. A user couldn’t get through onboarding and got “The response is not a valid JSON response.” The plugin author replied that this usually means WordPress.com couldn’t parse the response from the site, because some random output made the JSON invalid. The user eventually found commented-out lines in a theme file, removed them, and the connection worked. If you’ve ever debugged a Jetpack connection, you know this kind of bug: a theme or plugin prints a stray space, newline, or debug line before the response body, and every JSON consumer downstream breaks quietly.
So check the store before you install anything. The WordPress REST API serves JSON exclusively, which means anything printed before the opening brace corrupts every consumer of it, this plugin included. Run this on the store in question:
# the index should start with {"name": and nothing before it
curl -s https://example.com/wp-json/ | head -c 80
# snapshot the database before any bulk apply
wp db export backup-$(date +%F).sqlIf the output does not begin with {“name”: then something on the site is printing early output. Fix that first. It’s the kind of bug that also breaks application passwords, mobile apps, and half the modern tooling that talks JSON to WordPress, so the fix pays for itself whether or not you keep the advisor installed.
Why I’d apply suggestions in small batches
The Overview screen shows a lift/dip indicator next to products you’ve updated. In the comments, the author explained how it works: the baseline is the 30 days before the last suggestion was applied, the first 7 days are collection only, and after that it compares the baseline to everything since, with no upper bound on the after window. He also admitted the numbers get less reliable over time and said the behavior needs adjusting. I’m glad he said so, because it tells you the indicator is a plain before/after comparison that controls for nothing else.
In practice, bulk applying hundreds of suggestions in one afternoon wrecks your own measurement. Every product gets the same baseline window, and the after period swallows whatever else happened, whether that’s your summer sale, a new ad campaign or a rebuilt category page. On a store with normal seasonality those effects will dwarf any copy change. A queue full of meaningless lift numbers is worse than having none, because someone will act on them.
There’s a second cost. A few hundred product edits at once mean cache purges, feed rebuilds, and sitemap churn in a single event. On stores with large object caches and product feeds, that’s the kind of spike that surfaces problems you didn’t know you had. It’s the same reasoning as splitting big background jobs: spread the write load and watch what happens.
To be fair to the tool, two things are better than the usual AI listing plugin. The tone profile is a real attempt at the generic-copy problem, since it’s derived from your own catalog rather than a prompt template. And the author confirmed in the comments that it can fill empty descriptions from the product name, categories, and tags, and keep the listing’s language. For a store with five hundred bare products from a CSV import (a common state), that alone justifies the test.
I’d run it like this: staging first, a database export before onboarding, and the curl check from above. Review the first batch of diffs the way you’d review a pull request, because the diff view is good for that. Apply twenty or thirty products, ideally within one category, and let the 30-day baseline pass before the next batch. One known gap to plan around: the author acknowledged that changing the Tone and Feel settings does not regenerate suggestions already in the queue, so set the tone carefully during onboarding or expect to dismiss and requeue.
If you’d rather not point a beta AI plugin at a live catalog yourself, or you want the connection checks and a rollback plan handled properly, that’s work I take on. I’m glad to look at the store before anything touches it.
So start with the curl check against the store you’re considering. If the response does not start with {“name”: fix that first. You’ll need it clean for this plugin and for everything else that talks JSON to WordPress.
