Server-Rendered Reviews

Also known as client-side reviews, iframe reviews

There are three ways a review app can put reviews on a Shopify product page, and they look identical in a browser. The reviews can be rendered into the HTML the server sends, so they are in the document before any script runs. They can be fetched by JavaScript after the page loads and inserted into that same document. Or they can sit inside an iframe, which is a separate document served from the vendor's domain and displayed inside a window on your page. To a shopper these are the same thing. To anything that is not a browser they are three different situations.

The iframe case is the clearest. Content inside an iframe belongs to the framed document and its URL, not to the page that embeds it, and search engines generally attribute it there. So a store can have two hundred reviews on screen and a product page whose own text mentions reviews nowhere, which is a strange position to be in when the reviews were the thing you were paying to display.

The JavaScript case is subtler and more common. Google has said it executes JavaScript, but rendering is a second pass on its own budget and you cannot observe from outside whether or when a given page got it. More to the point, a browser is no longer the only reader. Plain fetches, link preview services, and several of the crawlers behind answer engines do not run scripts, and most publish little about what they do run. Structured data has exactly the same dependency: markup injected by a script is only there for readers that ran the script, which is why a page can pass a rendering-based testing tool and still never earn a rich result.

The check takes a minute and is the only version of this worth trusting. Fetch your own product URL without JavaScript, using curl or a browser with scripting disabled, and search the source for a sentence you know appears in a review. If the sentence is not there, the reviews exist for shoppers and not for readers, whatever the widget shows.

Consider a Shopify store selling a cast-iron casserole with 240 reviews on the page. The raw HTML comes back with no review text and no aggregateRating: the widget loads reviews from the app's own domain into a frame. Two things follow. The rich result never appeared, and the merchant had assumed the cause was review count, which it was not. And when the merchant asked an answer engine what buyers said about the enamel chipping, the reply drew on a marketplace listing of a comparable pan rather than on the 240 reviews the store owned. Switching the app to its server-rendered display option put the text and the markup in the source. The stars followed some weeks later. Whether the answer-engine behaviour changed is harder to attribute honestly, because nobody can see inside those systems, and a single store is not a measurement.

Server-rendering is not free. Putting the review block in the initial HTML adds weight to the document, and a block whose height is not reserved will shift the layout as it settles, which is a real cost measured in Core Web Vitals rather than a hypothetical one. Pagination has to be handled deliberately too, so that the pages holding the older reviews have URLs of their own instead of existing only as widget state. Those are engineering problems with known answers, which is a better position than a rendering problem with none.

For a merchant choosing an app, this is a purchase criterion that the vendor's marketing page will not answer and that costs nothing to check yourself: open the source on any live store already running that app and search it for a review sentence. Making the reviews a store already has readable and citable, rather than collecting more of them, is the gap BeyondReviews is built to close.