An AI-generated product photo can look convincing while changing the product. A missing seam, invented attachment or altered colour may be enough to create the wrong expectation. Review the image against the actual item before judging it as marketing creative.
This guide is a practical acceptance checklist for teams using AI to edit product imagery or create scenes around an item. It is not a comparison of image generators. Google Merchant Center requirements are one channel-specific reference, reviewed September 14, 2026; other destinations need their own checks.
- 01Preserve product identity.A better-looking image is not acceptable if it changes the item or selected variant.
- 02Separate the scene from the sale.Props and accessories must not imply that additional products are included.
- 03Inspect the delivered file.Cropping, optimisation and metadata handling can change an approved asset after export.
- 04List the destinations.A corrected website image does not automatically update a scheduled post, a marketplace feed or an exported deck; the approval record names every place the asset went.
01 — Practical guidanceCreate a source of truth before generating
Keep an approved photograph of the actual product, its variant identifier and the relevant specification. Identify features that must remain unchanged: proportions, material, colour, closures, connectors, printed wording and included parts. Use more than one reference angle when a single image cannot establish the detail.
A prompt such as “keep the product identical” is an instruction, not evidence that the output complied. The acceptance record should list the visible features a reviewer can compare. When a feature is hidden or ambiguous, mark it unresolved rather than inferring it from a plausible render.
For an illustrative backpack listing, a generated side pocket or reinforced handle could imply a functional feature the customer will not receive. That is different from a harmless background change. Classify the difference by its effect on the purchase expectation, not by how small it looks on screen.
02 — MethodReview six kinds of product drift
The table is a proposed review aid. It does not score a particular model or claim that all image errors can be found automatically. A person familiar with the product should resolve disputed details before the asset is approved.
Review at useful magnification and at the actual display size. A label may be legible in the master file but become distorted after resizing. Conversely, a subtle full-resolution change may materially alter a prominent feature in a mobile product card.
| Check | Compare against | Reject or investigate when |
|---|---|---|
| Shape and construction | Approved photographs and specification | Seams, ports, handles or proportions change. |
| Colour and material | Selected variant and reference lighting | Finish, texture or colour implies a different variant. |
| Words and symbols | Actual packaging and product markings | Labels, safety marks or brand text are invented. |
| Included items | Bundle contents and offer description | Props appear to be included accessories. |
| Scale and function | Dimensions and documented use | Scene implies unsupported size, capacity or performance. |
| Final file and provenance | Approved export and channel requirements | Crop, conversion or metadata removal changes the accepted asset. |
03 — The evidenceKeep channel requirements distinct from creative preference
Google’s image-link specification requires accurate product representation and sets rules for main images, promotional elements and generated-image metadata. A scene approved for a social post is not automatically suitable as a Merchant Center main image.
The specification requires metadata indicating generative-AI origin and says to preserve relevant embedded digital-source tags. It lists different source types, including fully generated and composite synthetic media. Do not apply a convenient tag without checking what it means for the actual production process.
Google’s page contains a future image-size transition notice alongside its requirements. This checklist deliberately does not turn that into an undated universal size rule. Verify the effective requirement for the destination and publication date when preparing the final export.
04 — The decisionTest the whole publishing path
Keep the approved master and inspect the file actually served by the website or feed. An optimiser may remove metadata, a content system may choose the wrong crop, or a variant mapping may attach the image to the wrong item. Acceptance at the design stage cannot detect those later mistakes.
Open the product on a phone-sized view and compare image, title, price context and selected variant. Check that a customer can distinguish the item being sold from illustrative surroundings. Where an image needs explanatory wording, ensure that the explanation is visible in the destination itself.
Our AI product photography overview covers tool selection. Use the present checklist after creation to determine whether an output can represent the product. Tool capability and asset acceptance are separate decisions.
05 — ExampleMake corrections traceable
Store the original reference, generation or editing instructions, approved output and reason for acceptance. Identify who can approve product details and who can approve presentation. This reduces the chance that a visually attractive revision bypasses somebody who knows the item.
If a later review finds drift, replace the affected file and check every destination that reused it. A corrected website image does not automatically update a scheduled social post, marketplace feed or exported presentation. Keep a small list of asset destinations with the approval record.
For content production, the useful efficiency gain is less work per accurate, publishable asset. Count rejected outputs and review effort as part of that process. The human review cost guide explains why generation speed alone is an incomplete measure.
When a video reuses the product image, check its soundtrack separately with the commercial music rights reference. Approval of one asset element does not clear the others.
As-of date. September 14, 2026. Sources reviewed for this article; the article is dated September 14, 2026.
Method. Reviewed Merchant Center image requirements and built six product-fidelity checks. All examples are illustrative; no image generation, catalogue audit or model-performance test was performed.
Sources. Merchant Center image specification.
Limits. Channel-specific requirements are not universal legal clearance. The checklist cannot establish rights, product compliance or complete automated error detection.
06 — The failuresFour images that looked right and sold the wrong thing
Product drift is easy to miss because the image is attractive and the change is small. The illustrative images below each passed a glance and failed the product. They continue the backpack example from the first section and are not accounts of a catalogue.
The invented pocket
The generated scene adds a side pocket the backpack does not have. The image is cleaner than the photograph; the customer orders a bag with a feature they will not receive. The comparison against the approved photograph was never made.
The variant colour
Reference lighting in the scene shifts the navy bag toward black. The listing is for navy; the image now matches the black variant. A customer choosing by picture receives a different product from the one shown.
The stripped metadata
The master file carries the generative-origin metadata Google’s Merchant Center specification requires. The site’s image optimiser removes it on upload. The served file no longer meets that requirement for Merchant Center use, and nobody inspected it after export.
The stale social post
Drift is found and the website image replaced. A scheduled social post and the marketplace feed still carry the old file, because no list of destinations existed when the correction was made.
Each failure sits in a different row of the checklist and each is caught by the record in the next section, which is written before the image and completed after it is live.
07 — The recordThe approval record in six fields
The corrections section asks for the original reference, the instructions, the approved output and the reason for acceptance to be stored together, with named approvers and a list of destinations. Written as a record, that is six fields. The reference: the approved photograph, the variant identifier and the specification, with the features that must not change listed. The instructions: the generation or editing prompt as issued, including the instruction to keep the product identical, which the record treats as an instruction rather than as evidence. The output: the approved master file and its hash. The acceptance: which checklist rows were compared, at what magnification and display size, and which features were marked unresolved. The approvers: the person who approved product details and the person who approved presentation, since the checklist asks for both. The destinations: every place the asset is published or scheduled, so a correction reaches all of them.
An illustrative record for the backpack reads: reference, the navy variant’s approved photograph with seams, strap hardware and the printed logo listed as fixed; instructions, replace the studio background with an outdoor scene and keep the product identical; output, the approved file by hash; acceptance, shape, colour, wording and included parts compared at full resolution and at phone-card size, scale marked unresolved because the scene has no reference object; approvers, the product manager for the item and the designer for the scene; destinations, the product page, the marketplace feed and a social post scheduled for Thursday.
The record also settles the publishing-path test. Inspecting the served file against the approved master is a comparison between field three and what the site actually delivers, and when drift is found later, field six is the list of places the replacement has to go.
Someone who knows the item approves the product details; someone who knows the channel approves the presentation. The checklist separates them because a visually attractive revision can otherwise bypass the one person who would have noticed the pocket.
08 — Next stepA good picture can still misrepresent the product
Write the six-field record for the next product image before it is generated. The reference and the fixed features are listed once, and they are the comparison that the glance at the finished image cannot make.
Approve the product representation, not just the picture
Compare the output with the actual item, check what the scene implies and inspect the delivered file. Publish only when product accuracy and destination requirements are both satisfied, with a record that makes later corrections straightforward.