{"id":372,"date":"2026-10-12T10:00:00","date_gmt":"2026-10-12T08:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=372"},"modified":"2026-09-21T22:09:34","modified_gmt":"2026-09-21T20:09:34","slug":"woocommerce-csv-proefimport","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/testing-a-woocommerce-product-import-on-a-sample-set-first\/","title":{"rendered":"Testing a WooCommerce product import on a sample set first"},"content":{"rendered":"

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.<\/p>\n

Choose a test set that represents the catalogue<\/h2>\n

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.<\/p>\n

The built-in WooCommerce CSV importer<\/a> 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.<\/p>\n

Record the expected change beforehand<\/h2>\n

In a fictional store, an existing product needs a new description and image while its SKU stays the same<\/a>. 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.<\/p>\n

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.<\/p>\n

Check the result in administration and in the store<\/h2>\n

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.<\/p>\n

For a new online store<\/a> 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.<\/p>\n

For a relationship with AFAS<\/a> 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.<\/p>\n

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.<\/p>\n

Scale up with checkpoints<\/h2>\n

Process a larger set only after the trial\u2019s 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.<\/p>\n