Testing a WooCommerce product import on a sample set first

A product import can change a large amount of catalogue data quickly. That makes a small test set valuable. It reveals how columns are interpreted, which existing data is updated and whether product relationships are preserved. Start with representative exceptions, rather than an arbitrary first group of simple items.

Choose a test set that represents the catalogue

Include a new simple product, an existing product to be updated and a product with variations. Add an item with several images and a long description if those occur in the range. The set needs to cover the fields and relationships actually used. Successfully importing only a title and price says little about more complex data.

The built-in WooCommerce CSV importer uses column mapping and can update existing products. Check the current documentation for supported data and the file format used. Do not assume fields from every external extension are automatically included.

Record the expected change beforehand

In a fictional store, an existing product needs a new description and image while its SKU stays the same. Before importing, note which fields should change and which should remain unchanged. Checking only whether the product is visible afterwards can leave unwanted changes to other fields unnoticed.

Also check the meaning of empty cells and identifier fields within the chosen import settings. An empty value may be treated differently from a missing column. Base the approach on a checked trial, not on how a spreadsheet looks. Keep the original and imported files with clear versions.

Check the result in administration and in the store

Compare the test products with expectations field by field. Then open the public product pages in the test environment. Check text, images, categories and variation choices. Add representative items to the basket to see whether the chosen variation remains recognisable.

For a new online store the test import can be combined with reviewing the product design. This reveals whether missing source information also creates a presentation problem. A card that cannot show distinguishing features may need better data before its design is changed.

For a relationship with AFAS it must also be clear which data will later be managed through synchronisation. A manual import must not quietly become a competing source for the same fields.

Review descriptions with punctuation, lists and special characters too. An import can handle product identity correctly while truncating text unexpectedly or displaying formatting as ordinary characters. Include at least one content-rich test product. Check its final readability in the store, not just the cells in the supplied file.

Scale up with checkpoints

Process a larger set only after the trial’s discrepancies are understood and resolved. Choose manageable batches and record the number of products expected and processed. Investigate the underlying content cause of errors. An import warning about one row may point to a source problem present throughout the catalogue.

  • Product identity is recognised unambiguously.
  • Field mappings are deliberately chosen.
  • Variations belong to the correct parent products.
  • Images and text are appropriate to the products.
  • Source responsibility after import is agreed.

Also define in advance how an incorrect import will be recovered without overwriting new store data. This requires an appropriate testing and recovery strategy for the environment. The test set ultimately provides more than confidence in a button: it becomes repeatable evidence for the chosen import method and a practical check for future catalogue changes.

Previous insight
Next insight

Start with your question

Where does your team get stuck?

Your first enquiry does not need to be a technical brief. Tell us which systems you use and where work gets stuck. Together we discuss what is possible and which step you can take next.

Discuss my project