iFrames und SEO: was Google mit eingebetteten Inhalten macht

Ein iFrame bindet ein fremdes HTML-Dokument in eine Seite ein: eine Landkarte, ein Video, ein Bewertungswidget, ein Buchungsformular. Für Besucher wirkt das nahtlos – für Google ist es das nicht. Der Inhalt im iFrame bleibt technisch ein eigenständiges Dokument mit eigener URL, nicht automatisch ein Teil der Seite, die ihn anzeigt. Ob dieser Inhalt überhaupt gerendert und indexiert wird, wer dafür die Ranking-Signale bekommt und ob er der einbettenden Seite überhaupt etwas nützt, hängt von drei Faktoren ab: der technischen Renderfähigkeit des Frames, dem robots-Status der Quelle und – seit einigen Jahren – einer eigenen Meta-Direktive namens indexifembedded.

Die kurze Antwort vorab: Verlassen kann sich die einbettende Seite nicht darauf, dass Text, der nur im iFrame steht, ihr zugerechnet wird. Googlebot rendert den Frame zwar mit demselben Web Rendering Service, der auch den restlichen Rendervorgang der Seite übernimmt, doch ob der Inhalt der Host-Seite zugerechnet wird oder an seine Quell-URL gebunden bleibt, ist nicht garantiert. Was das für Kartenausschnitte, YouTube-Videos, Bewertungs- und Buchungswidgets konkret bedeutet, wie die indexifembedded-Direktive daran etwas ändert und wann ein natives HTML-Element die bessere Wahl ist, zeigt dieser Artikel anhand konkreter Fälle.

Wie Googlebot iFrame-Inhalte rendert – und wie du das prüfst

Googlebot crawlt und rendert Seiten mit dem Web Rendering Service, einer Chromium-basierten Engine, die JavaScript ausführt und eine Seite so aufbaut, wie sie auch ein Browser darstellen würde. Ein iFrame wird dabei wie in einem echten Browser behandelt: Der Rendering Service lädt die im src-Attribut angegebene URL, führt deren eigenes JavaScript aus und zeigt das Ergebnis innerhalb des Frames an. Das ist ein wesentlicher Unterschied zu älteren Crawler-Generationen, die iFrames häufig schlicht ignoriert haben.

Rendern ist aber nicht gleich Indexieren. Der Web Rendering Service erzeugt aus dem sichtbaren Ergebnis ein Bild der Seite, um zu entscheiden, wie die angeforderte URL zu bewerten ist – aber ein iFrame bleibt dabei ein separater Browsing-Kontext mit einem eigenen Dokument und einer eigenen URL. Google kann iFrame-Inhalte beim Rendern zwar der umschließenden Seite zurechnen, garantiert das aber nicht. Ein Absatz Fließtext, der nur innerhalb eines iFrames steht, ist deshalb eine unsichere Grundlage für die Seite, die ihn eingebunden hat.

Zur Einordnung: Das klassische HTML-Frameset – mehrere komplett getrennte Dokumente nebeneinander, ohne eine gemeinsame Haupt-URL – war für Suchmaschinen jahrzehntelang ein eigenes Problem, weil Nutzer über Suchergebnisse oft in einem einzelnen Frame ohne Navigation und ohne Kontext landeten. Ein iFrame innerhalb eines normalen, modernen Dokuments hat dieses spezifische Problem nicht: Es gibt weiterhin eine reguläre Haupt-URL mit eigener Navigation. Die Frage, wem der Inhalt inhaltlich zugerechnet wird, bleibt davon aber unberührt – sie betrifft iFrames im Kern genauso wie sie einst Framesets betroffen hat.

Ob ein iFrame beim Rendern tatsächlich geladen wurde, lässt sich direkt nachvollziehen, ohne zu raten. Die URL-Prüfung in der Search Console bietet nach einem Live-Test einen Blick auf die gerenderte Seite – einen Screenshot dessen, was der Rendering Service tatsächlich zu sehen bekommen hat – sowie den gerenderten HTML-Code. Fehlt der Inhalt des iFrames in diesem Screenshot oder erscheint dort nur eine leere Fläche, ist das ein zuverlässiges Zeichen dafür, dass die Quelle beim Rendern nicht erreichbar war.

Der Abschnitt zu den Seitenressourcen in derselben Prüfung listet zusätzlich auf, welche Ressourcen beim Laden blockiert wurden – etwa durch die robots.txt der Fremd-Domain oder durch eine fehlgeschlagene Anfrage. Wer regelmäßig Widgets von Drittanbietern einbindet, sollte diese Prüfung nach jeder relevanten Änderung wiederholen: Anbieter ändern ihre Embed-Skripte, CSP-Header oder robots.txt unabhängig von der eigenen Seite, und ein Frame, der letzten Monat noch problemlos gerendert wurde, kann es diesen Monat nicht mehr.

• Blockiert die robots.txt der Quell-Domain den Pfad des iFrames, kann der Rendering Service ihn nicht laden – die Fläche bleibt beim Rendern leer, für Host- und Quellseite gleichermaßen unsichtbar.
• Inhalte hinter Login, Captcha oder einer Nutzerinteraktion wie Klick oder Scroll-Trigger werden beim automatisierten Rendering oft nicht erreicht.
• Cross-Origin-Beschränkungen wie eine restriktive Content-Security-Policy können das Laden des Frames selbst dann verhindern, wenn die Quelle grundsätzlich crawlbar wäre.

Wem gehört der Inhalt: Host-Seite oder Quelle?

Die Einheit, die Google indexiert, ist die URL – nicht die visuelle Zusammensetzung, die ein Nutzer am Ende sieht. Wenn die im iFrame geladene URL selbst eine reguläre, crawlbare und indexierbare Seite ist, kann Google sie unabhängig von der Host-Seite in den Suchergebnissen führen, mit eigenem Titel und eigenem Snippet aus ihrem eigenen Inhalt. Die Host-Seite, die diese URL nur einbettet, erhält dafür keinen automatischen Anteil.

Das gilt genauso für strukturierte Daten. JSON-LD oder Microdata werden dem Dokument zugeordnet, in dem sie im Quellcode stehen. Steht das Markup nur im Dokument, das im iFrame lädt, bezieht es sich auf dessen URL – nicht auf die Seite, die den Frame einbindet. Eine Host-Seite kann sich also keine Rich-Result-Signale wie Sternebewertungen oder Video-Vorschaubilder von einem fremden iFrame leihen. Wer diese Signale für die eigene URL will, braucht eigenes Markup und meist auch eigenen, sichtbaren Text – nicht nur den Embed.

Die indexifembedded-Direktive: was sie löst

Viele Betreiber von einbettbaren Inhalten – interaktive Grafiken, Rechner, Diagramme, Konfiguratoren – setzen auf die eigenständige Seite, die diesen Inhalt hostet, ein noindex. Nachvollziehbar: Diese Rohseite ist meist nur ein technischer Träger ohne Navigation, ohne Kontext, oft in leicht variierter Form auf Dutzenden Partnerseiten eingebettet – als eigenständiges Suchergebnis macht sie wenig Sinn und würde eher als dünner Duplicate-Content auffallen. Das Problem: Ein klassisches noindex hat lange Zeit auch verhindert, dass Google diesen Inhalt überhaupt berücksichtigt, wenn er per iFrame anderswo eingebettet wurde.

Die Meta-Direktive indexifembedded trennt diese beiden Fälle. Im robots-Meta-Tag der Quellseite gesetzt, sagt sie Google: Diese URL soll nicht als eigenständiges Suchergebnis erscheinen, aber ihr Inhalt darf berücksichtigt werden, wenn er per iFrame in eine andere, selbst indexierbare Seite eingebettet ist. Eine Redaktion, die ein interaktives Diagramm aus einem separaten Microsite-Baustein in Dutzende Artikel einbettet, kann so verhindern, dass der nackte Grafik-Baustein selbst rankt, ohne dass die einbettenden Artikel den Inhalt der Grafik verlieren.

Wichtig ist die Reihenfolge der Wirkung: Die Direktive ändert nichts an einer Quelle, die ohnehin ganz normal indexierbar ist – dort gilt weiterhin die Trennung aus dem vorigen Abschnitt. Sie greift ausschließlich in Kombination mit noindex und öffnet dort eine gezielte Ausnahme, keine generelle Zuschreibung von Inhalten an jede beliebige Host-Seite.

Praxisfall: Google Maps und Standortdaten

Eine eingebettete Karte zeigt Adresse, Route und manchmal Öffnungszeiten – nützlich für Besucher, aber SEO-technisch fast wertlos. Die Kartenkacheln selbst sind kein Text, den Google einer Standortseite zuschreiben würde, und die begleitenden Infofenster liegen auf der Domain von Google Maps, nicht auf der eigenen. Wer für seinen Firmennamen, seine Adresse oder eine Suche nach den eigenen Öffnungszeiten gefunden werden will, braucht diese Angaben als echten, für Google lesbaren Text auf der eigenen Seite – nicht nur innerhalb des eingebetteten Kartenausschnitts.

Praktisch heißt das: Name, Adresse, Telefonnummer – das klassische NAP-Trio – gehören als sichtbarer Fließtext ins Hauptdokument, ergänzt durch LocalBusiness-Markup mit denselben Angaben. Der iFrame bleibt dann, was er sein sollte: eine Zusatzfunktion für Orientierung und Interaktion, nicht die einzige Quelle für Informationen, die eigentlich rankfähig sein sollen.

Praxisfall: Video-Embeds

Ein YouTube-Video per iFrame einzubinden ist bequem: Hosting, Transcoding und Player-Infrastruktur bleiben bei YouTube. Für die eigene Seite bedeutet das aber auch, dass das Video selbst weiterhin als Inhalt von youtube.com gilt. Ein Rich Result mit Video-Vorschaubild in den Suchergebnissen der eigenen URL entsteht nicht automatisch allein durch den Embed.

Um ein Video für die eigene Seite nutzbar zu machen, braucht es VideoObject-Markup auf der Host-Seite selbst, dessen embedUrl auf den iFrame verweist, plus einen begleitenden Text: eine Beschreibung, ein Transkript, ein paar erklärende Sätze darüber, was im Video passiert. Dieser Begleittext ist es, der der Host-Seite tatsächlich als eigener, indexierbarer Inhalt zugerechnet wird; das Video selbst bleibt visuelles Beiwerk aus fremder Quelle. Wer maximale Kontrolle über die Video-Indexierung der eigenen Domain will, hostet die Datei stattdessen selbst über ein natives Video-Element statt über ein fremdes iFrame – auf Kosten von Reichweite und Infrastrukturaufwand, die eine Plattform wie YouTube sonst übernimmt.

Praxisfall: Bewertungs- und Buchungswidgets

Bewertungswidgets, die per Skript ein iFrame von einer Bewertungsplattform nachladen, haben zwei Probleme gleichzeitig. Erstens liegt der eigentliche Bewertungstext auf der Domain des Anbieters, nicht auf der eigenen – für ein eigenes Rich Result mit Gesamtbewertung reicht der bloße Embed nicht. Zweitens sind solche Widgets oft mehrstufig verschachtelt: Ein Skript lädt ein iFrame, das iFrame lädt per weiterem Request die eigentlichen Bewertungen nach – das macht das Rendering fehleranfälliger als ein einfacher, direkter iFrame.

Wer eigene Sternebewertungen in der Suche zeigen will, sollte Bewertungs-Markup mit Inhalten verwenden, die tatsächlich als Text auf der eigenen Seite stehen – nicht nur im Widget verborgen sind. Ob sich Bewertungen einer Drittplattform überhaupt in eigenes Markup übernehmen lassen, regeln in der Regel die Nutzungsbedingungen des Anbieters, unabhängig von der SEO-Frage.

Buchungswidgets für Tischreservierung, Zimmerbuchung oder Terminvereinbarung sind ein Sonderfall: Der Buchungsvorgang selbst muss nicht indexiert werden, er ist ein Werkzeug, kein Inhalt. Problematisch wird es, wenn eine Seite außer dem Widget kaum eigenen Text bietet – Leistungsbeschreibung, Preisrahmen, Bedingungen. Eine Seite, die im Wesentlichen aus einem iFrame plus wenig Text drumherum besteht, liest sich für Google schnell dünn, unabhängig davon, wie funktional das Widget für Besucher ist. Wird dasselbe Buchungswidget mit leicht unterschiedlichen Parametern auf vielen Standort- oder Filialseiten eingebettet, lohnt sich zusätzlich ein Blick darauf, ob sich die umgebenden Host-Seiten inhaltlich stark genug unterscheiden – sonst trägt am Ende nur das Widget die Varianz, während der Rest praktisch identisch bleibt.

iFrame oder natives HTML: Entscheidungskriterien

Die Wahl zwischen iFrame und einem nativen HTML-Element ist selten eine reine Geschmacksfrage. Ein iFrame passt, wenn der Inhalt von einem Drittanbieter stammt, sich unabhängig von der eigenen Seite ändert, eine eigene Skript- oder Style-Isolation braucht oder als fertiger Embed-Code bereitgestellt wird – etwa für einen Kalender, ein Zahlungsformular oder ein Chat- und Support-Tool. Natives HTML passt, wenn der Inhalt zur eigentlichen Suchintention der Seite gehört, dauerhaft stabil bleiben soll oder als Grundlage für eigenes Schema-Markup dienen soll – also für alles, wofür die Seite eigentlich gefunden werden soll. Als Kompromiss lässt sich der Embed zeigen und daneben eine kurze textliche Zusammenfassung in echtem HTML anbieten: Nutzer mit blockierten Frames – und Crawler bei Rendering-Problemen – haben dann trotzdem Zugriff auf den Kern der Information.

Sicherheits-Isolation ist dabei kein Nebenaspekt: Ein iFrame mit dem sandbox-Attribut kann Skriptausführung, Formulareinreichung oder Popup-Fenster gezielt einschränken, ohne dass diese Einschränkungen auf das Hauptdokument übergreifen – ein Vorteil, der nichts mit Indexierung zu tun hat, aber oft der eigentliche Grund ist, warum ein Team sich für ein iFrame statt für serverseitig eingebundenen Code entscheidet.

Unabhängig von der Indexierung lohnt sich außerdem das title-Attribut am iFrame-Element: Es beschreibt für Screenreader-Nutzer, was der Frame enthält, und ist die einzige zugängliche Kurzbeschreibung, die ein iFrame von sich aus mitbringt. Ein iFrame ohne title-Attribut ist für assistive Technologien ein unbeschriftetes, undurchsichtiges Element.

Eine einfache Faustregel: Alles, wofür eine Seite in der Suche gefunden werden soll, muss außerhalb eines iFrames existieren. Ein iFrame darf ergänzen, aber nicht die einzige Quelle für den Inhalt sein, der eigentlich ranken soll.

Häufige Fehler bei iFrame-Einbettungen

Die technischen Probleme rund um iFrames wiederholen sich über Projekte hinweg. Die häufigsten:

• Die robots.txt der Quelldomain blockiert genau den Pfad, der im iFrame geladen wird – Google rendert eine leere Fläche, wo eigentlich Inhalt stehen sollte.
• Eine restriktive Content-Security-Policy auf der eigenen Seite verhindert, dass andere Seiten – auch die eigene Domain in anderem Kontext – den Inhalt überhaupt einbetten dürfen, was jede indexifembedded-Strategie von vornherein ausschließt.
• Kritischer above-the-fold-Inhalt liegt ausschließlich im iFrame: zusätzlicher Netzwerk-Request, zusätzliche Rendering-Kosten, potenzieller Layout-Shift – alles mit Wirkung auf Core Web Vitals. Für Frames unterhalb des ersten Bildschirms hilft ein Lazy-Loading-Attribut, um das Laden zu verzögern.
• Interne Links, die nur innerhalb eines iFrames existieren, werden weniger zuverlässig verfolgt als normale Links im Hauptdokument. Wichtige interne Verlinkung gehört ins Hauptdokument, nicht in einen eingebetteten Baustein.
• Schema-Markup landet im Quellcode des iFrames statt im Hauptdokument und wird dadurch nie mit der eigentlichen Host-URL verknüpft – ein häufiger Grund, warum erwartete Rich Results einfach nicht erscheinen.