Squarespace preparation should establish how the commerce catalog fits inside the broader website before any migration run begins. Each Product belongs to one Store Page, while physical, service, gift card, and download Products have different variant and inventory behavior. Contacts, Orders, Transactions, Pages, Blog Posts, navigation, extensions, and site design also remain separate record families.
Squarespace preparation should record each required action together with its accountable owner, supporting evidence, and clear ready condition. This prevents a complete Product export from being mistaken for a complete Store Page, a Contact from being treated as a subscription or member entitlement, or historical payment data from being confused with current checkout configuration.
Confirm the Squarespace Site and Store Page Model
Define the intended relationship among the website, Store Pages, Products, content, navigation, and connected systems.
| Preparation area | Decision to record | Owner | Ready evidence |
|---|---|---|---|
| Website structure | Domains, locale, currency, navigation, Pages, Blog, and commerce-enabled areas | Site owner | Site and route map |
| Store Pages | Which Store Page owns each Product family | Commerce owner | Store Page assignment matrix |
| Product types | Physical, service, gift card, and download Product handling | Merchandising owner | Product-type inventory |
| Customer model | Contacts, subscribers, donors, Customers, accounts, and external CRM relationships | Customer owner | Contact classification matrix |
| Order and financial model | Orders, subscription Orders, Transactions, refunds, and external references | Operations/finance | Historical evidence packet |
| Extension model | Fulfillment, subscriptions, memberships, booking, tax, marketing, and analytics ownership | Technical owner | Dependency register |
The model is ready when every major commerce and content record has one intended Squarespace or external owner and each Product family has an assigned Store Page.
Prepare Access, Source Archives, and Recoverable Evidence
Collect:
- source administrator access and required Squarespace website and commerce permissions;
- dated exports or backups for Products, Customers, Orders, content, subscribers, and relevant custom data;
- Product images, downloadable files, page media, and source content archives;
- Store Page, navigation, domain, and URL inventories;
- extension, API, webhook, and external-system evidence;
- external Product, Contact, Order, and transaction identifiers;
- a source-change owner for Products, Contacts, Orders, content, and inventory during the migration window.
| Evidence item | Why it matters | Ready condition |
|---|---|---|
| Access record | Confirms source and destination areas can be inspected | Required permissions are available |
| Dated source archive | Preserves a recoverable reference state | Exports open correctly and carry a date |
| Media and file archive | Protects Product images, page media, and downloads | Files can be matched to their owning records |
| Store Page inventory | Prevents Products from being assigned to the wrong commerce page | Every Product family has a target Store Page |
| External-ID register | Protects CRM, fulfillment, accounting, or marketplace continuity | Each key is assigned to the correct entity |
| Change log | Captures source updates after the archive date | New and changed records have accountable owners |
If an application or external system cannot provide an export, record the limitation and responsible owner rather than omitting it from preparation.
Prepare Product Types, Variants, Images, and Inventory
Squarespace supports physical, service, gift card, and download Products. Physical and service Products can use variants; inventory records apply to physical and service variants and can be tracked or unlimited. Download Products have file relationships but do not use the same variant model.
Prepare representative examples for:
- each Product type used by the business;
- simple and multi-variant Products;
- Product attributes such as color, size, or weight;
- variant SKU, price, stock, and image relationships;
- downloadable files and access expectations;
- service Products and any booking or external scheduling dependencies;
- gift card history or current balances where relevant;
- bundles, subscriptions, personalization, or extension-owned behavior;
- ERP, PIM, warehouse, marketplace, and fulfillment identifiers.
| Source behavior | Preparation decision | Evidence | Ready condition |
|---|---|---|---|
| Physical or service Product has variants | Define Product and variant ownership | Parent/variant IDs, attributes, SKU, price, stock, and images | Every combination has an intended Squarespace variant |
| Download Product | Define Product, file, and delivery ownership | Source file, Product ID, access rules, and Order example | The file relationship has a named owner |
| Service Product uses scheduling | Separate Product data from booking or external scheduling records | Service and appointment examples | Scheduling ownership is documented |
| Gift card or stored value exists | Define historical and current owner | Code/balance examples and finance owner | Stored-value treatment is explicit |
| Product behavior is extension-owned | Identify continuing extension or external system | Related Product and configuration evidence | Required records appear in the dependency register |
The area is ready when every Product family has a type, Store Page, variant model, inventory treatment, media/file owner, and external key.
Prepare Store Pages, Categories, Navigation, and Product Discovery
Every Squarespace Product belongs to one Store Page. Store Page categories and navigation, however, are separate structures. The Products API does not provide Store Page category assignments, so source evidence for Product grouping and storefront discovery must be prepared directly.
Collect:
- Store Page names, identifiers, URLs, and Product assignments;
- Product categories and merchandising groups used within each Store Page;
- main navigation, secondary navigation, footer links, and landing pages;
- filters, attributes, internal links, and campaign collections;
- high-value shopping paths and source URLs;
- redirects and retirement decisions.
| Discovery area | Owner | Required evidence | Ready condition |
|---|---|---|---|
| Store Page | Commerce/site owner | Store Page and Product assignment list | Every Product has one intended Store Page |
| Category or grouping | Merchandising owner | Product membership and public route examples | Group meaning is documented independently of navigation |
| Navigation | Site owner | Menu tree and destination links | Store Pages, categories, Pages, and external links have intended placements |
| Landing content | Editorial owner | Page content, media, metadata, and Product references | Campaign and evergreen paths have defined owners |
| Redirect | SEO owner | Source and destination URL ledger | Every priority path has an approved outcome |
Do not assume that migrating Products automatically recreates Store Page categories, menu placement, or buyer journeys. These relationships need their own evidence and owners.
Prepare Contacts, Address Books, Subscribers, and Customer Identity
The Squarespace Contacts API represents people associated with the site, including Customers, mailing-list subscribers, donors, and other site participants. Contacts can have address books and marketing preferences, and the Contact ID corresponds to the Customer ID referenced by Orders.
Prepare:
- registered Customers, guest buyers, subscribers, donors, and other Contacts;
- duplicate email or identity examples;
- Contact address books and default shipping addresses;
- marketing preferences and consent evidence;
- Customer/Contact IDs used by Orders;
- account-access expectations;
- memberships, subscriptions, loyalty, booking, or CRM records owned elsewhere;
- external Contact and Customer identifiers.
| Identity case | Owner | Evidence | Ready condition |
|---|---|---|---|
| Customer with Orders | Customer operations | Contact ID, address book, and Order examples | Order relationships use the intended Contact identity |
| Guest buyer | Customer operations | Email, Order, and address snapshots | Guest history is documented without inventing an account |
| Subscriber or donor | Marketing/fundraising owner | Consent, list, and activity context | Non-commerce identity is not treated as a retail Customer by default |
| Membership or subscription participant | Application owner | Plan, entitlement, renewal, or access records | The specialized relationship has a continuing owner |
| External CRM Contact | Integration owner | CRM ID and matching rules | Cross-system identity is documented |
Authentication and account access should be prepared separately from Contact identity. A Contact record does not by itself reproduce a source password, membership entitlement, or application profile.
Prepare Historical Orders, Subscription Orders, and Transactions
Select Orders that expose one-time and subscription purchases, Product and variant lines, Customer IDs, addresses, discounts, taxes, shipping, fulfillment, refunds, and external references. Prepare Transactions separately because financial Documents can contain payments, refunds, fees, and gateway errors related to an Order or donation.
| Historical area | Required evidence | Ready condition |
|---|---|---|
| One-time Order | Product/variant lines, Customer, totals, status, and fulfillment | The transaction can be explained from the source packet |
| Subscription Order | Subscription context, renewal history, Products, and Customer | Historical recurrence is distinguished from live subscription configuration |
| Payment and refund | Transaction Document, payment type, refund, and error examples | Financial history is connected to the correct Order |
| Fulfillment | Shipment, tracking, fulfilled quantities, and external IDs | Past delivery context is understandable |
| Guest Order | Email, address, and Order relationship | Guest identity remains distinct from a persistent account |
| External Order | Channel, ERP, accounting, or support ID | Reconciliation keys remain attached to the correct Order |
Historical Orders and Transactions preserve past commerce. Current payment processors, checkout, tax, shipping, discounts, subscription billing, and fulfillment configuration remain separate preparation owned by the responsible teams.
Prepare Content, Blog Posts, Media, Domains, and URLs
Squarespace commerce commonly sits inside a content-led website. Prepare:
- CMS Pages, Blog Posts, Store Page content, Product descriptions, and landing pages;
- authors, dates, tags, categories, media, and internal links;
- image, video, downloadable-file, and alt-text inventories;
- primary domain, secondary domains, locale, currency, and analytics ownership;
- Product, Store Page, content, Blog Post, and campaign URLs;
- metadata, canonical relationships, redirects, and retired paths;
- navigation, footer, and campaign links.
| Content area | Owner | Evidence | Ready condition |
|---|---|---|---|
| CMS Page | Editorial owner | Content, media, metadata, route, and navigation context | Each Page has an intended destination and route |
| Blog Post | Editorial owner | Body, author/date, media, tags/categories, and URL | Editorial history and route are documented |
| Product/Store Page content | Commerce owner | Description, images, grouping, and page ownership | Content remains attached to the correct commerce object |
| Domain and route | SEO/site owner | Domain and URL ledger | Every priority path has a destination or retirement decision |
| Template or block dependency | Site designer | Layout, block, form, embed, or code inventory | Presentation work is separated from migrated content |
A content record is ready when its body, media, route, owner, and intended presentation layer are known. Copying text alone is not a complete preparation record.
Inventory Extensions, APIs, Webhooks, and External Systems
Create a dependency register covering fulfillment, subscriptions, memberships, bookings, email marketing, CRM, accounting, tax, shipping, reviews, loyalty, marketplace, donations, analytics, and custom applications.
For each dependency, record:
- business purpose;
- Products, Contacts, Orders, Transactions, content, or files affected;
- authoritative system and external IDs;
- export or API availability;
- configuration owner;
- continuing destination, replacement, or retirement decision;
- source evidence required before the destination workflow is configured.
The register is ready when every active extension-owned field or record has a named owner, parent entity, continuing consumer, durable identifier, and source evidence that can be recovered without relying on the storefront display alone.
Select Representative Migration Test Samples
| Sample | Preparation purpose |
|---|---|
| Physical Product with variants | Expose attributes, SKU, images, and inventory relationships |
| Service Product | Expose Product data versus scheduling or external service ownership |
| Download Product | Expose Product-file and Order-access relationships |
| Product assigned to a priority Store Page | Expose Store Page, category, navigation, and URL ownership |
| Contact with several addresses and Orders | Expose Contact ID, address book, and Customer relationship |
| Subscription or refunded Order | Expose recurrence, Transactions, refund, and totals |
| CMS Page or Blog Post | Expose content, media, metadata, and route ownership |
| Extension-owned record | Expose the continuing application and external identifiers |
For every sample, record the source ID, source URL where relevant, Product type, Store Page, business reason, intended Squarespace owner, known exclusions, external keys, and responsible reviewer.
Complete the Squarespace Readiness Gate
| Readiness question | Required evidence | Ready condition |
|---|---|---|
| Are access and source archives recoverable? | Access record and dated exports/backups | Required records can be inspected independently of the live source |
| Is website and Store Page ownership defined? | Site/Store Page matrix | Every Product family and content area has an owner |
| Are Product types and variants prepared? | Product-type and variant inventory | Physical, service, gift card, and download cases are documented |
| Are Contacts and Orders connected? | Contact/Order relationship examples | Identity, addresses, and historical transactions are understandable |
| Are Transactions and extensions inventoried? | Financial evidence and dependency register | Refunds, payments, and application-owned records have named owners |
| Are content and URLs prepared? | Content and route ledger | Pages, Blog Posts, Store Pages, media, and redirects have intended destinations |
| Are representative migration samples selected? | Sample ledger | Catalog, identity, Order, transaction, content, and extension complexity is covered |
| Are unresolved items controlled? | Decision log | Every open item has an owner and due date |
The gate is complete when no critical Store Page, Product type, variant, Contact, Order, Transaction, content, route, or extension decision depends on an undocumented assumption.
Conclusion
Squarespace preparation should produce a website-and-commerce evidence package. Products must be assigned to the correct Store Page and Product type, variants and inventory must retain their relationships, Contacts must remain distinct from specialized account programs, Orders and Transactions must preserve historical context, and content or routes must have clear owners.
When those decisions are documented before the representative migration test, the sample set can represent the intended Squarespace site without confusing imported commerce records with site design or live checkout configuration.
Common Questions
What should be prepared first for Squarespace?
Start with the website and Store Page ownership map. Define which Store Page owns each Product family and which Pages, Blog Posts, domains, Contacts, and external systems belong to the destination.
Why must Squarespace Product types be prepared separately?
Physical, service, gift card, and download Products do not share identical variant, inventory, file, fulfillment, or application relationships. Each type needs representative source evidence.
How should Store Page categories be prepared?
Collect them directly with their Product memberships, routes, and merchandising purpose. They are not available through the Products API and should not be assumed from Product records alone.
Are Squarespace Contacts and Customers separate identities?
Contacts represent site-associated people, including Customers, subscribers, and donors. The same Contact ID can appear as the Customer ID on an Order, but specialized memberships or subscriptions may remain owned by another application.
Why should Orders and Transactions be prepared separately?
Orders explain purchased items and fulfillment, while Transaction Documents explain payments, refunds, fees, and gateway errors. Both are needed for complete historical context.
When is Squarespace preparation complete?
It is complete when access, Store Pages, Product types, variants, inventory, Contacts, Orders, Transactions, content, routes, extensions, samples, and unresolved decisions all have accountable owners and recoverable evidence.