Product Reviews in PrestaShop: Built-In Module vs Third-Party Options

Many PrestaShop stores can add basic product reviews with the free Product Comments module — but test that it's compatible with your version and that your theme actually renders its output. So the real question isn't "should I add reviews" — it's "is the built-in module enough, or do I need something more?" That decision gets made badly all the time, usually in one of two ways: a merchant ships the native module and assumes the job is finished (it collects a trickle of reviews and quietly under-delivers for years), or a merchant signs up for a several-hundred-a-month review platform they didn't need. This guide draws the line precisely — what PrestaShop's built-in reviews actually do, where they stop, and how to tell which of three realistic routes fits your store. It's a decision post, not a setup tutorial; for the platform-by-platform setups (Trustpilot, Google) we link out to the focused guides as we go.

What the native productcomments module actually is

PrestaShop has a free first-party Product Comments module available for many 1.7/8/9 stores — check your module catalogue, Addons or GitHub for the exact version before relying on specific features. It is more capable than its reputation suggests, and knowing exactly what it includes is the only honest way to decide whether you need to spend money. Out of the box it gives you:

• Star ratings with custom criteria. A 1–5 rating, plus optional sub-criteria (e.g. Quality, Value for money, Comfort) that you define under the module configuration and can scope to specific categories. Stored in the module's database tables (e.g. product_comment_criterion) as structured review criteria rather than free text — though this does not by itself create schema.org rich-snippet markup.
• Moderation on by default. On install it sets PRODUCT_COMMENTS_MODERATE = 1, so no review goes live until you approve it from the back office. There's an approve/reject queue under the module's Configure screen.
• Guest reviews, off by default. The PRODUCT_COMMENTS_ALLOW_GUESTS toggle lets non-registered visitors leave reviews; it ships disabled, which is the safer default.
• A spam-floor timer. PRODUCT_COMMENTS_MINIMAL_TIME (default 30 seconds) blocks the same visitor from posting again immediately — a light brake on drive-by spam.
• "Was this review helpful?" voting. The PRODUCT_COMMENTS_USEFULNESS feature lets other shoppers up/down-vote reviews, surfacing the useful ones.
• GDPR plumbing. It registers registerGDPRConsent, actionExportGDPRData and actionDeleteGDPRCustomer hooks, so reviews are included in data-export and right-to-erasure flows. For an EU store that's not a footnote — it's compliance you'd otherwise have to build.

It typically uses product-page hooks such as displayProductAdditionalInfo / displayFooterProduct where the theme implements them, and exposes its own front controllers (PostComment, ListComments, ReportComment, UpdateCommentUsefulness, CommentGrade) for AJAX posting and voting. For a small catalogue with a steady trickle of motivated buyers, that genuinely may be all you need. Don't pay for what you already own until you've hit a wall the native module can't clear.

Where the native module stops — and why it matters

The walls are real, though, and they tend to be the exact features that turn "we have reviews" into "reviews that earn us trust and search visibility." Here's where productcomments runs out of road, framed by what it costs you in practice:

• No verified-purchase distinction. The native module cannot tell a review left by a real buyer from one left by any logged-in visitor. There's no "Verified purchase" badge in the data model. So what? Shoppers have learned to discount un-vetted reviews, and the single most persuasive review signal — "this person actually bought it" — is the one you can't show.
• No post-purchase review requests. This is the big one. The module is entirely passive: it waits for customers to come back on their own and review. There is no mechanism to email a buyer a few days after delivery asking for a review. Because the overwhelming majority of happy customers never return unprompted, a passive module collects reviews at a fraction of the rate a store with automated requests does. You can't fix a low review count by waiting harder.
• No photo or video reviews. Buyers can't attach an image. For anything where look, fit or scale matters — clothing, furniture, anything visual — a customer photo is the most convincing proof you can put on the page, and the native module has no slot for it.
• No rich-snippet structured data. Worth being precise here: productcomments 7.x does not emit an aggregateRating JSON-LD block of its own — whether your product pages show review stars in Google depends on your theme or a separate SEO module adding that schema. Don't assume installing native reviews gets you the stars in search results; it usually doesn't on its own.
• Thin moderation tooling. You get approve/reject and the 30-second timer. There's no spam scoring, no profanity filter, no rate-limiting beyond that timer, and no bulk actions — which gets painful fast the moment a spam bot finds your review form.
• No import. Migrating in from another platform with existing reviews? There's no import path; you'd be writing rows into the product_comment tables by hand or script.

None of these are bugs. They're the boundary of a deliberately simple first-party module. The question is whether your store has crossed any of them.

The three routes — and a decision framework

Once you've outgrown native reviews, there are three honest directions. They suit genuinely different situations, and the most common mistake is picking the expensive one out of reflex.

The deciding questions, in order:

• Is your review count low because of collection, or because of traffic? If you have steady sales but few reviews, the fix is automated post-purchase requests — an enhanced on-site module solves that directly and cheaply. Jumping to a paid platform doesn't collect more reviews by itself; it just relocates the problem.
• Do you need product-level reviews, or store-level trust? This is the cleanest dividing line. Trustpilot and Google Customer Reviews are fundamentally store-level ("how was your experience with this shop?"). On-site modules give you product-level reviews ("how is this specific product?") — which is what actually sits on the product page and drives the add-to-cart decision. Most stores need product-level first.
• Do you want to own your review data? Reviews collected on an external platform live on that platform. Stop paying and you typically lose the on-site display. On-site reviews are rows in your database that you keep forever.
• Are you buying reviews, or buying brand recognition? The honest reason to pay for Trustpilot is the recognised neutral logo and its seller-rating pipeline into Google Ads — not the review collection itself, which an on-site module does for less.

The two external routes each have their own focused setup, so we won't re-tread them here: see Trustpilot for PrestaShop for the widget-and-feed setup, and Google Customer Reviews for the free Merchant Center route. And before you lean entirely on an external widget, it's worth reading why third-party widgets are not enough on their own — the short version is that off-site reviews don't put product-level social proof where the buying decision actually happens.

The enhanced on-site route, concretely

The middle route exists precisely because most merchants don't need a paid platform — they need the native module's missing features without the monthly bill or the loss of data ownership. Our mprcomments module extends PrestaShop's reviews to close exactly the gaps listed above, and it's worth being specific about which gap each feature closes:

• Verified-purchase badges. Reviews from customers whose order contains the product carry a "Verified purchase" marker. So what? The most persuasive trust signal — real buyer — finally shows on the page.
• Automated review-request emails. A reminder is queued against the order after delivery and a one-click, tokenised review link is emailed to the buyer. This is the fix for a low review count: it converts passive waiting into active, opt-out collection.
• Photo reviews. Customers attach images to their review, so visual products get visual proof on the page.
• Proper rich-snippet schema. The module renders an aggregateRating JSON-LD block built from product-native reviews only — the correct approach, since store-level imported reviews don't describe a specific product and shouldn't inflate a product's rating. Schema is only part of the picture, though: whether stars actually appear in search results depends on valid Product schema, genuinely visible reviews, policy compliance, and Google's own discretion — no module can guarantee the listing.
• Spam detection. Content pattern checks and rate-limiting on top of the native 30-second timer, so a spam bot finding your form doesn't bury your moderation queue.

So what does this mean for you? The change customers feel is a product page with verified, photo-backed reviews and a steady stream of new ones; the change you feel is that it installs and configures from the back office, the data stays in your database, and there's no recurring invoice. It's the route that fits the largest share of stores that have outgrown the native module — which is most of them.

Getting reviews in the first place (this is the real bottleneck)

Whichever route you pick, the system is only as good as the reviews flowing into it — and for most stores the bottleneck isn't the display, it's collection. A few approaches that work and stay inside the rules:

• Post-purchase request emails sent a sensible interval after delivery (long enough that the customer has used the product, not so long they've moved on), with a direct link to the review form for the exact product bought. This single mechanism does more for review volume than anything else on this list.
• In-package inserts — a small card with a QR code to the review form. Cheap, and it reaches the buyer at the moment they're holding the product.
• Incentives, carefully. A small loyalty-point or next-order discount can lift response rates, but the incentive must be offered for any honest review regardless of rating. Rewarding only positive reviews breaks FTC guidance (US) and the EU Omnibus Directive, and Google strips rich snippets from sites it judges to be gaming reviews.
• Never buy fake reviews. Beyond being illegal under the Omnibus Directive (with real fines), it's self-defeating: a wall of suspiciously uniform five-star reviews reads as fake to shoppers, and a product with a believable mix of ratings consistently out-converts a suspiciously perfect one.

Moderation, the right way

Reviews aren't fire-and-forget. A few practices that hold across every route:

• Reply to the negative ones. A calm, helpful response to a one-star review reassures every future reader far more than the review damages you — they see a store that shows up when something goes wrong.
• Don't delete bad reviews. Remove only what genuinely violates policy: profanity, personal attacks, spam, or reviews that are actually about delivery rather than the product. Scrubbing honest criticism is both against most platforms' terms and obvious to shoppers.
• Watch for low-star reviews fast. Set up notification so a one- or two-star review reaches you while there's still time to respond publicly and reach out privately.
• Distinguish product from service complaints. A "delivery was slow" review on a product page is misfiled feedback. For pre-purchase product questions that would otherwise turn into a poor review, route them to a proper channel — see Ask About Product — and pull recurring questions into your product FAQ.

How this fits the rest of the product page

Reviews are one social-proof signal among several, and they pull hardest when the page around them is doing its job. If reviews are the proof, the rest of the page is the pitch — the layout that decides whether a visitor scrolls down to the reviews at all is covered in product page design best practices, and the surrounding trust signals (badges, guarantees) in trust badges. Reviews also feed the same Google rich-results system as your copy: getting the aggregateRating stars to show is partly schema and partly having real review content, while the listing's words come from your product descriptions.

The short answer

Start native — it's free, it's GDPR-aware, and for a small store it may be enough. The moment your review count is stuck low despite real sales, or you need verified badges, photos, or stars in search, move to an enhanced on-site module before you reach for a paid platform: you keep your data, you skip the monthly fee, and you get product-level reviews where the buying decision happens. Reach for an external platform only when you specifically need a neutral brand's recognition or its seller-rating pipeline into Google Ads — not as a way to collect reviews you could collect yourself. Reviews aren't a nice-to-have on a product page; they're often the last thing a hesitant buyer reads before deciding. Make sure what they read is real, verified, and actually there.