Platforms

How to add a Google reviews widget to WordPress (3 ways, measured)

26 July 2026 · JustReview

If you want Google reviews on a WordPress page, you have three real options: a plugin, a snippet in your theme, or a Custom HTML block in the editor. All three end up doing the same thing in the browser, because every review widget on the market is client-side JavaScript. The difference is what happens on your server, and that difference is measurable.

Here is the short version. A plugin adds PHP that runs on every page load and usually stores review copies in your database. A snippet adds two cached static files and touches nothing in WordPress. Unless you specifically need reviews inside WordPress content (for search inside your own site, or for a custom template loop), the snippet is the lighter choice.

The three ways, side by side

The last row matters more than people expect. Review plugins are a graveyard: the platform changes an API, the plugin stops importing, and the site keeps showing three-year-old reviews until someone notices. A widget that fetches from a live endpoint fails loudly instead, which is easier to catch.

What the widget actually costs

We measured our own production files on 26 July 2026, requesting them the way a browser does, with Brotli enabled:

So the page pays roughly 143 KB of transfer for two requests, both served from the CDN edge with a long cache lifetime, plus one request to our API for the review data itself. On the WordPress side the cost is zero: no PHP executes, no query hits wp_posts or wp_postmeta, and nothing is written to your database.

That is the honest number, not a marketing number. 143 KB is not nothing. It is, however, less than a single hero image on most WordPress themes, and it is static, cacheable and off your server. A plugin that renders reviews server-side moves that work back onto your hosting, on every uncached page view.

Why not just call the Google API yourself?

Because of a cap that surprises most developers on day one: Google’s public Places API returns a maximum of five reviews per place, and you do not choose which five. That is why so many free “Google reviews” tools show exactly five reviews and no more. To display more than that, reviews have to be imported and stored, which is the part that takes infrastructure rather than an afternoon.

There is a second reason. Once you have built the Google integration, the next request from your client is always Facebook, then the industry platform they actually care about, then the marketplace they sell on. That is a different integration each time, with a different failure mode each time.

The snippet method, step by step

This is the version we recommend for most WordPress sites.

1. Decide where the reviews should appear. Put a container in the template or in the page content where you want the widget to render:

   <div id="justreview-testimonials"></div>

2. Load the widget once, globally. In a child theme’s footer.php, or through a code-snippets plugin that outputs to wp_footer, add:

   <link rel="stylesheet" href="https://justreview.co/widget/justreview.css">
   <script defer src="https://justreview.co/widget/justreview.js"></script>

3. Initialise it with your account hash. The hash comes from your JustReview dashboard, and the services array decides which connected sources feed this particular widget:

   <script>
     document.addEventListener('DOMContentLoaded', function () {
       JustReview.initTestimonials('YOUR_HASH', {
         config: { limit: 20, displaySlider: true, visibleSlides: 3, displayDate: true },
         services: ['google', 'facebook']
       });
     });
   </script>

4. Check it on a page that is not cached. Open the page in a private window and look at the browser console. An empty container with no console error almost always means the script was blocked, not that the code is wrong. More on that below.

The full copy-paste version, including the block editor route, lives in our WordPress installation guide.

The five reasons it renders nothing

We see these in support in roughly this order.

1. A consent tool is holding the script. Cookie banners with automatic blocking (Cookiebot’s auto mode is the common one) rewrite third-party <script> tags to inert types until the visitor accepts. The widget then never initialises for the majority of visitors who never click anything. We hit this on our own site. If your review widget sets no cookies, mark the tag so the consent tool leaves it alone:

<script defer src="https://justreview.co/widget/justreview.js" data-cookieconsent="ignore"></script>

Check your own widget’s network and storage footprint before you do this, and keep the decision documented. “It sets no cookies” is a claim you should be able to prove, not assume.

2. A caching or minification plugin reordered your code. Autoptimize, WP Rocket and friends combine and defer inline scripts. If your JustReview.init... call ends up executing before the library has loaded, you get JustReview is not defined in the console and an empty div. Exclude the inline init from combination, or wrap it in a small retry loop.

3. The container is missing. Page builders sometimes strip unknown id attributes, and a Custom HTML block inside a collapsed accordion may not exist in the DOM when init runs.

4. The account hash is wrong. Copying it from an old tab or a colleague’s account produces a valid-looking call that returns no data.

5. The source has not finished importing. First-time imports of a large profile take time. If the API returns no reviews, the widget renders nothing rather than an empty frame.

Where to put it on a WordPress site

Placement decides whether the widget does any work at all. Three spots earn their keep, in this order.

On the page where the decision happens. For a service business that is the service page, not the homepage. For a shop it is the product page and the cart. Reviews work as an objection handler, so they belong next to the objection: the price, the booking form, the “add to cart” button. A slider parked in the footer of every page is decoration.

Just above the contact or booking form. This is the cheapest win on most WordPress sites, because the form is where visitors hesitate and reviews answer the question they are actually asking: “will these people show up and do the job?”

On a dedicated reviews page, linked from the main menu. This one has a second benefit: it is a page you can point to from quotes, emails and Google Business Profile, and it is indexable content of your own. Use the reviews-page widget rather than the slider there, because visitors who land on that page came to read, not to be entertained by an autoplay carousel.

What we would not do: put the same slider in the header of every template. It pushes your actual content below the fold on mobile, and reviews stop being read the moment they become furniture.

If you want to see all six widget types side by side before choosing, they are on the Google reviews widget page, and the display limits per plan are on the pricing page.

Which option should you actually pick?

• Snippet in a child theme if you want reviews sitewide with the least server cost. This is the default we would choose.
• Custom HTML block if reviews belong on one landing page only, or if nobody on the team is comfortable editing theme files.
• Plugin only if you need review content stored inside WordPress, for example to loop over it in a custom template or to make it searchable by your site’s own search.

One thing worth deciding at the same time: do not plan for Google alone. Every business we onboard starts with Google and ends up connecting at least one more source, because Google is where people look and the other platforms are where the reviews already are. Whatever you install, check that it can add a second source without a rebuild.