SEO Website Migration: How to Change CMS, Design or Domain Without Losing Traffic

In short: a site loses traffic after migration not because of the CMS or design change itself, but because of lost URLs, missing redirects, a stray noindex and broken internal linking. A safe migration is a pre-launch benchmark, a 301 redirect map, staging checks, a launch-day checklist and monitoring afterwards.

Why do migrations break traffic?

To a search engine a page is a URL with a history: indexing, links, behavioural signals. If an address changes without a redirect, the engine sees a new empty page and an old one that vanished. If a template changes, titles, structure, internal links and speed change too, and signals get re-evaluated. Temporary swings after large changes can happen even with flawless execution, but systemic mistakes lead to long drops.

The most common causes of loss:

• old URLs return 404 or all redirect to the homepage;
• a noindex or Disallow: / from staging stays on production;
• titles, H1s and text of important pages changed;
• pages that brought traffic disappeared;
• broken internal links and redirect chains;
• markup, hreflang and canonicals weren't carried over;
• analytics is broken, so the damage is noticed late.

What kinds of migration exist?

The more changes you bundle into one release, the harder it is to find the cause of a drop. If you can split them (for example CMS first, redesign later), do.

Stage 1. Benchmark before launch

Record the "before" state, because without it you cannot measure losses.

1. A list of all URLs on the old site: crawler plus sitemap plus Search Console pages.
2. Top pages by clicks and impressions over the last 12 months.
3. Rankings for key queries.
4. Organic conversions in GA4: leads, orders.
5. Backlinks: which pages have external links; they must not be lost.
6. Metadata and markup of old pages: title, description, H1, JSON-LD.
7. Speed of key templates (Core Web Vitals), so the new site isn't slower.

Stage 2. The 301 redirect map

This is the most important part of a migration. For every old URL that had traffic, links or rankings, decide the new address.

Rules:

• the target must be the closest match in meaning, not "everything to the homepage";
• one redirect hop, no A → B → C chains;
• don't use 302 for a permanent move;
• keep redirects for at least a year, longer if strong external links exist;
• if no relevant page exists, returning 404 or 410 is better than redirecting to an irrelevant one.

Apache example:

RewriteEngine On
RewriteRule ^old/service-seo/?$ /en/services/seo [R=301,L]

nginx example:

location = /old/service-seo {
    return 301 /en/services/seo;
}

For large maps use map in nginx or a redirects table in the CMS (in Laravel, middleware backed by a database table).

Stage 3. Staging: verification before launch

Develop on a test domain closed to indexing (authentication or noindex; robots.txt alone doesn't guarantee pages stay out of the index). Check:

• 301s work for the whole map, with no chains;
• title, description, H1, canonical and hreflang are in place;
• JSON-LD wasn't lost;
• internal links point to new addresses directly, not via redirects;
• the sitemap contains only new canonical URLs;
• speed and Core Web Vitals are no worse than on the old site;
• forms, goals and GA4 events work.

Stage 4. Launch: the day-X checklist

1. Remove the noindex and relax the robots.txt blocking used on staging.
2. Enable the 301 redirects.
3. Submit the new sitemap in Search Console.
4. Verify canonical, hreflang and markup on the live domain.
5. Confirm analytics and lead tracking work.
6. For a domain change, use the Change of Address tool in Search Console and add both properties.
7. Manually check 10–20 key URLs: status, redirect, content.
8. Crawl the new site and look for 404s and chains.

Launch on a weekday during low traffic, when a developer is available for quick fixes.

Stage 5. After launch: monitor for 2–4 weeks

• Search Console: the Pages report (indexing, new errors), Performance (impressions and clicks versus the benchmark), crawl stats.
• Server logs: whether Googlebot crawls new URLs and hits 404s.
• GA4: organic traffic and conversions by page group.
• Rankings for key queries.

A temporary dip is possible. Warning signs: mass 404s, growth in "Discovered – currently not indexed", top pages dropping out of results, conversions falling while traffic doesn't (form problems).

MODX, WordPress and Laravel specifics

• From MODX: keep resource aliases or build a counterpart for every resource. Export content, TV fields and metadata before migrating.
• From WordPress: keep the permalink structure or prepare a map; don't forget tag pages, archives and attachment pages that may have links.
• To Laravel: routes replace the file structure, so redirects, sitemap and canonicals must be implemented explicitly. A database redirects table with an admin screen is easy to maintain.

Common mistakes

• No benchmark, so nobody knows what "before" looked like.
• Redirects only for main pages.
• All old URLs redirect to the homepage.
• Staging open to indexing while production keeps a noindex.
• URLs, content, structure and domain all changed at once.
• Forgotten images, PDFs and other files with links.
• hreflang not carried over on a multilingual site.

FAQ

How long does traffic take to recover after a migration?

It depends on the scale of changes, redirect quality and site size. For small, well-executed migrations it is typically weeks; for large sites, longer. Timelines can't be guaranteed.

Do you need redirects for a simple redesign?

If URLs don't change, no. But verify that templates didn't alter titles, H1s, canonicals and internal links.

Can you migrate without changing URLs?

Yes, and it is the safest option. Keep addresses unless there is a strong reason to change them.

When can old redirects be removed?

Not earlier than a year, and only when old URLs have no external links or traffic.

Do you need the Change of Address tool?

Only for a domain change. For other migrations redirects and a new sitemap are enough.

Planning a CMS or design change? Request a free Kyivan audit — a developer will build the redirect map, verify staging and prepare a launch checklist.