E-Commerce-Architektur neu gedacht: Warum eine maßgeschneiderte React-SPA nicht automatisch besser ist als WooCommerce

Das Problem: Die Existenz von Variablen wie window.__INITIAL_DATA__ ist kein Beweis für Server-Side Rendering (SSR). Wenn das HTML nur ein leeres Wurzelelement enthält, handelt es sich um reines Client-Side Rendering (CSR). Erst wenn die Produktinformationen, Überschriften und Preise bereits im HTML-Quelltext stehen, spricht man von SSR.

Ein wichtiger Aspekt ist der Umgang mit Fehlerseiten. Wenn jede Route (auch /produkt/nicht-vorhanden) denselben HTTP-Status 200 zurückgibt und erst React eine „Nicht gefunden“-Meldung anzeigt, entstehen sogenannte „Soft 404“-Fehler. Google betrachtet dies als problematisch und empfiehlt entweder einen echten 404-Status oder einen

<meta name="robots" content="noindex">

1.3 Der Katalog-Datenfluss: Flexibel, aber unoptimiert

Die Endpunkte zeigen, dass der Produktkatalog nicht im Frontend-Bundle fest codiert ist:

• GET /api/products?limit=500&active=1

  – Ruft alle aktiven Produkte ab.

• GET /api/products?q=...

  – Sucht nach Produkten.

• GET /api/products/<slug>

  – Holt die Detailseite eines Produkts.

• GET /api/products/categories

  – Ruft die Taxonomie ab.

Vorteil: Änderungen im Katalog (Preis, Bild, Lagerbestand) erfordern keinen erneuten Build des Frontends. Dies entkoppelt die Frontend-Bereitstellung von den Daten.

Nachteil: Der Parameter limit=500 deutet darauf hin, dass die API für einen kleinen Katalog optimiert ist. Bei einem Katalog mit 16 Produkten ist das unproblematisch. Bei tausenden von SKUs würde die Payload-Größe, die Abfragezeit, der Browser-Speicher und die Cache-Invalidierung jedoch unnötig ansteigen. Eine zukunftssichere API sollte Cursor-Paginierung, Feld-Projektion und separate Endpunkte für Suche und Filterung nutzen.

Ein weiteres Problem ist der Fokus auf das Produkt statt auf die Variante. Das Schema zeigt, dass der stock auf Produktebene liegt, obwohl es variants gibt. Attribute wie sizes, colors, genders sind sowohl als Arrays auf dem Produkt als auch in den Varianten vorhanden. Zudem gibt es Inkonsistenzen (z. B. XXL vs. 2XL,

ink navy

Ink Navy

1.4 Homepage und Layout Builder: Flexibel, aber unstrukturiert

Die Startseite wird durch einen Builder im CMS gesteuert. Ein Endpunkt wie /api/homepage liefert die Konfiguration der einzelnen Abschnitte. Ein Renderer iteriert über section_order, findet den passenden React-Component-Typ (z. B. hero, trustbar, catshowcase) und prüft einen Toggle, bevor die Komponente eingebunden wird.

Stärke: Marketingteams können die Reihenfolge ändern und Abschnitte ein- oder ausblenden, ohne das Frontend neu auszuliefern.

Schwäche: Das System leidet unter Inkonsistenzen. So existieren sowohl ann als auch announcement als Schlüssel, was auf eine unvollständige Schema-Migration hindeutet. Da section_order, Toggle und Payload drei separate Strukturen sind, können sie leicht asynchron werden: Ein Schlüssel ist in der Reihenfolge vorhanden, aber ohne Payload, oder der Toggle hat einen anderen Namen.

Eine Neukonzeption sollte diese Logik in einer einzigen Liste von Blöcken zusammenfassen, wobei jeder Block eine eindeutige ID, einen Typ, einen Status (aktiviert/deaktiviert), eine Position und einen Payload hat.

1.5 Das Layout und die Einstellungen: Transparent, aber unsicher

/api/layout enthält die Konfiguration für Header/Footer/Navigation, während /api/public/settings Markenwerte und Store-Richtlinien bereitstellt. Diese Trennung ist sinnvoll, da Header/Footer auf jeder Seite gelten, die Homepage-Konfiguration jedoch nur auf der Startseite.

Die Vielzahl der Einstellungen (Marke, Farben, Logo, Versandkosten, PayPal-Client-ID, Social-Links) zeigt, dass eine Key-Value-Struktur oder ein großes JSON-Objekt verwendet wird.

Vorteil: Hohe Flexibilität: Neue Schlüssel können hinzugefügt werden, ohne dass ein Datenbank-Migration erforderlich ist.

Nachteil: Eine reine Key-Value-Struktur bietet keine Typsicherheit, keine Fremdschlüssel und keine Validierung über Felder hinweg. Beispielsweise sollte standard_handling_min nicht größer sein als standard_handling_max. Zudem sollten sensible Daten (Steuernummer, Geschäftsadresse, interne Betriebs-E-Mails) nicht über einen öffentlichen Endpunkt abrufbar sein. Die PayPal-Client-ID darf öffentlich sein, aber der client_secret muss zwingend auf dem Server bleiben. Jede Variable im window.__...-Objekt ist für den Nutzer einsehbar.

1.6 Coupons und PayPal-Checkout: Grundsätzlich richtig, aber komplex

Der Zahlungsablauf folgt der Logik:

1. Der Client sendet Warenkorb und Coupon an den Server.
2. Der Server berechnet auf Basis der aktuellen Produkt- und Aktionsdaten die korrekten Preise.
3. Das Backend erstellt eine PayPal-Order und speichert die Beziehung zum internen Checkout.
4. Der Client leitet den PayPal-Zahlungsvorgang ein.
5. Nach der Genehmigung durch den Nutzer captured der Server die Zahlung.
6. Der Server erstellt die offizielle Bestellung, verbucht die Zahlung und aktualisiert den Lagerbestand.
7. Ein PayPal-Webhook dient als Rückfallebene für asynchrone Statusänderungen.

Das A und O: Der Server darf niemals den Preis, Rabatt oder die Versandkosten vom Browser übernehmen. Diese Werte müssen serverseitig auf Basis der aktuellen SKU, der Promotionsregeln und der Versandart neu berechnet werden. Die Qualität der Implementierung hängt von folgenden Punkten ab:

• Idempotenz-Schlüssel, um Doppelklicks zu verhindern.
• Transaktionen oder Locks, um Überverkäufe zu vermeiden.
• Aufzeichnung des Zahlungsversuchs vor dem Aufruf des Zahlungsanbieters.
• Überprüfung der Webhook-Signatur.
• Klare State-Machine für den Checkout.
• Abgleich-Job für Fälle, in denen PayPal erfolgreich war, die Antwort aber nicht beim Shop ankam.

1.7 Bewertungen, Newsletter, Kontakt und Tracking: Die erweiterte Funktionalität

Diese Endpunkte machen das Backend zu einer vollwertigen E-Commerce-Anwendung.

• Bewertungen: Erfordern einen Status-Workflow (ausstehend/genehmigt/abgelehnt), Spam-Schutz, Ratenbegrenzung und idealerweise eine Überprüfung des Käufers. Der Endpunkt

  POST /api/reviews/<id>

  wirkt ungewöhnlich – eine Neukonzeption sollte klarere Ressourcen-Semantiken verwenden.
• Newsletter: Erfordert Normalisierung der E-Mail-Adresse, einen Unique-Constraint, Double-Opt-In (je nach Rechtslage), eine Abmeldefunktion und die Vermeidung ungeschützter Protokollierung.
• Kontaktformular: Benötigt CAPTCHA oder Bot-Schutz, Ratenbegrenzung, eine E-Mail-Warteschlange und die Entkopplung des HTTP-Requests vom E-Mail-Versand.
• Sendungsverfolgung: Sollte keine kurzen Bestellnummern verwenden, die leicht zu erraten sind. Besser sind signierte Tracking-Token oder eine Kombination aus Bestellnummer und E-Mail/Postleitzahl, kombiniert mit Ratenbegrenzung. Der Endpunkt ist anfällig für Enumeration, was personenbezogene Daten und Kaufhistorien preisgeben könnte.
• Analytics/Tracking (

  POST /api/track

  ): Reduziert die Abhängigkeit von clientseitigen Analyse-Tools und ist resistenter gegen Ad-Blocker. Erfordert jedoch eine Einwilligung, eine Datenaufbewahrungsrichtlinie, ein definiertes Event-Schema und Schutz vor Bots. Der Endpunkt sollte keine beliebigen JSON-Daten akzeptieren, sondern eine Whitelist für Event-Namen und Eigenschaften verwenden.

1.8 Das Backend: Eine Spekulation ohne endgültige Beweise

Die genaue Backend-Sprache lässt sich allein aus den Endpunkt-Namen und JSON-Schemata nicht bestimmen. Die wahrscheinlichsten Kandidaten sind:

• Node.js (Express/Fastify/NestJS): Ergibt Sinn, da React/Vite häufig mit TypeScript und den JSON-Serialisierungsmöglichkeiten von Node einhergehen. Das Einbetten von window.__INITIAL_DATA__ ist mit Node-Templates einfach.
• PHP (Laravel/Symfony): Ebenfalls gut möglich. Laravel bietet Controllers, Migrations, Queues und Mail – und Cloudflare verbirgt alle X-Powered-By-Header.
• Python (FastAPI/Flask/Django): FastAPI und Flask sind für JSON-APIs geeignet, Django hat ein starkes ORM. Die Vite-Build-Ergebnisse können unabhängig vom Python-Backend über Nginx oder einen separaten Origin-Server ausgeliefert werden.

Fazit: Es ist nicht möglich, die Backend-Sprache allein aus der Architektur abzuleiten. Ein sicheres Fingerprinting erfordert den Zugriff auf Deployment-Files, Lockfiles, Container-Images, unveränderte Response-Header (bevor Cloudflare sie verändert) und Fehlermeldungen.

1.9 Stärken und Schwächen der aktuellen Architektur

Stärken:

• Plattformunabhängige UI: React ist nicht an ein PHP-Theme oder den Lifecycle von WooCommerce gebunden.
• Exzellenter Cache für statische Assets: Der Vite-Content-Hash ermöglicht

  Cache-Control: immutable

  .
• Schlanker Builder: Der Homepage/Layout-Builder konzentriert sich auf die Bedürfnisse der Marke, ohne generische Page-Builder-Funktionalität.
• Klare API-Domänen: Katalog, Inhalte und Operationen können unabhängig voneinander für Web, App und Admin genutzt werden.
• Schnelle Navigation: Nach dem ersten Laden werden nur noch Daten nachgeladen.

Schwächen und Risiken:

• Langsamer First Load: Die leere App-Shell erfordert das Herunterladen, Parsen und Ausführen von JavaScript vor der Anzeige von Inhalten.
• API-Wasserfall: Wenn Einstellungen, Homepage, Layout und Produkte nacheinander geladen werden müssen, verlängert sich die LCP (Largest Contentful Paint).
• SEO und Statuscodes: Die Catch-All-Route erzeugt leicht Soft-404-Fehler und gemeinsame Title/Canonical-Tags.
• Komplexe Cache-Invalidierung: Unterschiedliche TTLs für Katalog, Homepage, Layout und Einstellungen erschweren die korrekte Zwischenspeicherung.
• Selbst entwickelte Geschäftslogik: Coupons, Bestellungen, Steuern, Retouren, Lagerverwaltung und Admin-Oberfläche müssen selbst getestet und gewartet werden.
• Unstandardisiertes Datenmodell: Arrays für Farben und Größen sowie der Lagerbestand auf Produktebene sind nicht skalierbar.
• Sicherheitsrisiken: Kontaktformulare, Bewertungen, Newsletter und Tracking sind öffentliche Mutations-Endpunkte.
• Wissensträger-Risiko: Wenn nur eine Person das gesamte Custom-Backend versteht, sind die Einarbeitungs- und Ausfallkosten hoch.

2. Der direkte Vergleich: Custom SPA vs. WooCommerce

2.1 Ist Custom automatisch besser?

Nein. Die Wahl des Tech-Stacks sagt nichts über Geschwindigkeit, SEO-Tauglichkeit oder Sicherheit aus. Ein gut optimierter WooCommerce-Shop kann schneller und SEO-freundlicher sein als eine schlecht konfigurierte Custom-SPA. Die Qualität hängt vom Datenmodell, der Rendering-Strategie, dem Cache, der Beobachtbarkeit und den Tests ab. Bei nur 16 Produkten kann ein Custom-Ansatz übertrieben sein.

2.2 Ladegeschwindigkeit

• Custom SPA: Potenziell sehr schnell bei nachfolgenden Navigationen, aber der erste Aufruf kann durch den JavaScript-Boot und den API-Wasserfall langsam sein.
• WooCommerce (traditionell): Liefert sofort HTML, die Inhalte sind ohne JavaScript sichtbar. Kann aber durch schwere Plugins und Datenbankabfragen verlangsamt werden.

Fazit: Custom hat ein höheres theoretisches Leistungspotenzial, wenn SSR/SSG und optimierte Bundles verwendet werden. WooCommerce ist einfacher und liefert eine solide Grundlage. Vergleichen sollte man nicht die Technologie, sondern die tatsächlichen Core Web Vitals (p75) auf mobilen Geräten.

2.3 UI-Anpassung und Builder

• Custom React: Bietet ultimative Freiheit für Animationen, Redaktionsblöcke und Kampagnen. Der selbst entwickelte Builder ist schlanker als generische Page-Builder.
• WooCommerce: Bietet einen ausgereiften Back-Office-Bereich (Produktverwaltung, Bestellungen, Coupons) und ein großes Plugin-Ökosystem. Der Einstieg ist schneller.

2.4 SEO

• Traditionelles WooCommerce: Liefert SEO-freundliches HTML und Metadaten standardmäßig aus dem Server.
• Pure Client-Side SPA: Erhöht das Risiko. Google kann JavaScript zwar rendern, aber der Inhalt hängt von der Rendering-Warteschlange, der API-Verfügbarkeit und der korrekten Implementierung ab. Zu den Risiken gehören:
  • Fehlender Produktname und Beschreibung im initialen HTML.
  • Verspätetes Setzen von Title/Canonical/Open-Graph-Tags.
  • Soft-404-Fehler.
  • Bei API-Problemen sieht der Crawler eine leere Seite.

Google betrachtet dynamisches Rendering (Anliefern von Pre-Rendered-HTML nur für Bots) als eine Übergangslösung und empfiehlt stattdessen SSR, SSG oder Hydration .

Die richtigen Lösungen:

1. SSG/ISR für Produkt-, Kategorie- und Inhaltsseiten.
2. SSR für Routen, die dynamische Daten benötigen.
3. CSR nur für den Warenkorb und personalisierte Elemente.
4. Serverseitige Generierung von title, canonical und JSON-LD (Product, Breadcrumb, Organization).
5. Echte 404/410-Statuscodes für nicht existierende Ressourcen.
6. XML-Sitemaps, robots.txt, Paginierung und Weiterleitungen.
7. Testen des gerenderten HTMLs und Validierung mit der Google Search Console.

2.5 Wartung

• Custom: Volle Kontrolle, aber auch volle Verantwortung. Jede Änderung an einem Feld kann Auswirkungen auf mehrere Clients haben. Kein Plugin-Konflikt, aber hoher Engineering-Aufwand.
• WooCommerce: Core und Admin werden von der Community gewartet. Jedes Update von WordPress, WooCommerce, Theme und Plugins erfordert ein gründliches Staging-Testing.

2.6 Hosting-Kosten

• Custom: Frontend kann günstig per CDN ausgeliefert werden, aber das Backend benötigt Rechenleistung, Datenbank, Objektspeicher, E-Mail-Dienste und mehr. Die Betriebskosten können höher sein.
• WooCommerce: Läuft oft auf einem einzelnen Managed-WordPress-Host. Bei geringem Traffic ist dies einfacher und günstiger.

2.7 Skalierbarkeit

• Custom: Durch die Trennung von Frontend und Backend können CDN, API und Datenbank unabhängig skaliert werden. Die Skalierung des Checkouts (Transaktionen, Lagerbestände, Zahlungs-Idempotenz) ist jedoch komplex.
• WooCommerce: Kann mit gutem Hosting, Caching und Datenbankoptimierung auch skalieren. Der Flaschenhals sind oft dynamische Requests, Plugin-Hooks und die PHP-Ressourcen.

2.8 Entscheidungsmatrix

2.9 Handlungsempfehlung

• Ziel: Schneller Marktstart, kleines Team, standardisierte Abläufe → Verwenden Sie traditionelles WooCommerce mit einem schlanken Theme, wenigen Plugins, Managed Hosting und einem guten Cache.
• Ziel: Eindeutige Markenidentität, eigener Builder, Multi-Channel, erfahrenes Team → Bleiben Sie beim Custom-Ansatz, aber ersetzen Sie die reine SPA durch ein SSR/SSG/ISR-Framework.
• Nicht empfohlen: „Headless WooCommerce“ nur aus Prestigegründen. Dies vereint die Kosten beider Welten (WordPress-Wartung + Custom-Frontend-Entwicklung), ohne einen klaren Mehrwert zu bieten.

Für den analysierten Shop ist der vielversprechendste Weg die Beibehaltung einer Custom-Commerce-Denkweise, aber die Neukonzeption des Storefronts mit einem hybriden Rendering-Ansatz. Der Builder und die Markenidentität sind bereits Kernkompetenzen. Was geändert werden muss, sind das Rendering, das Datenmodell, die Checkout-Korrektheit und der Betrieb.

3. Die Neukonzeption: Ein Leitfaden für die neue Architektur

3.1 Grundprinzipien

Die neue Architektur sollte die bestehenden Geschäftsanforderungen und Daten (auf die der Eigentümer das Recht hat) nutzen, aber nicht den dekompilierten Code, die Modulstruktur oder private Symbole der alten Implementierung kopieren.

Wiederverwendbare Ideen:

• Katalog-, Kategorie- und Produktdetailseiten
• Homepage auf Basis von Blöcken
• Layout mit Header/Footer/Navigation
• Coupons, Newsletter, Kontaktformulare, Bewertungen, Tracking
• PayPal Create/Approve/Capture
• Versandtarife und Store-Einstellungen

Von Grund auf neu machen:

• Pfad-Namen und Antwort-Envelopes der API
• Datenbankmodell für Varianten und Lagerbestand
• Komponenten-Registry und Builder-Schema
• Rendering-Strategie
• State-Machine des Checkouts
• Cache-Invalidierung
• Sicherheit, Beobachtbarkeit und Test-Suite

3.2 Empfohlener Stack

Storefront:

• Next.js App Router + React + TypeScript für Server Components, SSR, SSG/ISR und Client Components in interaktiven Bereichen.
• Zod für Validierung an den Schnittstellen.
• TanStack Query nur für clientseitige Zustände, die eine Aktualisierung benötigen (kein erneutes Abrufen bereits gerenderter Daten).
• CSS Modules oder Tailwind CSS (ein System wählen) und Laufzeit-CSS-in-JS vermeiden.
• Bildoptimierung über CDN/Objektspeicher mit klaren Breiten- und Formatangaben.

Hinweis: Next.js ist nicht die einzige Option. Alternativen wie Remix oder jedes andere SSR-Framework mit ähnlichen Fähigkeiten sind ebenfalls geeignet.

Backend:

• NestJS mit Fastify-Adapter + TypeScript oder ein modularisiertes Fastify, wenn weniger Abstraktion gewünscht ist.
• PostgreSQL als Source of Truth.
• Drizzle ORM oder Prisma für Migrations und typsichere Queries.
• Redis nur bei tatsächlichem Bedarf für Caching, Distributed Locks oder Ratenbegrenzung.
• BullMQ (oder ein Äquivalent) für E-Mail, Webhook-Retrys, Analysen und Abgleichsprozesse.
• S3-kompatibler Objektspeicher für Medien; die Datenbank speichert nur Metadaten/Schlüssel.
• OpenTelemetry + strukturierte Logs + Fehler-Tracking für die Nachverfolgung von Requests, Checkouts und Zahlungsversuchen.

Deployment:

• Storefront hinter einem CDN/Edge-Cache.
• API in einem eigenen Container/Dienst.
• Verwaltetes PostgreSQL mit Point-in-Time Recovery.
• Objektspeicher getrennt vom Container-Dateisystem.
• Preview/Staging-Umgebungen mit PayPal-Sandbox und eigener Datenbank.
• Geheimnisse über einen Secret Manager, nicht im Repository.