Product descriptions are the only text on a product page you fully control. They are also the text most stores never write.
The default is to paste whatever the supplier sent. It fills the space, it mentions the product, and it looks finished. What it actually does is publish a page that is word-for-word identical to every other retailer stocking that item — which is why so many catalogs sit invisible no matter how much technical work goes into them.
This is a working guide to product description SEO: what a description has to contain, how to write one that outranks the manufacturer's copy, how to scale it across thousands of SKUs with AI without recreating the duplicate problem, and how to tell whether any of it worked.
Why supplier copy keeps your pages out of the results
There is no duplicate content penalty in the punitive sense. What happens is quieter and worse.
When the same block of text appears on forty retailer sites, Google picks one version to show and filters the rest. The choice is not random — it follows authority. If your domain is not the strongest one carrying that text, you are the one filtered out, and you never see it happen. Your page is indexed. It simply never surfaces.
That is the mechanism worth internalising: you are not competing on description quality against the manufacturer. You are competing against every store that pasted the same paragraph, and the tiebreak is a signal you cannot win at.
Original copy removes you from that contest entirely.
What a description has to answer
A description is not a summary of the spec sheet. The spec sheet is already on the page, in a table, where it belongs. The description exists to answer the questions a table cannot.
Which version of this is right for me. Most catalogs sell three or four variants of the same thing. The shopper comparing them wants the difference stated plainly. "The Pro adds a metal gear housing and 40% more torque — worth it if you are drilling masonry, unnecessary for flat-pack furniture" does more work than any feature list.
Will it fit, and will it last. Sizing, dimensions, materials, care. These are the questions your support inbox already answers a dozen times a week. Every one of them answered on the page is a support ticket avoided and an objection removed.
Specifics, not adjectives. "Waterproof to IPX7, tested at one metre for thirty minutes" is verifiable. "Premium water resistance" is noise. Concrete numbers also give AI search engines something quotable, which matters more every quarter.
In the customer's words. Pull the vocabulary from reviews, support tickets, and your own search query reports — not the manufacturer's marketing language. Buyers search for "quiet blender for early mornings," not "advanced acoustic damping system."
Google's guidance on creating helpful, reliable, people-first content sets the test directly: does someone leave the page having learned enough to make their decision? A rewritten spec list does not pass. An explanation of who the product is for does.
A structure that works across a catalog
Consistency matters more than cleverness once you are past twenty products. A repeatable shape lets you write faster, lets a team write to the same standard, and lets you spot gaps at a glance.
| Block | Length | Job |
|---|---|---|
| Opening line | 1–2 sentences | Who this product is for, in plain language |
| The difference | 2–3 sentences | How it differs from the adjacent model |
| Use case | 2–4 sentences | The situation it is bought for |
| Fit and care | 2–3 sentences | Sizing, materials, maintenance |
| Honest limits | 1–2 sentences | What it is not for |
That last block is the one stores skip, and the one that earns trust fastest. Saying "this is not the right saw for hardwood" costs you a sale you would have refunded anyway, and it makes every other claim on the page more credible.
Length follows the product. A phone case needs 150 words. A £2,000 mattress needs 400 or more, because the decision is bigger. Word count is never the target — a 600-word description that restates the spec sheet is worse than a 200-word one that explains the trade-off.
Where the keyword actually goes
Product descriptions are not where you win broad category terms. That fight belongs to the category page. The description supports a product-level query, and the keyword work is correspondingly light.
- Product name and model in the first sentence, written the way people search it — brand, model, and the distinguishing qualifier.
- The qualifier that matters worked in naturally: "waterproof," "wide fit," "for sensitive skin." These are what turn a generic search into a purchase-intent one.
- Nothing repeated for its own sake. Keyword stuffing in descriptions is a solved problem that only survives in old advice. It reads badly, and it converts worse.
The genuinely valuable long-tail comes from the questions you answer, not the terms you insert. A paragraph explaining that a jacket runs one size small will pick up traffic for phrasings you would never have thought to target.
Scaling with AI without recreating the problem
Rewriting four thousand descriptions by hand is not realistic, which is exactly why AI belongs in this workflow — and exactly why most stores get it wrong.
The failure mode is specific: generate every description from the product name alone. The model has nothing to work with, so it produces confident, fluent, interchangeable text. You have replaced forty stores sharing one paragraph with four thousand of your own pages sharing one voice and saying nothing. The duplicate problem returns wearing a better suit.
What works is treating the model as a writer with a research file rather than an oracle:
1. Feed it real inputs per product — the spec sheet, the three most common support questions for that item, the recurring themes in its reviews, and the specific differences from the adjacent model. 2. Hand-write the head of the catalog. The products carrying your revenue deserve a human. That is usually 5–10% of SKUs and 60%+ of sales. 3. Generate the tail from structured inputs, using a template that forces the model to fill real fields rather than free-write. 4. Review a sample before publishing, not after. Ten randomly drawn descriptions from a batch of five hundred will tell you whether the batch is usable. 5. Never publish text you have not read at least in sample. If the model invented a certification or a measurement, that is now a claim your store is making.
The test for whether your AI workflow is working is simple: pick two similar products and read their descriptions side by side. If you could swap them and not notice, the inputs were too thin.
Descriptions and AI search
Product discovery is moving into assistants, and the queries look different — "quiet blender under $150 that fits under a cabinet" rather than "blender." The answer gets assembled from pages that contain assemblable facts.
This is where specific descriptions quietly outperform. A model comparing three blenders can use "62 dB at maximum speed, 14.5 inches tall" and cannot use "whisper-quiet performance in a sleek design." The same writing that helps a human decide is the writing that gets cited.
Nothing here requires a separate AI strategy. Concrete facts, stated plainly, in original text — that is the whole overlap.
Proving it worked
Description rewrites are easy to do and easy to never measure, which is how they end up deprioritised.
Set this up before you start:
- Pick a test set. Fifty to a hundred products, rewritten; a matched set of similar products left alone as a control.
- Record the baseline. Impressions, clicks, and average position per URL in Search Console, plus conversion rate, for the eight weeks before.
- Wait a full crawl cycle. Six to eight weeks minimum. Judging in week two tells you nothing.
- Compare against the control, not against last month. Seasonality moves everything; the control is what separates your work from the season.
The metric that matters most is usually not ranking. It is the number of distinct queries a page picks up. A description that answers real questions starts appearing for phrasings nobody targeted, and that broadening shows up in Search Console long before the head term moves.
The description checklist
- Original text, not the manufacturer's
- Product name and model in the first sentence, as people search it
- Difference from the adjacent model stated explicitly
- Use case described, not just features listed
- Sizing, materials, and care covered
- Honest limits included
- Common support questions answered on the page
- Specific figures instead of adjectives
- Customer vocabulary, not manufacturer marketing language
- No repeated keywords for their own sake
- Head-of-catalog products written by a human
- AI-generated tail built from real inputs and sampled before publishing
- Baseline recorded and a control set chosen before the rewrite
Sources
- Creating Helpful, Reliable, People-First Content — Google Search Central
- SEO Best Practices for Ecommerce Sites — Google Search Central
- Ecommerce Product Data and Content on Google — Google Search Central
- Intro to Product Structured Data on Google — Google Search Central
- Google Search Essentials — Google Search Central
Frequently Asked Questions
Want this run against your store? Book a call with The Reach Bureau.
