ChatGPT can turn a scrappy product note into readable copy. It can also make a cotton bag waterproof in a single sentence. Give it a small sheet of approved facts, then check what it actually wrote before that sentence reaches your shop.
In this guide
Make a small approved facts sheet
Choose one product and its exact variant. Compare the shop entry with the current supplier sheet, product instructions or a measurement you have actually made. A WooCommerce record is stored data, not proof that its claims are correct. Settle conflicts before asking AI to write.
Keep only facts the customer is allowed to see: product name, material, relevant dimensions with units, included items, verified compatibility and care instructions. Note what is unknown. Keep supplier invoices, margins, customer information, credentials and internal notes out of the prompt.
Leave changing prices and availability in WooCommerce’s live fields where practical. A description saying “in stock at $29” can become wrong even when the original draft was checked. For variable products, match the facts to the option being sold; WooCommerce supports variation-specific pricing and stock settings.
Draft from those facts
Paste the approved public facts into ChatGPT with a short brief like this. These instructions guide the draft; they do not guarantee accuracy.
Write a short product description for a customer choosing this item.
Use only the approved public facts below. Do not add benefits,
compatibility, certifications, delivery promises or performance claims
that the facts do not support. Leave out prices and availability.
If an important detail is missing, list it separately as a question.
Return the description, followed by a separate list linking each
factual claim to its supporting approved fact.
Approved public facts:
[Paste the checked facts for this exact product and variant.]The claim list is a useful review aid. It is still written by the same model and can be wrong. Keep it in your working notes, not in the customer-facing description.
Check a before-and-after description
Imagine an illustrative tote bag with these approved facts: 100% cotton, 38 cm wide by 42 cm high, open top, one internal pocket, spot-clean only. Waterproofing and load capacity have not been verified.
Draft to reject: “A waterproof everyday bag with a secure zip and room for heavy shopping. Machine washable for easy care.”
Checked rewrite: “This cotton tote has an open top and an internal pocket for smaller items. It measures 38 cm wide by 42 cm high. Spot-clean when needed.”
The rewrite uses the verified material, opening, pocket, dimensions and care instruction. It removes waterproofing and load claims because there is no supporting fact, removes the invented zip, and corrects the washing advice. It is less dramatic, but it describes the bag the customer would actually receive.
Verify the words customers will read
Read every factual claim in the drafted description and point to its approved source. Check numbers, units, variant names and exceptions. Also check implications: “ideal for outdoor use” can imply weather resistance even without the word “waterproof”. Remove or resolve unsupported claims.
Preview the product on mobile and desktop. Select its options and compare the description, images and current price/availability display. Make sure the supplier facts, shop fields and prose agree. Save the old description so a correction is reversible. Start with one item and review the published result before expanding the workflow.
Optional: API automation
You do not need API access for the workflow above. If a developer automates it, keep the integration read-only until the checks are proven and pass only an allowlisted set of approved public fields to the model. Do not forward an entire privileged record or arbitrary meta_data.
For wc/v3, use the documented stock_status, manage_stock and stock_quantity fields. A product with unmanaged stock may have a null quantity and still be marked instock. Do not impose “in stock means quantity greater than zero”. Check the backorder settings too: a product can accept orders without positive stock. The REST Products reference defines these fields and status values; use documentation for the endpoint version you actually call.
For variable products, resolve whether stock is managed by the parent or the selected variation. Do not infer one variation’s availability from another. Code can check field types and compare quantities, but those checks neither prove a supplier claim nor validate the generated prose. A model returning checks_passed is not independent validation.
Take one existing description and compare its claims with a checked facts sheet. For other practical uses, see ChatGPT jobs for WooCommerce; for measurements, see dimensions customers can use.