Platforms

Google reviews in PrestaShop: where the snippet goes, measured

9 August 2026 · JustReview

To display Google reviews in PrestaShop you paste three things: a stylesheet link plus the widget script, one init call with your account key, and an empty <div> where the reviews should appear. There is no module to install and no PHP to run, because the widget is client-side and fetches the reviews from our API in the visitor’s browser. The PrestaShop-specific problem is that those three pieces do not naturally live in the same file, so they drift apart, and when they do the widget fails in a way that leaves no error anywhere.

We know how often that happens because we measured it. On 9 August 2026 we took every domain that called our widget API in the previous 17 days, fetched each one, fingerprinted the platform, and then loaded the PrestaShop ones in a headless browser to see what the code actually did.

What 16 live PrestaShop shops actually do

Our widget API saw 718 distinct domains between 24 July and 9 August 2026. 655 of them answered an ordinary HTTPS request, and 16 returned PrestaShop fingerprints, spread across 13 accounts. Every one of the 16 is on the 1.7 or 8 generation. Not a single 1.6 shop is left.

The first thing the sample shows is where people put the library.

The second thing it shows is that the stock theme is a minority of one. Fifteen of the 16 shops run a non-stock theme, and only sleep-lenly.com was on PrestaShop’s own classic. Five of the 16 had a page builder module available: Creative Elements on three, Ap Page Builder on two. That matters for the advice at the end, because “just edit header.tpl” is advice about a file that belongs to somebody else’s theme.

The failure PrestaShop produces: loaded, called, rendered nothing

Here is the part no tutorial covers. On five of the pages we loaded, the widget stylesheet downloaded, the widget script downloaded, an init call ran, our API answered with reviews, and nothing appeared on the page. Not a broken layout, not an empty box: no container element in the DOM at all, and a clean console.

The cause is the same in all five: the library and the init call are global, because they were pasted into a template that renders on every page, while the container div sits in one template only. So the shop pays for the widget everywhere and gets it in one place.

We measured what “pays for it” comes to. The script is 128,293 bytes over the wire and 488,265 bytes once decompressed. The stylesheet is 15,285 bytes over the wire, 109,861 decompressed. The API response for a 20-review list is 1,738 bytes over the wire. That is roughly 142 KB of transfer and three round trips, on every page view, for zero pixels.

Worth saying plainly: this is not PrestaShop being broken, and it is not the widget being broken either. It is what happens when a three-part snippet is split across three template files that are edited at different times by different people. PrestaShop just makes it easy, because the templates are genuinely separate files and nothing checks that they agree.

A snippet pasted twice costs an API call, not a download

Two shops in the sample had the library more than once. gogolfun.pl has four widget script tags and three copies of the stylesheet link on its home page; gogolfun.it has three and two.

The obvious guess is that this downloads the file four times. It does not, and we checked rather than assumed. The browser deduplicates identical script URLs, so justreview.js is fetched once. What does double is the work: on both shops we recorded two separate getWidgetData calls to our API on a single page load, around 390 ms each. So a duplicated snippet costs an extra round trip and an extra render pass, not extra bandwidth. Our PrestaShop install guide says the library belongs in your templates only once for exactly this reason.

Do not diagnose this from view-source

One shop in the sample looked broken and was not. jawo2008.pl has the stylesheet, the script and a justreview-testimonials container in its HTML, and no init call anywhere in the served markup. By reading the source you would conclude the widget can never run.

Then we loaded it in a real browser. The widget renders at 1110 by 785 pixels, with a live API call for its Allegro reviews. The init simply arrives from somewhere the raw HTML does not show. The lesson is cheap and applies to every widget on every platform: PrestaShop themes concatenate and cache their JavaScript, so the served HTML is not the whole story. Open the page, not the source.

Where each of the three parts should go

PrestaShop gives you proper places to attach code, and they are visible in the theme it ships. In the classic theme for PrestaShop 8.1 and up, the layout ends with a displayBeforeBodyClosingTag hook, the footer partial exposes displayFooterBefore, displayFooter and displayFooterAfter, and index.tpl renders the home hook inside <section id="content" class="page-home">.

That last one is not theory. On the five shops in our sample whose container renders on the home page, the div sits exactly there, inside section#main > section#content, which is the region the stock index.tpl fills from the home hook. Whatever route those shop owners took, they landed in the place PrestaShop designed for this.

So, in order of what survives longest:

The library and the init call go once per shop, as late in the page as you can put them. A small HTML block attached to displayBeforeBodyClosingTag is the cleanest home, because it is a hook built for third-party scripts and it is not a file a theme vendor will replace. If you do edit templates, do it in a child theme. PrestaShop’s own index.tpl opens with a comment telling you not to edit it if you want to upgrade cleanly, and with 15 of 16 shops on a non-stock theme, that warning is aimed at almost everyone reading this.

The container div goes in the template that renders the page you want reviews on, and only there. If you want reviews on the home page and on product pages, that is two containers, not one, and the container id has to match the init call.

Then clear the cache in Advanced Parameters → Performance, and check the published shop rather than the back office preview. Both of those are the standard reason a correct paste appears to do nothing.

Your PrestaShop reviews are probably not all on Google

One more thing the sample shows, and it changes what widget you actually want. Across the 13 PrestaShop accounts, Google is the most common source but it is not close to universal, and a Polish marketplace shows up more often than eBay.

Three of those 13 accounts have Allegro as their only source. Together the 13 accounts store 9,661 reviews, 9,627 of them visible, with a median of 261 per shop. If your reviews sit on a marketplace rather than on a business profile, the approach is the same snippet and the same container, which we cover in putting marketplace reviews on your own site.

Why run our widget on PrestaShop

The reason to use JustReview here is that everything above was measurable from the outside. The widget is a stylesheet, a script and one init call from our domain, so there is no module to install in your shop, no PHP running on your server, no database queries added to a page load, and nothing to update when PrestaShop ships 8.3. When something looks wrong you open dev tools and see exactly what happened, which is how we found the five silent failures in the first place. That is also why it does not care whether your theme is classic, a vendor theme or a page builder: embedding it on your own site is the same three parts in all of them, and it puts Google, Facebook and marketplace seller feedback in one list.

Two caveats, and the second is about our own pricing. A review list is taller than people expect, around 700 to 800 pixels on desktop in the shops we measured, so give it a row of its own rather than squeezing it beside a product carousel. And the list widget starts on our paid Plus plan at 9 € a month: the free plan gives you the floating badge, 100 stored reviews and Google plus Facebook, no card. The median PrestaShop shop in our sample stores 261 reviews, which is already past the free cap, and Allegro is not a free-plan source at all, so three of those 13 accounts could not have run on free even if they wanted to. The full split is on our pricing page.

The honest route in is to create an account, connect your sources, and paste the badge into a hook first. It costs nothing, it needs no container div, so it cannot fail the way the five shops above failed, and it tells you within a minute whether your domain whitelist and your cache are in order. Add the list once you know the plumbing works. You can see that list widget running live further down this page.