Shopify CSV Import: Where the Native Importer Breaks and When to Stop Using It

The importer is better than its reputation and worse than you need

Shopify CSV import is the first bulk tool every merchant meets. It is free, it is built in, and it will get you from zero to a few hundred products faster than anything else.

It also has a small set of behaviours that are not obvious, are not warned about, and can quietly destroy data that other systems depend on. This post is those behaviours, and the honest line for when to stop using it.

The rules that are not on the screen

The file cannot exceed 15 MB. If your upload errors or times out, the fix is to split it into smaller files. Note that 15 MB of CSV is a lot of rows — you will usually hit this because of long HTML product descriptions, not because of SKU count.

`Handle` is the key. With "Overwrite any current products that have the same handle" enabled, a handle in your file that matches an existing product means the CSV values overwrite the matching columns on that product. That is the whole update mechanism. There is no ID matching, no SKU matching, no "update if newer."

One row per variant, product fields on the first row only. The first row of a handle carries title, body, vendor, type, tags. Subsequent rows for the same handle carry only variant data. Additional images get their own rows with just the handle and the image columns.

Never sort the file in a spreadsheet editor. This is Shopify's own warning and it is the one that catches people: sorting a product CSV in Excel or Numbers can separate products from their image rows, and the images are lost. The row order is structural. If you need to sort to review the data, sort a copy and import the original.

You cannot delete products with a CSV. There is no delete command. Bulk deletion is a different workflow entirely.

An import cannot be cancelled once it starts. There is no stop button. If you realise thirty seconds in that you uploaded the wrong file, your options are to wait and then repair. Which is why the next section exists.

There is no import history. You cannot open a list of past imports and see what changed. The activity log is the closest thing, and it is not a diff.

The one that costs the most

This is the behaviour I would put on a warning sticker:

Changing data in the Option1/Option2/Option3 value columns deletes the existing variant IDs and creates new ones.

Renaming "Med" to "Medium" is not an edit. It is a delete and a create. The variant is gone and a new variant with a new ID takes its place.

Shopify says plainly that any change to variant ID values can break third-party dependencies, and in practice the list is long: inventory records tied to the old variant, third-party inventory and ERP syncs keyed on variant ID, subscription contracts, back-in-stock waitlists, wishlist entries, Klaviyo product references, ad platform catalogues, and any ?variant= URL sitting in a live campaign or an email that has already gone out.

Nothing about the import tells you this happened. The product page looks correct afterward. The store looks fine. What breaks is everything downstream, days later, in a way that never gets traced back to a tidy-up of option names.

If you need to normalise option values across a catalogue — and everyone does eventually, because "Med / Medium / M" accumulates — treat it as a migration with a plan for the downstream systems, not as a spreadsheet cleanup.

Working safely inside the native importer

If the native importer is the right tool for where you are, these five habits cover most of the risk:

Export first, always. The export you take before the import is your rollback file. There is no undo, so this is the undo.

Import only the columns you are changing, plus the handle. The importer overwrites matching columns. Every extra column you include is an assertion about a field you did not look at. A price update is a handle, a SKU and a price — not forty-one columns.

Test on five rows. Import five, open them in the admin, look at them. Then import the rest. The five-row test catches encoding problems, column-name typos and option-value surprises for the cost of two minutes.

Format ID-shaped columns as Text before you paste. A 13-digit identifier pasted into Excel becomes 1.05E+13. This is the single most common cause of an import that reports success against zero matched rows.

Never sort. Never re-save through a tool that re-encodes. Especially watch out for anything that converts to UTF-16 or strips the BOM.

Where the native importer stops being enough

There is a real line, and it is not about SKU count. It is about what you need to touch.

The native product CSV covers products, variants, images and the basic Google Shopping fields. It does not give you a comfortable path to:

• Metafields across the catalogue, which is where the actual differentiating product data lives on any serious store.
• Inventory per location, once you have more than one.
• URL redirects, which you need every time a handle changes.
• Collections, customers, orders, pages and discounts as bulk-editable objects.
• A dry run. There is no "tell me what this would do" pass. You find out by doing it.
• A results file. You cannot open a per-row report of what changed after the fact.
• Deletion, at all.

The moment your recurring work includes metafields, redirects, or multi-location inventory, you are fighting the tool. And the moment a bad import would cost real money — a price change, a status flip on a live product, a redirect on a page with paid traffic pointed at it — the absence of a dry run stops being an inconvenience and becomes the actual risk.

That is where I move stores to Matrixify for bulk catalogue operations. What you buy is not speed, it is safety: an Analyze pass that reports what would change per row before anything is written, per-field commands so a tag import appends instead of wiping, a results file you can read afterwards, and coverage of every object type instead of just products.

The discipline I run there is a separate piece — the Matrixify field guide covers the command columns, the key-column choice, and the rollback-asymmetry rule that decides how hard I review a given file.

The honest recommendation

If you are under a few hundred products, changing only product-level fields, and not syncing to anything downstream: the native importer is fine. Use it. Keep an export as your rollback and test five rows.

If any of these are true, you have outgrown it:

• Your catalogue feeds a marketplace, an ERP, a PIM or a retail partner.
• Your product data lives in metafields.
• You have more than one inventory location.
• Anyone will notice within an hour if a price is wrong.
• You have ever needed to answer "what exactly did that import change?"

The upgrade is cheap relative to a single bad import. And the muscle you are building either way is the same one: never let an unreviewed change reach a live catalogue.

Related services

Bulk product upload, CSV and Excel workflows, metafield backfills and inventory sync are Matrixify expert services. If the catalogue problem is really a platform problem, see Shopify migration expert. For everything else on the storefront, Shopify expert development. Related reading: the Matrixify field guide.

I run catalogue operations on stores from a few hundred SKUs to enterprise-scale multi-variant catalogues. See [Matrixify expert services](/matrixify-expert) or [hire a Shopify developer](/hire-shopify-developer).

Direct: [WhatsApp +55 11 98851-2788](https://wa.me/5511988512788) · [contato.matheusabrahao@gmail.com](mailto:contato.matheusabrahao@gmail.com)