Opening Pain Point: You Translated It, But Customers Still Won't Use It
There's a company website for industrial equipment that spent money in 2025 translating its Chinese site into English, Spanish, and Russian. Three months after launch, overseas inquiries barely increased.
Upon investigation: the English page titles were still in Chinese, the URLs used parameter formats like `?lang=en`, and Google barely indexed them; the Spanish pages showed dates as "2025年10月15日," which local customers couldn't understand; the Russian version had garbled characters on some pages because the encoding wasn't set properly.
The problem wasn't the translation—it was that multilingual website development never treated "language" as a systematic engineering challenge from the start.
A multilingual website is not an appendage of translation. It involves technical architecture, SEO, content management, and ongoing maintenance. Below, we break it down into five points to clarify where problems are most likely to occur and how to avoid them.
1. Don't Mix Up Language Codes and Region Codes
The first step in multilingual development is to think clearly: are you building "multilingual" or "multi-regional"?
- Multilingual: The same product, different languages. For example, Chinese, English, Japanese.
- Multi-regional: The same language, different regions. For example, English needs to be split into US, UK, and Australian versions because pricing, currency, and regulations differ.
The standard technical approach is to use the `hreflang` tag with the format "language-region," such as `zh-CN`, `en-US`, `en-GB`, `es-MX`.
Common pitfall: writing only `en` without the region. Google won't know who you're targeting, and your site may end up competing with other English sites.
Recommended approach:
1. First, create a table listing target languages and target regions separately;
2. Add `hreflang` to every page, with mutual references;
3. Don't forget to add `x-default` pointing to the default version (usually English or Chinese).
This table may seem tedious, but it's the foundation for URLs, SEO, and backend structure later on. Many website development projects require rework precisely because this step was skipped.
2. Choosing the Wrong URL Structure Is Painful to Fix Later
There are three common URL approaches for multilingual sites:
- Subdirectory: `c-mic.cn/en/`
- Subdomain: `en.c-mic.cn`
- Separate domain: `c-mic-en.com`
None is absolutely better than the others, but subdirectories are recommended as the priority. The reasons are practical:
- The main domain's authority can be directly shared with each language version, making new sites easier to index;
- One SSL certificate and one CDN configuration can cover everything;
- Adding a language later just means adding a directory without touching the main site structure.
Subdomains and separate domains are better suited for cases with significant brand differences or when separate local registrations are required.
Pitfall warning: Never use parameter formats like `?lang=en`. Search engines have always handled parameter URLs poorly—slow indexing, diluted authority, and extensive 301 redirects needed if you want to change later.
If you're currently doing a corporate website redesign, it's best to decide this at the prototype stage, not after all the pages are written.
3. Character Encoding and Typography: Details Determine Professionalism
Garbled text is the most credibility-damaging problem for multilingual sites, bar none.
Technical baseline:
- Use UTF-8 encoding site-wide;
- Specify `` in HTML;
- Databases, APIs, and exported files should also use UTF-8 to avoid Chinese being stored and Russian coming out as question marks.
Typography details:
- Arabic and Hebrew are right-to-left (RTL), requiring `dir="rtl"` in CSS and a fully mirrored layout;
- German and Russian words are long, easily overflowing buttons and navigation—leave at least 30% extra space in design;
- Dates, currencies, and number formats should follow regional conventions—don't hardcode one format site-wide;
- Confirm fonts support the target language. Source Han Sans for Chinese, Noto Sans JP for Japanese, and Amiri for Arabic are common choices.
These aren't "aesthetic" issues—they're the first thing customers see when judging whether you're professional.
4. SEO Isn't Translation—It's a Complete Redo
The most common mistake in multilingual sites: machine-translating Chinese titles directly.
Search engines care about whether "this page can solve local users' problems," not whether "the word was translated accurately."
Things you should do:
1. Redo keyword research. Chinese users search for "网站安全测试," but English customers might search for "penetration testing service"—completely different root words.
2. Localize titles and descriptions. Don't mix Chinese and English, and don't use Chinese punctuation.
3. Don't just do literal translations. For example: Chinese websites love writing "公司简介," but English sites more commonly use About Us + Our Team + Case Studies—splitting them up actually gets indexed more easily.
4. Submit sitemaps separately. Generate independent sitemaps for each language version and submit them separately in Google Search Console.
5. Keep internal links language-consistent. Don't link English pages to Chinese pages—it confuses both user experience and crawler logic.
If you're also doing mini-program development or App development, it's best to share one copy library for multilingual content across the official website to avoid translating three times and having inconsistent terminology.
5. Backend Management: Don't Make Operations Staff Find Developers Every Time They Change a Word
Launching a multilingual site is just the beginning—the real burden is ongoing maintenance.
A specific scenario: a company doing cross-border appointment services has three versions of its website (Chinese, English, Japanese) plus an appointment mini-program. Every time operations staff changes a campaign message, they have to log into three separate backends, make three edits, publish three times, and often miss one language.
A reasonable approach:
- Use a "one content entry + multiple language fields" structure in the backend, rather than building three separate content sets;
- Allow copying, comparing, and marking "pending translation" between languages;
- Support exporting Excel or CSV for translators and importing back after translation;
- When switching languages on the frontend, try to stay on the current page rather than jumping back to the homepage.
This structure takes an extra two or three days to design upfront but saves massive communication costs later.
When to Consider MIC Studio
If your project falls into any of the following categories, going it alone can lead to unnecessary detours:
- The website needs to expand from one language to three or more, while also handling SEO indexing;
- Corporate website redesign that also requires a backend management system and multilingual content library;
- Mini-program development or App development that needs to share a multilingual copy library with the official website;
- Security testing needed before launching an overseas site, especially for forms, payments, and login sections;
- Existing sites with garbled text, indexing anomalies, or chaotic language redirects that need troubleshooting.
MIC Studio does corporate websites, mini-programs, Apps, and script development, as well as website security testing and reverse engineering testing. For multilingual projects, we typically spend half a day clarifying the language table, URL approach, and backend structure before writing any code, avoiding post-launch rework.
Conclusion: Three Actionable Recommendations
1. Define the table before starting. Write target languages, regions, URL approach, and default language into a one-page document, get team confirmation, then develop.
2. Get encoding and hreflang right the first time. Unify UTF-8 across the entire chain, add hreflang and x-default to every page—don't leave it for phase two.
3. Design the backend around "one content entry with multiple language fields." Even if you only have two languages now, build it with an extensible structure so adding languages doesn't require restructuring.
The barrier to multilingual website development isn't translation—it's architecture and details. Get these things right, and overseas customers' trust will be noticeably different.