Was ist Headless Commerce? Wann es sich im E-Commerce lohnt

Headless Commerce wird oft als Weg dargestellt, einen sehr schnellen und flexiblen Shop zu erstellen. Das klingt gut, doch die bloße Trennung des Frontends von WooCommerce löst die Probleme mit Performance, SEO oder Verkäufen nicht automatisch.

In dieser Architektur nutzt der Kunde eine separate Anwendung, während Produkte, Preise und Bestellungen von einem im Hintergrund laufenden System bearbeitet werden. Das verschafft mehr Freiheit, bedeutet aber auch mehr Integrationen, Tests und Entwicklungsarbeit.

Für eine große B2B-Plattform, einen umfangreichen Konfigurator oder einen Shop, der über mehrere Kanäle läuft, kann Headless begründet sein. Für einen Shop mit einem Standardkatalog und einem typischen Checkout ist es oft ein unnötiger Kostenfaktor.

In diesem Leitfaden erklären wir, was Headless Commerce ist, wie es mit WooCommerce zusammenarbeiten kann und woran Sie erkennen, ob sich eine solche Investition für Ihren E-Commerce lohnt.

Kurz gesagt

Headless Commerce ist eine Architektur, bei der die dem Kunden angezeigte Schicht (das Frontend) vom Shop-System, z. B. WooCommerce, getrennt ist und eine API die Daten verbindet. Das verschafft mehr Freiheit und potenziell höhere Performance, behebt aber weder SEO noch Geschwindigkeit oder Verkäufe automatisch und erhöht die Kosten sowie die Komplexität der Umsetzung. Es lohnt sich bei großem Umfang, einem ungewöhnlichen Frontend oder mehreren Verkaufskanälen — nicht für einen typischen Shop.

Kurz zusammengefasst (TL;DR)

• Headless Commerce trennt das Frontend des Shops vom System, das Produkte, Kunden und Bestellungen verwaltet.
• WooCommerce kann weiterhin als Verkaufs-Engine arbeiten, doch das Aussehen des Shops erstellt eine separate Anwendung.
• Die Lösung verschafft mehr Kontrolle über UX, Performance und Integrationen, garantiert aber weder einen schnellen noch einen bei Google gut sichtbaren Shop.
• Die meisten für den Kunden sichtbaren Funktionen müssen über eine API mit dem Backend verbunden werden.
• Headless ist vor allem bei einem ungewöhnlichen Verkaufsprozess, mehreren Kanälen oder einem großen Projektumfang sinnvoll.
• Für die meisten kleinen und mittleren Shops ist ein klassisches oder hybrides WooCommerce einfacher zu pflegen.

Was ist Headless Commerce?

Headless Commerce ist eine Architektur, bei der das Aussehen des Shops und der für den Kunden sichtbare Teil vom System getrennt sind, das den Verkauf abwickelt.

Ganz einfach gesagt:

• das Frontend ist der für den Kunden sichtbare Teil, zum Beispiel Kategorien, die Produktseite und der Warenkorb;
• das Backend ist das System, das Produkte, Preise, Bestellungen und Kunden verwaltet;
• die API ermöglicht den Datenaustausch zwischen dem Frontend und dem Backend.

Im klassischen WooCommerce ist WordPress gleichzeitig für das Administrationspanel, die Shop-Logik und die Erzeugung der für den Kunden sichtbaren Seiten zuständig. In einem Headless-Shop kann WooCommerce weiterhin Produkte speichern und Bestellungen bearbeiten, doch die Seite für den Kunden ist eine separate Anwendung. Sie kann zum Beispiel in Next.js, Astro oder Nuxt erstellt werden — das sind Frameworks, also Werkzeugsätze, die Entwickler zur Erstellung schneller Webanwendungen verwenden.

Wie funktioniert ein Headless-Shop in der Praxis?

Der Kunde nutzt ein separates Frontend, das Daten über eine API aus WooCommerce und anderen Systemen abruft.

Ein vereinfachtes Schema sieht so aus: Kunde → Frontend → API → WooCommerce → Zahlungen, Lager und Integrationen.

Der Kunde öffnet eine Produktseite. Das Frontend sendet eine Anfrage an WooCommerce und ruft den Produktnamen, die Beschreibung, die Bilder, den Preis, die Varianten und die Verfügbarkeit ab. Wenn der Kunde ein Produkt in den Warenkorb legt, übermittelt das Frontend diese Information an die Shop-Engine. WooCommerce kann dann den Rabatt, die Steuer, die Versandkosten und den Bestellwert neu berechnen.

WooCommerce kann für die Produktdatenbank, Varianten und Attribute, Preise und Aktionen, Lagerbestände, Rabattgutscheine, Steuern, Kunden, Bestellungen, einen Teil der Zahlungs- und Versandlogik sowie für Integrationen mit externen Systemen zuständig sein.

Ein separates Frontend kann die Startseite, das Menü, die Kategorien, die Produktseite, die Suche, das Filtern, den Warenkorb, den Checkout, das Kundenkonto und die für Google sichtbaren Inhalte übernehmen. In der Praxis verläuft die Grenze nicht immer genau an derselben Stelle — manche Unternehmen belassen den Checkout im klassischen WooCommerce und bauen nur den Produktkatalog und die Präsentationsschicht separat.

Technische Abkürzungen an einem Ort

Abkürzung oder Begriff	Was es in der Praxis bedeutet
ERP	Ein System zur Unternehmensverwaltung, z. B. Preise, Lager, Rechnungen und Bestellungen
PIM	Eine Datenbank mit Produktinformationen wie Beschreibungen, Parametern und Bildern
CMS	Ein System zur Verwaltung von Inhalten, z. B. Seiten und Artikeln
CRM	Ein System, das Informationen über Kunden und Geschäftskontakte speichert
Endpoint	Eine konkrete API-Adresse, von der die Anwendung Daten abruft oder an die sie Daten sendet
Framework	Ein Werkzeugsatz, der zum Aufbau einer Webanwendung verwendet wird
Composable Commerce	Ein Shop, der aus mehreren unabhängigen und austauschbaren Systemen aufgebaut ist

Sie müssen diese Werkzeuge nicht technisch kennen. Wichtig ist zu verstehen, dass in einem größeren E-Commerce das Produkt, der Preis und der Lagerbestand aus verschiedenen Quellen stammen können.

Klassischer Shop, Headless oder eine hybride Lösung?

Zur Auswahl stehen drei Hauptmodelle: ein klassischer Shop, vollständiges Headless und eine hybride Lösung.

Modell	Wie es funktioniert	Wann es sinnvoll ist
Klassischer Shop	Ein System übernimmt Panel, Verkauf und Aussehen	Ein Standard-B2C- oder B2B-Shop
Headless	Backend und Frontend sind separate Anwendungen	Ungewöhnliche UX, großer Umfang, mehrere Kanäle
Hybrid	Nur ein Teil des Shops arbeitet als Headless	Ein schrittweiser Umbau oder das Ausgliedern einer einzelnen Funktion

Klassisches WooCommerce muss weder langsam noch schwer weiterzuentwickeln sein. Ein leichtgewichtiges Theme, ein bewährter Satz an Plugins, ein guter Server und eine korrekte Cache-Konfiguration können auch in einem umfangreichen Shop ausreichen. Der größte Vorteil ist das fertige Ökosystem — Sie installieren ein Plugin für Zahlungen, Versand oder Varianten und erhalten in der Regel sowohl die Logik als auch die für den Kunden sichtbaren Elemente.

Vollständiges Headless. Bei vollständigem Headless ist das gesamte Frontend eine separate Anwendung. WordPress und WooCommerce können unter einer anderen Adresse laufen und für den Käufer unsichtbar bleiben. Das verschafft die größte Freiheit, erfordert aber, dass Sie den Warenkorb, die Kundensitzung, den Checkout, die Zahlungen, das Benutzerkonto, die Analytik, das SEO, API-Fehler und den Veröffentlichungsprozess selbst übernehmen.

Eine hybride Lösung. Sie müssen nicht immer den ganzen Shop auf einmal trennen. Sie können zum Beispiel:

• einen separaten Produktkonfigurator erstellen;
• nur den Katalog umbauen;
• den klassischen WooCommerce-Checkout behalten;
• eine mobile Anwendung starten, die dieselbe Produktdatenbank nutzt;
• ein separates B2B-Panel vorbereiten;
• den Blog und die Informationsseiten in WordPress belassen.

Wie sieht Headless WooCommerce aus?

WooCommerce kann die Shop-Engine bleiben, während ein separates Frontend Daten daraus abruft und Bestellungen zurückgibt.

Der Shop-Inhaber kann weiterhin Produkte in WordPress hinzufügen, Preise ändern, Bestellungen einsehen, Gutscheine verwalten, Lagerbestände aktualisieren und ausgewählte Integrationen nutzen.

Das Frontend kommuniziert mit WooCommerce über mehrere Arten von APIs:

• WooCommerce REST API — dient unter anderem der Arbeit mit Produkten, Bestellungen und Kunden;
• WooCommerce Store API — übernimmt einkaufsbezogene Funktionen wie Produkte, den Warenkorb und den Checkout;
• WordPress REST API — stellt Beiträge, Seiten, Medien und andere Inhalte aus WordPress bereit;
• eigene Endpoints — werden verwendet, wenn der Shop nicht standardmäßige Daten oder Prozesse hat.

Die technischen Details, die Autorisierungsmethode und Beispiele der Kommunikation lassen sich besser separat besprechen. Wir vertiefen sie im Leitfaden WooCommerce API — was es ist und wofür es dient.

Ein Beispiel. Sie installieren ein Modul zur Auswahl eines Abholpunkts. In einem regulären WooCommerce erscheint die Karte automatisch im Checkout. Bei Headless kann sich herausstellen, dass:

1. das Plugin die Daten in WooCommerce speichert;
2. es sie nicht in der passenden API bereitstellt;
3. es keine fertige Komponente für das neue Frontend gibt;
4. die Karte und die Validierung selbst gebaut werden müssen.

Deshalb müssen vor der Bepreisung eines Projekts alle Funktionen des Shops inventarisiert werden, nicht nur die Anzahl der Unterseiten.

Welche Vorteile bringt Headless Commerce?

Headless verschafft mehr Kontrolle über das Frontend, die Art der Produktpräsentation und die Verbindung mehrerer Verkaufssysteme.

Mehr Kontrolle über die Performance. Ein separates Frontend kann ausgewählte Seiten vorab vorbereiten, im Cache speichern und dem Nutzer aus einer in der Nähe seines Standorts befindlichen Infrastruktur ausliefern. Dadurch muss nicht jeder Besuch den vollständigen Prozess der Seitenerzeugung durch WordPress auslösen. Das ist jedoch keine automatische Garantie für Geschwindigkeit — schweres JavaScript, zu große Bilder oder eine langsame API können dazu führen, dass ein Headless-Shop weiterhin schlecht funktioniert.

Mehr Freiheit bei der UX-Gestaltung. Headless bewährt sich, wenn ein Standard-Theme oder ein Block-System das Design einschränkt. Sie können zum Beispiel einen umfangreichen Konfigurator, eine 3D-Produktvisualisierung, einen ungewöhnlichen Prozess der Variantenauswahl, eine interaktive Produktseite, einen personalisierten B2B-Katalog, einen von früheren Antworten abhängigen Bestellprozess, eine eigene Suchmaschine oder eine an ein mobiles Programm erinnernde Anwendung vorbereiten. Solche Funktionen lassen sich auch im klassischen WooCommerce erstellen, doch ein separates Frontend verschafft den Entwicklern mehr Unabhängigkeit von der Theme-Struktur.

Ein Backend für mehrere Kanäle. Dieselbe Produktdatenbank kann einen B2C-Shop, ein B2B-Panel, eine mobile Anwendung, ein Panel für Vertriebsmitarbeiter, einen Bildschirm im Verkaufsraum, einen Konfigurator für Partner und mehrere regionale Versionen versorgen. Eine Änderung des Preises oder der Beschreibung kann an alle Kanäle weitergegeben werden, sofern die Datenquellen und die Synchronisation korrekt gestaltet sind.

Unabhängige Entwicklung von Frontend und Backend. Das Frontend-Team kann die Shop-Oberfläche weiterentwickeln, ohne direkt in das Bestellsystem einzugreifen. Sie können auch das Backend oder einen Teil der Integrationen ändern, ohne die gesamte für den Kunden sichtbare Schicht umzubauen. Dieser Vorteil hat vor allem in Unternehmen einen realen Wert, die das Produkt regelmäßig weiterentwickeln und über ein festes technisches Team verfügen.

Verbinden von Daten aus mehreren Systemen. In einem größeren E-Commerce sind die Daten oft verstreut — WooCommerce übernimmt Bestellungen, das ERP speichert Preise und Bestände, das PIM enthält Produktbeschreibungen und Parameter, das CMS ist für Ratgeber zuständig, und eine externe Suchmaschine übernimmt das Filtern. Das Frontend kann diese Informationen zusammenführen und dem Kunden als einen kohärenten Shop zeigen. Dieser Ansatz wird manchmal als Composable Commerce bezeichnet, also der Aufbau von E-Commerce aus unabhängigen Diensten, die bei Bedarf ausgetauscht werden können.

Welche Nachteile hat Headless Commerce?

Der größte Nachteil von Headless ist der Anstieg der Komplexität: Sie müssen mehrere Systeme pflegen und auf die Kommunikation zwischen ihnen achten.

Sie pflegen mehrere Anwendungen. In einem klassischen Shop aktualisieren Sie WordPress, WooCommerce, das Theme und die Plugins. Bei Headless kommen unter anderem ein separates Frontend, seine Bibliotheken und Abhängigkeiten, die Deployment-Plattform, API-Integrationen, ein zusätzlicher Cache, das Monitoring und der Prozess der Veröffentlichung einer neuen Version hinzu. Ein Ausfall kann auf vielen Ebenen auftreten:

• das Frontend funktioniert, ruft aber keine Produkte ab;
• die Produktseite zeigt einen alten Preis;
• der Warenkorb behält seinen Inhalt nicht;
• die API funktioniert nach einem Update nicht mehr;
• der Kunde bezahlt, sieht aber keine Bestätigung;
• das Panel zeigt die Bestellung, doch die Analytik erfasst sie nicht.

Das Monitoring sollte daher den gesamten Kaufprozess prüfen, nicht nur die Verfügbarkeit der Startseite.

Größere Abhängigkeit von Entwicklern. Im klassischen WordPress kann der Shop-Inhaber oft selbst ein Banner ändern, einen Block hinzufügen, das Seitenlayout korrigieren, ein Plugin aktivieren, ein Formularfeld hinzufügen oder eine Aktion starten. In einem separaten Frontend können einige dieser Änderungen die Arbeit eines Entwicklers und die Veröffentlichung einer neuen Version der Anwendung erfordern. Es lässt sich ein komfortables Inhalts-Panel mit fertigen Komponenten vorbereiten, doch diese müssen im Voraus konzipiert werden.

Schwierigere Fehlerdiagnose. Wenn der Kunde einen falschen Preis sieht, kann das Problem in WooCommerce, im ERP, in einer Integration, im Cache, in der API, in der Frontend-Logik oder im Synchronisationszeitplan liegen. Ohne Logs und Monitoring kann das Team lange brauchen, um festzustellen, welches System die falschen Daten zurückgegeben hat.

Warenkorb und Checkout erfordern viel Arbeit. Das Anzeigen einer Produktliste ist relativ einfach. Die schwierigsten Elemente beginnen in der Regel beim Warenkorb und beim Abschluss der Bestellung. Sie müssen unter anderem die Kundensitzung, die Änderung der Produktmengen, die Neuberechnung des Preises, Rabatte, Steuern, Gutscheine, Versandkosten, Abholpunkte, Rechnungsdaten, die Formularvalidierung, die Weiterleitung zur Zahlung, die Rückkehr vom Gateway, eine abgebrochene Zahlung und die Bestellbestätigung übernehmen. Jedes dieser Elemente muss in verschiedenen Browsern, auf Telefonen und bei einer langsameren Verbindung getestet werden.

Verbessert Headless Commerce das SEO?

Headless kann die Erstellung eines schnellen und gut gebauten Shops erleichtern, doch Rendering- oder Indexierungsfehler können das SEO auch verschlechtern.

Google kann JavaScript verarbeiten, doch ein Shop sollte sich nicht allein darauf verlassen, dass der Robot der Suchmaschine alle Skripte ausführt und Daten aus mehreren Systemen abruft. Die wichtigsten Informationen sollten möglichst früh im Seitencode verfügbar sein. Das betrifft unter anderem den Produktnamen, den Preis, die Verfügbarkeit, die Beschreibung, die Bilder, die H1-Überschrift, interne Links, strukturierte Daten, den Canonical, den Meta-Title und die Meta-Description.

Was muss vor dem Start geprüft werden?

1. Inhalts-Rendering — Google sollte den korrekten Namen, die Beschreibung und den Preis des Produkts erhalten.
2. URLs — jede wichtige Kategorie und jedes Produkt sollte eine separate, direkt erreichbare Adresse haben.
3. Metadaten — Title, Description, Canonical und Robots müssen für die konkrete Adresse erzeugt werden.
4. Strukturierte Daten — Preis, Verfügbarkeit und Bewertungen müssen mit dem übereinstimmen, was der Kunde sieht.
5. Interne Verlinkung — der Robot sollte zwischen Kategorien, Produkten und Ratgebern wechseln können.
6. XML-Sitemap — sie sollte die Adressen des neuen Frontends enthalten, nicht die technischen Adressen des Backends.
7. Umgang mit gelöschten Produkten — ein nicht existierendes Produkt sollte den korrekten Fehlercode oder eine Weiterleitung zurückgeben.
8. Varianten und Filter — es muss festgelegt werden, welche Kombinationen indexiert werden sollen.
9. 301-Weiterleitungen — bei einer Änderung der Adressen müssen der Traffic und die SEO-Signale aus dem alten Shop erhalten bleiben.
10. Tests nach dem Start — Indexierung, Fehler und Daten sollten in der Google Search Console geprüft werden.

Bei der Migration eines funktionierenden Shops lohnt es sich, vor der Entwicklung ein Shop-SEO-Audit durchzuführen. Das Audit ist hier eine diagnostische Stufe, die die Sichtbarkeit vor dem Start des neuen Frontends absichert.

Verbessert Headless automatisch die Core Web Vitals?

Nein. Headless verschafft mehr technische Kontrolle, garantiert aber keine guten Core-Web-Vitals-Ergebnisse.

Auch ein separates Frontend kann zu viel JavaScript laden, unnötig große Bilder abrufen, viele Werbeskripte ausführen, auf eine langsame API warten, Elemente während des Ladens verschieben oder mit Verzögerung auf Klicks reagieren. Gute Technologie ersetzt kein korrektes Design, keine Tests und kein Monitoring. Mehr über die Performance-Kennzahlen finden Sie im Leitfaden Core Web Vitals im WooCommerce-Shop.

Wann lohnt sich Headless Commerce?

Headless lohnt sich dann, wenn es ein konkretes Problem löst, das sich in einem Standard-Shop nicht sinnvoll bewältigen lässt.

1. Der Shop hat einen ungewöhnlichen Verkaufsprozess. Ein Beispiel kann ein Schritt für Schritt konfiguriertes Produkt sein: Der Kunde wählt ein Basismodell, legt die Parameter fest, betrachtet eine Vorschau, fügt eigene Dateien hinzu, erhält einen individuellen Preis und gibt eine Bestellung auf oder sendet eine Anfrage. In einem solchen Fall ist das Frontend eine umfangreiche Anwendung und nicht nur eine typische Produktseite.

2. Ein Backend soll mehrere Kanäle bedienen. Headless ist erwägenswert, wenn dieselben Produkte und Preise von einem B2C-Shop, einem B2B-Panel, einer mobilen Anwendung, Vertriebsmitarbeitern, Partnern und Verkaufskiosken genutzt werden sollen.

3. Das Unternehmen hat ein eigenes technisches Team. Headless erfordert Pflege nach dem Start: Sie müssen Abhängigkeiten aktualisieren, die API testen, Fehler überwachen, Komponenten weiterentwickeln und auf Änderungen bei Zahlungen und Integrationen reagieren. Ein dauerhafter Zugang zu Entwicklern ist daher eine wichtige Voraussetzung.

4. Der Shop führt regelmäßig nicht standardmäßige Funktionen ein. Ein separates Frontend kann sinnvoll sein, wenn das Unternehmen regelmäßig Personalisierung, Konfiguratoren, Empfehlungen, neue Kaufprozesse, UX-Experimente und Funktionen für bestimmte Kundengruppen testet.

5. Das aktuelle System blockiert das Wachstum tatsächlich. Die Entscheidung sollte sich aus einem Geschäftsziel ergeben und nicht aus dem Namen der Technologie selbst:

Ein guter Grund: Wir können keinen gemeinsamen Kaufprozess für den B2C-Shop, das B2B-Panel und die mobile Anwendung umsetzen.
Ein schwacher Grund: Wir wollen Headless, weil diese Technologie gerade beliebt ist.

Wann ist Headless überdimensioniert?

Headless ist in der Regel nicht sinnvoll, wenn der Shop einen Standardkatalog, einen einfachen Checkout und kein festes technisches Team hat.

Das betrifft am häufigsten Shops, die:

• Standardprodukte haben;
• verbreitete Zahlungen und Lieferungen nutzen;
• keine mobile Anwendung benötigen;
• nicht mehrere Verkaufskanäle betreiben;
• selten neue Funktionen einführen;
• keine eigenen Entwickler haben;
• ein begrenztes Wartungsbudget haben;
• ihr Geschäftsmodell erst noch validieren.

Wenn ein Shop einige Hundert Produkte und einen Standard-Kaufprozess hat, lohnt es sich, zuerst den Zustand des aktuellen WooCommerce zu prüfen. Manchmal löst ein leichteres Theme, ein besseres Hosting, eine korrekte Cache-Konfiguration, der Austausch einiger Plugins, das Aufräumen der Datenbank oder der Umbau ausgewählter Elemente das Problem. Mehr praktische Maßnahmen beschreiben wir im Artikel wie man einen WooCommerce-Shop beschleunigt — 9 bewährte Schritte.

Headless Commerce — ein Rentabilitätstest

Je mehr „Ja"-Antworten, desto größer die Chance, dass ein separates Frontend gerechtfertigt ist.

Frage	Ja	Nein
Blockiert das aktuelle Frontend eine wichtige Verkaufsfunktion?	+1	0
Soll ein Backend mehrere Kanäle bedienen?	+1	0
Benötigt der Shop einen ungewöhnlichen Konfigurator?	+1	0
Hat das Unternehmen dauerhaften Zugang zu Entwicklern?	+1	0
Wurden die Probleme durch eine technische Analyse bestätigt?	+1	0
Hat das Unternehmen ein Budget für die Pflege mehrerer Anwendungen?	+1	0
Soll die Umsetzung einen messbaren geschäftlichen Effekt bringen?	+1	0

Interpretation:

• 0–2 Punkte — vollständiges Headless wird wahrscheinlich nicht benötigt;
• 3–4 Punkte — es lohnt sich, eine hybride Lösung zu analysieren;
• 5–7 Punkte — Headless kann gerechtfertigt sein, erfordert aber eine Analyse der Architektur.

Das ist kein automatischer Entscheidungsrechner. Er soll helfen, das Gespräch mit dem Auftragnehmer zu strukturieren.

Wovon hängen die Kosten einer Headless-Umsetzung ab?

Die Kosten hängen vor allem von der Anzahl der Funktionen, Integrationen und Prozesse ab, die im separaten Frontend nachgebildet werden müssen.

Element	Was erhöht den Arbeitsumfang?
Frontend	Die Anzahl der Ansichten, Komponenten, Animationen und Sprachversionen
Katalog	Varianten, Sets, Konfiguratoren, mehrere Preislisten
Warenkorb	Gutscheine, Rabatte, Mengenregeln und Steuern
Checkout	Zusätzliche Felder, Rechnungen, Abholpunkte und mehrere Märkte
Zahlungen	Die Anzahl der Anbieter und die Art der Rückabwicklungen
Lieferungen	Kuriere, Paketautomaten und Sperrgutsendungen
Kundenkonto	Bestellungen, Retouren, Dokumente und Abonnements
Integrationen	ERP, PIM, CRM, BaseLinker und Marktplätze
SEO	Migration der Adressen, strukturierte Daten und Filter
Analytik	GA4, Google Ads, Consent Mode und eigene Ereignisse
Infrastruktur	Hosting des Frontends, des Backends, Cache und Monitoring
Wartung	Updates, Tests, Fehler und Weiterentwicklung

Headless sollte nicht allein mit dem Preis für die Erstellung eines WooCommerce-Themes verglichen werden. Es handelt sich um den Aufbau einer separaten Anwendung, die mit der Verkaufs-Engine verbunden ist.

Wie führt man Headless Commerce sicher ein?

Eine sichere Umsetzung beginnt mit einer Analyse der Prozesse und Integrationen, nicht mit der Wahl eines Frameworks.

Schritt 1: Definieren Sie das Geschäftsproblem. Halten Sie fest, was der aktuelle Shop unmöglich macht, wer die neue Funktion nutzen soll, welcher Effekt erreicht werden soll, wie er gemessen wird und welche Funktionen nicht verloren gehen dürfen.

Schritt 2: Inventarisieren Sie den aktuellen Shop. Erstellen Sie eine Liste der Plugins, Zahlungsmethoden, Lieferungen, Produkttypen, Checkout-Felder, Rabatte, Integrationen, Automatisierungen, Analytik-Ereignisse und wichtigen SEO-Adressen.

Schritt 3: Legen Sie die Datenquellen fest. Wählen Sie für jede Information ein Hauptsystem — zum Beispiel die Produktbeschreibung aus dem PIM, den Preis aus dem ERP, die Bestellung aus WooCommerce, die Artikel aus WordPress, den Lagerbestand aus dem Lagersystem. Fehlen solche Regeln, führt das zu einer Situation, in der zwei Systeme einen unterschiedlichen Preis oder eine unterschiedliche Verfügbarkeit anzeigen.

Schritt 5: Bereiten Sie einen SEO-Plan vor. Legen Sie vor der Veröffentlichung die URLs, Weiterleitungen, Canonicals, Indexierungsregeln, die XML-Sitemap, strukturierte Daten, die Verlinkung und die Fehlerbehandlung fest. Hilfreich ist eine technische WooCommerce-SEO-Checkliste.

Schritt 6: Konfigurieren Sie die Analytik. Prüfen Sie Ereignisse wie Produktansicht, Hinzufügen zum Warenkorb, Beginn des Checkouts, Auswahl der Lieferung, Auswahl der Zahlung, Kauf, Bestellwert, Währung und Transaktionskennung. Ohne korrekte Messung lässt sich schwer feststellen, ob der neue Shop tatsächlich besser funktioniert.

Schritt 7: Starten Sie in Etappen. Sicherer ist eine schrittweise Einführung oder der Beginn mit einem hybriden Modell. So lassen sich Geschwindigkeit, Konversion, Zahlungen, Fehler, Indexierung, API-Last und Nutzerverhalten überprüfen.

Was können Sie selbst prüfen?

1. Halten Sie drei Probleme des aktuellen Shops fest. Verwenden Sie keine allgemeinen Floskeln wie „er ist veraltet" — notieren Sie konkrete Einschränkungen.

2. Prüfen Sie die wichtigsten Seitentypen. Untersuchen Sie die Startseite, eine Kategorie, ein Produkt, den Warenkorb und den Checkout.

3. Sehen Sie die aktiven Plugins durch. Markieren Sie diejenigen, die für den Kunden sichtbare Elemente hinzufügen.

4. Listen Sie alle Integrationen auf. Berücksichtigen Sie Zahlungen, Kuriere, ERP, Rechnungen, BaseLinker, CRM und Marketing-Automation.

5. Bestimmen Sie den Eigentümer jeder Datenart. Prüfen Sie, woher Preise, Beschreibungen, Bestände und Bestellungen stammen.

6. Legen Sie fest, wer das Frontend pflegen wird. Headless erfordert eine dauerhafte Betreuung, nicht nur eine einmalige Umsetzung.

7. Definieren Sie ein messbares Ziel. Das kann die Bedienung eines neuen Kanals, die Verkürzung der Zeit zur Einführung von Funktionen oder die Reduzierung von Kauffehlern sein.

Wann lohnt es sich, dies einem Spezialisten zu überlassen?

Die Analyse eines Spezialisten ist nötig, wenn der Shop umfangreiche Integrationen, funktionierenden SEO-Traffic oder einen ungewöhnlichen Kaufprozess hat.

Das gilt besonders, wenn:

• die Preise aus mehreren Systemen stammen;
• der Shop auf mehreren Märkten tätig ist;
• die Produkte konfigurierbar sind;
• es individuelle B2B-Preislisten gibt;
• der Checkout zusätzliche Felder und Regeln hat;
• der Shop mit einem ERP oder PIM verbunden ist;
• unklar ist, ob klassisch, hybrid oder vollständig Headless gewählt werden soll;
• der Umbau einen funktionierenden Dienst mit organischem Traffic betrifft.

Eine Analyse vor der Umsetzung sollte zeigen, welches Problem gelöst werden soll, welche Funktionen umgebaut werden müssen, welche Risiken bestehen, was Wartung erfordert und ob eine einfachere Variante nicht rentabler wäre. Das Hauptergebnis sollte ein Plan für die Architektur und Umsetzung des Shops sein — das SEO-Audit ist hingegen eine Stufe, die die Sichtbarkeit vor der Migration absichert.

---

Ist Headless in Ihrem Shop sinnvoll?

Headless Commerce kann konkrete Probleme eines großen oder ungewöhnlichen E-Commerce lösen. Es sollte jedoch nicht allein deshalb gewählt werden, weil es mit neuer Technologie und hohen Geschwindigkeitswerten assoziiert wird. Wenn Sie einen Umbau Ihres Shops planen, analysieren wir Ihren aktuellen Verkaufsprozess, Ihre Integrationen und technischen Anforderungen und vergleichen anschließend klassisches WooCommerce, eine hybride Lösung und vollständiges Headless:

• WooCommerce-Shop-Erstellung — die Hauptrichtung der Umsetzung und Erweiterung.
• SEO-Audit — Absicherung der Sichtbarkeit und der URLs bei der Migration.
• Wie man einen WooCommerce-Shop beschleunigt — oft eine günstigere Alternative zu Headless.
• WooCommerce API — wie das Frontend mit der Shop-Engine kommuniziert.