Web Development

Building a Multilingual Website: Architecture, SEO and Translation Workflow

Adding languages is more than translating text. Learn how to structure URLs, handle SEO and right-to-left layouts, and set up a translation workflow that lasts.

Illustration of one website shown in three language versions, including a right-to-left Arabic layout, linked by a globe icon

Serving customers in more than one language opens new markets, but it also multiplies complexity. Every page, form, email, product and error message now exists in several versions — and search engines need to understand how they relate. Done well, multilingual website development gives each audience a site that feels native. Done poorly, it creates duplicate content, broken navigation and an admin panel nobody wants to touch. This guide covers the architecture decisions, SEO requirements, right-to-left (RTL) considerations and translation workflow you should plan before building.

Start with strategy, not translation

Before choosing technology, answer these questions:

  • Languages or regions? Are you targeting languages (English, French, Arabic) or specific countries (Canada, UAE, Saudi Arabia), or combinations such as French for Canada?
  • Same content or localized content? Will every language have the same pages, or will offers, products and contact details differ by market?
  • Who translates and approves? Internal staff, agencies, or a mix?
  • How often does content change? A static corporate site and a daily news feed need very different workflows.

In Canada, many businesses serve English and French audiences; in the UAE, English and Arabic are both common. Our guide to localizing for GCC markets covers regional nuances in more detail.

Choosing a URL structure

Each language version needs its own crawlable URL. The main options:

Structure Example Pros Cons
Country-code domains example.ca, example.ae Strong local signal, clear to users Higher cost, separate authority to build, more to manage
Subdirectories example.com/fr/, example.com/ar/ One domain's authority, simple to manage Weaker per-country signal than ccTLDs
Subdomains fr.example.com Can be hosted separately Often treated more like separate sites
URL parameters example.com?lang=fr Easy to bolt on Not recommended; poor for SEO and sharing

For most businesses, subdirectories offer the best balance. Avoid serving different languages on the same URL based on browser settings or cookies — search engines may only ever see one version.

Key takeaway: Every language version needs its own stable URL. Decide the structure before you build, because changing it later means redirects across the entire site.

Multilingual SEO essentials

Hreflang

Hreflang annotations tell search engines which version to show each audience. Rules that are often missed:

  • Every version must list all versions, including itself.
  • Annotations must be reciprocal — if the English page points to the French page, the French page must point back.
  • Use correct codes: language (fr), or language plus region (fr-CA, ar-AE).
  • Add an x-default for users who match no listed language.

See our dedicated article on international SEO and hreflang for implementation patterns.

Translate the SEO elements too

  • Titles, meta descriptions and headings in each language.
  • Translated, readable URL slugs where practical.
  • Image alt text.
  • Structured data with localized names and descriptions.
  • Separate XML sitemaps per language, or a combined sitemap with hreflang.

Research keywords per language

Direct translation of keywords rarely matches how people actually search. Research each market separately, ideally with native speakers.

Architecture inside the application

How content is stored determines how pleasant the system is to use.

Field-level translation

Each translatable field (title, body, summary) stores a value per language, while shared data (price, SKU, images) is stored once. This works well for product catalogues where structure is identical across languages.

Entry-level translation

Each language version is a separate entry linked to the others. This suits content that differs substantially between markets, such as news or campaigns.

Many platforms combine both. Our Apex CMS engine, for example, supports translatable fields for catalogues alongside per-language entries for editorial content.

Do not forget the rest of the interface

  • Navigation menus and footer links
  • Form labels, validation messages and confirmation emails
  • Date, number and currency formats
  • Legal pages and cookie notices
  • Search results and filters
  • Transactional emails and PDF documents

Designing for right-to-left languages

Arabic, Persian and Hebrew read right to left, which affects the entire layout, not just text direction.

  1. Set dir="rtl" and the correct lang attribute on the page.
  2. Use CSS logical properties (margin-inline-start instead of margin-left) so layouts mirror automatically.
  3. Mirror directional icons such as arrows and progress indicators, but not universal icons like play buttons or logos.
  4. Choose fonts designed for the script, with proper line height; Arabic script often needs more vertical space.
  5. Handle mixed-direction content — phone numbers, product codes and English brand names inside Arabic text.
  6. Test with real content, not placeholder Latin text.

For a deeper dive, read designing right-to-left websites.

Building a translation workflow

Technology is only half the problem; the other half is keeping translations accurate and current.

  1. Author content in the source language and mark it ready for translation.
  2. Notify translators automatically when source content changes.
  3. Track status per language: not started, in progress, in review, published.
  4. Use glossaries for product names, technical terms and brand voice.
  5. Review in context — preview translated pages before publishing.
  6. Flag outdated translations when the source changes after publication.

Machine translation can help with first drafts and internal content, but customer-facing pages benefit from human review, particularly for legal, medical or technical material.

Language detection and switching

  • Let users choose their language with a clear, always-visible switcher that names each language in its own script (for example "Français", "العربية").
  • Switch to the equivalent page, not the home page.
  • Suggest a language based on browser settings if you like, but do not force redirects; respect the user's choice and remember it.
  • Never block search engine crawlers from reaching any language version.

Performance and hosting for multiple markets

Serving audiences in different regions raises practical infrastructure questions:

  • Server location. Hosting closer to your main audience reduces latency. If you serve both Canada and the Gulf, a CDN can deliver static files from locations near each audience while the application runs in one region.
  • Data residency. Some industries and contracts require personal data to stay in a specific country. Check your obligations before choosing hosting, and seek legal advice where personal or health data is involved.
  • Fonts. Arabic and Persian fonts can be large. Subset them to the characters you need and load only the weights you use.
  • Caching per language. Make sure caches vary by language so visitors never see a page cached in the wrong language.

Testing a multilingual site before launch

A structured test plan catches the problems users notice first:

  1. Switch languages on every template type and confirm you land on the equivalent page.
  2. Check that no hard-coded text remains in the wrong language, including buttons, errors and emails.
  3. Validate hreflang with a crawler and confirm every annotation points to a live, indexable page.
  4. Submit each form in each language and check the confirmation email.
  5. Review RTL pages for mirrored layout, icon direction, number formatting and mixed-direction text.
  6. Test search and filters with non-Latin characters.
  7. Ask a native speaker to read key pages in context, not just in a spreadsheet.

Common mistakes

  • Launching with partially translated pages mixing two languages.
  • Hreflang errors that point to redirected or non-existent URLs.
  • Hard-coded text in templates that never got translated.
  • Using flags to represent languages (languages are not countries).
  • Forgetting localized contact details, currencies and legal requirements.

Next steps

A multilingual site is a long-term commitment to every audience it serves, so the architecture and workflow deserve as much attention as the design. DigiVort builds bilingual and multilingual platforms, including right-to-left interfaces, on engines designed for translation from the start. Explore our custom web development and SEO and content services, or start a project to discuss your markets and languages.

Frequently asked questions

Can I use automatic translation for my multilingual website?

Machine translation can speed up first drafts, but publishing it unreviewed risks errors, awkward phrasing and poor search performance. For key pages, have a fluent reviewer or professional translator check and adapt the content.

Should each language have its own domain?

Not necessarily. Separate country domains send strong local signals but cost more to manage and build authority for. Subdirectories on one domain are often the most practical choice for businesses entering a few markets.

What is hreflang and do I need it?

Hreflang is an annotation that tells search engines which language or regional version of a page to show to which users. If you have equivalent pages in more than one language, you should implement it correctly on every version.

How do I handle content that only exists in one language?

Decide a clear policy. You can hide untranslated pages from the other language's navigation, or show a notice and link to the available version. Avoid automatically showing mixed-language pages without telling the user.

Does a right-to-left language need a separate design?

It needs a mirrored layout, not a completely separate design. With logical CSS properties and careful testing, one design system can serve both left-to-right and right-to-left languages.