An AI writes an inaccurate product description for one reason: it was not given the facts. Handed only a product name, a model has nothing to work from but the statistical average of every similar product it has ever seen, so it fills the gaps with plausible specifications your product may not have. The fix is not a better prompt, it is better inputs. Record the real facts as WooCommerce product attributes, generate only from those attributes plus the product name and categories, then review every result before it saves. A description built this way can still read badly, and you still have to check it, but the model is no longer filling gaps with guesses about a product it has never seen.
A language model does not know your product. It knows how descriptions of products like yours tend to read. Give it "Oak Dining Table" and nothing else, and it will produce a fluent paragraph about solid oak construction, a protective lacquer finish and seating for six, because that is what the average listing with that name says. Some of it may even be true. None of it came from your store.
This is not a flaw you can prompt your way out of. Asking a model to "only use accurate information" does not give it information it was never handed. The gap gets filled either way. The only reliable control is what goes in.
When you review a generated description, you are looking for four specific failures:
WooCommerce already has a place for product facts, and most stores underuse it. Attributes come in two kinds, and picking the right one saves work later.
Global attributes are created once at Products, then Attributes, and reused across the catalogue. WooCommerce's own documentation is blunt about why they are the better default: they are "defined globally, so they're easy to update across the entire store, and available to be used on any product". If you sell forty products in cotton and the supplier changes the blend, you edit one term.
Custom attributes are typed directly on a single product, in the Attributes tab of the Product data panel. Per the same documentation, they "can be defined individually, at the product level, and they will only exist for that single product". They are right for genuinely one-off facts and wrong for anything you will type twice.
The practical rule: if a fact will appear on more than one product, make it a global attribute. If it will not, a custom attribute is fine. Attributes are also what variations are built from, which WooCommerce describes as "crucial for creating variable products", so the work you do here is not just for descriptions. It feeds filtering, variation dropdowns and your structured data as well.
You do not need every attribute. You need the ones a buyer would ask about, and the ones that distinguish this product from the next one along. A useful starting set, by category:
| Product type | Attributes worth recording |
|---|---|
| Clothing and textiles | Material or composition, size range, fit, care instructions, country of manufacture |
| Furniture and homeware | Dimensions, weight, material, finish, assembly required, what is in the box |
| Electronics and accessories | Compatibility, power or battery, connections, dimensions, what is in the box, warranty |
| Food, drink and cosmetics | Ingredients, allergens, net weight or volume, storage, origin, certifications |
| Parts and consumables | Fitment or compatible models, dimensions, material, quantity per pack, standard met |
This is data entry, and no tool does it for you. That is the honest part of this guide. What it buys you is that every description generated afterwards is grounded in something real, and that the same facts do useful work in filters, variations and search.
If you sell food, drink, cosmetics or anything with a safety standard attached, treat the regulated attributes as the ones you check twice. An AI that invents an allergen statement has created a problem that a careful review would have caught in five seconds.
In ChatGPT, Claude or any other chat tool, the instruction that does the work is the one that tells the model what to do when a fact is missing. Without it, the model guesses. This pattern works:
The last line is the important one. It gives the model permission to produce a shorter description, which is what you want, rather than a complete one built partly from invention.
There is one question worth asking of any AI description plugin before you trust it with a catalogue: what does it actually send? A plugin that reads only your structured product data has a narrow and predictable input. A plugin that also reads your images, your existing copy or the open web has more to work with, and more surface for error. Neither is wrong, but you should know which you have bought.
| Tool | What it reads from your store | AI access |
|---|---|---|
| AltoScribe | Product name, its attributes and its categories. Nothing else: not your images, not your existing description, not the web | Hosted, no API key and no account |
| AI Product Tools | Product categories, attributes, price and stock status. Pro adds full descriptions and custom attributes as context | Bring your own key (OpenAI, Gemini, Claude, OpenRouter) |
| WriteText.ai | Product name, attributes, tags, the featured image via image recognition, plus detail and keywords you add yourself, with optional web research | Hosted, its own account and credits |
| StoreAgent | Indexes your store into what it calls "a vector knowledge database of your content": product listings, existing product content, store policies, FAQs and blog posts | Hosted, no API key |
Narrower is not automatically better. A tool that reads only your attributes has less room to go wrong, because there is no extra source for it to import a stray fact from, but it also cannot rescue a product with nothing recorded against it: thin attributes produce a thin description. A tool that reads your images and your own notes has more raw material, and can write well about a product whose attribute list is sparse, at the cost of more places for a mistake to enter. Match the tool to the state of your data, and remember that none of them removes the review step.
AltoScribe sends your product's name, attributes and categories and nothing else, generates a short and a long description, and shows you every one to review before it saves. It never overwrites existing copy unless you ask. Free on WordPress.org: 10 descriptions a month, no API key and no account.
Get AltoScribe on WordPress.orgRead the description with the attribute list next to it, not on its own. On its own, a fluent paragraph reads as true. Side by side, invention is obvious. Four checks:
On a small catalogue, review everything. On a large one, review every description for your best-selling and highest-traffic products, and sample the rest, weighting the sample towards categories where a wrong fact costs you a return or a complaint. Whatever tool you use, keep the review as a step rather than a setting you can switch off.
Three concrete reasons this matters beyond the writing being good.
Shopping feeds. If you send products to Google, the Merchant Center specification asks you to use the description attribute "to accurately describe your product and match the description from your landing page", and tells you not to include "links to your store, sales information, details about competitors, other products, or accessories". An AI description written from generic marketing language fails on both counts at once.
Structured data. Google's structured data policies state plainly that "Your structured data must be a true representation of the page content" and that you should not "mark up content that is not visible to readers of the page". If your product schema carries a specification your description invented, the markup is describing a product you do not sell.
Search itself. Google does not treat AI writing as against policy. What its spam policies target is scaled content abuse, defined as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users", with using "generative AI tools or other similar tools to generate many pages without adding value for users" given as an example. A description grounded in your product's real attributes and reviewed by you is on the right side of that line. A thousand near-identical paragraphs of filler is not.
Not for being AI-written. Google's spam policies target scaled content abuse, which it defines as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users", and it names using "generative AI tools or other similar tools to generate many pages without adding value for users" as an example. The method is what separates the two cases. A description generated from your product's real attributes, reviewed by you, and genuinely useful to a shopper is not what that policy is aimed at.
Then that is the work, and no tool will do it for you. A generator handed a product name and nothing else has only the average of every similar product to draw on, which is exactly where invented specifications come from. Start with the products that earn the most or get the most traffic, fill in the handful of attributes that actually distinguish them, and generate only for those. A short accurate description beats a long invented one, and you can extend the attribute set later.
Carefully, and rarely. Manufacturer copy is a useful source of specifications, but it is written to sell the product everywhere it is listed, so it carries marketing claims, comparisons and sometimes details that do not apply to the variant you stock. Feed it in wholesale and the model will repeat all of that as though it were yours. Better to lift the facts out of it into your attributes and generate from the attributes. That also avoids publishing the same paragraph as every other shop selling the same item.
Yes, but check what the tool actually reads. Variations in WooCommerce are built from attributes, so the values are there, but not every plugin sends per-variation data and some describe the parent product only. If size, colour or material genuinely changes what a buyer needs to know, write the parent description from the shared facts and let the variation attributes speak for themselves on the product page, rather than asking the AI to guess what is different.