Fixing Duplicate Product Descriptions

Duplicate product descriptions are ecommerce's default state — the manufacturer writes one paragraph, five hundred stores paste it, and Google gets five hundred pages saying identical things about identical products. The result isn't a penalty (per the standing myth-correction); it's worse in a quieter way: your product pages become interchangeable candidates in a lottery you don't control, ranking nowhere in particular because nothing distinguishes them. Here's the fix at catalogue scale — triage, the uniqueness sources cheaper than rewriting, and the variant-level duplication hiding inside your own store.

The two duplication problems (external and internal)

External: your descriptions match every competitor carrying the line — the boilerplate problem, solved by adding what the manufacturer didn't write. Internal: your own variants, colourways and near-identical SKUs duplicating each other — solved structurally, not editorially: one canonical product page with variant options as the default (per the template decision), separate URLs only where variant-level search demand justifies them, and canonicals doing the consolidation everywhere else. Audit both before writing anything — the internal fix is configuration, and it's frequently the bigger indexation win.

The triage (because rewriting 5,000 SKUs is a misallocation)

Per the 80-of-800 rule: full rewrites for the revenue head — top sellers, high-margin, high-search products get genuinely original descriptions (what it's for, who it fits, honest trade-offs, the pre-sales questions answered — the content layer proper); enhanced templates for the middle — attribute-driven generation done right (see below) plus the uniqueness sources; structure-only for the long tail — canonical hygiene, schema, and a strong category carrying them. Revisit the tiers as sales data moves products between them.

The uniqueness sources cheaper than writing

1. Customer reviews, rendered indexably — the highest-value unique text a product page can carry, written free, in buyer language, continuously refreshed. A boilerplate description above thirty real reviews is a substantially unique page; the review engine is secretly a content engine.
2. Q&A blocks — pre-sales questions answered on-page: unique, snippet-shaped, and conversion-relevant.
3. Structured attribute prose, generated honestly: templates that render real per-product data ("weighs X, fits Y, compatible with Z — unlike [sibling product], it...") produce genuinely informative variation — the data-density rule at product scale. Templates that shuffle synonyms around identical claims produce spun boilerplate, which is the disease with extra steps.
4. Your own media: original photos and measurements — uniqueness signals text-matching can't commoditise, per the receipts principle.

Frequently asked questions

Will we be penalised for keeping manufacturer text on the long tail?

No — filtered, not punished: those pages just won't win contested queries, which for tail SKUs riding category strength is an acceptable trade made knowingly. The danger tier is scale: a store that's 95% boilerplate reads thin sitewide (the aggregate evaluation), which is what the triage's head-and-middle investment prevents.

Can AI rewrite our descriptions at scale?

As paraphrase, it launders boilerplate without adding information — the same sameness in new words, and scaled-content policy territory besides. As a renderer of real per-product data and review insights into readable prose, with editorial spot-checks — legitimately useful for the middle tier. The input data, not the generator, decides which you're doing, per the dividing line.

We syndicate OUR descriptions to retail partners. Who ranks?

The syndication rules apply with commerce stakes: bigger partners can outrank the originator on its own text. Defences: keep your on-site version richer than the syndicated cut (reviews, Q&A, media do this automatically), and negotiate canonical or at least delayed syndication where leverage allows. Beyond that, the tiebreaker is the usual one — domain authority, built deliberately (our trade).