Writing Amazon Listing Copy From Product Photos with Claude Vision

The usual AI listing workflow is: type a product name, paste some keywords, get a title and five bullets. The output reads fine and is frequently wrong, because the model is working from a name and inferring the rest.

Your product photographs already contain most of what a good listing needs — material, finish, colour, shape, what it holds, what it sits next to for scale, whether it looks handmade or machined.

1. Upload the photographs

   Store them against the product, not just in the request. You will regenerate copy more than once, and you want the same inputs each time.

2. Assemble the context

   Images, plus a weighted sample of keywords from your keyword bank, plus the product type. Sampling rather than pasting everything keeps successive generations from being identical.

3. Call the model with an SOP prompt

   The rules for this category — structure, tone, banned words, length limits — live in editable data, not in code. See below, this is the part that decides quality.

4. Get back more than a title

   Title, bullets, description, tags, and SEO-friendly image filenames. Ask for the filenames explicitly — they are free at this point and nobody writes them by hand.

5. Run a compliance gate before anything is stored

   Length limits, banned words, filename format. Block on failure rather than warning.

Keeping the whole generated set versioned and diffable is worth the small extra effort — and if you would rather not own that plumbing, I build the SP-API side of tools like this. Copy gets regenerated, compared and rolled back constantly, and "which version is live" becomes a real question by the tenth product.

This is the design decision that matters most, and it is easy to get wrong on day one.

Every category has rules — what a title must lead with, how bullets are structured, words that must never appear, tone. The temptation is to bake them into the prompt in code. Don't.

Make the template a database record, scoped to a product type, editable in your own UI. Three reasons:

• The person who knows the rules is not the developer. They should be able to tune wording without a deploy.
• Categories genuinely differ. A template resolved by product type lets one system serve very different catalogues.
• Tone can be a requirement, not a preference. Some categories demand real care — anything bought under emotional circumstances, anything medical-adjacent, anything for children. A grief-appropriate template is not a nice-to-have in those categories, and it needs to be tunable by someone who understands the buyer.

If you have a keyword bank, the naive move is to paste all of it into the prompt. That produces keyword-stuffed copy and, worse, identical copy across products in the same theme.

A weighted random sample per generation works better: high-value terms appear most of the time, the long tail rotates. Two products in the same category get genuinely different copy, and regenerating gives you a real alternative rather than a paraphrase.

Where the weights come from matters — terms the product actually ranks for should outweigh incidental ones. If your keyword source has no relevance signal, you may have to derive one.

Being clear about this is what makes the tool trustworthy to the people who have to use it:

• Facts the photo cannot show. Dimensions, weight, capacity, certifications. A vision model will describe what it sees and should not be inventing measurements — ask the operator for those and pass them in as context.
• Category compliance. The gate catches length and banned words. It does not know your category's specific claim restrictions.
• The final read. Especially for sensitive categories. Someone signs off before it publishes.
• Video. Worth stating plainly: text-and-vision models generate text, not video. If you want listing video, that is a separate tool or a slideshow assembled from your existing images — not something the copy model produces.

The honest framing for the whole thing: this removes the blank page and the tedium, not the judgement. A good operator with this pipeline gets through ten times the listings. An absent one ships ten times the mistakes.

Can Claude write Amazon listings from product images?

Yes. Sending product photographs as image blocks alongside your keywords lets the model describe the actual product — material, finish, colour, scale — rather than inferring attributes from a product name. The same call can also return tags and SEO image filenames.

Where should listing rules and tone live?

In an editable database record scoped to product type, not hard-coded in the prompt. The person who knows the category rules is usually not the developer, and categories differ enough that one fixed prompt does not serve them.

Should I put all my keywords in the prompt?

No. Dumping the full bank produces stuffed and repetitive copy. Take a weighted random sample per generation so high-value terms recur and the long tail rotates, giving genuinely different copy per product.

Can an AI model generate listing video?

Not a text-and-vision model — those produce text. Listing video requires either a dedicated video model or assembling a slideshow from your existing product images.

What has to be checked before publishing generated copy?

Length limits and banned words automatically, blocking on failure. Then a human for anything the photo cannot establish — dimensions, weight, certifications — and for category-specific claim rules, which an automated gate will not know.