MOVE OFF A WEBSITE BUILDER WITHOUT LOSING RANKINGS

Do this first, today, before anything else moves. It takes twenty minutes and it's the most skipped step in every migration.

Export and save, with the date in the filename:

• Search Console performance, last 12 months. Queries and pages, exported separately. This is your evidence.
• Your top 20 pages by clicks, with their current average position.
• Analytics traffic by landing page, same window.
• The indexed page count from the Pages report. You'll compare against this for weeks.
• Which pages other sites link to, from the Links report, External links, Top linked pages. A page with three good inbound links is worth protecting even if it gets almost no traffic, because links are the part you can't rebuild by trying harder.
• Which pages produce enquiries, from your form or call tracking. Traffic and money are different columns, and this is the one that decides what gets careful treatment in step 4.

Here's why this matters more than it sounds. Search Console doesn't backfill. It holds roughly 16 months of rolling history, and that history belongs to the property, not to you. If something goes wrong six weeks after launch and you never took the export, there's no way to reconstruct what you had. The argument about whether the migration caused it becomes unwinnable, because nobody can produce the before state.

A real one: on the Wix migration we ran for Magic At My Door, a princess party company here in the GTA, the only surviving record of how the site performed beforehand is a manual export taken before launch. Not because anything went wrong, but because the new property started from zero and Google filled in nothing behind it. That export is now the single source for every before-and-after number, and it exists only because somebody spent twenty minutes on a Tuesday.

Your navigation isn't your site. Most builder sites carry pages that no menu links to and that the owner forgot exist: an old landing page from a campaign, a thank-you page, a service page that got superseded, blog posts from four years ago. Google still has them, and some of them still get traffic.

Pull from four places, because no single one is complete:

• Your XML sitemap. Usually /sitemap.xml. The starting point, not the answer.
• Search Console, Pages report. Everything Google has indexed, which will include things your sitemap doesn't.
• Analytics, landing pages, last 12 months. Anything that received a visit is a URL worth keeping alive.
• A crawl of the live site. Catches what's linked but not submitted.

Paste all four into one spreadsheet column and remove duplicates. That list, not your menu, is what you're migrating.

Before you plan a rebuild, establish what leaves with you. This is where builder migrations differ from any other kind of site move, and where the timeline usually slips.

Closed builders aren't designed to be left. Export tends to be partial, format-specific, or absent, and what you get is rarely the site: it's some of the text. Assume until proven otherwise that you're carrying content across by hand.

Check your platform's own current documentation rather than a blog post, because these capabilities change:

• Wix redirect and URL documentation
• Squarespace URL mappings

Then inventory what has to be recreated manually. Usually: page copy, images at full resolution, alt text, meta titles and descriptions, any structured data, and your form setups. Budget real hours for it. A migration that stalls halfway because nobody costed the copy-paste is how sites end up live and half finished.

Download your images while you still can, at the largest size available. This is the asset people most often discover they can't retrieve after cancelling.

Take the list from step 2, add a second column, and give every single URL a destination. One to one wherever a genuine equivalent exists.

The rule that matters most is about what not to do. Google is explicit: don't redirect many old URLs to one irrelevant destination such as the new homepage, because it confuses users and might be treated as a soft 404. That's worth understanding rather than just obeying. A bulk redirect to the homepage looks tidy, produces no broken links, and quietly throws away everything each of those pages had earned. It's a 404 wearing a costume.

So for each URL, one of four decisions, and every one gets written down:

• Direct equivalent. The same page on the new site. Most of your list.
• Closest parent. No exact match, but a genuinely relevant category or service page.
• Recreate it. The page earns enough that it should exist on the new site even if you weren't planning to.
• Let it go. A deliberate 404 is a legitimate choice for a page with no traffic, no links and no equivalent. An accidental one isn't.

The difference between a real redirect map and a lazy one is whether the fourth category was a decision or an oversight.

A new design is fine. A new set of words on the pages that currently rank is a different project, and doing both at once means you'll never know which one caused the change.

For your top 20 pages from step 1, carry across deliberately:

• The body content. Improve it if you like, but don't cut it. Length and specificity are usually why it ranks.
• Titles and H1s. If a page ranks for a term, that term is probably in its title. Keep it there.
• Meta descriptions. Cheap to carry, annoying to rewrite later.
• Internal links. Point them at the new URLs rather than letting them run through the redirects.
• Structured data. Most builders emit some automatically and most custom builds emit none unless you add it. The schema guide covers rebuilding it.
• A self-referencing canonical on every new URL, which Google lists as part of migration preparation.

Change the design, the speed and the platform in this move. Save the content rewrite for a month later, when you have a stable baseline to measure it against.

This is the step most guides get backwards, and getting it backwards means every redirect you carefully wrote does nothing at all.

Think about what actually happens on launch day. You point your domain's DNS at the new host. From that moment, a browser asking for yourdomain.com/old-page is sent to the new host, and the new host answers. The old builder never sees the request. Its redirect manager, however carefully you filled it in, is no longer in the path.

So redirects configured inside Wix or Squarespace are for while that platform is still serving your domain. The moment you leave, they stop mattering. Your redirect map has to be implemented on the new host, and it has to be live the moment DNS switches.

Then the type. Google supports several kinds and treats them differently:

• Permanent, which is what you want: HTTP 301 and 308. These tell Google to show the new URL.
• Temporary, which you don't want here: 302, 303, 307. These tell Google to keep the old URL in results, which is the opposite of a migration.
• Server-side beats the alternatives. Google ranks server-side redirects highest for reliability, and says to use JavaScript redirects only if you can't do server-side or meta refresh, because rendering can fail.

Watch for chains. If A points to B and B points to C, that's a chain, and Google advises keeping them to ideally no more than 3 and fewer than 5. Chains appear on their own when you migrate a site that was migrated before, so test rather than assume.

The nastier version is a loop: A points to B and B points back to A. Nothing resolves, the browser gives up, and the page is unreachable for everyone including Google. Loops are usually created by adding a redirect to fix a 404 without checking what already pointed at the destination, which is exactly what you'll be doing at speed on launch day. A chain is a tax. A loop is an outage, and it won't appear in any list of pages because the page never loads.

Staging sites are built to be hidden from Google, usually with a noindex tag or a blanket Disallow in robots.txt. Shipping that flag to production is the most expensive bug available in a migration, because the site works perfectly for every human who looks at it and is invisible to search.

Google puts this in its own migration documentation, in as many words: don't forget to remove any noindex or robots.txt blocks that were only needed for the migration.

Check it before you celebrate, not after. View source on the new homepage and three inner pages, search for noindex, then open /robots.txt and read it in full. It takes two minutes and it's the difference between a good week and a terrible month.

Then the rest of the launch sequence, in order:

1. Redirects live on the new host and spot-checked. Step 6.
2. DNS switched.
3. Verify every variant in Search Console. Google says to verify www and non-www, and HTTP and HTTPS, for both old and new. Most people do one and think they're covered.
4. Submit the new sitemap. The old one can be removed once the new one is in.
5. Analytics tag present on the new site and firing. Check Realtime with your own visit.
6. Change of Address only if the domain changed. It's for moving between domains or subdomains. If you kept the same domain and only changed platform, it doesn't apply and you haven't missed anything.

Something will move. The job now is telling a normal migration wobble apart from a real problem, and the difference is direction rather than the number on any given day.

What normal looks like. Google says a small to medium site can take a few weeks for most pages to move across. So expect impressions and positions to be unsettled for a fortnight, and expect your indexed page count to drop before it climbs. Panicking on day three and reverting is its own disaster.

Check weekly, not daily, and watch four things:

• 404s in the Pages report. Should spike, then fall steadily. Every one that persists is a URL missing from your map, so add the redirect and move on.
• Indexed page count. Should climb back toward the step 1 number.
• Your top 20 pages. Positions should recover toward the step 1 export. This is why you took it.
• Clicks, but last. Noisiest signal, slowest to settle, and the one that tempts people into changing things too early.

At three weeks, if 404s are flat rather than falling, or your top pages haven't begun reappearing, stop waiting and go looking. That's the point where patience turns into denial.

Leave the redirects alone. Google says to keep them as long as possible and generally at least a year, because other sites linking to you need to be recrawled and reassigned, and that runs on nobody's schedule but theirs.