What should a website content and URL migration include?
Direct answer. Use seven acceptance groups for a content migration: inventory, page mapping, content, media, metadata, working journeys and cutover. Moving files to a new host and rebuilding content in a different CMS are different scopes; count the pages and URLs before comparing quotes.
Commissioning work now? Compare the Wix or Squarespace to WordPress migration scope, or send the project details for a scope check.
Identify what is moving before choosing the service
A host move copies an existing application into a different hosting environment. A CMS move may rebuild layouts, replace widgets and change the way content is edited. A new domain adds another decision about addresses and access. A quote that says “website migration” without those boundaries can describe several very different jobs.
Write down the current platform, destination platform, domain decision, approximate content count and features people use. Include downloadable brochures, embedded forms, image galleries, search and language versions where they exist. Separate public editorial content from product catalogues, customer records, memberships and mailboxes. They do not become included simply because the business calls all of them “the website”.
Create the inventory and URL map together
Start a worksheet with one row for each relevant old address. Record its content type, current title, intended destination, decision and responsible approver. Use keep, merge, rewrite or remove as editorial decisions. If two old pages become one useful page, document that mapping rather than pretending the page counts still match.
The original seven-row checklist below is an acceptance framework. Adapt it to the actual size and scope of the site. Add an exception list for anything that cannot be moved as-is: a proprietary booking widget, a missing original image, an expired PDF or a page whose owner has requested removal. Discovering these before cutover makes the quote and approval meaningful.
| Group | Prepare before work | Verify at handover |
|---|---|---|
| Inventory | Pages, downloads, platforms and feature exceptions | Included and excluded content accounted for |
| URL map | Old address, destination and editorial decision | Relevant redirects or agreed error responses |
| Content | Approved text and pilot page types | Complete, editable destination pages |
| Media | Images, downloads and reuse rights | Important files served from intended locations |
| Metadata | Titles, descriptions and canonical choices | Agreed metadata, links and sitemap checked |
| Journeys | Contact form and other critical actions | Labelled tests reach their intended destination |
| Cutover | Editing freeze, backup, switch and recovery owners | Public checks and exception list recorded |
Test a representative pilot before copying every page
Choose a normal text page, an image-heavy page and a page with an important interaction for the first review. Three is an illustrative pilot size, not a package inclusion. Check the editable content in the destination CMS as well as the front of the site. A page that looks right but is a single uneditable screenshot fails a normal content-maintenance goal.
A content export is not the same as a portable copy of the whole site. Squarespace documents XML export of supported content for WordPress, with limits on what is included. WordPress’s own export tool produces a WXR XML file containing selected content data. Ask the implementer what the export carries, what needs separate files or rebuilding, and how the result will be checked. Avoid treating the existence of an import button as evidence that every widget and layout will survive.
Compare meaning, media and metadata
For each approved page, check the heading, main text, contact details, calls to action and relevant title and description. Preserve accurate content, but do not copy an obsolete claim merely because it existed on the old site. Ask the business owner to approve intentional edits. Carry a clear changed-content list so the migration review does not become an unbounded copywriting project.
Open important images and downloads from the new site and verify that the page does not silently depend on the old host staying online. Check captions, useful alternative text and links within the content. Missing files, broken internal links and content truncation belong in the defect list. Record the agreed handling of large media libraries and licensed assets rather than assuming every file is available for reuse.
Treat old addresses as a deliverable
Google’s site-move guidance recommends mapping existing URLs to their corresponding new destinations and implementing redirects when URLs change. Ask for direct old-to-new mappings and sample status checks, including important pages that receive links or enquiries. Redirecting every missing page to the homepage does not tell a visitor where the requested content went.
For intentionally removed content without a relevant replacement, agree the appropriate error response rather than manufacturing an unrelated destination. Review canonical URLs, internal links and the new sitemap as part of the move. Google warns that rankings can fluctuate while it recrawls and processes changes, so no migration supplier should promise that a checklist guarantees unchanged rankings or a fixed recovery date.
Protect the enquiry journey and the cutover window
Plan when content editing pauses, who can approve the switch and how last-minute changes are carried over. Identify the backup or retained original site, where it is stored and what would trigger recovery. For a site that accepts enquiries or orders, say how records created around cutover will be reconciled. A rollback can otherwise restore old files while losing newer business records.
Test the important journey on the new environment and again after the domain points there: send a labelled enquiry, inspect its destination, open key downloads and follow important navigation. Check HTTPS and the agreed public URLs. Keep business email dependencies visible when DNS changes; moving website files does not migrate mailbox contents. Remove temporary staging restrictions from the public pages where appropriate, while keeping the staging copy controlled.
Use a brief that separates transfer from rebuilding
Example brief: “Move our twelve public brochure pages to WordPress on our hosting. Approve a representative pilot, preserve the agreed text and media, carry page titles and descriptions, and map changed addresses to their relevant new pages. Recreate the named contact form and demonstrate a delivered test enquiry after cutover. Quote the booking widget and mailbox migration separately.” This describes an example project boundary, not an automatic entitlement under any service.
ZoopCoder’s website migration service lists backup, transfer, testing, DNS/SSL and post-move checks for an existing site, with hosting, mailbox content and sites over 10 GB excluded from that fixed scope. The separate Wix/Squarespace to WordPress scope covers rebuilding up to fifteen pages, content and images, matching the current look, redirects, a recreated contact form and basic metadata. Hosting, ecommerce catalogues and unsupported platform widgets are excluded.
We sell migration work and publish this checklist so the boundaries are inspectable. Send the current URL, platform, page inventory and feature exceptions for a scope check. A useful proposal should tell you what will be copied, what will be rebuilt, what will be left out and what evidence you will receive before the old environment is retired.
Questions before you commission the work
Is moving hosting the same as changing my CMS?
No. A host move transfers the existing site, while a CMS change may require rebuilding layouts and features. Name both platforms and the included content before comparing quotes.
Does Squarespace allow content export?
Yes. Squarespace documents an XML export of supported content for WordPress, with exclusions. It is not a complete transferable copy of every design element, page type and feature.
Can a migration guarantee that search rankings stay the same?
No. Technical checks reduce avoidable mistakes, but search engines still have to recrawl and process changes. Monitor the old and new URLs and correct errors without promising a ranking outcome.
Sources and scope
Primary documents checked 4 November 2026. The commissioning tables and sample briefs are editorial suggestions, not platform requirements or measured client outcomes. Live service pages govern the current price and included work.