How a Shopify CSV import overwrites products, and how to see what it changed

Shopify decides what to change from the handle and the columns in the file

A Shopify product import does not look at product titles. It matches each row to an existing product by the URL handle, and it reads only the columns that are present in the file. Those two facts explain most surprising results. If a row carries a handle that already exists and the overwrite option is ticked, every value in that row's columns replaces what the product holds. If the overwrite option is not ticked, the same row is skipped and the product keeps what it had.

Column headers must also match exactly. Shopify documents that headers are case sensitive, so a lowercase handle column is not the same as the header it expects, and a missing or mismatched header makes the import fail rather than guess.

• A product is identified by its handle, not its title.
• Overwrite on means matching products take the file's values for the columns it contains.
• A column absent from the file is left alone, so deleting a column is a way to protect a field.

Three ways an import quietly damages products you did not mean to change

The first is the blank cell. Shopify documents that a blank cell in a non-required column erases the stored value, so a vendor column exported empty from another system clears every vendor on every matching product. The fix is to remove the column from the file, not to leave it blank.

The second is a variant column without its option columns. If the file includes something that belongs to a variant, such as the SKU or weight, but not the option name and value columns, Shopify can create a new default variant and delete the existing ones. A product that had sizes and colours ends up with one variant. The third is an option value change. Changing the value of an option deletes the existing variant IDs and creates new ones, and the page warns this can break third-party tools that rely on those IDs. A spreadsheet cannot put the old IDs back.

• Sorting a file in a spreadsheet can break the link between a product row and its image rows, so images are lost or misattached.
• Curly quotes and files that are not UTF-8 cause quoting errors and garbled characters.
• Moving an existing option to a different position in the same import can fail with a "Line is invalid" message; the documented workaround is to import under a temporary option name first, then again with the final name.

What you cannot rely on afterwards

Shopify tells you plainly that an import cannot be cancelled once it starts and that there is no import history. A confirmation email arrives after upload, and the store activity log shows changes, but neither gives you the old values. The only way back to the old values is a file that holds them, which is why the advice on the import page is to export your products first and to test large imports on a development store.

That also sets the practical limit on any repair. If there is no export from before the import, and no supplier or source file with the right values, nobody can know what to put back. The repair is then a data-entry decision for you, not something a file can solve.

A safe first investigation, with no logins shared

Do not import again yet. A second import with overwrite on can damage the products a second time. Instead, take a fresh export of the affected products today so the current state is preserved, find the export taken before the damaging import, and find the file that was imported. Open the three files side by side.

• Compare the header rows. Look for headers that exist in one file and not another, and for a column that was empty in the imported file.
• Pick three affected handles and compare every column across the three files.
• Count the variant rows per handle in the pre-import export and in the current export.
• Look at the store activity log for the time of the import to confirm which products it touched.
• Check whether an app depends on variant IDs, such as subscriptions, bundles or inventory sync.

What fixes it, and what does not fit

A repair is a corrective file that holds only the affected handles and only the columns that need restoring, built from the pre-import reference. It should be imported on a separate test store first, one that has been loaded with the damaged products so the test starts from the same damage, then re-exported and compared with the reference. Only when that comparison shows no differences should the same file be imported on the live store, after another fresh export as a safety copy.

Some things a file cannot fix. It cannot restore variant IDs that Shopify discarded. It cannot restore stock counts for a store with more than one location, because the inventory quantity column in the CSV applies to single-location stores only. It cannot fix problems that were never in the product data, such as a theme that displays a field badly.

How the paid repair is accepted

The fixed job for this problem, put products back after a damaging import, is accepted on evidence you can check yourself: a fresh export from the test store, which first showed the damage, matches your reference in every agreed column for every agreed product, variant counts and option values match, and the corrective file touches only the agreed handles and columns. We work from your files and a test store; we do not log in to the live store, and you run the live import.