RU/EN website in Dubai: what to translate, what to rewrite

Translate the pages that state facts, such as prices, specs, hours and policies, and rewrite the pages that have to persuade or rank, such as the homepage, service pages, FAQs and articles.

Published 10 min read

Translate the parts of your site that state facts: prices, opening hours, addresses, specs, policies and legal wording. Rewrite the parts that have to persuade or rank in search: the homepage offer, service pages, headlines, FAQs and articles.

A Russian-speaking customer in Dubai and an English-speaking one often want the same service. They phrase the question differently, trust different signals and may expect to reach you through different apps. A line-by-line translation keeps your facts and loses the rest.

Why line-by-line translation underperforms

Search phrasing is the first problem. People type queries in their own language with their own habits. Someone looking for a rental car in Russian might write "аренда авто без депозита дубай", while an English speaker types "car rental dubai no deposit". A translated page targets whatever phrase the translator happened to pick, and nobody may search for that phrase.

Wording matters even inside one language. In OpenSEO data (October 2026, UAE), "web design dubai" has 2,900 monthly searches with keyword difficulty 59. "Web design company dubai" has 1,600 searches with difficulty 6. Two phrases that look almost identical compete on very different terms. A second language adds its own layer of differences on top of that.

The second problem is what the reader needs to see before they contact you. An English-speaking expat might look for accepted insurance or parking nearby. A Russian-speaking reader might first look for a Russian-speaking manager and a familiar contact channel. The business is the same, but each reader needs a different first screen.

Page by page: translate or rewrite

Page or element Translate Rewrite Why
Homepage headline and offer Yes It has to match what each audience is looking for
Service pages: intro and benefits Yes Persuasion and keywords differ per language
Service pages: specs, inclusions Yes Facts must match across versions
Prices and packages Yes One source of truth; check currency and VAT wording
Product, car or menu item details Yes Keep names consistent, translate descriptions
Contact page Adapt Show the channels each audience uses
Privacy policy, terms Yes, by a professional Legal meaning has to survive; have a lawyer check
FAQ Yes Build it from questions each audience asks you
Meta titles and descriptions Yes Each one targets a phrase in that language
Blog articles Write separately Topics often differ between audiences
Customer reviews No No Show them in the original language

The facts layer: what a translator can handle

Facts are safe to translate because the meaning does not depend on tone. A car's horsepower, a clinic's opening hours or a package price stay the same in any language.

Two rules keep this layer clean:

  1. One source of truth. Store prices, specs and hours in one place that both versions read from. If the price lives in two hand-edited pages, someone will update English and forget Russian.
  2. Keep proper names as they appear elsewhere. Your business name, street and building should match your Google Business Profile, so a reader can find you on the map in either language.

Legal pages belong here too, with one condition: use a professional translator, then have your lawyer check the result. If the meaning of a privacy policy drifts between versions, you carry two different promises to two groups of customers.

The persuasion layer: what needs its own copy

Headlines, offers, service descriptions and calls to action need a writer who thinks in the target language. Give that writer the facts and a description of the audience, and ask for a page written for that reader.

Hypothetical example: a dental clinic in JLT. - English homepage: "Same-week appointments in JLT. Direct billing with major insurers. Free parking in the building." - Russian homepage: leads with a Russian-speaking doctor by name, shows prices in AED next to each treatment, and puts a Telegram button beside WhatsApp.

Both pages describe the same clinic with the same prices. They open with different things because the two readers check different things first.

Contact channels and payments are part of this layer. Lucent Legal is a site I built for a law firm serving Russian speakers in the UAE. Its AI assistant sends urgent cases straight to WhatsApp or Telegram. On the Lucent Rental site, the code supports Stripe for card payments in AED and YooKassa for Russian-issued cards. For a bilingual audience, the second language often means extra channels and payment methods as well as text.

Research keywords separately for each language

Run keyword research twice, once per language. Do not translate the English keyword list into Russian. Start from what customers say on calls and in chats, then check volume and difficulty in a tool set to that language and market.

If the tool shows thin or empty volumes for Russian queries in the UAE, use the numbers to compare phrases with each other. Do not use them to predict traffic. Let Russian queries decide the structure of the Russian version. If Russian speakers search "brand plus area" combinations more than generic terms, build those pages first. The Lucent Rental site has pages of this type ("brand by location") in both languages.

To learn how to shape each article so search engines and AI assistants quote it, see writing articles that AI cites.

When one language is enough

A second language costs money to write and maintain, so add it where a real audience will use it.

Two examples from my own projects: - Lucent Staff, an app for rental staff in Dubai, has an English interface because the staff who use it work in English. - IMPERIA THE1, a fitness app for a Russian-speaking audience worldwide, has a Russian interface and one Russian storefront for all App Store regions.

Apply the same logic to a website. If almost all your customers speak English, a thin Russian version with a few translated pages will look neglected. One strong English site serves them better.

Articles and guides: full parity or a selection

Full parity makes sense when both audiences ask the same questions. Lucent Legal has 213 guides in Russian and 213 in English. The Moon Mars site has 33 articles in each language. Both sites cover topics that the readers of each language need.

When the questions differ, write different articles. A Russian-speaking audience in Dubai may ask about moving money, Russian documents or services in Russian. An English-speaking audience may not care about any of this. If you match article counts only for symmetry, one version fills up with pages nobody searches for.

A rule of thumb: put every service and product page in both languages, and add articles only where the topic has demand in that language.

What about Arabic

Most venue sites in Dubai skip a second and third language. The Savage Media study analysed 409 Dubai restaurant and venue websites in full in October 2026. Only 82 of them (20.0%) had an Arabic version, 50 (12.2%) had a Russian one and 38 (9.3%) had all three.

Arabic brings right-to-left layout and separate typography. For some businesses it also brings rules about Arabic in advertising and signage. The Savage Media journal has an overview of Arabic language rules for ads and websites in the UAE. Requirements depend on the activity and the emirate, so check your case with a lawyer or the licensing authority before you decide.

Connecting the versions technically

Content decisions fail if search engines cannot tell the versions apart. Each language needs its own URL, such as /ru/ for Russian. Add hreflang tags that point each page to its counterpart. The language switcher should open the same page in the other language. If it drops the reader on the homepage, they have to search for the page again.

Common technical mistakes are covered in hreflang mistakes on RU/EN/AR sites. For the full technical setup with Arabic and RTL, see the multilingual website guide in the Savage Media journal. This article covers the content side.

What not to do

  • Auto-translate the whole site with a plugin and publish. The text will be grammatical in places and wrong in tone almost everywhere. The meta titles will target phrases nobody types.
  • Redirect visitors by IP or browser language. A Russian speaker with an English phone gets the wrong version, and search bots may never see one of the versions.
  • Translate reviews and show them as native. Keep reviews in their original language.
  • Copy the English keyword list into Russian. Research Russian phrases from scratch.
  • Launch a Russian version you will not maintain. If a price changed in English six months ago and still shows the old figure in Russian, you lose the reader's trust.
  • Put both languages on one URL with a toggle. Search engines index one version and ignore the other.
  • Leave English interface text in the Russian version. Buttons, form errors and cookie banners need translating too, and these are the elements people forget most often.
  • Mix languages in one page title. Pick one language per page and stay in it.

Questions to ask your web contractor

  1. Will each language have its own URL and hreflang tags?
  2. Where do prices and specs live, and does a change in one place update both versions?
  3. Who writes the Russian copy: a translator, a native copywriter or a tool? Who checks it?
  4. Will you run keyword research separately for each language?
  5. Where does the language switcher lead: the same page in the other language or the homepage?
  6. Are form messages, error pages and email notifications translated?
  7. Can I edit each language version myself without breaking the other?

The websites service page describes how I build bilingual sites against these points. For restaurant and venue sites, also read the restaurant website checklist.

Checklist

  1. List every page and mark it: translate, rewrite, adapt or write separately.
  2. Move prices, specs and hours into one shared data source.
  3. Run keyword research in each language, starting from real customer questions.
  4. Write the homepage and service pages from scratch for each audience.
  5. Have legal pages translated by a professional and reviewed by a lawyer.
  6. Set the contact channels for each language: WhatsApp, Telegram, phone.
  7. Keep reviews in their original language.
  8. Give each version its own URL and add hreflang pairs.
  9. Make the switcher open the same page in the other language.
  10. Translate interface text: buttons, forms, errors, notifications, the cookie banner.
  11. Add articles only where a topic has demand in that language.
  12. Once a month, open five random pages in both languages and compare prices and hours side by side.

Questions and answers

Can I use machine translation for the Russian version of my site?

For the facts layer (specs, hours, prices), a machine draft checked by a native speaker can work. For headlines, service pages and articles, you need copy written for Russian speakers from their own search phrases. A translated homepage usually reads like a translation, and readers notice.

Do both language versions need the same number of pages?

No. Product, service and legal pages should exist in both languages. Articles can differ if the two audiences ask different questions. Write the articles each audience searches for and skip the rest.

Should I translate customer reviews into Russian?

Show reviews in the language they were written in. A translated review presented as if a Russian speaker wrote it misleads the reader.

Is a separate URL for each language required?

For search, yes. Each version needs its own address, for example /ru/ for Russian, linked with hreflang so Google shows the right version to the right person. A language toggle that swaps text on one URL leaves one version invisible to search.