Von Squarespace zu einem eigenen Shop wechseln

Was Squarespace ist und wer bleiben sollte

Squarespace ist ein designorientierter Website Baukasten mit angeschlossenem Shop. Du wählst eine Vorlage, ordnest Inhaltsblöcke in einem visuellen Editor an, und heraus kommt eine schöne Seite mit sehr wenig Aufwand. Für einen kleinen Katalog ist das oft genau das Richtige, und wenn das auf dich zutrifft, ist dieser Artikel kein Grund zum Wechseln. Eine Werkstatt mit vierzig Produkten, ein Studio mit einer Buchungsseite, eine Marke, die vor allem aus einer schönen Startseite mit einem bescheidenen Shop darunter besteht: Das macht Squarespace gut, das Hosting ist erledigt, und ein eigener Shop würde mehr kosten, als er einbringt.

Ich baue eigene Shops mit Solidus, einem quelloffenen Ecommerce Framework auf Ruby on Rails. Du weißt also, wo ich stehe, und gerade deshalb will ich fair sein, wo Squarespace die richtige Antwort ist. Dieser Artikel ist für die, die den Baukasten hinter sich gelassen haben: Der Katalog ist über das hinausgewachsen, was die Verwaltung bequem bewältigt, der Checkout lässt sich nicht so ändern, wie es das Geschäft jetzt braucht, eine Anbindung an ein Lager oder die Buchhaltung will nie ganz passen, oder der Shop ist schlicht zum Geschäft geworden statt ein Kanal daneben zu sein. Wenn die Art, wie Leute bei dir kaufen, ein Teil davon ist, warum sie bei dir kaufen, stößt du an die Wände eines geschlossenen Baukastens. Dann lautet die Frage, wie du umziehst, ohne zu verlieren, was du aufgebaut hast.

Das ist der ehrliche Bericht über diesen Umzug: Was Squarespace sauber herausgibt, was nur teilweise, was du neu bauen musst und wie ich das Ganze plane. Für die tiefe Mechanik jeder Datenart verlinke ich die Leitfäden dieser Serie, statt sie zu wiederholen. Starte mit dem Überblick, was sich überträgt und was nicht, der über jedem plattformspezifischen Teil steht, auch über diesem.

Was dir auf Squarespace gehört und was der Baukasten behält

Das Erste, was du vor jedem Export verstehen musst, ist, wie wenig von einem Squarespace Shop tatsächlich dir gehört und mitgeht.

Der Code gehört dir nicht. Es gibt keine Anwendung, die du kopieren kannst, kein Repository, keinen Server, den du steuerst. Die Storefront wird von Squarespace eigenen Vorlagen samt deren JavaScript und CSS gerendert, und das bleibt bei Squarespace. Die Datenbank gehört dir nicht. Deine Produkte, Bestellungen und Kundendaten liegen in Squarespace Systemen und sind nur über das erreichbar, was Squarespace freigibt. Hosting, URL Struktur und Checkout gehören dir nicht. Die Inhalte, die du anordnest, stecken in proprietären Blöcken, die nur im Baukasten existieren.

Was dir gehört, sind deine Daten, in dem begrenzten Sinn, dass du von den meisten eine Kopie herausbekommst. Dieser Unterschied ist die ganze Migration. Auf einer eigenen Plattform ist der Shop ein Vermögenswert, den du hältst. Auf einem geschlossenen Baukasten ist der Shop ein Dienst, den du mietest, und Weggehen heißt, deine Daten aus dem Dienst zu ziehen und alles neu zu bauen, was der Dienst darum herum erledigt hat. Das ist kein Skandal. So ist ein Baukasten, und das war der Handel für den leichten Start. Die Eigentumsfrage behandle ich allgemein in wem gehören eigentlich deine Geschäftsdaten.

Die Export Wirklichkeit: Was herauskommt und in welcher Form

Squarespace hat zwei getrennte Exportwege, und keiner gibt dir den ganzen Shop.

Der erste ist der Export der Seiteninhalte. Aus den Einstellungen kannst du deine Seiten und den Blog als .xml Datei im WordPress Format exportieren. Squarespace sagt klar, dass das zum Umzug von Inhalten auf eine WordPress Seite gedacht ist und vieles zurücklässt: Es nimmt Layoutseiten, eine Blogseite mit ihren Beiträgen sowie Text und Bildblöcke mit, aber keine Shopseiten und keine Produktblöcke, und auch keine Stileinstellungen oder eigenes CSS, weil so viele Funktionen auf Squarespace eigenem Code beruhen.¹ Für einen Shop taugt der Inhaltsexport für Blogbeiträge und sonst wenig. Deine Produkte sind nicht darin.

Der zweite Weg ist der Produktexport. Im Produkte Bereich klickst du auf Export all, und Squarespace erzeugt eine Produkt CSV, die du in einer Tabelle öffnen kannst.² Das ist der eigentliche Katalogexport und das Sauberste, was du bekommst. Ein paar Grenzen prägen ihn. Das CSV Format deckt physische Produkte und Serviceprodukte ab, keine Downloadprodukte, digitale Güter liegen also außerhalb. Der Katalogweg trägt bis zu 10.000 Produkte auf einer aktuellen Seite der Version 7.1 und bis zu 250 Varianten je Produkt.² Und es ist ein einmaliger Auszug: eine Kopie zu einem Zeitpunkt, kein Live Feed, alles was sich danach ändert, musst du erneut ziehen. Für den Umzug eines Katalogs von echter Größe ist das die Datei, mit der ich arbeite, nachdem ich ihre Spalten auf das Produktmodell des neuen Shops abgebildet habe. Das Detail dieser Abbildung, die SKUs, die Varianten, die Optionsstruktur und die Bilder, steht in Produkt und Katalogdaten migrieren.

Was die zwei Exportwege nicht geben, sind Bestellungen und Kunden in großer Menge. Es gibt keinen einzelnen Knopf, der deine gesamte Bestellhistorie und deine Kundenliste in einer sauberen, dokumentierten Datei herausgibt, so wie es der Produkte Bereich tut. Dafür steigst du auf die API hinunter.

Die Commerce API und wo sie aufhört

Squarespace veröffentlicht ein Set von Commerce APIs, und für eine ernsthafte Migration sind sie das richtige Werkzeug. Sie sind zugleich der Ort, an dem die Decke der Plattform sichtbar wird, darum lohnt sich Genauigkeit.

Um die Developer API Keys überhaupt zu nutzen, muss der Shop im Tarif Commerce Advanced sein. Squarespace sagt deutlich, dass eine eigene Anwendung für eine Händlerseite auf Commerce Advanced gebaut wird.³ In einem niedrigeren Tarif bieten die Keys die Commerce Berechtigungen schlicht nicht an, also kann die erste Ausgabe einer sauberen Migration ein Upgrade auf den höchsten Tarif für die Monate des Umzugs sein.

Mit einem Key in der Hand sind die Berechtigungen fein abgestuft. Orders, Inventory, Products und Contacts lassen sich je nur lesend oder lesend und schreibend vergeben. Transactions ist nur lesend. Die ältere Profiles API ist im Wartungsmodus, und Squarespace lenkt neue Arbeit auf Contacts.³ Für eine Migration brauche ich Lesezugriff über Orders, Products, Inventory und Contacts, den der Key erteilen kann.

Die Ratengrenzen sind bescheiden, und du planst darum herum, statt dagegen zu kämpfen. Die Commerce APIs erlauben 300 Anfragen pro Minute, was Squarespace mit fünf Anfragen pro Sekunde gleichsetzt. Überschreitest du das, bekommst du eine 429 Antwort mit einer Abkühlzeit von einer Minute.⁴ Für einen großen Katalog und eine lange Bestellhistorie ist das seitenweise Durchblättern mit fünf Anfragen pro Sekunde samt Wiederholungen eine Aufgabe von Minuten bis Stunden, nicht Sekunden, das Exportskript muss also geduldig und wiederaufsetzbar sein.

Was die Orders API tatsächlich liefert, ist gut, innerhalb ihrer Grenzen. Jede Bestellung trägt die Bestellnummer, die Kunden E Mail, die Rechnungs und Lieferadresse, die Positionen mit ihren SKUs und Preisen, die Zwischensumme, Rabatte, Versand, Steuer und Gesamtsumme sowie den Fulfillment Status mit Sendungsdetails.⁵ Squarespace beschreibt die Orders API als Zugang zur Bestellhistorie für einmalige Käufe und für Abobestellungen.⁶ Das reicht, um im neuen Shop eine lesbare Bestellhistorie aufzubauen. Wie ich Bestellhistorie übernehme und wie weit zurück sich das lohnt, steht in Bestell und Kaufhistorie migrieren.

Hier die wichtige Grenze. Die einzige Zahlungsinformation an einer Bestellung ist ihr Zahlungsstatus, ein Wert wie bezahlt oder erstattet.⁵ Keine Kartennummer, keine gespeicherte Karte, kein Zahlungstoken kommt aus der API, und die Transactions API daneben ist nur lesend.³ Das ist korrektes und sicheres Verhalten, und es ist zugleich die harte Wand, an die jede Migration stößt. Rohe Kartendaten verlassen eine konforme Plattform nie, und gespeicherte Karten gehören dem Zahlungsdienstleister, nicht Squarespace. Mit Kundenpasswörtern ist es genauso: Sie liegen als Einwegprüfsummen, die kein Export und keine API je herausgibt, also setzt jede Kundin und jeder Kunde im neuen Shop ein neues Passwort. Konten und die Passwortfrage behandle ich in Kundenkonten und Adressen migrieren, die Frage der gespeicherten Karten in Zahlungstoken und gespeicherte Karten migrieren.

Die Fallen speziell bei Squarespace

Jede Plattform hat eine Handvoll Dinge, die Leute beim Abgang erwischen. Das sind die von Squarespace.

Digitale Produkte und Mitgliederbereiche werden von Grund auf neu gebaut. Wenn ein Teil deines Geschäfts aus Downloads, Kursen oder einem nur für Mitglieder zugänglichen Bereich hinter einem Login besteht, kommt nichts davon über die Produkt CSV heraus, und das Zugangsmodell für Mitglieder ist proprietär. Im neuen Shop werden daraus Funktionen, die du baust: ein digitaler Download, der bei Zahlung ausgeliefert wird, ein abgesperrter Bereich an einem Kundenkonto, eine Kursstruktur. Diese Arbeit lohnt sich meist, weil du auf einem eigenen Shop endlich steuerst, wie sich das verhält, aber du musst sie als Neubau einplanen, nicht als Import.

Die URL Struktur gehört Squarespace, und deine Rankings sitzen darauf. Squarespace legt die Form deiner Produkt und Seiten URLs fest, und Jahre an Links und Suchrankings haben sich gegen diese Adressen angesammelt. Am Tag des Umzugs muss jede davon auf ihr neues Zuhause weiterleiten, sonst liefert sie einen 404 und das Ranking versickert. Googles eigene Anleitung für einen Umzug mit URL Änderungen lautet, jede alte Adresse auf ihre neue mit einer dauerhaften Weiterleitung abzubilden, jede Weiterleitung direkt auf das Ziel zu richten und die Weiterleitungen mindestens ein Jahr zu halten.⁷ Diese Karte zu bauen ist die unglamouröse Arbeit, die den Verkehr schützt, den du schon hast, und ich behandle sie als Teil des Katalogumzugs in Produkt und Katalogdaten migrieren.

Zahlungen und gespeicherte Karten hängen an deinem Dienstleister. Squarespace Shops nehmen Geld über Squarespace Payments, Stripe oder PayPal an. Wohin deine gespeicherten Karten als Nächstes gehen können, hängt ganz davon ab, welchen davon du nutzt und ob der neue Shop sich mit demselben Dienstleisterkonto verbinden kann. Läuft der Shop schon über ein eigenes Stripe Konto, können die gespeicherten Karten genau dort bleiben und der neue Shop verbindet sich damit, das ist der beste Fall. Sitzen die Karten in Squarespace Payments, plane damit, dass Kundinnen und Kunden sie erneut eingeben. Die Mechanik steht in Zahlungstoken und gespeicherte Karten migrieren.

Aktive Abos sind das Schwerste. Wenn du wiederkehrend verkaufst, eine Abobox oder eine Mitgliedschaft, die monatlich abrechnet, hängen diese laufenden Pläne an Squarespace und seinem Dienstleister, und sie sind der heikelste Teil jeder Migration. Sie ohne Lücke in der Abrechnung oder eine Welle fehlgeschlagener Zahlungen zu verschieben, braucht meist die Mitwirkung der alten Plattform oder des Gateways und manchmal eine bewusste Neuanmeldung der Kundschaft. Lass das nicht bis zur letzten Woche. Die ganze Frage hat ihren eigenen Leitfaden in Abonnements und wiederkehrende Zahlungen migrieren.

Was sich überträgt, was teilweise, was neu gebaut wird

Die ehrliche Zusammenfassung eines Squarespace Umzugs auf einer Seite sieht so aus.

Teil des Shops	Was du von Squarespace bekommst	Was das für den Umzug heißt
Blog und Seiteninhalte	WordPress .xml Export, keine Shopseiten, kein Stil¹	Text importieren, Design neu bauen
Produkte	Produkt CSV über Export all, nur physisch und Service, einmalig²	Sauberster Export, auf das neue Produktmodell abbilden
Digitale Produkte und Mitgliederbereiche	Nicht in der CSV, proprietäres Zugangsmodell	Als Funktionen im neuen Shop neu bauen
Bestellungen	Commerce API, Orders lesend, E Mail, Adressen, Positionen, Summen⁵	Als nur lesende Historie übernehmen
Kunden	Commerce API, Contacts lesend, keine Passwörter³	Datensätze importieren, Kunden setzen neue Passwörter
Gespeicherte Karten	Nur Zahlungsstatus, keine Kartendaten, kein Token⁵	Dienstleister behalten, oder Karten neu eingeben
Abos	Nur Bestellhistorie, laufende Pläne am Dienstleister⁶	Früh planen, braucht oft Mitwirkung des Dienstleisters
Design, Code, Hosting, Checkout	Nicht übertragbar	Neu gebaut und dann im Eigentum

Lies die rechte Spalte hinunter, und die Form des Projekts ist klar. Katalog und Inhalte sind eine Abbildungsaufgabe. Konten und Bestellungen sind ein API Auszug mit klarer Decke. Design, Checkout und alles Proprietäre sind ein Neubau, und der Neubau ist der Sinn, denn am Ende gehört er dir.

Der ehrliche Umzugsplan

Ich führe einen Squarespace Umzug so, dass er die zwei Dinge schützt, die du nicht zurückbekommst: deine Suchrankings und das Vertrauen deiner Kundschaft. Die Methode ist dieselbe wie im Leitfaden darüber, auf diese Plattform angewendet.

Die Historie früh sichern. Bevor sich etwas ändert, ziehe ich eine volle Kopie dessen, was APIs und Exporte geben: die Produkt CSV, die Bestellungen, die Kontakte und deine Analysedaten. Squarespace eigene Analysen reisen nicht mit, wenn du also die Fähigkeit behalten willst, zurückzuschauen und zu prognostizieren, ist jetzt der Zeitpunkt, sie festzuhalten, solange der alte Shop noch lebt. Gründe und Methode stehen in Analyse und Verlaufsdaten für Prognosen migrieren.

Behalten, sichern oder neu bauen, je Sache entschieden. Manche Daten werden lebend in den neuen Shop getragen (Produkte, aktuelle Kunden, jüngste Bestellungen). Manche werden gesichert und archiviert statt importiert (alte Bestellungen jenseits einiger Jahre, rohe Analysedaten). Manches wird neu gebaut, weil es nicht umziehen kann (die Storefront, der Checkout, digitale Auslieferung, Mitgliederbereiche, Anbindungen). Diese Entscheidung für jeden Teil des Shops aufzuschreiben ist der Großteil der Planung.

Bauen und parallel laufen. Der neue Solidus Shop wird auf einer Staging Adresse gebaut und getestet, während der alte Squarespace Shop weiter verkauft. In den letzten Wochen wird der Katalog auf dem alten Shop eingefroren, damit die zwei nicht auseinanderdriften, und der finale Auszug am Umstellungsmorgen hält keine Überraschungen bereit, weil er geprobt wurde.

Jede URL vor der Umstellung abbilden. Die Weiterleitungskarte wird vor der Umstellung gebaut und geprüft, nicht danach. Jede alte Produkt und Seitenadresse zeigt mit einer dauerhaften Weiterleitung auf ihr neues Zuhause, und die Weiterleitungen leben im neuen Shop, damit sie jedes künftige Deployment überleben.

Den alten Shop einen Monat behalten. Nach der Umstellung bleibt die Squarespace Seite dreißig Tage genau so, wie sie war, als Rückfalloption und als Quelle für Übersehenes. Erst nach einem sauberen Monatsabschluss auf dem neuen Shop kündigst du den Tarif.

Wenn dich die Geldseite interessiert, wie sich fünf Jahre auf einem eigenen Bau gegen das Bleiben auf einer gemieteten Plattform rechnen, arbeite ich das in den Gesamtkosten über fünf Jahre durch, und die Plattformen selbst vergleiche ich in Solidus gegen Shopify, Shopware, Magento und WooCommerce.

Ein durchgerechnetes Beispiel

Nimm ein erfundenes Geschäft. Tonwerk Linz (tonwerk.example) ist ein Linzer Studio, das heuer vor fünf Jahren auf Squarespace mit vierzig glasierten Stücken und einer schönen Startseite begann. Es lief tadellos, und der Shop wuchs. Heute listet es rund neunhundert Produkte mit Farb und Größenvarianten, führt einen monatlichen Glasurklub, der Abonnenten abrechnet, verkauft eine Handvoll Onlinekurse als Downloads und will Galerien und Einrichtungsstudios, die inzwischen in Menge kaufen, Händlerpreise anbieten. Die Verwaltung ist träge geworden, der Checkout kann einen Händler nicht nach seinen Kontobedingungen fragen, und die Kursdownloads halten an einer Fremd App zusammen, die ständig bricht. Tonwerk ist dem Baukasten entwachsen.

So lief der Umzug, ehrlich. Die neunhundert Keramikprodukte kamen über die Produkt CSV sauber heraus, Varianten und alles, und wurden in zwei Tagen sorgfältiger Prüfung auf das neue Produktmodell abgebildet. Der Blog, fünf Jahre Studiotagebuch, kam über den WordPress Export herüber und wurde in den neuen Shop umformatiert. Die Kundenliste und drei Jahre Bestellungen kamen über die Commerce API an einem Nachmittag geduldigen Blätterns mit fünf Anfragen pro Sekunde heraus und gingen als Datensätze und nur lesende Historie in den neuen Shop. Jede Kundin und jeder Kunde bekam vor der Umstellung eine freundliche Nachricht, die erklärte, dass sie beim ersten Besuch ein neues Passwort setzen, weil sich kein Passwort übertragen ließ.

Drei Dinge wurden neu gebaut statt verschoben. Die Kursdownloads wurden eine richtige digitale Auslieferung im neuen Shop, die endlich verlässlich lief. Die Händlerpreise, auf dem alten Checkout unmöglich, wurden ein Kontotyp mit eigener Preisliste. Und der Glasurklub war der heikle Teil: Weil Tonwerk ihn schon über ein eigenes Stripe Konto abrechnete, blieben die Abos und die gespeicherten Karten bei Stripe und der neue Shop verband sich mit demselben Konto, sodass niemand eine Karte neu eingeben oder sich neu anmelden musste. Wäre der Klub über Squarespace Payments gelaufen, wäre das stattdessen eine Neuanmeldungs Aktion gewesen. Die Weiterleitungskarte umfasste rund zwölfhundert Zeilen, jede alte Produkt und Tagebuch URL zeigte auf ihr neues Zuhause, und der Suchverkehr hielt durch die Umstellung. Die alte Squarespace Seite blieb einen Monat oben, dann wurde der Tarif gekündigt.

Tonwerk besitzt jetzt seinen Shop: den Code, die Datenbank, den Checkout und die drei Funktionen, die der Baukasten nie hätte geben können. Das erste Jahr kostete mehr als ein weiteres Jahr Squarespace gekostet hätte. Ab dem zweiten Jahr steht keine Tarifstufe mehr zwischen dem Studio und dem Nächsten, das es bauen will.

Wer wechseln sollte und wer bleiben

Bleib auf Squarespace, wenn dein Shop klein ist, dein Katalog bescheiden, dein Checkout gewöhnlich und das Design der Großteil des Werts. Diese Leichtigkeit bekommst du durch einen Wechsel nicht zurück, und ein eigener Bau, den du noch nicht brauchst, ist früh ausgegebenes Geld.

Wechsle, wenn der Shop zum Geschäft geworden ist. Wenn der Katalog groß ist, wenn der Checkout Dinge tun soll, die der Baukasten nicht erlaubt, wenn digitale Produkte oder Mitgliederbereiche oder Händlerpreise oder Abos zentral sind statt eine Nebensache, und wenn du willst, dass der Shop ein Vermögenswert ist, den du besitzt, statt ein Dienst, den du mietest. Das ist der Punkt, an dem ein geschlossener Baukasten dich mehr an Nichtkönnen kostet, als ein eigener Shop zu bauen kostet.

Wenn du irgendwo dazwischen und wirklich unsicher bist, ist genau das der Zweck eines Gesprächs. Bring deinen Squarespace Shop, deine Katalogröße, deine Wunschliste an Anbindungen und deinen Ärger zu einem kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, ob du dem Baukasten schon entwachsen bist, und wenn nicht, sage ich dir, dass du bleiben sollst.

Squarespace Help Center, Exporting your site (Export im WordPress Format als .xml, Shopseiten, Produktblöcke, Stileinstellungen und eigenes CSS werden nicht exportiert), abgerufen am 14. November 2026, https://support.squarespace.com/hc/en-us/articles/206566687-Exporting-your-site ↩ ↩²
Squarespace Help Center, Importing and exporting products with a .csv (Export all im Produkte Bereich, nur physische und Serviceprodukte, keine Downloadprodukte, bis zu 10.000 Produkte auf Version 7.1 und 250 Varianten je Produkt, ein einmaliger Export ohne spätere Synchronisation), zuletzt aktualisiert am 22. Jänner 2025, https://support.squarespace.com/hc/articles/115000378108 ↩ ↩² ↩³
Squarespace Developers, Authentication and permissions (Tarif Commerce Advanced für eine eigene Anwendung nötig, Orders, Inventory, Products und Contacts nur lesend oder lesend und schreibend, Transactions nur lesend, Profiles im Wartungsmodus), abgerufen am 14. November 2026, https://developers.squarespace.com/commerce-apis/authentication-and-permissions ↩ ↩² ↩³ ↩⁴
Squarespace Developers, Rate limits (300 Anfragen pro Minute, fünf Anfragen pro Sekunde, 429 Too Many Requests mit einer Abkühlzeit von einer Minute), abgerufen am 14. November 2026, https://developers.squarespace.com/commerce-apis/rate-limits ↩
Squarespace Developers, Retrieve all orders (Bestellnummer, Kunden E Mail, Rechnungs und Lieferadresse, Positionen mit SKUs und Preisen, Summen, Fulfillment Status und Sendungsverfolgung, nur Zahlungsstatus), abgerufen am 14. November 2026, https://developers.squarespace.com/commerce-apis/retrieve-all-orders ↩ ↩² ↩³ ↩⁴
Squarespace Developers, Making requests to Commerce APIs (die Orders API gibt Zugang zur Bestellhistorie für einmalige Käufe und für Abobestellungen), abgerufen am 14. November 2026, https://developers.squarespace.com/commerce-apis/making-requests ↩ ↩²
Google Search Central, Site moves with URL changes (jede alte URL auf ihre neue abbilden, dauerhafte Weiterleitungen nutzen, jede direkt auf das Ziel richten, mindestens ein Jahr halten), abgerufen am 14. November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩