iframeはリンクエクイティを渡しません。レビューウィジェットはiframeです。計算は単純です。.

2026年のベストクリーンセラムについて、あるブロガーが記事を書きます。彼女はストア運営者の商品ページにリンクを張り、ブロガーがGoogle検索で見つけた顧客レビューからの引用をアンカーテキストとして使います。このリンクは一票の投票です。Googleのリンクグラフでは、この投票はストア運営者のドメインに蓄積されるはずです。その結果、ストア運営者は「クリーンセラム 2026」でより上位に表示されるようになるはずです。

ところが、ほとんどのレビュープラットフォームがデフォルトで採用している設定では、この投票はストア運営者に蓄積されません。レビュープラットフォームに蓄積されます。

このエッセイは、その理由の説明です。確認方法と、対価を払いながら所有していないドメインへの配信を続けている小規模なストアにとっての意味についても説明します。

iframeとは、親ページの画面内に別の文書を読み込むHTML要素です。ブラウザは親文書と子文書を、別々のDOMツリー、別々のオリジン、別々のCSS、別々のJavaScriptランタイム、そして別々のアドレスを持つ2つの独立した文書として処理します。

購入者はブラウザ上で2つの文書が視覚的に重なって見えます。商品ページの中に星評価やレビューが存在しているように見えます。しかしブラウザは2つのページがあることを知っています。Googleも知っています。リンクグラフも2つのページとして扱います。

これが問題の機械的な仕組みのすべてです。

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/[merchant]にあります。これらのURLのいずれも、ストア運営者のドメインではありません。

ここで、ブロガーが商品ページのレビューを読み、レビューの見出しをクリックして自分の記事で引用したとします。多くの場合、彼女はTrustpilotのカノニカルURLにリンクします。なぜなら、それが彼女がクリックしたレビューのURLだからです。リンクはtrustpilot.comに向かいます。リンクエクイティはtrustpilot.comに向かいます。ストア運営者の商品ページには何も届きません。

今度は、ブロガーがレビューをアンカーテキストとして引用し、ストア運営者の商品ページにリンクしたとします。リンクはストア運営者のドメインに向かいます。Googleはストア運営者のドメインを取得します。GoogleはHTMLを解析します。Googleはiframeをみつけます。標準的なケースでは、Googleはiframeのコンテンツをストア運営者のページの一部として扱いません。iframeは独立した文書であり、インデックスされる場合はwidget.trustpilot.comの下でインデックスされます。ブロガーが使ったアンカーテキスト、つまりレビューの引用は、別のオリジンにあるコンテンツの説明として意味論的に処理されます。関連性シグナルは部分的なものにとどまります。ページはある程度の評価を得ますが、同じテキストをページ独自のHTMLに段落として書いた場合に得られる評価には及びません。

これが基本的な機械的損失です。レビューはストア運営者が対価を払ったコンテンツであり、ストア運営者の顧客が書いたものであり、ストア運営者が所有していないドメインにリンクしているものです。

一部のレビュープラットフォーム（標準インストールのYotpo、Okendo、Junip、Stamped）はiframeを使いません。JavaScriptを通じて、ストア運営者独自のページのdivにレビューを挿入します。機械的にはこちらの方が優れています。レビューがレンダリングされると、それはストア運営者のDOMの中に存在します。購入者がいるURLはストア運営者のURLです。カノニカルはストア運営者のカノニカルです。リンクエクイティは正しく流れます。

ただしthe end of the review widgetで詳述したように、これには前提条件があります。レビューはJavaScriptが実行されたときにのみ存在します。Googlebotにとって、JavaScriptはいずれ実行されますが、鮮度の遅延を伴います。GPTBot、ClaudeBot、PerplexityBotにとって、JavaScriptは全く実行されません。レビューはクローラーが見るページには存在しません。

つまり、3つの設定があります。

iframeの設定：レビューは別のドメインに存在し、リンクエクイティはストア運営者に蓄積されません。ストア運営者のページにはレビューがないため、どのクローラーもストア運営者のレビューを見られません。

JavaScript挿入の設定：レビューはレンダリング時にストア運営者のドメインに存在し、リンクエクイティは蓄積されます。しかしAIクローラーにはレビューが見えず、Googlebotにも部分的にしか見えません。

サーバーサイドレンダリングの設定：レビューはストア運営者のHTMLに存在し、リンクエクイティが蓄積され、すべてのクローラーがレビューを見られます。これはほぼすべてのレビューウィジェットがデフォルトとして採用していない設定です。

数字は明快です。iframeが最悪です。JavaScript挿入が中間です。サーバーレンダリングのHTMLが最良です。2026年のほとんどのストアは、最悪の2つのうちいずれかを使っています。

リンクエクイティの問題とは機械的に独立していながらも、同じ問題に重なる第2の次元があります。Core Web Vitalsは2021年からGoogleのランキングシグナルであり、2024年にInteraction to Next Paintの導入でリフレッシュされました。3つのシグナルのうちの一つが累積レイアウトシフト（CLS）です。これはページが読み込まれる際にコンテンツがどれだけ移動するかを測定します。Googleはスコアが0.1を超えるページにペナルティを与えます。

iframeに読み込まれたレビューウィジェットは、多くの実装において、ウィジェットを生成するスクリプトによって実行時にサイズが決まります。ページは最初、ウィジェットなしでレンダリングされます。スクリプトが読み込まれます。iframeが挿入されます。ウィジェットが購入ボタンの下のスペースを占有するにつれて、ページのコンテンツが200から400ピクセル下に移動します。そのページ読み込みのCLSスコアは、移動したコンテンツがビューポートを占める割合に応じて増加します。2026年初頭の私たちの実際のフィールド測定では、それ以外の点ではよく最適化されたShopifyのテーマ上のiframeベースのレビューウィジェットで、0.18から0.34のシフトが観測されています。

CLSスコアが0.25のページは、他の条件が等しければ、スコアが0.05のページほど上位に表示されません。ストア運営者は、自分のドメインに属さないコンテンツブロックを掲載する特権のために、検索順位という形で代償を払っています。測定方法とウィジェット別の詳細については別の記事で取り上げました。ここで重要なのは構造的な点です。iframeは同時に2つの軸で失点します。リンクエクイティの軸と、Core Web Vitalsの軸です。どちらもアルゴリズムの評価対象です。ストア運営者はレビュープラットフォームのベンダーを変えても、どちらも修正できません。iframeという形そのものが損失の形です。

iframeモデルの擁護者はこう言うかもしれません。レビューがTrustpilotにあるのは、それがTrustpilotのレビューだからです。レビュアーはTrustpilotに登録し、そこに書きました。Trustpilotはそのコンテンツのカノニカルな場所です。iframeは礼儀としての表示に過ぎません。

これは事実ですが、無関係です。Trustpilotウィジェットをインストールするストア運営者は、コンテンツ配信の決断をしています。つまり、Trustpilotのコンテンツを自分の商品ページで表示することを選んでいます。その選択のコストが、このエッセイのテーマです。レビュアーの文章は、購入者の視点からすると、ストア運営者のページ上のコンテンツです。購入者はiframeとインラインブロックの違いを知りません。しかしクローラーは知っています。リンクグラフは知っています。Core Web Vitalsの測定も知っています。

レビュアーの文章はまた、商業的な観点からもコンテンツ資産です。ストア運営者はそれを生み出した顧客関係に対価を払いました。購入後のフローに対価を払いました。それをホストするプラットフォームの利用料を払っています。しかしストア運営者は、その文章が存在するカノニカルURLを所有していないため、その文章の発見可能性がもたらす長期的な便益を享受できません。

これがthe category errorのテーマでした。より深いレベルで言えば、レビューをUIの機能として扱い、コンテンツ資産として扱わなかったことが誤りでした。iframeの設定はその誤りの最も極端な形です。ストア運営者はコンテンツに対価を払い、コンテンツを表示しながら、そのコンテンツが存在するURLを所有していません。

2つ目の反論：iframeが悪い方法であり、JavaScriptウィジェットが良い方法です。iframeではなくJavaScript挿入を採用するプラットフォームを選べば問題は解決します。

これは部分的な解決策です。JavaScriptウィジェットはストア運営者のDOMに存在するため、リンクエクイティの問題は修正されます。しかし最初のHTMLには存在しないため、AIクローラーの問題は全く未解決のまま残り、Googlebotの鮮度の問題も半分しか解決されません。3つのクローラーに対してcurlを実行する実験については別の場所で説明しました。結果は、JavaScriptウィジェットがGPTBot、ClaudeBot、PerplexityBotには見えず、Googlebotにも部分的にしか見えないというものでした。

iframeウィジェットからJavaScriptウィジェットに切り替えたストア運営者は、リンクエクイティの流れを改善しました。しかし引用エコノミーに対してレビューを可視化したわけではありません。事実上、「最悪」から「中間」に移動しただけです。正しい方向性は移動を続けることです。JavaScript挿入からサーバーレンダリングHTMLへ。そこではどのクローラーでも読めるページにレビューが存在し、リンクエクイティ、引用、鮮度のすべてがストア運営者のドメインに流れてきます。

JavaScript挿入モデルは、iframeと同じ問題のより穏やかなバージョンを生み出します。レビューはストア運営者のDOMに存在しますが、写真のURL、レビュアーのプロフィールページ、レビューごとのパーマリンクは、多くの場合プラットフォームのCDNまたはプラットフォームのレビュー詳細ページを指しています。ストア運営者の商品ページ上のYotpoレビューを引用するブロガーは、そのレビューのyotpo.comパーマリンクにたどり着くことがよくあります。より良い設定においても、ストア運営者のコンテンツ資産の断片は他人のドメインの下に置かれます。対策は、ページ上のすべてのレビュー関連URLがストア運営者独自のドメインで解決されるようにすることです。ほとんどのデフォルト設定はそうなっていません。

iframeはカテゴリーエラーの最も明快な例示です。ストア運営者はその文章に対価を払い、文章を表示しながら、その文章が存在するURLを所有していません。顧客はブランドへのラブレターを書きました。ストア運営者はそれを他人のメールボックスに入れました。

3つの確認、それぞれ10分。

確認1。ブラウザで商品ページを開き、レビューセクションを右クリックして「要素を検証」を選択してください。レビューブロック内にiframeタグがないか確認してください。あった場合、レビューは別の文書に存在しています。iframeのsrc属性を確認して、どのドメインかを見てください。

確認2。Chrome DevToolsでページを開き、パフォーマンスタブでキャッシュを無効にしてフレッシュな読み込みを記録してください。Layout Shiftのエントリーを確認してください。レビューウィジェットが0.1以上のシフトをもたらしている場合、そのページはすべての読み込みでCore Web Vitalsのペナルティを払っています。2026年のコマースページのCLS問題の3分の2は、私たちのスポットチェックでは、レビューウィジェットに起因しています。

確認3。ストア運営者の最近のレビューから特定のフレーズをウェブ検索してください。検索エンジンがtrustpilot.comやreviews.ioやその他のレビュープラットフォームのドメイン上のページを返し、そこにストア運営者の商品への言及があるにもかかわらず、ストア運営者自身の商品ページが返ってこない場合、その文章のカノニカルな場所は、ストア運営者が売上を得る場所とは別にあります。そのレビューにリンクするブロガーはそのドメインにリンクします。そのリンクからやってくる購入者はそのドメインに到着します。ファネルは他人のサイトから始まります。

レビューウィジェットをインストールするストア運営者は、ほとんどの場合それを意識することなく、コンテンツ配信の決断をしています。iframeの設定は、ストア運営者が対価を払ったコンテンツを、ストア運営者が所有していないドメインに配信します。JavaScript挿入の設定は、購入者のブラウザ上ではコンテンツをストア運営者のドメインに保ちますが、クローラーのインデックスには保ちません。サーバーレンダリングHTMLの設定は、あらゆる重要なコンテキストでコンテンツをストア運営者のドメインに保ちます。

私たちは15年間、iframeとJavaScriptウィジェット上にレビュープラットフォームを構築してきました。コマースにおいて、私たちは配信の対価を払い、自分の顧客の文章のカノニカルURLが、自分が販売するページとは別の場所に存在することを受け入れてきました。これはもはや許容できるトレードではありません。リンクエクイティはストア運営者のものです。レビューはストア運営者のものです。そのページはストア運営者のものであるべきです。

the half life of a product pageで書いたように、商品ページの半減期は、ページがコンテンツを複利的に蓄積することにかかっています。レビューはストア運営者が持つ最も複利的な資産です。iframeはその資産を別のドメインに渡してしまいます。計算してみてください。その計算は単純明快です。