// stack · schnittstelle
Ein Video auf der Website — und im selben Moment Fremdcode im Dokument. Genau da setzt die Umsetzung an: siteway stellt an die Stelle des Players zuerst ein Vorschaubild von der eigenen Domain mit einem beschrifteten Play-Schalter. Der Player wird erst nach Klick und Einwilligung nachgeladen. Diese Seite beschreibt die Technik dahinter — den eingebetteten Player, die YouTube Data API für Kanal- und Videolisten und den Weg in TYPO3, WordPress und Statamic.
// definition
Hinter dem einen Begriff stecken zwei völlig verschiedene Dinge — und sie
gehen im Projektgespräch regelmäßig durcheinander. Das eine ist ein
einzelnes eingebettetes Video: ein Player im
<iframe>, der genau einen Clip ausspielt,
adressiert über die Video-ID. Das andere ist die YouTube Data API: eine
Schnittstelle, über die sich Daten abfragen lassen, ohne dass ein Player im Dokument steht.
Die Data API in Version 3 führt laut Dokumentation unter anderem channels, playlists, playlistItems, videos, search und captions als eigene Ressourcen. Damit lassen sich Titel, Beschreibung, Veröffentlichungsdatum und die Adressen der Vorschaubilder holen — der Stoff, aus dem eine Kanalübersicht oder eine Videoliste auf der eigenen Seite besteht. Jede Anfrage braucht dafür einen API-Schlüssel oder ein OAuth-2.0-Token.
Die Steuerung des Players wiederum läuft über die
IFrame Player API — dasselbe
<iframe>, aber per JavaScript
ansprechbar. Diese Trennung ist der Grund, warum eine Videoseite mehr ist als ein kopierter
Einbettungscode: Die Liste kommt vom Server, der Player kommt auf Zuruf. Wie so ein Bereich als
Baustein aussieht, beschreibt die Komponente
Portfolio- & Media-Galerie.
Hier geht es um die Schnittstelle darunter.
// praxis
player auf zuruf
Die erste Entscheidung fällt vor dem Video: Die Seite lädt keinen Player, solange niemand ihn angefordert hat. An der Stelle, an der später das Video läuft, steht ein Standbild mit einem beschrifteten Play-Schalter darüber. Wird er betätigt und liegt die Einwilligung vor, kommt der Player nach und erscheint im selben Container — gleiches Seitenverhältnis, gleiche Position, nichts verspringt.
Das Vorschaubild ist dabei kein Notbehelf, sondern ein normales Bild unserer Website. Es liegt auf der eigenen Domain, wird als AVIF und WebP in mehreren Größen ausgeliefert und bekommt einen echten Alt-Text. Der Server holt das Standbild einmalig über die Data API und legt es in der Dateiverwaltung des CMS ab. Danach ist es Teil des normalen Bildwegs — und kein Aufruf verlässt beim Seitenaufbau die eigene Domain.
Für Kanal- und Videolisten gilt derselbe Weg wie bei den sozialen Netzen: Der Server fragt die Data API in ruhigem Takt ab, speichert Titel, Beschreibung, Veröffentlichungsdatum und Bildadressen im CMS zwischen und die Website rendert daraus ihr eigenes Markup. Kein Besucher spricht direkt mit einer fremden Schnittstelle, der Schlüssel bleibt auf dem Server, und die Liste steht auch dann auf der Seite, wenn die Schnittstelle gerade zickt. Denselben Aufbau beschreiben wir für Social-Feeds unter Meta.
Die Video-ID ist ein Redaktionsfeld, kein Codeschnipsel. Wer ein Video einsetzt, trägt die ID ein und lädt bei Bedarf ein eigenes Standbild dazu — kein eingefügter Einbettungscode im Fließtext, keine Fremdmarkierung, die sich später nicht mehr anfassen lässt. Damit bleibt die Darstellung im Griff der Website und nicht im Griff eines kopierten HTML-Blocks.
Und schließlich das, was oft fehlt: der Text zum Video. Untertitel gehören zum Video, ein Transkript gehört auf die Seite — als echter Text, lesbar für Menschen, für Suchmaschinen und für alle, die den Ton nicht hören können oder wollen. Mehr dazu unter Barrierefreiheit im Stack.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Entwicklerdokumentation und der Hilfe von YouTube — Ressourcennamen, Parameter und Funktionsumfang im Original. Kontingente und Konditionen ändern sich und stehen deshalb nicht auf dieser Seite; sie gehören in die Planung eines konkreten Projekts, nicht in eine Technikbeschreibung.
// d-01player
Ein Video wird über seine ID adressiert und in einem <iframe> ausgespielt. Der Player bringt seine eigene Oberfläche mit — Bedienleiste, Qualitätswahl, Vollbild, Untertitel. Für uns ist er der Baustein, der nach dem Klick kommt, nicht der, mit dem die Seite startet.
zweck: wiedergabe
// d-02steuerung
Laut Dokumentation wird die API asynchron über ein Skript geladen und meldet sich über onYouTubeIframeAPIReady(). Danach lassen sich Wiedergabe, Lautstärke und Zustand per JavaScript steuern. Vorausgesetzt wird enablejsapi; für ein selbst erzeugtes iframe empfiehlt die Doku zusätzlich den Parameter origin.
zweck: start nach klick
// d-03daten
Die Datenschnittstelle neben dem Player. Die Referenz führt unter anderem channels, playlists, playlistItems, videos und search als Ressourcen. Jede Anfrage braucht laut Doku einen API-Schlüssel oder ein OAuth-2.0-Token — bei uns liegt beides auf dem Server.
zweck: listen & metadaten
// d-04standbild
Die Data API liefert zu jedem Video die Adressen der Vorschaubilder mit. Der Server lädt das Standbild einmalig herunter, legt es im CMS ab und erzeugt daraus AVIF- und WebP-Varianten. Ausgeliefert wird es von der eigenen Domain, mit festen Maßen im Markup.
zweck: platzhalter
// d-05modus
YouTube beschreibt in seiner Hilfe einen Modus für eingebettete Player: Die Domain in der Einbettungs-URL wird von youtube.com auf youtube-nocookie.com geändert. Aufrufe des Videos personalisieren dann laut dieser Beschreibung weder YouTube-Nutzung noch Werbung des Zuschauers. Ein Fremdaufruf bleibt es.
zweck: ergänzung, kein ersatz
// d-06untertitel
Untertitelspuren sind in der Data API eine eigene Ressource — sie lassen sich laut Referenz hochladen, herunterladen, ändern und löschen. Das heißt: Untertitel sind pflegbarer Inhalt und keine Nebensache der automatischen Erkennung. Auf der Seite kommt das Transkript als Text dazu.
zweck: verständlichkeit
Aus diesen Bausteinen wird kein eingefügtes Fenster, sondern ein Bereich der Website. Ein einzelnes Video steht als Standbild im Text, mit Titel, Dauer und einem Schalter, der aussieht wie ein Bedienelement und auch eins ist. Eine Videoliste zeigt die Beiträge eines Kanals oder einer Playlist als Karten mit Standbild, Titel und Datum — im eigenen Raster, in der eigenen Typografie, filterbar und sortierbar, weil die Daten im CMS liegen.
Dazu kommt das, was Maschinen lesen. Für ein Video kann strukturierte Daten vom Typ VideoObject sinnvoll sein — Titel, Beschreibung, Standbild, Veröffentlichungsdatum und Dauer maschinenlesbar an derselben Stelle, an der auch der Besucher sie sieht. Ob das Markup zu einer Seite passt, entscheidet sich am Inhalt: Es beschreibt ein Video, das auf dieser Seite tatsächlich das Thema ist, nicht jeden beiläufigen Clip.
Und der Container, in dem all das steckt, hat von Anfang an ein festes Seitenverhältnis. Das Standbild belegt es, der Player übernimmt es — kein Nachrutschen des Textes darunter, kein Layout-Sprung. Warum das mehr als Kosmetik ist, steht unter Performance im Stack.
// integration
drei systeme · ein muster
Der Ausgangspunkt ist in jedem System derselbe: Ein YouTube-Player lädt Fremdcode und überträgt Besucherdaten, sobald die Seite geladen wird. Deshalb steht an seiner Stelle zunächst ein Vorschaubild mit Play-Schalter. Das Standbild liegt auf der eigenen Domain und wird in modernen Formaten ausgeliefert — als AVIF mit WebP als zweiter Variante, in passenden Größen, mit festen Maßen im Markup. Der Player wird erst nach Klick und Einwilligung nachgeladen und erscheint im selben Container. Der Zustand der Einwilligung wird an einer Stelle verwaltet, nicht in jedem Template neu entschieden; das Video-Template fragt ihn nur ab.
Dieser Weg ist gleichzeitig gut für die Ladezeit: Solange niemand auf Play drückt, überträgt die Seite kein Player-Skript, keine fremden Schriften und keine Videodaten — auf einer Seite mit mehreren Videos summiert sich das schnell. Was übrig bleibt, ist ein Bild, das im Bildverarbeitungsweg der Website liegt und dort so behandelt wird wie jedes andere. Warum das direkt auf die Core Web Vitals wirkt, steht unter Performance. Unterschiedlich sind zwischen den Systemen nur die Bordmittel, mit denen wir das bauen.
// cms-01typo3
Wir bauen die Einbindung als eigene Extension mit einem eigenen Content-Element. Das Element hat ein Feld für die Video-ID, ein Feld für den Titel und ein Bildfeld für das Vorschaubild — abgelegt in der Dateiverwaltung, damit es durch die normale Bildverarbeitung läuft und als AVIF oder WebP herauskommt. Für Kanal- und Videolisten holt ein Scheduler-Task die Daten über die Data API und schreibt sie in Records; der Schlüssel steht in der Extension-Konfiguration statt im Template. Im Frontend rendert ein Fluid-Template zuerst den Consent-Platzhalter mit Standbild und Schalter; erst danach kommt der Player.
// cms-02wordpress
In WordPress entsteht die Einbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie den Theme-Wechsel. Für den Editor kommt ein eigener Block mit einem Feld für die Video-ID dazu; das Vorschaubild liegt in der Mediathek und bekommt dort seine Größen und modernen Formate. Für Listen holt ein geplanter Lauf die Kanaldaten über die Data API und legt sie als Beiträge oder als zwischengespeicherten Datensatz ab. Der Schlüssel steht in der wp-config.php oder in einer Umgebungsvariablen. Das Template gibt den Platzhalter aus und lädt den Player erst auf Anforderung nach.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil angenehm gerade. Ein Blueprint bekommt ein Feld für die Video-ID und ein Assets-Feld für das Vorschaubild; das Bild liegt im Assets-Container und wird von dort in modernen Formaten ausgespielt. Für Listen schreiben wir einen Artisan-Command, den der Laravel-Scheduler regelmäßig aufruft: Er fragt die Data API ab und legt Titel, Datum und Bildadressen als Entries oder im Cache ab. Der Schlüssel steht in der .env. Antlers oder Blade rendern zuerst den Platzhalter, danach den Player — und weil Static Caching die Seiten ausliefert, kostet der Platzhalter beim Aufruf praktisch nichts.
// datenschutz
technik, nicht rechtsberatung
Der technische Sachverhalt ist schnell beschrieben: Ein eingebetteter YouTube-Player holt Code, Schriften, Bilder und Videodaten von Servern von Google. Damit diese Auslieferung überhaupt funktionieren kann, geht die IP-Adresse des Besuchers an den Server, der die Daten schickt — das ist keine Eigenheit dieser Plattform, sondern gilt für jede Ressource, die von fremder Stelle geladen wird. Der Unterschied liegt darin, ob das ungefragt beim Seitenaufruf passiert oder erst, wenn jemand das Video tatsächlich sehen will.
Bei einer Website, die wir trackingfrei bauen, wäre ein automatisch mitladender Player der einzige Fremdaufruf im Dokument — und damit die Ausnahme von der eigenen Regel. Deshalb ist das Vorschaubild mit Play-Schalter bei siteway der Standardweg: Der erste Klick fordert den Player an, der zweite startet das Video. Bis dahin steht an der Stelle das Standbild vom eigenen Server, dazu Titel und Dauer als Text. Wer nur wissen will, worum es geht, hat es damit vor dem ersten Klick.
Für Kanal- und Videolisten gilt dasselbe auf der Datenseite: Die Abfrage läuft auf dem Server, nicht im Browser des Besuchers. Der Schlüssel bleibt serverseitig, die Ergebnisse werden im CMS zwischengespeichert und die Website rendert daraus eigenes Markup. So entsteht keine Verbindung zwischen Besucher und fremder Schnittstelle, nur weil eine Liste auf der Seite steht. Dazu gehört, dass die Entscheidung nachvollziehbar bleibt: Der Schalter ist beschriftet, nicht als Bildfläche getarnt, und die Einwilligung lässt sich zurücknehmen — dann steht beim nächsten Aufruf wieder das Standbild.
Wir beschreiben hier die Technik und ihre Umsetzung — die rechtliche Bewertung des Einzelfalls gehört in die Hand von Juristinnen und Juristen. Was wir liefern, ist die Grundlage dafür: eine Umsetzung, die zeigt, wann welche Daten fließen, und eine Dokumentation, die das festhält. Wie das im Zusammenhang der ganzen Website aussieht, steht unter Sicherheit & Datenschutz; wer den Bestand einer vorhandenen Seite geprüft haben will, findet das im Datenschutz-Audit.
// faq
Indem der Player nicht mit der Seite mitlädt. Ein eingebetteter YouTube-Player holt Code, Bilder und Videodaten von Servern von Google; damit die Auslieferung überhaupt funktionieren kann, wird dabei die IP-Adresse des Besuchers übertragen. Der Weg ist deshalb ein Vorschaubild mit Play-Schalter: Das Standbild liegt auf der eigenen Domain und wird als AVIF oder WebP ausgeliefert, darüber liegt ein beschrifteter Schalter. Erst wenn jemand ihn betätigt und der Einwilligung zustimmt, wird der Player nachgeladen und erscheint an derselben Stelle im selben Container. Bis dahin verlässt kein Aufruf die eigene Domain. Wie die Datenverarbeitung im konkreten Fall zu bewerten und in der Datenschutzerklärung zu beschreiben ist, gehört in die Hand der Rechtsberatung — wir liefern die technische Umsetzung und die Dokumentation dazu.
Die YouTube Data API in Version 3 ist die Schnittstelle, über die sich Daten von YouTube abfragen und verwalten lassen — getrennt vom Player. Die Dokumentation führt unter anderem Kanäle, Playlists, Playlist-Einträge, Videos, Suchergebnisse und Untertitelspuren als eigene Ressourcen. Für eine Website heißt das praktisch: Titel, Beschreibung, Dauer, Veröffentlichungsdatum und die Adressen der Vorschaubilder lassen sich holen, ohne dass ein Player im Dokument steht. Jede Anfrage braucht laut Dokumentation entweder einen API-Schlüssel oder ein OAuth-2.0-Token — beides gehört auf den Server und nicht in den Quelltext der Seite.
Aus zwei Gründen, die in dieselbe Richtung zeigen. Erstens: Ein Vorschaubild, das direkt von einem fremden Server geladen wird, ist selbst schon ein Fremdaufruf — die Einwilligung wäre damit umgangen, bevor jemand den Play-Schalter überhaupt gesehen hat. Zweitens: Auf dem eigenen Server lässt sich das Bild so ausliefern, wie wir jedes andere Bild ausliefern — in modernen Formaten, in passenden Größen, mit festen Maßen im Markup. Der Server holt das Standbild einmalig über die Data API, legt es in der Dateiverwaltung des CMS ab und erzeugt daraus die Varianten. Danach kostet das Vorschaubild einen Bruchteil dessen, was der Player gekostet hätte.
Ein Player ist einer der schwersten Bausteine, die eine Seite haben kann: Skript, Stylesheets, Schriften, Bilder und die Videodaten selbst kommen zusammen, und mehrere Videos auf einer Seite vervielfachen das. Genau deshalb passt die Vorschaubild-Lösung so gut zur Technik — solange niemand auf Play drückt, wird nichts davon geladen. Das Standbild ist ein Bild mit festen Maßen und kostet fast nichts. Wird der Player angefordert, geschieht das nach dem ersten Seitenaufbau und in einem Container, dessen Seitenverhältnis vorher feststeht, damit nichts nachträglich verspringt. Das wirkt an drei Stellen gleichzeitig: weniger übertragene Daten, weniger Arbeit im Hauptthread, kein Layout-Sprung.
YouTube beschreibt in seiner Hilfe einen erweiterten Datenschutzmodus für eingebettete Player: Man ändert dafür die Domain in der Einbettungs-URL von youtube.com auf youtube-nocookie.com. Laut dieser Beschreibung sorgt der Modus dafür, dass Aufrufe des eingebetteten Videos die YouTube-Nutzung und die ausgespielte Werbung des Zuschauers nicht personalisieren; nicht personalisierte Werbung kann weiterhin erscheinen. Was der Modus nicht ändert: Es bleibt ein Aufruf an einen fremden Server, sobald der Player im Dokument steht. Er ersetzt die Einwilligung also nicht, sondern ergänzt sie — der Player wird bei uns trotzdem erst nach dem Klick geladen.
Das ist eine Zuordnung nach Anwendungsfall, keine Rangliste. Kurze Hintergrundschleifen, Teaser, Produktdemos und UI-Aufnahmen liegen besser selbst gehostet: als WebM mit MP4 als zweiter Quelle im video-Element, ohne Fremdaufruf, ohne Player-Oberfläche, vollständig im eigenen Design. Sobald Videos länger werden, in vielen Auflösungen ausgespielt werden sollen oder ohnehin ein Kanal mit Reichweite existiert, spielt YouTube seine Stärken aus: adaptives Streaming über ein weltweites Netz, automatische Varianten, Auffindbarkeit auf der Plattform selbst. Häufig läuft beides parallel auf derselben Website — kurze Clips selbst, lange Formate über den Kanal.
Über drei Dinge, die zum Video gehören und nicht nachträglich drangehängt werden. Erstens Untertitel: YouTube führt Untertitelspuren als eigene Ressource in der Data API, sie lassen sich also gepflegt hochladen statt der automatischen Erkennung überlassen zu werden. Zweitens ein Transkript als echter Text auf der Seite — es hilft allen, die nicht hören können oder nicht hören wollen, es lässt sich durchsuchen und es ist für Suchmaschinen lesbar. Drittens der Play-Schalter selbst: ein echtes Bedienelement mit sprechender Beschriftung, per Tastatur erreichbar, nicht eine Bildfläche mit einem aufgemalten Dreieck. Und ein Video startet nicht von allein mit Ton.
Ja, in allen drei Systemen — und wir bauen die Einbindung jeweils selbst, mit den Bordmitteln des Systems. In TYPO3 entsteht eine eigene Extension mit einem Content-Element, das ein Feld für die Video-ID hat; das Vorschaubild liegt in der Dateiverwaltung, ein Fluid-Template gibt zuerst den Consent-Platzhalter aus. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Block mit Feld für die Video-ID, das Vorschaubild in der Mediathek, ein Template-Teil mit Platzhalter. In Statamic liegt Laravel darunter: ein Blueprint-Feld für die Video-ID, das Vorschaubild im Assets-Container, gerendert über Antlers oder Blade. Die Mechanik ist überall dieselbe, nur die Bordmittel heißen anders.
// womit das zusammenhängt
baustein, technik & grundlagen
// komponente · buchen
Die Technik hier, der Baustein dort: Galerie, Lightbox, Filter und Videos als buchbare Komponente, gepflegt im CMS.
zur komponente →
// stack · media
Der Weg für selbst gehostete Videos: kurze Schleifen und Teaser direkt im video-Element, ohne Fremdaufruf.
zur technik →
// stack · grundlage
Wo Fremdcode ins Spiel kommt, wird es konkret: Einwilligung, Schlüssel serverseitig, Datensparsamkeit, Dokumentation.
zur technik →
// stack · a11y
Untertitel, Transkript und ein Play-Schalter, der per Tastatur erreichbar ist — was Bewegtbild für alle bedeutet.
zur technik →
// stack · messwerte
Player sind schwer. Verzögertes Laden, feste Seitenverhältnisse und weniger Fremdcode wirken direkt auf die Core Web Vitals.
zur technik →
// leistung · buchen
Analyse, Mapping, Umsetzung, Monitoring und Betrieb einer Anbindung — als buchbare Leistung beschrieben.
zur leistung →
// Videos auf der Website, die erst nach Einwilligung laden?
Projekt anfragen