Build a WooCommerce store with AI. Describe the catalogue once.

Get the source sheet right before you build a WooCommerce store with AI

Almost every catalogue problem an agent runs into was already in the spreadsheet. The brief tells it to stop rather than fill a missing SKU or price, so gaps should surface as a list of skipped products instead of a store. That is an instruction to a model, not a check the server runs, so compare saved values with the sheet anyway. Tidy the sheet first and the run becomes mostly typing.

• One row per sellable thing: a simple product, or one variation of a variable product with a column naming its parent.
• A unique SKU on every row. WooCommerce refuses a duplicate SKU, so two rows sharing one means the second fails rather than overwriting the first.
• Prices as plain numbers in one currency, with sale prices and their dates in their own columns.
• Attribute values spelt exactly as you want shoppers to filter on them, so Navy and navy do not become two terms.
• Image file URLs or a folder you will upload, with the photographer or supplier noted where reuse terms matter.
• Stock quantities only if you manage stock in WooCommerce; otherwise a stock status column is enough.

Run a pilot batch, then the rest

Do not send the whole catalogue first. Pick a handful of rows that cover the awkward cases: one simple product, one variable product with every attribute, one with a sale price and one with no image. The agent creates them as drafts, then reads them back with woocommerce-get-product and woocommerce-list-product-variations so you can compare the saved data with the sheet before it multiplies a mistake across hundreds of items.

Open those drafts in the WooCommerce product editor and on the storefront preview. Check that variation dropdowns offer only real combinations, that the category tree reads as a shopper would browse it, and that the gallery order is right. Fix the brief, not the products, then run the remainder. Because each product is its own set of calls, a batch that stops partway can be picked up again from the returned IDs, after a fresh read, rather than started from scratch.

Honest timings for a catalogue

A store is not built in one sitting because the work scales with rows, not with prompts. A variable product with many sizes and colours is a parent call plus one call per variation, each counting against the write limit, and images add their own imports. Small catalogues fit in an afternoon of runs and review; large ones are a series of batches across days, with you sampling each batch before the next.

Budget most of your own time for the parts the agent cannot judge: whether a product description is accurate, whether the photography matches the variant, and whether shipping classes match what your carrier actually charges. Checkout, tax and payment testing with sandbox providers is a separate stage again and belongs on the plan before launch day.

What Free can do in a store, and what needs Pro

GoBuildWP Free already reads a store and edits products that exist: woocommerce-check-setup, woocommerce-list-products, woocommerce-get-product, the order and customer readers and a basic copy of woocommerce-edit-product are all in the free edition. Free's editor changes a product's name, description, regular and sale price and stock; on a variable product only the name and description, because prices live on the variations. That is enough to correct copy or fix a price on a store someone set up by hand. Status, SKU, categories and images need Pro's fuller copy of the same ability.

Building the catalogue is Pro: creating products and variations, categories, global attributes and their terms, tags and shipping classes. So is ongoing maintenance at scale. woocommerce-bulk-update-prices and woocommerce-bulk-update-stock change up to a hundred items per call, preview every before and after with a dry run that writes nothing, and refuse the real write unless the call carries confirm: true.

Undoing a bad import

Inspect each product entry before relying on recovery. Current Pro product and variation edits that omit manage_stock, stock_quantity and stock_status can retain a before-image that preserves live stock during undo. An edit that supplies those stock fields on a stock-managed product, and the separate bulk writers on managed-stock items, have different limits; retain their original values for manual recovery. Bulk calls return per-item entries rather than one universally reversible batch. Global attribute definitions live in WooCommerce's own table and have no ledger restoration.

For a pilot that went wrong in a way you only noticed afterwards, list-sessions finds the session. Read undo-session's plan first: it reverses supported writes newest first, refuses the run where anyone has edited a product since, and lists irreversible items, which block the run unless you explicitly allow a partial undo.

Deletion is deliberately harder. woocommerce-delete-product and the other delete abilities are destructive: the call must carry a confirmation flag, and Read Only refuses them outright. By default the AI client sets that flag itself; to make a person approve each delete, turn on the "A person approves" setting or the Pro approval queue. Because drafts never reach the storefront, the safer clean-up after a failed pilot is usually to undo the session or leave the drafts for you to move to the Trash in wp-admin.