
Squarespace exports directly into a WordPress-compatible file, so this move has an unusually direct path: export, import, match your URLs, then point the domain. Squarespace's export tool produces the same WXR/XML format WordPress uses natively, and WordPress.com even has a purpose-built importer for it. What doesn't come across is your page design, your store, and a handful of page types Squarespace excludes from every export — those get rebuilt, not imported.
In Squarespace, open the Import & export content panel, click Export, choose the WordPress icon, select a primary blog if you have more than one, and click Export again. Squarespace processes the export, which "may take a few minutes," then offers Download for the .xml file (Squarespace). The resulting XML file carries "layout pages," "one blog page, including all of its posts and up to 1,000 comments per post," and text and image blocks (Squarespace). It does not carry "other page types (including album pages, cover pages, index pages, info pages, calendar pages, portfolio pages, and store pages)," page-specific headers, footers or sidebars, multiple blog pages, or "Custom CSS" (same source). If your site has more than one blog section, only the one you pick during export comes across — plan to handle any others separately.
WordPress.com built a dedicated guide for this exact move, not a generic XML importer. From your WordPress.com dashboard, go to Tools → Import and choose the Squarespace importer if it's listed, or the general guided importer at the top of the page if not. Upload the XML file you downloaded. If Squarespace detected more than one author, you'll get the option to map each one to a WordPress.com user; otherwise everything is assigned to your account automatically (WordPress.com). Click Start Import — it runs in the background, and WordPress.com says "you should receive an email when it's completed" (same source). Images can lag behind: the same guide warns "the import may not include all images from Squarespace... images created from external links might not all come through," and recommends keeping your Squarespace site publicly accessible throughout the whole process so the importer can still reach them.
If you're also running a Squarespace store, that's a separate export: from Squarespace's Home Menu → Commerce → Inventory, click Export all to get a product CSV, then install the free WooCommerce plugin on WordPress.com, go to Products → Import, upload that CSV, and run WooCommerce's column-mapping importer (same source). Orders and customers aren't part of this product-only export; see our export capability matrix for what Squarespace Commerce does and doesn't export separately.
Self-hosted WordPress uses the identical WXR format, so the same export file works without conversion. In your WordPress admin, go to Tools → Import and choose WordPress, which "will import posts, comments and categories contained in the uploaded file into your blog" (WordPress.org). During the import you can choose to "map to an existing user on the blog or to create a new user" for each author, and check the option to "download and import file attachments" so linked images get pulled in rather than left as remote links (WordPress.org). If the export file is large, the same documentation warns "your server may run out of memory when you import it" If that happens on a large site, the fix is on the server side (a higher PHP memory limit from your host), not in the export.
Custom CSS, page layouts, and Squarespace's closed-editor design choices have no export path on any plan — Squarespace's own documentation lists custom CSS under content that "won't export." Screenshot every page you care about before you cancel Squarespace, and rebuild the layout by hand in a WordPress theme, since there's no file that carries a Squarespace design into WordPress. The same is true for store, cover, album, index, portfolio, and calendar pages: none of them are in the XML export, so anything you need from them (a photo gallery's layout, a calendar's event list) has to be rebuilt in whatever WordPress plugin or block pattern replaces it.
This is the one place WordPress.com documents an exact fix. If your Squarespace blog posts used a pattern like www.yourwebsite.com/blog/post-title, go to Settings → Permalinks on your new WordPress.com site (WordPress.com documents this for Personal, Premium, Business and Commerce plans), choose Custom structure, and enter /blog/ followed by the %postname% tag. WordPress.com's own example confirms the result: your posts "will automatically include the blog title after 'blog,' as follows: http://www.yourwebsite.com/blog/post-name" (WordPress.com). Self-hosted WordPress has the same Settings → Permalinks screen with no plan restriction. Either way, spot-check a sample of imported posts against their old Squarespace URLs before you cut over — a mismatched permalink structure is easy to catch now and expensive to find out about from a 404 report later. For any URL that still changes despite matching the pattern (a renamed page, a retired store URL), our redirects guide covers building the map and setting the 301s on the WordPress side.
WordPress.com's own guidance is to keep the Squarespace site live and public through the whole export and import process, specifically so image imports keep working, then only move the domain once you're satisfied with the new site's content and design (WordPress.com). If your domain is registered at Squarespace, you can either connect it to WordPress.com by DNS or transfer the registration outright — WordPress.com documents both paths from the same step. If you also run email through the domain (Google Workspace added via Squarespace, for example), read will switching builders break my email before you touch any DNS records — a domain move for the website and a domain's mail records are separate things, and it's easy to break one while fixing the other.
Moving to WordPress trades one platform's constraints for a different set — themes and plugins instead of Squarespace's block editor. If the actual complaint is the editing experience rather than the platform, our guide to moving from Squarespace to Figment covers a different kind of destination: a Figma file published directly as a site. It's not a replacement for this WordPress path if you specifically want a CMS, comments, or a plugin ecosystem — just a different answer to a similar complaint.
Example (hypothetical): A consultant's Squarespace site has 25 blog posts under /blog/, a services page, and a gallery-style portfolio page. The move: export the WordPress XML from the Import & export content panel, import it via WordPress.com's Squarespace importer, set the custom permalink structure to /blog/%postname% to match the old URLs, manually rebuild the portfolio page in a WordPress gallery block (since portfolio pages aren't in the export), screenshot the old page for reference first, then point the domain at WordPress.com once the new site is verified. This is illustrative only, not a test we ran.
The export/import process doesn't touch your Squarespace site, so a bad import costs you time, not data — delete the partially-imported content on WordPress and re-run the same XML file. If images are missing afterward, re-check that your Squarespace site is still public (the importer fetches images from the live Squarespace site, so a canceled or password-protected site makes any re-run fail to fetch them) and manually upload any that still don't resolve. Keep both the original XML export and your Squarespace account active until you've confirmed every post, its images, and its URL are correct on the new site — cancel Squarespace only after that check, not before.
Bottom line: Export from Squarespace's Import & export content panel, import with WordPress.com's dedicated Squarespace importer (or the standard WordPress importer, self-hosted), match your permalink structure to keep URLs intact, and rebuild the page types Squarespace never included in the first place.