Shopware Shopping Experiences: The Complete Guide to Building Content-Driven Commerce Pages
Most ecommerce platforms treat content and commerce as separate concerns. Products live in the catalog. Content lives in a CMS or blog. The two don’t interact unless a developer builds a bridge between them.
Shopware’s Shopping Experiences rejects that separation. It’s a layout system built directly into the commerce platform where content blocks and product blocks coexist on the same page, pulling from the same data layer. A landing page can display editorial content alongside live product listings, dynamic pricing, and personalized recommendations – all rendered server-side, all managed through a drag-and-drop admin interface.
This isn’t a page builder bolted onto an ecommerce backend. It’s an integrated content-commerce system that powers category pages, landing pages, product detail pages, and brand pages from a single interface.
We’ve built dozens of Shopping Experiences implementations – from simple promotional landing pages to complex B2B product configurator pages with conditional content blocks. This guide covers everything: core concepts, the block system, building custom blocks, API integration, multi-channel workflows, performance optimization, and how Shopping Experiences compares to headless CMS alternatives.
Core Concepts
Layouts
A Shopping Experience is a layout – a page structure composed of sections and blocks. Every layout has a type that determines where it can be assigned:
- Landing page layouts are standalone pages with their own URLs
- Listing layouts are assigned to category pages and control how products are displayed alongside content
- Detail page layouts override the default product detail page structure
- Custom entity layouts display data from custom data structures
Layouts are the container. Everything else – sections, blocks, content – lives inside them.
Sections
Sections are horizontal rows within a layout. Each section has a layout mode:
- Default – single column, full-width blocks
- Sidebar – main content area with a sidebar (left or right)
Sections can have background colors, background images, and CSS classes. They’re the structural skeleton of the page.
Blocks
Blocks are the content units that fill sections. A block occupies a slot within a section and contains one or more elements. Shopware ships with dozens of block types – text blocks, image blocks, product listing blocks, video blocks, form blocks, and more.
Blocks are where the content-commerce integration happens. A text block and a product slider block can sit side by side in the same section, creating pages where editorial content flows naturally into shoppable product displays.
Elements
Elements are the individual content pieces within blocks. A two-column image-text block contains two elements: an image element and a text element. Elements have configurable properties – the image element has source, alt text, and link properties; the text element has rich text content and alignment.
Slots
Slots are the positions within a block where elements are placed. A three-column block has three slots. Each slot can hold one element. The slot system ensures blocks maintain their structure regardless of what content fills them.
The Block System
Shopware ships with block types organized into categories. Understanding the available blocks is essential for planning page layouts.
Block Type Reference
Text Blocks
| Block | Description | Slots |
|---|---|---|
| Text | Single text area with rich text editor | 1 |
| Text (two columns) | Two side-by-side text areas | 2 |
| Text (three columns) | Three side-by-side text areas | 3 |
| Text on image | Text overlay on background image | 2 (image + text) |
| Text hero | Large centered text with background | 2 |
Image Blocks
| Block | Description | Slots |
|---|---|---|
| Image | Single image | 1 |
| Image (two columns) | Two side-by-side images | 2 |
| Image (three columns) | Three side-by-side images | 3 |
| Image gallery | Grid of images with lightbox | 1 (multiple images) |
| Image slider | Carousel of images | 1 (multiple images) |
| Image highlight row | Large image with smaller images | 3 |
Image + Text Blocks
| Block | Description | Slots |
|---|---|---|
| Image + text | Image and text side by side | 2 |
| Text + image | Text and image side by side (reversed) | 2 |
| Image + text (centered) | Vertically centered variant | 2 |
| Image + text + image | Three-column with text center | 3 |
Commerce Blocks
| Block | Description | Slots |
|---|---|---|
| Product listing | Category product grid/list | 1 |
| Product slider | Horizontal product carousel | 1 |
| Product (three columns) | Three specific products | 3 |
| Cross-selling | Related/upsell products | 1 |
| Buy box | Add-to-cart with product info | 1 |
| Product description/reviews | Product detail components | 1 |
Video Blocks
| Block | Description | Slots |
|---|---|---|
| YouTube video | Embedded YouTube player | 1 |
| Vimeo video | Embedded Vimeo player | 1 |
Form Blocks
| Block | Description | Slots |
|---|---|---|
| Contact form | Name, email, message fields | 1 |
| Newsletter form | Email signup | 1 |
Sidebar Blocks
| Block | Description | Use |
|---|---|---|
| Sidebar filter | Faceted navigation filters | Listing layouts |
| Category navigation | Category tree menu | Sidebar sections |
Building Custom Blocks
The built-in blocks cover standard content needs. But real-world implementations almost always require custom blocks for business-specific content patterns.
When to Build Custom Blocks
Build custom blocks when you need:
- Brand-specific content patterns – testimonial carousels, team member grids, pricing comparison tables that match your design system
- Commerce-integrated content – product comparison blocks that pull live pricing, stock availability widgets, dealer locator maps
- Interactive elements – calculators, configurators, ROI tools embedded in content pages
- Data-driven content – blocks that pull data from external sources (CRM, ERP, analytics) and display it on content pages
- Industry-specific layouts – technical specification tables, compliance documentation blocks, certification display blocks
Custom Block Architecture
A custom block in Shopware requires four components:
1. Block definition (JavaScript/Vue). Registers the block in the admin panel’s Shopping Experiences editor. Defines the block’s name, category, preview image, and slot configuration.
2. Admin component (Vue.js). The editing interface for the block within the admin panel. This is what content managers see when they add the block to a layout and configure its content.
3. Storefront template (Twig). The HTML/Twig template that renders the block on the frontend. This controls how the block appears to visitors.
4. Element plugin (optional). If the block uses custom elements beyond what Shopware provides natively, each element needs its own plugin definition, admin component, and storefront template.
Custom Block Example: Testimonial Carousel
A testimonial carousel block might include:
- Slots: Multiple testimonial slots (configurable number)
- Element properties per slot: Customer name, company, quote text, customer photo, star rating
- Admin component: Form fields for each testimonial with image upload and text inputs
- Storefront template: Responsive carousel with lazy-loaded images, star display, and company attribution
The admin component renders in the Shopping Experiences editor, allowing content managers to add, remove, and reorder testimonials without touching code. The storefront template renders the carousel with whatever CSS framework or custom styling the theme uses.
Custom Block Best Practices
- Keep blocks focused. One block should do one thing well. A “testimonial block” and a “team member block” are better than a “people block” with a type toggle.
- Make blocks configurable, not coded. Colors, layouts, number of items, and visibility should be configurable through the admin, not hardcoded in templates.
- Follow Shopware’s slot pattern. Even for complex blocks, use the slot/element architecture. This ensures compatibility with the layout system and future Shopware updates.
- Test responsive behavior. Custom blocks must work on mobile. The Shopping Experiences editor doesn’t show mobile previews by default – test manually.
- Document for content managers. Custom blocks are useless if the content team doesn’t know how to use them. Provide naming conventions and brief guides for each custom block.
API Integration
Shopping Experiences layouts are fully accessible through Shopware’s Store API and Admin API. This enables headless implementations, external content management, and programmatic layout creation.
Store API (Frontend)
The Store API provides layout data for rendering on custom frontends. When a headless storefront loads a category page or landing page, it requests the layout through the Store API, which returns the complete layout structure – sections, blocks, elements, and all configured content – as JSON.
Key endpoints:
POST /store-api/cms/{id}– Load a specific CMS page by IDPOST /store-api/category/{id}– Load a category page (includes the assigned Shopping Experience layout)POST /store-api/landing-page/{id}– Load a landing page
The response includes the full layout tree: sections with their blocks, blocks with their elements, and elements with their configured data (text content, image URLs, product IDs, etc.).
Admin API (Backend)
The Admin API enables programmatic creation and management of layouts. This is useful for:
- Bulk layout creation – generating hundreds of category layouts from a template
- Content migration – importing content from another CMS into Shopping Experiences
- External CMS integration – syncing content from a headless CMS (Contentful, Strapi) into Shopping Experiences layouts
- Automated testing – creating test layouts programmatically for QA
Key endpoints:
POST /api/cms-page– Create a new layoutPATCH /api/cms-page/{id}– Update an existing layoutGET /api/cms-page/{id}– Retrieve a layout with its full structureDELETE /api/cms-page/{id}– Delete a layout
Programmatic Layout Creation
Creating a layout through the API requires building the full hierarchy: layout, sections, blocks, and elements. The JSON payload is nested – sections contain blocks, blocks contain slots, slots reference elements.
This is the approach we use when migrating content from other platforms into Shopware. Rather than manually recreating hundreds of pages through the admin panel, we write migration scripts that transform the source content into Shopping Experiences API payloads and create all layouts programmatically.
Multi-Channel Workflow
One of Shopping Experiences’ strongest capabilities is multi-channel content management. A single layout can serve different sales channels with channel-specific content.
Sales Channel Assignment
Shopware supports multiple sales channels from a single instance – different storefronts for different markets, languages, or customer segments. Shopping Experiences layouts can be:
- Shared across channels – the same layout appears on all sales channels, with translated content
- Channel-specific – different layouts for different channels
- Mixed – a shared structure with channel-specific content blocks
Translation Workflow
Every text element in a Shopping Experience layout supports translations. The content manager creates the layout in the primary language, then switches the language context in the admin to add translations. Images can also be swapped per language (useful when images contain text).
This means a single layout structure – same sections, same blocks, same visual hierarchy – can serve English, German, French, and Spanish storefronts with language-appropriate content. The structure is defined once; the content is translated per channel.
B2B vs B2C Content
For businesses with both B2B and B2C sales channels, Shopping Experiences enables different content for different audiences on the same category structure. A category page might show consumer-oriented content (lifestyle images, benefit-focused copy) on the B2C channel and technical-oriented content (specifications, bulk pricing information, compatibility charts) on the B2B channel.
This is managed through layout assignment: the B2C sales channel’s categories are assigned consumer layouts, and the B2B channel’s categories are assigned business layouts. The product catalog is shared; the content experience is tailored.
Assignment Strategies
How you assign layouts to pages determines the content management workflow and the visitor experience.
Category-Level Assignment
Assign a layout to a category, and all products listed under that category are displayed within that layout. This is the most common approach for category pages.
Direct assignment – each category gets a specific layout. Works well when categories have distinct content needs (the “Industrial Pumps” category needs different content than the “Plumbing Supplies” category).
Inherited assignment – child categories inherit the parent’s layout unless overridden. This creates a default layout that applies broadly, with specific categories getting customized layouts where needed.
Product Detail Page Assignment
Shopping Experiences can override the default product detail page template. This enables:
- Category-based PDP layouts – products in the “Premium” category get an enhanced detail page with additional content sections
- Product-specific layouts – high-value products get individually designed detail pages with custom content blocks
- Product type layouts – configurable products, simple products, and downloadable products each get optimized detail page structures
Landing Page Strategy
Landing pages are standalone – they’re not tied to categories or products. They’re used for:
- Campaign pages – seasonal promotions, sale events, product launches
- Content hubs – resource centers, buying guides, comparison pages
- SEO landing pages – pages targeting specific keyword clusters
- Brand pages – manufacturer or brand showcase pages with product listings
Each landing page gets its own URL (configurable SEO URL) and its own layout. The layout can include any combination of content and commerce blocks.
Performance Optimization
Shopping Experiences pages can become heavy if not optimized. A page with multiple product sliders, high-resolution images, and embedded videos loads differently than a page with text and a few images.
Image Optimization
- Use Shopware’s media management for all images. The platform generates thumbnails at configurable breakpoints (800px, 1920px, etc.) and serves appropriately sized images.
- Implement lazy loading for images below the fold. Shopware’s default templates support lazy loading, but custom blocks need explicit implementation.
- Use WebP format where supported. Shopware can generate WebP versions of uploaded images with the right configuration.
- Set explicit dimensions on image elements. This prevents layout shift (CLS) during page load.
Block Loading Strategy
- Limit product slider blocks. Each product slider triggers database queries and product data processing. Three sliders on a page is reasonable. Ten sliders will create noticeable load time.
- Use static content for non-dynamic blocks. If a block’s content doesn’t change frequently, consider whether it needs to be a Shopping Experience block or could be a simpler static template element.
- Avoid deeply nested layouts. Sections within sections, complex sidebar configurations, and blocks referencing other blocks create rendering complexity.
Caching
- HTTP cache (Varnish/Fastly) caches full page responses. Shopping Experience pages that don’t contain personalized content should be fully cacheable.
- Object cache (Redis) caches database queries and CMS data structures. The layout tree is cached after first load.
- ESI (Edge Side Includes) can cache static sections while keeping dynamic sections (cart widgets, login status) fresh.
For pages with a mix of static content and dynamic product data, the caching strategy matters. Static text and image blocks should be cached aggressively. Product listing blocks with live pricing and stock data need shorter cache TTLs or ESI integration.
Core Web Vitals Impact
Shopping Experiences pages can achieve good Core Web Vitals scores with attention to:
- LCP (Largest Contentful Paint): Ensure the hero image or primary content block loads quickly. Preload hero images. Avoid huge unoptimized banner images.
- FID/INP (First Input Delay / Interaction to Next Paint): Minimize JavaScript in custom blocks. Avoid third-party scripts that block the main thread.
- CLS (Cumulative Layout Shift): Set dimensions on all images and embeds. Avoid blocks that resize after initial render.
Shopping Experiences vs Headless CMS
A common question: should you use Shopping Experiences for content, or integrate a headless CMS (Contentful, Strapi, Sanity) and use Shopware only for commerce?
When Shopping Experiences Is the Better Choice
- Content and commerce are tightly integrated. Your content pages include live product data – pricing, stock, add-to-cart functionality. Shopping Experiences pulls this data natively.
- Your content team is small. One or two people managing content don’t need the complexity of a separate CMS with API integration. The Shopping Experiences admin is sufficient.
- You want a single admin panel. Managing content, products, orders, and promotions in one interface reduces tool switching and training burden.
- SEO matters. Shopping Experiences pages are server-rendered and fully indexable by default. A headless CMS feeding a JavaScript frontend adds rendering complexity for SEO.
- Your budget is constrained. A separate headless CMS adds license cost ($300-3,000+/month for Contentful), integration development cost, and ongoing maintenance cost.
When a Headless CMS Is the Better Choice
- Content volume and complexity are high. If you’re publishing 50+ content pages per month with complex workflows (draft, review, approve, schedule), a dedicated CMS like Contentful or Strapi provides better editorial tooling.
- Content is shared across multiple frontends. If the same content appears on a website, mobile app, digital signage, and email templates, a headless CMS provides single-source content management with multi-channel delivery.
- You need advanced content modeling. Structured content with complex relationships (authors, topics, related articles, content series) is better modeled in a dedicated CMS.
- Your development team prefers composable architecture. If you’re already running Shopware headlessly with a Next.js or Nuxt.js frontend, adding a headless CMS fits the architectural pattern.
Hybrid Approach
Some implementations use both. Shopping Experiences handles commerce-heavy pages (category pages, product landing pages, promotional pages) while a headless CMS manages pure content (blog, knowledge base, documentation). The Shopware frontend integrates content from both sources.
This adds complexity but can be the right approach for organizations with significant content operations alongside complex commerce.
Best Practices for Shopping Experiences
Content Management
- Establish naming conventions. Layouts multiply quickly. Use a consistent naming scheme:
[Type] - [Category/Purpose] - [Channel](e.g., “Landing Page – Summer Sale 2026 – B2C”). - Create template layouts. Build base layouts for common page types (standard category, promotional landing page, brand page) and duplicate them as starting points for new pages. This ensures consistency and speeds up content creation.
- Use sections strategically. Each section should have a clear purpose – hero section, content section, product section, CTA section. This makes layouts readable and maintainable.
- Keep mobile in mind. Blocks stack vertically on mobile. A three-column layout that looks great on desktop becomes three stacked blocks on mobile. Ensure the stacking order makes sense.
- Version your layouts. Before making significant changes to a live layout, duplicate it, make changes on the copy, and swap assignments when ready. This prevents content editing from affecting live pages mid-edit.
Development
- Build a block library. Create custom blocks for your recurring content patterns and document them. A library of 10-15 custom blocks typically covers 90% of content needs for most ecommerce sites.
- Test layouts at scale. A layout with a product slider pulling 50 products behaves differently than one pulling 500. Test with production-scale data.
- Implement preview properly. The admin preview doesn’t always match the storefront rendering exactly. Build a proper preview workflow that renders the layout in the actual storefront theme.
- Use theme variables in blocks. Custom blocks should reference theme CSS variables for colors, spacing, and typography. This ensures blocks adapt when the theme changes.
- Consider accessibility. Custom blocks need proper ARIA labels, keyboard navigation, and screen reader compatibility. The default Shopware blocks handle this; custom blocks are your responsibility.
SEO
- Configure SEO URLs for all landing pages. Every landing page should have a clean, keyword-relevant URL – not an auto-generated one.
- Set meta titles and descriptions per page. Shopping Experiences pages support meta tags – use them. Don’t rely on auto-generated meta content.
- Use heading hierarchy correctly. The page title should be H1. Section headings should follow H2/H3 hierarchy. Don’t use text blocks with large bold text as a substitute for proper headings.
- Include internal links in content blocks. Text blocks within Shopping Experiences support links. Use them to build internal linking between content pages and between content and product pages.
- Implement structured data. For FAQ blocks, how-to blocks, or review blocks, implement appropriate schema markup in the block templates.
5 Common Mistakes With Shopping Experiences
1. Building everything as a Shopping Experience
Not every page needs the Shopping Experiences editor. Simple, rarely-changed pages (terms of service, privacy policy, about page) can be static Twig templates. The Shopping Experiences overhead – layout tree loading, block rendering, admin complexity – isn’t justified for a page that changes once a year.
2. Creating too many unique layouts
If every category has a completely unique layout, you have a maintenance problem. When you need to update the header section style or add a new promotional banner, you’re editing 50 layouts instead of one template. Use shared layouts with category-specific content, not category-specific structures.
3. Ignoring mobile layout behavior
A four-column image grid looks great on desktop and terrible on mobile. Blocks stack vertically by default, and some block types don’t translate well to narrow screens. Always preview Shopping Experiences pages on mobile before publishing.
4. Overloading pages with product blocks
Each product listing block, product slider, and cross-selling block triggers product data queries. A page with six product sliders, each loading 20 products, is loading 120 products’ worth of data. This affects page speed, especially on first load before caching kicks in.
5. Not setting up content workflows
Shopping Experiences doesn’t have built-in approval workflows. A content manager can edit a live layout and the changes appear immediately. For teams where content needs review before publishing, establish an external workflow (duplicate layout, edit copy, get approval, swap assignment) or use a plugin that adds approval functionality.
Frequently Asked Questions
Can Shopping Experiences replace a headless CMS?
For most ecommerce businesses, yes. Shopping Experiences provides layout building, content management, translation support, and server-side rendering that covers standard content needs. It replaces a headless CMS when your content is primarily commerce-related (category content, landing pages, promotional pages) and managed by a small team. It doesn’t replace a headless CMS for organizations with large editorial teams, complex content workflows, or content that needs to serve multiple non-ecommerce frontends.
How many custom blocks do I typically need?
Most implementations need 5-15 custom blocks beyond Shopware’s built-in set. Common custom blocks include: testimonial/review carousel, team member grid, FAQ accordion, pricing comparison table, feature highlight with icon, call-to-action with form, and brand/partner logo grid. The exact number depends on your design system and content patterns.
Can I use Shopping Experiences with a headless frontend?
Yes. The Store API exposes all layout data as JSON. A headless frontend (Next.js, Nuxt.js, etc.) can request the layout, parse the section/block/element tree, and render it using custom frontend components. Each Shopware block type maps to a frontend component. This is how Shopware Frontends (the official headless toolkit) handles Shopping Experiences.
Do Shopping Experiences pages affect page speed?
They can. A well-built Shopping Experiences page with optimized images, reasonable block count, and proper caching performs well. A page with multiple product sliders, unoptimized images, embedded videos, and custom JavaScript blocks can be slow. Performance depends on implementation quality, not the Shopping Experiences system itself.
Can I A/B test Shopping Experiences layouts?
Not natively within Shopware. However, you can create two layout variants and assign them through the Rules Engine based on customer segments, or use external A/B testing tools (Google Optimize successor, VWO, Optimizely) that modify the rendered page. Some Shopware plugins add native A/B testing for layouts.
How do Shopping Experiences handle dynamic content?
Product listing blocks, product sliders, and cross-selling blocks pull live data – current pricing, stock status, and product attributes are rendered at page load (or cache refresh). Text and image blocks are static and change only when edited. For dynamic non-product content (real-time data feeds, user-generated content), custom blocks with API calls are needed.
Can non-technical users manage Shopping Experiences?
Yes, that’s a primary design goal. The drag-and-drop editor in the admin panel allows content managers to create and edit pages without code. Adding blocks, changing text, uploading images, and rearranging sections are all visual operations. Custom blocks should be designed with the same ease of use – configurable through form fields, not code editing.
Is there a limit to how many Shopping Experiences pages I can create?
No hard limit. Shopware can handle hundreds or thousands of layouts. The practical limit is management complexity – having 500 unique layouts becomes difficult to organize and maintain. Use naming conventions, template-based creation, and inherited assignments to keep the layout count manageable.
Getting Started
If you’re already on Shopware 6, Shopping Experiences is available out of the box. Start with:
- Audit your current pages. Identify which category pages, landing pages, and content pages would benefit from Shopping Experiences layouts.
- Design 3-5 template layouts. Create base layouts for your most common page types. Don’t try to build unique layouts for every page from the start.
- Identify custom block needs. Review your design system and identify content patterns that aren’t covered by built-in blocks. Build custom blocks for these patterns.
- Train your content team. The Shopping Experiences editor is intuitive, but training ensures consistent usage and prevents common mistakes.
- Measure performance. Monitor Core Web Vitals and page speed for Shopping Experiences pages. Optimize images, reduce block count, and configure caching as needed.
If you’re evaluating Shopware and Shopping Experiences is a factor in your decision, [talk to us about what’s possible]. We’ll show you real implementations and help you understand whether Shopping Experiences meets your content-commerce integration needs – or whether a headless CMS integration is the better path for your situation.