How to bulk edit Shopify products without CSV files

A bulk edit is one rule applied to many rows. The rows are products, or variants, or variants at a location. The rule is a constant ("set vendor to Kestrel"), a transform ("increase by 10 percent, round to .99"), a template ("title plus the collection name"), or per-row generation (alt text written from the image). The four methods below differ in which rules they can express and how much of the result they show you before writing.

The level matters more than merchants expect. A price is per variant. A tag is per product. Inventory is per variant per location. A rule written at the wrong level either fails or touches more rows than intended, and that is the most common way a bulk edit does something different from what was meant.

Products, select some, "Bulk edit". A table with the columns you choose: price, compare-at price, quantity, tags, status, vendor, type, a few metafields. Type into cells, or select a column and set one value for every row. Save.

It is the right tool when you can see every row you are changing. Twenty products, one field, values you can type: the bulk editor is faster than anything else. It has no filter beyond the product list search and its saved views, no formula (you cannot say "increase by 15 percent"; you type each new price), and no undo. Variant rows are inside each product and have to be expanded one product at a time. Pages are fifty products; a change across five hundred is ten pages.

It does reach a few things the other methods reach awkwardly: sales channel publishing is a column, and so is product status, and both are single clicks per row.

Export, edit in a sheet, import. It scales to any size and it is auditable: the file is the record of the change. It is also the method with the most ways to go wrong, because the spreadsheet is a general tool that does not know what a Shopify product is.

Five things go wrong often enough to list. Tags in the CSV replace the product's tags; they do not add to them. Spreadsheets reformat "29.99" into a number with the locale's decimal separator, strip the leading zero from SKUs, and turn a thirteen-digit barcode into scientific notation. An empty image column clears the images on import. Variants are rows with the handle repeated, so a product with eight variants is eight rows, and a row count that does not match the variant count means a variant was lost or duplicated. And there is no undo except the export you made before.

The safe pattern is to import only the columns you changed. Export, delete every column except the identifiers and the one you are editing, edit, import. A file with three columns cannot clear your images. Matrixify adds an "update only" mode that refuses to create, an import log per row, and scheduling; for a migration or a supplier feed it is the right tool and this site says so on every page that mentions it.

Matrixify, Ablestar, Hextom, QuickEdit. They add what the admin lacks: filters by collection, vendor, tag, price or inventory with AND and OR; formulas; scheduling; a preview of the target rows; and a backup window for undo, 30 to 180 days depending on app and plan. Each is compared in detail elsewhere on this site; the shape is what matters here.

The shape is a task: you configure a filter and an action in a form, look at the count, preview, run. The cost is the configuration. Each change is a task you build before it runs, and the task builder has the fields and conditions it has. "Everything tagged sale except anything already discounted" is two conditions if the builder has a compare-at condition, and a workaround if it does not.

That pays off when the same task runs every month. A markdown that starts Friday and ends Monday is a saved task on a schedule, and no other method does that as cleanly. It does not pay off for a one-off change you could say in a sentence, because the task takes longer to build than the change takes to check.

You type the change. "Raise prices by 10 percent only for XL variants, round to .99, skip anything already on sale." The tool reads the variants in scope, builds one row per change, and shows them: current value, new value, the reason the row is in scope, and the count at the top. Nothing is written until you approve. The previous values are saved per row at write time, so the job can be reverted as a job.

It is the shortest path from a sentence to a reviewed change, and it is the only method that writes per-row text: alt text from the image, a meta description from the description, a title rewritten to a pattern with exceptions. It also answers questions before the write. "Which products have no vendor?" is a report with no approval, and the fix is the next sentence.

It is not a spreadsheet. A supplier file with 5,000 rows of new prices and images belongs in CSV, not in chat, and a good chat tool says so. It is not a scheduler either; a sentence that should run every Friday is a sentence you send every Friday, or a task in an app.

Six jobs merchants actually run, and what each method makes of them. "No" means the method cannot do it, not that it is slow.

Not every method reaches every field. This is the table merchants look for after the first tool they tried did not have the column.

Most product fields are actually variant fields. Price, compare-at, SKU, barcode, weight, inventory: all per variant. A product with four sizes has four prices. A bulk edit that "sets the price to 49" on a product sets it on every variant, which is usually what you meant for a single-variant product and never what you meant for a sized one.

In the admin bulk editor, variant rows are inside each product and expanded per product. In CSV, each variant is its own row and the product fields repeat on the first row only. In apps, you choose the resource (products or variants) before you build the filter. In chat, you say the level: "every XL variant" versus "every product".

Structural edits (adding a size to every product, removing a "Ships From" option, renaming "Color 3" to "Navy" across products) are a category on their own. The admin does them per product on the options screen. CSV does them badly, because removing an option column collides on re-import. Most apps do not do them. Chat does them with a per-variant preview that states which variants stay and which go, because deleting an option deletes variants.

Three questions, whatever the tool. If the tool cannot answer them, do a smaller test first, and read the page on undo before the real job.

The question that decides the method is not which tool is best. It is where the change starts and whether it repeats.