Headless WooCommerce mit Astro

Headless WooCommerce ist kein zweiter Shop. wp-admin, Bestand, Bestellungen und Gateways bleiben. Das HTML, das der Kunde lädt, kommt nicht mehr aus einem PHP-Theme. Astro 7 druckt den Katalog. Die Kasse bleibt, wenn der Shop Geld verdienen soll, auf WooCommerce.

Ein klassischer WooCommerce-Request führt PHP aus, trifft den Object-Cache, die Plugin-Liste und das Theme, für eine Produktseite, die seit Dienstag unverändert ist. HTML-Cache vor der Origin räumt davon schon viel ab. Headless ist der nächste Schnitt: der Katalog wird ein statischer Baum, der Warenkorb eine kleine Island, das Geld landet weiter auf der Origin, die schon im PCI-Scope sitzt.

Dieser Text ist die Trennung. Cache-Schichten, TTFB und Feld-LCP stehen im Performance-Leitfaden Headless WooCommerce mit Astro. Die kommerziellen Flächen sind WooCommerce-Entwickler und Astro-Entwickler. Dieselbe Systemtrennung ohne Warenkorb steht im Headless-WordPress-Architekturleitfaden. WPPoland ist die Agentur, die diese Trennung baut. Wir verkaufen kein Theme und kein Hosting-Siegel.

#Was in WooCommerce bleibt

Das Backoffice wandert nicht. Produkte, Varianten, Bestand, Gutscheine, Bestellungen, Erstattungen, Berichte. Stripe, Klarna, PayPal, lokale Gateways. Table-Rate-Versand. Steuer-Plugins. ERP-Konnektoren, die in Bestellungen schreiben. Das ist PHP, und das soll PHP bleiben.

Was geht, ist das Storefront-Theme: header.php, das Produkt-Template, das Mini-Cart-Widget, Elementor auf der Startseite, das Zoom-Plugin, das Karussell „komplettiere den Look“, das 200 KB lädt, um drei SKUs zu zeigen.

Redakteure behalten dasselbe wp-admin. Wenn sie das nicht tun, sind Sie nicht headless gegangen. Sie haben ein zweites PIM gebaut, und im dritten Monat hassen Sie es.

Für einen deutschen Shop sitzen dort zusätzlich Felder, die kein Astro-Build erfinden soll: Grundpreis, Pfand, GTIN, USt-IdNr. des Käufers, OSS-Steuerklassen, Versandklassen für DHL-Paket und Warenpost. Germanized oder German Market schreiben diese Daten in Produktobjekte und Bestellungen. Der Katalog darf den Bruttopreis als Merchandise-Zahl drucken. Die rechtlich bindende Zeile entsteht an der Kasse.

xmlrpc und die öffentliche REST-Users-Route brauchen dieselbe Härtung wie jede WordPress-Origin. Headless versteckt wp-admin nicht. Access davorsetzen. Das Katalog-CDN ist keine Firewall.

Bestellmails, PDF-Rechnungen, DATEV-Export, Stornos: alles Origin. Ein Astro-Host, der „Bestellung eingegangen“ nachbaut, hat in Woche zwei eine abweichende MwSt.-Zeile. Dann schreibt die Buchhaltung Tickets statt der Redaktion.

Mitgliedschaften und Abos leben in WooCommerce. Astro darf „Sie haben Zugriff“ nur zeigen, wenn es fragen kann. Malt das Membership-Plugin Inhalte, indem es the_content in PHP wickelt, liegen diese URLs nicht in Ihrem SSG. Entweder exponieren, oder die URLs auf WordPress lassen.

#Das Plugin, das mit dem Theme stirbt

Das ist die Inventur, die niemand machen will, und das ist das ganze Risiko.

Stirbt mit dem Theme (als Island neu bauen, oder streichen):

• Variations-Swatches, die das Dropdown durch Farbpunkte ersetzen
• Quick-View und Ajax-In-den-Warenkorb in der Loop
• Produktbild-Zoom und 360-Viewer
• Upsell-Popups, Fake-Knappheitsbalken, „andere kauften auch“-Widgets, die in woocommerce_after_shop_loop drucken
• Page-Builder auf Startseite und Landing-SKUs
• One-Page-Checkout-Plugins, die die checkout-Templates übernehmen
• Theme-Footer mit Trusted-Shops-Widget, das nur HTML klebt und keine Bestellnummer kennt
• Cookie-Banner, die nur im Theme-Header sitzen und auf der PHP-Kasse fehlen

Bleibt (API oder Webhook, kein Theme):

• Zahlungsgateways
• Versand und Abholung (DHL, Hermes, Filiale, Table-Rate-Versand)
• Steuer (inklusive OSS)
• Subscriptions und Memberships, solange der Status abgefragt und nicht vom Plugin-CSS gemalt wird
• Klaviyo oder Mailchimp über Bestell-Hooks
• ERP (siehe WooCommerce-ERP-Integration)
• Germanized- und German-Market-Daten im Auftrag, PDF, Versandetikett

Wenn die Conversion-Tricks des Shops in der ersten Liste leben, ist Headless ein Redesign, kein Speed-Projekt. So kalkulieren. Der WooCommerce-Entwickler-Umfang sagt diese Trennung offen. Wir haben einen Shop „headless“ gesehen, der das alte Theme für die Kasse wieder einschaltete, weil das One-Page-Plugin das eigentliche Produkt war. Das sind zwei Storefronts. Nicht tun.

Nützlicher Test: auf Staging das Theme deaktivieren und eine Produkt-URL als ?theme=noop oder mit Blank-Theme laden. Was noch da ist (Preis, Bestand, In-den-Warenkorb über Store-API), behalten Sie. Was verschwand (Swatches, Badges, Lieferzeit-HTML), ist Arbeit. Ist die verschwundene Liste der Grund, warum Kunden kaufen, Islands budgetieren. Ist es Dekoration, streichen.

Composites, Bundles und Product-Add-ons sind die Grauzone. Manche exponieren REST, manche filtern nur woocommerce_add_to_cart. Wenn In-den-Warenkorb eines Bundles auf der Store-API 404 liefert, ist diese SKU nicht katalogstatisch, bis jemand das Mapping schreibt. Das nicht am Launch-Morgen entdecken.

Ein Mode-Shop, den wir auf Staging so getestet haben, verlor mit dem Theme die Lieferzeit „ein bis drei Werktage“ unter dem Button, die Packstation-Hinweiszeile und die Farbpunkte. Der Preis und der Warenkorb-Endpunkt blieben. Drei Wochen Island-Arbeit, weil die Farbpunkte der eigentliche Kaufgrund waren. Der Hinweis „1-3 Werktage“ war Theme-HTML ohne Tracking zur Versandklasse. Den haben wir nicht nachgebaut. Die Versandklasse bleibt ein Checkout-Feld.

#Astro 7 für den Katalog

Astro 7 liefert standardmäßig HTML und CSS. JavaScript nur dort, wo Sie eine Island markieren.

Katalog, der statisch sein soll:

• Start, Kategorie, Produkt, Content, Policy-Seiten
• getStaticPaths aus der Produktliste beim Build
• AVIF aus der Mediathek, sizes passend zum Grid, nicht 100vw auf einem 320-px-Thumb

Islands:

• In-den-Warenkorb, Menge, Variantenwähler
• Mini-Cart
• Suche, die einen Index trifft, nicht PHP ?s=
• Vielleicht ein PayPal-Button auf einem eigenen Zahlungsschritt, wenn Redirect wirklich nicht geht

client:visible auf In-den-Warenkorb. client:idle auf Suche. Eine Produktseite, die ein komplettes Icon-Pack in die Island importiert, hat den Punkt schon verloren. Dieselbe Regel wie jedes andere Astro-6-Front: die Island ist eine Komponente, kein Freibrief, die Seite zu hydratisieren.

Rebuilds: ein Produkt-updated-Webhook baut diesen Pfad neu, oder eine kleine Menge Pfade (Produkt, seine Kategorien, Start wenn sie merchandised). Vollkatalog-Rebuilds alle zehn Minuten sind der Moment, in dem Leute merken, dass sie 40 000 SKUs haben. Inkrementell oder on-demand. Cloudflare oder der Host, den der Stack schon nutzt. Nicht „Vercel, weil das Tutorial das sagte“, wenn der Rest schon auf Cloudflare liegt.

Suche: PHP ?s= ist ein PHP-Treffer. Auf einem statischen Katalog ist Suche entweder ein Client-Index (winzige Kataloge), ein externer Index (Algolia, Meilisearch, Typesense) aus derselben Payload wie SSG, oder eine Store-API- bzw. REST-Abfrage durch eine Island. Die Suchbox nicht nach WordPress schicken, wenn der Rest des Shops das nie tut. Facetten, die Live-Bestand brauchen, gehören neben die Buy-Box, nicht ins SSG-HTML.

Verwandte Produkte: wenn sie in wp-admin merchandised sind, sind sie Daten. Beim Build abfragen. Wenn sie woocommerce_output_related_products aus dem Theme waren, waren sie nie Daten, sie waren ein Template. Als statischen Streifen aus derselben Kategorie neu bauen, oder streichen.

Der Bruttopreis auf der Produktseite ist Merchandise. „inkl. MwSt.“ im SSG-HTML ist eine Aussage über die Darstellung, nicht über die Kassenzeile. OSS rechnet auf Origin. Pro-Land-Preise nur SSG-en, wenn Sie auch pro-Land-Pfade SSG-en und invalidieren können. Die meisten Shops zeigen einen Katalogpreis und lassen WooCommerce die Steuer an der Kasse anwenden. Das ist der Default. Ein veralteter UK-Bruttopreis vor einem EU-Gast ist die Mail von der Buchhaltung.

Bilder bleiben in der WordPress-Mediathek. Astro liest URLs, oder ein Build-Schritt kopiert AVIF. Kein zweites DAM erfinden, außer Sie haben schon eines. Das LCP-Bild ist weiter das Hero der Produktseite. Headless wählt das Format nicht für Sie. Feldmessung dazu steht im Performance-Leitfaden, nicht hier.

Vorschau: Redakteure müssen ein Entwurfsprodukt auf dem Astro-Host sehen. Ein Webhook oder ein Preview-Token, der ein Produkt von Origin holt, reicht. Heißt Vorschau „in wp-admin einloggen und den Customizer nutzen“, ist die Trennung nicht fertig, und sie verlangen das alte Theme zurück.

JSON-LD für Product kommt aus derselben Payload wie die Seite. Nicht einmal GraphQL für HTML und einmal REST für Schema. Google sieht den Drift. Canonicals zeigen auf die Astro-URL. canonicalUrl in einem alten Theme-Header, der noch antwortet, ist ein Split-Signal.

#Store-API gegen GraphQL

Zwei Leitungen. Sie zu mischen ist die übliche selbst zugefügte Wunde.

Katalog-Build: WPGraphQL plus WooGraphQL, oder der REST-Products-Endpunkt, zur Build-Zeit. Eine Query pro Produktseite. Name, Preise, Bestandsstatus, Bilder, Kategorien, Attribute. Nicht den Warenkorb.

Warenkorb und Session: WooCommerce Store-API (/wp-json/wc/store/v1/cart). Sie besitzt das Cart-Cookie, Nonces, Gutscheine, Versandberechnung. Dieses Cookie muss auf der Origin liegen, die später die Kasse übernimmt. Ist die Astro-Site shop.example.de und Woo cms.example.de, haben Sie ein Cookie-Problem, bevor Sie ein React-Problem haben. Gleiche Site, oder ein dokumentierter Proxy.

Wir sehen Teams, die In-den-Warenkorb über WooGraphQL-Mutations legen, weil der Katalog schon GraphQL spricht. Dann zeigt die WooCommerce-Kasse einen leeren Korb. Die Session ist nie mitgegangen. Store-API für den Warenkorb. GraphQL für die SSG-Payload. Das an die Wand schreiben.

Same-Site-Cookies: liegt Astro auf der Apex und WordPress auf wp., die Cart-Cookie-Domain explizit setzen und /wp-json/wc/store/ zur Origin proxen. CORS auf der Store-API ist kein Ersatz für das Cookie. SameSite=Lax auf einem Cross-Site-Checkout-Redirect sieht aus wie „Klarna geht auf Staging“ (gleicher Host) und „leerer Warenkorb in Produktion“ (zwei Hosts). Ein Hostname für den Käufer, interner Hostname für wp-admin.

Nonce-Ablauf auf einer statischen Seite ist ein echter Bug. Die Cart-Island muss beim Hydrate einen frischen Nonce von der Store-API holen, nicht einen von heute Morgen in SSG-HTML backen. Gebackene Nonces liefern nach ein paar Stunden 403, und der Button „tut nichts“.

Bestand beim Build ist ein Snapshot. Eine ausverkaufte Größe, die noch im HTML steht, ist eine Erstattung. Webhook woocommerce_product_set_stock (oder das Varianten-Äquivalent) muss diesen Pfad invalidieren. Wenn Sie das nicht können, die Buy-Box nicht SSG-en. Buy-Box zur Request-Zeit aus der Store-API rendern, weiter als kleine Island. Katalog-HTML kann statisch bleiben.

Gutscheine gehören in dieselbe Session wie der Warenkorb. Ein GraphQL-Coupon, der den Preis auf der Produktseite malt, ohne den Cart-Nonce zu setzen, sieht auf der Kasse anders aus. Der Kunde hat einen anderen Rabatt erwartet. Store-API wendet den Code an, WooCommerce bleibt Source of Record.

Versandkosten im Mini-Cart sind Annahmen, bis die Postleitzahl da ist. Table-Rate und DHL-Paket hängen an PLZ und Warenkorbwert. Die Island darf schätzen. Die Kasse rechnet. Eine feste Versandzeile im SSG-HTML ist Merchandise, oft falsch für Packstation und Warenpost.

#Trusted Shops, PayPal und die Kasse, die deutsch bleibt

Deutsche Shops bauen die Kasse nicht nebenbei in Astro nach. PayPal, Klarna, Rechnung bzw. Klarna-Rechnung, das Trusted-Shops-Trustbadge, Widerruf und oft DHL- oder Hermes-Widgets haken in woocommerce_thankyou und in die Checkout-Templates. Hybrid ist der Default. Das ist kein Rechtsrat. Das ist eine Inventur von Hooks.

Redirect auf /checkout/. Katalog und Cart-Island leben auf Astro. „Zur Kasse“ ist ein Link auf das WooCommerce-Checkout-Template, am HTML-Cache vorbei, mit gesetztem Store-API-Cookie. Jedes Gateway-Plugin, jedes Steuer-Plugin, jede „Bestellung eingegangen“-Mail bleibt. PCI-Scope bleibt, wo er war. Trusted-Shops, Rechnungs-PDFs, ERP auf woocommerce_thankyou, alles feuert weiter.

Was an dieser PHP-Kasse in einem DACH-Shop hängt, und warum das kein Island-Nachmittag ist:

• PayPal. WooCommerce PayPal Payments hängt Smart Buttons und oft PayPal-Express in Checkout- und Cart-Templates. Billing Agreement, Pay Later, 3-D-Secure-Return. Der Return landet auf Origin, nicht auf einem Astro-Pfad, den die Gateway-Doku nie gesehen hat.
• Klarna. Sofort, Ratenkauf, Rechnung. Das Payments-Plugin rendert auf dem Checkout-Template. Die Session, die Klarna kennt, ist die Woo-Order, nicht ein Fetch in einer Island.
• Rechnungskauf. Ratepay, Billie, Klarna-Rechnung. Scoring, Bonität, Rechnungs-PDF. Alles Order-Lifecycle auf Origin.
• Trusted-Shops. Das Trustbadge auf der Danke-Seite braucht Bestellnummer, Betrag, Zahlungsmethode, oft Kundenmail. Der Plugin-Hook ist woocommerce_thankyou. Ein Astro-„Danke“ ohne diesen Hook liefert Reviews und Käuferschutz nicht. Das Widget im Theme-Footer ist Dekoration. Das Trustbadge nach Bestellung ist der Vertrag, den der Händler mit Trusted-Shops hat.
• Widerruf. Belehrung, Checkbox, später das Formular. Germanized und German Market hängen das an Checkout-Felder und Mails. Eine selbstgebaute Astro-Kasse muss dieselben Felder, dieselben Zeitpunkte, denselben Mail-Anhang treffen. Wir tun das nicht als Default. Das ist kein Rechtsrat und keine Checkliste für Abmahnungen. Es ist der Grund, warum die Kasse PHP bleibt.
• DHL und Hermes. Packstation, Filiale, Wunschtag, Ablageort. Felder im Checkout, Widgets auf Danke, Labels im Admin. Die Plugins erwarten checkout-Templates und Thank-you. Ein Headless-Checkout, der nur Straße und Hausnummer kennt, bricht Packstation.

Custom-Checkout in Astro heißt, Sie bauen neu:

• Adressprüfung und Länderfelder, plus Packstation
• Versandarten, die mit PLZ wechseln
• Steuer und OSS
• Gateway-JS (PayPal, Klarna, lokale Methoden)
• 3-D-Secure-Returns
• Fehlgeschlagene Zahlungen, Retry
• Order-Pay-Links aus Mails
• Trustbadge, Widerrufs-Checkbox, AGB-Version des Händlerbund- oder IT-Recht-Plugins

Wir haben das für Shops gebaut, die einen Schritt brauchten, den kein PHP-Template halten konnte. Das ist ein Produkt. Das ist nicht der Default. Der Default ist hybrid: statischer Katalog, Island-Warenkorb, PHP-Kasse.

Ein Shop mit Germanized, PayPal und Trusted-Shops, den wir angefasst haben, wollte „die Kasse auch noch headless“. Nach zwei Sprints lagen Packstation, Trustbadge und die Widerrufs-Checkbox wieder auf WooCommerce. Der Katalog blieb auf Astro. Das war kein Rückzieher. Das war die Trennung, die der Plugin-Stapel schon vorgegeben hatte.

MwSt. und OSS rechnen auf Origin. Ein statischer Euro-Preis auf der Produktseite ist Merchandise. Die Kassenzeile ist die bindende. Pro-Land-Preise nicht SSG-en, außer Sie SSG-en auch die Pfade und können sie invalidieren.

Bestellabschluss und Mein-Konto dürfen auf WooCommerce bleiben. „Headless“ heißt nicht „jede URL ist Astro“. Es heißt: die URLs, die die Anzeigen treffen, sind Dateien. /my-account/ hinter Access oder hinter Login ist als PHP in Ordnung.

Webhook-URLs (/?wc-api=, Stripe, Klarna, PayPal IPN) müssen Origin treffen, nicht das Astro-CDN. Diese Pfade am Cache vorbeileiten. Dieselbe Skip-Listen-Disziplin wie eine Cloudflare-WAF: jeder Skip hat einen Namen.

Händlerbund- und IT-Recht-Kanzlei-Plugins aktualisieren AGB-Texte auf Origin. Der Katalog darf Impressum und Datenschutzerklärung als statische Seiten führen, wenn der Build dieselben URLs 301-sauber hält. Die Checkbox „AGB gelesen“ gehört an die Kasse, nicht in eine Island, die den Text von vor drei Builds zeigt.

Wir geben in diesem Text keine Rechtsauskunft. Ob Ihre Belehrung, Ihr Impressum nach DDG und Ihr Widerrufsablauf haltbar sind, prüft die Kanzlei, die Sie schon bezahlen. Was wir prüfen, ist, ob der Hook nach dem Cutover noch feuert.

#Bestand, Cache

Statische Dateien auf einem CDN skalieren. Bestand nicht. Zwei Kunden, die die letzte SKU kaufen, sind ein Shop-Problem, kein Lab-Score.

Muster, das hält:

1. Katalog-HTML ist statisch, inklusive Preis, bis ein Webhook etwas anderes sagt.
2. Die Buy-Box fragt die Store-API nach stock_status, wenn die Island hydratisiert, oder Sie akzeptieren ein kurzes Stale-Fenster und gleichen an der Kasse aus (WooCommerce lehnt Oversell ab, wenn Sie das so konfiguriert haben).
3. Auftragserstellung ist Origin. ERP und Mail feuern dort.

„Unbegrenzt viele gleichzeitige Nutzer“ gilt für das HTML. Es gilt nicht für Kasse, Bestand, Datenbank. PHP auf den Checkout-Peak dimensionieren, den Sie wirklich haben (Drop, Newsletter, Black Friday). Das CDN nimmt die Karte nicht.

HTML-Cache vor einem klassischen Theme ist weiter der erste Hebel. Ist die Produktseite schon Datei plus AVIF, und der Brief lautet trotzdem „Headless, weil schnell“, zuerst den Performance-Leitfaden lesen. Headless macht aus einem 3-MB-PNG kein kleines Hero.

Invalidierung ist Teil der Architektur, nicht ein Cron. woocommerce_update_product trifft Produktpfad, Kategoriepfade, oft Start. woocommerce_product_set_stock trifft die Buy-Box. Ein Full-Purge nach jedem Lagerbuchungstakt ist, wie Shops ihren CDN-Etat verbrennen. Tags oder präzise Pfade.

Wenn der Bestand aus einem ERP kommt (siehe WooCommerce-ERP-Integration), ist WooCommerce weiter Source of Record für den Shop, nicht Astro. Der Webhook, der den Edge räumt, hängt am Woo-Event, nicht am ERP-File. Sonst zeigt Astro 12 Stück, Woo 0, das ERP 7, und der Support erklärt drei Zahlen.

Variantenbestand ist der häufige Blindspot. Der Parent ist „auf Lager“, Größe M nicht. SSG, das nur den Parent malt, verkauft M. Die Island muss die Variation fragen, oder die Kasse räumt hinterher und der Kunde ist weg.

#Wann nicht headless

• Katalog unter ein paar Dutzend SKUs, kein Traffic-Problem, Customizer-Edits jede Woche
• Das Storefront ist die Plugin-Liste (Builder, One-Page-Checkout, Live-Chat im Theme)
• Niemand im Team besitzt das Astro-Repo nach Launch
• Der Brief ist ein Lab-Screenshot, und die Produktseite hat schon HTML-Cache und AVIF
• Die Kasse ist das Produkt: Germanized plus Trusted-Shops plus Packstation plus One-Page, und niemand darf daran rühren
• Redaktion erwartet, Startseiten in Elementor zu bauen, ohne auf einen Frontend-Deploy zu warten

Dann: Plugin-Diät, HTML-Cache, Bildpipeline, Consent-Slot. Billiger, umkehrbar. Headless ist eine Systemtrennung. Sie haben jetzt zwei Deploys, zwei Previews, zwei Fehlerbilder. Das lohnt, wenn das Theme der Engpass ist und der Katalog überwiegend gelesen wird.

Abos und Mitgliedschaften: der Anspruch lebt in Woo. Die Astro-Seite kann „Sie haben Zugriff“ zeigen, wenn sie fragen kann. Malt das Membership-Plugin Content, indem es the_content in PHP wickelt, liegt dieser Content nicht in Ihrem SSG. Exponieren oder diese URLs auf WordPress lassen.

B2B mit Nettopreisen pro Kundengruppe ist ein zweites Warnschild. Der Katalogpreis im SSG ist öffentlich. Die echte Nettozeile sitzt in der Session. Entweder Buy-Box nach Login aus der Store-API, oder diese SKUs nicht headless. Ein geleakter Netto-HTML-Build ist peinlicher als ein langsames Theme.

Wenn Marketing jede Woche eine Landing in einem Page-Builder braucht, ist Astro die falsche Fläche dafür. Der Katalog kann trotzdem Astro sein. Die Kampagnen-URLs bleiben PHP. Headless heißt nicht, den Builder zu verbieten. Es heißt, ihn vom Produkt-URL zu nehmen.

#Migrationsreihenfolge

1. Inventur. Plugin-Liste in bleibt / stirbt / unbekannt. Unbekannt wird ein Spike, keine Überraschung am Launch.
2. API am Live-Shop. Store-API ist auf modernem WooCommerce schon da. GraphQL, wenn der Katalog-Build sie will. Kunden sehen nichts.
3. Astro-Katalog auf Staging, echte Produktdaten, noch keine Kasse. Permalinks vergleichen. Trailing-Slash und Category-Base-Kämpfe finden Sie hier, nicht in Woche acht.
4. Cart-Island plus Cookie gegen Staging-Origin. In-den-Warenkorb, Gutschein, leerer Korb. Dann, und erst dann, Kasse verlinken.
5. Kasse weiter auf Woo. Cache umgehen. Gateways in einer echten Sandbox. Bestellmails. Erstattungspfad. Trusted-Shops-Testbestellung. Packstation-Feld. Widerrufs-Checkbox. PayPal- und Klarna-Returns.
6. SEO. 301-Map, Canonicals, Produkt-JSON-LD aus denselben Feldern wie die Seite, Sitemap der Astro-URLs. Eine Produkt-URL vor Cutover inspecten. lastmod nicht auf 10 000 SKUs erfinden.
7. Katalog-DNS schwenken. wp-admin und Kasse auf Origin lassen. Bestands-Webhooks eine Woche beobachten.

Blue-Green des Katalogs ist einfach (es sind Dateien). Blue-Green der Kasse ist dasselbe wie heute: Sie haben schon eine. Keine zweite erfinden.

Cutover-Woche ist vor allem DNS und 301s, nicht React. Ein kurzes Fenster halten, in dem das alte Theme noch per Header-Bypass antwortet, damit Sie eine SKU vergleichen können. In dem Moment, in dem beide Storefronts In-den-Warenkorb gegen dieselbe Store-API machen, doppeladdieren alte Tabs. Altes Theme drainen: 301, dann 410 auf Theme-Assets, dann löschen. Dual-Run „nur zur Sicherheit“ ist der Weg, auf dem der Customizer zurückkommt.

Rechtstexte und Policy-URLs in der 301-Map nicht vergessen. /widerruf/, /agb/, /impressum/, /datenschutz/ sind in DACH oft verlinkt aus Mails und Trusted-Shops. Ein 404 dort nach Cutover ist lauter als ein 404 auf einer alten Kategorie.

Gateways in Sandbox heißen: PayPal Developer, Klarna Playground, Trusted-Shops-Testbadge. Eine Live-PayPal-Zahlung auf Staging, „nur um zu sehen ob es geht“, vermischt PCI-Scope und Logs. Nicht tun.

#Audit und Lektüre

Feld-LCP, Cache-Schichten und Store-API-Payload-Gewicht: Performance-Leitfaden. Die Systemtrennung: diese Seite. Die Fläche WooCommerce-Entwickler ist die kommerzielle Katalogarbeit. Astro-Entwickler ist das Front. ERP-Integration ist, was nicht brechen darf, wenn das Theme stirbt. Headless-Architektur ist dieselbe Trennung ohne Warenkorb.

Eine vertrauliche Umsetzung (Cloudflare, Store-API, Kasse auf Woo) steht in der Headless-WooCommerce-Fallstudie. Zahlen, die in diesem Text nicht stehen, sind keine Zahlen, die wir haben.

Auditfragen, die wir vor einem Angebot stellen:

• Welche Plugins schreiben HTML in Loop, Produkt, Warenkorb, Kasse, Danke?
• Welche davon haben REST oder Store-API, welche nur Template-Hooks?
• Darf die Kasse auf WooCommerce bleiben, inklusive PayPal, Klarna, Trusted-Shops, DHL/Hermes, Widerruf?
• Wer besitzt nach Launch das Astro-Repo, und wer drückt den Produkt-Webhook?
• Wo liegt der Bestand nachts, wenn das ERP schreibt?

Ohne diese Liste ist „wir machen Headless“ ein Theme-Relaunch mit zwei Hosts.

#Fazit

WooCommerce bleibt der Shop. Astro 7 bleibt der Katalog. Warenkorb als Island auf der Store-API. Kasse auf PHP, in DACH inklusive PayPal, Klarna, Trusted-Shops und Versand-Widgets. Plugins, die das Theme gemalt haben, werden neu gebaut oder gestrichen. Plugins, die das Geschäft betrieben haben, bleiben. GraphQL baut Seiten. GraphQL hält den Korb nicht.

Schreiben Sie mit der Plugin-Liste und der Frage, ob die Kasse auf WooCommerce bleiben darf. Lautet die Antwort „sie muss identisch zum One-Page-Checkout des Themes aussehen“, kaufen Sie ein Redesign. Die Fläche WooCommerce-Entwickler ist, wo dieser Umfang anfängt.

Messwerte, Cache-Tiers und das Gewicht der Store-API-Payload gehören in den Performance-Leitfaden. Dieser Text endet, wo die Origin den Auftrag schreibt.