Website Migration: Reduce SEO Risk When Changing Platforms

A website migration can reduce avoidable search losses by preserving useful content and mapping changed URLs before launch. It cannot guarantee unchanged rankings. Inventory the old site, agree the destination of each URL, build on a protected preview, test permanent redirects and inspect canonicals, internal links and sitemaps. After launch, monitor the pages that mattered before the move.

Google's site-move guidance describes this preparation and warns that temporary ranking fluctuations can occur. The six-week schedule below is a working project example, not a Google recovery deadline.

The launch decision depends on the evidence being ready, not on reaching a date in the schedule.

Key Takeaways

• Inventory URLs independently of the platform export.
• Give each moved URL one appropriate redirect destination.
• Test content, redirects, canonicals, forms and analytics before and after launch.
• Monitor beyond the cutover; no workflow guarantees unchanged rankings.

Jump to platform exports, the URL map, redirect testing, cutover or the checklist.

Why migrations lose rankings

Redirect errors, unintended content changes and missing monitoring create avoidable migration risk. They are not the only reasons rankings change: recrawling, competition and wider search changes can also affect results. Start with the factors the team can inspect.

URLs that go nowhere. If a retained page moves without a suitable redirect, old links can fail and search systems must discover the change without that signal. Inspect all URL patterns, including posts and assets. A missing redirect does not imply a fixed timetable or amount of ranking loss.

Unintended changes. A rebuild can alter titles, useful content, canonical URLs or structured data. Preserve the intended meaning and update destination-specific references. An intentional rewrite may be valid; record it separately so a migration problem is easier to investigate.

No monitoring owner. Assign someone to check crawl errors, indexing, key pages and real user tasks after cutover. Google's guidance describes variable processing time. Monitoring can expose repairable problems, but cannot promise a cheap fix or fixed recovery period.

Every step below exists to close one of those three.

What each platform lets you take with you

The export is the step that changes by platform. Treat the table as an inventory checklist: request a sample export from the actual account before scoping the rebuild. Plans, plugins and site features affect what survives.

The export is an input to the migration. Framer's HTML-export help page and data-portability page give conflicting descriptions, so do not promise either a complete editable export or a mandatory total rebuild without testing. Squarespace documents a partial WordPress XML export. Wix separately explains that its hosted site cannot be exported for external hosting and Wix Blog has no built-in export to other platforms. Those limits do not establish the export behavior of every other Wix product. In every case, keep a URL inventory independent of what the exporter happens to include.

Week 0: the inventory and the map

Inventory live URLs with available traffic, search evidence and an explicit destination decision. Use a period that reflects seasonality and data retention. Each redirected URL needs one appropriate destination. If a long page splits into several, choose the most relevant successor or a useful overview and link onward; a single HTTP redirect cannot send visitors to several pages. Several old pages may consolidate into one when it satisfies their intent. Deliberately removed content without a replacement may return an appropriate 404 or 410 rather than an irrelevant redirect.

Then compare a crawl with the available analytics, sitemap and other URL records. It can identify linked pages absent from the analytics inventory, such as paginated archives, tag pages, image attachment pages or PDFs. A crawl alone can miss unlinked URLs, so reconcile the sources rather than treating one export as complete.

These are illustrative decisions. The actual map needs evidence that each destination satisfies the old page's purpose.

The map is agreed in writing with whoever owns the site before a line of the new one is built. It is also where the price of a migration comes from: our Website Migration is from $6,000 flat for a site of up to twenty pages, and the inventory is what tells you whether you have twenty pages or a hundred and twenty.

Week 1: the build, on a preview URL

The new site is built on its own account, in its own repository, on a preview URL that is not indexed. For us that is Next.js on the client's Vercel or Cloudflare account. Content comes out of the builder through the export or, for Wix and Squarespace's uncovered pages, by hand from the live site, and lands in files or a headless CMS depending on how often the team edits.

Two rules during the build. Every retained page on the map gets built, including the ones that seem minor. Preserve useful titles, descriptions and content while updating canonicals, social URLs and structured-data URLs to the correct destination. Copying an old canonical unchanged onto a new URL can undo the migration. Keep discretionary content improvements separate so problems are easier to diagnose.

Week 2: the redirects, written and tested

Use permanent server-side redirects, such as 301 or 308, for moved pages with appropriate replacements. Google's guidance recommends retaining them for as long as possible, generally at least a year. Keeping rules in version control helps preserve the intended mapping, but a new host or routing system can still ignore them. Retest after any hosting or configuration change.

Testing is a script as well as a click-through. For changed URLs, check a direct permanent redirect to the mapped destination, without chains or loops. Retained URLs should still load; deliberately removed URLs should return their intended status. Check image URLs, the sitemap and robots rules separately. Run the checks again on cutover day against the live domain.

Cutover: from staging, never live

The person who owns the site clicks through the preview and signs off. DNS moves. The old sitemap is replaced by the new one in Search Console, and if the domain changed, the Change of Address tool is used; Google notes it applies only to domain moves, not to path changes on the same domain. The old builder stays alive and paid for one more billing cycle, so that anything missed can be recovered from the source rather than from memory.

Run the redirect checks against the live domain immediately after cutover, then verify analytics, tag-manager events and forms separately. On this site, the form smoke script submits test data and checks the visible success state. It does not confirm inbox delivery. A complete form check also needs a person to verify that the labeled submission reached the intended inbox or CRM, with the expected fields. Record both results; a success panel alone does not prove delivery.

Weeks 3 to 6: watching, and fixing what moved

During this example monitoring period, inspect indexing reports, sitemap processing, crawl errors and the pages that mattered before the move. Compare search performance over suitable mature periods and account for seasonality. Google's guidance allows temporary fluctuations and variable processing times; two weeks is not a universal failure cutoff. Investigate material changes promptly without assuming their cause from duration alone.

Start with the controllable failures above: missing redirects, changed content and mistaken consolidation. Also check crawl access, canonical selection, rendering and analytics. A ranking change alone does not prove a migration defect; seasonality, competitors and search updates can affect the same period.

The receipt

2Wheel Epix is a mountain-bike tour operator whose WordPress site we redesigned and migrated. That project moved into a builder rather than out of one. The relevant lesson is the same: treat URL mapping, content and launch checks as part of the build. This article does not include a query-level before-and-after dataset, so we do not use the project to promise a numerical ranking outcome.

This site uses Next.js on Cloudflare with code-managed redirects. Those implementation choices do not prove ranking preservation for another migration; the launch plan still needs its own verified URL map and acceptance checks.

What a migration costs

Three honest answers, depending on where you are going.

Between WordPress hosts: check whether the selected plan includes migration assistance and which sites qualify. Plugin, server and domain differences can still require work even when the content remains in WordPress.

To another builder: quote from the actual export, page templates, integrations and redirect requirements. A content export may save re-entry without preserving the design or behavior. Run the inventory and redirect map before accepting a fixed price.

To code, run as above: our Website Migration is from $6,000 flat for a site of up to twenty pages including posts, about two weeks to cutover and four weeks of watching after, with the URL map agreed in writing before anything moves, the site delivered on your own Vercel or Cloudflare account in your own repository, and larger sites quoted from the inventory before day one. Afterwards the Website Care Plan at $1,500 a month keeps it hosted at cost, edited within two business days, updated, and monitored, which is also where the daily Search Console habit lives for a team that does not want to run it.

Even a one-page rebuild needs a check for old links, forms, analytics and integrations. A site without search traffic can still have important bookmarked URLs or partner links. Scale the migration work to those dependencies rather than skipping it because the site is small.

The checklist

1. Every live URL in a sheet with traffic, queries, and a destination. Crawl for the ones analytics forgot.
2. The map agreed in writing. The number comes from the map.
3. Build on a preview URL, on your own account, in your own repository.
4. Preserve useful metadata and content; update canonical and structured-data URLs to the intended destinations.
5. A permanent redirect for each moved URL, tested by script, kept for at least a year.
6. Cut over from staging. Keep the old platform alive one more cycle.
7. New sitemap submitted, Change of Address if the domain changed, and form success states and destination delivery both verified.
8. During this example's four-week monitoring period, inspect Search Console and key user tasks regularly. Investigate material changes and extend monitoring when the evidence requires it.

The cutover ends one phase. Keep monitoring against the agreed baseline and investigate material changes with both technical and search evidence.