Preserving SEO During a Website Migration

Treat URLs as permanent identifiers

A URL is not an implementation detail of the current CMS. It is the public name of a resource, cited in other people's pages, bookmarks, emails and reading lists. The default position in any migration is therefore that no URL changes. Where a change is genuinely unavoidable — a platform that cannot reproduce a path pattern, a taxonomy that must be restructured — the old address gets a permanent 301 redirect to its closest specific equivalent.

Two habits do most of the damage. The first is redirecting anything unmatched to the homepage, which search engines treat as a soft 404 and which destroys the accumulated value of each redirected page. The second is chaining: an old URL redirecting to a second old URL redirecting to the new one. Collapse every chain to a single hop before launch and re-test after.

Build the redirect map from a crawl of the live site, not from the sitemap. Sitemaps describe what the CMS believes exists; a crawl plus server logs describe what the world actually requests, including the ten-year-old PDF that still receives referral traffic.

Carry metadata across, do not regenerate it

Titles and meta descriptions written by an editor over several years encode judgement that no template can reproduce. Export them, import them, and diff the result. A migration that regenerates titles from a pattern will look consistent and read worse, and the click-through decline shows up weeks later when nobody is still watching.

The same applies to canonical tags, robots directives, Open Graph and Twitter Card values, language attributes and hreflang relationships. Each is a small signal, and their absence is rarely visible in a page-by-page visual review, which is exactly why it survives quality assurance.

Publication and modification dates deserve particular care. Importing an archive with today's date tells search engines that a decade of material was published simultaneously, which flattens topical history and can suppress older but authoritative pages.

Keep structured data and internal links intact

Structured data is how a page explains itself to machines: what kind of thing it is, who wrote it, when, and where it sits in the site hierarchy. Article, BreadcrumbList, FAQPage and Organization markup should be emitted from real content fields in the new system rather than pasted into a template, so that it stays correct as content changes.

Internal linking is the other half. Anchor text distribution, hub pages and cross-references shape how crawlers understand topical relationships. A migration that flattens navigation or drops in-content links removes signals that took years to build. Reproduce the link graph first; improve it in a second, measurable phase.

Finally, verify at scale rather than by sampling. Crawl staging, compare the URL inventory against the reference crawl, diff every title and description, validate structured data across templates, and only then consider launch.

The two weeks after launch

Most recoverable migration damage is visible within fourteen days. Watch server logs for 404 patterns daily, monitor index coverage, resubmit the sitemap, and check that the redirect map is being followed rather than intercepted by a caching layer or a security plugin.

Keep the previous platform accessible in read-only form for at least a month. When a missing asset surfaces, having the original available turns an archaeology project into a file copy.