Multilingual Website for Business (RO/RU/EN): Why You Need One and How to Do It Right

In Short

In Moldova, multilingual websites aren’t a nice-to-have — they reflect the reality of the market. According to the 2024 census, 15.9% of the population, or 370,500 people, use Russian in everyday communication. That’s nearly one in six people in the country. Another 11.6%, or 280,000 people, said Russian is their native language. For companies that export or work with clients in the EU, English matters too. Without an English version, a meaningful share of potential customers, partners, and decision-makers simply won’t be able to properly use the site. CSA Research surveyed 8,709 consumers across 29 countries and found that 76% prefer to buy products when information is available in their own language. Another 40% said they won’t buy from websites that don’t support their language at all. Technically, the best way to build a multilingual website is to create separate language sections such as /ro/, /ru/, and /en/. That works much better than using subdomains or relying on a Google Translate widget. The language versions should also be connected with properly configured hreflang tags. At ilab.md, multilingual functionality doesn’t increase the cost of website development. We build websites with multilingual architecture from day one, so adding another language doesn’t require rebuilding templates or paying for a separate structural implementation. The only separate cost is translating and adapting the content.

Five Ways to Build a Multilingual Website — and Why Only One Makes Sense

• Subdirectories (ilab.md/ro/, /ru/, /en/) — each language gets its own version of the page while staying under the same main domain. These pages benefit from the authority of the primary domain while still being treated by search engines and AI crawlers as separate but related language versions.
• Subdomains (ro.site.md, ru.site.md) — they work technically, but search engines may treat them more like separate websites. In practice, that can mean each subdomain has to build authority independently instead of fully benefiting from the reputation of the main domain.
• Separate domains / ccTLDs (site.md, site.ro) — this setup is more expensive and more complicated to maintain. You’re dealing with several domains, SSL certificates, hosting environments, and often separate SEO efforts. It only makes sense when a company genuinely operates in several countries, especially through different legal entities. For most small and medium-sized businesses, it’s overkill.
• URL parameters (site.md?lang=ru) — this approach makes it harder for search engines to clearly separate language versions. Different content is being served through variations of the same URL structure, which can complicate indexing and make it harder for AI crawlers to understand that these are distinct language pages.
• Automatic translation widgets (Google Translate widgets and similar tools) — these translate the page dynamically in the user’s browser, but the underlying HTML still exists in only one language. For search engines and AI crawlers, the translated versions don’t exist as separate pages that can be indexed, ranked, or cited.

For businesses that care about visibility in Google and AI-generated answers, the practical choice is the first one: dedicated language subdirectories with complete, separately indexable pages for every language.

How to Build a Multilingual Website the Right Way

1. Architecture: Use Subdirectories, Not Subdomains

Google Search Central lists subdirectories as one of the standard approaches for multilingual and multi-regional websites, and for most businesses they’re usually the simplest and most efficient option. With subdirectories, every language version stays under the same main domain. You don’t have to split the website across several separate properties or build up the reputation of each language version from scratch. That’s exactly how ilab.md is structured: /ro/, /ru/, and /en/ all live under one domain rather than on separate subdomains or standalone websites. For a business, this means backlinks, mentions, reviews, and overall domain authority work together instead of being spread across several disconnected properties.

2. hreflang — One of the Most Common Technical Mistakes

hreflang tells search engines which language version of a page should be shown to which audience. One of Google’s key requirements is reciprocity. If the Romanian version points to the Russian version through hreflang, the Russian version needs to point back to the Romanian page. If that return link is missing, Google may ignore the annotation. This is one of the most common issues we see on multilingual websites: developers add hreflang to one version of the page but forget to implement the same relationship across all other language versions. Language codes also need to follow the correct ISO 639-1 format, such as ro, ru, and en. Custom or incomplete codes can create additional problems. It’s also a good idea to use x-default. This tells search engines which version should be shown when a user’s language doesn’t match any of the available options.

3. Translation: Machine Translation Is Useful, but Not for Sales Pages

Machine translation tools such as Google Translate API and DeepL are often good enough for news, support content, and straightforward informational pages. Sales pages are different. When you’re dealing with pricing, service terms, forms, guarantees, delivery times, or contractual details, small translation errors matter. A sentence can become less persuasive, unclear, or even misleading. CSA Research found that 65% of consumers are willing to tolerate content of average quality if it’s available in their own language. But that doesn’t mean businesses can afford mistakes in pricing, deadlines, guarantees, or service terms. For commercial pages, machine translation should be treated as a first draft. A fluent or native speaker should review and adapt it before publication.

4. Content You Can’t Simply Copy Between Languages

A multilingual website involves much more than translating the main body copy. You also need to localize the parts that are often forgotten: the meta title and meta description for every language, not just the H1; JSON-LD structured data with translated names and descriptions; phone number and currency formats; button labels; and contact form text. For an EU-facing audience, for example, it may make sense to show prices in euros and use an international phone number format rather than relying only on local conventions. Partial localization — where the main text is translated but metadata, structured data, buttons, and forms stay in one language — removes much of the value of having a multilingual website in the first place.

5. Why You Need English Even If Your Business Operates Only in Moldova

Even if your company serves only the Moldovan market today, an English version gives you access to three important audiences at once. The first is investors and international partners. In many cases, they’ll research your company online before they ever contact you. If the website isn’t available in English, you’re making that first evaluation harder than it needs to be. The second is AI search. Platforms such as ChatGPT, Perplexity, and similar tools generate answers in English when the user searches in English. Having high-quality English-language pages gives your website a much better chance of being discovered and referenced in those responses. The third is future export growth. If international expansion is even a medium-term goal, it’s much easier and cheaper to build the English version into the website from the start than to turn it into a separate project a year later.

Multilingual Websites Also Matter for AI Visibility — Not Just SEO

AI search engines such as ChatGPT, Perplexity, and Google AI Overviews usually answer in the language of the user’s query and tend to rely most heavily on content available in that same language. Based on our own observations while working on ilab.md and its visibility in AI search, a Romanian-language article may appear in answers to Romanian queries while having little or no visibility for equivalent Russian- or English-language searches. From an AI engine’s perspective, those language versions aren’t necessarily interchangeable. In practice, you should think of them as three separate sets of pages that need to be optimized, maintained, and promoted in their respective languages. That means a monolingual website doesn’t just lose part of Moldova’s local audience. It can also miss out on AI-generated answers in two of the three languages used by potential customers, partners, and decision-makers.

How We Do It

At ilab.md, multilingual architecture is built into the website from the beginning. With PHP/CodeIgniter, the language version is handled as part of the page structure rather than as a completely separate copy of the website that needs to be maintained independently. That means adding a new language doesn’t require new layouts, a rebuild, or a separate development budget. You only pay for translating and adapting the content for that specific audience. The hreflang setup and language subdirectory structure are configured once at the project level. After that, they’re applied automatically to every new page and article added to the website.

Sources

Localized versions of your pages — Google Search Central
Subdomain vs. Subdirectory vs. ccTLD — Search Engine Journal
Survey of 8,709 Consumers in 29 Countries Finds That 76% Prefer Purchasing Products With Information in Their Own Language — CSA Research