Shopware Shopping Experiences: Page-Builder ohne Code 2026

Content-Velocity entscheidet im E-Commerce 2026 über Time-to-Market: Kombiniert man einen visuellen Page-Builder mit einem Headless-CMS, lassen sich neue Landingpages erfahrungsgemäß 75% (BigCommerce/Contentstack — K2 Sports) schneller ausspielen, während die Produktivität der Content-Teams um rund 50% (BigCommerce/Contentstack) steigt. Yeti Cycles berichtet, dass Time-to-Live von Wochen auf Stunden (BigCommerce-Case) sinkt. Auf der Conversion-Seite zeigen Landingpage-Daten Effekte wie +86% (GemPages 2026) durch Video-Module, +34% (SellersCommerce 2026) durch Social-Proof-Elemente und Top-10%-CR-Werte oberhalb von 10% bei einem Median von 2,35% (SellersCommerce 2026). Shopware beantwortet diese Anforderungen mit den Shopping Experiences — einem Drag-Drop-Page-Builder, der vollständig in der Community Edition verfügbar ist und sich über Plugins oder Apps um eigene Block-Typen erweitern lässt.

Shopping Experiences: Was im Standard enthalten ist

Shopping Experiences ist der Marketing-Name für das integrierte CMS-Modul von Shopware 6. Anders als oft vermutet ist diese Funktion nicht an einen kostenpflichtigen Plan gebunden — sie steht in der Community Edition / Open Source-Variante mit vollem Funktionsumfang zur Verfügung (solution25). Wer die Plattform selbst hostet oder über unsere Shopware-Agentur betreuen lässt, kann den Page-Builder also ohne Lizenzkostenargument nutzen. Die Bedienung erfolgt direkt in der Administration: Inhalte werden per Drag-and-Drop kombiniert, jede Seite lässt sich Schritt für Schritt aufbauen, ohne dass Twig-Templates angefasst werden müssen.

Im Tagesgeschäft heißt das: Marketing-Teams können Kampagnenseiten in Stunden statt Wochen freischalten, ohne ein Deployment auszulösen. Die Editor-Oberfläche bleibt identisch zur kommerziellen Variante — Block-Picker, Slot-System, Live-Preview und das SEO-Tab sind in allen Editionen vorhanden. Lediglich einige Cloud-spezifische Komfort-Features fallen weg, sind aber für die reine CMS-Funktion nicht relevant. Wer die Plattform on-premises betreibt, bekommt mit der Community Edition ein Page-Builder-Werkzeug, das im Funktionsumfang erfahrungsgemäß mit dedizierten Drittanbieter-Buildern mithalten kann — und im Unterschied dazu nativ in den Produkt-, Kategorie- und Sales-Channel-Kontext eingebunden ist.

Hierarchie: Page → Section → Block → Slot → Element

Die Datenstruktur einer Shopping Experience ist nach offizieller Dokumentation (developer.shopware.com) fünfstufig: Eine Page ist die oberste Einheit (Shop-Startseite, Kategorieseite, Produktseite, Landingpage). Eine Page enthält mehrere Sections (Bereiche), die das Spaltenlayout bestimmen. Sections enthalten Blocks — die eigentlichen, kuratierten Bausteine wie Text-Image-Row oder Product-Slider. Jeder Block bringt vordefinierte Slots mit (etwa left und right bei einem zweispaltigen Block), und Slots werden mit konkreten Elements gefüllt: einem Bild-Element, einem Text-Element, einem Produkt-Element. Diese Trennung erlaubt strenge Typsicherheit: Ein Bild-Slot akzeptiert nur Image-Elements, ein Produkt-Slot nur Product-Box-Elements.

In der Datenbank wird diese Hierarchie über die Tabellen cms_page, cms_section, cms_block, cms_slot und die Verknüpfung zu konkreten Element-Datensätzen abgebildet. Über die Store-API liefert Shopware die fertige Page als verschachteltes JSON aus — exakt das Format, das ein Headless-Frontend konsumieren würde. Damit bleibt eine spätere Migration zu einer Composable-Architektur offen, ohne dass die im Page-Builder erstellten Inhalte verlorengehen oder neu erfasst werden müssten.

{
  "page": {
    "type": "landingpage",
    "name": "Black Week 2026",
    "sections": [
      {
        "type": "default",
        "blocks": [
          {
            "type": "image-text",
            "slots": {
              "left": { "type": "image", "config": { "media": "hero.jpg" } },
              "right": { "type": "text", "config": { "content": "<h2>Black Week</h2>" } }
            }
          },
          {
            "type": "product-slider",
            "slots": {
              "products": { "type": "product-slider", "config": { "category": "black-week" } }
            }
          }
        ]
      }
    ]
  }
}

Section-Layouts und Layout-Typen

Sections kennen in der Community Edition zwei Layouts: Default (volle Breite) und Sidebar (zweispaltig mit fixer Sidebar links). Beide Layouts dürfen in einer Page beliebig gemischt werden — ein Hero-Bereich über die volle Breite, ein Filter-Listing-Bereich mit Sidebar darunter (docs.shopware.com). Auf Page-Ebene unterscheidet Shopware vier Layout-Typen: Shop Page für generische Inhaltsseiten, Landing Page für Marketing-Kampagnen, Category für Kategorieansichten und Product Detail für individuell gestaltete Produktseiten. Letzteres ist seit Shopware 6.4 möglich und lässt sich pro Produkt zuweisen.

Auf Section-Ebene lassen sich außerdem Hintergrundfarben, Hintergrundbilder und Mobile-Sichtbarkeiten pro Section steuern. Eine Section kann etwa nur auf Desktop sichtbar sein, während eine alternative kompaktere Section auf Mobile angezeigt wird — ohne dass dafür eine eigene Layout-Variante nötig wäre. Die Layout-Typen wiederum bestimmen, welche Slots und Blocks im Editor priorisiert vorgeschlagen werden: Eine Category-Page erzwingt das Vorhandensein eines Product-Listing-Blocks, eine Landing-Page bietet stattdessen frei kombinierbare Marketing-Blöcke.

Block-Library im Überblick

Shopware liefert Standard-Blöcke in sieben Kategorien aus, die seit 6.7.3 direkt im Editor sichtbar gruppiert sind. Im Sortiment finden sich rund 30 vorgefertigte Blöcke (developer.shopware.com), die sich ohne Custom-Code kombinieren lassen — vom einfachen Text-Heading bis zum Produkt-Slider mit Kategorie-Filter.

Im Editor werden die Blöcke in Kategorien gruppiert dargestellt. Seit 6.7.3 sind diese Kategorien direkt in der Editor-Sidebar als Reiter sichtbar, ohne dass man sie vorher per Dropdown auswählen müsste — ein typisches Quality-of-Life-Update, das die Produktivität erfahrungsgemäß spürbar steigert. Beim Hovern über einen Block-Typ wird eine Preview-Komponente eingeblendet, die das spätere Storefront-Rendering schematisch zeigt. Die Preview-Komponente ist auch der erste Anpassungspunkt, wenn ein Custom-Block einen aussagekräftigen Vorschauzustand bekommen soll.

Custom-Block per Plugin entwickeln

Wer ohnehin eigene PHP-Plugins betreut, kann Custom-Blöcke direkt in einem Plugin ausliefern. Die Verzeichnisstruktur folgt der offiziellen Konvention src/Resources/app/administration/src/module/sw-cms/blocks/<category>/<name>/ für die Editor-Komponente und src/Resources/views/storefront/block/cms-block-<name>.html.twig für das Storefront-Rendering (developer.shopware.com). Mit Shopware 6.7 wurde das Build-System auf Vite umgestellt — Webpack ist Geschichte; gleichzeitig wurden Meteor-Komponenten wie mt-button zum Pflicht-Standard und ersetzen das alte sw-button.

Die Editor-Komponente besteht typischerweise aus zwei Teilen: einer Konfigurations-Komponente (sw-cms-block-<name>-config), in der Slot-Bindungen, Margins und Sizing-Modes eingestellt werden, und einer Render-Komponente, die den Block im Editor darstellt. Mit Shopware 6.7 sollten dabei die neuen Meteor-Komponenten verwendet werden — mt-card, mt-text-field, mt-button, mt-select. Die alten sw-*-Pendants sind weiterhin registriert, gelten aber als deprecated und werden in einem späteren Major-Release entfernt. Wer ein Plugin pflegt, sollte den Umstieg auf Meteor-Komponenten in den 6.7-Release einplanen.

Auf Storefront-Seite kommt mit Shopware 6.7 eine weitere Neuerung: Header und Footer werden via ESI (Edge Side Includes) gerendert. Das hat keine direkten Auswirkungen auf einen Custom-Block, aber Caching-Strategien für Block-Inhalte sollten dies berücksichtigen — insbesondere wenn ein Block kontextabhängige Inhalte ausspielt (etwa kundengruppen-spezifische Preise). Die sw-thumbnails-Filterkette bleibt für Bild-Blöcke der empfohlene Weg, um responsive Bildausgaben mit korrekten srcset/sizes-Attributen zu erzeugen.

import './component';
import './preview';

Shopware.Service('cmsService').registerCmsBlock({
    name: 'product-spotlight',
    label: 'Produkt-Spotlight',
    category: 'commerce',
    component: 'sw-cms-block-product-spotlight',
    previewComponent: 'sw-cms-block-product-spotlight-preview',
    defaultConfig: {
        marginBottom: '40px',
        marginTop: '40px',
        sizingMode: 'boxed',
    },
    slots: {
        product: 'product-box',
        text: 'text',
    },
});

Im Storefront-Twig wird der Block dann über die Slot-Ausgabe gerendert — typisch in der Datei cms-block-product-spotlight.html.twig mit block_renderer.element(element) als Helper für jeden Slot. Pluginseitig kann der Block sofort in der Administration ausgewählt und in jeder Shopping Experience platziert werden, ohne dass weitere Konfiguration nötig ist.

Custom-Block per App: Ohne PHP-Plugin

Seit Shopware 6.7 unterstützen Apps auch eigene CMS-Blöcke und Apps in CMS-Detail-Pages. Apps sind die richtige Wahl, wenn kein PHP-Code deployt werden soll — etwa für SaaS-Erweiterungen oder cloudgehostete Shopware-Instanzen. Die Konfiguration erfolgt deklarativ in der manifest.xml, die Block-Templates liegen unter Resources/cms/blocks/<name>/ und werden serverlos aus der App ausgeliefert (developer.shopware.com).

Bei der App-Variante übernimmt Shopware die Rendering-Brücke: Der Storefront-Twig wird aus dem App-Verzeichnis geladen und zur Laufzeit gerendert, ohne dass die App einen eigenen HTTP-Endpoint braucht. Für komplexere Szenarien stehen außerdem App-Action-Buttons, App-Custom-Fields und App-Webhooks bereit, sodass eine App durchaus an Daten-Events der Shopware-Plattform andocken kann — ohne PHP, aber mit klar definierten REST-Schnittstellen. Diese Kombination macht Apps in der Praxis zu einem leichteren Wartungsmodell: Updates werden über das Shopware-Store-Backend ausgespielt, ohne dass composer install oder Migrations-Skripte auf dem Zielsystem ausgeführt werden müssen.

Aus Wartungssicht ist ein dritter Aspekt relevant: Updatesicherheit. Während Plugins bei jedem Shopware-Major-Update geprüft und ggf. angepasst werden müssen — etwa wegen Veränderungen an sw-cms-Komponenten oder Twig-Block-Strukturen — sind Apps gegen viele Breaking Changes deutlich robuster, weil sie nur mit der manifest-Schema-Version kompatibel sein müssen. Praktisch bedeutet das geringere Folgekosten über den Lebenszyklus eines Shops, was bei Custom-Block-Investitionen mit langer Nutzungsdauer ein relevanter Faktor sein kann.

<?xml version="1.0" encoding="UTF-8"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/shopware/shopware/trunk/src/Core/Framework/App/Manifest/Schema/manifest-3.0.xsd">
    <meta>
        <name>XictronSpotlight</name>
        <label>XICTRON Spotlight Blocks</label>
        <description>Custom CMS-Blocks per App</description>
        <author>XICTRON</author>
        <copyright>(c) XICTRON</copyright>
        <version>1.0.0</version>
        <license>MIT</license>
    </meta>
    <cms>
        <blocks>
            <block>
                <name>xictron-spotlight</name>
                <category>commerce</category>
                <label>Spotlight Product</label>
                <slots>
                    <slot name="product" type="product-box"/>
                    <slot name="text" type="text"/>
                </slots>
            </block>
        </blocks>
    </cms>
</manifest>

Landing Pages für SEO und Kampagnen

Der Markt für Landing-Page-Builder wird auf rund 2,5 Mrd USD (2025) geschätzt und wächst laut Branchen-Reports mit einer CAGR von 15% auf prognostizierte 6,3 Mrd USD bis 2032 (SellersCommerce 2026). KI-generährte Kampagnen-Pages erzielen erfahrungsgemäß +37% (SellersCommerce) Conversion-Lift; auch ein simpler Schritt wie die Reduktion von 11 auf 4 Formularfelder kann +120% (SellersCommerce 2026) Conversion bringen. Shopware-Landingpages decken diese Anforderungen direkt ab — eigene URL, eigene SEO-Felder, freie Section-/Block-Kombination und Strukturdaten via JSON-LD.

Aus SEO-Sicht sind die separaten Meta-Felder einer Landing-Page besonders wertvoll: Title und Description lassen sich exakt auf die Suchintention der Kampagne ausrichten, ohne mit den Meta-Feldern einer Kategorie zu kollidieren. Dazu kommt die Möglichkeit, strukturierte Daten über Twig-Snippets zu ergänzen — etwa Product-Schemas für eingebettete Produkt-Slider oder FAQPage-Markup für FAQ-Blöcke. In Kombination mit hreflang und Canonicals entstehen Kampagnenseiten, die sowohl in der nationalen als auch in der internationalen Suche eindeutig zugeordnet werden können. Wer mehrere Storefronts (DE/AT/CH) betreibt, sollte pro Sales Channel eine eigene LP-Variante anlegen, statt eine globale Page zu spiegeln — die Pflege bleibt dadurch übersichtlich.

• Eigene URL pro Landingpage (/black-week-2026/) — frei vom Kategorie-Pfad
• Separate Meta-Title/-Description über das SEO-Tab im Layout-Editor
• Sales Channel-Zuweisung — eine Page kann nur für DE-Storefront aktiviert sein
• Verknüpfung mit Kampagnen-Code-Banner, Coupons oder dynamischen Produkt-Slidern
• Performance-tauglich über fetchpriority (siehe Abschnitt unten) und Lighthouse 100
• Keine Migration nötig — Landingpages laufen parallel zur normalen Shop-Struktur

Product Detail Pages individualisieren

Seit Shopware 6.4 dürfen Product Detail Pages über Shopping Experiences individualisiert werden — pro Produkt lässt sich ein eigenes Layout zuweisen, das die Standard-PDP ersetzt. Damit lassen sich Hero-Produkte, Bundle-Listings oder Premium-Marken visuell anders darstellen als der Long-Tail-Katalog. Die Custom-PDPs erben ab Shopware 6.7.5 sichtbar markierte CMS-Content-Vererbung, sodass im Editor klar erkennbar ist, welche Werte vom Layout, vom Produkt oder von der übergeordneten Kategorie kommen.

Ein typisches Einsatzszenario sind Hero-Produkte oder Premium-Marken, deren PDPs sich bewusst vom Standard-Layout abheben sollen. Mit einem zugewiesenen Product-Detail-Layout können Editorial-Blöcke, Story-Sections, Bild-Galerien und kundenspezifische Cross-Selling-Module integriert werden — ohne dass dafür ein Custom-Theme nötig wäre. Wichtig ist, dass das Layout den Pflicht-Slot Product-Box weiterhin enthält, damit Preis, Variantenwahl und der In-den-Warenkorb-Button verfügbar bleiben. Wer das vergisst, riskiert PDPs ohne Kaufoption — der Conversion-Verlust wäre gravierend.

Performance: fetchpriority und Image-Loading

Shopping Experiences setzen oft auf große Hero-Bilder, weshalb das LCP-Element regelmäßig in einem CMS-Image- oder Image-Slider-Block landet. Shopware 6.7.2 brachte dafür die fetchpriority-Konfiguration für Image-Slider und Image-Gallery, 6.7.4 zog mit fetchpriority="high" für das CMS-Image-Element nach (developer.shopware.com Release Notes). Damit lässt sich pro Block steuern, welches Bild der Browser priorisiert lädt — ein direkter Hebel für Core-Web-Vitals-LCP.

Aus messtechnischer Sicht lohnt sich eine getrennte Auswertung der LCP-Werte zwischen Standard-Storefront und CMS-getriebenen Pages. CMS-Pages tendieren zu höheren LCP-Werten, weil Hero-Bilder oft uneditierte Original-Auflösungen mitbringen, die der Editor nicht automatisch herunterskaliert. Eine sinnvolle Praxis: Für jeden Hero-Slot ein Image-Resolution-Limit in der Block-Konfiguration setzen und das Image-Element mit width/height-Attributen ausstatten, um CLS-Sprünge zu vermeiden. Kombiniert mit fetchpriority="high" und loading="eager" lässt sich der LCP-Wert eines Shopping-Experience-Hero-Blocks typischerweise unter die 2,5-Sekunden-Schwelle drücken — auch auf langsameren Mobile-Verbindungen.

{# Storefront-Override für CMS-Image-Element #}
{% block element_image_inner %}
    {% set fetchpriority = element.config.fetchpriority.value|default('auto') %}
    {% set loading = (fetchpriority == 'high') ? 'eager' : 'lazy' %}

    <img
        src="{{ media|sw_thumbnails }}"
        alt="{{ media.translated.alt|default('') }}"
        loading="{{ loading }}"
        fetchpriority="{{ fetchpriority }}"
        decoding="async"
        width="{{ media.metaData.width }}"
        height="{{ media.metaData.height }}"
    >
{% endblock %}

Shopware 6.7 Updates: Was ist neu?

1. 6.7.0 — Storefront-Produktbox mit A11y-Verbesserungen, deprecated-Prop für 6.6/6.7-Kompatibilität. Header/Footer-Rendering über ESI, Build-System auf Vite umgestellt; Meteor-Komponenten (mt-button) ersetzen sw-button.
2. 6.7.2 — fetchpriority-Konfiguration für Image-Slider- und Image-Gallery-Blöcke; pro Slide gezielt steuerbar (developer.shopware.com).
3. 6.7.3 — Block-Typen sind direkt in der Editor-Sidebar sichtbar — keine vorherige Kategorie-Auswahl nötig.
4. 6.7.4 — fetchpriority="high" für das CMS-Image-Element ergänzt; kombiniert mit loading="eager" für LCP-Bilder.
5. 6.7.5 (Dezember 2025) — CMS-Content-Vererbung wird im Editor visuell markiert; nativer Video-Media-Typ plus Video-Element mit Autoplay/Loop/Controls; Apps dürfen in CMS-Detail-Pages eingebunden werden (Shopware GitHub UPGRADE-6.7).

Shopping Experiences vs Headless: Wann was?

Shopping Experiences und Headless Shopware sind keine Gegensätze, sondern unterschiedliche Werkzeuge. Wer eine reine Storefront baut, profitiert vom integrierten Page-Builder. Wer eine PWA, Mobile-App oder einen reinen API-Konsumenten betreibt, lädt die Shopping-Experience-Daten als JSON über die Store-API und rendert eigenständig — aber: Drag-Drop-Komfort gibt es dann nicht out-of-the-box.

Eine hybride Architektur ist häufig die pragmatischste Lösung: Die klassische Storefront wird weiterhin von Shopping Experiences gerendert, während eine Mobile-App oder PWA über die Store-API die Shopping-Experience-Daten als JSON konsumiert und mit einem eigenen Renderer ausspielt. Das spart auf der einen Seite Marketing-Zeit (Drag-Drop für Web), erlaubt aber gleichzeitig kanalspezifische Darstellungen auf der anderen Seite. Wer von Anfang an konsequent headless arbeiten möchte, kann den Page-Builder dennoch als reines Content-Management-Werkzeug nutzen — die Editor-Oberfläche ist auch ohne aktive Storefront sinnvoll, sobald die JSON-Daten an das eigene Frontend gehen.

Konkrete Indikatoren für den Headless-Weg: Wenn ein Mobile-App-Team eigenständig deployt, wenn POS-Systeme oder IoT-Endpunkte angebunden werden sollen oder wenn sehr individuelle Animationen und State-Management-Logiken gefragt sind. Indikatoren für den Shopping-Experience-Weg: Marketing-getriebene Inhalte mit hoher Frequenz, kleinere Teams ohne dediziertes Frontend-Engineering und ein klarer Fokus auf den Web-Kanal. In beiden Fällen bleibt die Plattform Shopware der zentrale Datenlieferant — die Frage ist lediglich, wo das finale Rendering passiert und wer die Komposition steuert.

5-Phasen-Roadmap zur skalierbaren CMS-Pipeline

Eine erfolgreiche Migration bestehender Vorlagen auf Shopping Experiences gelingt erfahrungsgemäß am besten in iterativen Schritten: Erst die statischen Seiten, dann Kampagnen-Landingpages, schließlich die hochfrequentierten Kategorien und ausgewählte PDPs. Jede Phase sollte mit einem Performance-Check (Lighthouse, RUM-Daten) und einem Editorial-Check (sind die Blöcke verständlich benannt? Welche brauchen Dokumentation?) abgeschlossen werden. Custom-Blöcke entstehen dann gezielt aus konkreten Marketing-Anforderungen, statt vorab spekulativ entwickelt zu werden — das hält den Custom-Code-Anteil niedrig und die Wartbarkeit hoch.

Wer das Custom-Block-Inventar laufend dokumentiert — Naming-Konvention, Slot-Spezifikation, Vorschau-Screenshot, Beispiel-Use-Case — schafft eine Wissensbasis, die Onboarding neuer Marketing-Mitarbeitender drastisch beschleunigt. Erfahrungsgemäß lohnt sich der Aufwand: Schon bei wenigen Custom-Blocks vergisst ein Team nach Monaten, welche Konfigurations-Optionen ein Block bietet und wann er gegenüber einem Standard-Block bevorzugt eingesetzt werden sollte.

1. Phase 1 — Inventur: Alle bestehenden Landingpages und Kategorien auf Shopping-Experience-Layouts überführen; nicht-CMS-basierte Sondervorlagen identifizieren.
2. Phase 2 — Block-Audit: Prüfen, welche Standard-Blöcke bereits ausreichen und wofür Custom-Blöcke nötig sind (Spotlight, Konfigurator, Bundle-Display).
3. Phase 3 — Plugin- oder App-Entscheidung: Pro Custom-Block den Weg festlegen — PHP-Plugin für datengetriebene Blöcke, App für deklarative Layouts.
4. Phase 4 — Performance-Layer:fetchpriority, Lazy-Loading, AVIF/WebP-Thumbnails und Core Web Vitals-Tracking pro Block validieren.
5. Phase 5 — Marketing-Enablement: Editor-Schulung, Naming-Konventionen, Section-Templates als Vorlage; Marketing-Team baut LPs eigenständig, SEO und Programmierung liefern nur Custom-Blöcke nach.