**TL;DR.** Headless Commerce gibt Ihnen die Kontrolle über das Frontend und die Leistung am Edge, auf Kosten von operativer Komplexität und Ingenieurzeit. Gehostetes SaaS tauscht Flexibilität gegen Geschwindigkeit beim Start und verwaltete Infrastruktur. Der ideale Punkt für die meisten Händler im Jahr 2026 ist eine gehostete Plattform, die nativ headless-ähnliche Leistung bietet (Cache Components + PPR) und die Wahl eliminiert.

## Was "headless commerce" tatsächlich bedeutet

Headless Commerce entkoppelt das Backend des Handels (Katalog, Bestellungen, Inventar) vom Frontend des Shops. Das Frontend ist eine separate Codebasis, typischerweise React/Next.js oder Astro, die das Backend des Handels über eine GraphQL- oder REST-API konsumiert.

Berühmte Beispiele:

- **Shopify Hydrogen**: Shopifys headless Framework, gehostet auf Oxygen.
- **BigCommerce + Next.js Commerce**: BCs Storefront API, konsumiert von einem Next.js-Frontend.
- **commercetools + benutzerdefiniertes Next.js**: vollständige komponierbare Handelsarchitektur.
- **Magento PWA Studio**: Magentos headless PWA-Lösung.

Gehosteter (oder "monolithischer") Commerce hält Frontend und Backend auf einer Plattform. Standard-Shopify-Themen, BigCommerce-Stencil-Themen, WooCommerce-Standardthemen und Squarespace Commerce sind gehostet.

## Was headless löst

Drei echte Probleme:

1. **Frontend-Anpassung über das hinaus, was ein Thema erlaubt.** Marken mit besonderen UX-Anforderungen (benutzerdefinierte Konfiguratoren, AR-Produktansichten, komplexe Bundle-Builder) stoßen oft an die Grenzen von Themen.
2. **Wiederverwendung von Inhalten über mehrere Kanäle.** Ein Team, das einen Webshop, eine mobile App und einen Kiosk im Geschäft betreibt, möchte ein Backend, das alle drei bedient.
3. **Edge-Rendering-Leistung.** Ein gut gestaltetes headless Frontend auf Vercel/Cloudflare/Netlify kann aus Edge-POPs in <50ms TTFB bedienen und schlägt monolithische PHP-Stacks entscheidend.

Wenn keines dieser Probleme für Ihr Unternehmen drängend ist, ist headless Overhead ohne Nutzen.

## Was headless kostet

Echte Kostenpunkte:

| Kosten                          | Gehostet (Ordiko)  | Headless (typisch)                                       |
| ------------------------------- | ------------------ | -------------------------------------------------------- |
| Plattform-Abonnement             | $19–$149/Monat     | $40–$600/Monat (Shopify Plus-Stufe + Hydrogen Oxygen usw.) |
| Frontend-Hosting                | Inklusive          | $20–$500/Monat (Vercel/Netlify Pro)                     |
| Headless CMS                    | Nicht benötigt     | $100–$2,000/Monat (Sanity, Contentful, Storyblok)      |
| Frontend-Engineering             | Optional           | 1–3 FTEs laufend                                         |
| DevOps / Bereitstellungspipeline | Nicht benötigt     | 0.5–1 FTE laufend                                       |
| Gesamte realistische monatliche  | $19–$149           | $5,000–$50,000+                                         |

Der Anstieg beträgt ein bis zwei Größenordnungen. Es lohnt sich nur, wenn die headless-Funktionen ein strategisches Problem lösen.

## Leistungsvergleich

Die Leistung hängt mehr von der Ingenieursqualität als von der architektonischen Wahl ab. Datenpunkte aus der realen Welt (Median CWV von öffentlich beobachtbaren Shops):

| Architektur                          | LCP        | INP        | CLS        |
| ------------------------------------- | ---------- | ---------- | ---------- |
| Shopify Standard Liquid-Thema        | 2.0–3.5s   | 200–400ms  | 0.05–0.20  |
| Shopify Hydrogen + Oxygen             | 1.2–2.2s   | 100–250ms  | <0.10      |
| BigCommerce Stencil                   | 2.0–3.0s   | 150–350ms  | 0.05–0.15  |
| BC + Next.js Commerce (headless)      | 1.0–2.0s   | 80–200ms   | <0.10      |
| Magento unoptimiert                   | 4.0–8.0s   | 400–1000ms | 0.15–0.30  |
| Magento optimiert                     | 1.8–2.8s   | 180–350ms  | 0.05–0.15  |
| Magento PWA Studio (headless)         | 1.0–2.0s   | 100–250ms  | <0.10      |
| **Ordiko (gehostet + PPR)**           | **1.0–1.8s** | **80–160ms** | **<0.05** |

Ordiko ist enthalten, um einen Punkt zu verdeutlichen: Eine gehostete Plattform mit Next.js 16 + Cache Components + PPR bietet headless-ähnliche Leistung ohne den operativen Overhead. Es ist die "beste Lösung aus beiden Welten" Architektur im Jahr 2026.

## SEO-Äquivalenz

Headless verbessert nicht automatisch SEO. In der Praxis regressieren Teams, die headless implementieren, oft, weil grundlegende SEO-Oberflächen unvollständig neu implementiert werden.

Erforderliche Oberflächen (unabhängig von der Architektur):

- Meta-Titel, Meta-Beschreibung, kanonisch, hreflang pro Entität.
- Server-gerendertes HTML (nicht nur clientseitiges React).
- Produkt-, Organisations-, Breadcrumb-, FAQ-JSON-LD.
- 2026-Schema-Felder: `hasMerchantReturnPolicy`, `shippingDetails`.
- XML-Sitemap (paginiert für große Kataloge).
- robots.txt mit AI-Crawler-Richtlinie.
- llms.txt und llms-full.txt.
- IndexNow bei Mutationen.
- Slug-Historie + 301-Weiterleitungen + 410 gone-Pfade.

Wenn headless Sie zwingt, all dies von Grund auf neu zu erstellen, ist die Architekturentscheidung auch eine "Werden wir SEO ernsthaft angehen?" Entscheidung. Viele Teams budgetieren dies zu niedrig und liefern ein schönes Frontend mit gebrochenem SEO.

## Wann man sich für headless entscheiden sollte

- Jährlicher Umsatz > $5M.
- Interne Frontend-Engineering-Kapazität (≥ 2 FTEs).
- Strategischer Bedarf an Frontend-Differenzierung (benutzerdefinierte Konfiguratoren, AR, markenwürdige UX).
- Multi-Channel-Wiederverwendung (Web + App + Kiosk).
- Sie betreiben bereits eine inhaltsreiche Website auf einem headless CMS.

## Wann man sich für gehostet entscheiden sollte

- Sie haben keine oder möchten keine interne Frontend-Engineering-Kapazität.
- Geschwindigkeit beim Start ist wichtiger als Frontend-Differenzierung.
- Ihr Team bevorzugt operationale Einfachheit gegenüber Flexibilität.
- Sie liegen unter der Umsatzmarke von $5M, wo die TCO von headless proportional wird.

## Wann man sich für das Hybrid (Ordiko) entscheiden sollte

- Sie möchten headless-ähnliche Leistung, ohne zwei Systeme zu betreiben.
- Sie möchten 2026 SEO-Oberflächen integriert, nicht von Grund auf neu erstellt.
- Sie möchten mehrere Shops nativ, ohne sie zu komponieren.
- Ihr Team ist mit React/Next.js vertraut, möchte aber keine DevOps-Verantwortung.

## FAQ

**Hat headless immer eine bessere Leistung?**
Nein. Headless auf einem gut gestalteten Next.js- oder Astro-Stack schlägt typischerweise das Standard-Shopify-Liquid oder Magento PHP. Headless auf einer schlecht gestalteten React-App ohne Caching kann langsamer sein als das gehostete Pendant. Die Plattform ist nicht der entscheidende Faktor; das Engineering ist es.

**Ist Ordiko headless?**
Ordiko bietet headless-ähnliche Leistung durch Next.js 16 Cache Components + PPR, während es als eine einzige verwaltete Codebasis ausgeliefert wird. Sie verwalten nicht zwei Systeme. Für Teams, die die Geschwindigkeit von headless ohne die operationale Belastung möchten, ist dies der ideale Punkt.

**Wann macht headless wirtschaftlich Sinn?**
Ungefähr über $5M Jahresumsatz mit interner Frontend-Engineering-Kapazität oder für Marken, bei denen die Frontend-Differenzierung zentral für die Positionierung ist. Unterhalb dieser Schwelle begünstigt die TCO gehostete Lösungen.

**Kann ich AI-Suchoptimierung auf headless durchführen?**
Ja, aber Sie müssen alles neu implementieren. Die Generierung von llms.txt, Markdown-Zwillingen, AI-Crawler-Richtlinien und hreflang pro Entität in einer headless-Umgebung bedeutet, dass Sie Routen-Handler für jede Oberfläche schreiben müssen. Ordiko liefert diese als Standard.