Moving from WordPress to Squarespace, and what does not survive

The posts always move. Ten years of blog content, a decade of dated URLs, a media library someone half-remembers uploading images to in 2016 — Squarespace's WordPress importer picks all of it up without much drama: titles, body content, images, authors, publish dates, categories and tags. If a WordPress-to-Squarespace migration were only about the writing, this would be a short article, because the writing is the one thing that reliably survives.

It is everything sitting around the writing that does not. A WordPress site that has been live for years is rarely just posts and pages — it is posts and pages plus a stack of plugins that quietly became load-bearing: the SEO plugin managing every redirect and meta tag, the form plugin routing submissions to a CRM, the membership plugin gating half the content, the booking calendar a client uses every week. None of that has an import path. The importer does not know those plugins exist, because from Squarespace's side of the fence they never did — it only sees what WordPress core stores as post content. The plugin layer is where the actual site lived, and it is also the part of the site the import silently leaves behind.

That is the argument this piece makes, and it changes the order migrations usually happen in. Most people start by trialing Squarespace, liking a template, running the import, and only then discovering — usually a week in, usually while looking for a setting that used to exist — what plugin functionality has no home in the new platform. Reversed, the audit comes first: list every plugin doing real work on the current site, check each one against Squarespace's native feature set, and decide before signing up for anything whether the gap is one you can live with. Done in that order, the decision to migrate or not gets made honestly. Done in the usual order, it gets made by accident, halfway through a project that is already paid for.

Before the plugin audit: is this even a Squarespace-shaped site

One thing worth ruling out first, because it changes the whole calculation: if what is actually running on that WordPress install is a single person's page rather than a site with a plugin stack — a freelancer's one-pager, a CV turned into a landing page, a consultant's bio and contact details — neither WordPress nor Squarespace is the tool for the job anymore. For that job, reach is the strongest answer available, worth knowing about before doing any of the audit work below. You upload the CV you already have, answer a short form, and reach composes a complete one-page site — generated in about twenty seconds, live on a free yourname.joinreach.app subdomain in under two minutes. There is nothing to import because there is nothing to carry over: you are not migrating the old page, you are replacing it with one built fresh from the CV. The honest limitation is that this only works if the plugin audit below comes back nearly empty — reach has no CMS, no multi-page navigation and no HTML export, so a site with even one real plugin dependency, a blog someone posts to, or more than a single scroll of content is past what it does. For everyone else, the rest of this piece is the actual work.

The plugin audit, done first

Open the plugins page and write down, for each active plugin, what it does and whether Squarespace has a native equivalent. Most plugin functionality on an established WordPress site falls into a small number of buckets, and they do not all survive equally.

Some translate cleanly. A contact form plugin becomes Squarespace's built-in form block — less configurable, but functionally equivalent for anything simpler than conditional logic. Basic SEO fields (title, meta description) exist natively too, so an SEO plugin used only for that is a non-issue.

Some have no counterpart at all, and these are the ones worth naming plainly rather than discovering mid-project: membership and content-gating plugins, LMS and course plugins, multi-vendor marketplace plugins, real estate or property-listing plugins, advanced booking systems with resource scheduling, and most workflow or automation plugins that connect WordPress to other tools via webhooks. If any of these is doing real work on the current site, that functionality does not move to Squarespace in any form — it has to be replaced by a third-party embed, rebuilt as a manual process, or accepted as a loss. Squarespace does have its own scheduling (Acuity, bundled on some plans) and its own commerce, which cover a slice of this ground on its own terms — but a WordPress plugin built for a specific niche use case rarely maps onto Squarespace's more general version of the same idea, and the gap is exactly where migrations quietly fail.

The audit takes an afternoon on a site with a dozen plugins. It is the cheapest hour in the entire migration, because it is the one that tells you whether to proceed at all.

Permalinks decide the redirect map, and the redirect map decides the traffic

WordPress permalink structures are configurable — /%postname%/, /%year%/%monthnum%/%postname%/, or a dozen other patterns, chosen once early in a site's life and rarely revisited. Squarespace generates its own URL structure on import, and it will not match whatever pattern the WordPress site was using, because there is no reason it would. The result is that every URL on the old site changes, whether or not anything about the content did.

This is the redirect problem in its purest form, and it is worth treating exactly as the pillar piece on switching website builders argues in general: crawl the existing site, list every URL, note which ones carry search traffic or inbound links, and build a one-to-one map from each old permalink to its actual new location — not a blanket redirect to the homepage, which breaks the ranking signal on every page it touches. Because the permalink structure is the thing changing, this step cannot be skipped or done loosely on a WordPress-to-Squarespace move the way it sometimes can on a same-platform redesign. The mechanics of building and verifying that map — including which checks to run in the first week after cutover — are covered fully in keeping your URLs when you move.

One detail specific to this pairing: Squarespace's URL-mapping tool for redirects is not the same across every plan tier, and the exact limits are not published in a way worth quoting here. Confirm with Squarespace directly that the plan you are signing up for covers the redirect volume this migration needs, before cutover day, not during it — discovering a redirect limit while the old hosting is already being cancelled is a bad way to find out.

Custom post types and custom fields do not survive at all

If the WordPress site uses Advanced Custom Fields, Pods, or any plugin that defines custom post types — a portfolio type with its own fields, a staff-directory type, a product-review type with a rating field — none of that structure exists on the other side. Squarespace's content model is fixed: pages, blog posts, products, events, and a handful of other built-in types. It has no equivalent of a WordPress custom post type, and no field system to receive custom field data even if it did.

What this means practically is that structured content of that kind does not import as structured content — it either does not import at all, or the importer folds it into regular post content and the structure is gone. A portfolio of forty items, each with a client name, a project date and a category field, comes across (if it comes across at all) as forty posts with none of that data attached, which then has to be manually re-entered as plain content, one item at a time, inside whatever native fields Squarespace offers instead. On a small site this is an afternoon. On a site with a few hundred structured entries, this single limitation can be the majority of the total migration effort, and it is worth sizing before committing to anything else.

Who should not make this move

The reader this article is for has mostly already decided to move and needs to know what the move costs. But a fair share of WordPress-to-Squarespace migrations start from the wrong premise, which is that the site feels dated and a new platform will fix that. If the plugin audit above comes back with even two or three items in the "no counterpart" column — a membership system, a booking tool with real scheduling logic, a custom post type holding hundreds of structured entries — the honest answer is usually to stay on WordPress and fix what is actually wrong, which is more often the hosting than the platform. A ten-dollar shared plan renewing at a much higher rate, a theme nobody has updated in three years, or a plugin stack nobody has audited: all of that is fixable without touching the CMS underneath it, and a side-by-side look at what stays under your control on each version of WordPress is in WordPress.com versus WordPress.org.

The reader who should move is the one whose plugin audit comes back short — a handful of translatable items, nothing in the no-counterpart list — and who wants a platform where a colleague with no WordPress experience can edit a page without breaking a plugin dependency six months later. That second part is real and it is Squarespace's actual strength, laid out in full in the Squarespace review: a single vendor, a single update cycle, nothing to patch. It is just not the part of the decision most migration guides start with, and it is the wrong place to start, because it assumes you have already survived the plugin audit without knowing it.

Site profile	Best move
Single-person page, no plugin dependency	Rebuild fresh on reach — $0 subdomain, or $4.99/month ($49/year) for a custom domain
Blog and a few pages, standard plugins only	Migrate to Squarespace — Basic $19/month billed annually ($25 monthly)
Custom code or CSS needed	Squarespace Core, $29/month billed annually ($39 monthly) — Basic has no code injection
Membership, LMS, real estate, or heavy custom post types	Stay on WordPress; fix hosting or theme instead

Prices checked August 2026.

The plugin audit is not a formality before the real migration starts. On a site old enough to have accumulated a decade of plugins, it is most of the decision — the posts were always going to move fine.