The real risk number most businesses don't know
That number doesn't mean every migration goes badly. It means the average migration — including ones where people tried to do things right — takes over a year to fully recover. The migrations that go well aren't lucky. They're planned.
The businesses that lose the most traffic in a migration share one thing: they treated SEO as an afterthought. The new site launched, the developer handed over the keys, and three weeks later the business owner noticed their phone had stopped ringing. By then the damage is done — you can't retroactively redirect 200 URLs that have already been crawled as 404s.
This post is the brief you hand your developer before they touch anything.
Before the migration: what to do first
The most important SEO work in a migration happens before a single line of code is written. This is where most small businesses skip steps — and where most traffic losses originate.
1. Crawl and export your current site
Before anything changes, you need a complete record of every URL currently on your site — every page, every post, every product, every image that's been indexed. Use Screaming Frog (free up to 500 URLs) or your developer's crawl tool. Export everything: URL, title tag, meta description, H1, word count, inbound links. This is your before-state baseline.
2. Pull your GSC data
In Google Search Console, export your performance data for the last 12 months — clicks, impressions, and average position by page. This tells you which pages are actually driving traffic and rankings. These are your highest-value pages and they need special attention in the migration. A page ranking on page 1 for a competitive term is an asset — treat it like one.
3. Build your redirect map
This is the single most important document in the migration. For every indexed URL on your old site, you need a corresponding destination URL on the new site. The format is simple: old URL → new URL → redirect type (301 for permanent).
Every indexed URL must redirect to a topically equivalent page — not to your homepage. Sending 50 old blog post URLs to your homepage is one of the most common migration mistakes, and it's why so many businesses see immediate traffic drops. Each URL's authority needs to transfer to the most relevant equivalent destination.
4. Document your current title tags and meta descriptions
Your developer will rebuild pages on the new platform. Unless you hand them the existing title tags and meta descriptions, they'll either leave them blank or write new ones from scratch — neither of which is what you want. Export all titles and metas from your crawl and include them in the developer brief.
5. Note your current URL structure
If you can preserve your URL structure on the new platform, do it. Identical URLs mean no redirects needed — the authority signals transfer cleanly. If the new platform forces a different URL structure (common in CMS migrations), document every URL change and make sure your redirect map covers each one.
During the migration: what your developer needs from you
Your developer's job is to build the new site correctly. Your job is to make sure they have everything they need to protect SEO in the process. Most developers are skilled at building — they're not SEO specialists. The brief you provide is what bridges that gap.
Hand your developer a written brief that includes:
- The complete redirect map — every old URL → new URL
- Exported title tags and meta descriptions for every page
- The pages that are currently ranking (from your GSC export) — flag these as priority
- Your current robots.txt and sitemap.xml — for reference
- Schema markup requirements — which pages need which schema types
- GA4 and GSC verification codes — so tracking is set up on launch day, not after
The new site must be built on a staging environment with noindex directives active until launch day. If Google crawls a staging version of your site, you can end up with duplicate content issues that take months to resolve. Confirm with your developer that the staging environment is blocked from indexing before they start.
Before launch day, verify:
- All redirects in the map are implemented and tested — check a sample manually
- No pages returning 404 errors that should be live
- Staging noindex removed — the live site must be indexable on launch
- XML sitemap submitted to GSC on launch day
- GA4 tracking confirmed live — verify events firing before you go public
- GSC verified on the new domain or property if it changed
After launch: the first 30 days
The work isn't done when the site goes live. The first 30 days are when most recoverable problems surface — and when they're easiest to fix.
Week 1
Check GSC daily for crawl errors. A spike in 404s means redirects are missing or broken. Fix them immediately — every day a redirect is missing is a day Google's signals are not transferring to the new URL. Also check that your sitemap has been submitted and is being processed.
Week 2–4
Compare your GSC clicks and impressions against your pre-migration baseline. Some volatility is normal in the first two weeks — Google is re-crawling and re-evaluating the new site. A significant drop (30%+) that doesn't start recovering by week 3 warrants a deeper audit of your redirect implementation.
Month 2–3
Rankings should be stabilizing. Monitor your highest-value pages specifically — the ones you flagged from your GSC export. If specific high-value pages lost rankings, check that their redirects are pointing to the correct destination and that the new page content matches the search intent of the old page.
Some ranking fluctuation after migration is normal and expected. Google needs time to re-crawl, re-evaluate, and re-rank the new site. What's not normal: a 50%+ traffic drop that doesn't start recovering within 60 days. That's a signal of redirect errors, missing content, or indexation problems that need immediate diagnosis.
The four most expensive migration mistakes
Do you actually need to change platforms?
Before committing to a migration, it's worth asking whether the platform change is actually necessary — or whether it's being driven by developer preference or a consultant's recommendation that benefits them more than you.
Platform is not the primary SEO variable. Squarespace, Wix, Webflow, and WordPress can all rank well when configured correctly. The technical SEO fundamentals — correct redirects, clean URLs, proper schema, fast load times — are achievable on all of them. Any consultant pushing you to migrate platforms primarily to improve SEO is overstating the case. The migration itself carries more SEO risk than the platform difference in most situations.
The legitimate reasons to migrate platforms are: your current platform is genuinely limiting a capability you need (e-commerce functionality, custom integrations, content at scale), your site has outgrown the platform's performance envelope, or the development overhead on your current platform is unsustainable. "Better SEO on WordPress" is rarely a sufficient reason on its own.
If you're migrating for legitimate reasons, the checklist above applies regardless of which platforms you're moving between. The SEO work is the same whether you're going Squarespace → WordPress, Wix → Webflow, or custom CMS → anything.
If you want someone to own the SEO side of your migration — building the redirect map, briefing your developer, and monitoring GSC through the recovery period — that's exactly what the SEO Migration Support service covers.