A Squarespace to WordPress migration starts with selected content export and continues with rebuilding and verification. The XML export is not a complete copy of every page type, design setting, business feature, or media file.
Inventory the source, export the supported material, test a representative import, and create a separate plan for everything outside that path. Then rebuild the required layouts and functions, preserve or redirect important URLs, and verify the final site before ending source services.
This guide explains that process for a business website moving to WordPress. It distinguishes self-hosted WordPress from WordPress.com’s hosted import behavior and gives special attention to media that may still depend on the old site.
Define the destination and the project boundary
Choose whether the destination is a self-hosted WordPress installation or a hosted service such as WordPress.com. Confirm the actual importer, plugin access, staging, backups, and application requirements available there.
Do not assume a screenshot from a hosted dashboard describes every WordPress installation. Import controls, image handling, and plan capabilities can differ. Use the chosen platform’s current instructions.
Define the business outcomes separately from the platform. The owner may need easier publishing, a custom integration, a different store workflow, or more control over templates. Those outcomes determine what must be rebuilt and tested.
Keep an optional redesign visible as its own scope. Changing navigation, rewriting content, and replacing business tools at the same time can be sensible, but each decision adds work beyond importing XML.
Inventory what exists before exporting
Create a content inventory of pages, blog collections, posts, images, galleries, downloads, titles, descriptions, and important addresses. Include material not linked from the main navigation.
Create a functionality inventory of forms, commerce, scheduling, memberships, email campaigns, search, languages, and external services. A page can contain transferable text while the application behind its button requires a separate replacement.
Record the source owner, domain registrar, DNS provider, email service, and billing relationships. Keep secrets in a password manager rather than the migration worksheet.
The inventory is a reconciliation baseline. It lets you identify what moved, what requires reconstruction, and what the business intentionally retires. Without it, an importer can finish successfully while the project remains incomplete.
Read the export limitations before choosing a workflow
Squarespace’s current content-export documentation describes a WordPress-format XML file for selected content, with important exclusions.
| Source material | Planning treatment |
|---|---|
| Supported layout-page, text, and image content | Test the XML route and verify the destination result |
| Blog collections | Confirm which collection is selected; reconcile all required posts |
| Styles and custom CSS | Rebuild in the destination design system |
| Store and other unsupported page types | Use a separate supported data route or reconstruct |
| Audio, video, product, and other specialized blocks | Verify the actual exported result and rebuild missing behavior |
| Drafts and page-specific extra regions | Preserve separately where required |
This matrix is a planning summary, not a guarantee about a particular site’s export. Review the current provider documentation and inspect your actual file and sample import.
Handle multiple blogs explicitly
The documented XML process exports one selected blog collection at a time. A site with several collections needs a plan that accounts for all required material and avoids duplicate imports.
Keep a source-to-destination mapping for each collection and post. Decide whether separate source blogs become categories, separate content types, or another supported structure in WordPress.
Do not keep importing the same file into production until the numbers look right. Rehearse the mapping, understand duplicate behavior, and retain the original export unchanged. Record each import run and its scope.
Preserve material outside XML
Save approved copy, original media, downloadable files, and references for excluded features through authorized methods. Capture layout and behavior notes for pages that need reconstruction.
A screenshot preserves appearance at one viewport but not the underlying content, links, access rules, or dynamic behavior. Use it as a design reference alongside a structured inventory.
Keep private data protected. Customer exports, member records, form submissions, and business documents should not be placed in a public project folder merely because they are part of migration preparation.
Export while the source remains available
Follow the current Squarespace process for the relevant site and subscription state. The provider’s documentation includes availability requirements, so verify those before assuming an expired or private site can be exported normally.
Select the intended blog where the interface asks for one. Download and preserve the resulting XML with its source, date, and scope. Keep a separate untouched copy before any transformation.
Record any export error or missing content. If the process fails, preserve the message and consult the provider rather than repeatedly changing source content to force a result you cannot explain.
Keep the old site available as required for media retrieval during the import. Protect genuinely private material separately; do not make confidential content public simply to imitate a generic tutorial.
Build a protected WordPress test destination
Set up the intended host, supported runtime, theme approach, and required plugins. Confirm backup and recovery access before importing a large archive.
Protect the test site from public access and unwanted indexing. Google’s noindex guidance explains indexing controls, but noindex is not authentication or protection for private customer data.
Block or redirect outbound email, payments, webhooks, and other production actions before using copied business settings. A staging hostname does not prevent server-side integrations from contacting real services.
Record environment differences that affect testing, such as cache behavior, resource limits, mail capture, and external callback approval. A test can be useful while still having clearly documented limits.
Run a representative import first
Use the destination’s supported WordPress-format import process. If a separate importer plugin is required, check its current compatibility, source, and maintenance status before installation.
The WordPress.com Squarespace import guide describes that service’s workflow. Treat it as platform-specific guidance rather than proof of identical behavior on every host.
Map authors to legitimate destination accounts and preserve accurate dates where supported. Do not create invented author credentials or publication history to fill gaps in imported data.
Choose a sample containing ordinary pages, older and newer posts, image-heavy content, and unusual embeds. Verify its output before importing the rest of the archive.
Check the result beyond the completion message
An importer completion notice confirms that its operation ended. It does not establish that all source content was eligible, every remote file was retrieved, or the new layout works correctly.
Compare source identity, destination record, title, date, author, content, media, and URL. Record exceptions in a visible list with an owner and next action.
Check special characters, lists, quotations, tables, and embedded links. A visually subtle formatting loss can change meaning or make a useful guide difficult to read.
If an import is incomplete, diagnose the failed stage: export coverage, file parsing, remote-media retrieval, permissions, or destination limits. Repeating the entire import without understanding duplicate behavior can make cleanup harder.
Verify images as files, not just visible pictures
A page can display an image hosted by Squarespace after its text arrives in WordPress. That does not establish that the image is stored in the destination’s media system.
Squarespace’s export guidance specifically warns that self-hosted imports may retain reference links and describes separate image-preservation considerations. WordPress.com’s import guidance also advises checking for missing media. Treat actual storage verification as part of acceptance.
For important assets, confirm that the file exists in the intended WordPress storage and inspect the URL requested by the public page. Use representative fresh requests so a browser cache does not hide dependence on the source.
Reconcile media systematically
Create a list of important images and downloads with source usage, destination file, and verification status. Include older posts and pages outside the homepage.
Check originals and generated sizes where relevant. A thumbnail can work while a linked full-size file is missing. A product or portfolio page may use several images that an initial import handles differently.
If files need manual transfer, use authorized originals and preserve legitimate rights. Update content links to the destination through a reviewed process. Avoid blindly replacing every URL because some external citations and embeds should remain external.
Rebuild layouts around content patterns
A Squarespace layout does not arrive as a ready-to-use WordPress theme. Choose a destination design system that can express the business’s content and that its future editors can maintain.
Start with a small set of patterns: homepage, service page, article, portfolio or project page, and any important landing page. Define typography, spacing, navigation, image treatment, and calls to action once, then apply them consistently.
Use the source as a reference, not as proof that every layout decision must be reproduced exactly. A redesign can improve readability or editing, but the owner should approve changes that affect content, hierarchy, or customer paths.
Check mobile behavior early. A desktop reconstruction can appear close while menus, galleries, forms, and headings become awkward on a smaller screen. Test the actual patterns before rebuilding the entire site.
Preserve semantic structure
Use headings for content organization rather than choosing levels only for visual size. Keep descriptive link text and meaningful relationships between captions, images, and surrounding copy.
If the source contains a table or structured list, preserve its meaning in the destination. Turning it into an image may make it harder to read, search, or maintain. Choose a supported component that serves the information.
Review interactive controls through keyboard use as well as a pointer. A navigation menu that looks correct but cannot be operated reliably is not equivalent to the intended feature.
Separate reusable structure from individual content
Staff should be able to edit ordinary text and images without accidentally changing the whole page system. Use the selected editor’s supported patterns, templates, and permissions appropriately.
Document where site-wide changes belong. If the business changes a phone number, it should not need to discover several disconnected copies across custom HTML blocks and page footers.
Practice a routine content change with the future editor before handoff. The project should produce a usable publishing workflow, not a site that only the builder knows how to update.
Move commerce data through a separate supported path
Squarespace offers a product CSV export with its own scope and exclusions. Treat it as a product-data source, not a complete transfer of store design, customers, orders, payment relationships, and app behavior.
If WooCommerce is the destination, compare the export with the WooCommerce product CSV schema. Map fields deliberately and test representative product types before importing the whole catalog.
Do not assume two CSV files are interchangeable because both contain product names and prices. Variants, identifiers, images, inventory, categories, and custom fields may use different structures and meanings.
Validate a product sample
Choose a simple product, a product with variations, an item with several images, an unavailable item, and any special product type the business depends on. Check the destination’s actual support for each.
Verify names, descriptions, prices, identifiers, availability, options, shipping-relevant attributes, and image relationships. Keep the original source export unchanged and document any transformations.
A product that displays correctly can still behave incorrectly in cart or checkout. Test representative selections and confirm the intended total and order result through supported test facilities.
Plan historical and current obligations
Open orders, refunds, unfulfilled items, customer accounts, gift balances, memberships, and subscriptions need their own review. Verify supported transfer routes with the actual destination tools and providers.
Do not promise that customer passwords or recurring-payment credentials move through a product export. Establish the supported account and payment transition before asking customers to use the new site.
The business may retain source access for historical operations while starting new sales in WordPress. If so, document who handles old refunds, fulfillment questions, and records. A new storefront does not automatically make the old operational history irrelevant.
Treat scheduling and member features independently
A scheduling service may be a separate product or integration rather than part of the page export. Inventory the calendar, appointment types, availability, time zones, reminders, payment rules, and staff access.
Decide whether the destination keeps the existing external service or replaces it. An embed can sometimes remain appropriate, while a replacement requires data and workflow planning beyond page reconstruction.
For member content, identify accounts, access rights, paid entitlements, and protected files. A public page importer should not be assumed to recreate those relationships.
Test permitted and denied access with controlled accounts. A maintainer’s administrator session is not evidence that a customer has the correct rights after migration.
Keep communications under control
Test reminders, receipts, password resets, and form notifications with approved recipients. Prevent the protected development site from sending unintended messages to copied customer addresses.
If a new application requires a customer account transition, coordinate the communication and make its purpose clear. Do not send a bulk message just to discover whether every imported email address works.
Record which old and new systems remain active during transition. Duplicate reminders or conflicting account messages can confuse customers even when both applications are technically functioning.
Recreate forms and lead routing end to end
List each important form’s fields, required validation, attachments, consent choices, confirmation, storage, notification, and downstream destination. Rebuild the intended behavior using a supported WordPress tool.
Use fictional test details and controlled recipients. Verify that the submission reaches the actual mailbox, CRM pipeline, or booking system required by the business.
Check failure handling as well as success. A missing required field should produce a useful response, and a delayed integration should not silently create duplicate leads when a visitor retries.
Keep source submission history separately if the business needs it and a supported export is available. Preserving old records and operating a new form are distinct tasks with different acceptance criteria.
Map URLs before the public switch
Create a source-to-destination URL map from navigation, sitemaps, content inventory, and available analytics or search data. Include landing pages, older posts, downloads, and important campaign destinations.
Preserve useful existing paths where practical. When paths change, point each old address to equivalent final content through an appropriate permanent redirect.
Google’s URL-changing site-move guidance explains the related search-engine considerations. A redirect map supports the move, but it does not guarantee traffic or ranking outcomes.
Account for collection paths and trailing slashes
A source blog may use a collection prefix that differs from the destination permalink structure. Decide the final pattern before importing and linking the archive.
Test representative old URLs, including the variants people actually use. Confirm the final content and status rather than assuming a redirect plugin’s saved row means the public request behaves correctly.
Avoid unnecessary chains. Update the site’s own navigation, article links, canonical URLs, and sitemap to the final addresses so visitors and crawlers do not depend on repeated redirects.
Preserve useful metadata accurately
Review titles, descriptions, headings, image descriptions, and structured data against the final content. Some values may need manual reconstruction or mapping rather than arriving through XML.
Do not invent author credentials, reviews, or publication details to make structured data appear richer. Use accurate information and avoid duplicate article entities from overlapping SEO plugins.
If the migration includes a content rewrite, distinguish approved changes from transfer defects. The owner should know whether a missing paragraph was intentionally retired or accidentally omitted.
Plan domain routing without disrupting email
Website hosting, domain registration, DNS, and email can be separate services even when one account sells them. Confirm ownership and the exact changes needed for the chosen destination.
A registration transfer is not always required to connect a domain to new hosting. Review the available method and avoid adding an unnecessary account move to the launch window.
If authoritative DNS changes, preserve all required web, mail, verification, and service records. Coordinate any DNSSEC transition with the responsible providers rather than changing unfamiliar security settings casually.
Test employee mail separately from WordPress-generated notifications. A working mailbox does not prove the new form’s sending route is configured correctly, and a working form does not prove the business mail service survived a nameserver change.
Reconcile the archive before launch
Use a table that records source identity, destination identity, content type, import method, and verification result. Group exceptions by missing content, formatting, media, metadata, URL, or unsupported functionality.
Counts can reveal an obvious gap, but sample quality matters too. Review the oldest and newest posts, long pages, galleries, downloads, and records with unusual formatting.
Keep import runs traceable. Record the file, source collection, date, destination, and tool result. If a retry is necessary, understand whether the tool updates existing records or creates duplicates.
Do not clean up duplicates by deleting records at random. Compare source identifiers and destination usage, preserve a recovery point, and use a reviewed correction. A record that looks duplicated may have a different role or incoming URL.
Inspect rendered content and editor content
The editor can contain information that the selected theme does not display. Conversely, a rendered page can look complete while relying on an external embed or source-hosted asset.
Check both layers for representative content. Confirm that staff can maintain the result through the intended interface and that the public output matches the approved information.
If a new template intentionally hides a source field, record that design decision. Otherwise, missing presentation can be mistaken for missing data and lead to unnecessary reimports.
Coordinate final content changes and transactions
The source may continue changing while WordPress is built. Decide who can edit, how final changes are captured, and when the destination becomes authoritative.
A simple content project may use a coordinated editing pause and final comparison. An active store, booking system, or membership application needs a more detailed plan for records, external events, and ongoing writers.
List browser activity, staff, APIs, webhooks, imports, and scheduled jobs. A maintenance page may not stop every source of change. Do not assume that the source became static merely because public navigation was hidden.
Preserve final exports and a current destination backup before material launch operations. Keep one coordinator responsible for the boundary and reconciliation record.
Run acceptance checks through normal user journeys
For a service business, test mobile navigation, contact routes, forms, downloads, and the actual receiving system. For a publisher, test archive discovery, categories, internal links, and media.
For commerce, scheduling, or membership, use representative controlled scenarios and supported test facilities. Verify local records and relevant external state. Coordinate any necessary live transaction with the business.
Check an ordinary visitor and the relevant authenticated roles. An administrator may bypass cache or permissions that customers encounter.
Review secure hostname behavior, redirects, public indexing settings, and temporary-domain references. Remove staging-only restrictions from the intended production application while keeping test copies protected.
Verify maintenance and recovery readiness
Confirm backups for the new files and database, their storage location, and the authorized restore route. The WordPress file-backup guide and database-backup guide cover separate recovery components.
Record plugin and theme licenses, custom code, service owners, and update responsibility. Have the future editor perform a controlled routine change before handoff.
If the new application uses scheduled work, verify its actual execution mechanism. The WordPress Cron handbook describes the built-in model, while hosts and plugins may add their own runners. Do not run every pending job manually as a generic test because some actions have real business effects.
Troubleshoot an incomplete import by stage
An incomplete destination can result from a limited export, a stopped import, a failed media request, or a presentation problem. Those conditions need different corrections.
First compare the source inventory with the export’s documented scope. If a portfolio or store page type was never included, repeating the same XML import will not create the missing feature. Preserve the required source material and use the planned rebuild or separate data path.
If supported records are missing, inspect the import result and destination logs through the host’s approved tools. Record the file, run time, error, and last confirmed record. Avoid posting the full XML or private export publicly because it can contain information unrelated to the support question.
If records exist but do not appear publicly, inspect templates, publication state, navigation, and access settings. A theme that does not display a field can make valid imported data look absent. Confirm that distinction before deleting and recreating records.
Check media failures separately
A text import can complete while remote image retrieval fails because of availability, request limits, authentication, or destination capacity. Identify the actual failed asset and response rather than assuming every image needs the same treatment.
Keep the source available through the supported import period and verify the destination can write files through a safe application-level test. Have the host correct ownership or capacity where needed; do not make every directory broadly writable as an improvised fix.
For manual recovery, map the correct source asset to the intended destination usage. Similar filenames can refer to different crops or versions. A gallery that contains all expected filenames can still show the wrong image in a project if the relationships were not preserved.
Understand retry and duplicate behavior
Before rerunning an import, determine whether the tool recognizes existing records, updates them, or creates new ones. Test that behavior on a protected copy if the documentation does not answer the relevant case.
Preserve any destination edits made after the first run. A retry that updates existing content can overwrite approved corrections, while a retry that creates new records can leave duplicate URLs and confused navigation.
Keep the original export and transformed versions separately. Record the purpose of each transformation and which run used it. This allows a qualified operator to reproduce the process without relying on a file named “final-final” whose origin is unclear.
Verify authors, dates, categories, and comments deliberately
A content archive carries editorial context as well as text. Confirm how source authors map to real destination accounts and how publication dates appear in the final site.
Use controlled examples around dates where time-zone interpretation could matter. A post changing calendar date can affect archive ordering or a date-based URL. Preserve accurate source facts and record any deliberate editorial correction.
Decide how source collections, categories, and tags should organize the destination. Avoid creating a large set of nearly identical labels simply because several imports used slightly different names. Use an approved mapping and verify the public archive navigation.
If comments are part of the required transfer, review the export’s current limits and the actual destination result. Preserve moderation state and attribution where supported, and keep excluded or unsupported material visible in the exception record. Do not manufacture comments or reviews to make the new site resemble a complete archive.
Separate stored content from generated metadata
Some titles or descriptions may be explicitly saved in the source, while others are generated from a page template. A blank exported field does not always mean the public source had no title or description.
Use a baseline of important rendered pages to decide what the destination should emit. Recreate accurate metadata through the selected SEO system and inspect the final HTML. Do not fill every missing description with the same generic sentence merely to remove a warning.
Check article and organization structured data for accuracy and duplication. The migration should preserve legitimate identity and context without inventing publication dates, credentials, ratings, or media references.
Keep production performance part of acceptance
A rebuilt design can introduce a large hero image, several font families, or unnecessary scripts even when the content transfer is correct. Select representative pages and compare their actual delivery under recorded conditions.
Treat staging measurements as diagnostic evidence with limits. Shared resources, different caching, authentication, and test data can make the environment behave differently from production. Do not present one fast test run as proof of every visitor’s experience.
After launch, inspect the intended public route and important mobile interactions. If an optimization change is needed, preserve functionality while testing it. A faster page with a broken gallery, menu, form, or checkout does not meet the business requirement.
Give the future maintainer a short record of the important templates and acceptance checks. This connects the migration to ongoing care and makes later regressions easier to recognize.
Agree on a content freeze that fits the business
For a mostly static site, the final content boundary may be a brief editing pause and an owner review. Name the person allowed to make urgent source corrections during that window and how those changes reach WordPress.
For a dynamic application, a content freeze alone is not enough. Orders, bookings, memberships, API clients, and scheduled work can continue creating state. Identify the supported transition for each and preserve the final authoritative records.
If the launch is postponed, review whether the destination is still current. A migration candidate approved last week may omit changes made since then. Refresh or reconcile the relevant material deliberately, preserving approved destination work before replacing anything.
Retire Squarespace only after dependency review
Check that content and media are owned and served through the intended destination, old records remain available where needed, and domain and mail services have a clear home.
Do not use a universal countdown after launch as the only cancellation criterion. A successful homepage test does not establish that older images, downloads, billing relationships, or historical operations are no longer needed.
Keep necessary archives protected with a retention owner. Remove temporary accounts and revoke unnecessary integration access. Avoid leaving an old application publicly active with no maintenance responsibility.
Document what the business still uses from the source provider. A domain or scheduling subscription may remain intentionally separate from the retired website service.
Three illustrative migration decisions
These examples are fictional planning scenarios, not customer cases or performed tests.
A consulting site has supported pages and a blog
The team tests the XML route, maps authors and URLs, rebuilds the reusable page patterns, and confirms that images exist in destination storage.
The final acceptance includes article navigation, a controlled inquiry, mobile layout, and an owner editing exercise. The source remains available until media and service dependencies are verified.
A creative business has portfolios and several blog collections
The inventory identifies content outside a single XML export path. The team chooses a destination model for projects and blogs and preserves the required media and copy separately.
It reconciles each source collection and records unsupported layouts as rebuild work. The project is not marked complete merely because one blog imported successfully.
A retailer also uses scheduling and paid access
The project separates page content, product data, appointment operations, and member rights. Each has a supported transfer or transition plan and an explicit owner.
The team tests representative customer actions and explains where historical records remain. Launch is based on verified business workflows rather than a single importer report.
Keep a concise transfer manifest
Record each source export, its scope, capture time, and destination import run. Include separate media archives and business-data exports so the operator can see which material belongs together.
For every transformed file, retain the unchanged source and document the mapping or correction. A repeatable process is easier to review than a collection of manually edited copies whose differences are unknown. Keep customer data and secrets out of the owner-facing summary while preserving authorized access to the underlying evidence.
The final manifest should identify what transferred through XML, what used another supported route, what was rebuilt, and what remains elsewhere intentionally. Review it with the business owner before canceling source services. This makes completion a concrete agreement about content and responsibilities instead of a vague conclusion that the import looked successful.
If the source changes after acceptance, record whether the destination must be updated before launch. The manifest should describe the actual candidate being released, not an earlier rehearsal that no longer matches the business’s current information.
Frequently asked questions
Does Squarespace XML include the whole website?
No. The current export covers selected content and excludes important page types, styles, and features. Review the actual provider documentation and your source inventory, then create separate paths for everything required outside XML.
Will my Squarespace design transfer to WordPress?
Expect to rebuild the design through a WordPress theme and editing system. Preserve useful structure and brand assets with appropriate rights, but do not assume the source layout becomes an installable destination theme.
Can I migrate several blogs?
Plan for the documented selected-blog export behavior and reconcile every required collection. Decide the destination structure, track import runs, and avoid uncontrolled repeated imports that create duplicates.
Why do images appear but not show in the Media Library?
The page may still reference a remote source asset. Inspect the actual file URL and destination storage. Confirm media ownership and availability before ending the source subscription.
Does the product CSV move the whole store?
No. It is a product-data route with its own limits and formatting. Customers, historical orders, payments, subscriptions, fulfillment, and store behavior need separate supported planning and verification.
Can I keep my domain and business email?
Often, yes, with a clear service and DNS plan. Domain registration, web hosting, and mail are different responsibilities. Preserve required records and test both mailbox service and website-generated notifications.
Do I need a redirect for every imported page?
If a public address remains identical, it does not need a new redirect solely because the platform changed. When addresses change, map old URLs to equivalent destinations and test the actual request behavior.
When is the migration ready to launch?
When required content is reconciled, media and URLs are verified, business workflows pass their acceptance checks, final source changes are accounted for, and recovery and ownership are clear. Record remaining limitations instead of claiming every possible action was tested.
Keep the final acceptance tied to the actual release candidate. A result from an earlier rehearsal may no longer apply after a content refresh, template change, or new import run. Repeat the checks affected by those differences before the public switch.
Move the content and rebuild the responsibilities
A successful Squarespace migration combines a verified export with deliberate reconstruction of everything the business still needs. The inventory, exception list, and acceptance record make that work concrete.
Web Expert Solutions provides Squarespace-to-WordPress migration, website rebuilding, hosting, and troubleshooting support. Share the source content types, required features, and active business records so the proposed move can distinguish supported import work from the rebuilding and validation needed for a dependable launch.
