Iframes geben keine Link-Gewichtung weiter. Review-Widgets sind Iframes. Mach die Rechnung auf..

Eine Bloggerin schreibt einen Beitrag über die besten Clean-Seren des Jahres 2026. Sie verlinkt auf eine Produktseite eines Händlers, mit einem Ankertext, der eine Kundenbewertung zitiert, die sie über eine Google-Suche gefunden hat. Der Link ist eine Stimme. Diese Stimme soll im Linkgraphen von Google dem Händler zugute kommen. Der Händler sollte dadurch für „Clean Serum 2026" besser ranken.

In der Konfiguration, mit der die meisten Bewertungsplattformen standardmäßig ausgeliefert werden, landet diese Stimme nicht beim Händler. Sie landet bei der Bewertungsplattform.

Dieser Essay erklärt warum, wie du das prüfst und was das für einen kleinen Shop bedeutet, der für eine Reichweite zahlt, die er nicht besitzt.

Ein Iframe ist ein HTML-Element, das ein separates Dokument in ein Fenster einer übergeordneten Seite lädt. Der Browser stellt die übergeordnete und die untergeordnete Seite als zwei eigenständige Dokumente dar, mit separaten DOM-Bäumen, separaten Ursprüngen, separatem CSS, separaten JavaScript-Runtimes und separat adressierbaren URLs.

Der Käufer im Browser sieht beide Dokumente visuell überlagert: Sterne und Bewertungen scheinen auf der Produktseite zu liegen. Der Browser weiß, dass es zwei Seiten sind. Google weiß es. Der Linkgraph behandelt sie als zwei Seiten.

Das ist das gesamte mechanische Problem.

Trustpilot ist das am stärksten verbreitete Iframe-Deployment im E-Commerce. Ein Händler, der das Trustpilot-Stars-Widget auf einer Shopify-Produktseite installiert, liefert in seinem HTML einen Iframe aus, dessen Quelle widget.trustpilot.com ist, gefolgt von einer langen Zeichenfolge aus Bezeichnern. Der Iframe wird geladen. Darin rendert Trustpilot die Sterne, die Anzahl, vielleicht eine aktuelle Bewertung.

Der Inhalt des Iframes liegt unter widget.trustpilot.com. Seine kanonische URL liegt unter widget.trustpilot.com. Seine Meta-Tags liegen unter widget.trustpilot.com. Der direkte Link zu einer bestimmten Bewertung im Trustpilot-System liegt unter trustpilot.com/review/[händler]. Keine dieser URLs gehört zur Domain des Händlers.

Stell dir vor, die Bloggerin liest eine dieser Bewertungen auf der Produktseite, klickt auf die Überschrift der Bewertung und zitiert sie in ihrem Beitrag. In vielen Fällen verlinkt sie auf die kanonische Trustpilot-URL, denn das ist die URL der Bewertung, auf die sie geklickt hat. Der Link geht an trustpilot.com. Die Link-Gewichtung geht an trustpilot.com. Die Produktseite des Händlers erhält nichts.

Stell dir vor, die Bloggerin verlinkt stattdessen auf die Produktseite des Händlers, mit der Bewertung als Ankertext. Der Link geht zur Domain des Händlers. Google ruft die Domain des Händlers ab. Google parst das HTML. Google findet den Iframe. Google behandelt den Inhalt des Iframes im Standardfall nicht als Teil der Seite des Händlers: Der Iframe ist ein separates Dokument, das, wenn überhaupt, unter widget.trustpilot.com indexiert ist. Der Ankertext, den die Bloggerin verwendet hat, das Zitat der Bewertung, ist damit semantisch eine Beschreibung von Inhalten, die unter einer anderen Herkunft liegen. Das Relevanzsignal ist unvollständig. Die Seite erhält einen Teil des Nutzens, aber nicht den Nutzen, den derselbe Text als Absatz im eigenen HTML der Seite erbracht hätte.

Das ist der grundlegende mechanische Verlust. Die Bewertungen sind Inhalte, für die der Händler bezahlt hat, die seine Kunden geschrieben haben, und die auf eine Domain verweisen, die dem Händler nicht gehört.

Einige Bewertungsplattformen (Yotpo in der Standardinstallation, Okendo, Junip, Stamped) verwenden keine Iframes. Sie injizieren Bewertungen per JavaScript in ein Div auf der eigenen Seite des Händlers. Das ist mechanisch besser. Die Bewertungen liegen, wenn sie gerendert werden, im DOM des Händlers. Die URL, auf der der Käufer sich befindet, ist die URL des Händlers. Die Canonical ist die Canonical des Händlers. Die Link-Gewichtung fließt korrekt.

Der Haken, wie wir in the end of the review widget erläutert haben, besteht darin, dass die Bewertungen nur existieren, wenn das JavaScript ausgeführt wird. Für den Googlebot wird das JavaScript irgendwann ausgeführt, mit der Aktualitätsverzögerung, über die wir geschrieben haben. Für GPTBot, ClaudeBot und PerplexityBot wird das JavaScript überhaupt nicht ausgeführt. Die Bewertungen sind auf der Seite, die der Crawler sieht, nicht vorhanden.

Es gibt also drei Konfigurationen.

Die Iframe-Konfiguration: Bewertungen liegen auf einer anderen Domain, Link-Gewichtung fließt nicht zum Händler, kein Crawler sieht die Bewertungen des Händlers, weil auf der Seite des Händlers keine Bewertungen vorhanden sind.

Die JavaScript-Injection-Konfiguration: Bewertungen liegen beim Rendern auf der Domain des Händlers, Link-Gewichtung fließt korrekt, aber die Bewertungen sind für KI-Crawler unsichtbar und für den Googlebot nur teilweise sichtbar.

Die serverseitig gerenderte Konfiguration: Bewertungen befinden sich im HTML des Händlers, Link-Gewichtung fließt, alle Crawler sehen die Bewertungen. Das ist die Konfiguration, die fast kein Bewertungs-Widget standardmäßig liefert.

Die Rechnung ist einfach. Iframe ist am schlechtesten. JavaScript-Injection liegt in der Mitte. Serverseitig gerendertes HTML ist am besten. Die meisten Shops laufen 2026 mit einer der beiden schlechteren Optionen.

Es gibt eine zweite Dimension, mechanisch getrennt von der Link-Gewichtungs-Frage, aber auf denselben Vorfall geschichtet. Die Core Web Vitals sind seit 2021 ein Google-Rankingfaktor, der 2024 mit der Einführung von Interaction to Next Paint aktualisiert wurde. Eines der drei Signale ist der Cumulative Layout Shift, der misst, wie stark sich der Inhalt einer Seite beim Laden verschiebt. Google benachteiligt Seiten mit einem CLS-Wert über 0,1.

Ein in einem Iframe geladenes Bewertungs-Widget wird in vielen Implementierungen zur Laufzeit von dem Skript skaliert, das es erzeugt. Die Seite rendert zunächst ohne das Widget. Das Skript lädt. Der Iframe wird eingebettet. Der Inhalt der Seite verschiebt sich um 200 bis 400 Pixel nach unten, während das Widget seinen Platz unter dem Kaufen-Button beansprucht. Der CLS-Wert erhöht sich für diesen Seitenaufruf um einen Betrag, der davon abhängt, wie viel des Viewports der verschobene Inhalt einnimmt. Wir haben in eigenen Feldmessungen Anfang 2026 Verschiebungen zwischen 0,18 und 0,34 durch iframe-basierte Bewertungs-Widgets auf ansonsten gut optimierten Shopify-Themes beobachtet.

Eine Seite mit einem CLS-Wert von 0,25 rankt nicht so gut wie eine Seite mit einem CLS-Wert von 0,05, wenn sonst alles gleich ist. Der Händler zahlt im Ranking dafür, einen Inhaltsblock zu hosten, der nicht zu seiner Domain gehört. Wir haben die Messmethodik und die Aufschlüsselung nach Widget in einem separaten Beitrag behandelt. Der strukturelle Punkt hier: Der Iframe verliert auf zwei Achsen gleichzeitig, der Link-Gewichtungs-Achse und der CWV-Achse, beide davon sind die Achsen des Algorithmus. Der Händler kann keine davon beheben, indem er den Bewertungsplattform-Anbieter wechselt. Der Iframe ist die Form, und die Form ist der Verlust.

Ein Verteidiger des Iframe-Modells wird sagen: Die Bewertungen liegen bei Trustpilot, weil es Trustpilot-Bewertungen sind. Der Rezensent hat sich bei Trustpilot registriert, dort geschrieben, und Trustpilot ist der kanonische Ort für diesen Inhalt. Der Iframe ist nur eine Anzeige als Gefälligkeit.

Das stimmt, und es ist irrelevant. Der Händler, der das Trustpilot-Widget installiert, trifft eine Entscheidung über die Inhaltsverteilung: Er entscheidet, Trustpilots Inhalte auf seiner eigenen Produktseite anzuzeigen. Die Kosten dieser Entscheidung sind der Inhalt dieses Essays. Das Schreiben des Rezensenten ist aus der Sicht des Käufers ein Inhalt auf der Seite des Händlers; der Käufer sieht keinen Unterschied zwischen einem Iframe und einem eingebetteten Block. Der Crawler sieht ihn. Der Linkgraph sieht ihn. Die CWV-Messung sieht ihn.

Das Schreiben des Rezensenten ist auch, in wirtschaftlicher Hinsicht, ein Inhalts-Asset. Der Händler hat für die Kundenbeziehung bezahlt, die es hervorgebracht hat. Er hat für den Post-Purchase-Prozess bezahlt, der es ausgelöst hat. Er zahlt für die Plattform, die es hostet. Er besitzt nicht die kanonische URL, unter der das Schreiben liegt, und erfasst daher nicht den langfristigen Nutzen der Auffindbarkeit dieses Schreibens.

Darum ging es in the category error auf einer tieferen Ebene. Der Kategorienfehler bestand darin, die Bewertung als UI-Funktion zu behandeln, nicht als Inhalts-Asset. Die Iframe-Konfiguration ist die extremste Version dieses Fehlers: Der Händler hat für den Inhalt bezahlt, den Inhalt angezeigt und besitzt nicht die URL, unter der der Inhalt liegt.

Eine zweite Reaktion: Der Iframe ist die schlechte Variante. Das JavaScript-Widget ist die gute. Wähle eine Plattform, die JavaScript-Injection statt Iframes verwendet, und das Problem ist gelöst.

Das ist eine Teillösung. Das JavaScript-Widget liegt im DOM des Händlers, was die Link-Gewichtungs-Frage behebt. Es liegt nicht im initialen HTML, was die KI-Crawler-Frage offen lässt und die Googlebot-Aktualitätsfrage halb schließt. Wir haben das curl-gegen-drei-Crawler-Experiment anderswo erläutert; das Ergebnis ist, dass das JavaScript-Widget für GPTBot, ClaudeBot und PerplexityBot unsichtbar ist und für den Googlebot nur teilweise sichtbar.

Der Händler, der von einem Iframe-Widget auf ein JavaScript-Widget wechselt, hat den Link-Gewichtungs-Fluss verbessert. Er hat die Bewertungen nicht für die Zitationswirtschaft sichtbar gemacht. Er hat sich, im Wesentlichen, von „am schlechtesten" auf „in der Mitte" bewegt. Der richtige Schritt ist weiterzumachen: von der JavaScript-Injection zum serverseitig gerenderten HTML, wo die Bewertungen auf der Seite liegen, die jeder Crawler lesen kann, und wo Link-Gewichtung, Zitation und Aktualität alle gemeinsam zur Domain des Händlers zurückfließen.

Das JavaScript-Injection-Modell erzeugt eine weichere Version desselben Iframe-Problems: Die Bewertungen liegen im DOM des Händlers, aber die Foto-URLs, die Rezensenten-Profilseiten und die Permalinks zu einzelnen Bewertungen verweisen häufig zurück auf das CDN der Plattform oder die Bewertungsdetailseiten der Plattform. Die Bloggerin, die eine Yotpo-Bewertung auf der Produktseite eines Händlers zitiert, landet beim Kopieren der Bewertung oft auf einem yotpo.com-Permalink für genau diese Bewertung. Auch in der besseren Konfiguration werden Splitter des Inhalts-Assets des Händlers unter der Domain von jemand anderem abgelegt. Der Ausweg besteht darin, sicherzustellen, dass jede bewertungsbezogene URL auf der Seite auf die eigene Domain des Händlers auflöst. Die meisten Standardeinstellungen tun das nicht.

Der Iframe ist die klarste Illustration des Kategorienfehlers. Der Händler bezahlt für das Schreiben, zeigt das Schreiben an und besitzt nicht die URL, unter der das Schreiben liegt. Der Kunde hat einen Liebesbrief an die Marke geschrieben. Der Händler hat ihn in den Briefkasten von jemand anderem gelegt.

Drei Prüfungen, je zehn Minuten.

Prüfung eins. Öffne die Produktseite im Browser, klicke mit der rechten Maustaste auf den Bewertungsbereich und wähle „Element untersuchen". Suche nach einem Iframe-Tag innerhalb des Bewertungsblocks. Wenn es einen gibt, liegen die Bewertungen in einem anderen Dokument; prüfe das src-Attribut des Iframes, um zu sehen, wessen Domain es ist.

Prüfung zwei. Öffne die Seite in den Chrome DevTools, Tab „Performance", zeichne einen frischen Ladevorgang mit deaktiviertem Cache auf. Schau dir die Layout-Shift-Einträge an. Wenn das Bewertungs-Widget eine Verschiebung von 0,1 oder mehr verursacht, zahlt die Seite bei jedem Ladevorgang eine CWV-Einbuße. Zwei Drittel der CLS-Probleme auf E-Commerce-Seiten im Jahr 2026 gehen laut unseren Stichproben auf Bewertungs-Widgets zurück.

Prüfung drei. Suche im Web nach einem bestimmten Satz aus einer der neuesten Bewertungen des Händlers. Wenn die Suchmaschine eine Seite bei trustpilot.com, reviews.io oder einer anderen Bewertungsplattform-Domain zurückgibt, auf der das Produkt des Händlers erwähnt wird, anstatt der eigenen Produktseite des Händlers, ist der kanonische Ort für dieses Schreiben woanders als dort, wo der Händler den Umsatz erzielt. Die Bloggerin, die diese Bewertung verlinkt, wird auf diese Domain verlinken. Der Käufer, der über diesen Link kommt, kommt auf dieser Domain an. Der Funnel beginnt auf dem Grundstück von jemand anderem.

Der Händler, der ein Bewertungs-Widget installiert, trifft, meist ohne es zu wissen, eine Entscheidung über die Inhaltsverteilung. Die Iframe-Konfiguration verteilt Inhalte, für die der Händler bezahlt hat, an eine Domain, die dem Händler nicht gehört. Die JavaScript-Injection-Konfiguration hält die Inhalte im Browser des Käufers auf der Domain des Händlers, aber nicht im Index des Crawlers. Die serverseitig gerenderte HTML-Konfiguration hält die Inhalte in jedem relevanten Kontext auf der Domain des Händlers.

Wir haben fünfzehn Jahre damit verbracht, Bewertungsplattformen auf dem Iframe und dem JavaScript-Widget aufzubauen. Im E-Commerce haben wir für Reichweite bezahlt und akzeptiert, dass die kanonische URL des Schreibens unserer eigenen Kunden woanders liegt als auf der Seite, von der aus wir verkaufen. Das ist kein akzeptabler Kompromiss mehr. Die Link-Gewichtung gehört dem Händler. Die Bewertungen gehören dem Händler. Die Seite sollte dem Händler gehören.

Die Halbwertszeit einer Produktseite, wie wir in the half life of a product page geschrieben haben, hängt davon ab, dass die Seite Inhalte ansammelt, die sich aufbauen. Bewertungen sind das am stärksten kumulative Asset, das ein Händler hat. Der Iframe gibt dieses Asset an eine andere Domain. Mach die Rechnung auf. Die Rechnung ist nicht subtil.