A core product CSV is a catalog mutation plan. Protect IDs, SKUs, parent relations, media, and update intent before expanding beyond a small controlled import.
WooCommerce core includes a product CSV importer and exporter under Products > All Products. The separate premium Product CSV Import Suite uses a different schema. A file prepared for one should not be partially renamed and sent to the other. Start by confirming that the destination workflow is the built-in core importer described in the official WooCommerce product CSV documentation.
Core headers include ID, Type, SKU, Name, Published, Regular price, Images, and Parent. Dynamic families add numbered attribute and download columns, while meta: headers can carry custom metadata. Preserve exact spelling and punctuation because the mapping screen treats unknown columns separately.
The private WooCommerce product CSV validator detects core, premium-suite, hybrid, and unknown signatures. Its optional safe repair is deliberately narrow: it can correct case or outer whitespace when one exact core header matches. It never guesses that a business column should become price, stock, taxonomy, image, attribute, or metadata.
A product import mutates WordPress and WooCommerce records. Export the current catalog before an update, copy the database and uploads according to the store's operating procedure, and use staging when possible. Record the store, environment, plugin set, theme, currency, weight and dimension units, and the person responsible for rollback.
The update option matches products by ID or SKU. WooCommerce documents that products not found by those identifiers are skipped. Every update row therefore needs a stable ID or SKU, and those identifiers must refer to the destination store rather than a different environment. A local file cannot prove that they exist or identify the record they will match.
For new products, do not treat the ID column as a way to assign chosen WordPress IDs. WooCommerce uses the next available ID. Keep SKU strategy explicit because a missing SKU may be generated, but stable unique SKUs make updates, parent relationships, grouped products, upsells, and cross-sells easier to audit.
Save core product CSVs as UTF-8. Use one header row, standard comma-separated quoting, and a consistent field count. Quote any cell that contains commas, line breaks, or quotes, and double quotes inside a quoted cell. The validator reads raw CSV bytes with fatal UTF-8 decoding and normalizes approved output to UTF-8 with LF record endings.
There is no universal WooCommerce core file-size number that is safe for every store. PHP upload, memory, execution, proxy, and host limits vary. Treat the actual byte count as server evidence to test, not a pass/fail threshold. Split large jobs into controlled batches and keep relationship rows together.
Core fields use documented tokens. Published values can represent published, private, draft, or pending states. Boolean fields generally use 1 and 0; catalog visibility, tax status, and backorders have their own enums. Prices and dimensions are plain numbers without currency symbols. Dates use the store's local timezone, so compare sale start and end deliberately.
A variable parent uses Type=variable and complete attribute groups such as Attribute 1 name plus Attribute 1 value(s). Visibility and global flags use boolean tokens. The parent's values describe the available choices; keep names and global taxonomy usage consistent with the destination store.
Each variation uses Type=variation, a unique SKU and Name, and a Parent that matches the parent's SKU or an id: reference. Variation attribute cells should identify one choice. If several values appear in a variation cell, the importer may use only the first, which makes the row ambiguous and worth correcting before import.
The validator resolves parents that are present in the same file and blocks a local match whose Type is not variable. A Parent that points outside the batch is marked unresolved rather than invalid because the record may exist in the store. That is still a manual review item, not proof of a working relationship.
Core product Type tokens include simple, variable, grouped, external, variation, virtual, and downloadable, with documented combinations where applicable. External products need an External URL. Grouped products normally reference component IDs or SKUs. Upsells and cross-sells use the same reference idea: existing IDs carry an id: prefix while SKUs do not.
Stock may be numeric, while a variation can inherit from its parent with parent. In-stock, sold-individually, review, featured, tax, and backorder behavior all use documented tokens. Local validation can detect malformed shapes and contradictions, but it cannot query warehouse state, backorders, tax classes, shipping classes, or extensions that modify inventory.
Downloadable products need numbered Download URL columns. Download limit and expiry accept nonnegative whole numbers or n/a. The preflight checks HTTP(S) syntax without requesting a file, so authorization, redirect behavior, media type, range support, licensing, and availability remain external dependencies.
The core importer can use a filename for an image already uploaded to the site or a directly accessible external HTTP(S) URL. Scripted redirect URLs are not a reliable substitute. The validator checks each comma-separated image reference as text and makes no request, so it cannot prove reachability, permissions, dimensions, media type, or import success.
WooCommerce core's documented importer cannot add, edit, or update image alt text. Plan alt-text work separately in the media library or an approved workflow. Do not add a guessed alt-text header and assume the mapping screen will apply it.
Categories use > for hierarchy. A literal comma inside a category name needs the documented escaping, while comma-separated lists still require correct CSV cell quoting. Tags, shipping classes, tax classes, global attributes, and metadata also depend on definitions in the destination store. Syntax is not existence.
Run the complete file through the validator. Resolve blockers, then read every warning and review item. The normalized download changes only approved exact header repairs, CSV quoting, UTF-8 serialization, and LF endings. It preserves source row order, duplicate positions, empty cells, and cell strings rather than coercing product data.
Download the relationship-safe test batch and inspect it in a plain-text editor. It selects the first ten root or non-variation rows and every variation whose Parent matches one of those selected root IDs or SKUs. Reduce the batch further when one product is high value or complex, but never detach variations from the parent you intend to test.
In WooCommerce, choose the core importer, upload the test, inspect the column mapping, and leave unrecognized columns unmapped unless you understand their destination. For updates, select the existing-product update option only after confirming IDs and SKUs. Keep the backup, source file, normalized test, and aggregate report together.
Open every test product in the admin and storefront. Check name, status, catalog visibility, type, SKU, price, sale dates, tax, stock, backorders, weight, dimensions, shipping, reviews, notes, categories, tags, images, downloads, external links, grouped relations, upsells, cross-sells, attributes, variations, and parent behavior that matter to the store.
Compare expected and imported root and variation counts. Select each variation, add representative products to a cart, open downloadable or external actions, and confirm that media belongs to the correct item. For updates, compare previously populated values specifically so accidental blanks, skipped rows, or identity mismatches are visible.
If rows fail or skip, check duplicate or existing IDs and SKUs, whether update mode was selected, invalid schema values, product status, and server limits. Plugin or theme conflicts can also affect imports. Fix the smallest understood cause, rebuild a relationship-safe test, and repeat before scaling the batch.
Yes. This local preflight checks the built-in core schema, headers, row widths, product types, identities, values, variable-parent relationships, images, downloads, and import intent. It cannot query your store or guarantee acceptance.
No. WooCommerce core and the separate premium Product CSV Import Suite use different schemas. The validator detects suite and hybrid signatures, then blocks them instead of guessing a conversion.
No. Parsing, validation, masked evidence, normalization, the test batch, and reports remain in the browser tab. Image and download URLs are never requested.
Variation rows need a unique SKU and Name plus a Parent ID reference or SKU. Locally matched parents must be type variable, and attribute groups are checked for complete names, values, and flags.
It contains the first ten root or non-variation rows and every variation whose Parent matches a selected root ID or SKU. It preserves source order and cell strings.
No. The core product CSV importer can use preuploaded filenames or accessible image URLs, but its documented limitations say it cannot add, edit, or update image alt text.
There is no single core byte limit that applies to every store. The practical maximum depends on server upload and execution settings, so back up, use staging, and split large imports.
No. Local evidence cannot prove server limits, plugin or theme behavior, taxonomy, media reachability, current IDs or SKUs, stock state, or downstream acceptance.