Shopware Shopping Experiences: Page Builder without Code 2026

Content velocity decides time-to-market in 2026 e-commerce: Combining a visual page builder with a headless CMS lets teams ship new landing pages around 75% (BigCommerce/Contentstack — K2 Sports) faster while content team productivity rises about 50% (BigCommerce/Contentstack). Yeti Cycles reports time-to-live dropping from weeks to hours (BigCommerce case). On the conversion side, landing-page data shows lifts like +86% (GemPages 2026) from video modules, +34% (SellersCommerce 2026) from social-proof elements and top-10% conversion rates above 10% while the median sits at 2.35% (SellersCommerce 2026). Shopware addresses these requirements with Shopping Experiences — a drag-and-drop page builder that ships fully in the Community Edition and can be extended with custom block types via plugin or app.

Shopping Experiences: What's in the standard?

Shopping Experiences is the marketing name for Shopware 6's integrated CMS module. Contrary to common belief, the feature is not gated behind a paid plan — it ships with the Community Edition / Open Source variant with its full feature set (solution25). Anyone self-hosting or working with our Shopware agency can use the page builder without any licensing argument. Operation happens directly inside the Administration: Content is composed via drag-and-drop, and every page can be assembled step by step without touching Twig templates.

In day-to-day operations this means: Marketing teams can publish campaign pages in hours rather than weeks without triggering a deployment. The editor surface stays identical to the commercial variants — block picker, slot system, live preview and the SEO tab exist in all editions. Only some cloud-specific convenience features drop out, but they are not relevant for the pure CMS function. On-premises operators get a page-builder tool with the Community Edition that typically holds its ground against dedicated third-party builders — and unlike them, it is natively integrated into the product, category and sales-channel context.

Hierarchy: Page → Section → Block → Slot → Element

According to the official documentation (developer.shopware.com), a Shopping Experience uses a five-level data structure: A Page is the top unit (storefront home, category, product page, landing page). It contains multiple Sections (areas) which define column layout. Sections hold Blocks — the curated building blocks like Text-Image-Row or Product Slider. Every block defines pre-set Slots (such as left and right for a two-column block), and slots are filled with concrete Elements: an image element, a text element, a product element. This separation enforces strict type safety: An image slot only accepts image elements, a product slot only accepts product-box elements.

In the database, this hierarchy maps to the cms_page, cms_section, cms_block, cms_slot tables and the link to concrete element records. Through the Store API, Shopware delivers the finished page as nested JSON — exactly the format a headless frontend would consume. That keeps a later migration to a composable architecture open, without losing the content created in the page builder or having to re-enter it.

{
  "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 and layout types

Sections support two layouts in the Community Edition: Default (full width) and Sidebar (two-column with a fixed left sidebar). Both can be mixed freely within a single page — for example a full-width hero on top, a filter-listing area with sidebar below (docs.shopware.com). At the page level, Shopware distinguishes four layout types: Shop Page for generic content, Landing Page for marketing campaigns, Category for category views, and Product Detail for individually crafted product pages. The latter has been possible since Shopware 6.4 and can be assigned per product.

On the section level, background colours, background images and mobile visibilities can be controlled per section. A section may, for example, be visible on desktop only, while an alternative compact section appears on mobile — without needing a separate layout variant. The layout types in turn determine which slots and blocks are prioritised in the editor: A category page enforces the presence of a product-listing block, a landing page instead offers freely combinable marketing blocks.

Block library overview

Shopware ships standard blocks across seven categories that have been visually grouped in the editor since 6.7.3. The catalogue covers around 30 ready-made blocks (developer.shopware.com) which can be combined without any custom code — from a plain text heading to a product slider with category filter.

In the editor, blocks are displayed grouped by category. Since 6.7.3, these categories are visible directly as tabs in the editor sidebar, removing the need to pick them via dropdown first — a typical quality-of-life update that visibly improves productivity. Hovering a block type reveals a preview component showing the schematic storefront rendering. That preview component is also the first place to extend when a custom block needs a meaningful preview state.

Building a custom block via plugin

Teams already maintaining custom PHP plugins can ship custom blocks directly inside a plugin. The directory layout follows the official convention src/Resources/app/administration/src/module/sw-cms/blocks/<category>/<name>/ for the editor component and src/Resources/views/storefront/block/cms-block-<name>.html.twig for storefront rendering (developer.shopware.com). Shopware 6.7 swapped the build system to Vite — Webpack is gone; at the same time, Meteor components like mt-button became the new standard, replacing the legacy sw-button.

The editor component typically consists of two parts: A configuration component (sw-cms-block-<name>-config) where slot bindings, margins and sizing modes are set, and a render component that displays the block inside the editor. With Shopware 6.7, the new Meteor components should be used — mt-card, mt-text-field, mt-button, mt-select. The legacy sw-* counterparts are still registered but considered deprecated and will be removed in a later major release. Anyone maintaining a plugin should plan the migration to Meteor components in the 6.7 release window.

On the storefront side, Shopware 6.7 adds another change: Header and footer are rendered via ESI (Edge Side Includes). This has no direct impact on a custom block, but caching strategies for block content should take it into account — especially when a block delivers context-dependent content (such as customer-group-specific prices). The sw-thumbnails filter chain remains the recommended way for image blocks to produce responsive image output with correct srcset/sizes attributes.

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

Shopware.Service('cmsService').registerCmsBlock({
    name: 'product-spotlight',
    label: 'Product 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',
    },
});

On the storefront side the block is then rendered through slot output — typically inside cms-block-product-spotlight.html.twig using block_renderer.element(element) as the helper for each slot. From the plugin perspective, the block becomes immediately selectable in the Administration and can be placed in any Shopping Experience without further configuration.

Custom block via app: no PHP plugin

Since Shopware 6.7, apps also support custom CMS blocks and apps inside CMS detail pages. Apps are the right choice when no PHP code should be deployed — for SaaS extensions or cloud-hosted Shopware instances. Configuration is declarative through manifest.xml, block templates live under Resources/cms/blocks/<name>/ and ship serverlessly out of the app (developer.shopware.com).

With the app variant, Shopware itself takes over the rendering bridge: The storefront Twig is loaded from the app directory and rendered at runtime without the app needing its own HTTP endpoint. For more complex scenarios, app action buttons, app custom fields and app webhooks are available, allowing an app to hook into data events of the Shopware platform — without PHP, but via clearly defined REST interfaces. In practice, this combination makes apps a lighter maintenance model: Updates ship through the Shopware Store backend without running composer install or migration scripts on the target system.

<?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 via 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 for SEO and campaigns

The landing-page builder market is estimated at around USD 2.5 bn (2025) and is projected by industry reports to grow at a 15% CAGR to USD 6.3 bn by 2032 (SellersCommerce 2026). AI-generated campaign pages typically deliver lifts of +37% (SellersCommerce); even a simple step like reducing forms from 11 to 4 fields can drive +120% (SellersCommerce 2026). Shopware landing pages cover these requirements out of the box — custom URL, dedicated SEO fields, free section/block composition and structured data via JSON-LD.

From an SEO perspective, the dedicated meta fields of a landing page are particularly valuable: Title and description can be aligned exactly to the campaign's search intent without colliding with the meta fields of a category. On top of that, structured data can be injected through Twig snippets — for example a Product schema for embedded product sliders or FAQPage markup for FAQ blocks. Combined with hreflang and canonicals, campaign pages emerge that can be unambiguously matched in both national and international search. Operators running multiple storefronts (DE/AT/CH) should set up an own LP variant per sales channel rather than mirroring a global page — maintenance stays much cleaner this way.

• Custom URL per landing page (/black-week-2026/) — independent from category paths
• Separate meta-title/description via the SEO tab inside the layout editor
• Sales-channel scoping — a page can be enabled only for a specific storefront
• Wired with campaign banners, coupons or dynamic product sliders
• Performance-ready via fetchpriority (see below) and Lighthouse 100
• No migration required — landing pages run alongside the regular shop structure

Individualising product detail pages

Since Shopware 6.4, product detail pages can be individualised through Shopping Experiences — every product can be assigned a custom layout that replaces the default PDP. This allows hero products, bundle listings or premium brands to look visually different from long-tail catalogue items. Custom PDPs inherit the visually highlighted CMS content inheritance from Shopware 6.7.5 onwards, making it clear inside the editor which values come from the layout, the product or the parent category.

A typical use case are hero products or premium brands whose PDPs should look deliberately distinct from the standard layout. With an assigned product-detail layout, editorial blocks, story sections, image galleries and customer-specific cross-selling modules can be integrated — without needing a custom theme. It is important that the layout still contains the mandatory product box slot so that price, variant selection and the add to cart button remain available. Forgetting this risks PDPs without a buy option — the conversion loss would be severe.

Performance: fetchpriority and image loading

Shopping Experiences often rely on big hero images, which means the LCP element regularly lives inside a CMS image or image-slider block. Shopware 6.7.2 added the fetchpriority configuration for image sliders and image galleries, 6.7.4 followed up with fetchpriority="high" for the CMS image element (developer.shopware.com release notes). Block-level control over which image gets prioritised by the browser is a direct lever for Core Web Vitals LCP.

From a measurement perspective, it is worth tracking LCP separately for the standard storefront and CMS-driven pages. CMS pages tend toward higher LCP values because hero images often arrive at the original resolution that the editor does not automatically downscale. A sensible practice: Set an image resolution limit per hero slot inside the block configuration and equip the image element with width/height attributes to avoid CLS jumps. Combined with fetchpriority="high" and loading="eager", the LCP of a Shopping-Experience hero block can typically be pushed below the 2.5-second threshold — even on slower mobile connections.

{# Storefront override for the 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: what's new?

1. 6.7.0 — Storefront product box with a11y improvements, deprecated prop for 6.6/6.7 compatibility. Header/footer rendering via ESI, build system switched to Vite; Meteor components (mt-button) replace sw-button.
2. 6.7.2 — fetchpriority configuration for image-slider and image-gallery blocks; controllable per slide (developer.shopware.com).
3. 6.7.3 — Block types are now visible directly in the editor sidebar — no upfront category selection required.
4. 6.7.4 — fetchpriority="high" added for the CMS image element; combined with loading="eager" for LCP imagery.
5. 6.7.5 (December 2025) — CMS content inheritance is visually marked in the editor; native video media type plus video element with autoplay/loop/controls; apps can be embedded in CMS detail pages (Shopware GitHub UPGRADE-6.7).

Shopping Experiences vs headless: when to use what?

Shopping Experiences and headless Shopware are not opposites — they are different tools for different jobs. A pure storefront benefits from the integrated page builder. A PWA, mobile app or pure API consumer pulls Shopping-Experience data as JSON over the Store API and renders independently — but drag-and-drop convenience is then no longer available out of the box.

A hybrid architecture is often the most pragmatic answer: The classic storefront keeps being rendered by Shopping Experiences, while a mobile app or PWA consumes the Shopping-Experience data as JSON via the Store API and ships its own renderer. That saves marketing time on one side (drag-and-drop on the web) while permitting channel-specific presentation on the other. Teams that want to go fully headless from day one can still use the page builder as a pure content-management tool — the editor experience remains valuable even without an active storefront, as soon as the JSON data goes to the team's own frontend.

5-phase roadmap for a scalable CMS pipeline

A successful migration of existing templates to Shopping Experiences typically works best in iterative steps: First the static pages, then campaign landing pages, finally the high-traffic categories and selected PDPs. Each phase should close with a performance check (Lighthouse, RUM data) and an editorial check (are the blocks understandably named? Which need documentation?). Custom blocks then emerge from concrete marketing requirements rather than being built speculatively up front — that keeps the custom-code share low and maintainability high.

1. Phase 1 — Inventory: Migrate all existing landing pages and categories to Shopping Experience layouts; identify non-CMS-based special templates.
2. Phase 2 — Block audit: Decide which standard blocks already cover the need and where custom blocks are required (spotlight, configurator, bundle display).
3. Phase 3 — Plugin or app decision: For each custom block, lock in the route — PHP plugin for data-heavy blocks, app for declarative layouts.
4. Phase 4 — Performance layer: Validate fetchpriority, lazy loading, AVIF/WebP thumbnails and Core Web Vitals tracking per block.
5. Phase 5 — Marketing enablement: Editor training, naming conventions, section templates as starting points; the marketing team builds LPs autonomously, with SEO and development shipping only the missing custom blocks.