Lohnt sich headless überhaupt?

Nur mit einem echten Grund. Gute Gründe sind eine große Redaktion, die in TYPO3 arbeitet, mehrere Marken auf einer Inhaltsbasis oder ein Frontend, das es so in Shopware nicht gibt. Kein guter Grund ist „ist moderner“ – headless verdoppelt die Systeme, die gepflegt werden müssen.

Kann ich Shopware-Inhalte in WordPress einbinden?

Ja, dieselbe Technik: Die Store API liefert Produkte und Kategorien, WordPress stellt sie dar. Häufiger und einfacher ist allerdings der umgekehrte Weg – Inhalte aus WordPress in die Shopware-Seiten holen, statt den ganzen Shop nachzubauen.

Was passiert mit der Suchmaschinen-Sichtbarkeit?

Das ist der Punkt, an dem headless am häufigsten schiefgeht. Wenn Produktseiten unter zwei Adressen erreichbar sind, konkurrieren sie miteinander. Es braucht eine Entscheidung, welche Adresse die richtige ist, und ein Canonical, das konsequent darauf zeigt.

Funktioniert der Warenkorb über zwei Systeme hinweg?

Ja, wenn die Sitzung sauber weitergereicht wird. Heikel wird es bei zwei verschiedenen Domains – dann greifen Cookie-Beschränkungen der Browser. Eine gemeinsame Domain mit Unterverzeichnissen erspart diese ganze Klasse von Problemen.

Was ist der einfachere Weg?

In den meisten Fällen: Shopware bleibt das Frontend, und Inhalte kommen über eine Schnittstelle hinein. Das ist weniger aufwendig, weniger fehleranfällig und für Suchmaschinen unproblematisch. Wir sagen Ihnen, wenn das bei Ihnen reicht.

Wird der Shop dadurch schneller?

Nicht von selbst. Headless verschiebt nur, wo gerendert wird – die Ladezeit entscheidet sich danach an denselben Stellen wie vorher: Bildgrößen, Caching, Zahl der Abfragen. Wer wegen der Geschwindigkeit headless baut, hat meist ein Caching-Problem, das sich im bestehenden Shop billiger lösen lässt.

TYPO3 · WordPress · Store API

Shopware headless: Inhalte aus TYPO3 oder WordPress, Handel aus Shopware

Die Store API liefert Katalog, Warenkorb und Checkout an ein fremdes Frontend. Wir sagen Ihnen vorher, ob sich der zweite Systemstrang für Sie rechnet – oft tut er es nicht.

Headless-Machbarkeit prüfen Shopprojekte ansehen

Vertrauen u.A von:

Grundsatzfrage

Die ehrliche Frage vor dem Projekt: brauchen Sie das?

Headless heißt, dass zwei Systeme dieselbe Seite bauen – eines liefert Inhalte, eines den Handel. Das ist mächtig und kostet dauerhaft: doppelte Pflege, doppelte Updates, doppelte Fehlersuche. Deshalb steht bei uns am Anfang keine Architektur, sondern eine Frage: Was geht heute nicht, das danach gehen soll?

Gute Gründe gibt es. Eine Redaktion, die seit Jahren in TYPO3 arbeitet und nicht wechseln soll. Mehrere Marken oder Länder auf einer Inhaltsbasis. Ein Frontend, das in Shopware nicht abbildbar ist. Kein guter Grund ist, dass headless moderner klingt.

In etwa der Hälfte der Gespräche ist der einfachere Weg der richtige: Shopware bleibt das Frontend, und Inhalte kommen über eine Schnittstelle herein. Weniger Aufwand, weniger Fehlerquellen, keine Probleme mit doppelten Adressen. Wenn das bei Ihnen reicht, sagen wir es.

Praktisch heißt das: Wir fangen mit einer Machbarkeitsrunde an, nicht mit einem Angebot. Darin steht am Ende, welche der drei Bauarten zu Ihrem Fall passt, was sie im Betrieb kostet – und ob der einfachste Weg genügt.

Anbindungswege

Drei Bauarten, von einfach nach aufwendig

Die Reihenfolge ist auch unsere Empfehlungsreihenfolge.

Inhalte in Shopware holen

Shopware bleibt das Frontend, Redaktionsinhalte kommen aus dem CMS herein. Ein System im Frontend, eine Adresse je Seite, keine Sitzungsprobleme. Für die meisten der richtige Weg.

Teilweise headless

Das CMS baut Kampagnen- und Markenseiten, Shopware alles ab der Kategorie. Zwei Systeme, aber eine klare Grenze und je Seite eine eindeutige Zuständigkeit.

Vollständig headless

Das CMS baut alles, Shopware liefert nur Daten über die Store API. Maximale Freiheit im Frontend, dafür bauen Sie Warenkorb, Checkout und Kundenkonto nach – und pflegen sie dauerhaft.

Stolpersteine

Woran headless-Projekte scheitern

Vier Punkte, die alle erst nach dem Start auffallen – und alle vorher entscheidbar sind.

Zwei Adressen für dieselbe Seite

Ist ein Produkt über CMS und Shop erreichbar, konkurrieren die Seiten miteinander. Es braucht eine Entscheidung und ein Canonical, das konsequent darauf zeigt.
Warenkorb über zwei Domains

Browser beschränken Cookies zwischen Domains immer stärker. Eine gemeinsame Domain mit Unterverzeichnissen erspart diese ganze Klasse von Problemen.
Der Checkout wird nachgebaut

Zahlarten, Steuerlogik, Rechtstexte, Fehlerfälle – im Shopware-Checkout steckt mehr, als von außen sichtbar ist. Wer ihn nachbaut, pflegt ihn für immer.
Zwei Update-Zyklen

Shopware und das CMS aktualisieren unabhängig voneinander. Was einzeln funktioniert, muss zusammen getestet werden – dauerhaft, nicht einmal.

Datenmapping

Was über die Store API läuft

Der übliche Umfang einer Anbindung. Je weniger davon Sie brauchen, desto einfacher wird das Projekt.

Kategorien und Navigation

Shopware ins CMS, damit die Struktur an einer Stelle gepflegt wird.

Produkte und Varianten

Shopware ins CMS: Daten, Preise, Verfügbarkeit, Bilder – dargestellt im Layout des CMS.

Suche und Filter

Shopware ins CMS. Die Suche im Shop kennt Ihre Daten; sie im CMS nachzubauen lohnt fast nie.

Warenkorb

In beide Richtungen, mit durchgereichter Sitzung. Der Punkt, an dem zwei Domains wehtun.

Checkout

Unsere Empfehlung: im Shopware-Checkout bleiben. Dort stecken Zahlarten, Steuerlogik und Rechtstexte.

Kundenkonto

Shopware ins CMS, wenn Bestellhistorie und Belege im Markenfrontend sichtbar sein sollen.

FAQ · Headless mit TYPO3 & WordPress

Häufige Fragen zur Headless-Anbindung

Über die Store API von Shopware: TYPO3 liefert die Seiten, ruft Katalogdaten, Warenkorb und Checkout bei Shopware ab und zeigt sie im eigenen Layout. Der Shop bleibt das System, das Handel kann – TYPO3 das, was Redaktion kann.