How to Add Reviews to Magento: Saving Is Not Publishing

Every hosted builder in this series has the same last step: press publish and it is live. Magento does not work that way, and that single difference accounts for most of the trouble people have adding anything to a storefront. The embed goes in through an HTML Code element in Page Builder and takes about a minute. Then there is a cache inside Magento, usually a cache in front of Magento, and often a CDN in front of that, and until those agree with the database nobody sees what you saved.

The One Store Here Where Publish Is Not the Last Step

Magento is software you run rather than a service you log into, and it is built to serve pages fast under load, which means serving them from a cache rather than rebuilding them per visitor. That is the correct design for a store, and it is also why an admin save and a shopper seeing the change are two separate events.

It helps to hold the layers in mind before touching anything. There is the database, where your saved content lives. There is Magento’s own cache, which holds rendered layouts and blocks and full pages. Then in production there is usually Varnish, and often a CDN above that.

Nothing about this is exotic and none of it is a problem to be solved. It just means the checklist is longer than paste and save, and knowing that in advance turns a confusing afternoon into a four-step task.

The HTML Code Element in Page Builder

From the admin, open the CMS page or block where the reviews belong and edit it with Page Builder. Drag an HTML Code element into the row you want, click into it and paste the widget embed. Save the page. That is the whole of the content half of the job.

Use an HTML Code element rather than a Text element. A text editor runs content through a WYSIWYG layer that can escape a script tag or rewrite attributes, which is the usual reason a snippet that is definitely correct renders as visible markup instead of as a widget.

If the reviews are wanted in more than one place, put the embed in a CMS block rather than repeating it across pages, then reference the block. One place to edit later is worth the extra minute now, particularly on a store where a template change is a deployment.

Open Source or Adobe Commerce, Same Route

Page Builder used to be the dividing line here, and that is no longer true. Adobe’s release notes state that Page Builder is available as a bundled extension in Magento Open Source, and that it is the default content editing tool for Adobe Commerce 2.4.3 and Magento Open Source 2.4.3.

So the HTML Code element is present on both editions and the instructions above do not fork. This matters because a lot of older writing about Magento embeds assumes Page Builder is a commercial feature and sends Open Source users towards the legacy WYSIWYG editor for no reason.

On a store older than 2.4.3 the editor will be the legacy one, in which case the same principle applies in its own terms: use the source or code view rather than the visual field, because the visual field is what escapes the markup.

What the Invalidated Cache Notice Means

Magento maintains a set of cache types, among them Configuration, Layouts, Blocks HTML output, Collections Data and the Full Page Cache. Saving content invalidates the ones your change affects, and the admin surfaces a notification with a link to the Cache Management page whenever a refresh is needed.

Follow that link and refresh the invalidated types rather than flushing everything by reflex. A full flush on a busy store means every page is rebuilt from scratch for the next wave of visitors, which is a real performance event and an unnecessary one when two cache types were the only ones affected.

If the notification is not showing and the change still is not visible, that is informative in itself. It usually means Magento thinks it has served you the current version, which points at the layer above rather than at Magento.

The Layer Above Magento

Adobe recommends Varnish for full page caching in production, and most serious Magento stores run it. Varnish holds fully rendered pages and answers visitors directly, so it will keep serving the previous version of your page after Magento itself has moved on, until it is purged or its cached copy expires.

A CDN in front of that behaves the same way and needs the same treatment. Between them these two layers explain nearly every case of a change that is definitely saved, definitely cache-refreshed in the admin, and definitely not on the storefront.

The quickest way to tell them apart is to load the page in a way that bypasses the caches your team has set up for that purpose, or to check the response headers for a cache hit. Whoever deploys the store will know the local answer, and it is a thirty-second question rather than an investigation.

How Do You Build the Widget?

Paste your Google, Trustpilot or Facebook profile URL, preview your real reviews and rating, then choose from over 100 layout styles across the slider, marquee, grid, list, masonry and badge families, and set the colours to the theme.

The header rating comes from the platform aggregate rather than being averaged from the cards on screen, so the figure on the storefront is the figure on the profile. On a store that also collects its own product ratings, keeping those two numbers honest and clearly separate is worth the care.

Free plan, unlimited widget views. A Magento store is usually the one with real traffic, and a widget with a view ceiling would fail exactly when the store is doing well.

Where Should the Reviews Go?

The home page below the main banner, and the category landing pages. Those are the pages where a shopper is still deciding whether to buy from this store rather than which item to buy, which is the question a business-level review answers.

Keep it out of the product grid. A row of review cards interrupting a listing costs scanning speed on the page whose entire job is scanning speed, and the shopper who wanted reassurance has already had it on the way in.

On a multi-store or multi-site installation, remember that a review profile is usually one business. If store views serve different brands or regions, each wants its own CMS block rather than a single shared one, which is another argument for putting the embed in a block from the start.