How to migrate from Squarespace to WordPress

Short answer: Squarespace’s built-in export covers your blog posts and standalone pages as a WordPress-compatible XML file. WordPress imports it in a few minutes. The hard parts are everything that XML does not include – images (still hosted on Squarespace’s CDN with absolute URLs), navigation, design, forms, custom CSS, member areas, and any commerce – all of which rebuild manually in WordPress. Plan for a weekend if your site is under 50 posts and you do not have a store; plan for two to three weeks if you have hundreds of posts, an active store, or heavy custom design.

This guide walks through the full migration end to end: what exports cleanly, what does not, how to rebuild the gaps, how to handle the image problem that traps most people, how to set up the 301 redirects that protect your SEO, and how to move the domain. The traps come at predictable points – missing images, wrong permalink structure, broken Squarespace-specific blocks – and each is fixable if you see them coming.

Migration at a glance#

Phase	What it covers	Time for a 50-post site	Time for a 500-post site
Plan	Inventory content, pick hosting, set up staging WordPress	1-2 hours	3-5 hours
Export from Squarespace	Generate the XML file	5 minutes	5 minutes
Import to WordPress	Run WordPress Importer plugin	10-30 minutes	1-3 hours
Image migration	Pull images off Squarespace CDN into WordPress media library	1-2 hours	4-8 hours
Rebuild pages and design	Pick a theme, rebuild non-blog pages, navigation, forms	4-8 hours	1-2 weeks
Redirects and DNS	301 redirect map, domain transfer or DNS change	1-2 hours	2-4 hours
Post-launch	Test, fix broken links, submit to Search Console	2-3 hours	1-2 days

The export and import steps are mechanical and fast. The rebuild step is where the time goes – because Squarespace’s design system does not exist in WordPress, anything visual rebuilds in your new WordPress theme regardless of how good the export was.

What migrates and what does not#

The Squarespace XML export is a WordPress-compatible WXR file. Understanding what is in it – and what is not – prevents the most common surprise mid-migration.

What the XML export includes#

• Blog posts (title, body content, publish date, author, categories, tags)
• Standalone pages (title, body, slug)
• Basic HTML formatting (paragraphs, headings, lists, links)
• Image references (as absolute URLs pointing back to Squarespace’s CDN – this is the trap, covered below)

What the XML export does not include#

• The images themselves – only URLs pointing to Squarespace’s CDN, which keeps serving them until you cancel
• Custom CSS or design styling
• Squarespace-specific blocks (gallery blocks, summary blocks, audio/video blocks, form blocks, e-commerce blocks)
• Member areas, gated content, or any audience features
• Comments (Squarespace’s commenting system is proprietary)
• E-commerce data (products, orders, customers)
• Site navigation and menu structure
• Forms and form submissions
• Custom code injection (header/footer scripts)
• 301 redirects you set up in Squarespace’s settings

For most blog migrations, the WXR file plus a separate plan for images and design covers 80% of the work. For sites with stores, member areas, or heavy custom design, expect the WXR to be a starting point that recovers the writing – everything else rebuilds.

Step 1: Set up WordPress before you migrate anything#

Migrating into a clean WordPress install you can throw away if something goes wrong is safer than migrating into your future production site. Two clean options:

Option A: Stand up WordPress on a temporary subdomain or staging environment. Pick a host, install WordPress on staging.yournewdomain.com or similar, do the entire migration there, verify it works, then push it to the real domain. How to create a WordPress staging site covers the staging pattern in detail.

Option B: Install WordPress locally first. LocalWP, DevKinsta, or XAMPP let you run WordPress on your laptop. You can do the entire migration locally and only push to production when satisfied. This works well for small migrations; it gets clunky for large ones because you have to migrate twice (local then production).

Whichever you pick, do these before importing:

1. Set permalinks to “Post name” (Settings > Permalinks > Post name). This produces URLs like yoursite.com/post-title/ – the closest match to Squarespace’s /blog/post-title structure, which makes the redirect map shorter.
2. Install an SEO plugin (Yoast or Rank Math). You will need it for the per-post meta descriptions, schema markup, and sitemap generation.
3. Pick a theme. This is where a lot of the rebuild time hides. Do not use a Squarespace-look-alike theme – WordPress’s modern block themes (Twenty Twenty-Five, Kadence, Astra, GeneratePress) are faster, more SEO-friendly, and more flexible. How to change, install, and customize a WordPress theme covers the theme picking and setup.
4. Configure basic settings – site title, tagline, time zone, default category. None of this carries from Squarespace.

Step 2: Export from Squarespace#

Squarespace’s export lives at Settings > Import & Export Content > Export. Click Export, pick WordPress as the format, and Squarespace generates an XML file.

A few constraints to know about:

• One blog per export. If you have multiple Squarespace blog pages, you export each one separately and import them separately.
• Pages with non-standard content are skipped. Album pages, product pages, gallery pages, event pages, and index pages do not export. Squarespace shows you a notice listing what was skipped. Note these – they will rebuild manually in WordPress.
• Member content is skipped. Gated content, member-only pages, and member sign-ups do not export.

Save the XML file somewhere you will not lose it. Squarespace lets you re-export, but doing so during DNS cutover is stressful.

Step 3: Import into WordPress#

In your new WordPress site, go to Tools > Import, find “WordPress” in the list, and click “Install Now.” This installs the WordPress Importer plugin. Once installed, click “Run Importer.”

Upload the XML file from Squarespace. The importer will ask:

• Assign authors. Map Squarespace authors to existing WordPress users, or create new users. If you are a one-person site, assign everything to your admin user.
• Import attachments. Check this box. This is the importer attempting to download the images that were referenced in the XML.

Click Submit. WordPress will work through the file, creating posts and pages. For 50 posts this takes a few minutes. For 500+, it can take an hour and may time out.

If the import times out (you will see “504 Gateway Timeout” or similar), the file is too large for your hosting’s PHP execution limits. Two fixes:

1. Split the XML file into smaller chunks (300-500 posts each) using a text editor and re-import each chunk.
2. Raise PHP execution time and memory limits if your host allows it – see WordPress maximum execution time exceeded for the specifics.

Most hosts run shared PHP limits around 30-60 seconds. Managed WordPress hosting typically runs higher.

Step 4: Fix the image problem#

This is where most Squarespace migrations get stuck. The WordPress Importer’s “Import attachments” option does its best to download images, but it has two real limits:

1. It depends on your server being able to reach Squarespace’s CDN reliably. Half the time it succeeds and pulls the images into WordPress’s media library. Half the time it fails silently, leaving image URLs pointing at Squarespace.
2. It does not update image URLs in post content. Even when it downloads an image, the post content still references the Squarespace CDN URL. Until you fix this, your posts are loading images from Squarespace – and the day you cancel Squarespace, every image breaks.

The right fix: Auto Upload Images plugin#

The free Auto Upload Images plugin is the standard solution. After you import, install it and:

1. Go to Settings > Auto Upload Images and review the settings (defaults are fine for most cases).
2. Bulk-update your imported posts. The plugin scans post content for external image URLs, downloads each image into the WordPress media library, and rewrites the URL in the post.

For a 50-post blog this finishes in a few minutes. For 500+ posts plan for an hour, and watch for memory errors – the plugin processes one image at a time but each download is a small spike.

Alternative: manual download#

For small migrations (under 20 posts), it is sometimes faster to:

1. Open each post in the WordPress editor
2. Right-click the image, copy the URL
3. Download the image from Squarespace
4. Re-upload into WordPress via the editor
5. Delete the old image reference

Tedious but reliable. Do not do this for sites with hundreds of images.

Verify with a broken-link checker#

After the image fix runs, install Broken Link Checker (the free WordPress plugin) and let it scan your site. Anything still pointing at *.squarespace.com or images.squarespace-cdn.com did not migrate and needs manual attention.

Step 5: Rebuild the non-blog parts of your site#

Posts and basic pages come over. Everything else rebuilds. Plan for this explicitly – it is the largest single time sink in a Squarespace migration.

Navigation menus. WordPress does not import Squarespace’s navigation. Recreate menus in Appearance > Menus (classic themes) or in the block editor’s Site Editor (block themes). Match your old structure as closely as makes sense, but you can use this as an opportunity to clean up.

Homepage. Squarespace homepages are built with their visual editor and do not export. Rebuild using your WordPress theme’s homepage template or the block editor. How to set the homepage in WordPress covers the static-homepage vs latest-posts decision.

Forms. Squarespace’s contact and newsletter forms do not migrate. Use WPForms, Fluent Forms, Gravity Forms, or Contact Form 7 in WordPress. Wire them to the same email destination or your email service provider (Mailchimp, ConvertKit, etc.).

Member areas and gated content. Squarespace’s member areas have no direct WordPress equivalent. The closest options are:

• MemberPress, Restrict Content Pro, or Paid Memberships Pro for paid memberships
• Restrict User Access (free) for simple per-page member-only gates

Member sign-ups and subscription history do not export – you will need to email existing members with new account credentials.

Stores. Squarespace Commerce does not migrate to WooCommerce. For small product catalogs (under 50 products), manual recreation in WooCommerce is the fastest path. For larger stores, look at Cart2Cart or LitExtension as paid migration services. Customer data and order history are particularly hard to migrate – in most cases you start fresh.

Calendars and events. Squarespace’s event pages do not export. The Events Calendar (free or pro) is the WordPress equivalent.

Custom CSS and design. Anything you customized in Squarespace’s design panel rebuilds in your WordPress theme’s customizer or CSS settings. This is often where the migration “feels” hardest because the result rarely looks identical out of the gate. Resist the urge to match Squarespace pixel-for-pixel – WordPress themes have different design conventions and trying to force a Squarespace look usually produces something that is neither.

Step 6: Categories, tags, and the permalink decision#

Squarespace’s blog tags and categories come through, but with a quirk: Squarespace allows the same name as both a tag and a category, while WordPress treats them as separate taxonomies. After import, review Posts > Categories and Posts > Tags for duplicates and clean up.

This is also a good moment to think about category structure. WordPress tags and categories for SEO covers the tag-vs-category decision; the short version is to keep categories broad (5-15 total) and use tags sparingly. Squarespace blogs often accumulate dozens of tags – a migration is a good cleanup moment.

Permalink decision. Squarespace URLs look like yoursite.com/blog/post-title . WordPress with “Post name” permalinks produces yoursite.com/post-title/ . You have three options:

1. Match Squarespace exactly with a /blog/%postname%/ custom permalink structure. Pro: every URL stays identical, no redirects needed for the slug part. Con: the /blog/ prefix is dead weight you will probably want to remove later.
2. Drop the /blog/ prefix and use plain /%postname%/ . Pro: cleaner URLs that match modern conventions. Con: every post needs a 301 redirect, covered below.
3. Move to a date-based structure like /%year%/%postname%/ . Generally not recommended – it ties URLs to publish dates and ages the content artificially.

Option 2 is what most migrations end up doing. The redirect setup is one-time work; the cleaner URL structure pays off forever.

Step 7: Set up 301 redirects#

This is the single most important SEO step in the migration. Without redirects, every backlink and search ranking pointing at your old Squarespace URLs hits a 404 on your new WordPress site. With redirects, the SEO equity transfers cleanly.

What needs redirecting#

• Every blog post URL ( /blog/post-title → /post-title/ )
• Every page URL ( /about → /about/ , etc.)
• Squarespace’s tag and category archive URLs if they had inbound links
• Image URLs only if they had direct inbound links (rare; usually not worth the effort)

The redirect map#

Open a spreadsheet. Two columns:

Old URL (Squarespace)	New URL (WordPress)
/blog/welcome-to-our-site	/welcome-to-our-site/
/blog/how-we-do-x	/how-we-do-x/
/about	/about/

Generate this by exporting your Squarespace sitemap ( yoursite.com/sitemap.xml ) and comparing to your new WordPress sitemap. For 50 posts, this is a 30-minute spreadsheet job. For 500+ you want a script – the WordPress export contains the new slugs, and the Squarespace sitemap contains the old paths.

Implementing the redirects#

Three places to put them:

1. A WordPress redirect plugin. Redirection (free, by John Godley) is the standard choice. Import the spreadsheet directly. Pro: easy to manage, no server access needed. Con: each redirect adds a tiny database query overhead.
2. At the web-server level (nginx or Apache). Faster than plugins, no database overhead. Pro: high-performance. Con: needs server config access.
3. A managed redirect manager if your host provides one. Hostney’s control panel includes a 301 redirect manager that does the same job without plugin overhead or config edits.

Test a sample of the redirects after launch by visiting the old Squarespace URL in a browser. You should see a 301 status in the network tab and end up at the new WordPress URL.

For redirect mechanics broadly, how to change your WordPress domain name covers the same redirect patterns from a different angle (domain change rather than platform change).

Step 8: Move the domain#

You have two paths and they affect the migration order differently.

Path A: Move the domain to a new registrar#

Squarespace lets you transfer domains out. The mechanics:

1. Unlock the domain in Squarespace’s domain settings.
2. Request the authorization code (sometimes called EPP code or transfer code). Squarespace emails it.
3. Start the transfer at your new registrar (Namecheap, Cloudflare Registrar, Porkbun, etc.). Paste the auth code. The transfer takes 5-7 days.
4. Update DNS at the new registrar to point at your WordPress host. The hosting will give you A records or nameservers.
5. Wait for the transfer to complete before canceling Squarespace – if Squarespace cancels first, the transfer can get stuck.

Transfer costs are usually $10-15 (one year added to your registration). Use this path if you want full control of the domain long-term.

Path B: Keep the domain at Squarespace, point DNS at WordPress#

Squarespace domains can be kept at Squarespace and only the DNS records point at the new WordPress host. Faster (no 5-7 day transfer wait), but you keep paying Squarespace for the domain.

1. In Squarespace’s domain settings, edit DNS records.
2. Update the A record for @ and www to point at your WordPress host’s IP (or use a CNAME if your host requires it).
3. Wait 1-24 hours for DNS propagation.
4. Cancel Squarespace’s hosting but keep the domain. Some plans bundle these; verify before canceling.

This path is faster but means you are stuck paying Squarespace’s domain renewals (often higher than transferred-out renewals at a budget registrar).

Either way, set up SSL on the WordPress side before the DNS change so the new site loads over HTTPS immediately. Most managed WordPress hosts handle this automatically.

Step 9: Post-launch checks#

The first 24 hours after DNS propagation are when broken things surface. Run through this checklist:

• Open the new site in an incognito window at the old Squarespace URL. You should be redirected to the WordPress version automatically.
• Test 5 random old post URLs. Each should 301 to the new WordPress URL.
• Run the Broken Link Checker plugin one more time. Look for anything still hitting *.squarespace.com .
• Submit the new sitemap to Google Search Console. Use the WordPress site’s sitemap URL (usually /sitemap_index.xml if you use Yoast, /sitemap.xml if Rank Math).
• Check Google Search Console for crawl errors. Some 404s in the first week are normal as Google rediscovers URLs – watch for sustained 404s that suggest a missed redirect.
• Test the contact form and any other forms you rebuilt. Send a test submission to verify the destination email works.
• Check the favicon, OG images, Twitter card images. These often need to be re-uploaded in WordPress.
• Verify Google Analytics or your analytics platform is firing on the new site. If you used Squarespace’s built-in analytics, you have lost that history – export anything you wanted to keep before canceling.

Plan to do another pass after a week. Some issues only surface once visitors find them.

Common mistakes#

• Canceling Squarespace before DNS has fully propagated. If the new WordPress site is not reachable yet and Squarespace turns off, your domain shows nothing. Keep Squarespace running for at least 7 days after the DNS change.
• Skipping the image migration step. Posts will look fine for weeks because images load from Squarespace’s CDN – until you cancel and they all break at once. Always run Auto Upload Images.
• Forgetting to set up redirects. Every old URL becomes a 404, and Google penalizes you for the sudden mass of broken pages. Set up redirects before DNS cutover.
• Trying to match Squarespace’s design pixel-for-pixel. The themes work differently. Pick a clean WordPress theme and let it have its own identity. Spending two weeks on CSS to match a Squarespace template is wasted time.
• Importing into your final production WordPress site. If something goes wrong, you cannot easily start over. Use staging or local first.
• Migrating during high-traffic seasons. If you are a content business with seasonal spikes (e-commerce, holiday content, event planners), migrate in the off-season.
• Not exporting Squarespace analytics history. Squarespace’s built-in analytics do not export and are gone the moment you cancel. Download CSV exports of anything worth keeping.
• Underestimating the rebuild time. Squarespace migrations are deceptively quick on the XML side and deceptively slow on the rebuild side. Budget 2-3x what you think for non-blog content.
• Skipping the staging WordPress install. Migrating live is high-stress and high-risk. The few hours to stand up staging save days of recovery if something breaks.

How long does it take?#

The honest answer depends on what your Squarespace site is, not just how big it is.

Site type	Realistic timeline
Blog only, under 50 posts, simple design	1-2 days
Blog only, 50-300 posts	3-5 days
Blog + a few static pages	4-7 days
Blog + member area	1-2 weeks
Blog + small store (under 50 products)	1-2 weeks
Blog + complex store + custom design	2-4 weeks
Enterprise Squarespace site with deep customization	4-8 weeks (consider hiring help)

The biggest variable is not post count – it is how much non-blog content you have. A 1000-post blog migration is mostly running the importer overnight and fixing redirects. A 50-post blog with a store, member area, and custom design is genuinely two weeks of work.

How Hostney handles this#

Hostney is purpose-built for WordPress – which is to say, once you are migrating off Squarespace and onto WordPress, the host you pick matters for the next decade more than the migration itself does.

For the migration: one-click WordPress install lets you stand up a staging WordPress site in a couple of minutes for testing. File manager, MySQL access, and the built-in 301 redirect manager handle the parts of the migration that need direct platform control – the redirect manager in particular saves you from installing a plugin and the database overhead that comes with it. SFTP and SSH access let you run Auto Upload Images at scale without timing out on shared PHP limits, because the PHP execution time and memory limits are configurable per site rather than fixed across the whole server.

For the post-migration site: per-site PHP version selection means you can run PHP 8.x for performance without breaking older plugins on the rare WordPress install that needs PHP 7.4. Daily automated backups capture your work before any post-migration cleanup, so an accidental find-and-replace mistake is reversible. The Hostney Cache plugin handles object caching and full-page caching with automatic purge on content changes, which matters more on WordPress than on Squarespace because Squarespace’s caching is invisible to you and WordPress’s is not.

Hostney does not include a Squarespace-to-WordPress migration tool – our migration plugin is purpose-built for WordPress-to-WordPress moves, where it handles the hard parts of the archive model, serialized data, and find-and-replace that Squarespace exports do not need. For Squarespace migrations the right path is the WordPress Importer plus Auto Upload Images, which is what this guide covers. Where Hostney earns its place is the destination side – the WordPress hosting that runs the migrated site – not the migration mechanic itself.

For the bigger picture of why WordPress migrations succeed or fail at scale, why most WordPress migrations fail (and what we do differently) covers the architectural failure modes – serialized data corruption, OFFSET pagination, WAF body inspection. Squarespace migrations dodge most of these by virtue of the XML format being simpler, but the same patterns apply if you later move your WordPress site between hosts. The host migration guide covers WordPress-to-WordPress moves end to end.

Summary#

Squarespace to WordPress is a two-track migration: the content track is mechanical (export, import, run Auto Upload Images for the image fix) and surprisingly quick; the rebuild track is manual and slow because Squarespace’s design, navigation, forms, and any commerce or member features have no direct WordPress equivalent. Plan for a weekend on a blog-only migration, a week or more if you have non-blog features, and several weeks if you have a store or deep customization. Do the work on a staging WordPress install before touching production, set up 301 redirects from every old Squarespace URL before DNS cutover, run Auto Upload Images so post content references the new WordPress media library instead of Squarespace’s CDN, and keep Squarespace running for at least a week after the new site is live so the transition is reversible. Done right, you keep your SEO equity, your readers do not notice the change, and you land on a platform that scales with the next ten years of your content – not the next twelve months.