WordPress als modernes Storefront-Frontend: Der Build-Guide

Ist eine neue WooCommerce-Kampagnenseite eine Theme-Anpassung, ein Page-Builder-Drag oder eine Plugin-Installation? In einem klassischen WordPress-Stack ist es meistens alles drei gleichzeitig, und genau dort verlieren Storefront-Teams Wochen. Dieser Guide nimmt einen konkreten Blickwinkel: WordPress und WooCommerce als Datenquelle, darüber ein visuell bearbeitbares Frontend. So spielst du Storefront-Änderungen aus, ohne Theme-Fork und ohne neues Plugin für jede Anforderung. Eine breitere Options-Übersicht haben wir bereits veröffentlicht, sie ist unten verlinkt. Dieser Beitrag ist der Page-Builder-CMS-Build-Blickwinkel.

Die native Antwort: Block-Themes, WPGraphQL und Faust.js

WordPress rendert standardmäßig über PHP-Themes. Seit der Block-Editor mit WordPress 5.0 kam und Full Site Editing mit Block-Themes in 5.9 landete, komponieren Redakteure Seiten aus Gutenberg-Blöcken, und Page-Builder wie Elementor oder Divi legen ihre eigene visuelle Schicht obendrauf. Für Commerce bringt WooCommerce eigene Templates, Blöcke und Shortcodes mit.

Für ein Headless-Setup stellt WordPress-Core die REST-API bereit, das Plugin WPGraphQL ergänzt eine typisierte GraphQL-Schicht, und WooGraphQL erweitert sie um Produkte, Warenkörbe und Bestellungen. WooCommerce liefert zusätzlich die Store-API für Cart und Checkout. Auf der Frontend-Seite ist Faust.js das Framework, um ein headless WordPress Frontend mit Next.js gegen WPGraphQL zu bauen. Forkst du den Starter, bekommst du ein lauffähiges React-Frontend, das WordPress-Inhalte liest, ohne die API zurückentwickeln zu müssen.

Für ein Team mit dauerhafter Frontend-Kapazität ist das eine faire Basis, ähnlich wie andere Plattformen ein Boilerplate ausliefern statt eines fertigen Storefronts.

Was der Theme- und Plugin-Build wirklich kostet

Die Rechnung kommt in der Produktion, egal ob du beim klassischen Theme plus Buildern bleibst oder ein Faust.js-Frontend forkst:

• Jede Kampagnenseite und jeder Banner-Tausch ist eine Template-Änderung, ein Builder-Eingriff oder ein Plugin, Deployment inklusive.
• Plugin-Wildwuchs ist real: ein mittelgroßer WooCommerce-Shop betreibt oft 30 bis 50 Plugins, jedes davon eine Wartungs-, Performance- und Sicherheitsfläche.
• Page-Builder-Markup aus Elementor, Divi oder WPBakery bläht das DOM auf und zieht die Core Web Vitals nach unten, was dann einen eigenen Tuning-Sprint braucht.
• Ein Faust.js-Fork trägt die übliche Bring-your-own-Frontend-Last: Next.js-Upgrades, WPGraphQL-Schema-Änderungen und Security-Patches landen in deinem Backlog, nicht bei WordPress.
• Marketing kann ein Headless-Storefront nicht gefahrlos anfassen. Ohne Editor wird jede Änderung zum Engineering-Ticket.
• Mehrsprachigkeit heißt meist noch ein Plugin, WPML oder Polylang, plus ein zweiter Durchgang, um das Locale-Routing ins Frontend zu verdrahten.

Das ist kein WordPress-spezifischer Fehler, es steckt in jedem CMS-First-Stack mit angeflanschtem Storefront. Trotzdem lohnt es sich, diese Kosten früh einzupreisen.

Laioutr als gemanagte Schicht

Laioutr sitzt als composable Frontend-Layer über WordPress und WooCommerce, ohne die Redaktions-Ebene anzufassen. WordPress bleibt dein Content-Rückgrat: Beiträge, Seiten, Rollen, Mediathek und Redaktions-Workflows laufen weiter dort, wo sie hingehören. Unser Orchestr-Datenlayer spricht mit WPGraphQL, oder der REST- und Store-API, holt Seiten, Blöcke, Navigation und WooCommerce-Produktdaten und mappt sie auf unser einheitliches Component-Schema. Das sind dieselben Daten, die ein Faust.js-Frontend konsumieren würde, nur ohne dass dein Team die Verbindung pflegt.

Das Frontend verhält sich dann wie ein Composable Visual Page Builder: Marketer komponieren Storefront-Seiten aus geprüften Komponenten, statt Plugins und Builder-Widgets zu stapeln. Die Plattform-Seite, CI/CD, Hosting, Framework-Upgrades und Security-Patches, ist Frontend as a Service, nicht die Sprint-Arbeit deines Teams.

Wie die technische Anbindung funktioniert

Orchestr fragt WordPress einmal ab und normalisiert das Ergebnis für jede View. Ein einziger WPGraphQL-Request kann Content und Katalog zugleich tragen:

query StorefrontData {
  pages(first: 20) {
    nodes { title uri content }
  }
  products(first: 12) {
    nodes {
      name
      ... on SimpleProduct { price stockStatus }
      image { sourceUrl }
    }
  }
}

Orchestr mappt pages auf Content-Komponenten und products auf PDP- und PLP-Komponenten, egal ob WooCommerce, ein separates Headless-Commerce-Backend oder ein reiner Content-Fall dahinter liegt. Custom-Resolver binden WordPress-spezifische Felder wie ACF-Gruppen (Advanced Custom Fields) oder Custom Post Types an, statt sie in einem Theme-Template nachzubauen. Navigation, Seitenbaum und Mehrsprachigkeit existieren bereits als Komponenten.

Wer macht was: Redaktion, Engineering und Marketing

Redakteure arbeiten weiter im vertrauten WordPress-Admin, ohne Umschulung. Engineering definiert Komponenten, verdrahtet WordPress- und WooCommerce-Daten über Orchestr und erweitert die Library für Projektbedarf wie Custom Post Types oder Freigabe-Schritte. Marketing arbeitet parallel im Studio-Editor: Kampagnenseiten, Banner, Landingpages, ohne Pull Request und ohne auf ein Deploy-Fenster zu warten. Bei einem klassischen Theme-plus-Plugin-Build gibt es diese Trennung nicht, jede Änderung läuft über Code, einen Builder oder ein Plugin.

Welcher Weg passt: ein kurzer Vergleich

Build-Checkliste

• Liste die Storefront-Flächen, die Marketing besitzen soll: Kampagnenseiten, PDP-Struktur, Banner, Landingpages.
• Entscheide den Datenpfad: WPGraphQL plus WooGraphQL, oder die REST- und Store-API.
• Behalte WordPress als Redaktions-Rückgrat, migriere Inhalte nicht heraus.
• Mappe WordPress-spezifische Felder, ACF und Custom Post Types, einmalig auf Komponenten, über Orchestr.
• Setze ein Core-Web-Vitals-Budget und prüfe es gegen die aktuellen Builder-Seiten.
• Gib Marketing ein geprüftes Component-Set, kein rohes HTML, damit Brand und Accessibility halten.

Fazit

Ein klassisches Theme mit Page-Buildern, oder ein Faust.js-Fork, sind ehrliche Optionen für Teams mit dauerhafter Frontend-Kapazität. Für alle anderen behält Laioutr WordPress und WooCommerce als Datenquelle und übergibt Template-Wartung, die Deploy-Pipeline und Marketing-Self-Service an eine Frontend Management Platform, die genau dafür gebaut ist. Wenn du zuerst die volle Bandbreite der Ansätze willst, lies unsere Options-Übersicht zum headless WordPress Frontend, und den parallelen Fall für ein anderes CMS im TYPO3-Headless-Storefront-Guide. Die WordPress-Anbindung im Detail steht auf der WordPress-Page-Builder-Seite.