How to Move Your WordPress Site to Squarespace

Canva-generated infographic

The honest truth is that this step-by-step guide for moving a WordPress site from a major web hosting provider to an all-in-one website builder covers exactly what most tutorials skip: the sequence.

Moving a self-hosted WordPress site to a platform like Squarespace is absolutely doable for most small businesses and creators, but it’s not a one-click process.

The order matters more than most guides let on.

Get the sequence wrong and you’ll either lose search rankings, face hours of downtime, or find yourself rebuilding without a safety net. This guide walks through every stage in the right order, from protecting what you have before touching a single setting to going live on your new platform with your rankings intact.

If you’re specifically planning a move to Squarespace and want someone experienced in your corner, Wallis Williams Design offers one-on-one guidance for exactly this kind of transition.

But first, here’s what the process actually looks like.

Back up everything before you move a single file.

This step is the safety net most people skip because they assume their hosting provider handles it.

Many hosts do provide backups, but retention periods, formats, and restore options vary widely, and none of them guarantee you a backup in a format you fully control.

Before migration, you need your own complete export of the site’s data and media.

Export your WordPress database as a SQL file

The WordPress database contains every post, page, setting, user, and piece of metadata on your site. If you have phpMyAdmin access through your hosting control panel, open it, select your WordPress database, and use the Export function with the SQL format selected.

If you’re comfortable with command-line access via SSH, WP-CLI is more reliable: run “wp db export backup.sql" from your WordPress directory, and you’ll get a clean SQL dump in seconds.

One critical detail most guides omit:

WordPress stores complex data structures in a serialized format inside the database. If you ever need to do a URL find-and-replace on this file, a plain text editor will silently corrupt those values by changing string lengths without updating the serialized length counters.

Always use WP-CLI’s search-replace command (wp search-replace 'https://old-domain.com' 'https://new-domain.com') or a migration plugin for any URL replacement.

This is the most overlooked reason why DIY migrations break.

Download Your Media Library from “WP-Content/Uploads”

WordPress stores every uploaded image and file in the wp-content/uploads folder, organized by year and month. This is the only folder you need to preserve for content purposes.

Themes and plugins won’t follow you to a builder platform, so there’s no point downloading them.

In cPanel’s File Manager, navigate to “wp-content”, right-click the uploads folder, compress it as a ZIP, then download that ZIP.

Downloading a compressed archive is faster and far less likely to miss files than selecting items individually.

Document Your Current URLs and SEO Data

Run a full crawl of your site using Screaming Frog or export your URL list from Google Search Console before you change anything.

Save every URL, page title, meta description, and H1 heading into a spreadsheet.

This document becomes your redirect map later, and skipping it is one of the most common causes of migration-related damage to search rankings; without a complete URL record, you simply cannot redirect pages you’ve lost track of.

You cannot protect rankings for URLs you never documented.

Step by Step: What Transfers and What You’ll Rebuild from Scratch

Here’s the reality of what moves and what doesn’t, and why the rebuild side of the ledger isn’t as bad as it seems.

Squarespace has a WordPress importer that can pull over blog posts, categories, tags, authors, and attached images when you provide your WordPress XML export file or site credentials.

What it reliably imports is blog content.

Static pages and page layouts often need manual reconstruction depending on your export and content structure. The importer does not bring over plugin content, gallery images, image captions, CSS styles, or media stored in your WordPress library that isn’t directly attached to a post or page.

You will need to recreate or adapt on the new platform:

• Service pages

• Landing pages

• Portfolio layouts

• Navigation menus

For platform functionality, the four areas where WordPress users most rely on plugins all have native equivalents on major builders.

• Contact forms exist as native blocks.

• Squarespace includes SEO settings, such as meta titles, meta descriptions, XML sitemaps, canonical tags, and structured data, without requiring a plugin.

• You can handle e-commerce through Squarespace Commerce.

• Blogging works natively.

The harder cases are complex membership sites, highly customized WooCommerce stores with extensive order history, and any site that relies on logic-heavy custom plugins.

Those situations require either third-party integrations or a rethink of how we deliver those features on the new platform.

The upside of rebuilding is real. Most WordPress sites that have been running for years accumulate bloated plugin stacks, unused theme files, and layers of technical debt.

A rebuild on Squarespace’s all-in-one platform can often result in a faster, cleaner site with significantly less ongoing maintenance.

Building Your New Site Systematically Before Touching DNS

The biggest mistake in the rebuild phase is building reactively, adding pages as you remember them rather than working from a plan.

A systematic approach prevents that.

Start by turning your URL export into a site structure spreadsheet.

List every WordPress page, its current URL slug, its purpose, and what it maps to on the new platform.

Decide which pages are being kept as-is, combined with other pages, retired, or restructured. This document serves two purposes: it drives your build order and informs your redirect strategy.

Don’t build a single page on the new platform until you know what your final navigation structure looks like.

Before adding content, set up the foundational configurations first:

• SEO page titles and meta descriptions in the platform’s SEO panel

• Form blocks connected to your email provider or CRM

• Google Analytics

• Any scheduling or booking tools

Wiring these in before content goes in means everything is connected and working from the start, rather than going back to configure integrations after dozens of pages are already published.

Rebuilding on Squarespace isn’t technically difficult, but the decisions compound quickly.

• How does a page layout that doesn’t map cleanly to the new platform’s blocks get handled?

• Does that custom feature require code injection or a third-party embed?

Business owners can work directly with Wallis Williams Design for personalized Squarespace guidance tailored to their specific site and goals, rather than spending weeks working through those questions alone.

Working with a specialist can save significant time compared to solo trial-and-error; decisions that might take days to research and test on your own get resolved in a single focused session.

Step-by-Step Domain Transfer:
Moving from Major Hosting without Taking Your Site Offline

Domain transfers make people nervous, but the process is controllable when you understand TTL timing.

Most site downtime during a migration comes from changing nameservers before the setup is ready or before the TTL is low enough to allow fast propagation.

Lower your TTL 24 to 48 hours before the cutover

TTL (time to live) controls how long DNS resolvers cache your current records. If your current TTL is set to 86,400 seconds (24 hours) and you change your nameservers, resolvers that cached the old records can continue pointing visitors to your old host for up to 24 hours while they wait to check for updates.

The fix is straightforward:

Log into your current DNS provider at least 24 to 48 hours before your planned cutover and lower the TTL on your A records and CNAME records to 300 to 600 seconds.

Then wait out the original TTL before making the switch, giving resolvers time to pick up the lower value.

The nameserver switch: sequence matters

• Once your new site is fully built and tested on the builder platform, log into your domain registrar and update the nameservers to those provided by your new platform.

• Keep your old hosting account active during the switchover window; do not cancel it the same day you go live.

• With a lowered TTL, most visitors will resolve to the new site within one to four hours, though full global propagation can take up to 48 hours.

• Confirm the new site is loading correctly from multiple devices and different networks before considering the old hosting account expendable.

Protecting Your Search Rankings Through the Transition

A platform migration changes URLs, removes plugins, and restructures pages. Without a deliberate redirect strategy in place before launch day, Google loses the connections between your old content and your new pages, and rankings drop.

Pull your saved URL list from the pre-migration audit and map every old WordPress URL to its exact equivalent on the new platform.

If a page was retired or consolidated, redirect it to the most closely related existing page.

Redirecting everything to the homepage is one of the most common SEO mistakes during a migration; Google treats it as a soft 404 signal, which causes ranking authority to evaporate rather than transfer to your new pages.

In Squarespace, redirects are managed under Settings, then Developer Tools, and then URL Mappings.

Enter each redirect on its own line using the format /old-url -> /new-url 301. The old URL must not exist as an active page in Squarespace for the redirect to work.

Add every redirect from your map before or immediately after you publish the new site, and confirm how your Squarespace account applies them.

Test each one by visiting the old URL and confirming it lands on the correct new page with a 301 response.

Then submit your updated sitemap to Google Search Console and monitor the Coverage and Crawl Stats reports in the days following launch for any errors that surface.

Test Before Going Live and Know Your Rollback Plan

Going live before testing is the most avoidable migration mistake. A structured review of the new site before the DNS switch catches problems that would otherwise appear in front of real visitors at the worst possible time.

• Work through the site systematically.

• Test every page on desktop and on mobile.

• Click every navigation link.

• Submit every form and confirm the notification email arrives.

• Verify that images load at appropriate sizes without blurring or unusual cropping.

• Verify that every redirect you configured returns a 301.

• Confirm that your SEO meta fields are populated for every key page.

• Check that the SSL certificate is active and the site loads on HTTPS without a security warning.

None of these checks are complicated, but doing them before launch rather than after is what separates a clean migration from a stressful one.

Keep your WordPress hosting active, and do not delete anything until your new site has been live for at least 24 to 48 hours with stable traffic, longer if your site handles significant volume or you want additional confidence before cutting over fully.

A rollback is only possible if the old environment still exists.

If something breaks after the DNS switch, you can revert the nameservers to point back to the old host while you resolve the issue.

That option disappears the moment you cancel old hosting, so resist the urge to cut the cord on day one.

The Migration is a Process, Not a Single Event

This step-by-step guide for moving a WordPress site from a major web hosting provider to an all-in-one website builder is all about sequence:

• Backup up first

• Document your URLs before you touch anything

• Rebuild systematically

• Lower TTL before the DNS switch

• Implement every redirect before or immediately after launch

• Test thoroughly before going live.

• Sites that skip steps in the middle are the ones that lose rankings or face unexpected downtime.

The rebuild phase, especially on a platform like Squarespace, often results in a faster and easier-to-maintain site than what you’re leaving behind, built-in SEO tools, a streamlined design system, and far fewer plugins demanding ongoing updates just to stay secure.

The process takes real effort, but the outcome is a site that’s genuinely easier to own long-term.

If you’re planning this migration and want an experienced Squarespace specialist involved at any stage, whether that’s auditing your current WordPress setup or guiding the rebuild from start to finish, Wallis Williams Design is worth reaching out to before you begin.

The guidance is one-on-one throughout, with transparent flat-fee consulting so you know what you’re getting into before you commit.