Squarespace export can mean three different things: an official WordPress XML export from the Squarespace dashboard, a public static copy of the published site as HTML, CSS, JavaScript, images, fonts, and files, or a rebuild in a new CMS or stack. It usually does not mean one official "download my whole Squarespace website as portable HTML" button that preserves the full design, assets, Commerce, Member Areas, Scheduling, forms, editor, and dashboard data.

That distinction matters before you cancel Squarespace. The official export is useful for some source content, especially if WordPress is one possible destination, but it is not a full HTML, CSS, JavaScript, and assets archive of the rendered public website. A public-site copy is the practical way to export Squarespace to HTML for a static archive or self-hosted mirror, but it cannot turn Squarespace-hosted business systems into static files.

If your goal is a Squarespace backup, archive, self-hosted brochure site, or temporary mirror while you rebuild, the practical path is to combine dashboard exports with a public-site static copy and a careful acceptance test. If your goal is ongoing editing, ecommerce ownership, bookings, member access, forms processing, or structured publishing, plan the replacement systems before moving DNS.

For the broader topic of downloading any public website as HTML, CSS, JavaScript, and assets, start with the hub guide to downloading an entire website. If the final deliverable needs to be a portable archive, the website-to-ZIP guide explains what to inspect inside the package. This page stays focused on "squarespace export," "export Squarespace website," "export Squarespace site," "download Squarespace website," "Squarespace backup," "Squarespace to HTML," and the sequence for leaving Squarespace safely.

Only export sites you own or are authorized to copy. A public URL is not permission to republish someone else's website.

What "Squarespace export website" can mean

People search for "squarespace export," "export Squarespace," "Squarespace export website," "Squarespace export site," "how to export Squarespace website," "download Squarespace website," "Squarespace backup website," "Squarespace to HTML," and "Squarespace export HTML" while looking for different outcomes. Mixing those outcomes is how a migration breaks.

Official Squarespace content export

Squarespace's official export is mainly a WordPress migration path. It creates a WordPress-format XML file for supported content, not a complete downloadable copy of the live site.

Squarespace documents limits around what can export. Depending on the site, the XML export may include layout pages, one blog page with posts, text blocks, image blocks, some text from other blocks, and certain gallery pages. Squarespace also notes that many items do not export, including several page types, page-specific headers and footers, more than one blog page, dropdowns, audio blocks, product blocks, video blocks, drafts, style settings, and custom CSS.

Use the official export before any major move where it applies. It can preserve source content for a rebuild or WordPress import. It is not the same as a browser-visible static HTML export, and it should not be evaluated as if it were an HTML website downloader.

Official export vs Squarespace HTML export

The honest gap in most Squarespace export searches is that the official path and the HTML path solve different jobs.

| Question | Official Squarespace export | Published-site HTML export | | --- | --- | --- | | Main output | WordPress-format XML for supported content | Static HTML, CSS, JavaScript, images, fonts, and public files | | Best use | WordPress migration, content archive, rebuild source | Self-hosted brochure site, visual archive, temporary mirror, static handoff | | Design fidelity | Limited; not a full rendered-site package | Preserves what visitors can load and what you can verify by clicking through | | Hosted systems | Does not recreate Commerce, forms, members, scheduling, or checkout | Does not recreate Commerce, forms, members, scheduling, or checkout | | Editing after export | Import or rebuild in a CMS | The files are yours; an AI assistant can help you edit them |

If you are trying to migrate blog content into WordPress, start with the official XML export and then plan cleanup in WordPress. If you are trying to self-host the visible Squarespace site as static files, you need the published-site HTML route and a copy that proves the important pages were captured.

Public-site static copy

A Squarespace website downloader or browser-based exporter visits the published public URL, saves the pages and assets delivered to visitors, and rewrites links so the result can run from a static host. This is the practical "export Squarespace to HTML" path when the public front end is the asset you need.

Export Your Site is one way to create that public-site copy. The ZIP is for published pages and public assets; it is not a Commerce backend, CMS dashboard, form processor, member database, or Squarespace editor clone.

A Squarespace backup

A Squarespace backup is broader than a website download. A useful backup may include the official XML export, product or order exports where available, customer and contact data, scheduling records, mailing-list data, invoices, DNS settings, brand assets, and a static copy of the public front end.

The public static copy is the visitor-facing part of the backup. It does not include private dashboard records, unpublished drafts, account settings, payment details, or the editor project.

A maintainable rebuild

A rebuild recreates the site in a new CMS, static-site generator, framework, or hosted platform. The Squarespace site becomes the visual reference, and the static export can become an archive or bridge, but the rebuild creates a new source of truth.

Choose a rebuild when editors need to publish often, structured content matters, Commerce is core, bookings drive revenue, members need accounts, or you want clean maintainable code instead of generated delivery output.

Backup vs download vs official export

These terms overlap in search results, but they answer different risks.

| Goal | Best artifact | What it helps with | What it does not solve | | --- | --- | --- | --- | | Preserve supported source content | Official Squarespace XML export | WordPress import, content archive, rebuild reference | Full design, complete assets, Commerce, forms, members, scheduling | | Preserve the public front end | Static website download | Self-hosted brochure site, archive, temporary mirror, visual reference | Dashboard data, editor workflow, private records, hosted services | | Preserve business records | Dashboard CSV/API/provider exports | Contacts, orders, products, scheduling, mailing lists, compliance records | Public page rendering or design fidelity | | Own future editing and systems | Rebuild or platform migration | Maintainable source, new CMS, commerce, forms, memberships | Instant one-click copy of the current generated site |

If you want to leave Squarespace, do not pick only one artifact because the phrase "Squarespace backup" sounds complete. Export dashboard data where Squarespace supports it, save the public site if the visible pages matter, and decide how future edits and hosted workflows will run.

Images from a public page may be resized, compressed, cropped, or served from generated CDN URLs. If you need source-quality logos, product photos, brand images, or design files later, save them separately from the Squarespace dashboard or your original asset library where your permissions allow it.

When to export Squarespace to HTML instead of using WordPress XML

Choose a static HTML export when the public website itself is the thing you need to preserve. This is usually the right leave path for a brochure site, portfolio, campaign microsite, restaurant site, event site, personal site, documentation page, or temporary mirror where the published pages are mostly informational and the acceptance test is visual and navigational.

Choose the official WordPress XML export when your real goal is moving supported source content into WordPress. XML is better for posts and pages that should become editable WordPress content. It is not better for preserving the exact public Squarespace front end, because it does not package the rendered design, client scripts, images, fonts, and route structure as a ready-to-host static site.

Many exits need both paths. For example, you might use the official XML export to seed a future WordPress content model while using a static HTML ZIP as the public bridge during the rebuild. If WordPress is the destination but you ultimately want static hosting, the WordPress to static HTML guide explains the second half of that workflow.

Do not choose static HTML if the business requirement is "keep editing the site in a visual CMS" or "keep checkout, bookings, member login, or form submissions working without replacement." In those cases, use the static export as evidence and an archive while the maintainable system is rebuilt.

What a public Squarespace site copy can preserve

For an ordinary marketing site, portfolio, event landing page, restaurant page, personal site, or small brochure site, a static copy can often preserve the browser-facing pieces:

published HTML pages;
Squarespace-delivered CSS and browser JavaScript;
public images, icons, SVGs, fonts, and downloadable files;
responsive layouts as delivered to visitors;
menus, galleries, lightboxes, overlays, accordions, and other client-side interactions;
links between captured public routes;
public embeds and third-party scripts that are still allowed to run from the new host.

The output is a snapshot of rendered delivery files. It is not the Squarespace editor, a template you can import back into Squarespace, a clean component project, or a complete copy of Squarespace as a backend platform.

That is why inspecting the copy matters more than the promise of a ZIP. A screenshot only proves one viewport looked right once. Opening the copied site lets you open navigation, visit deeper routes, resize pages, and find the places where the static copy still depends on Squarespace or another hosted service.

What a static Squarespace export cannot preserve independently

Squarespace editor and dashboard

A public copy cannot recover private account access, unpublished pages, revision history, collaborators, permissions, billing settings, app configuration, analytics dashboards, Email Campaigns, or the visual editing canvas. If those are the assets you need, pursue an account handoff, dashboard export, or official provider-supported path.

Commerce

Product pages can be copied visually, but a static ZIP cannot preserve product management, inventory, variants, carts, checkout, taxes, discounts, shipping, customer accounts, order history, subscriptions, refunds, or payment reporting. Export products and orders where available, then choose a commerce platform or rebuild the store flow.

Forms and lead capture

The visible fields may survive. Submission handling often depends on Squarespace or scripts configured for the original host. Replace every form with a form provider, serverless endpoint, or application backend, then test validation, spam protection, redirects, error states, CRM delivery, and notification emails.

Member Areas

Memberships combine authentication, permissions, payments, private pages, gated files, account emails, and support workflows. A public static copy can preserve marketing pages around the membership. It cannot enforce member access or copy private content a visitor cannot load.

Scheduling

Squarespace Scheduling and Acuity-style flows depend on availability, calendars, intake forms, payments, confirmation emails, reminders, cancellations, and staff rules. A static export may keep public scheduling copy or an embed container. The booking system itself needs a provider or rebuild.

Blogs, collections, and ongoing editing

Published blog posts and collection pages may be captured as frozen HTML when they are public and reachable. Future Squarespace edits, drafts, scheduling rules, tags, categories, comments, content permissions, and dashboard publishing workflows do not move with static files.

You can still change those copied pages in the files, including with an AI assistant. If you want a dashboard for collections, use the official XML export where it helps and choose a CMS. The Squarespace editor does not come with the ZIP.

Search, email, analytics, and embeds

Hosted search needs a new index. Email campaigns and mailing lists need separate exports and a new provider if you are leaving. Analytics, pixels, consent scripts, maps, videos, booking embeds, chat widgets, and other third-party scripts should be reviewed rather than blindly carried over. Some embeds may continue working, but they remain remote dependencies.

Decide why you are exporting Squarespace

Write the requirement plainly before choosing tools:

"We need a Squarespace backup of the public site and supported dashboard data."
"We need to download a Squarespace website for archival reasons."
"We need to self-host a simple brochure site."
"We need a temporary public mirror while a rebuild happens."
"We need clean maintainable source code."
"We need editors to keep publishing without developers."
"We need to move Commerce, forms, scheduling, or members off Squarespace."
"We need to stop paying for Squarespace only after the replacement works."

A public Squarespace to HTML copy fits the first four goals when the site is mostly public and presentational. It may support the last goal after testing. It does not create clean source code, preserve private dashboard data, or replace hosted Squarespace applications.

If you are comparing tool categories, the guide to best website downloaders explains browser services, desktop crawlers, command-line mirrors, and extensions. This playbook assumes the site is on Squarespace and focuses on how to leave without breaking the business parts.

For comparison across other builders, see the Wix export playbook, the Webflow export guide, and the guide on leaving Framer. The same principles apply, but Squarespace's official XML export and hosted feature limits are different enough to deserve a separate checklist.

Step 1: map the live Squarespace site

Use the published site, your Squarespace dashboard, analytics, search console data, and any sitemap you have. Record:

primary navigation pages;
unlinked landing pages and campaign URLs;
blog pages, collection pages, portfolio items, events, products, and representative templates;
localized routes or alternate language versions;
forms, success states, and notification recipients;
Commerce products, checkout paths, subscriptions, taxes, shipping, discounts, and customer account flows;
Member Areas, gated pages, downloads, pricing, and account emails;
Scheduling services, staff, calendar rules, intake forms, and payment settings;
downloadable files and public media assets;
search, filters, comments, chat, reviews, maps, video embeds, and other widgets;
custom code injection, third-party scripts, analytics, pixels, cookie consent, and marketing tags;
redirects, canonical URLs, sitemap, robots rules, and 404 behavior;
current DNS records, connected domains, email records, and rollback notes.

This inventory becomes the acceptance test. It also separates visible pages from Squarespace-hosted behavior that no HTML export can own for you.

Step 2: preserve dashboard data separately

Before using any Squarespace website downloader, export data through supported Squarespace or provider paths where they apply. At minimum, check whether you need:

the official WordPress XML export for supported pages and blog content;
products, SKUs, variants, product images, inventory, and order records;
customers, contacts, subscribers, and mailing lists;
form submissions, notification rules, automations, and CRM destinations;
scheduling clients, services, appointments, staff, calendars, intake forms, and payments;
member lists, plan records, billing references, and access rules;
invoices, billing receipts, plan details, and domain registration records;
original brand assets, source images, design files, fonts, and logos;
custom code snippets, third-party account credentials, API keys, and webhook notes.

Use current Squarespace documentation for exact export procedures and limits because product screens and plan rules change. Keep the exports in durable storage before you alter domains or cancel anything.

A public-site copier cannot log into your dashboard, reach private records, or turn hosted product data into a new backend. It should not try.

Step 3: create the public copy or start the rebuild

Use a public-site copier when the current published front end is what you need to preserve. Squarespace pages can use generated scripts, responsive image variants, CDN assets, platform hosts, and page structures that a single "Save page as" action will miss. The exporter should load pages like a browser, follow safe route limits, save required assets, rewrite internal links, respect page and byte limits, and avoid crawling unrelated domains.

Use a rebuild when the future workflow matters more than preserving generated output. If a team needs ongoing content editing, clean Git-based code, a new CMS, a new store, a booking application, or a different membership system, the static ZIP is a reference and bridge rather than the destination.

Use WordPress, Shopify, or another platform migration path when the destination owns business data. The official Squarespace XML export may help with WordPress content; the WordPress static guide is relevant only after WordPress becomes the source you want to freeze. Commerce records, customer data, checkout, accounts, subscriptions, bookings, and memberships need destination-specific tools, CSV exports, APIs, or a rebuild plan.

For larger sites, choose representative and important pages instead of assuming a bounded crawl will discover everything. Collection variants, hidden landing pages, old campaign URLs, and pages behind filters may need separate capture or a proper rebuild.

Step 4: inspect the output as an acceptance test

Do not treat a homepage screenshot as proof that you can leave Squarespace. Open the copied site and test:

desktop and mobile navigation;
one page from every distinct layout;
representative blog posts, portfolio items, events, products, and collection pages;
menus, galleries, lightboxes, accordions, overlays, tabs, and animations;
fonts, icons, responsive images, video posters, background images, and downloadable files;
clean routes, trailing slashes, anchors, and internal links;
legal pages, privacy pages, redirects, 404 behavior, sitemap, and robots rules;
forms, checkout buttons, scheduling widgets, member login controls, and search;
references that unexpectedly point back to a Squarespace domain, an old custom domain, or hosted endpoints.

Open the copied site and click through it for this reason. If the copy does not satisfy your acceptance list, a ZIP of the same files will not make missing platform behavior independent. If it does satisfy the list, you have the captured static files for the published pages and public assets you inspected.

Some remote requests are expected, such as analytics, embedded video, maps, and payment widgets. The goal is not a perfectly silent console. The goal is to know which pieces still depend on Squarespace or another service.

Step 5: replace Squarespace-hosted services

Forms and lead capture

Point each form at a new destination and test it on the temporary host. Confirm validation, spam handling, redirects, error states, CRM delivery, email alerts, consent language, and privacy requirements. Remove old Squarespace form scripts if they no longer have a role.

Commerce and payments

Choose the commerce system before launch. Product pages alone do not sell anything; inventory, cart, checkout, fraud checks, tax, shipping, discounts, refunds, subscriptions, customer email, order history, and admin workflows need a platform.

Scheduling and events

Choose a replacement scheduling service or rebuild the workflow. Test the whole customer path: availability, booking, payment, confirmation emails, cancellation, staff notifications, calendar sync, reminders, and support processes.

Member Areas and gated content

Pick a membership or authentication system if gated access still matters. Confirm sign-up, login, password reset, billing, permissions, content visibility, account emails, cancellation, and support workflows before launch.

CMS and content operations

For occasional brochure updates, direct HTML edits may be acceptable. For ongoing publishing, migrate content into WordPress, Ghost, a headless CMS, Markdown repository, or another system your editors can use. Keep the static copy as a bridge, not as the publishing system.

Analytics, pixels, email, and consent

Decide which tags should survive. A migration is a good moment to remove stale scripts. If consent rules apply, confirm the new deployment actually blocks optional scripts until consent rather than only displaying a banner. Move mailing lists and email campaigns to a separate provider before you shut down the source account.

Step 6: prepare the static files for self-hosting

Serve the archive locally first. Then review:

page titles, descriptions, canonical links, and Open Graph tags;
absolute references to old Squarespace hostnames or temporary domains;
sitemap and robots behavior;
custom 404 behavior and fallback routes;
redirects from previous URLs;
asset caching, compression, and MIME types;
security headers and iframe rules;
third-party scripts and allowed origins;
form endpoints and allowed origins;
accessibility after replacing forms, navigation, or widgets;
any generated files that are much larger than expected.

If canonical tags still point to the Squarespace version, update them before launch. Otherwise search engines may keep treating the old version as the source of truth. If internal links still target the old domain, decide whether to rewrite them or leave them as intentional external references.

Get the copy online first. Make the smallest changes needed for a reliable deployment. You can change more later, including with an AI assistant.

Step 7: deploy to a temporary host

Upload the static output to the host you intend to use under a temporary hostname. Cloudflare Pages, Netlify, Vercel, GitHub Pages, object storage with a CDN, and conventional web servers can all serve static HTML when configured correctly.

Test the deployed version, not just local files:

clean URLs and trailing-slash behavior;
HTTPS certificate issuance;
custom 404 page;
redirects from old paths;
canonical URLs and social previews;
sitemap and robots rules;
form endpoints and allowed origins;
cache rules for HTML and assets;
analytics events and conversion paths.

Production hosting changes path handling, redirects, HTTPS, caching, compression, and security headers. A folder that works locally can still fail after deployment.

Step 8: change DNS last

Keep Squarespace live while the replacement is under test. Save your current DNS records, connected-domain settings, mail records, and rollback notes. If you can, lower the relevant record TTL before the move, understanding that some resolvers may still cache longer.

Move DNS only after the temporary deployment passes acceptance. Then monitor the homepage, deep routes, TLS, form delivery, analytics, error logs, and the most important conversion path. Keep Squarespace available during this validation period, especially if real leads, bookings, purchases, or member access depend on the site.

If your domain is registered through Squarespace, separate domain ownership from website hosting. You may be able to keep the domain and point DNS somewhere else, transfer it to another registrar, or leave it registered where it is while the website runs on a different host. Confirm email records before changing nameservers.

Step 9: cancel the right things

Do not start a migration by cancelling Squarespace. Cancel after the new site has been copied or rebuilt, deployed to a temporary hostname, tested, moved behind DNS, and observed under real traffic.

Before cancelling, keep:

the static ZIP;
a copy in version control or durable storage;
the official XML export and any dashboard exports;
source brand assets;
the route and integration inventory;
old DNS records and rollback notes;
invoices and receipts for any plan or app changes.

Then cancel only the plan, add-on, domain connection, mailbox, scheduling subscription, email campaign service, or commerce dependency you no longer need. If another site, email service, domain, store, booking flow, or member system still depends on the same account, do not remove the wrong dependency.

Is Squarespace static output easy to edit?

Yes. The exported files are yours. An AI assistant such as ChatGPT, Claude, or Cursor can help you swap text or add a page if you do not want to hire a developer.

You still do not get the Squarespace editor, Commerce, members, or scheduling. Those hosted systems need replacements if you use them.

Should you rebuild instead of exporting Squarespace to HTML?

Rebuild if you want a CMS dashboard, a framework codebase, or new integrations. A static copy is enough when the current design should stay online and you will edit the files yourself or with an AI assistant.

The static export can still be useful during a rebuild. It gives you an archive, a visual reference, a temporary mirror, and a way to compare the new implementation against the old public site.

FAQ

Can I export Squarespace to HTML?

Yes, but not through a complete official Squarespace HTML export button. To export Squarespace to HTML in practice, use a public-site copier that captures the published pages, CSS, JavaScript, images, fonts, and files visitors can load, then inspect and test the static result before relying on it. The result can preserve the public front end, not private dashboard data or hosted backend features.

Does Squarespace give you HTML files?

Squarespace does not give you a complete set of portable HTML files for the whole live site. The official export is a WordPress-format XML file for supported content. If you need HTML files, you are looking for a published-site export or website downloader, plus separate exports for dashboard records and replacements for forms, Commerce, scheduling, members, and other hosted systems.

How do I export or download a Squarespace website?

First, use official Squarespace exports for supported content and dashboard data you need to preserve. Next, create a public static copy of the published pages if the visible website should be archived or self-hosted. Then inspect the output, replace hosted services such as forms or checkout, deploy to a temporary host, change DNS only after testing, and cancel Squarespace only after the replacement works.

Is a Squarespace backup the same as a website download?

No. A Squarespace backup should preserve the data and records you may need later, while a website download captures the public pages and assets a browser can receive. You may need both: official XML or dashboard exports for source content and business records, plus a static copy for the visible front end.

Will Squarespace Commerce, forms, members, or scheduling work after export?

Not as independent static files. Product pages, form layouts, member marketing pages, and scheduling pages may remain visible, but inventory, checkout, submissions, authentication, permissions, availability, reminders, payments, customer records, and dashboard workflows need separate exports, replacements, or rebuilds.

Should I cancel Squarespace before exporting?

No. Keep Squarespace live until the replacement has been copied or rebuilt, deployed to a temporary hostname, tested, moved behind DNS, and observed under real traffic. Cancel only after required routes, forms, purchases, bookings, member flows, analytics, and integrations work somewhere else.

Can I keep my domain if I leave Squarespace?

Usually the domain decision is separate from the website export. If the domain is registered through Squarespace, you may keep it there and update DNS, transfer it to another registrar, or move nameservers depending on your setup. Save existing DNS records first, especially email records, and change the domain only after the new host passes testing.

Can I edit the HTML after exporting?

Yes. The files are yours. An AI assistant can help you swap text or add a page if you do not want to hire a developer. You do not get the Squarespace editor or a CMS dashboard with the ZIP.

Can I move from Squarespace to WordPress with a static ZIP?

A static ZIP can preserve the public design, page copy, and assets as a reference or temporary mirror. It is not a WordPress migration by itself. Use Squarespace's official XML export where it applies, then use destination-specific importers, manual cleanup, or a rebuild plan for posts, pages, theme structure, forms, commerce, and editor workflows.

Is a Squarespace website downloader different from a general website downloader list?

Yes. A general website downloader comparison helps choose between tool categories. This guide is Squarespace-specific: it defines official XML export versus static public copy versus backup, explains hosted feature limits, and gives an exit sequence that avoids changing DNS or cancelling too early.

Can I use the static ZIP as my long-term website?

Yes, if the copy passes your acceptance test. Replace forms, Commerce, scheduling, memberships, or other hosted systems if you use them. The pages themselves stay yours, and an AI assistant can help you swap text or add a page.

What "successfully left Squarespace" means

You have successfully left Squarespace when the domain resolves to infrastructure you control, important public routes load without Squarespace hosting, required forms and integrations reach their new destinations, canonical URLs point to the new host, and your team knows how future edits will be made.

The last condition is easy to skip. The files are yours, and an AI assistant can help with later edits. Hosted systems such as forms, stores, members, and bookings still need replacements if you use them. Decide who owns those systems before you remove the platform that currently supports them.

There is a Squarespace export page for copying published pages.