A CMS migration, such as moving from WordPress to Shopify, Webflow or a headless front end, keeps your rankings when three things survive the move: the URLs, or a one-hop 301 from each old URL to its new one; the on-page signals, such as titles, descriptions, headings, internal links and structured data; and a site Google can render and index from launch day. Platforms differ most in the URLs they allow and in what their import tools leave behind. This guide is for site owners and the people building the new site: it shows how to plan a platform change template by template, where each platform forces URL changes, and how to verify the result. For migrations in general, including domain and https moves, start with the website migration guide.
Quick answer
- Keep every URL the new platform lets you keep. Slugs are usually free; fixed prefixes such as Shopify's
/products/are not. - Map every URL that must change to its closest new equivalent, and redirect it in one 301 hop on launch day.
- Inventory the SEO fields before you export: titles, meta descriptions, canonicals,
noindexsettings, hreflang, alt text and structured data often live in plugins that import tools skip. - Compare templates, not just pages. Check one product, one category, one article and one landing page on staging against the live site.
- Make sure the new site renders on the server, or that content and links appear in the HTML without JavaScript.
- Verify on staging, on launch day and a week later with every old URL, using the migration redirect validator.
Why a platform change is riskier than it looks
A new CMS looks like a design project, so SEO is often checked last. But a platform decides the things search engines read: the URL pattern, the HTML each template outputs, what goes in the <head>, how pagination and filters work, and whether content is in the HTML or appears only after JavaScript runs. When those change, Google has to re-learn the site.
The losses after a CMS migration usually come from four gaps:
- URLs changed without a redirect, because the new platform uses different prefixes or slugs and nobody mapped them.
- SEO fields left behind. Custom titles and meta descriptions written in a WordPress SEO plugin are stored in plugin fields, not in the post content, so a content import brings the text but not the metadata.
- Thinner templates. Category pages without their intro text, products without their FAQ block, articles without author or date, lost breadcrumbs and related links.
- Missing structured data. Product, breadcrumb, article and organization markup that a plugin produced on the old site and nothing produces on the new one.
All four are visible on staging if you look before launch.
Step 1: inventory what the old site has
Export more than the content. For every indexable URL, record:
| Field | Where it usually lives on the old site |
|---|---|
| URL | Sitemap, crawl, analytics landing pages, Search Console pages with impressions |
| Title tag and meta description | SEO plugin fields, not the page body |
| H1 and main headings | Page content or template |
Canonical and noindex settings | SEO plugin or template |
| hreflang | Multilingual plugin or template |
| Structured data types | SEO or schema plugin, theme |
| Image alt text | Media library |
| Internal links in navigation, footer, breadcrumbs | Theme menus and widgets |
| Existing redirects | Redirect plugin, .htaccess, CDN |
A crawl with an SEO crawler gives you most of this in one export. For the pages that matter most, the full getReport report gives a snapshot you can compare later, with titles, descriptions, headings, canonical, structured data and speed per page. The before-and-after measurement guide shows how to choose those key pages and what baseline to record.
Do not forget the existing redirects. Rules from earlier relaunches, in a WordPress redirect plugin or .htaccess, disappear with the old platform unless you carry them across, and old links from other sites start answering 404 again.
Step 2: keep URLs where the platform allows
Every platform lets you set the last part of a URL, the slug. Where they differ is the path in front of it:
| Platform | Typical URL patterns you cannot change freely |
|---|---|
| Shopify | /products/{handle}, /collections/{handle}, /pages/{handle}, /blogs/{blog}/{article} |
| Webflow | CMS items at /{collection}/{item}; static pages can be nested in folders |
| Wix | Blog posts under /post/, store products under /product-page/ by default |
| WordPress | Almost anything, set by permalinks and custom post types |
| Headless or custom | Anything the developer builds |
Moving from WordPress to Shopify therefore changes every product and category URL, even when every slug stays the same: /shop/red-runner/ becomes /products/red-runner. Moving from Shopify to WordPress with WooCommerce, the reverse is true, and you can often recreate Shopify's paths exactly with WooCommerce's permalink settings.
Rules of thumb:
- Keep slugs identical wherever you can, including the trailing slash convention. It makes mapping mechanical.
- Keep static pages at the same paths. About, contact, services and landing pages can almost always keep their URLs.
- Do not change URLs for tidiness. A shorter slug is not worth a redirect and weeks of recrawling.
- Check how the new platform handles the trailing slash and letter case, and pick the form it serves as canonical.
Step 3: map and redirect the URLs that change
Every old URL that has traffic, links or rankings needs a one-hop 301 to its closest equivalent: product to product, category to category, article to article. Build the list as a two-column spreadsheet, old and new. When slugs stayed the same, most rows can be matched automatically by slug, and only the leftovers need a human.
The redirect mapping guide walks through collecting the old URLs, matching them, handling pages with no equivalent and testing the map. The generator turns the finished list into rules:
Where the redirects live depends on the new platform:
- Shopify has URL redirects in the admin (under Content → Menus → URL redirects in current versions) with CSV import. Shopify only applies a redirect when nothing exists at the old path, and its redirects are permanent 301s.
- Webflow has 301 redirects under Site settings → Publishing, including patterns with capture groups for whole folders.
- WordPress uses a redirect plugin or server rules; see WordPress redirects.
- Headless and custom sites can redirect at the host or CDN, such as Netlify, Vercel or Cloudflare, before the app loads, which is the fastest option on any platform.
Check whether the platform limits the number of redirects or how query strings are matched. Old URLs such as /index.php?id=12 need rules that match the query string, which not every redirect tool supports; a CDN rule usually can.
Step 4: carry the on-page signals across
Go through the new site one template at a time, on staging, and compare it with the old live page of the same type:
- Title and meta description. Custom values moved into the new platform's SEO fields, not replaced by a default pattern such as "Product name – Store name" everywhere.
- Headings. One
h1per page with the same wording, and the same subheadings on long pages. - Body content. The same text, including category intros, product descriptions, FAQ blocks and specifications. Import tools often drop anything that lived in a page builder's shortcodes or custom fields.
- Images. The same images with their alt text, at sensible sizes.
- Internal links. Navigation, breadcrumbs, related products and in-text links pointing at the new URLs, not at old ones that now redirect.
- Canonical tags pointing at each page's own new URL, and
noindexonly where you intend it. - hreflang for multilingual sites, with every language version on its new URL.
- Structured data. The same types as before: Product with price and availability, BreadcrumbList, Article, Organization. Run the schema validator on each template.
Then run the full getReport report on each staging template. These findings catch most of what gets lost:
Step 5: check that the new platform renders for Google
Hosted platforms such as Shopify and Webflow send content in the HTML. Headless setups and JavaScript frameworks may not: if the product text and links appear only after scripts run, Google has to render the page to see them, and other crawlers, including link previews and many AI crawlers, may never see them. Make sure the framework renders pages on the server or at build time. getReport measures how much of the visible text needs JavaScript:
The JavaScript SEO guide explains server rendering, static generation and what to ask your developer.
Step 6: launch and verify
On launch day, switch DNS or the platform, publish the redirects at the same moment, remove any staging password or noindex, and submit the new XML sitemap in Search Console. The Search Console property stays the same when the domain does not change.
Then run every old URL through the validator:
Paste the redirect map, up to 1,000 pairs per run. Each old URL is requested and followed hop by hop, and every pair gets a verdict: correct, wrong target, not redirected or gone, chain, temporary redirect, or a target that is broken or set to noindex. Run it on staging before launch if the redirects can be tested there, on launch day, and a week later when caches have caught up.
In the following weeks, watch Search Console's Page indexing report for rising "Not found (404)" counts, check the 404 log of your new platform or server for old URLs you missed, and compare your key pages against the baseline. The site migration checklist has every launch-day and after-launch task in order. If you are also changing the domain, read changing domain name without losing SEO as well.
Platform notes
WordPress to Shopify. Products and collections move to /products/ and /collections/, so every shop URL changes. Blog posts move under /blogs/news/ or another blog handle. Shopify's theme outputs Product structured data in most themes; check yours. Filter and sort URLs change completely; do not try to redirect every filter combination, only the category pages. What you can and cannot fix on Shopify lists the platform's SEO limits.
WordPress to Webflow. Blog posts become CMS items under a collection path such as /blog/{slug}, so a WordPress blog that used /{slug}/ at the root needs redirects for every post, which Webflow's pattern redirects can cover in one rule only if the old URLs share a folder. The Webflow SEO settings guide covers titles, sitemaps and canonicals there.
Any CMS to headless. You control the URLs completely, so keep them all. The risks move to rendering, the <head> output of each route, and redirects, which now have to be configured at the host.
Common mistakes
- Importing content and assuming metadata came with it. Check titles and descriptions on staging, page by page for key pages.
- Letting the new platform's defaults write every title. A pattern is fine as a fallback, not as a replacement for pages that ranked.
- Dropping old redirects from the previous platform. Carry them across and point them at the final new URLs.
- Redirecting everything to the new home page because mapping was too much work.
- Launching with staging protection on, a
noindexor aDisallow: /. Check within the hour. - Changing design, content and URLs in one launch with no baseline, so nobody can say which change caused a drop.
Questions people ask
Will changing my CMS affect my SEO?
It can, in either direction. If URLs stay the same or redirect in one hop, and titles, content, internal links and structured data come across, rankings usually settle within a few weeks. Traffic drops when old URLs answer 404, metadata is lost in the import, templates get thinner, or the new site depends on JavaScript to show content.
Do I need redirects if my slugs stay the same on the new platform?
Only if the full URL changes. A slug that stays red-runner but moves from /shop/red-runner/ to /products/red-runner is a new URL, so it needs a 301. If the path, slug and trailing slash are identical, no redirect is needed. Compare full URLs in your map, not just slugs.
How do I move SEO titles and descriptions from WordPress to another CMS?
Export them separately. SEO plugins such as Yoast SEO and Rank Math store titles and descriptions in their own fields, which standard content exports and many import apps skip. Crawl the old site to export each URL's title and description, then import them into the new platform's SEO fields, or check key pages by hand on staging.