What product image versioning actually has to answer
Versioning is often mistaken for a naming habit. It is really a set of questions your records must be able to answer for any image, on any day, without asking the person who made it:
- Which file is live right now for this SKU and this slot (hero, back, detail, lifestyle)?
- What did it replace, and can that earlier file be restored in minutes?
- Why was it changed: a reshoot, a retouch correction, a new brand standard, a product change?
- What was it made from: which original capture, and which edits sit between that capture and the published file?
- Where else is it used: marketplaces, feeds, email templates, wholesale line sheets?
If you can answer all five, you have versioning, whatever your filenames look like. If you cannot, a tidy _v3 suffix is decoration.
The reason this gets harder with scale is arithmetic. A catalog of 500 products with six images each is 3,000 live files. Refresh a third of them once a year and add two channel-specific crops per image, and you are tracking several thousand new files annually on top of the ones they replaced. Nobody holds that in their head, and a folder tree alone does not hold it either.
Three layers: master, working file, published derivative
Most version chaos comes from treating every file as the same kind of thing. Separate them into three layers and give each layer its own rules.
| Layer | What it is | Can it be overwritten? | Versioned how |
|---|---|---|---|
| Master | The original capture (RAW or the highest-quality file the camera or supplier produced) | Never | One per capture; a reshoot creates a new master |
| Working file | The edited, full-resolution result: retouched, background set, colour corrected | No, save a new version | Version number increments on every approved edit |
| Published derivative | The resized, compressed export a channel actually serves | Yes, it is regenerable | Inherits the version of the working file it came from |
The rule that does most of the work: derivatives are disposable, working files are append-only, masters are untouchable. A 1600px WebP for the storefront does not need its own history, because you can always regenerate it from working file v3. What you cannot regenerate is the working file itself once someone saves over it, or the master once it is deleted to free up space.
Keeping only the published JPEG. Every later edit then starts from a compressed, resized file, and quality degrades a little with each round. If storage is tight, drop old derivatives first, never masters.
A version label that survives contact with real work
A label scheme has to be simple enough that a freelancer follows it on day one. A workable pattern is a stable identifier plus a slot plus a version:
SKU_slot_v## → TB-4410-NVY_hero_v03.tif
Three details keep it from collapsing:
- The version describes the content, not the export. The storefront WebP, the marketplace JPEG and the square social crop made from v03 are all v03. If exports get their own counters, you lose the ability to say which channels are in sync.
- Zero-pad the number.
v03sorts beforev10;v3does not. - Ban the words "final", "new" and "latest". They are true for about a week. The highest approved number is the current version; nothing else needs saying.
Decide up front what earns a new number. A sensible line: any change a customer could see creates a new version (retouch, colour correction, crop, background, a reshoot). Changes a customer cannot see, such as recompressing or renaming an export, do not. A reshoot is worth marking more loudly, because it resets the lineage. Some teams jump to the next ten (v10, v20) for a new capture, which makes "same photo, re-edited" and "new photo" distinguishable at a glance.
The filename carries the label, but it should not carry the whole history. That belongs in a log. For the naming side of this in more depth, see our guide to product image naming conventions.
The version log: one row per change
The log is what turns labels into an audit trail. It can live in a DAM, a PIM, or a spreadsheet; the tool matters less than whether a row gets written every time. Keep the fields few enough that people fill them in:
| Field | Example |
|---|---|
| SKU and slot | TB-4410-NVY, hero |
| Version | v03 |
| Source | Master capture 2026-03-12, edited from v02 |
| Reason | Navy rendering too purple; colour corrected to match sample |
| Approved by / date | Merchandising, 2026-09-30 |
| Published to | Storefront, Google feed, Amazon |
| Status | Live (v02 superseded) |
The reason field is the one teams skip and later miss most. Six months on, when someone asks why the hero no longer matches the wholesale line sheet, "colour corrected after return complaints" settles it in one line. Without it, the likely outcome is that someone "fixes" the image back to the wrong colour.
The published to field is what makes partial rollouts visible. It is common for a storefront to be on v03 while a marketplace listing still shows v01, because the feed was never refreshed. A periodic image catalog audit is far quicker when the log already says where each version was sent.
You do not need to reconstruct history. Record today's live image for each SKU as v01 with the reason "baseline", and log changes from here on. A log that starts today is worth more than a perfect one that never gets built.
Replacing a live image without breaking things
Swapping a published image looks trivial and causes most of the real-world damage. The core choice is whether the new version takes over the old URL or gets a new one.
Overwrite at the same URL
- Links in emails and feeds keep working
- CDNs and browsers may serve the cached old file for hours or days
- Feed crawlers may not notice the image changed
- The previous version is gone unless archived first
Publish at a new URL
- Caches cannot serve the stale file
- Feeds see a clear change and refetch
- Old version remains addressable for rollback
- Anything hard-linked to the old URL must be updated or redirected
For most catalogs, a new URL per version is the safer default. Hosted platforms often do this for you: Shopify's CDN, for example, serves product images with a version parameter in the URL, so a replaced image is fetched fresh rather than from cache. On a self-managed stack, put the version in the filename or path of the published file and let the product record point to the newest one.
Feeds deserve particular care. Google Merchant Center's guidance for the image link attribute is to use a new URL when the image changes, because an updated file at an unchanged URL may not be recrawled promptly. The practical consequence: an overwrite can leave your shopping ads showing the old packaging long after the storefront has moved on.
Two more habits prevent the common failures:
- Do not delete the superseded file on the same day. Emails already sent, marketplace listings awaiting sync and cached pages may still request it. Retire old published files on a schedule, after checking nothing references them. Deleting eagerly is how catalogs end up with broken image URLs.
- Carry the metadata across. Alt text, position in the gallery and the descriptive filename belong to the slot, not to one version. When v03 replaces v02 as the hero, it should inherit the hero's position and alt text unless the content of the image has changed enough to need new wording.
Rollback, retention and when to retire old versions
A version system earns its keep the day something goes wrong: a retouch removed a real product feature, a new hero underperforms, a supplier reverts a packaging change. Rollback should be a routine operation, not an archaeology project.
Define it as a procedure before you need it:
- Look up the previous approved version in the log.
- Re-export derivatives from that version's working file (do not reuse old exports unless you are certain they match current channel specs).
- Publish as a new log entry, for example "v04, restored from v02, reason: v03 misrepresented collar shape". History only moves forward; you never delete the row for the version that failed.
Recording the rollback as a new version feels redundant, and it is what keeps the trail honest. Anyone reading the log later sees that v03 existed, was live for a period, and was withdrawn for a stated reason. That matters for customer service disputes and, in regulated categories, for showing what a listing displayed on a given date.
Retention needs a rule too, or storage grows without limit:
| Asset | Suggested retention |
|---|---|
| Masters | Life of the product, plus your returns and dispute window |
| Current and previous working file | Always kept, so one-step rollback is instant |
| Older working files | Archive to cold storage; delete after the product is discontinued |
| Superseded published derivatives | Remove once no channel, feed or email references them |
Treat these as starting points. If your category has specific record-keeping obligations, those take priority over tidiness.
Versioning when images are edited in bulk or by AI
Bulk and AI-assisted editing changes the rhythm of versioning more than the principles. When a new background standard can be applied to four hundred products in an afternoon, you create four hundred new versions in an afternoon, and the log has to keep up.
Three adjustments make that manageable:
- Log the batch, then the rows. Give the batch an identifier and a single reason ("2026 autumn background standard, light grey"), and stamp every affected SKU's new version with it. If the standard is later reversed, you can find every image it touched with one filter.
- Record the recipe, not only the result. For an edited or generated image, note the source file and the settings that matter: background colour, crop standard, shadow style. This is what lets you produce a matching image for a product added six months later, and it is what keeps the tenth batch consistent with the first.
- Always edit from the master or the last approved working file. Running a new edit on top of a published derivative stacks compression and makes the lineage untraceable.
Approval still belongs to a person. Speed makes it tempting to publish a whole batch on trust; a sampled review before publishing, with a full pass on hero images, catches the handful of results that misrepresent the product. A pre-publish routine like our product image QA checklist fits naturally as the gate between "version created" and "version live".
Where the tooling helps, let it write the record for you. When Retouchable pushes a finished image back to a Shopify product, for instance, it sets the filename, alt text and gallery position as part of the same step, so the published file carries its label onto the storefront instead of relying on someone to rename it afterwards. Whatever tools you use, the goal is the same: the version label is applied at the moment of publishing, by the system, every time.