By Mehdi HassanWhat is a multilingual website migration?
A multilingual website migration is a platform move where the site serves two or more languages, so every page exists several times and each copy has its own URL, metadata and rankings. You aren't migrating one site. You're migrating one site per locale, plus the links that tell search engines how those versions relate.
That's why multilingual moves go wrong more often than single-language ones. A redirect map that's complete for English can still miss hundreds of German or Spanish URLs, and a missing hreflang return tag can make search engines ignore those annotations. The good news is that the work is predictable. It's the same five decisions every time, and this hub walks through them in order.
Each section links to a deeper guide for a specific route: Weglot to Webflow Localization, moving a localized Webflow site to Framer, WPML or Polylang off WordPress and Next.js internationalization.
Which locale URL strategy should you use after migrating?
For most startups and B2B companies, subfolders such as /de/ and /fr/ are the right default. They keep all languages on one domain, so links and authority are shared, and every modern builder supports them. Choose subdomains or country domains only when you have a legal, business or infrastructure reason.
Structure | Example | Best for | Watch out for |
|---|---|---|---|
Subfolder | example.com/de/ | Most marketing sites | Needs a platform that supports locale routing |
Subdomain | de.example.com | Proxy translation tools, separate teams | Treated more like separate sites; harder to share authority |
Country domain | example.de | Strong local brands, regulated markets | Separate domains to buy, host and build links for |
URL parameter | example.com/?lang=de | Nothing new | Google's documentation recommends against it for locales |
A migration is the cheapest moment you'll ever have to change structure, because you're already rebuilding and redirecting. But it also doubles the risk. If you switch from subdomains to subfolders, every translated URL changes at once, so treat the redirect map as the most important deliverable of the project. The Weglot to Webflow guide covers that exact change.
Which platform handles multilingual sites best?
There is no single winner. Webflow Localization and Framer Localization both give you native subfolder locales inside a visual builder, Weglot adds translation to almost any site through a proxy or script, and Next.js gives full control at the cost of developer time. The right pick depends on how many locales you run and who edits them.
Option | How locales work | Editing workflow | Cost model |
|---|---|---|---|
Webflow Localization | Native subfolders, localized CMS fields and slugs | Translate in the Designer and CMS | Add-on per site; check the current plan page |
Framer Localization | Native locales with translated pages and CMS | Translate in Framer, optional AI translation | Charged per locale |
Weglot | Proxy or script layer on top of a site | Separate Weglot dashboard | Subscription by word count and languages |
Next.js with a headless CMS | Locale route segment plus CMS locale fields | In the CMS, with any workflow you build | Hosting plus CMS plan; no per-locale fee |
WordPress with WPML or Polylang | Plugin-managed language versions | Inside WordPress | Plugin license plus hosting |
Our full comparison of Webflow Localization vs Framer Localization vs Weglot prices the same site on each option. If you're also choosing between a translation tool and a real localization process, read why machine translation isn't enough first.
How do you export translations and translation memory?
Export everything in a standard format before you touch the new platform: page and CMS translations as XLIFF or CSV, and your translation memory as TMX if your translators or tool keep one. Translation memory is the database of approved sentence pairs, and it's often the most valuable asset in the whole project because it represents years of paid human translation.
List every translation source
Note where each locale's text lives today: the CMS, a plugin like WPML, a proxy like Weglot, a translation management system, or hardcoded strings in templates.
Export per locale and per content type
Pull pages, CMS items, navigation, forms, SEO titles and meta descriptions separately. Metadata is the part teams forget, and it's the part search results show.
Export translation memory and glossary
Ask your translation vendor or tool for a TMX file and the term glossary. Even if the new platform can't read them, your next translator can.
Check the export, not just the file
Open a sample in each language. Look for missing items, broken characters, and untranslated strings that a proxy tool was translating on the fly.
Freeze translation changes
Agree a cut-off date. Anything translated after the export has to be re-applied by hand on the new site, so keep that window short.
How do you map multilingual URLs and redirects?
Build one redirect map that lists every old URL in every locale next to its new URL, with one row per language version. Sorting it by locale makes gaps obvious: if French has noticeably fewer rows than English, you've found the problem before launch instead of in Search Console.
Include the URLs that only exist in some languages, the language switcher targets, and any locale-specific landing pages that campaigns still point to. Redirect each old translated URL to its direct equivalent, never to the new homepage or the English version. Redirecting a French page to English tells search engines the French page is gone.
For example, suppose you move from subdomains with untranslated slugs to subfolders with translated slugs
Hypothetical example: a SaaS site serves fr.example.com/pricing and fr.example.com/features/reporting. On the new platform these become example.com/fr/tarifs and example.com/fr/fonctionnalites/rapports.
Every French URL changes in two ways at once: host and slug. The redirect map needs a row for each, the subdomain needs to stay pointed at a server that issues the 301s, and the new hreflang annotations need to reference the new URLs only. If the subdomain's DNS record is deleted on launch day, none of the redirects can fire.
For the mechanics of building the sheet, the website migration cost hub links to our project plan template and related planning guides. For sites where hreflang is the main worry, see migration SEO for multilingual sites.
How do you set up hreflang after a migration?
hreflang tells search engines which URL to show for each language or region. After a migration, every page needs a full, reciprocal set of hreflang annotations that point to the new final URLs, plus an x-default for the fallback version. Missing return tags are the most common error, and they cause search engines to ignore the annotation.
- Self-reference. Each page lists itself as well as every alternate.
- Reciprocity. If the English page names the German page, the German page must name the English page.
- Final URLs only. Annotations point to 200 responses, never to redirects or non-canonical URLs.
- Valid codes. Use language codes like de, or language-region codes like de-AT, not country codes alone.
- One method. Put hreflang in HTML tags, HTTP headers or the XML sitemap, and don't mix methods with conflicting values.
Webflow and Framer generate hreflang automatically when you use their native localization, which removes most errors. On Next.js you generate it yourself from the same locale config that drives routing, which our Next.js internationalization guide shows step by step. Google documents the rules in its guide to localized versions of your pages.
What are the common multilingual migration routes?
Most multilingual migrations fall into one of five routes, and each has a different hard part. Find yours below and start with the matching guide.
Route | The hard part | Read next |
|---|---|---|
Weglot to Webflow Localization | Subdomain to subfolder URLs and exporting proxy translations | |
Localized Webflow to Framer | Translated slugs, CMS locale fields and hreflang checks | |
WPML or Polylang to Webflow or Framer | Exporting linked translations and language URL formats | |
Any builder to Next.js | Locale routing, CMS locale fields and generated hreflang | |
Framer to Next.js with locales | Rebuilding Framer locales as code and CMS fields |
If you're on Wix, Squarespace or GoDaddy with a translation app bolted on, our guide to outgrowing website builders covers the first step. If your move is driven by a bill rather than a feature, read migrate or optimize your plan before committing.
How much does a multilingual website migration cost?
A multilingual migration costs more than the same site in one language, because translation export, per-locale QA and hreflang add work for every language. Agency quotes for website migrations typically range from about $1,500 to $25,000 by size and CMS complexity, and multilingual projects tend toward the upper half of that range.
The biggest cost drivers are the number of locales, whether slugs are translated, how many CMS collections are localized, and whether translations are clean exports or locked inside a proxy tool. Recurring cost matters as much: per-locale localization fees on builders grow with every language you add, while a headless setup trades those fees for developer time. Our guides to multilingual website cost and website migration cost break both down.
- Designify website, up to 6 pages, custom design, Next.js and CMS
- $8,000
- Per extra page beyond six
- +$500
- Trial week before committing
- $1,000
Can AI translate and migrate a multilingual site?
AI can do a lot of the mechanical work: rebuilding templates, transforming exports between formats, drafting first-pass translations and checking hreflang sets for missing return tags. It shouldn't be the final word on translated copy or on the redirect map, because both carry real business and ranking risk.
The practical split is to let agents handle volume and let people handle judgment. Use AI to convert a WPML export into CMS-ready CSV or to generate a sitemap with alternates. Use native speakers to review pricing pages, legal pages and anything that sells. Our guide to AI-assisted website migration covers what coding agents do well and where they still need supervision.
A pre-launch checklist for multilingual migrations
Every locale has the same page count as before, or a written reason why not.
Every old translated URL returns a 301 to its direct equivalent in the same language.
hreflang is reciprocal, self-referencing and points to 200 URLs, with an x-default.
SEO titles, meta descriptions and social images are translated, not copied from English.
The language switcher links to the equivalent page, not the locale homepage.
Forms, cookie banners and legal pages work in every language.
Sitemaps list every locale, and Search Console has the property for any subdomain or country domain you're retiring.
What should you do first?
Start with an inventory, not a platform demo. Export a crawl of every locale, note where each language's translations live, and count the URLs per language. Those three facts tell you how big the project is and which route above you're on.
Then decide the URL structure, because it's the one decision that's expensive to change later. Once that's settled, choosing between Webflow, Framer and Next.js gets much easier, and our platform comparison for localization can do the rest.
