Website Localisation for Chinese-Owned Businesses: Language, Currency and Search
A translated website is not a localised one. Localisation is three layers — language, commercial convention, and search structure — and most projects do the first, skip the second, and break the third.
A Chinese-owned business operating in Europe or North America usually needs two audiences on one site: local customers who decide in the local language, and Chinese-speaking owners or partners who review the same content in Chinese. Getting both right is a structural problem, not a translation problem.
Layer one: language
The first decision is not which languages, but which content is genuinely bilingual. Translating everything produces a Chinese version of pages that only a local customer would read, which adds maintenance cost without adding an audience. The pattern that works is:
- Product and service pages: fully localised, because they are read by the buyer.
- Company, quality and certification pages: localised, because they are read by the buyer\u2019s procurement team.
- Operational detail — internal process descriptions, staff guides — kept in the operating language only.
- Commercial documents such as quotations and invoices: local language, with a Chinese reference copy for the owner rather than a bilingual document for the customer.
Mixing both languages into one page ("Chinese headline, English body") is the pattern to avoid. It reads as unfinished to a local buyer and makes the page impossible to rank in either language.
Layer two: commercial convention
This is the layer most often skipped, and it is the one that loses trust fastest. A buyer notices when a price is displayed without tax context, when the currency is ambiguous, or when the address and phone format belong to another country.
| Element | What a local buyer expects |
|---|---|
| Price display | Whether tax is included, stated explicitly — B2C in the EU shows gross prices, B2B often shows net |
| Currency | Local currency, or a clearly marked currency code rather than a bare symbol |
| Address | Local format, with the country stated if the business is elsewhere |
| Phone | A number that can be dialled locally, or a stated calling window if it cannot |
| Dates and units | Local order and units — day/month versus month/day, metric versus imperial |
| Legal identifiers | Company registration and VAT number, where the jurisdiction requires them on the site |
None of these are hard to implement, and all of them are visible in the first ten seconds. A price without tax context is the single most common credibility leak on a Chinese-owned business site selling into Europe.
Layer three: search structure
Once there is more than one language, the way the versions relate to each other decides whether search engines show the right one. Three things have to be right.
Separate URLs, not a language cookie
A language switcher that changes content without changing the URL leaves search engines with one page and no way to index the other language. Each language needs its own address — a subdirectory, a subdomain or a separate domain — and the choice should be made once, because changing it later means re-earning whatever the old URLs had.
Reciprocal hreflang, including x-default
Every language version should declare every other version, including itself, and the declarations must be mutual: if the English page points to the German page, the German page must point back. A one-way hreflang set is ignored. The x-default entry tells search engines which version to serve when no language matches, and pointing it at a Chinese page means an English-speaking searcher lands on Chinese content.
A canonical that does not contradict the hreflang
The most common structural mistake is a canonical tag on the translated page pointing back to the original language. That tells search engines the translated page is a duplicate and should not be indexed, which silently removes it from results. Each language version should be self-canonical.
A release checklist
- Decide which pages are genuinely bilingual, and say so in the sitemap.
- Give each language its own URL path, decided before launch.
- Make hreflang reciprocal across all versions, with x-default pointing at the international fallback.
- Keep each language version self-canonical.
- Show prices with the tax treatment stated, in a currency with an explicit code.
- Localise address, phone, date and unit formats.
- Publish a sitemap per language and submit each one separately, so indexing can be tracked per market.
The technical items take days, not months. The reason they are often wrong is that they are decided by whoever builds the language switcher rather than by whoever owns the search strategy — and the cost shows up months later as a market that never gets traffic.
Questions we are asked
Should we use a subdirectory or a separate domain per market?
A subdirectory keeps authority concentrated and is simpler to maintain; a separate domain is occasionally required by local regulation or brand structure. Both work if hreflang is correct. The expensive mistake is changing the choice after launch.
Do we need a Chinese version if our customers are local?
Not for the customer-facing pages. But owners and partners frequently review the site in Chinese, and a Chinese version that mirrors the commercial content — not the marketing copy — is usually worth having. It should not be the default version that an international visitor lands on.
How do we show prices to both B2B and B2C buyers?
Separate the price from the display rule. Store net price and tax rate as data, then let the page decide how to present it by audience. Hard-coding "including VAT" into page text is what makes the site impossible to reuse across markets.
