iframe은 링크 에쿼티를 전달하지 않습니다. 리뷰 위젯은 iframe입니다. 직접 계산해 보십시오..
많은 설정에서, 판매자의 상품 페이지에 있는 별점 5점짜리 리뷰를 향한 백링크는 실제로는 전혀 다른 도메인으로 연결되는 백링크입니다. 링크 에쿼티는 다른 곳에 쌓이고, 누적 레이아웃 이동(CLS) 페널티는 판매자에게 남습니다.
CONTENTS · 08
한 블로거가 2026년 최고의 클린 세럼을 소개하는 글을 씁니다. 블로거는 판매자의 상품 페이지 중 하나로 링크를 걸면서, Google 검색에서 찾은 고객 리뷰의 문구를 앵커 텍스트로 사용합니다. 이 링크는 하나의 투표입니다. Google의 링크 그래프에서 이 투표는 판매자의 도메인에 귀속되어야 합니다. 그 결과 판매자는 "clean serum 2026" 검색에서 더 높은 순위를 얻어야 합니다.
하지만 대부분의 리뷰 플랫폼이 기본값으로 제공하는 설정에서는 이 투표가 판매자에게 귀속되지 않습니다. 투표는 리뷰 플랫폼에 귀속됩니다.
이 에세이는 그 이유와 확인 방법, 그리고 자신이 소유하지 않은 배포 채널에 비용을 지불하는 소규모 스토어에 이것이 무엇을 의미하는지 설명합니다.
iframe이란 무엇인가, 두 문장으로
iframe은 부모 페이지의 창 안에 별도의 문서를 불러오는 HTML 요소입니다. 브라우저는 부모와 자식을 각각 별개의 DOM 트리, 별개의 출처, 별개의 CSS, 별개의 JavaScript 런타임, 그리고 별도로 주소를 지정할 수 있는 URL을 가진 두 개의 독립적인 문서로 렌더링합니다.
브라우저를 사용하는 구매자의 눈에는 두 문서가 시각적으로 겹쳐 보입니다. 별점과 리뷰가 상품 페이지 안에 있는 것처럼 보이는 것입니다. 하지만 브라우저는 이것이 두 개의 페이지임을 알고 있습니다. Google도 알고 있습니다. 링크 그래프도 두 개의 페이지로 취급합니다.
이것이 바로 이 구조적 문제의 전부입니다.
Trustpilot 사례 분석
Trustpilot은 커머스에서 가장 많이 사용되는 iframe 배포 방식입니다. Shopify 상품 페이지에 Trustpilot Stars 위젯을 설치한 판매자는 페이지의 HTML에 widget.trustpilot.com을 출처로 하는 iframe을 포함시키고 있는 것입니다. 그 뒤에는 긴 식별자 문자열이 붙습니다. iframe이 로드되면 Trustpilot은 그 안에 별점, 리뷰 수, 그리고 최근 리뷰를 렌더링합니다.
iframe의 콘텐츠는 widget.trustpilot.com에 있습니다. 정규 URL도 widget.trustpilot.com입니다. 메타 태그도 widget.trustpilot.com에 있습니다. Trustpilot 시스템에서 특정 리뷰에 연결되는 고유 링크는 trustpilot.com/review/[판매자명] 형태입니다. 이 URL 중 어느 것도 판매자의 도메인이 아닙니다.
이제 블로거가 상품 페이지에서 리뷰 중 하나를 읽고, 리뷰 제목을 클릭한 뒤 글에서 인용한다고 가정합니다. 많은 경우 블로거는 클릭한 리뷰의 URL, 즉 Trustpilot 정규 URL로 링크를 겁니다. 링크는 trustpilot.com으로 연결됩니다. 링크 에쿼티도 trustpilot.com으로 흘러갑니다. 판매자의 상품 페이지에는 아무것도 남지 않습니다.
반대로 블로거가 리뷰를 앵커 텍스트로 인용하며 판매자의 상품 페이지로 링크를 건다고 가정합니다. 링크는 판매자의 도메인으로 연결됩니다. Google이 판매자의 도메인을 크롤링하고 HTML을 파싱합니다. Google은 iframe을 발견합니다. 그러나 일반적인 경우 Google은 iframe의 콘텐츠를 판매자 페이지의 일부로 취급하지 않습니다. iframe은 별도의 문서이며, 색인이 되더라도 widget.trustpilot.com 아래에 색인됩니다. 블로거가 사용한 앵커 텍스트, 즉 리뷰 인용구는 의미론적으로 다른 출처에 있는 콘텐츠에 대한 설명이 됩니다. 관련성 신호는 불완전합니다. 페이지는 일부 점수를 얻지만, 같은 텍스트가 페이지 자체의 HTML 안에 단락으로 존재할 때 얻는 점수만큼은 아닙니다.
이것이 구조적 손실의 기본 원리입니다. 리뷰는 판매자가 비용을 지불하고, 판매자의 고객이 작성했지만, 판매자가 소유하지 않은 도메인으로 연결되는 콘텐츠입니다.
JavaScript 위젯이 낫긴 하지만, 크게 낫지는 않습니다
일부 리뷰 플랫폼(Yotpo 기본 설치, Okendo, Junip, Stamped)은 iframe을 사용하지 않습니다. 이들은 JavaScript를 통해 판매자 자신의 페이지에 있는 div에 리뷰를 주입합니다. 이 방식이 구조적으로 더 낫습니다. 렌더링되면 리뷰는 판매자의 DOM 안에 위치합니다. 구매자가 있는 URL은 판매자의 URL입니다. 정규 URL도 판매자의 정규 URL입니다. 링크 에쿼티는 올바르게 흐릅니다.
그러나 the end of the review widget에서 설명했듯, 문제가 있습니다. 리뷰는 JavaScript가 실행될 때만 존재합니다. Googlebot의 경우 JavaScript가 결국 실행되지만, 앞서 언급한 최신성 지연이 발생합니다. GPTBot, ClaudeBot, PerplexityBot의 경우 JavaScript가 전혀 실행되지 않습니다. 크롤러가 보는 페이지에는 리뷰가 없습니다.
따라서 세 가지 설정이 존재합니다.
iframe 설정: 리뷰가 다른 도메인에 위치하고, 링크 에쿼티는 판매자에게 귀속되지 않으며, 판매자의 페이지에 리뷰가 없으므로 어떤 크롤러도 판매자의 리뷰를 볼 수 없습니다.
JavaScript 주입 설정: 렌더링되면 리뷰가 판매자의 도메인에 위치하고 링크 에쿼티도 귀속되지만, AI 크롤러에게는 보이지 않고 Googlebot에게는 부분적으로만 보입니다.
서버 사이드 렌더링 설정: 리뷰가 판매자의 HTML에 포함되어 있고, 링크 에쿼티가 귀속되며, 모든 크롤러가 리뷰를 볼 수 있습니다. 이것이 거의 어떤 리뷰 위젯도 기본값으로 제공하지 않는 설정입니다.
계산은 간단합니다. iframe이 가장 나쁩니다. JavaScript 주입이 중간입니다. 서버 렌더링 HTML이 가장 좋습니다. 2026년 현재 대부분의 스토어는 최악의 두 가지 설정 중 하나를 사용하고 있습니다.
CLS 페널티
링크 에쿼티 문제와 구조적으로는 별개이지만, 같은 사안에 겹쳐 있는 두 번째 차원이 있습니다. Core Web Vitals는 2021년부터 Google의 순위 지표입니다. 2024년에는 Interaction to Next Paint 도입과 함께 업데이트되었습니다. 세 가지 신호 중 하나인 누적 레이아웃 이동(CLS)은 페이지가 로드되는 동안 콘텐츠가 얼마나 이동하는지를 측정합니다. Google은 CLS 점수가 0.1을 초과하는 페이지에 페널티를 부여합니다.
iframe에 로드된 리뷰 위젯은 많은 구현에서 위젯을 생성하는 스크립트에 의해 런타임에 크기가 결정됩니다. 페이지는 처음에 위젯 없이 렌더링됩니다. 스크립트가 로드됩니다. iframe이 주입됩니다. 위젯이 구매 버튼 아래 공간을 차지하면서 페이지 콘텐츠가 200~400픽셀 아래로 이동합니다. 해당 페이지 로드의 CLS 점수는 이동한 콘텐츠가 뷰포트를 얼마나 차지하는지에 따라 증가합니다. 2026년 초 자체 현장 측정에서, 잘 최적화된 Shopify 테마임에도 불구하고 iframe 기반 리뷰 위젯으로 인해 0.18~0.34의 이동값이 관측되었습니다.
다른 조건이 동일할 때, CLS 점수가 0.25인 페이지는 0.05인 페이지만큼 순위가 높지 않습니다. 판매자는 자신의 도메인에 속하지 않는 콘텐츠 블록을 호스팅하는 대가를 순위 하락이라는 형태로 지불하고 있습니다. 측정 방법론과 위젯별 상세 분석은 별도의 글에서 다루었습니다. 여기서 핵심은 구조적인 문제입니다. iframe은 두 축, 즉 링크 에쿼티 축과 Core Web Vitals 축에서 동시에 손실을 봅니다. 두 축 모두 알고리즘의 영역입니다. 판매자는 리뷰 플랫폼 업체를 바꾼다고 해서 어느 쪽도 해결할 수 없습니다. iframe이 바로 그 형태이고, 그 형태가 손실입니다.
"리뷰어가 직접 Trustpilot에 리뷰를 쓴 것 아닌가"
iframe 모델을 옹호하는 입장에서는 이렇게 말할 것입니다. 리뷰가 Trustpilot에 있는 것은 Trustpilot 리뷰이기 때문입니다. 리뷰어가 Trustpilot에 가입해서 거기에 작성했고, Trustpilot이 그 콘텐츠의 정규 공간입니다. iframe은 단순히 보여주기 위한 것입니다.
이것은 사실이지만, 핵심과 무관합니다. Trustpilot 위젯을 설치하는 판매자는 콘텐츠 배포 결정을 내리고 있는 것입니다. 자신의 상품 페이지에 Trustpilot의 콘텐츠를 노출하기로 선택한 것입니다. 그 선택의 비용이 이 에세이가 다루는 주제입니다. 구매자의 관점에서 리뷰어의 글은 판매자 페이지의 콘텐츠입니다. 구매자는 iframe과 인라인 블록의 차이를 알지 못합니다. 하지만 크롤러는 압니다. 링크 그래프는 압니다. CWV 측정도 압니다.
상업적 측면에서 리뷰어의 글은 콘텐츠 자산이기도 합니다. 판매자는 이 리뷰를 만들어낸 고객 관계에 비용을 지불했습니다. 이 리뷰를 유도한 구매 후 흐름에도 비용을 지불했습니다. 이 리뷰를 호스팅하는 플랫폼에도 비용을 냅니다. 그런데 판매자는 그 글이 위치한 정규 URL을 소유하지 않으므로, 그 글의 검색 가능성에서 오는 장기적 이익을 가져가지 못합니다.
이것이 더 깊은 수준에서 the category error가 다룬 내용입니다. 그 카테고리 실수는 리뷰를 콘텐츠 자산이 아닌 UI 기능으로 취급한 것이었습니다. iframe 설정은 그 실수의 가장 극단적인 형태입니다. 판매자가 콘텐츠 비용을 지불하고, 콘텐츠를 표시하면서도, 콘텐츠가 위치한 URL을 소유하지 못하는 것입니다.
"그러면 JavaScript 위젯을 쓰면 되지 않는가"
두 번째 반응이 있습니다. iframe이 나쁜 버전이라면 JavaScript 위젯이 좋은 버전이니, iframe 대신 JavaScript 주입 방식의 플랫폼을 선택하면 문제가 해결된다는 것입니다.
이것은 부분적인 해결책입니다. JavaScript 위젯은 판매자의 DOM 안에 위치하므로 링크 에쿼티 문제는 해결됩니다. 그러나 초기 HTML에는 없기 때문에, AI 크롤러 문제는 완전히 열려 있고 Googlebot의 최신성 문제는 절반만 해결됩니다. 세 크롤러를 대상으로 한 curl 실험은 이미 다른 글에서 다루었습니다. 결과는 JavaScript 위젯이 GPTBot, ClaudeBot, PerplexityBot에는 보이지 않고, Googlebot에는 부분적으로만 보인다는 것입니다.
iframe 위젯에서 JavaScript 위젯으로 전환한 판매자는 링크 에쿼티 흐름을 개선한 것입니다. 그러나 인용 경제(citation economy)에서 리뷰가 보이도록 한 것은 아닙니다. 사실상 '가장 나쁜' 상태에서 '중간' 상태로 이동한 것입니다. 올바른 방향은 계속 나아가는 것입니다. JavaScript 주입에서 서버 렌더링 HTML로, 즉 모든 크롤러가 읽을 수 있는 페이지에 리뷰가 있고, 링크 에쿼티, 인용, 최신성이 모두 판매자의 도메인으로 함께 흘러오는 상태로 이동해야 합니다.
JavaScript 주입 방식은 동일한 iframe 문제의 완화된 버전을 만들어냅니다. 리뷰는 판매자의 DOM에 있지만, 사진 URL, 리뷰어 프로필 페이지, 리뷰별 고유 링크는 플랫폼의 CDN이나 플랫폼의 리뷰 상세 페이지를 자주 가리킵니다. 판매자의 상품 페이지에서 Yotpo 리뷰를 인용하는 블로거는 리뷰를 복사할 때 해당 리뷰의 yotpo.com 고유 링크로 이동하는 경우가 많습니다. 더 나은 설정에서도 판매자의 콘텐츠 자산 일부가 다른 도메인에 파킹됩니다. 이를 완화하려면 페이지의 모든 리뷰 관련 URL이 판매자 자신의 도메인으로 연결되도록 해야 합니다. 대부분의 기본값은 그렇지 않습니다.
iframe은 카테고리 오류를 가장 명확하게 보여주는 사례입니다. 판매자는 글의 비용을 지불하고, 글을 표시하면서도, 글이 위치한 URL을 소유하지 못합니다. 고객이 브랜드에 보내는 편지를 썼는데, 판매자가 그것을 남의 우편함에 넣어둔 것입니다.
판매자가 직접 할 수 있는 간단한 점검
세 가지 확인 사항이 있으며, 각각 10분씩 걸립니다.
첫 번째 확인. 브라우저에서 상품 페이지를 열고, 리뷰 섹션에서 우클릭한 뒤 '요소 검사'를 선택합니다. 리뷰 블록 안에 iframe 태그가 있는지 확인합니다. 있다면 리뷰는 다른 문서에 있는 것입니다. iframe의 src 속성을 확인해 어떤 도메인인지 파악합니다.
두 번째 확인. Chrome DevTools의 Performance 탭에서 캐시를 비활성화한 상태로 새로 로드를 기록합니다. Layout Shift 항목을 확인합니다. 리뷰 위젯이 0.1 이상의 이동값을 만들어낸다면, 페이지는 매 로드마다 Core Web Vitals 페널티를 받고 있는 것입니다. 2026년 현재 자체 점검에 따르면, 커머스 페이지의 CLS 문제 중 3분의 2는 리뷰 위젯에서 비롯됩니다.
세 번째 확인. 판매자의 최근 리뷰 중 특정 문구를 검색해 봅니다. 검색 엔진이 trustpilot.com이나 reviews.io 또는 다른 리뷰 플랫폼 도메인 페이지를 반환하면서 판매자의 상품을 언급하고 있다면, 그리고 판매자 자신의 상품 페이지가 아니라면, 그 글의 정규 공간은 판매자가 매출을 거두는 곳이 아닌 어딘가에 있는 것입니다. 그 리뷰로 링크를 거는 블로거는 그 도메인으로 링크를 걸 것입니다. 그 링크를 통해 오는 구매자는 그 도메인에 도착할 것입니다. 구매 여정이 남의 부지에서 시작되는 셈입니다.
마무리
리뷰 위젯을 설치하는 판매자는 대부분 인식하지 못한 채 콘텐츠 배포 결정을 내리고 있습니다. iframe 설정은 판매자가 비용을 지불한 콘텐츠를 판매자가 소유하지 않은 도메인에 배포합니다. JavaScript 주입 설정은 구매자의 브라우저에서는 콘텐츠를 판매자의 도메인에 유지하지만, 크롤러의 색인에서는 그렇지 않습니다. 서버 렌더링 HTML 설정은 중요한 모든 맥락에서 콘텐츠를 판매자의 도메인에 유지합니다.
우리는 15년 동안 iframe과 JavaScript 위젯 위에 리뷰 플랫폼을 구축해 왔습니다. 커머스에서 우리는 배포 비용을 지불하면서 자신의 고객이 쓴 글의 정규 URL이 판매 페이지가 아닌 다른 곳에 있다는 것을 당연하게 받아들였습니다. 이것은 더 이상 용납할 수 있는 거래가 아닙니다. 링크 에쿼티는 판매자의 것입니다. 리뷰도 판매자의 것입니다. 페이지도 판매자의 것이어야 합니다.
the half life of a product page에서 썼듯이, 상품 페이지의 반감기는 페이지가 복리로 누적되는 콘텐츠를 쌓느냐에 달려 있습니다. 리뷰는 판매자가 가진 가장 복리로 누적되는 자산입니다. iframe은 그 자산을 다른 도메인에 넘겨줍니다. 직접 계산해 보십시오. 계산이 복잡하지 않습니다.
THE LETTER
When there is a new essay worth sending, it goes here first.
If any of this reads like something your store could use,write to us.
We will write back.