Multilingual corporate website: the right structure for exporters
A translate button bolted onto a Turkish page costs export deals. The real structure: separate URLs, hreflang, a translation workflow, proven on BRT Cabinet and Truexim.
A multilingual corporate website is not a Turkish page with a language switcher bolted on. It needs four things built correctly: a dedicated URL path per language with matching hreflang tags, a decision about which content gets professionally translated versus rewritten for that market, a translation workflow that doesn't rely on a plugin, and a pre-launch QA pass per language. Here is how that structure works on two sites Lumiasoft actually built: BRT Cabinet, a US-market kitchen cabinet brand, and Truexim, a foreign-trade operations platform.
Summary
A correct multilingual corporate site runs on four parts: a dedicated URL path per language with hreflang tags, a translate-vs-rewrite decision per page, a real translation workflow, and a pre-launch QA pass per language. BRT Cabinet's English pages are written for the US market specifically, not translated from Turkish, and score 98 on Lighthouse mobile and desktop. Truexim's multilingual corporate site and intranet run on the same path-based structure this site itself uses, with a 100/100 Lighthouse SEO score.
Where a single-language site loses the foreign buyer
A construction, manufacturing or trading firm that sells abroad usually has one Turkish site, sometimes with a machine-translated English toggle stacked on top. A buyer in Germany or the US opens it, hits broken grammar on the first paragraph, and closes the tab before reaching the contact form. The lost deal never shows up on an invoice. It shows up as a quote request that never arrived, which is why the cost stays invisible for years. The fix isn't a translation plugin: it's a site built from the start with a real multilingual structure, the same way Lumiasoft built it for BRT Cabinet and Truexim.
The technical backbone: URL structure and hreflang
Before any content decision, the site needs a URL structure search engines and buyers can both read correctly. There are three common approaches, and they are not interchangeable:
What the structure needs, part by part
URL path per language
A dedicated path for every language (/en/, /de/) with matching hreflang alternates, so search engines serve the right version to the right reader.
Translation workflow
A defined handoff for every new page: who writes the source, who translates or rewrites it, who approves it before it goes live.
Local SEO and metadata
Its own title, meta description and keyword targeting per language, not the Turkish metadata run through a translator.
Pre-launch QA per language
A native reader checks every page in that language before launch, not just the developer who built the template.
The URL structure choice itself has real tradeoffs:
| Structure | Hreflang setup | SEO authority | Used on |
|---|---|---|---|
| Path (/en/, /de/) | Simple, same domain | Consolidated under one domain | lumiasoft.com itself, BRT Cabinet |
| Subdomain (en.site.com) | Needs cross-subdomain hreflang | Split, harder to consolidate | Larger sites with separate teams per market |
| Country domain (site.co.uk) | Most complex, cross-domain | Fully separate per market | Enterprise brands with local legal entities |
For a corporate site built to win export deals, not to operate as separate regional businesses, the path-based structure is the right default: one domain's authority instead of three fragments. This very site runs that way, with every public URL carrying a /tr/ or /en/ path and a matching hreflang alternate generated automatically from the route table. It's the same structure Lumiasoft shipped for BRT Cabinet.
Which content gets translated, which gets rewritten: the BRT Cabinet and Truexim example
Translation and rewriting are not the same decision. A privacy notice can be translated word for word. A homepage pitch usually can't: what convinces a Turkish buyer and what convinces a US buyer are different arguments, built on different proof. BRT Cabinet's English pages were written for the American kitchen cabinet market specifically, with their own structure and their own proof, not a Turkish original run through a translator. Truexim went further: alongside a rebuilt corporate site, Lumiasoft built it an internal intranet module and mail automation that standardizes quote and customer handling across languages, plus an international search module for tracking opportunities across markets from one panel.
BRT Cabinet, Lighthouse
Mobile and desktop, US-market content written as its own original, not a translated Turkish page.
Truexim, Lighthouse
96 mobile, 100 desktop, built on top of an intranet and mail automation layer standardizing cross-market quotes.
The most common mistake: pages published through machine translation
The fastest way to make a multilingual site look worse than no English page at all is publishing raw machine-translated text. A buyer who can tell the English was never read by a human reads it as a signal that nobody on the other end is paying attention either. The pattern to avoid: a translation plugin or widget that rewrites the DOM at render time, with no native speaker ever reviewing a single page before it goes live. The fix costs one QA pass per language before launch, not a rebuild: a native reader goes through every page, flags anything that reads translated rather than written, and the team fixes it before the first foreign visitor sees it.
When this structure isn't needed yet
A firm that sells only within Turkey, with no plan to bid on foreign-buyer or foreign-investor work in the next year, doesn't need a second language yet. Building and maintaining a second language is ongoing work: every new page is two pages, not one, and a stale, half-translated second language looks worse than no second language. The honest starting point there is a strong single-language site with the export expansion planned for a later phase, not built speculatively before there's a market to serve.
FAQ
Is a translation plugin enough for a corporate site?
Only for low-stakes pages like a privacy notice. For anything a buyer reads to decide whether to trust the company, a plugin's machine translation reads as untranslated to a native speaker and costs more trust than it saves.
Does hreflang actually matter if the content is good?
Yes: without correct hreflang tags, search engines can show a buyer in Germany the Turkish version of a page even when a German or English version exists, which defeats the point of having built it.
Should the English site be a translation or its own version?
Its own version wherever it argues for the business. BRT Cabinet's English pages were written for the American market specifically; only low-stakes legal pages are straight translations.
Path, subdomain, or country domain: which should an exporter pick?
Path-based (/en/, /de/) for most exporters: it consolidates SEO authority under one domain and is what this site and BRT Cabinet both run on. Subdomains and country domains make more sense for enterprise brands with separate legal entities per market.
How long does adding a second language take on an existing site?
It depends on page count and whether content is translated or rewritten, but Lumiasoft's corporate website build ships a bilingual structure within the same 2-week standard delivery window when planned from the start.
BRT Cabinet's and Truexim's full builds are on their project page and project page. For the broader export-site checklist this structure sits inside, see construction company website examples; for the data side of running a multilingual catalog across channels, see e-commerce ERP integration. Both this structure and that data layer come out of the same corporate website build.