What a Shopify CSV export actually leaves out

Why this list exists

"I export to CSV every week, so I have a backup" is a sentence we hear a lot, and it is half true. The file exists and it is yours - that part is real. The other half depends entirely on what is in the file, and the honest answer is: less than the store, and less than most people assume. This page is the itemised list, checked against Shopify's own documentation in August 2026. Where the CSV is better than its reputation, we say that too.

Better than its reputation: metafields with definitions

The old advice said metafields never survive a CSV. That is out of date. Once a product metafield has a definition, it gets its own column in the product export. If your custom fields live in defined metafields, the CSV carries them.

The catch is the word "defined". Metafields created by apps without a definition do not travel, and product metafields are the well-served case - the further you get from products, the thinner the coverage. Check your own export: open it and look for columns named like product.metafields.namespace.key. What you do not see there, you do not have.

Collection membership: exported never, imported only

This one surprises people in the worst direction. The product import accepts an optional Collection column, so it feels like collections are covered. But the export does not include that column at all - Shopify's documentation says so explicitly. Round-trip a store through CSV and every product comes back belonging to nothing. Smart collection rules and the collections themselves - titles, descriptions, images, ordering - have no CSV anywhere.

Orders: export yes, import no

The orders export is genuinely rich - line items, addresses, transaction references, tags, timestamps. Keep taking it, it is the copy of record for accounting. But there is no order import in the admin. An order CSV is an archive you can read, not a state you can put back. Any recovery story that involves "re-importing the orders" is not describing Shopify.

The same one-way property holds for backup apps, which is why we call orders an archive rather than a restore - the platform decides that boundary, not the vendor.

Customers: the person, not their history

The customer export carries names, contacts, addresses, tags. What it does not carry is what makes a customer record valuable on a bad day: their order history lives in the orders, and the link between the two is not something an import reconstructs. Import a customer file into a fresh store and you have a mailing list, not customers.

Images: URLs, not files

The product CSV stores an image as a URL, and the import re-downloads from that URL. While the product exists, the URL points at Shopify's CDN and everything works. Delete the product and try to bring it back months later, and the import is fetching from a URL that may no longer serve the file. The CSV never contained the image - it contained directions to where the image used to be.

No CSV at all

Themes, pages, blog posts, navigation menus, metaobjects, discounts, app configuration: none of these have a CSV export. The one pleasant exception is URL redirects, which can be exported and imported from the navigation settings - worth doing before any migration, because redirects are exactly the thing nobody remembers until search traffic drops.

And the part no export has: time

Every gap above is about width - which fields, which types. The deepest gap is about depth: a CSV is one moment, and it is always the moment you exported, never the moment before the mistake. Which 40 products did the pricing app touch overnight? A folder of weekly CSVs answers that with a diff exercise across spreadsheets, if the right week exists. A versioned backup answers it with the record's own history.

Our advice has not changed: keep exporting. A CSV before every bulk edit is the cheapest insurance there is. Just know which of your store's parts are actually in the file - and let something with versions cover the rest. If a bulk edit already went wrong, start here.