Product Review Content Programme
Reviews are the only product page content a competitor selling the identical item cannot copy, which is exactly why syndicated review pools are worth less than they look: the same 40 reviews sit on every retailer in the network. The usual programme, an automated request to every buyer, returns a five-star sentence carrying no information and a response rate that collapses within a quarter. What matters is getting a small number of specific reviews onto the pages that already have impressions, and keeping the aggregate honest enough to survive scrutiny.
FORMAT
product-review-content-programme.md
WHEN TO REACH FOR THIS
Use when product pages carry no reviews, or carry syndicated reviews that appear word for word on every other retailer selling the same item.
The skill file
product-review-content-programme.md
---
name: product-review-content-programme
description: Use when product pages carry no reviews, or carry syndicated reviews that appear word for word on every other retailer selling the same item.
---
# Product Review Content Programme
Reviews are the only product page content a competitor selling the identical item cannot copy, which is exactly why syndicated review pools are worth less than they look: the same 40 reviews sit on every retailer in the network. The usual programme, an automated request to every buyer, returns a five-star sentence carrying no information and a response rate that collapses within a quarter. What matters is getting a small number of specific reviews onto the pages that already have impressions, and keeping the aggregate honest enough to survive scrutiny.
## What you need first
- Order data joined to SKU with delivery dates, so requests can be timed against product use
- Review coverage per SKU crossed with Search Console impressions, so you know which gaps cost anything
- The review source stated per SKU: first party, syndicated, or a mix
- The existing moderation and disclosure policy, including how incentivised reviews are handled
## Method
1. Rank SKUs by impressions where coverage is zero or fewer than three reviews. Those are the pages where review content changes an outcome; the rest of the catalogue can wait indefinitely.
2. Time the request against product use rather than dispatch. Asking on delivery day for a mattress or a coffee machine produces a review about the packaging.
3. Ask one specific question instead of for a rating, for example what they compared it against or what surprised them. Open prompts return sentences that answer real queries; star prompts return stars.
4. Keep syndicated reviews if they help conversion, but render first-party reviews above them and mark up only the first-party set, so the unique text leads and the aggregate reflects your own customers.
5. Publish the negative reviews. A wall of five-star ratings converts worse than a mixed set and invites scrutiny of the aggregate you have declared in markup.
6. Handle variants deliberately. Reviews for a colour or size variant belong on the shared product page, and splitting them leaves every variant looking unreviewed.
7. Audit quarterly for review text duplicated across your own SKUs, which happens when a review platform maps a family to a parent product and republishes the same set to every child.
## What this produces
A review collection sequence targeted at high-impression SKUs with no coverage, plus a rendering and markup rule separating first-party from syndicated reviews.
## Where this goes wrong
- Marking up syndicated reviews as though they were collected by you, which is a direct route to a structured data manual action
- Filtering low ratings out before publication, which distorts the aggregate you have declared and is visible to anyone comparing sources
- Chasing catalogue-wide coverage, so effort lands on SKUs with no impressions while the pages that already rank stay empty
- Collecting reviews at brand level and displaying them on every product page, which tells a buyer nothing about the item in front of them
---
From the QuQi skill library - https://www.quqi.io/skills/product-review-content-programme
Free to download · no account, no email
What you need first
-
Order data joined to SKU with delivery dates, so requests can be timed against product use
-
Review coverage per SKU crossed with Search Console impressions, so you know which gaps cost anything
-
The review source stated per SKU: first party, syndicated, or a mix
-
The existing moderation and disclosure policy, including how incentivised reviews are handled
Method
-
01
Rank SKUs by impressions where coverage is zero or fewer than three reviews. Those are the pages where review content changes an outcome; the rest of the catalogue can wait indefinitely.
-
02
Time the request against product use rather than dispatch. Asking on delivery day for a mattress or a coffee machine produces a review about the packaging.
-
03
Ask one specific question instead of for a rating, for example what they compared it against or what surprised them. Open prompts return sentences that answer real queries; star prompts return stars.
-
04
Keep syndicated reviews if they help conversion, but render first-party reviews above them and mark up only the first-party set, so the unique text leads and the aggregate reflects your own customers.
-
05
Publish the negative reviews. A wall of five-star ratings converts worse than a mixed set and invites scrutiny of the aggregate you have declared in markup.
-
06
Handle variants deliberately. Reviews for a colour or size variant belong on the shared product page, and splitting them leaves every variant looking unreviewed.
-
07
Audit quarterly for review text duplicated across your own SKUs, which happens when a review platform maps a family to a parent product and republishes the same set to every child.
What this produces
A review collection sequence targeted at high-impression SKUs with no coverage, plus a rendering and markup rule separating first-party from syndicated reviews.
Where this goes wrong
-
Marking up syndicated reviews as though they were collected by you, which is a direct route to a structured data manual action
-
Filtering low ratings out before publication, which distorts the aggregate you have declared and is visible to anyone comparing sources
-
Chasing catalogue-wide coverage, so effort lands on SKUs with no impressions while the pages that already rank stay empty
-
Collecting reviews at brand level and displaying them on every product page, which tells a buyer nothing about the item in front of them
Use this skill in your own AI
The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.
Claude Code
Save it as ~/.claude/skills/product-review-content-programme/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude
Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT
There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else
Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.
Questions about this skill
When is this worth doing rather than switching on a syndicated review pool?
When product pages carry no reviews, or carry syndicated text sitting word for word on every retailer in the network. The usual alternative, an automated request to every buyer, returns five star sentences carrying no information and a response rate that collapses within a quarter. Use this when you need a few specific reviews on the pages that already have impressions.
What do I need before sending a single review request?
Order data joined to SKU with delivery dates, review coverage per SKU crossed with Search Console impressions, the review source stated per SKU, and your existing moderation and disclosure policy. Without the impressions join, effort spreads across the catalogue and lands on SKUs nobody sees. Without the source field you cannot keep syndicated text out of your own markup.
What does the programme produce, and which part is load bearing?
A collection sequence aimed at high impression SKUs with no coverage, plus a rendering and markup rule separating first party from syndicated text. The markup rule carries the weight: first party reviews render above the syndicated set and only they are marked up, so the aggregate you declare reflects your own customers and the unique text leads the page.
Which mistake here can cost you a manual action?
Marking up syndicated reviews as though you collected them, which is a direct route to a structured data manual action affecting the whole catalogue. Filtering out low ratings is the second: it distorts the aggregate you have declared, is visible to anyone comparing sources, and a wall of five star ratings converts worse than a mixed set anyway.
More in Ecommerce SEO