How to migrate URLs after redesigning a multilingual foreign trade website without losing search engine indexing

After a multilingual foreign trade website is redesigned, whether its indexed pages and organic traffic can be retained depends on whether clear, search-engine-recognizable relationships can be established between old pages, language versions, and new pages. As long as URL mapping, 301 redirects, language tags, and sitemaps are handled as a complete migration, the authority of most existing pages can be gradually transferred. Otherwise, even if the new website has a better design and richer content, indexing may decline due to a large number of broken old links.

For B2B foreign trade companies that rely on Google organic search to generate inquiries, a redesign involves more than changing the visual design and backend. Product pages, industry solution pages, blog content, PDF download pages, and directories in different languages may all have accumulated backlinks, keyword rankings, and historical crawl signals. During migration, the biggest concern is not that URLs change, but that “an old URL cannot find a suitable new destination.”

First determine: Which pages must retain migration relationships

Not every old page is worth migrating one-to-one, but any page that has been indexed, generates visits, or receives backlinks should first be included in the migration list. Many companies only organize product categories in the main navigation, overlooking earlier articles, discontinued products, old language directories, and advertising landing pages. Only after the redesigned site goes live do they discover that many 404 pages come from these omitted URLs.

When creating the list, old URLs should at least be divided into three categories:

• Pages that will remain available and whose topic is largely unchanged: An old product page corresponds to a new product page, and an old industry page corresponds to a new industry page. These pages should use the strictest one-to-one 301 redirects.
• Pages whose content has been consolidated: For example, multiple old model pages are consolidated into one series page, or several repetitive articles are integrated into one comprehensive guide. They can redirect to the most relevant consolidated page, but the new page must genuinely cover the core information of the old pages.
• Pages that are no longer available and have no reasonable replacement: For example, content related to products that have been completely discontinued or that is irrelevant to the current business. They may return 410 or retain a clearly explanatory page; it is not recommended to redirect all of them to the homepage merely to avoid 404 errors.

“Redirecting all old links to the homepage” may seem convenient, but it often causes a break in relevance. Neither search engines nor visitors can obtain corresponding information from a specific product link. Such redirects may be regarded as invalid handling, and the signals accumulated by old pages will also be difficult to transfer effectively.

URL mapping should be handled separately for each language version

Multilingual websites carry an additional layer of risk compared with single-language websites: the same product often has multiple independent URLs in English, German, Spanish, Russian, and other languages. If only the English directory is handled during the redesign, indexing for other language versions will gradually be lost due to path changes, changes in language-switching logic, or incorrect redirects.

Ideally, every old URL should have a clearly defined new URL. For example:

A migration table should not simply state “old product page redirects to product center.” It should record the old URL, new URL, page language, page type, redirect status, and notes. When there are many pages, this table also serves as a foundational document for collaboration among development, SEO, and content teams.

Do not redirect arbitrarily between languages either. Redirecting a visitor from an old German product page to the English homepage will usually reduce the user experience and make it difficult for search engines to understand the language attribution of the page. Unless content in a certain language has been formally discontinued and has no replacement page, priority should be given to retaining a target page in the same language.

301 redirects solve “where the old URL goes,” but cannot replace page quality

A 301 redirect is the standard method for telling search engines that a page has permanently moved. It should be implemented through server-side or website platform rules, rather than relying on JavaScript redirects, on-page prompt links, or Meta Refresh. For indexed URLs, a 301 redirect generally preserves existing search signals better than allowing the page to disappear directly.

However, 301 is not a universal remedy. Even when redirects are configured, the following practices can easily lead to unsatisfactory migration results:

• An old page redirects two or three times before reaching the final page, increasing crawl and visit loss;
• The new page has a canonical pointing to another URL, sending conflicting signals to search engines;
• The content of the new page is significantly reduced, retaining only a title and brief description and failing to address the original search intent;
• A large number of URLs are incorrectly matched by rules, causing product pages, article pages, and language pages to be directed to the same URL;
• Redirects are removed shortly after going live, or both old and new sites remain available for a long time, creating duplicate pages.

A relatively safe objective is for the old URL to return 301 directly, the new URL to return 200, and for the new page to be crawlable and indexable, without being blocked by robots directives or incorrectly set to noindex. Before going live, use URL crawling tools or browser developer tools to spot-check response statuses; do not only check whether the browser can ultimately open the page.

Multilingual tags and canonical settings determine how the new site is understood

After URL migration is completed, the second frequently overlooked issue is hreflang. It is not used to implement redirects; rather, it helps search engines understand which pages are equivalent versions for different languages or regions. If the URL structure changes after a redesign, old hreflang URLs, language codes, and reciprocal reference relationships must also be updated accordingly.

For example, when an English page identifies a German version, it should point to the redesigned German URL; the German page should also point back to the English version and include a self-reference. It is best to maintain corresponding relationships across language versions in terms of topic, product information, and page hierarchy. If the English page is a specific model page while the German page links only to a broad category page, the meaning of hreflang becomes unclear.

Also check canonical settings. Each indexable language page should generally self-reference its own canonical URL, rather than having all language versions canonicalized to the English page. The latter may cause non-English pages to be mistakenly treated as duplicate content, especially affecting smaller-language directories that already have an indexing foundation.

The launch sequence is more important than “submitting for indexing”

Search engines will not automatically inherit all page signals from the old site merely because a new sitemap has been submitted. A sitemap helps discover new URLs, while the actual migration still relies on accessible 301 redirects, reasonable internal links, and stable page statuses.

Before launch, URL mapping review, redirect deployment, hreflang and canonical updates should be completed, and an XML Sitemap containing only indexable new URLs should be generated. After launch, carry out four checks:

• Confirm that important old-site URLs return 301 and go directly to the final target pages;
• Confirm that new-site pages return 200, with no widespread 404, 500, noindex, or robots blocking issues;
• Submit the new Sitemap in Google Search Console, and monitor index coverage, crawl anomalies, and page redirect reports;
• Check pages with higher organic traffic, more backlinks, and greater inquiry value to ensure that page titles, main content topics, forms, or conversion paths were not lost during the redesign.

Redirects for old domains or old paths should not be disabled only a few weeks after the new site goes live. It takes time for search engines to recrawl, external websites to update links, and users to visit through historical bookmarks. For foreign trade websites, old links left in trade show materials, overseas directories, procurement platforms, and partner pages often remain in place much longer than expected.

Before redesigning, clarify whether URLs really need to change

Many migration losses can be avoided. If the main goals of a redesign are to update the visual design, improve the mobile experience, adjust inquiry components, or replace the website-building system, URL structures that already perform well do not necessarily need to be redone at the same time. Especially for product pages and long-established content pages, retaining the original paths is usually safer than comprehensively rewriting them merely to unify naming rules.

Systematic migration is more necessary only when the original URLs have issues such as language confusion, uncontrolled hierarchy, excessive parameter pages, site architecture adjustments, or international market segmentation. In this case, the redesign should be viewed as a handover of search assets: first identify which pages still have business value, then determine the destination for each language, and finally use ongoing monitoring to verify whether search engines accept the new site structure. By doing so, short-term indexing fluctuations may still occur, but years of accumulated page assets will not be wiped out at once due to fundamental migration errors.