# Headless-Shop-Agentur für Händler, deren Frontend mehr können soll als das Standard-Theme

Headless-Shops für Händler: eigene Storefront mit Astro oder Next.js, Shop-Backend über GraphQL oder API-Schicht, Checkout, Zahlung, Inhalte, Betrieb.

**Kurz beantwortet:** Headless-Shops entwickelt e-companion, ansässig in Oberasbach westlich von Nürnberg: eigene Storefronts mit Astro oder Next.js, die per Schnittstelle mit Magento, Shopware oder einem anderen Shop-Backend arbeiten, auf Wunsch über den ecompanion Hub als vermittelnde Schicht, dazu Checkout, Zahlungsanbindung, Inhalte und Betrieb. Ein Beispiel ist reetro.com, dessen statisch ausgelieferte Astro-Storefront Warenkorb und Bestellung ausschließlich über GraphQL an Magento 2 übergibt.

## Für wen ein Headless-Shop passt

Headless ist kein Upgrade, das jeder Shop irgendwann braucht, sondern eine Architekturentscheidung mit Folgekosten. Sie zahlt sich aus, wenn das Frontend Dinge leisten soll, die ein Standard-Theme nur mit Mühe hergibt. Typische Ausgangslagen:

- **Viel redaktioneller Inhalt neben den Produkten.** Magazin, Designer- oder Herstellerporträts, Ratgeber und Themenseiten sollen gleichberechtigt neben dem Katalog stehen und schnell laden, ohne dass jede Seite durch das Template-System des Shops muss.
- **Mehrere Oberflächen aus einem Bestand.** Neben dem Webshop sollen eine Marketing-Site, eine App oder ein Terminal im Laden auf dieselben Produkte, Preise und Bestände zugreifen.
- **Eine Gestaltung, die sich vom Theme lösen muss.** Wenn Markenauftritt und Bedienung so individuell sind, dass ein Theme fast vollständig überschrieben würde, ist ein eigenes Frontend oft der ehrlichere Weg.
- **Ein Backend, das bleiben soll, und ein Frontend, das sich ändern darf.** Bestellabwicklung, Steuern und Anbindungen laufen gut, die Oberfläche soll trotzdem in kurzen Abständen weiterentwickelt werden.
- **Absehbarer Wechsel des Shopsystems.** Steht ein Umzug des Backends im Raum, entkoppelt eine API-Schicht die Storefront davon, sodass Kunden vom Wechsel möglichst wenig merken.

Gegen Headless sprechen ein kleines Sortiment ohne eigenen Redaktionsbereich und ein Team, das keine zwei Anwendungen betreuen lassen möchte. Dann ist ein gut eingerichteter Standard-Shop wirtschaftlicher. Welche Systeme wir dafür einsetzen, lesen Sie auf den Seiten [WooCommerce-Agentur](/woocommerce-agentur), [Shopware-Agentur](/shopware-agentur) und [Magento-Agentur](/magento-agentur).

## Drei Muster für die Verbindung von Frontend und Shop

Bevor programmiert wird, steht die Frage, wie Frontend und Backend miteinander reden. In unseren Projekten kommen drei Muster vor, die sich auch kombinieren lassen.

**Direkte Verbindung.** Die Storefront fragt die Schnittstelle des Shopsystems selbst ab. Bei reetro.com ruft der Browser den GraphQL-Endpunkt von Magento 2 unmittelbar auf, ohne vermittelnde Instanz. Das ist der kürzeste Weg und hält die Zahl der Systeme klein. Dafür hängt das Frontend eng am Datenmodell des Backends.

**API-Schicht dazwischen.** Eine eigene Anwendung kapselt das Shopsystem und bietet dem Frontend eine schlanke, auf den Shop zugeschnittene Schnittstelle. Zugangsschlüssel für Verwaltungs-APIs bleiben so auf dem Server, und Logik wie die Anlage von Kundenkonten oder der Abgleich von Bestellungen liegt an einer Stelle. Wird das Backend später ausgetauscht, muss in erster Linie diese Schicht angepasst werden. Bei mid-centurydesigns.com übernimmt der ecompanion Hub diese Rolle vor Shopware 6.7.

**Getrennte Frontends für Marketing und Shop.** Inhaltsseiten und Storefront werden als zwei Anwendungen gebaut, jede mit der Technik, die zu ihr passt. Bei mid-centurydesigns.com sind das eine statische Astro-Site für Journal und Landingpages sowie eine Storefront auf Next.js 16 für den Verkauf.

## Leistungen im Detail

### Architektur und Systemwahl

Am Anfang steht eine schriftliche Architekturskizze: welches Backend führt, welches der drei Muster gilt, welche Daten live abgefragt und welche beim Build eingebaut werden, wo Inhalte gepflegt werden. Diese Entscheidungen bestimmen später Aufwand und Betriebskosten stärker als die Wahl des Frameworks.

### Storefront-Entwicklung mit Astro oder Next.js

Für kataloglastige Shops mit viel Inhalt bauen wir die Storefront mit Astro. Seiten entstehen beim Build, interaktive Teile wie Warenkorb und Kasse laufen als React-Komponenten, die nur dort Code laden, wo sie gebraucht werden. Verhält sich der Shop eher wie eine Anwendung, mit Kundenkonto, Filtern über große Sortimente und viel Logik auf der Client-Seite, ist Next.js die bessere Wahl. Grundlagen zu Astro erläutert die Seite [Astro-Agentur](/astro-agentur).

### API-Schicht und Hub

Wo eine Zwischenschicht sinnvoll ist, kommt der Hub zum Einsatz, aus der Suite ecompanion.io, die wir selbst entwickeln. Er vereint ein PIM, ein Warenwirtschaftsmodul und einen Channel Connector, gebaut mit Fastify, PostgreSQL und Drizzle, und hält Produktdaten mit Etsy, Kaufland, Magento, Shopware und WooCommerce synchron, jeweils im vollen Sync-Zyklus. Welche Rolle er vor einem Shop-Backend übernimmt, zeigt eines der Projekte weiter unten.

### Checkout und Zahlung

Der Bestellabschluss ist im Headless-Shop der heikelste Teil, weil hier Frontend, Backend und Zahlungsanbieter zusammenspielen müssen.

Bei mid-centurydesigns.com laufen die Zahlungen über Stripe, genutzt werden Payment Intents und Webhook-Benachrichtigungen; Bestellbestätigungen verschickt AWS SES.

Bei reetro.com übernimmt Braintree die Zahlung per Kreditkarte, PayPal und 3DS. Transaktionsmails gehen dort ebenfalls über AWS SES, abgesichert mit DKIM, SPF und DMARC.

### Inhalte und Redaktion

Für die Pflege von Inhalten braucht ein Headless-Shop eine eigene Lösung, denn das CMS des Shopsystems ist vom Frontend abgekoppelt. Wir arbeiten mit drei Varianten: Inhalte als Dateien im Repository, unsere Plattform wook.studio als Editor mit festen Schemas oder eine automatisierte Content-Pipeline, die neue Beiträge selbstständig veröffentlicht. Setzen Sie bereits ein Headless-CMS ein, prüfen wir, wie es sich anbinden lässt.

### Auswertung

Weil das Frontend neu entsteht, muss auch die Messung neu eingerichtet werden. Wir legen gezielt Events an, etwa für Klicks auf Produkte, Aktionen im Warenkorb und die einzelnen Schritte der Kasse, und werten sie in unserer App Stats aus.

### Betrieb

Nach dem Livegang betreuen wir auf Wunsch Hosting und Wartung des Shops. Updates von Frontend und Backend stimmen wir dann aufeinander ab, damit eine neue Version auf der einen Seite die andere nicht überrascht.

## Technik und Architektur

**Schnittstellen der gängigen Backends.** Magento 2 bietet eine GraphQL-API, über die ein Frontend den Weg vom leeren Warenkorb bis zur fertigen Bestellung steuern kann. Shopware 6 trennt eine Store API für Frontends von einer Admin API für Verwaltungsaufgaben und bringt mit Shopware Frontends nach aktuellem Stand einen eigenen Baukasten auf Basis von Vue.js und Nuxt mit. WooCommerce stellt neben der REST API eine Store API für Warenkorb und Kasse bereit. Shopify bietet nach aktuellem Stand die Storefront API und mit Hydrogen ein eigenes React-Framework, das sich auf Shopifys Hosting Oxygen betreiben lässt.

**Statisch, live oder beides.** Produktseiten lassen sich beim Build als HTML erzeugen, was sie schnell und robust macht. Preise und Bestände ändern sich aber häufiger als Beschreibungen. Deshalb wird je Datenfeld entschieden, ob es beim Build eingebaut, im Browser nachgeladen oder bei Next.js über zeitgesteuertes Neuerzeugen einzelner Seiten aktualisiert wird.

**SEO muss mitgebaut werden.** Was ein Shopsystem im eigenen Theme mitliefert, entsteht im Headless-Frontend neu: Titel und Beschreibungen, kanonische Adressen, Sitemap, strukturierte Daten für Produkte, Weiterleitungen alter Adressen und saubere Sprachversionen.

Wie das bei Sprachversionen aussieht, zeigt reetro.com: Die Storefront bildet Deutsch und Englisch über eigene Routen ab.

**Vorschau für Redaktion.** Im Standard-Shop sieht die Redaktion eine Änderung sofort im Theme. Im Headless-Aufbau muss eine Vorschau eigens vorgesehen werden, sonst arbeiten Redakteure blind.

**Zwei Deployments.** Frontend und Backend haben eigene Versionen und eigene Release-Zyklen. Ändert sich eine Schnittstelle im Backend, muss das Frontend mitziehen. Eine API-Schicht mit stabiler eigener Schnittstelle fängt solche Änderungen ab.

Wie sich Headless und klassische Shops wirtschaftlich gegeneinander abwägen lassen, beschreibt unser Artikel [Headless Magento oder Shopware](/headless-magento-oder-shopware). Den Schritt zu modularen Architekturen mit CMS, CRM und ERP behandelt der Beitrag zu [Composable Commerce im Mittelstand](/composable-commerce-mittelstand-shop-cms-crm-erp).

## Ablauf eines Headless-Projekts

1. **Ausgangslage.** Sortiment, vorhandenes Shopsystem, Kanäle, Inhalte, angebundene Systeme und die Gründe, warum der bisherige Aufbau nicht mehr reicht.
2. **Architekturskizze.** Muster, Datenflüsse und Zuständigkeiten je System, mit einer ehrlichen Einschätzung, ob sich Headless für Ihr Vorhaben lohnt.
3. **Angebot.** Umfang und Preis, auf Wunsch als Festpreisangebot für den vereinbarten Umfang.
4. **Schnittstelle zuerst.** Wir legen fest, welche Daten das Frontend in welcher Form bekommt, bevor die Oberfläche entsteht. Das verhindert, dass das Design an Daten scheitert, die das Backend gar nicht liefert.
5. **Frontend und Checkout.** Umsetzung der Storefront, Anbindung von Zahlung und Mails, Einrichtung der Events für die Auswertung.
6. **Umstellung.** Alte Adressen werden per 301-Weiterleitung auf neue Entsprechungen geführt, danach wird die Domain umgestellt.
7. **Betrieb.** Auf Wunsch bleiben wir nach dem Start für Hosting, Wartung und Ausbau zuständig.

## Was es kostet

Für Headless-Shops gibt es kein Paket von der Stange, weil Backend, Muster und Zahl der Frontends den Aufwand bestimmen. Zur Einordnung: Das Paket Digital Dominanz für individuelle Web-Applikationen sowie die Anbindung an Shops und externe Schnittstellen beginnt bei 2.890 €. Shop Enterprise mit Adobe Commerce (Magento), Multi-Store, Mehrsprachigkeit und Anbindung einer Warenwirtschaft gibt es ab 4.890 €; der Wartungsvertrag ist darin schon enthalten.

Den Preis treiben vor allem:

- **Zahl der Frontends**, etwa Marketing-Site und Storefront getrennt
- **API-Schicht** ja oder nein
- **Checkout-Logik**, Zahlarten und Sonderfälle wie Gastbestellungen mit späterer Kontoanlage
- **Inhaltsquellen** und die gewünschte Redaktionsvorschau
- **Sprachen** und die Übernahme bestehender Adressen
- **Marktplätze**: ab 490 € für jeden weiteren Marktplatz

Laufend kommen bei Shops Hosting und Domain ab 29 € monatlich sowie Wartung & Pflege ab 79 € monatlich hinzu; Shop Enterprise deckt die Wartung über den enthaltenen Wartungsvertrag bereits ab. Einen Stundensatz nennen wir nicht; der passende Satz für die jeweilige Tätigkeit steht im Angebot. Alle Pakete stehen auf unserer [Paketseite](/produkte/webseiten-shops).

## Referenzen

**reetro.com: direkte Verbindung zu Magento 2.** Verkauft werden Print-on-Demand-Dekorartikel im Stil von Retro und Mid-Century, mehr als 235 Produkte in fünf Kategorien. Astro 5 erzeugt die Storefront als statische Seiten; Warenkorb und Kasse kommen als React-19-Islands hinzu. Den gesamten Bestellweg wickelt sie über typisierte GraphQL-Mutations ab, beginnend mit `createEmptyCart` und endend mit `placeOrder`; Magento 2 bleibt dabei führendes System für die Bestellungen. Journal-Beiträge und Themenseiten entstehen über eine KI-gestützte Automation täglich neu.

**mid-centurydesigns.com: zwei Frontends hinter einer API-Schicht.** Für den Händler ausgesuchter Vintage-Stücke aus der Mid-Century-Ära laufen eine Marketing-Site auf Astro mit Journal, Landingpages sowie Porträts von Designern und eine Verkaufsoberfläche auf Basis von Next.js 16 nebeneinander. Keines der beiden Frontends greift direkt auf Shopware 6.7 zu, beide arbeiten ausschließlich mit dem ecompanion Hub. Stripe verarbeitet die Zahlungen im Live-Betrieb, Bestellbestätigungen gehen über AWS SES hinaus, und Kundenkonten entstehen auf Seiten des Hubs aus Gastbestellungen. So lassen sich Marketing, Storefront und Commerce-System unabhängig voneinander weiterentwickeln.

**ecompanion.io: unsere eigene Suite als Fundament.** Die Software-Suite entwickeln und nutzen wir produktiv im Eigenbetrieb. Neben dem Hub gehören ein SEO-Dashboard mit Auswertung der Sichtbarkeit in KI-Suchen und die Content Machine dazu, die Inhalte nach einem Review-Gate in Astro-, WordPress- und Typo3-Websites sowie auf Facebook, Instagram, LinkedIn und TikTok ausspielt.

Weitere Shops und Websites finden Sie unter [Referenzen](/referenzen). Unseren Praxisbericht über den Weg von Shopify zu Headless lesen Sie im Artikel [Von Shopify zu Headless](/von-shopify-zu-headless).

## Zusammenarbeit

Unser Standort ist Oberasbach westlich von Nürnberg; Headless-Projekte übernehmen wir unabhängig davon, wo Ihr Unternehmen sitzt. Abstimmungen laufen per Video, in Franken besuchen wir Sie auf Wunsch auch vor Ort. Architektur und Code bespricht Inhaber Maik Boche persönlich mit Ihnen.

Alle Leistungen rund um Shops, Produktdaten und Marktplätze bündelt der Bereich [Commerce](/commerce). Beschreiben Sie uns Ihren Shop und Ihr Vorhaben über das [Anfrageformular](/kontakt), oder wählen Sie für ein erstes Gespräch 0173 516 1038.

## Häufige Fragen

### Was bedeutet headless?

Der Begriff beschreibt Software ohne festen Kopf, also ohne eigene, fest verbundene Oberfläche. Ein Headless-System verwaltet Daten und Abläufe und stellt sie über Programmierschnittstellen bereit, meist als REST oder GraphQL. Wie die Inhalte am Ende aussehen und auf welchem Gerät sie erscheinen, entscheidet ein separat entwickeltes Frontend, etwa eine Website, eine App oder ein Bildschirm im Ladengeschäft.

### Was ist Headless Commerce?

Ein Aufbau, bei dem das Shopsystem nur noch im Hintergrund arbeitet: Katalog, Preise, Warenkorb, Bestellungen und Kundenkonten liegen dort, sichtbar werden sie über eine eigene Storefront. Beide Teile tauschen sich über APIs aus. So lässt sich die Oberfläche frei gestalten und unabhängig vom Shop weiterentwickeln, während Zahlung, Bestandsführung und Bestellabwicklung im bewährten Backend bleiben.

### Welche Headless-CMS gibt es, und welche Beispiele sind verbreitet?

Als Cloud-Dienst werden zum Beispiel Contentful, Storyblok und Sanity angeboten, zum Selbstbetrieb auf eigenen Servern eignen sich quelloffene Systeme wie Strapi, Directus oder Payload. Auch WordPress lässt sich über seine REST API als Inhaltsquelle für ein eigenes Frontend nutzen. Unsere Plattform wook.studio pflegt Inhalte als typisierte Collections und liefert sie unter anderem als JSON oder Markdown aus.

### Welche Aufgaben übernimmt eine E-Commerce-Agentur?

Planung, Aufbau und Betreuung von Onlineshops: Wahl des Shopsystems, Gestaltung, Einrichtung von Produkten, Zahlarten und Versand, Anbindung von Warenwirtschaft, Buchhaltung und Marktplätzen, danach Hosting, Updates und Weiterentwicklung. Bei Headless-Projekten kommen die Entwicklung der Storefront und die Abstimmung der Schnittstellen zwischen Frontend und Backend hinzu.

### Worin unterscheiden sich Headless und Composable Commerce?

Headless trennt zunächst nur Frontend und Backend. Composable Commerce geht weiter: Der Shop wird aus mehreren spezialisierten Diensten zusammengesetzt, etwa einem PIM für Produktdaten, einer eigenen Suche, einem CMS und einem Zahlungsdienst, die über APIs zusammenarbeiten. Oft fällt dabei das Kürzel MACH für Microservices, API-first, Cloud-native und Headless. Jeder composable Shop ist headless, aber nicht jeder Headless-Shop ist composable.

### Wem gehört der Code eines Headless-Shops?

Was wir für Sie entwickeln, also Storefront, Theme, eigene Erweiterungen und Frontend-Code, übergeben wir Ihnen, wenn das Hosting bei uns endet. Software aus unseren Plattformen, zum Beispiel der Hub von ecompanion.io, bleibt bei uns, während Sie Ihre Inhalte und Daten daraus bekommen. Läuft das Backend auf Shopify, gibt es dort keinen eigenen Server-Code, der übergeben werden könnte.

---
Quelle: https://e-companion.de/headless-shop-agentur · e-companion UG, Oberasbach bei Nürnberg · Kontakt: https://e-companion.de/kontakt