How to Prepare Product Data for a WooCommerce Import: Spreadsheet Columns, Images and Variations

To prepare product data for a WooCommerce import, build one spreadsheet row per product — and one extra row per variation — with consistent columns: a unique SKU, name, regular price, stock, categories, attributes and image filenames prepared in advance. Clean the data in the spreadsheet, test with a small file covering each product type, and only then import the full catalogue. This guide explains every core column, the SKU rules, variation rows and the image workflow in order.

Imports rarely fail because the importer is fragile. They fail because the spreadsheet was treated as a rough draft: SKUs that change between files, prices typed as text with currency symbols, categories spelled three ways, image names that match nothing on disk, and variation rows nobody tested. The store then inherits every one of those small untidinesses at scale, multiplied across hundreds of products, where fixing them one by one in the dashboard costs far more time than preparing the file properly once. The good news is that product data preparation is a learnable routine. Work through the columns deliberately, keep one master file as the source of truth, and prove your conventions on a tiny test import before the catalogue depends on them.

The core CSV columns, explained one by one

WooCommerce accepts a CSV file in which the first row names the columns and each following row describes one product or one variation. Column names should match the field names the importer offers to map, so keep the standard names and resist inventing your own labels for standard data. The columns below are the core set most catalogues need; a store may add columns such as weight, dimensions or tax class, but these carry the catalogue.

Column	What goes in it	Preparation rule
SKU	A unique code for this exact product or variation	Unique, stable, no spaces; never reused for a different item
Name	The product name customers see	Consistent format; no HTML; variants described on variation rows, not crammed into the parent name
Published	Whether the product is visible after import	Use the importer expected values; import new ranges as drafts when you want a review pass first
Regular price	The standard selling price as a plain number	Numbers only: no currency symbol, no thousands separators, one decimal convention throughout
Sale price	The reduced price where a sale applies, else blank	Must be lower than the regular price; leave blank rather than repeating the regular price
Stock status / quantity	Availability, or the exact quantity if you track stock	Decide one approach per product type and apply it consistently
Categories	The category path or paths for the product	One agreed spelling per category; build the category list before filling rows
Tags	Optional browsing labels	A short controlled list; tags are not a place to park leftover keywords
Attributes	Size, colour, material and similar structured facts	One attribute set, defined once, with consistent value spellings
Images	Image filenames or URLs, in display order	Names prepared in advance to match the files you will upload, first image is the main image
Description / Short description	The product copy	Plain, finished copy; write it as copy, not as internal notes

Three columns deserve extra care. Prices fail more imports than any other field: a price entered as a formatted currency value, with a symbol or a comma inside it, can import as text, as zero, or split the row at the comma and shift every later column. Enter prices as plain numbers with a full stop for decimals, and open the saved CSV once in a text editor to confirm the rows still line up. Categories fail socially rather than technically: three people preparing data will produce Trainers, trainers and Running Shoes for the same shelf unless the category list is agreed first and pasted, not retyped. Descriptions fail editorially: notes like new version, supplier photo to follow read as carelessness when they go live, so the import file should contain only copy you would happily publish today. For the copy itself, our guide to writing product descriptions that sell gives a structure that works at spreadsheet scale.

SKU discipline: the rule everything else hangs on

The SKU is the identity of a product inside the file and inside the store. The importer matches rows to existing products by SKU, which means a stable SKU turns a second import into an update, while a changed or blank SKU turns it into a duplicate. Adopt a simple, readable pattern and never deviate: a short product stem plus a variant suffix, such as MUG-STONE-01 for a stoneware mug and MUG-STONE-01-BLU for its blue variation, works well for small and mid-sized catalogues. Keep SKUs free of spaces and characters your other systems dislike, keep them case-consistent, and record them in the master file only — if a SKU is invented in a chat message or a notebook, it does not exist. Retired products keep their SKUs retired with them. Reusing a code for a new product corrupts order history, stock records and every future import that touches either item.

Variation products: parent rows and child rows

A variable product, such as a shirt in three sizes and two colours, is not one row with the options typed into a notes field. It is a small family: one parent row that defines the product and declares its attributes, followed by one child row for each purchasable combination. The parent row carries the name, description, categories, images and the attribute definitions, with the values listed. Each child row carries its own unique SKU, the specific attribute values for that combination, plus its own price and stock, because a large blue shirt can sell out while the small white one remains. Combinations you do not sell should simply have no child row; do not create rows for them and hide them later.

The chart counts rows, not products, in the 24-row practice file used while preparing this guide: 10 simple product rows, 4 variable parent rows and 10 variation rows. Read it as a workload warning. The four variable products generate fourteen of the twenty-four rows, because each parent brings its children with it. A catalogue that looks small in product count can still be a large data job once variations are counted honestly, and planning the spreadsheet around rows rather than products prevents the classic mid-project surprise.

Preparing images: naming, sizing and compression

Images are the column most often left until last and the one that causes the most visible mess. Prepare them as a batch, before the import, in three passes. Naming first: rename each file to match its product and view, following one pattern such as the SKU plus a sequence number, for example mug-stone-01-1.jpg for the main view and mug-stone-01-2.jpg for the detail view. Descriptive, consistent names keep the Images column honest, make missing files findable in seconds, and stop the store filling with camera-default filenames that mean nothing to anyone. Sizing second: export every image at one crop ratio suited to your product layout, commonly square, at the largest size your pages display, so the store can generate its smaller versions from a good master. Photographs that arrive in mixed shapes produce category pages that look untidy no matter how good the theme is; our online store product photo guide covers shooting and framing for a consistent catalogue.

Compression third: resized masters still need their file weight controlled, or category pages slow down under dozens of heavy images. Once files are named and sized, work through preparing images at a sensible file size without losing visible quality as the final pass before upload, so the filenames in your spreadsheet and the compressed files on disk stay the same set. Keep the uncompressed originals in a separate archive folder outside the upload set. The spreadsheet Images column should then list exactly the prepared filenames, in display order, first file as the main image. After the test import, open each test product and confirm the main image, gallery order and alt text are what the file promised.

A sample mini-catalogue: three example products

SKU	Name	Type	Regular price	Stock	Category	Images
CANDLE-SOY-01	Soy Candle — Cedar and Sage	Simple	24.00	In stock	Home > Candles	candle-soy-01-1.jpg, candle-soy-01-2.jpg
TEE-ORG-01	Organic Cotton T-Shirt	Variable (parent)	—	—	Clothing > T-Shirts	tee-org-01-1.jpg, tee-org-01-2.jpg
TEE-ORG-01-WHT-M	Organic Cotton T-Shirt — White, Medium	Variation	32.00	14	(inherits parent)	tee-org-01-wht-1.jpg

Even three rows teach the conventions: the parent row carries no price of its own because its children carry theirs; the variation SKU extends the parent SKU with its colour and size; prices are plain numbers; the category path is spelled once and reused. Prices in this sample are illustrative placeholders chosen to show format, not recommendations for any real product. Scale the same discipline to three hundred rows and the import becomes a verification exercise rather than a rescue operation.

Common import errors and their fixes

Symptom after import	Likely cause in the file	Fix
Duplicate products everywhere	SKUs blank, changed or inconsistent between files	Restore stable SKUs in the master file; remove duplicates deliberately before re-importing
Prices showing as zero or missing	Currency symbols, commas or spaces inside price cells	Re-enter prices as plain numbers; inspect the CSV in a text editor before importing
Columns shifted, data in wrong fields	A comma or line break inside an unquoted cell	Save with proper CSV quoting from the spreadsheet; check long description cells
Products in the wrong categories	Category spellings drifted between preparers	Agree the category list first; use find-and-replace to normalise spellings in the file
Variations missing or unselectable	Child rows lack attribute values, or the parent does not declare the attributes	Rebuild one variable product by hand, mirror its exact row pattern, then fix the rest
Wrong or missing images	Filenames in the sheet do not match the uploaded files	Compare the Images column against the upload folder listing; rename files or fix the column, never both at once

Five data mistakes that follow a store for years

• Letting the SKU be optional. Every downstream process — updates, stock checks, re-orders — leans on the SKU. A catalogue launched without disciplined SKUs pays for the omission at every later change.
• Preparing data in several files owned by several people. Conventions drift within days. One master file, one owner, contributions checked before they enter it.
• Typing prices the way humans display them. Symbols, separators and spaces are presentation. The file needs numbers; let the store format them for display.
• Testing with one simple product only. A test that never includes a variable product proves nothing about the rows most likely to break. Cover every type you sell.
• Importing the full catalogue first and checking later. Errors found after hundreds of products are live become a cleanup project. Errors found in a ten-row test are a five-minute file fix.

Pre-import checklist

• Every product and variation has a unique SKU, recorded only in the master file.
• Prices are plain numbers, one decimal convention, sale prices lower than regular prices or blank.
• The category list was agreed before rows were filled, with one spelling per category.
• Attributes are defined once, with consistent value spellings across all rows.
• Every variable product has a parent row plus one child row per purchasable combination.
• Images are named by the agreed pattern, sized consistently, compressed, and listed in display order.
• The saved CSV was opened in a text editor and its rows line up column by column.
• A small test import covered one of each product type, and every field was checked on the live test products.
• A backup of the store exists, and the full import is scheduled with time to verify the same day.

Conclusion: clean file, calm import

A WooCommerce import succeeds or fails in the spreadsheet, long before the importer runs. Unique and stable SKUs, plain-number prices, an agreed category list, honest parent and child rows for variations, plus images named, sized and compressed as one batch: those five habits turn importing from a gamble into a routine. Prove them on a small test file, then scale with confidence.

Frequently Asked Questions

What is the most important column in a WooCommerce import file?

The SKU. It is the identifier the importer uses to match rows to products, so it decides whether a re-import updates an existing product or creates a duplicate. Give every product and every variation a unique, stable SKU before the first import, keep the values in a master file, and never reuse a retired SKU for a different product.

Can I import products without images and add them later?

Yes. Prepare the image column with filenames or URLs when you can, because adding images product by product afterwards is slow, but a catalogue can launch with core data first if image work would otherwise delay everything. If you do phase the work, keep a list of which SKUs still need images so none are forgotten, and keep the file naming consistent so the later upload matches the plan.

How do I import variable products like sizes and colours?

Use a parent row for the variable product itself, carrying the attribute names, followed by one child row per variation, each with its own SKU, its attribute values, plus its own price and stock. The parent row ties the children together. Test one variable product end to end in a small import before preparing hundreds of variation rows the same way.

Why did my import create duplicates instead of updating products?

Almost always because the matching key changed: SKUs were edited, left blank, or regenerated between imports, so the importer treated each row as a new product. It can also happen when a first import used product IDs and a later one used SKUs inconsistently. Fix the master file so SKUs are stable, then clean the duplicates deliberately rather than importing again and compounding the problem.

What image size should product photos be before import?

Prepare images at the largest size your product pages actually display, commonly a square in the region of 1200 pixels for zoom-friendly product views, then compress them so file sizes stay modest. Consistency matters more than any single number: one crop ratio, one naming pattern, and files checked on a real product page after a test import. Resize oversized originals first, then compress the resized files.

Should sale prices and stock live in the import file or be managed in the dashboard?

Keep the master spreadsheet as the source of truth for launch data: regular price, sale price where a launch offer applies, stock status or quantities, categories and attributes. After launch, day-to-day stock and price changes usually happen in the dashboard or through your stock system, so decide who owns updates from that point and stop editing the old import file, or the two records will drift apart.

How large a first import should I run?

Small. Run a test file first with a handful of products covering each type you sell: one simple product, one variable product with its variations, and one product with several images. Check every field on the live test products, fix the file conventions, and only then prepare and import the full catalogue in batches you can verify the same day.