Alle Artikel · 10. Juli 2026 · Shopware 6 · Strategie

Headless Commerce oder iFrame. Was sich für kleine Shopware-Projekte lohnt

Ein eigenes Frontend auf der Store API klingt nach Kontrolle. In den Projekten, die ich kenne, lag der Aufwand dafür im fünfstelligen Bereich und die erste Kampagnen-Landingpage kam trotzdem zu spät. Für viele Shops reicht es, eine Shopware-Seite in WordPress oder Wix einzubetten.

Zwei Wege, Content und Checkout zu verbinden

Der Blog läuft oft auf WordPress, der Verkauf in Shopware 6. Der Default ist ein Link. Der Leser wechselt Domain und Layout. Zwei tragfähige Alternativen bleiben:

Headless. Shopware bleibt Backend. Ein eigenes Frontend spricht die Store API an.
iFrame. Die bestehende Storefront bleibt. Ein HTML-Snippet bettet Produkt, Kategorie oder Erlebniswelt ins CMS ein.

Was Headless in Shopware 6 konkret bedeutet

Produkte, Bestellungen und Lager bleiben in Shopware. Das sichtbare Frontend bauen Sie getrennt, häufig mit Next.js oder Nuxt. Session, Caching und Server-Side Rendering liegen dann bei Ihnen. Shopware-Updates am Theme stören dieses Frontend nicht. Dafür müssen Sie API-Änderungen selbst nachziehen.

Das lohnt sich, wenn dieselbe API Web und App speisen soll und ein Entwicklerteam dauerhaft da ist. Ohne dieses Team wird das Frontend zur Baustelle, sobald Shopware Felder oder Cart-Endpunkte ändert.

Was die iFrame-Einbettung macht

Die Storefront bleibt die Storefront. Das Plugin erzeugt ein Snippet. Sie fügen es im CMS als HTML-Block ein. Preise und Bestand kommen live aus Shopware, der Checkout bleibt dort. Zahlungsanbieter und DSGVO-Texte pflegen Sie einmal.

Die Grenzen sind klar. Das eingebettete Stück sieht aus wie Ihr Shop, nicht wie ein frei designedes CMS-Modul. Die Höhe müssen Sie setzen. In der Praxis hat 600 px oft nicht gereicht, weil der Warenkorb-Button unterhalb des Rahmens lag. Und die Einbettung scheitert, wenn der Shop X-Frame-Options: SAMEORIGIN sendet. Genau das war der erste Fehlerfall: Staging mit Default-Headern, Live erst nach der Plugin-Einstellung.

Kosten, Zeit und Wartung

Headless heißt Projekt, Caching-Konzept und laufende API-Pflege. iFrame heißt Plugin, Snippet und ein Test auf Mobilgeräten. In Agenturprojekten war der iFrame-Weg in ein bis drei Tagen live. Ein Store-API-Frontend habe ich so schnell nicht gesehen.

SEO bleibt getrennt: Der Blog rankt auf seiner Domain, der Canonical der Produktdaten liegt weiter auf dem Shop. Duplicate Content entsteht dadurch nicht, solange Sie die Produktseite nicht zusätzlich als HTML in WordPress nachbauen.

Wann Headless sinnvoll ist

Eigenes Team für Frontend und API
App und Web sollen dieselbe Store API nutzen
Die Storefront soll komplett vom Theme entkoppelt sein

Wann der iFrame reicht

WordPress- oder Wix-Blog plus bestehender Shopware-Shop
Kampagnen-Landingpage mit einem Produkt- oder Kategorieausschnitt
Kein festes Entwicklerteam
Test, ob Contextual Commerce überhaupt Bestellungen bringt, bevor Sie ein Frontend beauftragen

Für diese Fälle liegt die Umsetzung in der Administration, nicht im Theme. Die Dokumentation steht auf der Plugin-Seite zur iFrame-Einbettung.

Erst einbetten, Headless später prüfen

Blog und Kampagnen können Sie per iFrame anbinden. Shopware bleibt in beiden Architekturen das Backend. Eine Datenmigration brauchen Sie dafür nicht. Ein Custom-Frontend können Sie später bauen, wenn App oder Design das wirklich verlangen.

Kurze Entscheidung

Kein Dev-Team, Blog und Shop sollen zusammenlaufen: iFrame
Eigene App plus komplett eigenes Web-Frontend: Headless

Snippet erzeugen, eine Seite einbetten

Testen Sie die Einbettung an einer Produktseite, nicht shopweit. Danach Höhe und Mobilansicht prüfen, erst dann den Blog-Artikel live schalten.

Plugin ansehen Contextual Commerce iFrame für Shopware 6 im Store ansehen