Reviews

A shopper can only review a product they bought.

The storefront checks for a matching order item before it accepts the review, and rejects the submission when there is none. This is not a badge applied after the fact — it is the condition for the review existing at all.

Reviews land unmoderated, are stored in your own database, and appear on the product page and in its Product schema once you approve them.

The queue lives at:

Insights → Reviews
/admin/reviews

It requires the reviews:view permission. Each review carries a sequential number, so admin URLs stay short and readable.

Only buyers can review

Two gates, both tied to the same condition.

The storefront form is only shown when the customer has an order item for that product. The submit is only accepted under the same test — so hiding the form is a convenience, not the security.

Because the gate is the order item itself, the verified-buyer flag on a storefront review is always true. There is no unverified review to distinguish, and no separate verification step to run.

The database enforces one review per customer per product. A customer cannot stack five reviews on the same item, and the rule is held in the database rather than in form validation, so no route into the data can bypass it.

Four states, derived rather than stored

A review is pending, published, rejected or flagged.

There is no stored status column. The state is derived from which decision timestamp is set.

That sounds like an implementation detail and is not. A stored status is a second copy of the truth, and second copies drift — the list filter says one thing, the product page shows another, the moderation menu offers a move that no longer applies. Deriving the state from the decisions means the list filter, the product page and the moderation menu can never disagree.

A new review has no decision timestamp set at all, so it reads as pending without anything having to write that word anywhere.

The moderation moves

Each decision can carry a moderation note.

pending    → approve → published
flagged    → approve → published

pending    → flag    → flagged
published  → flag    → flagged

anything not already rejected → reject → rejected

The move worth noticing is flagging something already published. It pulls a live review back for a second look, which is what you need when a review that read fine on approval turns out to be a competitor, a mistake, or about the wrong product.

Ratings in the markup

Once a review is published, it reaches the product's structured data as well as its page.

The product's average rating and review count are emitted as AggregateRating on the Product schema.

Alongside that, up to ten individual Review nodes are emitted, each carrying:

• Rating
• Body
• Author
• Date

Only published reviews are included. A pending review is invisible to search engines for exactly the same reason it is invisible to shoppers — the state is derived from one place.

Imported reviews

A migrated catalog's review history sits in the same queue and the same table as new ones.

Reviews carry:

• A source
• An external id and URL
• An import batch id
• External image URLs

So there is no second inbox to check and no separate import table that behaves differently. An imported review moderates with the same moves as a fresh one.

Settings

Three things to set:

• Whether reviews are enabled at all
• How many days after delivery to request one
• One reminder

There is one reminder, not a configurable sequence.

Reviews you own

The reviews are rows in your database.

There is no widget to embed, so nothing third-party loads on your product pages, and there is no per-review fee — a catalog that accumulates review history does not become more expensive to keep.

Working the queue

A buyer with a matching order leaves a review, and it enters the queue as pending.

You approve, flag or reject it, with an optional moderation note recording why.

Approved reviews and the recalculated average rating then appear on the product page and in its structured data together.

When you are unsure about a review, remember what each move actually costs. Rejecting is final in the sense that it takes the review out of every surface; flagging keeps it in the queue for a second look. And a review already live can still be pulled back.

The queue is a publishing decision, not a verification one — the purchase check already happened before you ever saw the review.

Related