Website migrations are one of the highest-risk events in a site’s life. Done correctly, they’re invisible to search engines — traffic holds, rankings hold, nothing breaks. Done wrong, you lose months of organic traffic in a few days, and recovering it takes longer than you’d expect.
The problems are all preventable — and they almost always trace back to the same root cause.
Why Migrations Go Wrong
The cause of most migration-related SEO disasters is the same: the technical SEO work is treated as an afterthought, or skipped entirely.
Development teams focus on functionality. Designers focus on the new look. Project managers focus on the launch date. Nobody owns the question of what happens to the 450 URLs that used to exist and no longer do, or the fact that the new CMS generates different URL structures, or that the canonical tags are all pointing to the staging domain.
These aren’t edge cases. They’re the default outcome when SEO isn’t explicitly scoped into the migration project.
The Technical Checklist
Before launch:
Crawl the current site. Use Screaming Frog or a similar crawler to capture every URL, every redirect, every canonical, every internal link, and every piece of metadata on the current site. This is your baseline. You can’t measure what changed if you didn’t measure what existed.
Map redirects for every changed URL. Every URL that exists on the current site and will have a different URL on the new site needs a 301 redirect. Not a 302. Not a meta refresh. A 301. Map these in a spreadsheet before the migration, not after.
Check the new site’s robots.txt. Development and staging environments are almost always configured to block crawlers. That configuration needs to be reversed before launch. You’d be surprised how often it isn’t.
Audit canonicals. Every page on the new site should have a canonical tag pointing to itself (the production URL), not to staging. If your CMS auto-generates canonicals, verify they’re using the right base URL.
Verify internal links. The new site’s internal links should point to new URLs, not to old ones that will redirect. Redirect chains — link → redirect → redirect → destination — dilute link equity. Updating internal links directly is the cleaner solution.
Submit XML sitemaps to Search Console. The new site needs an accurate, up-to-date sitemap submitted to Google Search Console before or immediately after launch.
After launch:
Crawl the new site immediately. Verify that the site is crawlable, that the robots.txt isn’t blocking anything it shouldn’t, that canonicals are correct, and that redirects are resolving correctly.
Check Search Console for coverage errors. New crawl errors, indexing drops, or redirect issues show up in Search Console within days. Monitor it closely for the first two weeks.
Monitor rankings daily for the first month. Don’t wait for a monthly report to find out something went wrong. Set up rank tracking before launch so you have a pre-migration baseline to compare against.
Verify Core Web Vitals. New page templates often have different performance characteristics than old ones. Check LCP, CLS, and INP on the new site after launch.
Domain Changes and HTTPS Migrations
Two specific migration types carry additional risk:
Domain changes (moving from old-domain.com to new-domain.com) are the highest-risk migration type. Domain authority doesn’t fully transfer immediately. Expect a temporary dip in rankings even if the migration is executed perfectly — the question is whether it’s a minor dip that recovers in weeks or a major loss that takes months.
Critical extras for domain migrations: update all backlinks where possible, update all social profiles and directory listings, and set the new domain as the preferred domain in Search Console.
HTTP to HTTPS migrations were high-risk five years ago and are now low-risk if executed correctly — which means making sure every HTTP URL redirects to its HTTPS equivalent, that internal links use HTTPS, that the canonical tags use HTTPS, and that Search Console has the HTTPS property verified.
CMS Migrations
Moving platforms — WordPress to Webflow, Drupal to WordPress, custom CMS to HubSpot — adds complexity because URL structure, metadata handling, and internal linking are all platform-dependent.
The same principles apply, but pay particular attention to:
URL structure changes. If your blog was at /blog/post-title and the new CMS puts it at /articles/post-title, every one of those URLs needs a redirect.
Metadata migration. Titles, meta descriptions, and structured data don’t automatically transfer between platforms. They need to be explicitly migrated, which usually means a combination of export/import and manual cleanup.
Pagination and filtering. E-commerce and blog pagination creates large numbers of indexable URLs. The new platform may handle these differently. Audit and configure before launch.
Hiring a Website Migration SEO Consultant
If you’re planning a significant migration, the right time to bring in an SEO consultant is before the project starts — not after the launch, when the damage has already been done.
What a migration SEO consultant does:
- Pre-migration site audit and URL inventory
- Redirect mapping and review
- Technical SEO specification for the development team
- Pre-launch checklist and sign-off
- Post-launch monitoring and issue resolution
The cost of a migration SEO engagement is a small fraction of the cost of a traffic loss that takes six months to recover.
At Webward, we handle website migrations with SEO built into the process from the start — not bolted on after the fact. Get in touch if you have a migration coming up.