5,0 Sterne auf OMR Reviews. Serverstandort EU. BFSG-ready. Im Einsatz mit DACH-OXID-Partnern.
5,0 Sterne auf OMR Reviews. Serverstandort EU. BFSG-ready. Im Einsatz mit DACH-OXID-Partnern.
Headless für OXID trennt das Frontend, alles was Ihre Kundinnen und Kunden sehen, vom OXID-Backend mit Produkten, Account-Selection, Permission-Sets und Bestellprozessen. Statt Flow Theme oder Wave wird das Frontend über das OXID GraphQL StoreFront-Modul angebunden und kann frei gestaltet werden, ohne Smarty-Theme-Limits und mit voller Performance-Kontrolle.
OXID verwaltet weiter Produkte, Account-Selection, Permission-Sets, kundenspezifische Sortimente, VAT-Workflows, Bestellungen und Checkout. Sie nutzen die OXID-Admin unverändert, mit allen B2B-Modulen der Enterprise Edition.
Sie haben vier etablierte Optionen: Flow Theme (Default Smarty), Wave Theme (modernere Variante, ebenfalls nicht headless), Custom Build (Next.js, Nuxt mit OXID GraphQL StoreFront) oder eine Frontend Management Platform wie Laioutr.
Kein Datenduplikat, keine Sync-Konflikte. Laioutr spricht direkt mit der OXID GraphQL StoreFront API, inklusive aller B2B-Endpoints für Account-Selection, Permission-Sets und kundenspezifische Sortimente.
OXID hat keinen offiziellen Headless-Framework wie FastStore oder PWA Studio. Stattdessen die Wahl zwischen klassischen Themes und Custom-Build mit GraphQL StoreFront. Vier Optionen sind im Markt etabliert. Hier ist, wo sich jede für OXID-Käufer lohnt.
Smarty-basiert, mit OXID standardmäßig mitgeliefert, kein Headless. Sinnvoll für Bestands-Setups, die nicht migrieren wollen, oder für Greenfield-Projekte mit minimalem Customizing-Bedarf. Performance- und Modernisierungs-Limits sind real.
Modernere Theme-Variante, ebenfalls Smarty-basiert. Sinnvoll, wenn Sie Flow ablösen wollen, aber noch nicht headless gehen wollen. Bessere UI als Flow, aber dieselben Architektur-Limits.
Maximale Kontrolle, höchster Aufwand. Sechs- bis neunmonatige Build-Phase plus dauerhafte Wartung mit zwei bis drei Engineers. Sinnvoll für Enterprise-Teams mit dediziertem Frontend-Engineering und hochspezifischen B2B-Anforderungen.
Frontend Management Platform mit visuellem Builder, 70+ Komponenten inklusive B2B-Bausteinen, EU-Hosting und Multi-Backend-Support. Sinnvoll, wenn Sie schnell live wollen, B2B-Standardfunktionen out of the box brauchen, und Marketing-Velocity ohne Engineering-Sprint pro Page brauchen.
OXID-B2B liefert die kompletten Workflows. Laioutr ruft die GraphQL StoreFront API direkt auf und rendert Account-spezifische Frontends mit Permission-Logic, kundenspezifischen Preislisten und individuellen Sortimenten.
Bestehender Smarty-Theme-Stack soll abgelöst werden, ohne dass das OXID-Backend angefasst wird. Migration in Phasen, ohne dass die Bestand-Performance leidet.
Mehrere Marken auf einer OXID-EE-Instanz, mit eigenen Frontends, eigenen Domains, gemeinsamem Backend und gemeinsamer B2B-Konfiguration.
OXID-Multi-Country mit lokalisierten Preislisten, VAT-Workflows und Sprachvarianten. Frontend in Studio konfiguriert, ohne pro Markt einen Custom-Build aufzusetzen.
Sie haben einen Custom-Build mit Next.js und OXID GraphQL StoreFront laufen, das Engineering-Team ist ausgedünnt. Migration auf eine FMP, ohne den OXID-Backend anzufassen.
Neues OXID-Projekt, frischer Start. Mit Laioutr-Themes und der UI-Bibliothek geht das in Wochen produktiv, statt sechs Monate für Custom-Build mit OXID GraphQL StoreFront zu investieren.
Custom Build ist der häufigste Weg zu OXID-Headless: das offizielle GraphQL StoreFront-Modul plus ein eigenes Frontend in Next.js, Nuxt oder Vue Storefront. Laioutr ist eine vollständige Frontend Management Platform mit visuellem Builder, Komponenten-Bibliothek und Multi-Backend-Support. Beide funktionieren mit OXID. Wer maximale Code-Kontrolle und ein dediziertes Frontend-Team will, hat mit Custom Build die flexibelste Lösung. Wer Marketing-Velocity, B2B-Komponenten und planbare TCO will, ist mit Laioutr produktiver.
Unterschiede vergleichen | ||
|---|---|---|
Builder und Komponenten Was Sie aus der Box bekommen, mit Fokus auf B2B und DACH-Mittelstand. | ||
Visueller Page Builder Drag-and-Drop-Editor für Marketing- und Content-Teams. | Inklusive (Studio) Live-Preview, komponentenbasiert | Nicht enthalten Reine Code-Entwicklung in Next.js |
B2B-Komponenten Vorgefertigte UI-Bausteine für Account-Selection, Permission-Sets, kundenspezifische Sortimente. | 70+ Komponenten B2B-Bausteine inkl. Permission-UI | Selbst bauen B2B-UI als Custom-Build pro Workflow |
Themes und Vorlagen Startpunkt für neue Storefronts ohne Greenfield-Aufwand. | Vorgefertigte Themes Sofort einsatzbereit, voll erweiterbar | Greenfield Storefront komplett selbst designen |
Hosting Wo das Frontend ausgeliefert wird und wer es betreibt. | Inklusive (EU-CDN) Laioutr Cloud, kein separater Deploy | Selbst hosten Vercel, AWS, Hetzner, eigene Infrastruktur |
Architektur und OXID-Integration Wie das Frontend das OXID-Backend nutzt und wie viel Eigenleistung nötig ist. | ||
Backend-Flexibilität Welche E-Commerce-Backends sich anbinden lassen. | Multi-Backend OXID, Shopware, commercetools, weitere | OXID-spezifisch Code ist auf OXID-Schema zugeschnitten |
OXID-API-Anbindung Wie das Frontend mit dem OXID-Backend kommuniziert. | GraphQL StoreFront Standard-Anbindung über offizielles Modul | GraphQL StoreFront Standard-Anbindung über offizielles Modul |
Performance und Core Web Vitals Wie viel Aufwand für Lighthouse-100-Niveau nötig ist. | Out of the box Lighthouse 100 als Default-Ziel | Manuelles Tuning Performance-Engineering durch Team |
BFSG und WCAG 3.0 Konformität mit Barrierefreiheitsstärkungsgesetz und WCAG 3.0. | Im Standard WCAG 3.0, BFSG, EN 301 549 | Eigenverantwortung Audit separat erforderlich |
Team und Wirtschaftlichkeit Wer mit der Plattform produktiv ist und was es Sie über die Zeit kostet. | ||
Lernkurve Wie schnell ein neues Teammitglied produktiv wird. | Niedrig Marketing onboardet in Tagen | Hoch Next.js, GraphQL, OXID-Schema |
Time-to-Launch Realistische Zeitspanne bis zum Live-Gang einer neuen Storefront. | Wochen Mit Themes und Komponenten | Monate 6 bis 9 Monate Build-Phase |
Ideales Team-Setup Wer mit der Plattform arbeiten kann und wer arbeiten muss. | Cross-funktional Marketing, Design und Dev gemeinsam | Engineering-only Next.js-Team mit OXID-Erfahrung |
Total Cost of Ownership Software plus Engineering plus Wartung über 3 bis 5 Jahre. | SaaS (planbar) Hosting und Komponenten inklusive Preise ansehen | Engineering-lastig Hohe Build- und Wartungs-Kosten |
Alle Daten basieren auf öffentlich verfügbaren Informationen, Erfahrungen aus Sales-Gesprächen mit DACH-E-Commerce-Brands sowie eigenen Plattform-Tests. Stand: April 2026. OXID-Funktionen können sich weiterentwickelt haben.
Sie haben ein dediziertes Next.js- oder Nuxt-Team mit OXID-API-Erfahrung (mindestens drei Engineers), Sie akzeptieren sechs- bis neunmonatige Build-Phasen, maximale Pixel-Level-Differenzierung ist strategisch wichtig, hochspezifische B2B-Workflows lassen sich nicht mit Standard-Komponenten abbilden, Engineering-Wartung über Jahre ist budgetär eingeplant. Klassischer Anwendungsfall: ein Industriegüter-Hersteller mit komplexem Konfigurator und dediziertem Frontend-Team.
Sie wollen Wochen statt Monate bis Go-live, Marketing soll eigenständig Seiten bauen, B2B-Standardfunktionen sollen out of the box verfügbar sein, Sie haben kein dediziertes Frontend-Engineering-Team, Total Cost of Ownership über 5 Jahre ist relevant, BFSG-Compliance ohne separates Audit gelöst sein muss. Klassischer Anwendungsfall: ein DACH-Mittelstand-B2B-Brand auf OXID, der modernisieren will, ohne ein Frontend-Engineering-Team aufzubauen.