Squarespace combines hosted website structure and commerce records inside one site environment. That combination changes the meaning of migration data. A Product does not exist only as a catalog row; it belongs to a Store Page, has a specific Product type, may contain variants and attributes, and is displayed through the site’s content and navigation structure. A buyer can appear as a Contact, Customer, subscriber, donor, or site user depending on the relationship that created the record. An Order preserves a transaction, but it does not become the configuration that governs future checkout, payment, fulfillment, or tax behavior.
The central translation task is to preserve the relationships that make each record useful in Squarespace. Product data must remain connected to its Product type, Store Page, variants, images, URL, and inventory. Contact data must retain the distinction between buyer identity, mailing-list participation, donation activity, and account access. Content and SEO records must keep their destination and internal references rather than being treated as decorative text around the store.
Squarespace Commerce Meaning Begins With the Site and Store Page
Squarespace is not a detached catalog placed beside an unrelated website. Commerce records live inside a site whose Pages panel, Store Pages, navigation, content collections, domains, and URLs determine how Products are published and found. Every Product belongs to a single Store Page, while its visibility also depends on both Product status and Store Page state.
That ownership rule matters when the source platform uses several catalogs, collections, websites, or sales channels. A Product cannot be translated correctly until the destination Store Page relationship is defined. Store Page placement is not merely a menu choice: it participates in Product visibility and URL meaning.
| Source-store assumption | Squarespace relationship meaning | Translation consequence |
|---|---|---|
| Products exist independently of the website | Each Product belongs to a Store Page inside a Squarespace site | Preserve Product identity together with its intended Store Page owner. |
| Category assignment recreates navigation | Product grouping, Store Page placement, tags, Categories, and site navigation are related but separate | Translate classification separately from menus and page presentation. |
| One generic Product type fits every offer | Squarespace distinguishes physical, service, gift card, and download Products | The Product type determines available variant, inventory, fulfillment, and file relationships. |
| Customer equals mailing-list subscriber | Contacts can represent Customers, subscribers, donors, and other site relationships | Preserve the reason the person exists in the destination, not only the email address. |
| Imported Orders recreate commerce operations | Orders preserve history and current transaction state; future behavior remains configured elsewhere | Keep transaction evidence separate from payment, tax, shipping, and notification settings. |
This site-commerce relationship also affects external identifiers. A source Product ID may need to remain attached to the Squarespace Product or variant used by an ERP. A source page ID may belong to content migration rather than commerce. A Customer CRM ID belongs with the Contact relationship recognized by the CRM, not with an Order simply because the first occurrence came from checkout.
Product Types Define Different Record Relationships
Squarespace supports physical, service, gift card, and download Products. Those types are not cosmetic labels. They determine whether a Product can have variants, how inventory is represented, what fulfillment meaning applies, and which additional records participate in the sale.
Physical Products can contain variants and shipping-related data. Service Products can also contain variants, such as duration or tier, while their fulfillment meaning differs from physical delivery. Gift card Products can use variants for denominations. Download Products connect the Product to a digital good and do not support variants in the same way.
| Source offer | Squarespace Product meaning | Relationship to preserve |
|---|---|---|
| Tangible merchandise | Physical Product | Store Page, variants, SKU, price, weight/dimensions where relevant, inventory, images, shipping meaning, and URL. |
| Consulting, class, experience, or service tier | Service Product | Service identity, variant tier or duration, price, content, and any separate scheduling or delivery owner. |
| Store credit or digital gift certificate | Gift card Product | Denomination variants, gift-card issuance relationship, purchaser/recipient context, and financial meaning. |
| Downloadable file | Download Product plus DigitalGood relationship | Product metadata, purchased file, delivery entitlement, and URL; not an invented set of variants. |
| Subscription or recurring offer | Product plus subscription and Order relationship | Product identity remains separate from recurring billing, entitlement, and renewal state. |
| Donation or membership offer | Donation, membership, or connected Squarespace area rather than an ordinary Product when applicable | Contact, transaction, access, and content relationships remain owned by the correct Squarespace feature. |
A source platform may model all of these offers as Products, SKUs, or custom Product types. Squarespace translation should follow the destination behavior. A downloadable course file, a scheduled consultation, and a shipped book may share a title and price, but they do not share the same fulfillment or record relationships.
Product Attributes, Variants, Images, and Inventory
Squarespace Product attributes define values such as color or size, while Product variants represent purchasable combinations. A variant can carry a unique SKU, price, stock quantity, dimensions, and selected attribute values. Product images belong to the Product image collection and can be associated with variants.
Source options need to be separated by commercial effect. A value that changes SKU, price, stock, image, or fulfillment identity is variant-like. A personalization instruction, optional service, bundle component, or application-generated configuration may not have a direct Squarespace variant equivalent. Turning every source choice into a variant can create an unmanageable Product matrix, while flattening true variants into text removes inventory and SKU identity.
| Source option pattern | Squarespace owner | Meaning that must remain intact |
|---|---|---|
| Size/color combination with SKU and stock | Product attributes and ProductVariant | Purchasable identity, attribute values, SKU, price, inventory, and image relationship. |
| Service tier or duration | Service Product variant | Sellable service choice and its price or descriptive differences. |
| Gift-card denomination | Gift card Product variant | Purchasable monetary denomination. |
| Download format | Usually separate Product meaning or file relationship rather than a download-Product variant | Correct file entitlement and Product identity. |
| Engraving, free text, or buyer upload | Custom input, form, Order-line data, or connected extension according to supported behavior | Customer-supplied value remains connected to the purchase and fulfillment owner. |
| Bundle or configurator | Product relationship, accepted simplification, or extension/external-system structure | Components, resulting SKU, price, inventory, and Order-line output remain explainable. |
Inventory is variant-based. The Squarespace Inventory API represents an InventoryItem as a variant of a physical or service Product and stores whether inventory is tracked or unlimited, together with SKU and availability information. This means a source Product-level quantity must first be reconciled with the destination variant structure.
A source stock value also needs an authoritative-system decision. If Squarespace owns inventory, the opening quantity should align with the destination Product variants. If a warehouse or ERP remains authoritative, the durable relationship is ProductVariant → external stock key → inventory synchronization. A copied quantity without that identifier becomes stale as soon as the external system resumes updates.
Store Pages, Categories, Tags, Navigation, and Discovery
Store Pages own Products, but they do not replace every source discovery structure. Categories, tags, Store Page placement, navigation links, summary blocks, search, content pages, and external campaign links can all help visitors find Products. A source collection may have represented a permanent department, a temporary campaign, a brand, a filter result, or an editorial page. Those meanings should remain distinct.
| Source discovery structure | Squarespace destination meaning |
|---|---|
| Permanent catalog department | Product Category or enduring Store Page grouping according to the destination structure. |
| Product brand | Tag, content relationship, naming convention, or external Product information field, depending on how the brand is used. |
| Seasonal collection | Category, tag, curated page, or temporary navigation relationship rather than a permanent Product type. |
| Faceted filter attribute | Variant attribute, structured Product content, tag, or external search/filter owner; not automatically a Category. |
| Main navigation link | Site navigation relationship pointing to a Store Page, Category view, content page, or external URL. |
| SEO landing page | Page or Store Page destination connected to Products, content, URL, metadata, and internal links. |
The Products API does not expose every Store Page Category relationship in the same way it exposes Product records, which reinforces the need to distinguish catalog data from site organization. The destination model should identify which records own Product classification and which site records own public discovery.
A Product can be correctly migrated yet remain effectively unavailable if it belongs to the wrong Store Page, is hidden, or lacks a reachable navigation path. That is a relationship problem, not evidence that the Product fields themselves are missing.
Contacts, Customers, Subscribers, Donors, and Account Access
Squarespace commerce and marketing features can create several person-related meanings. Contacts can represent Customers, subscribers, donors, and other people associated with the site. Address books and marketing preferences belong to those relationships. The older Profiles model exposed similar site-user categories, while the current Contacts API is the modern owner for broader Contact management.
A source Customer account may also contain passwords, customer groups, B2B roles, loyalty balances, saved payment details, membership access, subscription state, tax exemptions, or CRM attributes. Those meanings should not be flattened into one Contact record simply because the person has one email address.
| Source identity pattern | Squarespace relationship decision |
|---|---|
| Registered commerce buyer | Contact/Customer identity connected to Orders, addresses, and supported account behavior. |
| Guest checkout buyer | Order-linked buyer identity, with a durable Contact only when the destination relationship supports it. |
| Newsletter subscriber | Contact plus marketing-list and consent relationship, kept separate from purchase history when appropriate. |
| Donor | Contact plus donation/transaction history, not automatically a commerce Customer. |
| Member or gated-content participant | Contact/site user plus membership or access relationship; password and entitlement are not ordinary profile fields. |
| B2B buyer or organization | Contact plus CRM/external-system ownership for company, role, pricing, tax, or approval structures. |
| Duplicate source profiles | Consolidated only when identity, consent, address, and Order evidence support one person. |
Email can be a strong identity signal but not the only one. Shared addresses, changed emails, guest Orders, duplicate imports, and organization contacts can create false merges. External CRM IDs, source Customer IDs, addresses, and Order relationships may be needed to preserve distinct people and history.
Marketing consent must remain a separate relationship from buyer identity. A Customer who purchased does not automatically become a mailing-list subscriber, and a subscriber may never have purchased. Preserving the Contact without preserving the relationship that explains why it exists can create both operational confusion and consent problems.
Orders, Transactions, Fulfillment, and Historical Context
Squarespace Orders can represent one-time purchases and subscription Orders. They contain line items, Customer information, billing and shipping addresses, totals, discounts, taxes, shipping details, fulfillment state, payment state, refunds, and other transaction context. Transactions provide the financial records associated with Orders and donations.
The Order should retain the Product or variant purchased at the time, even if the current Product later changes. A line item is a transaction snapshot, not a live reference that should be overwritten by current catalog content. Payment and refund states describe what happened financially. Fulfillment and tracking explain how the purchase was handled. Imported or historical Orders do not define current payment processors, shipping rules, tax configuration, email behavior, or warehouse connections.
| Historical record | Squarespace meaning |
|---|---|
| Source Order number | Traceable external reference for Customer service and reconciliation. |
| Product/variant line | Purchased title, SKU, attribute selections, quantity, price, and other line snapshot. |
| Billing and shipping addresses | Historical transaction context, not a permanent account address unless separately owned by the Contact. |
| Discount, tax, and shipping line | Explanation of the historical total rather than current discount or tax configuration. |
| Payment state and transaction | Financial history linked to the Order, not reusable payment credentials. |
| Fulfillment and tracking | Historical shipment or service-delivery context, not a definition of current fulfillment methods. |
| Subscription or payment-plan state | Order and transaction lifecycle that must remain connected to the system controlling future charges. |
| Imported third-party channel Order | Order history plus external channel identifier and source relationship. |
Squarespace can import Orders from third-party sales channels through its Commerce APIs, but imported history should still preserve the original source and identifiers. Creating a Squarespace Order does not make the source marketplace, payment provider, or fulfillment system disappear as the historical owner of related references.
Pages, Blog Posts, Media, URLs, and SEO Relationships
Squarespace sites can contain regular pages, Store Pages, Blog Posts, collection items, images, files, navigation links, product URLs, Category views, SEO fields, redirects, domains, and connected services. These records form a content graph around the commerce catalog.
A source Product description belongs with the Product. A buying guide may belong as a page or Blog Post that links to several Products. A Category description may become Store Page or landing-page content. A campaign page may contain Product references without owning Product data. Media can be shared across Products and content, but image order, cropping, alt text, captions, and internal links have site-specific meaning.
| Source web asset | Squarespace owner |
|---|---|
| Product title, description, images, URL slug, and SEO data | Product and Store Page relationship. |
| Policy or informational CMS Page | Squarespace page with content, media, metadata, and navigation relationship. |
| Blog Post | Blog collection item with publication context, categories/tags, media, internal links, and URL. |
| Product guide or campaign landing page | Page/content collection plus Product references and navigation. |
| Menu item | Site navigation relationship pointing to a page, Store Page, Product destination, anchor, or external URL. |
| Source URL | Destination route plus redirect relationship when the path changes. |
| Theme block or custom code | Site presentation/configuration that references content and commerce records without becoming their owner. |
URL continuity depends on destination identity. A redirect should connect the old source path to the correct Product, Store Page, page, Blog Post, or other destination. It should not be used to hide uncertainty about which record replaced the source page. Internal links inside migrated content should also point to the intended destination rather than preserving obsolete source URLs.
Extensions, APIs, Custom Fields, and External-System Ownership
Squarespace Commerce APIs expose Products, Inventory, Orders, Transactions, Contacts, Discounts, Websites, and webhooks. Connected services and extensions can also own reviews, loyalty, subscriptions, fulfillment, accounting, shipping, marketing, scheduling, donations, memberships, or other data. A source application record should not be treated as native Squarespace data merely because a destination extension provides a similar feature.
The correct owner depends on business purpose and lifecycle. A Product warehouse ID belongs with the ProductVariant and ERP relationship. A Contact CRM ID belongs with the Contact and CRM. A marketplace Order ID belongs with the Order and channel. A membership entitlement belongs with the membership system, not a generic Contact note.
| Custom or external value | Destination ownership |
|---|---|
| ERP Product or variant ID | Product/ProductVariant plus ERP relationship at the same catalog grain. |
| External inventory key | ProductVariant plus warehouse or inventory system. |
| CRM Contact ID | Contact plus CRM relationship. |
| Marketplace Order ID | Order plus sales-channel relationship. |
| Review, loyalty, or subscription record | Extension or external system plus Product, Contact, or Order references. |
| Product configurator output | Product/variant plus extension-owned configuration and resulting Order-line snapshot. |
| Custom checkout answer | Order or Contact according to business purpose, plus the form/extension that owns collection and display. |
| Unsupported source table | Explicit parent record, durable key, lifecycle, and destination owner before the value is retained. |
This boundary avoids two common failures: forcing every value into the nearest Squarespace field and preserving app data with no destination consumer. A custom field is useful only when the destination team knows which record owns it, which system recognizes it, and whether it describes current commerce, historical context, content, or external configuration.
Representative Squarespace Translation Chains
A relationship chain shows how one source concept is divided among Squarespace commerce, Contact, content, and external-system records. It makes the destination owner visible and prevents a single imported field from carrying several incompatible meanings. The chain should remain understandable even after the source platform is no longer available, so each Product, Contact, Order, URL, and extension reference has a clear parent and continuing consumer.
| Source pattern | Squarespace destination relationship |
|---|---|
| Apparel Product with size/color stock | Store Page → physical Product → attributes → ProductVariants → variant images/SKUs → InventoryItems. |
| Consulting packages | Store Page → service Product → tier/duration variants → content → external scheduling or delivery owner where required. |
| Digital download | Store Page → download Product → DigitalGood → Order line → purchaser Contact → delivery entitlement. |
| Subscriber who later buys | Contact → mailing-list/consent relationship → Customer/Order history, without assuming the two relationships are identical. |
| Imported marketplace sale | Order → line-item snapshot → transaction/fulfillment history → Contact → external marketplace ID. |
| SEO-sensitive Product collection | Store Page/Category or curated page → Product references → navigation → destination URL → redirects from source paths. |
| Membership or donation record | Contact → membership or donation owner → transaction/access history, separate from ordinary Product and Customer fields. |
These chains keep Product, site, Contact, Order, content, and external-system ownership visible. They also show where a source platform may have combined several meanings in one record that Squarespace represents separately.
Conclusion
Squarespace data-model translation depends on the relationship between commerce records and the site that publishes them. Products belong to Store Pages and Product types; variants own sellable combinations and inventory; Contacts can carry Customer, subscriber, donor, and account-related meanings; Orders preserve transaction history; pages, Blog Posts, URLs, and navigation own content discovery; extensions and external systems own specialized behavior.
A strong destination model preserves those relationships without confusing migrated data with site presentation or future operating configuration. The result is not merely a populated Squarespace site, but a coherent set of Product, Contact, Order, content, and external-system records whose ownership remains understandable.
Common Questions
Why does Store Page ownership matter for Squarespace Products?
Every Squarespace Product belongs to one Store Page, and Product availability is connected to both Product visibility and Store Page state. Product data and Store Page placement therefore form one destination relationship even though site navigation remains a separate layer.
Can every source Product option become a Squarespace variant?
No. A variant is appropriate when the choice creates a distinct purchasable combination with SKU, price, inventory, image, dimensions, or other sellable meaning. Personalization, bundles, uploads, or application-controlled choices may need another owner.
Are Squarespace Contacts, Customers, and subscribers the same record type?
They can refer to the same person, but the relationships are different. Customer history, mailing-list consent, donation activity, address books, and account access should remain distinguishable even when one Contact connects them.
Does a migrated Order recreate Squarespace checkout behavior?
No. The Order preserves transaction, line-item, payment, refund, address, and fulfillment context. Current payment processors, tax settings, shipping methods, notifications, and connected fulfillment behavior remain separate configuration.
How should Product inventory be represented in Squarespace?
Inventory should follow the Squarespace ProductVariant that represents the sellable item. If an external inventory system remains authoritative, the variant also needs the durable external key used to maintain stock after the opening data transfer.
Where should app-owned or custom Squarespace data live?
It should remain with the Product, ProductVariant, Contact, Order, content record, extension, or external system that owns its business purpose. Generic notes are not a substitute for a defined parent relationship and durable identifier.