Wix and Squarespace do very well what they were built for: getting a decent site online quickly, without a developer. The problem does not appear at launch but two or three years later, when you want to do something the platform did not anticipate — and discover that you cannot.
Migrating to WordPress is then a routine operation technically, but with one breaking point: if the redirects are botched, you start from zero in search. It is the only part that cannot be fixed afterwards.
The real reasons for leaving a closed platform
The reasons usually given are cost or SEO. They are rarely the right ones. A platform subscription stays cheaper than a custom site for several years, and Wix has improved considerably on the technical side — a well-built Wix site ranks perfectly well.
The reasons that hold up are elsewhere. People migrate when they hit a functional limit: connecting the site to a business system, running a catalogue with unusual pricing rules, building a client area, automating a process. And they migrate when they want to own what they have built.
There is a third reason, less often stated and perfectly legitimate: the cost of leaving rises with time. A twenty-page site migrates in four weeks; the same site five years later, with two hundred pages, a blog and a store, takes three months. If the functional limit is identified and the decision is made, postponing it a year simply makes it more expensive.
The question that settles it
"What can I not do today?" If the answer is "nothing specific, but I was told WordPress is better for SEO", stay where you are. A poorly motivated migration costs more than it returns.
Redirects: the one step you cannot undo
Every platform has its own URL convention. Wix often produces addresses like /post/my-article, Squarespace /blog/my-article, WordPress /my-article. Any address that changes without a redirect loses all the value it had earned.
The method is simple but tolerates no approximation: export the full list of existing URLs before touching anything, map it against the new addresses, then write a 301 redirect for each pair. One by one, with no lazy catch-all to the homepage.
- Export URLs from Search Console and from the old sitemap — the two lists always differ
- Each old address points to its equivalent page, never to the homepage
- A redirect to the homepage is treated by Google as a deleted page: you lose everything
- Keep the redirects for at least a year, ideally forever
The most expensive mistake
Switching the domain before testing the redirects. Once the old site is off, the URL list becomes impossible to reconstruct cleanly. Test on a subdomain, verify every redirect, then switch.
What does not migrate automatically
Import tools recover text and images. They almost never recover the rest, and the rest is what takes the time.
- Layout: the platform's proprietary blocks have no equivalent, everything is rebuilt
- Forms and their recipients
- Redirects already in place on the old site — often forgotten, and losing them breaks long-standing inbound links
- Title tags and meta descriptions, where they had been customised
- Reviews and content embedded from third-party services
Expect most of the migration effort to sit on these items, not on moving the content itself. That is what explains the gap between an £700 quote and a £5,000 one: the first migrates the text, the second migrates the site.
The URL inventory, the first hour of the project
A migration starts with a list, not a mockup. Until you know how many addresses exist and which ones receive traffic, any quote is a bet. That list takes one to three hours on a fifty-page site, and this is the only point in the project where it is still easy to obtain: once the old site is switched off, it cannot be rebuilt.
No single source is sufficient, and that is precisely what most migrations get wrong. The sitemap contains only what the platform chose to declare. Search Console reports only pages that received at least one impression. A crawler finds only what is linked from another page. Orphans — old campaign pages, PDFs, thank-you pages — show up only in server logs or in the web archive.
| Source | What it gives | What it misses |
|---|---|---|
| XML sitemap | The pages the platform declares | Unpublished pages and PDF files |
| Search Console, pages export | URLs with an impression over 16 months | Pages with no visibility at all |
| Site crawl | Everything reachable by an internal link | Orphan pages with no inbound link |
| Analytics, landing pages | URLs that receive and convert traffic | Pages nobody ever viewed |
| Web archive | Older versions of the site | Completeness, by design |
The deliverable is a four-column spreadsheet: old address, twelve-month traffic, new address, status. It serves as the brief during the project, as the test script on switchover day, and as evidence three months later when somebody claims "we lost traffic" without being able to say on which pages.
Not every URL deserves a redirect, and that is a decision worth making early. Test pages, pagination duplicates and deliberately deleted content are better served by a 410, which tells Google the removal was intentional and speeds up the cleanup of the index. Redirecting three hundred worthless pages on principle scatters crawl attention instead of concentrating it.
What exactly you lose without redirects
"You lose your rankings" is a vague phrase that never says what actually disappears. Three distinct things disappear, and they do not come back at the same speed — two of them do not come back at all.
Inbound links first: every link pointing at a page that has become unreachable stops passing anything. Those are often ten-year-old links from a press piece or a trade directory, impossible to recreate. Then the ranking itself: the URL drops out of the index, usually two to eight weeks after the first 404. And finally bookmarks, links in email signatures, QR codes printed on brochures and the link on your Google Business Profile, all of which keep sending visitors to an error page for years.
| Treatment | Signal sent to Google | Effect on the visitor | Use it when |
|---|---|---|---|
| 301 to the equivalent | Earned value is transferred | Lands in the right place | The page still exists elsewhere |
| 302 temporary | Temporary change, no value transferred | Lands in the right place | Never during a migration |
| 301 to the homepage | Read as a deleted page | Has to hunt for it again | Never |
| 404 | Not found, out of the index in weeks | Error page | Only by accident |
| 410 | Deliberate removal, faster de-indexing | Error page | Content removed on purpose |
The most expensive treatment is not the 404, it is the blanket redirect to the homepage. It creates the illusion of a job done, since nothing visibly breaks, while Google reads it as a deleted page and the visitor lands on a site they must re-navigate to find what they came for. The bounce rate on those arrivals sits close to 100 %.
One reasonable exception exists. When the old site held hundreds of pages with no equivalent — an abandoned blog, a discontinued catalogue — redirecting to the nearest category page beats redirecting to the homepage, and a clean 410 beats both if the content is never coming back. What matters is that the treatment is coherent, not that it is uniform.
Recovering content when there is no export
Squarespace produces a partial XML export. Wix exports blog posts and nothing else. The site builders bundled by some hosts sometimes export nothing at all. In those cases the question is no longer "how do we export" but "how long to retype", and that question has a number attached to it.
The method that holds up is a crawl of the existing site, producing for each page the title, meta description, subheadings, body text and image list. Re-entry into WordPress then happens page by page: allow five to eight minutes for a simple page, fifteen to twenty-five for one built from laid-out blocks. Forty-five simple pages is therefore around five hours of work, not two days — provided you extracted the text in one pass rather than clicking through page by page.
Images need separate attention. The ones published on the platform were resized and recompressed for its own display; taking them as they are locks in mediocre quality permanently. If the originals exist somewhere — an external drive, a Drive folder, the photographer — this is the moment to go back for them. If not, accept the loss and budget a photo session within the year rather than discovering the problem six months later.
- Crawl first: titles, meta descriptions, H1s and body text in a single extraction
- Pull every image at the largest size available, and rename them while you are at it
- The web archive helps for pages deleted recently but still linked from elsewhere
- Form copy, confirmation emails and thank-you pages are lost every single time: list them separately
This is also the moment to decide not to bring everything across. On a two-hundred-page site, a third has had no visits in a year. Migrating them costs several days and returns nothing; removing them cleanly with a 410 lightens the site and focuses Google's crawling on what actually works. A migration is the only occasion when that pruning happens without argument: six months later, nobody dares touch it.
A realistic migration timeline
A quoted ten days to migrate a brochure site is a development estimate, not a project estimate. The gap comes from approval cycles, from the client's availability to proofread forty pages, and from testing the redirects, which cannot be compressed because it consists of checking lines one at a time.
On a fifteen to twenty page site the workable sequence is this: one week of inventory and design, two weeks of build and content re-entry, one week of testing, redirects and switchover. Four calendar weeks, of which around ten days are actual work. On a store, moving the catalogue, customer accounts and order history adds two to four weeks on its own.
- Week 1: URL inventory, Search Console export, decisions on what to delete
- Weeks 2 and 3: build on a subdomain closed to indexing, content re-entry
- Week 4: redirect table tested line by line, client proofread, switch over on a Tuesday morning
- Weeks 5 to 10: watch 404s, indexing and rankings, fixing as you go
Two pieces of common sense save days. First: freeze the content on the old site during the re-entry phase, or you migrate a stale version and replay the edits twice. Second: switch over on a Tuesday morning, never a Friday evening. The twenty-four hours after a switchover are when the omissions surface, and somebody has to be available to fix them.
Timing in the year matters more than people expect. You do not migrate a plumber's site in January, a sailing school in May, or a store in November. The two-to-six-week dip that follows every switchover is painless in a quiet period and expensive in peak season; it is often the only argument that genuinely moves a launch date.
The seven days after the switch
The switchover is not the end of the project, it is the start of the only phase where mistakes still cost nothing to fix. The most common by a distance is the staging robots.txt left in place, or WordPress's "discourage search engines from indexing this site" box left ticked. The site is perfect and invisible, sometimes for three weeks, before anyone notices.
- Day 0: check indexing is allowed, the certificate, the www redirect and the move to HTTPS
- Day 0: test ten redirects picked at random from the table, including the five most visited pages
- Day 1: submit the new sitemap in Search Console and request indexing of the homepage
- Day 1: send a test form and confirm the email arrives, spam folder included
- Day 7: pull the 404 report and complete the redirect table
- Day 30: compare impressions and rankings against the same period last year, not last month
Traffic monitoring needs one methodological precaution. Comparing against the previous month leads to false conclusions, because seasonality mixes with the effect of the migration: a switchover in late August mechanically produces a rise in September, including when the redirects are bad. The useful comparison is with the same period a year earlier, on impressions rather than clicks — impressions react first and can be read two weeks sooner.
Finally, keep the old site readable for a month on a technical address closed to indexing. It is the cheapest insurance in the project: the day you discover, three weeks in, that a pricing page was never brought across, you find it in two minutes instead of rewriting it from memory.
The two-minute test
Open Search Console, take the ten most-clicked URLs of the last twelve months, and paste them one by one into the address bar. If all ten land on the right page in a single redirect, the migration is probably sound. If one lands on the homepage, the whole table needs revisiting: the error is rarely isolated.
How long and at what cost
For a ten-to-twenty page brochure site: two to four weeks, £2,500 to £6,000, redirects and testing included. For a store: four to eight weeks and £7,000 to £17,000, with catalogue and order history migration being the main item.
Expect a traffic dip of two to six weeks after the switch, even with perfect redirects: Google has to recrawl and reassign. A dip lasting beyond three months signals a redirect problem, not a normal phenomenon.
Key points
- Migrate for a specific functional limit, not for a promise of better rankings.
- The URL inventory comes before everything else, and draws on four sources that complete each other.
- One-by-one 301 redirects are the only step that cannot be fixed later; a blanket redirect to the homepage is equivalent to deletion.
- Most of the time goes on layout, forms and old redirects — not on the text.
- Four weeks for a brochure site, outside peak season, switching over on a Tuesday morning.
- The seven days that follow decide the rest: indexing allowed, sitemap submitted, 404s reviewed.
FAQ — Migrating to WordPress
Will you lose your rankings by migrating?
Not if 301 redirects are done address by address. A dip of two to six weeks is normal while Google recrawls everything and reassigns value to the new addresses. A lasting drop beyond three months reveals missing redirects, or redirects all pointing at the homepage.
Can you export your content from Wix?
Partially. Wix allows exporting blog posts, but not pages or layout, which rely on proprietary blocks. In practice the text can be recovered and the structure has to be rebuilt. It is a constraint to build into the budget from the start.
How long should you keep the old redirects?
As long as possible. Google transfers the value within a few months, but inbound links and bookmarks point at the old addresses for years. A redirect costs nothing to keep: keep them indefinitely.
Should you change domain name at the same time?
No, definitely not. Changing platform and domain simultaneously makes it impossible to tell where a problem comes from if traffic falls. Migrate first, let it settle for two or three months, then change domain if it is genuinely needed.
How do you rebuild the full list of your old URLs?
By cross-referencing four sources, never one: the old site's XML sitemap, the Search Console pages export over sixteen months, a full crawl of the site, and Analytics landing pages. Each one misses what the others find — orphan pages often appear only in Analytics or in the server logs. Do it before touching anything: once the old site is off, the list is gone for good.
Can you migrate a small brochure site yourself?
For five to ten pages with no complex forms or store, yes, provided you take the redirects seriously. That is the one part where improvising is expensive, and it requires access to the server configuration file or a redirect plugin. Allow two or three weekends for a first attempt, and keep the old site reachable for a month: that is what separates a failed migration from a fixable one.
Sources
- Google — Site moves with URL changes — official procedure and the role of 301 redirects
- Google — Redirects and Google Search — redirect types and signal transfer
- Google — Site moves with URL changes — what the export actually covers
- Google — URL Inspection tool — checking indexing and redirects after the switch
- Google — Build and submit a sitemap — submitting the new sitemap on switchover day
Planning a migration?
Describe your current setup. I'll tell you whether migration is justified, what it really involves, and where the risks sit in your case.
Review my migration