Von WooCommerce zu einem eigenen Shop wechseln

WooCommerce ist WordPress mit einer Kassa, und die Datenbank gehört dir schon

WooCommerce ist ein Plugin, das aus einer WordPress Seite einen Shop macht. Es ist kostenlos, quelloffen unter der GPLv3, läuft auf deinem eigenen Hosting und steckt in mehr als 7 Millionen WordPress Seiten, was es zur meistgenutzten Art macht, online zu verkaufen.¹ Wenn du einen kleinen, inhaltsgetriebenen Shop darauf betreibst und jemand die Plugins aktuell hält, will dich dieser Artikel nicht umsiedeln. Ein gut geführter WooCommerce Shop ist ein völlig brauchbarer Shop, und ich sage dir gegen Ende genau, wer bleiben soll.

Der Dreh bei WooCommerce, und der Grund, warum es sich von jeder gehosteten Plattform in dieser Serie unterscheidet, ist die Frage des Besitzes. Bei Shopify oder BigCommerce liegen deine Daten auf fremden Servern, und du bekommst sie nur über den Export heraus, den man dir zugesteht. Bei WooCommerce ist der Shop eine WordPress Installation auf Hosting, das du bezahlst, und die Daten liegen in einer MySQL Datenbank, die du längst erreichst. Die übliche Überschrift eines Umzugsartikels, "komme ich an meine Daten", trifft also kaum zu. Du kommst dran. Der Export ist der sauberste jeder Plattform, über die ich schreibe.

Das verändert die ganze Frage. Bei WooCommerce ist der Grund für einen Umzug fast nie, dass du von deinen Daten ausgesperrt bist. Es ist, dass der Unterbau unter dem Shop zu einem Wartungs und Risikoproblem geworden ist, und dass der Besitz der Dateien ihn nicht wartbar macht. In diesem Artikel geht es um genau diesen ehrlichen Tausch: wann ein zerbrechlicher Turm aus Plugins es wert ist, durch eine einzige eigene, getestete Rails Anwendung auf Solidus ersetzt zu werden, und wann nicht. Für das plattformunabhängige Detail, wie jede Datenart wirklich umzieht, verlinke ich die Datenart Artikel an Ort und Stelle, statt sie zu wiederholen. Die ganze Landkarte liegt in was mitkommt und was nicht.

Was dir gehört, und das ist wirklich fast alles

Drei Türen führen aus einem WooCommerce Shop hinaus, und anders als bei einer gehosteten Plattform hast du die Schlüssel zu allen dreien.

Die erste ist die Datenbank. WooCommerce speichert seine Daten in deiner WordPress MySQL Datenbank, also kannst du mit Datenbankzugriff Kunden, Produkte, Bestellungen und fast alles andere direkt auslesen. Seit WooCommerce 8.2, erschienen im Oktober 2023, speichern neue Shops Bestellungen in eigenen Tabellen wie wc_orders statt in den alten WordPress Tabellen posts und postmeta, was die Bestelldaten sauberer lesbar macht als früher.² Produkte liegen weiterhin in der WordPress Struktur aus posts und postmeta, die sich besser lesen als beschreiben lässt.

Die zweite ist die REST API. WooCommerce liefert eine REST API unter /wp-json/wc/v3/, die aktuelle Version ist v3, und sie deckt Produkte, Bestellungen, Kunden, Gutscheine, Rückerstattungen und mehr ab.³ Über HTTPS authentifizierst du dich mit einem Consumer Key und Secret als Basic Auth, die du unter WooCommerce, Einstellungen, Erweitert, REST API erzeugst und dabei Lese, Schreib oder Lese und Schreibrechte für einen Benutzer wählst. Über reines HTTP greift stattdessen eine einbeinige OAuth 1.0a Signatur mit HMAC-SHA1 oder HMAC-SHA256.³ In die Kern REST API ist kein Limit pro Minute eingebaut. Das einzige Limit, das WooCommerce dokumentiert, betrifft die neuere Store API und ist standardmäßig aus: eingeschaltet über einen Filter deckelt es POST Anfragen auf 25 in einem Fenster von 10 Sekunden, mit der strengeren Option von 3 Checkout Anfragen pro 60 Sekunden.⁴ In der Praxis ist die Obergrenze eines großen Exports dein eigener Server und dein Hoster, nicht WooCommerce, ein großer Abzug ist also eine Frage des höflichen Blätterns und kein Kampf gegen ein Kontingent.

Die dritte ist der eingebaute Produkt CSV Importer und Exporter. WooCommerce bringt ein CSV Werkzeug für Import, Export und Massenaktualisierung von Produkten von Haus aus mit.⁵ Es behandelt einfache, variable, gruppierte, externe und herunterladbare Produkte, Bilder per URL, Kategorien, Attribute und Preise, und es liest und schreibt eigene Felder, wenn du den Spaltenkopf mit meta: voranstellst, etwa meta:product_depth.⁵ Beim Export setzt du ein Häkchen, um alle eigenen Meta Felder mitzunehmen.⁵ Das Werkzeug ist wirklich nützlich, und es hat ehrliche Kanten: nicht erkannte Spalten werden standardmäßig nicht importiert, der Importer kann weder Alternativtexte für Bilder setzen noch einem neuen Produkt eine bestimmte Post ID zuweisen, exportierte Variantennamen verlieren mitunter ihre Attributwerte, und die maximale Uploadgröße ist auf Serverebene gesetzt, sehr große Kataloge werden also in Blöcke geteilt.⁵

Zwischen diesen dreien sind Kunden, Produkte und Bestelldaten alle erreichbar. Das ist die leichteste Exportgeschichte der Serie, und das gehört klar gesagt, bevor der Rest des Artikels erklärt, warum Leute trotzdem gehen.

Das Eine, das nicht sauber herauskommt: Passwörter

Der einzige Export, den WooCommerce dir nicht sauber übergeben kann, ist der, den keine Plattform schafft. WordPress speichert nie ein Passwort. Es speichert einen Hash. Jahrelang waren das portable phpass Hashes mit dem Präfix $P$, und seit WordPress 6.8 werden neue und geänderte Passwörter mit bcrypt gehasht, geschrieben mit dem Präfix $wp$2y$, wobei ältere Hashes beim nächsten Login auf bcrypt umgehasht werden.⁶ Ein Hash ist eine Einwegfunktion, es gibt also nichts zu entschlüsseln und nichts, was man in das eigene Hashverfahren eines neuen Shops übertragen könnte. Der saubere Weg ist ein Passwort Reset beim ersten Login im neuen Shop, eine geplante Nachricht statt eines Problems. Der Artikel zu Kundenkonten zeigt, wie du diesen Reset als Neustart führst und nicht als Überraschung.

Der wahre Grund zu gehen ist der Plugin Turm, nicht die Daten

Wenn die Daten leicht herauskommen, warum dann gehen? Weil ein echter WooCommerce Shop selten nur WooCommerce ist. Er ist WordPress, plus WooCommerce, plus ein Zahlungs Plugin, plus eine Abo Erweiterung, plus ein Plugin für Rechtstexte, plus ein Bewertungs Plugin, plus ein Page Builder, plus ein Caching Plugin, plus ein Sicherheits Plugin, plus ein Backup Plugin, plus was auch immer die letzte Agentur hinzugefügt hat, um das Problem des Vorjahres zu lösen. Jedes davon muss sich mit jedem anderen vertragen, alle müssen aktuell bleiben, und der Shop bricht, sobald zwei davon nach einem Update uneins sind, das niemand anzuwenden wagte.

Das ist ein Wartungs und Risikoproblem, und es hat drei scharfe Kanten.

Die erste ist die Sicherheit. Patchstack zählte heuer rückblickend 11.334 neue Schwachstellen im WordPress Ökosystem für 2025, 91 % davon in Plugins und 9 % in Themes, nur sechs im WordPress Kern, und 46 % hatten zum Zeitpunkt der Offenlegung noch keinen Fix des Entwicklers.⁷ Der Shop ist nicht der WordPress Kern, der gut verteidigt ist. Der Shop sind das Dutzend Plugins drumherum, und jedes ist eine Tür, die du zuhalten musst. Eine Datenpanne, die personenbezogene Daten betrifft, ist wo machbar innerhalb von 72 Stunden an die Behörde zu melden, nach der DSGVO, also ist das ein Thema für die Geschäftsführung und nicht nur die Sorge eines Entwicklers.⁸

Die zweite ist die Leistung. Ein kleiner Katalog auf gutem Hosting läuft gut. Jenseits einiger tausend Produkte, eines regen Bestellflusses oder einer Lastspitze braucht der Unterbau aus WordPress und MySQL jene Art von Caching, Feintuning und Hosting Aufmerksamkeit, die das Wort kostenlos leise aus dem Preis frisst. Die Plattform wurde als Blogsystem mit angehängtem Shop gebaut, und unter Last verhält sie sich auch so.

Die dritte, und das ist der Kern, ist, dass der Besitz der Dateien den Unterbau nicht wartbar macht. Dir gehört ein Turm aus Teilen von einem Dutzend verschiedener Firmen, jede mit eigenem Releaseplan, keine für das Ganze verantwortlich. Wird eines davon aufgegeben, verkauft oder ändert seine Lizenz, ist das dein Problem, meist zum Tagessatz einer Agentur und meist unter Zeitdruck.

Die eigene Alternative ist nicht "dasselbe, nur meins". Sie hat eine andere Form. Ein Solidus Shop ist eine einzige Rails Anwendung, als Ganzes geschrieben und getestet, als Ganzes ausgerollt, in der der Zahlungsfluss, die Abo Logik und der Checkout Code sind, der dir gehört, statt Plugins, von denen du hoffst, dass sie sich noch vertragen. Du tauschst einen zerbrechlichen Turm gegen ein einziges eigenes Gebäude. Das ist der Tausch, und ob er sich lohnt, hängt ganz davon ab, wie schwer dein Turm geworden ist.

Die Fallen, die WooCommerce eigen sind

Ein Umzug weg von WooCommerce ist großteils leichte Daten und eine Handvoll wirklich harter Knoten. Die Knoten gehören benannt, bevor du beginnst.

Zahlungsanbieter und gespeicherte Karten. Jeder Zahlungsanbieter ist ein eigenes Plugin, und jedes legt seine Konfiguration und seine gespeicherten Kartentoken auf seine Weise ab. WooCommerce verwaltet gespeicherte Methoden über sein Zahlungstoken System, in dem Token in der Datenbank liegen und pro Kunde und, optional, pro Anbieter abgerufen werden, ein Token hängt also immer an dem Anbieter, der es erzeugt hat.⁹ Gespeichert ist eine Referenz, nie die rohe Karte, denn die Kartendaten liegen beim Abwickler. Die Folge für einen Umzug ist überall in dieser Serie dieselbe: ein Token ist für einen anderen Anbieter bedeutungslos, gespeicherte Karten ziehen also nur mit, wenn du denselben Abwickler behältst, und selbst dann nur zwischen Anbietern mit Zertifizierung nach PCI DSS Level 1, was etwa Stripe auf Anfrage macht, aber ohne die Abos oder die Zahlungshistorie.¹⁰ Das beste Ergebnis ist, den neuen Solidus Shop mit demselben Stripe oder Anbieterkonto zu verbinden, das der Shop schon nutzt, dann ziehen die hinterlegten Karten gar nicht erst um. Der Artikel zu Zahlungstoken hat das volle Detail.

Abonnements. Wiederkehrende Abrechnung läuft bei WooCommerce fast immer über die kostenpflichtige Erweiterung WooCommerce Subscriptions, eine jährliche Lizenz, die sich für automatische Verlängerungen mit mehr als 25 Zahlungsanbietern verbindet, wobei manuelle Verlängerungen mit jedem Anbieter möglich sind.¹¹ Der Haken für einen Umzug ist, dass automatische Verlängerungen davon abhängen, dass der Anbieter ein wiederverwendbares Token hält, ein Abo ist also nur so übertragbar wie das Token dahinter. Abonnements werden auf deiner eigenen Seite verwaltet und nicht im Konto des Anbieters, das heißt der Zeitplan, das nächste Abbuchungsdatum und die Abrechnungshistorie gehören dir zum Export, aber die Befugnis, die Karte erneut zu belasten, liegt beim Abwickler.¹¹ Das ist der härteste Knoten in einem WooCommerce Umzug, und es ist das Erste, was ich zuordne, nicht das Letzte. Der Artikel zu Abonnements geht durch, wie aktive Abonnenten ohne Lücke weiter abgerechnet werden.

SEO und die URL Struktur. WooCommerce nutzt WordPress Permalinks, und an ihnen hängen jahrelange Links und Rankings. Ein Umzug hält diesen Wert nur, wenn jede alte Produkt, Kategorie und Inhalts URL auf eine dauerhafte Weiterleitung zeigt, die geradewegs auf ihr neues Ziel verweist und mindestens ein Jahr bleibt, genau das, was Googles eigene Anleitung für einen Umzug mit URL Änderungen verlangt.¹² Auf den Shops, die ich baue, ist die Weiterleitungstabelle eine Datenbanktabelle mit einer Verwaltungsmaske, sie überlebt also jedes künftige Deployment, und dein eigenes Personal kann eine eintragen, wenn es in der Search Console einen Ausreißer entdeckt. Die Mechanik von Produkten, Slugs und Weiterleitungen steht im Artikel zu Produkt und Katalogdaten.

Inhalt, der keine Produktdaten sind. Das ist das WooCommerce eigene Aufräumen. Vieles, was wie Produktinformation aussieht, ist in Wahrheit die Ausgabe eines Page Builders: ein in Elementor oder einem ähnlichen Werkzeug beschriebenes Produkt legt sein Layout als Mauer aus Shortcodes und Meta in postmeta ab, nicht als saubere Felder. Eigene Felder, die ein Theme oder Plugin ergänzt hat, sind dasselbe. Nichts davon exportiert über das Produkt CSV als strukturierte Daten, weil es nie strukturierte Daten war. Teil eines guten Umzugs ist zu entscheiden, was echte Produktinformation war, die sauber mitzieht, und was Darstellung war, die ein Builder angeklebt hat, die im neuen Shop ordentlich neu gebaut wird, statt als Rauschen mitgeschleppt zu werden.

Was mitkommt, was Arbeit kostet, was festsitzt

Die ehrliche Form eines WooCommerce Umzugs in einer Tabelle.

Was	Wie es umzieht	Aufwand
Produkte, Varianten, Preise, Bilder, Kategorien	REST API, CSV Exporter oder direkter Datenbankzugriff	Gering, meist Zuordnen und Prüfen
Kunden und Adressen	REST API oder Datenbank, eine Zeile je Kunde	Gering
Bestellhistorie	wc_orders Tabellen oder REST API, seit HPOS sauberer	Gering bis mittel
Passwörter	Ziehen nicht um, Reset beim ersten Login	Geplant, nicht hart
Gespeicherte Karten und Token	Nur mit demselben Anbieterkonto	Hart, zuerst planen
Aktive Abonnements	Hängen am Anbieter Token, nicht am Shop	Am härtesten, zuerst planen
SEO Wert in den URLs	Volle Weiterleitungstabelle, 301 je alte URL	Mittel, die besten Tage des Projekts
Page Builder und eigene Felder	Neu gebaut, nicht migriert	Mittel, entscheiden, was echt war

Das Muster ist das Gegenteil einer gehosteten Plattform. Die Daten sind leicht, und die Geldfragen, Karten und Abos, sind der harte Teil, sie stehen also zuerst im Plan und nicht zuletzt.

Der ehrliche Umzugsplan

Ein Umzug weg von WooCommerce auf einen eigenen Solidus Shop läuft in derselben Reihenfolge wie jeder Shop Umzug, mit den WooCommerce eigenen Hinweisen eingewoben. Zuerst benenne die Person auf deiner Seite, die die Daten versteht, die weiß, warum die alten Produktcodes Endungen haben und welche Kunden Geschäftskunden sind. Ohne diese Person bekommst du einen schönen neuen Shop voller falscher Daten. Zweitens klär die harten Knoten vor allem anderen: welcher Anbieter bleibt, ob aktive Abonnements ihre Token behalten können und wie der Abo Zeitplan aussieht. Drittens baue den Shop und schreibe die Importskripte, und lass sie wieder und wieder gegen eine Kopie der echten Datenbank laufen, bis der finale Import keine Überraschungen mehr birgt. Viertens baue die Weiterleitungstabelle aus den letzten zwölf Monaten Verkehr, eine Zeile je URL, getestet. Fünftens lass beide Shops parallel laufen, mit eingefrorenem altem Katalog, probe die Umschaltung zweimal, schalte dann an einem ruhigen Wochentagvormittag um und lass den alten Shop dreißig Tage unberührt als Rückfalllösung. Die ganze Methode, die Abfolge der Umschaltung und die Fehler, die es zu vermeiden gilt, stehen im Artikel zu den Gesamtkosten über fünf Jahre, und der Pillar Artikel ist die Landkarte über allem.

Ein durchgerechnetes Beispiel

Pfotengut Tierbedarf (pfotengut.example) ist ein erfundener Shop in Linz, der Futter, Spielzeug und Zubehör verkauft, mit rund 900.000 Euro Jahresumsatz online, etwa 2.500 Produkten und einem wachsenden monatlichen Futterabo, auf das sich ein fester Kern treuer Kunden verlässt. Der Shop läuft seit sechs Jahren auf WooCommerce. Er funktioniert, aber die Inhaberin schläft nicht mehr gut. Es sind vierzehn aktive Plugins. Das letzte WordPress Update zerlegte für ein Wochenende das Verhältnis zwischen dem Abo Plugin und dem Bewertungs Plugin, und vor drei Monaten meldete ein Sicherheitsscanner ein aufgegebenes Plugin mit einer bekannten Schwachstelle ohne Fix, genau die Art Fall, die Patchstack zählt.⁷ Die Agentur, die ihn gebaut hat, ist weitergezogen. Die Inhaberin will kein größeres WooCommerce. Sie will aufhören, auf einem schwankenden Turm zu wohnen.

So würde ich ihren Umzug abwägen. Die Daten sind die leichte Hälfte. Ihre 2.500 Produkte, ihre Kunden und sechs Jahre Bestellungen exportieren sauber über die REST API und die Datenbank, und die HPOS Bestelltabellen machen die Bestellhistorie ordentlicher, als sie erwartet.³² Passwörter werden beim ersten Login zurückgesetzt, mit einer vorab vorbereiteten Servicenachricht.⁶ Nichts davon hält mich nachts wach.

Das Abo ist die Hälfte, die ich zuerst zuordne. Ihre monatlichen Futterboxen laufen über WooCommerce Subscriptions auf einem Anbieter, der die Karte hinterlegt.¹¹ Bevor ich ihr irgendetwas verspreche, klär ich eine Sache schriftlich: ob die Karten ihrer Abonnenten im neuen Shop weiter abgerechnet werden können, ohne neu eingegeben zu werden. Verbindet sich der neue Solidus Shop mit demselben Stripe Konto, bleiben die Token, wo sie sind, und die Abos laufen weiter. Wenn nicht, planen wir eine Kampagne zur erneuten Freigabe und nehmen etwas Abwanderung in Kauf. Das sage ich ihr ehrlich am ersten Tag, denn es in Woche elf zu entdecken ist, wie Umzüge schieflaufen.¹⁰

Was sie gewinnt, ist eine einzige Rails Anwendung, in der die Abo Logik, der Checkout und die Geschäftskundenpreise, die sie ergänzen will, getesteter Code sind, der ihr gehört, statt dreier Plugins, die nach jedem Update einen Waffenstillstand aushandeln. Was sie aufgibt, ist der Start am Wochenende und der Marktplatz der Plugins. Ein Solidus Bau kostet im ersten Jahr mehr als das Weitermachen, und sie braucht einen Rails Entwickler, dem sie vertraut. Für einen Shop ihrer Größe, den die Wartung und das Risiko wach halten und nicht die Rechnung, lohnt sich dieser Tausch meistens. Für einen ruhigeren Shop nicht, und das würde ich ihr sagen.

Wer auf WooCommerce bleiben soll

Einen kleinen, inhaltsgetriebenen Shop mit überschaubarem Katalog, schlanker Plugin Liste und jemandem, der ihn aktuell hält, würde ich nicht umsiedeln. Wenn WordPress ohnehin der Ort deiner Inhalte ist, dein Katalog in den Hunderten und nicht in den Tausenden liegt und dich nichts am Shop nachts wach hält, ist WooCommerce eine vernünftige und wirklich eigene Antwort, und ein Neubau wäre Geld ausgeben für ein Problem, das du nicht hast. Schreib den Umsatz, die Plugin Zahl oder den Vorfall auf, der dich umdenken ließe, damit die Entscheidung mit Absicht fällt und nicht in Panik nach einer Panne.

Die Shops, die umziehen sollen, sind die, in denen der Turm zur Aufgabe geworden ist: wo das Plugins Vertragen, Aktuellhalten und Schnellhalten mehr Aufmerksamkeit kostet, als der Shop einbringt, wo es einen Sicherheitsschreck schon gegeben hat oder klar geben wird, und wo die Funktionen, die du als Nächstes brauchst, Kämpfe gegen die Plattform sind statt Teile von ihr. Wenn die Art, wie Leute bei dir kaufen, Teil davon wird, warum sie bei dir kaufen, ist der Plugin Turm das falsche Fundament, und ich vergleiche alle fünf Systeme ehrlich im Systemvergleich. WooCommerce und die gehosteten Plattformen sitzen an entgegengesetzten Enden derselben Frage des Besitzes, weshalb der Gegensatz zum Wechsel weg von Shopify daneben lesenswert ist. Willst du das tiefere Argument, wem deine Aufzeichnungen gehören, ist wem gehören eigentlich deine Geschäftsdaten der richtige Artikel.

Wenn du es abwägst, bring deine Plugin Liste, dein Abo Setup und zwölf Monate Agenturrechnungen in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf meine Rechnung. Ich ordne, was sauber mitkommt, was Arbeit kostet und was festsitzt, und ist die ehrliche Antwort, auf WooCommerce zu bleiben und es gut zu pflegen, sage ich dir das auch.

Footnotes

1. WordPress.org, WooCommerce Plugin Seite (aktive Installationen, aktuelle Version, quelloffen und GPLv3 Lizenz, setzt WordPress voraus), abgerufen am 14. November 2026, https://wordpress.org/plugins/woocommerce/ ↩

2. WooCommerce, High Performance Order Storage (Bestellungen in eigenen Tabellen, für neue Installationen standardmäßig aktiv seit WooCommerce 8.2, erschienen im Oktober 2023), abgerufen am 14. November 2026, https://developer.woocommerce.com/docs/features/high-performance-order-storage/ ↩ ↩²

3. WooCommerce, REST API Documentation (aktuelle Version wc/v3, Basisroute, HTTPS Basic Auth und HTTP OAuth 1.0a einbeinige Authentifizierung, Schlüsselerzeugung), abgerufen am 14. November 2026, https://woocommerce.github.io/woocommerce-rest-api-docs/ ↩ ↩² ↩³

4. WooCommerce, Store API rate limiting (standardmäßig aus, gesteuert über den Filter woocommerce_store_api_rate_limit_options, nur POST, Standard 25 Anfragen pro 10 Sekunden, Checkout Option von 3 pro 60 Sekunden), abgerufen am 14. November 2026, https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/ ↩

5. WooCommerce, Product CSV Importer and Exporter (unterstützte Produkttypen und Spalten, das Präfix meta: für eigene Felder, Export aller eigenen Meta Felder und dokumentierte Grenzen), abgerufen am 14. November 2026, https://woocommerce.com/document/product-csv-importer-exporter/ ↩ ↩² ↩³ ↩⁴

6. Make WordPress Core, Password hashing upgrades in WordPress 6.8 (von phpass zu bcrypt, das Präfix $wp$2y$, bestehende Hashes beim Login umgehasht), 17. Februar 2025, https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/ ↩ ↩²

7. Patchstack, State of WordPress Security in 2026 (11.334 neue Schwachstellen im Jahr 2025, 91 % in Plugins und 9 % in Themes, sechs im Kern, 46 % bei Offenlegung ohne Fix), 2026, https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/ ↩ ↩²

8. Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 28 und 33, EUR Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩

9. WooCommerce, WC_Payment_Tokens Klassenreferenz (Token in der Datenbank gespeichert, get_customer_tokens mit optionalem Anbieterfilter, Löschen per ID), abgerufen am 14. November 2026, https://woocommerce.github.io/code-reference/classes/WC-Payment-Tokens.html ↩

10. Stripe, Request a payment data export (Kartendaten nur an einen nach PCI DSS Level 1 zertifizierten Abwickler exportiert, ohne Abos oder Zahlungshistorie), Stripe Dokumentation, https://docs.stripe.com/get-started/data-migrations/pan-export ↩ ↩²

11. WooCommerce, WooCommerce Subscriptions Produktseite (eine kostenpflichtige jährliche Erweiterung, Anbindung an über 25 Zahlungsanbieter für automatische wiederkehrende Zahlungen, manuelle Verlängerungen mit jedem Anbieter, Abonnements auf der eigenen Seite verwaltet), abgerufen am 14. November 2026, https://woocommerce.com/products/woocommerce-subscriptions/ ↩ ↩² ↩³

12. Google Search Central, Site moves with URL changes (jede alte URL auf eine dauerhafte Weiterleitung zum Endziel abbilden, mindestens ein Jahr gehalten), https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩