Von Squarespace zu einem eigenen Shop wechseln

Was Squarespace ist und wer bleiben sollte

Squarespace ist ein designorientierter Website Baukasten mit angeschlossenem Shop. Du suchst eine Vorlage aus, ordnest Inhaltsblöcke in einem visuellen Editor an, und am Ende steht eine schöne Seite, für die du kaum Aufwand hattest. Für einen kleinen Katalog ist genau das häufig 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 eine schöne Startseite mit einem überschaubaren Shop darunter ist: Das erledigt Squarespace gut, um das Hosting musst du dich nicht kümmern, und ein eigener Shop würde mehr kosten, als er zurückbringt.

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 bleiben, wo Squarespace die richtige Wahl ist. Dieser Artikel richtet sich an die, die den Baukasten hinter sich gelassen haben: Der Katalog ist über das hinausgewachsen, was die Verwaltung bequem trägt, der Checkout lässt sich nicht so anpassen, wie es das Geschäft inzwischen braucht, eine Anbindung an ein Lager oder die Buchhaltung will nie ganz sitzen, oder der Shop ist schlicht zum Geschäft geworden statt ein Kanal daneben zu sein. Sobald 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 geht es darum, wie du umziehst, ohne zu verlieren, was du aufgebaut hast.

Das ist der ehrliche Bericht über diesen Umzug: Was Squarespace sauber herausgibt, was nur zum Teil, was du neu bauen musst und wie ich das Ganze plane. Für die genaue Mechanik jeder Datenart verlinke ich die Leitfäden dieser Reihe, statt sie zu wiederholen. Beginne 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 begreifen musst, ist, wie wenig von einem Squarespace Shop dir wirklich gehört und mitgehen kann.

Der Code gehört dir nicht. Es gibt keine Anwendung zum Kopieren, kein Repository, keinen Server unter deiner Kontrolle. Die Storefront wird aus 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 allein 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 Gehen bedeutet, deine Daten aus dem Dienst zu ziehen und alles neu zu bauen, was der Dienst darum herum geleistet hat. Das ist kein Skandal. So funktioniert ein Baukasten, und das war der Preis 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. In den Einstellungen kannst du deine Seiten und den Blog als .xml Datei im WordPress Format exportieren. Squarespace sagt klar, dass das dem Umzug von Inhalten auf eine WordPress Seite dient und vieles zurücklässt: Es übernimmt Layoutseiten, eine Blogseite mit ihren Beiträgen sowie Text und Bildblöcke, aber keine Shopseiten und keine Produktblöcke, und auch keine Stileinstellungen oder eigenes CSS, weil so viele Funktionen auf Squarespace eigenem Code aufsetzen.¹ Für einen Shop taugt der Inhaltsexport für Blogbeiträge und sonst wenig. Deine Produkte stecken 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 öffnest.² 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. Die Einzelheiten dieser Abbildung, die SKUs, die Varianten, die Optionsstruktur und die Bilder, stehen in Produkt und Katalogdaten migrieren.

Was die beiden Exportwege nicht liefern, 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 hinab.

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 die Stelle, an der die Decke der Plattform sichtbar wird, deshalb lohnt sich Genauigkeit.

Um die Developer API Keys überhaupt zu verwenden, muss der Shop im Tarif Commerce Advanced liegen. 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, die erste Ausgabe einer sauberen Migration kann also 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 jeweils nur lesend oder lesend und schreibend vergeben. Transactions ist nur lesend. Die ältere Profiles API steht 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 gewährt.

Die Ratengrenzen sind bescheiden, und du planst darum herum, statt dagegen anzukä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 Sache von Minuten bis Stunden, nicht von Sekunden, das Exportskript muss also geduldig und wiederaufsetzbar sein.

Was die Orders API tatsächlich liefert, ist gut, in ihren 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 genügt, 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 verhält es sich ebenso: 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 Bereich nur für Mitglieder 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 gesperrter Bereich an einem Kundenkonto, eine Kursstruktur. Diese Arbeit lohnt sich meist, weil du auf einem eigenen Shop endlich bestimmst, 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 auf diese Adressen aufgebaut. 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.

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 lassen. 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 beiden 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 überstehen.

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 Leipzig (tonwerk.example) ist ein Leipziger Studio, das 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 hängen an einer Fremd App, 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 online, 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 überschaubar, 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 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.