How to Migrate Your Med Spa Website Without Losing Bookings

Migrating a med spa website is one of the most damaging things you can do to your business if done wrong. We've seen clinics lose 30–60% of their organic bookings for 2–3 months after a sloppy migration — bookings that often never fully recover. Done right, you migrate with zero loss and a permanent upgrade. Here's the 7-step process.

Why most migrations lose bookings

Most agencies treat a migration as "build new site, point the domain." That's the move that costs you 30% of bookings. Three things go wrong:

• Old URLs (the pages Google has indexed for years) aren't mapped to new URLs, so visitors and search engines hit 404s.
• Schema markup, sitemaps, and meta data don't transfer — Google sees a "new" site without the trust signals the old one had built up.
• Booking integrations, forms, or pixels break on launch day and nobody notices for a week.

Each of those is preventable with planning. The process below prevents all three.

Step 1: Audit the current site

Before you change a thing, document what you have. Pull:

• A full list of every indexed URL (use Screaming Frog free up to 500 URLs, or pull from Google Search Console → Coverage report).
• Top 20 organic pages by traffic from GA4 / Search Console — these are the pages that MUST keep their URLs and content intact.
• Current rankings for your top 20 target keywords (use a free rank checker like Free Keyword Rank Checker or just google them yourself).
• All forms, booking integrations, and tracking pixels currently installed.
• Anything embedded from external services (Cal.com, Acuity, Square, Google Maps, Vimeo, etc.).

This baseline is what you'll measure against after launch. Without it, you can't tell if you broke something.

Step 2: Map old URLs → new URLs

This is the single most important step. Every URL Google has indexed must either: (a) keep the same path on the new site, or (b) have a 301 redirect from the old path to the new path. No exceptions.

Create a simple spreadsheet:

• Column A: Old URL (e.g., yourclinic.com/services/botox-treatment)
• Column B: New URL (e.g., yourclinic.com/treatments/botox)
• Column C: Action — "Keep same", "301 redirect", or "Delete + 410" (only for truly dead pages)
• Column D: Status — implement / verify after launch

Pro tip: keep your URL structure as close to the original as possible. Every URL change is a redirect to implement and a small ranking risk. Only restructure URLs when there's a real reason (e.g., consolidating duplicate pages).

Step 3: Stage the new site

Build the new site on a staging URL — never on the production domain. Common staging setups:

• A subdomain like staging.yourclinic.com (block from indexing with `noindex` and password-protect with HTTP auth)
• A platform-provided preview URL (Squarespace gives you a working preview before you publish; WordPress has staging environments on most managed hosts)
• A separate domain like yourclinic-new.com (block from indexing — this is critical so Google doesn't accidentally index the staging site)

The new site must be 100% complete on staging before you point the domain. "We'll finish it after launch" is how migrations break.

Step 4: Migrate content correctly

When migrating content, preserve everything Google was using to rank you:

• Page titles (the <title> tag) — keep the same text unless deliberately optimizing
• Meta descriptions — keep the same unless deliberately rewriting
• H1, H2, H3 structure — preserve the on-page hierarchy that Google understood
• Image alt text — migrate every alt attribute, not just the images
• Internal links — every link from page A to page B should still work after migration
• Schema markup — re-implement on the new site, ideally improved
• URL slugs — keep them unless there's a strong reason to change

Don't "refresh" content during migration. Doing a redesign AND a content rewrite simultaneously means if rankings drop, you don't know which change caused it. Migrate cleanly, then optimize content over the next 3 months.

Step 5: Test before launch

Run this checklist against the staging site BEFORE launch:

• Every page in the old sitemap exists or has a redirect mapped
• Mobile responsiveness on actual phones (not just Chrome DevTools)
• Booking integration works end-to-end — submit a test booking
• Contact form submits and you receive the email
• All tracking pixels fire (Google Analytics, Meta Pixel, Google Ads conversion)
• Page speed scores 80+ on mobile via PageSpeed Insights
• All images load — no broken image links
• No mixed-content warnings (HTTP resources on HTTPS pages)

Have someone outside the project test the booking flow on their actual phone. Fresh eyes catch what you've been staring at for weeks.

Step 6: Launch day execution

Pick a low-traffic day to launch — typically a Tuesday morning. Avoid Mondays (queue catch-up), Fridays (worst time to find a fire), and right before a marketing campaign. Your launch-day checklist:

1. Implement all 301 redirects on the new site (or at the DNS / CDN layer)
2. Point DNS A records (or CNAMEs) from old hosting to new hosting
3. Wait 1–4 hours for DNS propagation
4. Verify HTTPS works on the new domain (force-renew SSL if needed)
5. Submit the new sitemap to Google Search Console immediately
6. Submit the new sitemap to Bing Webmaster Tools
7. Click through every redirect from the URL map and verify the 301 returns the right destination
8. Test booking + contact form on production one more time
9. Watch GA4 real-time view for the first hour — make sure traffic is flowing and pages aren't 404'ing

Step 7: Monitor for 30 days

Migration isn't done at launch. It's done 30 days later when rankings are stable. During those 30 days:

• Check Search Console daily for new 404 errors. Fix immediately with redirects.
• Watch your top-20 keyword rankings weekly. Small dips (1-3 positions) are normal; big drops (5+ positions) need investigation.
• Monitor GA4 organic traffic vs. the pre-migration baseline. Expect a temporary dip of 5–15% in week 1–2 — anything bigger is a red flag.
• Re-verify Google Business Profile points to the new URL.
• Check that all backlinks pointing to the old site still resolve via 301s (they should, if your redirects are right).

Platform-specific migration paths

Common paths and their specific gotchas:

• WordPress → WordPress (replatform or redesign): cleanest path. Export content via WP CLI or All-in-One WP Migration plugin. Watch for hardcoded URLs in widgets and theme settings.
• Squarespace → WordPress: medium complexity. Export to XML via Squarespace settings, import to WP via standard importer. Page slugs sometimes change — verify URL map carefully.
• Wix → anything: hardest. Wix doesn't offer clean exports. Plan to manually rebuild content. Budget extra time for URL mapping.
• Custom HTML → modern platform: usually a content rebuild. The URL structure can usually be preserved with rewrites, but content layout typically needs reworking.
• GoHighLevel → WordPress / Squarespace: usually straightforward — GHL is rarely loaded with deep SEO assets, so the migration is mostly visual/structural.

If you're considering a migration and want a second opinion on the URL map, redirect strategy, or platform choice — that's a good fit for the free 5-min audit. Send your current site and target platform, and Sohaib will record a Loom flagging the specific risks.