English site left on machine translation, but sales cannot match product names in overseas inquiries—fix translations first or backend first?

Conclusion first: in 2026 projects, it is usually acceptable to put the English site live on machine translation first, but whether the work turns into wasted effort is usually decided not by machine translation quality but by two foundations—whether every product has a fixed Chinese-English terminology mapping, and whether every language has its own URL that can be crawled and shared. If these two are missing, product names in inquiries from overseas customers will not match, and sales can only guess one by one against the model list; when the translations need to be rewritten later, the page structure has to be reworked as well. So in terms of sequence, sorting out the backend structure first and then filling in translations is usually less troublesome than the reverse.

When product names in inquiries do not match, it is usually not a machine translation error—the naming was never fixed in the first place

The most common complaint about machine translation is that it reads stiffly, but when overseas customers actually send inquiries, what blocks sales is often not grammar but inconsistent naming. The same product may get one English spelling on one page from machine translation, another on another page, and a third in an English brochure from two years ago; when customers ask using the third version, sales has to check repeatedly against the specification table. This kind of problem cannot be solved by retranslating the whole site. It depends on a terminology reference fixed before launch: product names, model number format, units of measure, and certification names each occupy one row, with fixed Chinese and English versions, and any change has to pass through this checkpoint.

The benefit of a terminology glossary is that it is checkable: when a customer asks with an English brochure, a trade show business card, or an email signature, whether it matches can be seen at a glance. Whole-article polishing is harder to check; after polishing, no one can clearly say which version is correct, and six months later a new operations person changes it again according to their own habits.

As for whether to fill in translations first or sort out structure first, my judgment is to take two steps: structure (URLs, indexing, and the replaceable copy layer) is the architecture layer; changing it after launch and indexing means going through crawling and indexing again. Translations belong to the content layer and can be replaced page by page and paragraph by paragraph, starting rough and becoming detailed without major disruption. Therefore, sorting out structure first and using machine translation to cover the translations is a lower-cost path.

Three common approaches: where the costs and maintenance workload differ

For multilingual corporate websites in 2026, common approaches fall roughly into three categories. Which one to choose depends mainly on the target market, content volume, and who maintains it later. There is no universally applicable option, only a matter of fit; the criterion is not which is more advanced, but who is responsible for updates and how often updates happen.

• Front-end language pack switching: changing copy within the same address. It launches quickly and requires little configuration, and suits intranet systems or use after login. A common problem on public sites is that the page URL does not change, so English content is not easily crawled separately; when a customer sends a link, the recipient often still opens the default Chinese page.
• Independent pages under subdirectories (such as /en/): more common when there are dozens of pages, two or three languages, and single-site operation. It shares one domain's accumulated authority; the workload for configuration plus content entry usually falls in a typical range of three to six working days, fluctuating with template complexity and page count. Later, changing one translation passage only requires editing in the backend and does not affect the layout. The cost is that untranslated pages need fallback rules.
• Subdomains or independent sites: more suitable when the target market needs separate campaigns, has an independent team for maintenance, or has different regional compliance requirements. The experience range for first-year investment is often 1.5 to 2 times that of the subdirectory approach or more, and someone must keep following it long term; without that, the usual result is that both sites remain in machine-translated status.

For a corporate website with content within dozens of pages, subdirectories are usually enough for two or three languages; if every country needs its own landing pages, local customer service, and local assets, the boundary of an independent site becomes clearer. A common disagreement at delivery is that the client wants to go straight to an independent site, but no one in the company can maintain translations long term.

Four things to check before launch

Breaking multilingual launch into four items is useful because they correspond to address, indexing, content, and entry point. If any one is missing, it will show up later as rework, and the rework usually lands on development rather than translation.

1. URL rules: each language has an independent and stable path, fixed once and not changed later.
2. Indexing configuration: pages in each language declare hreflang for each other, and each canonical points to itself; check the implementation against official search engine documentation rather than copying forum posts.
3. Replaceable copy layer: copy and template are separated, so copy can be replaced at a single page or paragraph without affecting the layout.
4. Switcher and untranslated-page fallback: the switcher is visible in the header and clickable on both desktop and mobile; pages not yet translated fall back to English or the default page for that language, not a direct 404.

The third item is relatively easy to skip, and the cost is that later changing one sentence requires developer involvement; the fourth is relatively easy to overlook, and visitors who land on a blank page simply leave. Writing these two into the acceptance criteria is much less troublesome than fixing them after launch.

A delivery scenario: limited budget, launch in one month, and only an old brochure as material

Constraints: the client gave a typical corporate website budget range, excluding professional translation fees; launch was tied to a trade show, about four weeks away; the only materials at hand were the existing Chinese site and an English brochure from two years earlier; there was no dedicated English editor in the company, only one salesperson willing to help check. Approach: first spend half a day with sales and product to set the terminology reference table (product names, model number format, units, certification names); all URLs use the /en/ subdirectory and are fixed once; machine-translated copy is entered page by page; Chinese banners and specification table screenshots in images are first replaced with plain images or temporarily left blank; untranslated pages fall back to the English default page and are marked with the update month; the switcher is placed in the top right of the header. Result and cost: the site launched within four weeks; during the trade show several inquiries came in, and sales could match model numbers directly using the terminology table. In the second month, when the client filled in English materials, because the terminology table existed, page-by-page replacement took about three to five working days. By contrast, in another project where terminology was not fixed first, the same product appeared with three different names across three pages; manual page-by-page comparison and unification took one to two extra weeks, and that time was outside the original contract scope, ending with each side making a concession.

At delivery, two points can also be agreed in advance: how soon the English version is synchronized after a Chinese revision, and which language untranslated pages fall back to. Putting these two into the acceptance checklist is more useful than saying verbally that they will be filled in later.

When it is suitable to launch machine translation first, and the boundaries where forcing it is not advisable

Suitable for launching first: the target market is already clear, there are plans to exhibit or there are already scattered overseas inquiries; the Chinese content is basically stable; someone in the company can regularly check the translations, even if only to check terminology, model numbers, and contact information.

Not advisable to force it: for a website that receives only a few scattered overseas emails a year, a few English product pages plus contact information are enough; a site-wide rollout is more like decoration; if the Chinese content itself is still undergoing major changes, wait until the Chinese is stable, otherwise the translations will need two rounds of changes; in industries where external copy requires review, machine-translated content should not be published directly, as it can easily cause compliance and wording problems.

Boundary statement: whether a multilingual version can launch on machine translation first depends on whether the structure is replaceable and whether anyone maintains it later, not on how urgently the client is pushing.

Frequently asked questions

Will machine-translated English pages be treated as low-quality content by search engines?

Usually, pages are not penalized specifically for being machine-translated; the risk comes more from thin page content or large blocks of duplication. Writing specifications and application scenarios as concrete sentences, then polishing the translation later, is more cost-effective than retranslating the whole site.

For the English version, should we use a subdirectory or buy a separate domain?

When operating a single site with dozens of pages, a subdirectory is more common, and both configuration and maintenance are controllable; if you need separate campaigns, an independent maintenance team, or different regional compliance requirements, then consider an independent domain, at the cost of roughly increased investment and staffing.

Should the language switcher go in the header or footer?

Putting it in the top right of the header is more common, and it must be clickable on both desktop and mobile. In the footer, it is easily buried after mobile collapse; overseas visitors cannot find the switch entry and often just close the page.

Should we unify product names first, or polish the entire translation first?

Unify product names first. A terminology reference is checkable and transferable, and one change benefits everything; whole-article polishing has no baseline for comparison, and after polishing it is still hard to judge which version is correct, so whoever takes over later will still improvise in their own way.

If Chinese and English content are out of sync, which side should be updated first?

Update first the side that brings inquiries, usually Chinese or the main target market language; fill in the other side according to the agreed cycle and mark the update month on the page, so customers do not see two contradictory versions.

When preparing an English or other language version, first spend half a day fixing these four items: terminology reference, URL rules, hreflang implementation, and untranslated-page fallback. Then discuss who will produce the translations and to what degree they will be polished. When Xiyue Company handles this kind of delivery, it first confirms who is responsible for updating translations, then decides whether to use a subdirectory or an independent site. For a website whose Chinese content is still being revised frequently, or that has almost no overseas visitors in a year, this step can be postponed.