How to Migrate a Company Website Without Losing SEO

How to Migrate a Company Website Without Losing SEO

Most migrations that lose traffic fail the same way. The new site looks better, but somewhere in the move a few hundred URLs changed, titles were rewritten, structured data disappeared or redirects pointed at a 404. Google and AI assistants treat the new site as a stranger, and it takes months to recover.

The fix isn’t a better tool. It is a method: write down exactly what the old site says to search engines, rebuild it, and prove the new site says the same thing before you switch.

This guide walks through that method. The worked example is our own site, allsite.pro: 225 URLs, a CMS with seven collections, six interactive tools and a set of password-protected client pages, moving from Framer to a custom-code stack. At the time of writing the new build runs on a preview, and the live domain switches only when every check below is green.

First, why move at all: the right stack per stage

We build most client marketing sites in Framer, and we still recommend it for most B2B companies at seed to Series B. Our own site is moving for reasons that are specific to what it has become:

• Interactive tools. The site now runs six tools (an AEO scanner, a stack comparison, a pricing estimator and others) that behave more like small applications than pages.
• Server-side logic. Client proposals sit behind a password. In a visual builder, that check ran in the browser; we wanted it on the server.
• Own form handling. Every form, from project requests to tool results, now goes through one function we control.

None of these is a criticism of the old platform. They are the signals we describe in Framer vs Webflow vs custom code: when a site starts to become part of the product, the right stack changes. A migration is a normal step as a company grows. The risk is in how you do it.

Step 1: Crawl a baseline of every URL

Before changing anything, record what the current site says to search engines. We crawled all 225 URLs in the sitemap and stored, for each one:

• status code and redirect chain
• title, meta description, canonical and robots meta
• H1s and the H1–H3 outline
• Open Graph and Twitter tags
• structured data (JSON-LD), parsed
• internal links and images with alt text

We also saved robots.txt, llms.txt and the host rules: apex to www, http to https, no trailing slash (/insights/ redirects to /insights), and case-sensitive paths.

This baseline is the contract. Every later step is measured against it.

What the baseline usually reveals: problems on the live site you didn’t know about. Ours had two sitemap URLs that redirected, test pages listed in the sitemap, a page with two identical H1s, FAQ pages with an unrendered structured-data template and a broken internal link. Decide for each one whether to keep it as-is for parity or fix it, and write the decision down.

Step 2: Inventory everything the old platform does for you

Hosted platforms do quiet work that a new stack has to replace. List it:

• Redirects. Export the full list from the old platform’s settings, not just the ones you remember. We carried over 84 rules.
• Content. Export every CMS item, including drafts, with slugs unchanged. We exported 341 items and self-hosted 587 media files, named so each maps back to its original URL.
• Forms, scripts and embeds. Analytics, consent, scheduling links, tag scripts.
• Generated files. Sitemap, robots.txt, llms.txt, favicons, social images.

Anything missing from this list will be missing after launch.

Step 3: Rebuild with identical URLs and metadata

The rule for the rebuild is simple: same URL, same title, same description, same canonical, same H1, same structured data. Use the content export as the source, with file names equal to slugs, so a URL can’t drift.

Two practical points:

• Match the host rules exactly. Trailing slashes, case sensitivity and www handling all create duplicate or broken URLs if they differ.
• Write redirects deliberately. We use 301s. Where an old redirect ended on a 404, we pointed it at a live page instead. That is one of the few changes we allowed, because it fixes a dead end without changing any page that ranks.

Resist the urge to improve while you migrate. A sharper H1 or a new title might be better, but if rankings move after launch you won’t know whether the platform or the copy caused it.

Step 4: Test parity automatically, before launch

Checking 225 URLs by hand is unreliable. We wrote a parity test that crawls the new build with the same script as the baseline and compares every URL on:

• status and redirects
• title, description, canonical, robots
• Open Graph and Twitter tags
• H1
• structured data

Intended differences are listed explicitly, for example self-hosted image URLs and the fixed FAQ structured data. Everything else must match. The test exits with an error on any difference, so it can’t be ignored.

Launch only when it is green, against a build served exactly like production.

Step 5: Cut over and watch Search Console

On launch day:

1. Switch DNS and confirm the host rules and redirects on the live domain.
2. Resubmit the sitemap in Google Search Console. A Domain property verified by DNS survives the host change.
3. Request indexing for the homepage, the main hubs and one page of each template.

For the next one to two weeks, check daily:

• Pages report: new “Not found (404)”, “Page with redirect” or “Duplicate without user-selected canonical” entries. Fix every 404 with a redirect.
• Sitemap: still read successfully, with the same number of discovered pages.
• Performance: clicks and impressions compared with the two weeks before launch.

Step 6: Improve one change at a time

Once traffic is stable, the migration is done and optimisation starts. Change headings, titles and page structure one at a time, with a note of the date, so each ranking move can be traced to a cause. Content consolidation, such as merging overlapping articles with 301s, also belongs after launch, not in the cutover.

A migration checklist

• Baseline crawl of every URL, including status, metadata, headings and structured data
• Known issues on the live site listed, each marked keep or fix
• Full redirect export from the old platform
• Content export with slugs unchanged, media mapped
• Forms, scripts, sitemap, robots.txt and llms.txt replaced
• Host rules matched (www, https, trailing slash, case)
• Automated parity test green against a production-like build
• Search Console: sitemap resubmitted, key pages requested, daily checks for two weeks
• Improvements scheduled after launch, one at a time

We run the same method on client migrations, from WordPress, Webflow, AI builders or custom code to Framer, and from Framer to code where a company has outgrown it. See website migration or request a project to talk through yours.

Related reading

• Framer vs Webflow vs custom code
• Migrating from WordPress to Framer
• Preserving SEO when migrating from Webflow

Allsite is a Berlin design and development studio for funded tech companies: positioning, brand and websites, with migrations that keep content and rankings intact.