Iframes don’t pass link equity. Review widgets are iframes. Do the math..

A blogger writes a piece about the best clean serums of 2026. She links to one of the merchant's product pages, with anchor text that quotes a customer review the blogger found through a Google search. The link is a vote. The vote is, in Google's link graph, supposed to accrue to the merchant's domain. The merchant should rank higher for "clean serum 2026" as a result.

In the configuration most review platforms ship by default, the vote does not accrue to the merchant. It accrues to the review platform.

This essay is the explanation of why, and how to check, and what it means for a small store paying for distribution it does not own.

An iframe is an HTML element that loads a separate document inside a window on a parent page. The browser renders the parent and the child as two distinct documents, with separate DOM trees, separate origins, separate CSS, separate JavaScript runtimes, and separately addressable URLs.

The buyer in the browser sees the two documents visually overlaid: stars and reviews appearing to live inside the product page. The browser knows they are two pages. Google knows they are two pages. The link graph treats them as two pages.

This is the entire mechanical problem.

Trustpilot is the most-trafficked iframe deployment in commerce. A merchant who installs the Trustpilot Stars widget on a Shopify product page is shipping, in the page's HTML, an iframe whose source is widget.trustpilot.com followed by a long string of identifiers. The iframe loads. Inside the iframe, Trustpilot renders the stars, the count, perhaps a recent review.

The iframe's content is at widget.trustpilot.com. Its canonical URL is at widget.trustpilot.com. Its meta tags are at widget.trustpilot.com. Any reviewer's permalink to a specific review on the Trustpilot system is at trustpilot.com slash review slash [merchant]. None of these URLs are the merchant's domain.

Now suppose the blogger reads one of those reviews on the product page, clicks the review's headline, and quotes it in her piece. She links, in many cases, to the Trustpilot canonical URL, because that is the URL of the review she clicked. The link goes to trustpilot.com. The link equity goes to trustpilot.com. The merchant's product page receives nothing.

Suppose instead the blogger links to the merchant's product page, with the review quoted as anchor text. The link goes to the merchant's domain. Google fetches the merchant's domain. Google parses the HTML. Google finds the iframe. Google does not, in the standard case, treat the iframe's contents as part of the merchant's page; the iframe is a separate document, indexed (where it is indexed at all) under widget.trustpilot.com. The anchor text the blogger used, the quote of the review, is therefore semantically a description of content that lives at a different origin. The relevance signal is partial. The page gets some credit, but not the credit a paragraph of the same text in the page's own HTML would get.

This is the basic mechanical loss. The reviews are content the merchant has paid for, that the merchant's customers wrote, that link to a domain the merchant does not own.

Some review platforms (Yotpo in its standard install, Okendo, Junip, Stamped) do not use iframes. They inject reviews via JavaScript into a div on the merchant's own page. This is mechanically better. The reviews, when rendered, live in the merchant's DOM. The URL the buyer is on is the merchant's URL. The canonical is the merchant's canonical. The link equity flows correctly.

The catch, as we walked through in the end of the review widget, is that the reviews exist only when the JavaScript runs. For Googlebot the JavaScript runs eventually, with the freshness lag we wrote about. For GPTBot, ClaudeBot, and PerplexityBot the JavaScript does not run at all. The reviews are not on the page that the crawler sees.

So we have three configurations.

The iframe configuration: reviews live on a different domain, link equity does not accrue to the merchant, no crawler sees the merchant's reviews because there are no reviews on the merchant's page.

The JavaScript-injection configuration: reviews live on the merchant's domain when rendered, link equity does accrue, but the reviews are invisible to the AI crawlers and partially visible to Googlebot.

The server-side-rendered configuration: reviews are in the merchant's HTML, link equity accrues, all crawlers see the reviews. This is the configuration almost no review widget defaults to.

The math is straightforward. Iframe is worst. JavaScript-injection is middle. Server-rendered HTML is best. Most stores in 2026 are running one of the worst two.

There is a second dimension, mechanically separate from the link equity question but layered on the same incident. Core Web Vitals are a Google ranking signal as of 2021, refreshed in 2024 with the introduction of Interaction to Next Paint. One of the three signals is Cumulative Layout Shift, which measures how much the page's content moves around as it loads. Google penalises pages with a CLS score above 0.1.

A review widget loaded in an iframe is, in many implementations, sized at runtime by the script that creates it. The page initially renders without the widget. The script loads. The iframe injects. The page's content shifts down by 200 to 400 pixels as the widget claims its space below the buy button. The CLS score, for that page load, increments by an amount that depends on how much of the viewport the shifted content occupies. We have, in our own field measurements in early 2026, observed shifts of 0.18 to 0.34 from iframe-based review widgets on otherwise-well-tuned Shopify themes.

A page with a 0.25 CLS score does not rank as well as a page with a 0.05 CLS score, all else equal. The merchant is paying, in ranking position, for the privilege of hosting a content block that does not belong to her domain. We addressed the measurement methodology and per-widget breakdown in a separate piece. The point here is structural: the iframe loses on two axes at once, the link-equity axis and the CWV axis, both of which are the algorithm's. The merchant cannot fix either by switching review-platform vendors. The iframe is the shape, and the shape is the loss.

A defender of the iframe model will say: the reviews live at Trustpilot because they are Trustpilot reviews. The reviewer registered on Trustpilot, wrote there, and Trustpilot is the canonical home for the content. The iframe is a courtesy display.

This is true, and irrelevant. The merchant who installs the Trustpilot widget is making a content-distribution decision: she is choosing to surface Trustpilot's content on her own product page. The cost of that choice is what this essay is about. The reviewer's writing is, from the buyer's point of view, content on the merchant's page; the buyer does not know the difference between an iframe and an inline block. The crawler does. The link graph does. The CWV measurement does.

The reviewer's writing is also, in commercial terms, a content asset. The merchant paid for the customer relationship that produced it. The merchant paid for the post-purchase flow that prompted it. The merchant pays for the platform that hosts it. The merchant does not own the canonical URL the writing lives at, and so does not capture the long-run benefit of the writing's discoverability.

This is what the category error was about, at a deeper level. The category mistake was to treat the review as a UI feature, not as a content asset. The iframe configuration is the most extreme version of that mistake: the merchant has paid for the content, displayed the content, and does not own the URL the content lives at.

A second response: the iframe is the bad version. The JavaScript widget is the good version. Pick a platform that does JavaScript injection rather than iframes and the problem is solved.

This is a partial solution. The JavaScript widget does live in the merchant's DOM, which fixes the link equity question. It does not live in the initial HTML, which leaves the AI crawler question wide open and the Googlebot freshness question half-closed. We have already walked the curl-against-three-crawlers experiment elsewhere; the result is that the JavaScript widget is invisible to GPTBot, ClaudeBot, and PerplexityBot, and partially visible to Googlebot.

The merchant who switches from an iframe widget to a JavaScript widget has improved the link equity flow. She has not made the reviews visible to the citation economy. She has, in effect, moved from "the worst" to "the middle". The right move is to keep moving: from JavaScript injection to server-rendered HTML, where the reviews are in the page that any crawler can read, and where the link equity, the citation, and the freshness all flow back to the merchant's domain together.

The JavaScript-injection model creates a softer version of the same iframe problem: the reviews live in the merchant's DOM, but the photo URLs, the reviewer profile pages, and the per-review permalinks frequently point back to the platform's CDN or the platform's review-detail pages. The blogger who quotes a Yotpo review on a merchant's product page often, upon copying the review, lands on a yotpo.com permalink for that specific review. Even in the better configuration, slivers of the merchant's content asset get parked under someone else's domain. The mitigation is to ensure every review-related URL on the page resolves to the merchant's own domain. Most defaults do not.

The iframe is the cleanest illustration of the category error. The merchant pays for the writing, displays the writing, and does not own the URL the writing lives at. The customer wrote a love letter to the brand. The merchant put it in someone else's mailbox.

Three checks, ten minutes each.

Check one. Open the product page in a browser, right-click on the review section, choose "Inspect Element". Look for an iframe tag inside the review block. If there is one, the reviews are on a different document; check the iframe's src attribute to see whose domain it is.

Check two. Open the page in Chrome DevTools, Performance tab, record a fresh load with the cache disabled. Look at the Layout Shift entries. If the review widget contributes a shift of 0.1 or more, the page is paying a CWV penalty on every load. Two-thirds of CLS issues on commerce pages in 2026, in our spot-checks, trace to review widgets.

Check three. Search the web for a specific phrase from one of the merchant's recent reviews. If the search engine returns a page on trustpilot.com or reviews.io or any review-platform domain, with the merchant's product mentioned, and not the merchant's own product page, the canonical home for that piece of writing is somewhere other than where the merchant collects the revenue. The blogger linking to that review will link to that domain. The buyer arriving via that link will arrive at that domain. The funnel begins on someone else's property.

The merchant who installs a review widget is making, mostly without knowing it, a content-distribution decision. The iframe configuration distributes content the merchant has paid for to a domain the merchant does not own. The JavaScript-injection configuration keeps the content on the merchant's domain in the buyer's browser, but not in the crawler's index. The server-rendered HTML configuration keeps the content on the merchant's domain in every context that matters.

We have spent fifteen years building review platforms on the iframe and the JavaScript widget. We have, in commerce, paid for distribution and accepted that the canonical URL of our own customers' writing lives somewhere other than the page we sell from. This is no longer a tolerable trade. The link equity is the merchant's. The reviews are the merchant's. The page should be the merchant's.

The half-life of a product page, as we wrote in the half life of a product page, depends on the page accumulating content that compounds. Reviews are the most compounding asset a merchant has. The iframe gives that asset to a different domain. Do the math. The math is not subtle.