Web Development

Multilingual Website Development in the UAE (2026): Which Languages, and What It Costs to Keep Them

SKIMBOX Team

A second language looks like a project and behaves like a subscription. What the UAE government actually publishes about languages, how to structure URLs and hreflang, and the maintenance cost that quietly kills the second version.

Multilingual Website Development in the UAE (2026): Which Languages, and What It Costs to Keep Them

Last updated: August 2026

A second language looks like a project. It behaves like a subscription.

The build is the small part. What happens afterwards is that every page, every offer and every price now exists twice. Then three times. Then four. Your English site keeps moving, because that is where the business actually runs. The other versions do not, because nobody owns them. Eighteen months later a customer lands on your Russian pricing page and reads a number you stopped charging last year.

That is the honest case for publishing fewer languages properly rather than many badly, and it is where this guide starts.

The second thing worth your attention is hreflang, the most commonly broken piece of technical setup on multilingual sites. Google's rule is that the annotations have to point both ways, and when they do not, the whole set gets ignored [2].

Arabic is its own subject and we have written about it three times already. This guide sits above Arabic. It is about how many languages, which ones, how to structure them, and what it costs to keep them honest.

The cost that shows up after launch

Think about what a second language does to your operating model rather than to your build budget.

Every new service page is now two pages. Every price change is two edits. Every campaign landing page, every seasonal offer, every policy update, every new post. Add a third language and the multiplier is three. None of it is difficult. It is just relentless, and it competes with everything else your team has to do that week.

Here is where an annoyance turns into a search problem. Google's hreflang rule requires every version of a page to point at every other version, and if two pages do not both point to each other the tags are ignored [2]. So a new English page with no Russian counterpart is not part of your multilingual set at all. Google falls back on its own judgement about which version to show which searcher [2]. The set you paid to build no longer covers your newest and most commercial content.

The commercial damage lands first, though. A stale price is a stale promise. A visitor who finds one does not think the page was not updated. They think you quoted one number and charge another.

Real talk: the question is not whether you can afford to translate your site. It is whether you can afford to keep translating it every week for the next five years. If the answer is no for four languages but yes for two, publish two.

What the UAE government actually publishes about languages

Very little, and that is useful to know before somebody sells you a statistic.

Arabic is the official language of the UAE [8]. The government's own fact sheet also states that five other languages have official status in the courts: Chinese, English, French, Hindi and Russian [8]. Separately, the same fact sheet lists other widely spoken languages as Bengali, Farsi, Malayalam, Turkish and Urdu [8]. Road signs and commercial outlet signage appear in Arabic and English [8].

Read that for what it is. Court status is a legal recognition. The widely spoken list describes prevalence. Neither measures your customers, and the fact sheet attaches no percentage, share or ranking to any language on either list [8].

We are not going to quote you a population figure or a language share, and it is worth saying why. Figures of that kind circulate constantly, and almost all trace back to the federal statistics authority through several layers of retelling. We could not reach that authority's site directly to verify anything while researching this piece [9]. So we are not publishing numbers we could not confirm at source, and you should treat any language usage percentage you see elsewhere the same way.

The two official lists are good for one thing: a shortlist. Guessing from them is more defensible than guessing from a marketing blog.

The only language data that matters is yours

So stop guessing.

Your analytics already records the browser language of every visitor. Your CRM knows which enquiries close. Your sales team knows which calls get harder because of language. Your inbox and your WhatsApp know which questions arrive in which one.

Ask three questions of that data:

  • Where do enquiries that already close come from? Not traffic. Revenue.
  • Where do enquiries stall? A language barrier usually appears as a healthy enquiry rate with a poor close rate from one segment.
  • What would the second language actually change? If your buyer is a procurement manager who works in English all day, another version of your site is a courtesy, not a conversion lever.

A language earns its place when it maps to people who transact with you. Not people who pass through the country, and not people inside an unsourceable statistic.

Where the language versions live on your domain

Google names three URL patterns and publishes the trade offs for each [1].

  • A country code domain. Google calls this clear geotargeting, with server location irrelevant, but notes it is expensive, can have limited availability, and sometimes carries strict requirements [1].
  • A subdomain, such as ru.example.com. Easy to set up and allows different server locations, with the trade off that users might not recognise the geotargeting from the URL alone [1].
  • A subdirectory, such as example.com/ru/. Easy to set up and low maintenance because it is on the same host, with the trade off of a single server location and harder separation between sites [1].

Google does not recommend URL parameters for this kind of segmentation [1].

For most UAE businesses already running one domain, the subdirectory is the sensible default. It is the lowest maintenance option Google names, it sits on the domain you already have, and it does not create new infrastructure for somebody to forget about. A subdomain earns its place when a separate team or content system genuinely owns that language version. A dedicated country domain is the heavy option, and Google itself flags the cost [1].

One more line from the same page matters more than it looks. Google states it does not vary the crawler it uses to discover locale variations of a single site, and that you must explicitly tell Google about any locale or language variation [1].

hreflang, and why it is broken on so many sites

hreflang tells Google that several pages are localised variations of the same content, so the right one can be served to the right searcher [2]. It does not tell Google what language a page is written in. Google determines that algorithmically from the content itself [2].

Three rules matter more than the rest.

It has to be reciprocal. Google's own wording is that if two pages do not both point to each other, the tags will be ignored, so that someone on another site cannot arbitrarily name their page as an alternative version of yours [2]. Every version of a page must reference every other version, including itself.

x-default is the fallback. It is used when no other language or region version matches the visitor's browser setting [2]. Point it at a language selector or at your default version, which for most UAE businesses is English.

Placement is your choice, but pick one. Google supports three equivalent methods: link elements in the page head, HTTP Link headers, useful for non HTML files such as PDFs, and entries inside an XML sitemap [2]. Mixing methods is how sets end up half declared and nobody notices.

Google also names the common mistakes directly: missing return links, incorrect language codes, and invalid region codes such as EU, UN or UK, where the correct code for the United Kingdom is GB [2]. The values follow BCP 47, the standard behind language tags in HTML and XML, which is what makes short codes and region variants such as en-AE valid. W3C also recommends declaring the language on the html element of every page [7].

The failure we see most often is one directional. The new Russian page correctly points at the English page. The English page, built two years earlier and rarely revisited, never gets updated to point back. Because the set is invalid the moment one direction is missing, that single omission takes out the whole cluster rather than one pair.

Google's stated behaviour when annotations are broken is to ignore them, not to penalise the site [2]. That sounds mild. The practical result is the same as having no hreflang at all, and Google's own guidance says it is usually best to explicitly indicate your language or region specific pages [2].

So build the check into your release process. If a page ships in one language, either its counterparts ship with it or somebody records that the set is incomplete. Nobody finds a broken hreflang set by accident.

Do not guess the visitor's language for them

This is the most common well intentioned mistake on a multilingual site.

Google's guidance is explicit: avoid automatically redirecting users from one language version of a site to a different language version [1]. Google also states that IP location analysis is difficult and generally not reliable, and that it may not be able to crawl variations of your site properly when content is served that way [1].

The search consequence is worse than the user consequence. Googlebot's crawl requests are not reliably localised, and much of its crawling comes from one region, so a site that redirects on perceived location can end up showing Google only one version of itself [1][3]. Your other languages then do not merely rank badly. They may never be discovered.

Google's recommended alternative is plain: add hyperlinks to other language versions of a page, so users can click to choose a different language version [1]. A visible, persistent switcher. Not a pop-up that guesses.

One related detail catches teams out during phased rollouts. Robots directives have to be applied consistently across every locale variant of a page [3]. Blocking one version and not another creates crawl problems specific to multilingual sites, and a temporary block left in place after launch is an easy way to get there.

Translation quality, and where Google draws the line

Duplicate content is not automatically a problem. Google states that some duplicate content on a site is normal and is not a violation of its spam policies [4].

The multilingual rule is specific and worth memorising: different language versions of a single page are considered duplicates only if the primary content is in the same language [4]. A genuinely translated page is therefore not a duplicate of its source. A page where only the navigation and footer were translated, while the body stayed in English, still is. That is why the translate-the-template shortcut fails. Those pages never earn credit as distinct localised pages.

On machine translation, Google's spam policies name the practice directly. Under scaled content abuse, they list generating many pages through automated transformations, including synonymising and translating, as content produced at scale without adding value for users [5]. Note where the line sits. It is at scale and without review, not at the existence of machine translation. A machine first draft that a competent human then edits is a different practice from publishing thousands of unreviewed pages.

Nor should you assume Google's own translation covers you. Google can translate a result's title and snippet and let a user open a translated version of a page, but describes this as no different from using Google Translate or in browser translation, and states that it does not host translated pages [6]. You can opt out per page with a notranslate tag or header [6]. It is a convenience layer sitting on your unchanged page, not a localised page of your own.

What this costs

No government body, standards organisation or statistics authority publishes translation or localisation rates. This is a commercial rate, not a regulated one, so the figures below are ours and not a market survey [10].

Adding a second language to an existing site starts from around AED 2,500, where the pages already exist and only the content and the technical wiring are new [10]. Final pricing depends on scope. The two things that move it most are page count and whether your current setup can hold multiple locales at all.

For context against our other published figures:

  • A focused business website build starts from around AED 3,500. Our website cost guide breaks that down by site type [10].
  • Arabic costs more than the languages discussed here, because right-to-left work is layout engineering rather than translation. Our RTL design guide and our Arabic search guide cover that ground, and Urdu carries a similar right-to-left cost profile [10].
  • Video does not translate itself. Subtitles start from around AED 300, a professional voiceover track from around AED 550, and a full localisation with rebuilt on-screen text from around AED 1,500. See our voiceover and subtitling guide [10].
  • If a language rollout forces a URL restructure, that is a migration, starting from around AED 5,000 [10]. Our migration guide explains what has to be preserved.

Now the part that actually decides this. Compare the one off build against the recurring cost of keeping the second language alive. Content production is the honest benchmark: a single article starts from around AED 500, and an ongoing content retainer starts from around AED 2,000 per month [10]. Our content marketing cost guide sets out the bands.

Run that forward on a site that publishes regularly. Run that forward on a site that publishes regularly and the recurring cost overtakes the one off build faster than most teams expect. Do the sum with your own publishing rate before you agree to a fourth language, because that is the figure to show whoever is asking for it. That is the figure to show whoever is asking for a fourth language.

Real client stories

Situations from our own work. Details changed for privacy.

A Dubai services company with a Russian site nobody owned. The Russian version was built as part of a launch push and handed to nobody afterwards. Two years later it still carried the previous fee structure and a decommissioned phone number. A prospect quoted the old fee back at them during a negotiation and did not accept the correction. That conversation cost more than the translation ever had. We cut the Russian version back to a small, deliberately maintained set of pages with one named owner.

A free zone e-commerce brand with a one way hreflang set. Four languages, all correctly pointing back at English, and the English pages pointing at none of them. Because the annotations have to be reciprocal, the entire set was being ignored [2]. The team had assumed the tags worked because they could see them in the page source. Fixing the return links took an afternoon. Nobody had checked for eighteen months, because nothing on the site looked broken.

A UAE clinic redirecting visitors by IP. Visitors were sent automatically to a language version based on detected location, with no way back except editing the URL by hand. Residents whose location did not match their language were stuck, and the other versions were barely indexed, which is the crawl outcome Google's guidance warns about [1][3]. We replaced the redirect with a persistent switcher, the alternative Google recommends [1].

How SKIMBOX approaches multilingual sites

We usually start by talking you out of languages.

Not all of them. Just the ones you will not maintain. The first conversation is about your own analytics and sales records rather than a statistic, and it tends to end with a shorter list than the one we were handed.

After that the work is ordinary and specific. Choose a URL structure and commit to it [1]. Build hreflang as a reciprocal set, with x-default, in one placement method, and put a check in the release process so it stays that way [2]. Replace any automatic redirect with a visible switcher [1]. Make sure the body content is genuinely translated, not just the template [4]. Then name an owner for each language version, because a version with no owner goes stale.

If search visibility is the point, read our Google UAE ranking guide and our SEO cost guide before you commit budget, because a second language multiplies the search work as well as the content work.

Adding a second language to an existing site starts from around AED 2,500, and a focused business site build starts from around AED 3,500. These are our own figures, not a market survey. Final pricing depends on scope.

If you want this looked at properly, see our web development services or our content marketing services, or contact us.

References

[1] Google Search Central - Managing multi-regional and multilingual sites, covering the country code domain, subdomain and subdirectory trade offs, the locale signals Google uses, the guidance against automatic redirection, the unreliability of IP location analysis, and the recommendation to add hyperlinks to other language versions. developers.google.com [2] Google Search Central - Tell Google about localized versions of your page, covering what hreflang does, the reciprocity requirement, x-default, the three placement methods, and the common mistakes Google names. developers.google.com [3] Google Search Central - How Google crawls locale-adaptive pages, covering the crawl consequences of serving content by perceived locale and the requirement for consistent robots directives across locale variants. developers.google.com [4] Google Search Central - Consolidate duplicate URLs, covering duplicate content not being a spam violation and the rule that different language versions are duplicates only if the primary content is in the same language. developers.google.com [5] Google Search Central - Spam policies for Google Web Search, covering the scaled content abuse policy and its naming of automated transformations including translating. developers.google.com [6] Google Search Central - Translated results in Google Search, covering how Google translates result titles and snippets, its statement that it does not host translated pages, and the notranslate opt out. developers.google.com [7] W3C - Language tags in HTML and XML, covering the BCP 47 standard behind hreflang and lang attribute values and the recommendation to declare language on the html element. w3.org [8] The UAE Government Portal - Fact sheet, covering Arabic as the official language, the five languages with official status in the courts, the separately listed widely spoken languages, and Arabic and English signage. u.ae [9] Federal Competitiveness and Statistics Centre - the UAE's federal statistics authority, which we could not access directly while researching this article, and the reason no population or language usage figure appears here. fcsc.gov.ae [10] SKIMBOX - our own published pricing for website builds, Arabic subtitling and voiceover, video localisation, website migration and content production, and our own commercial figure for adding a second language to an existing site, 2026. skimbox.co

Frequently asked questions

  • Which languages should my UAE website publish in besides Arabic and English?

    There is no official percentage that answers this for you. The UAE government fact sheet does confirm that Chinese, English, French, Hindi and Russian carry official status in the courts alongside Arabic, and separately lists Bengali, Farsi, Malayalam, Turkish and Urdu as widely spoken. Treat that as a shortlist to test, not an answer. The decision itself comes from your own analytics, your enquiry records and your sales data, because those describe your buyers rather than the country.

  • Is there an official figure for what share of UAE residents speak Russian, Chinese, Hindi or Urdu?

    No. We could not find any UAE government body or statistics authority publishing a language usage percentage for the population. The government fact sheet names languages without attaching any share, ranking or headcount to them. Figures of that kind circulate widely online and almost none of them trace back to a primary source you can open. We are not quoting any of them here, and neither should your business case.

  • Which languages have official status in UAE courts?

    According to the UAE government fact sheet, five languages beyond Arabic have official status in the courts: Chinese, English, French, Hindi and Russian. That is a formal legal recognition published by the government. It is worth knowing because it is one of the few citable, official signals about which languages the state treats as significant. It is not a measure of population, market size or how many of your customers prefer that language.

  • Is Urdu an official language in the UAE?

    No. Arabic is the sole official language of the UAE. The government fact sheet lists Urdu among other widely spoken languages, alongside Bengali, Farsi, Malayalam and Turkish, but it does not carry the official court status that Chinese, English, French, Hindi and Russian have. For a website decision this distinction matters less than your own customer data, but it is worth getting right if you are writing a business case for someone senior.

  • How do I decide which language to add without a population statistic?

    Use the data you already own. Browser language in your analytics, the language of enquiries in your inbox and on WhatsApp, which segments convert and which stall, and what your sales team reports as a language barrier on calls. Then ask what a second language would actually change. If your buyer works in English all day, another version is a courtesy rather than a conversion lever. Revenue evidence beats country level statistics every time.

  • My competitors publish in English and Arabic only. Do I need a third language?

    That is a commercial question, not a technical one. Competitor coverage tells you what other people decided, not whether it worked. The better test is whether a specific group of your own buyers is stalling because of language, and whether you can keep a third version updated for years without it going stale. If you cannot commit to the maintenance, a third language will end up damaging trust rather than building it.

  • Should I add a language because a lot of tourists in Dubai speak it?

    Tourist volume and buyer volume are different questions. A visitor passing through the city is not the same as someone who enquires, books or purchases. A language earns its place when it maps to people who actually transact with your business. If your bookings data shows a segment converting despite a language gap, that is evidence. Foot traffic in the city, on its own, is not evidence of anything about your website.

  • Should each language live on its own domain, a subdomain or a folder on my main site?

    Google publishes the trade offs for all three. A country code domain gives clear geotargeting and makes server location irrelevant, but Google notes it is expensive, can have limited availability and sometimes carries strict requirements. A subdomain is easy to set up and allows different server locations, but users might not recognise the geotargeting from the URL alone. A subdirectory is easy to set up and low maintenance because it sits on the same host.

  • What is the simplest structure for a UAE multilingual site?

    For a business already running one domain, a subdirectory per language is usually the sensible default. It is the lowest maintenance pattern Google names, since it runs on the same host as your existing site and needs no new domain or hosting. It also inherits the domain you already have rather than starting a separate property that somebody has to remember to maintain. The trade off Google names is being limited to a single server location.

  • When does a subdomain make sense instead of a folder?

    When the technical situation genuinely differs, not just the content. Google flags subdomains as useful where you need a different server location or a separate technical setup for that language version. In practice that usually means a separate team, a separate content system, or a version of the site that is not simply a translation of the main one. If it is the same site in another language, a folder is easier to run.

  • Can I use a URL parameter like a lang query string instead of a proper folder?

    Google does not recommend URL parameters for language or region segmentation. Use a subdirectory, a subdomain or a country code domain instead. Parameters make it harder to declare clean localised versions, harder to keep hreflang annotations tidy, and harder for anyone to link to a specific language version reliably. It looks like the cheap option at build time and turns into the expensive one about a year later.

  • Will Google find my language versions on its own?

    Not reliably. Google states plainly that it does not vary the crawler it uses to discover locale variations of a single site, and that the site owner has to explicitly tell Google about any locale or language variation. Google also says that even without action it might still find alternate language versions, but that it is usually best to indicate your language or region specific pages explicitly. So treat discovery as your job, not as something that happens automatically.

  • What is hreflang and what does it actually do?

    It is an annotation that tells Google which of your pages are localised variations of the same content, so the right version can be served to the right searcher. It does not declare what language a page is written in. Google works the language out algorithmically from the content itself. Getting that distinction right matters, because teams often assume hreflang is a language label and then wonder why a badly translated page still ranks badly.

  • Does hreflang have to be reciprocal?

    Yes, and it is not optional. Google's stated rule is that if two pages do not both point to each other, the tags will be ignored. The reason Google gives is that otherwise anyone could arbitrarily tag their own page as an alternative version of yours. In practice every language version of a page must reference every other version, including itself. Miss one direction and the whole annotation set on that page can be disregarded.

  • What is x-default and do I need it?

    It is the reserved hreflang value used when none of your declared language or region versions match a visitor's browser setting. It usually points at a language selector page or at your default version, which for most UAE businesses is English. It is not strictly mandatory, but it is the mechanism Google provides for the none of the above case. Without it, visitors who match nothing you declared are handled entirely by Google's own judgement.

  • Where do hreflang annotations go?

    Google supports three equivalent placements: link elements in the page head, HTTP Link headers, which are useful for non HTML files such as PDFs, and entries inside an XML sitemap. Any of the three works. What causes problems is mixing them across a site, because sets end up half declared and nobody can see the full picture in one place. Pick one method, apply it everywhere, and document which one you chose.

  • What are the most common hreflang mistakes?

    Google names them directly: missing return links, incorrect language codes, and invalid region codes. On that last point, reserved codes such as EU, UN and UK are not valid, and the correct code for the United Kingdom is GB. In our own experience the missing return link is by far the most frequent, because the newest language version gets tagged correctly while the original English page, built earlier, never gets updated to point back.

  • What happens if my hreflang tags are broken?

    Google's stated behaviour is to ignore broken annotations rather than penalise the site. That sounds harmless and is not. The practical outcome is identical to having no hreflang at all, which means Google falls back on its own judgement about which version to serve to which searcher. For a business with several language versions of the same page, that judgement is frequently not the one you wanted for that market.

  • Is a language code like ru enough, or do I need ru-AE?

    Both are valid under BCP 47, the standard that hreflang and the HTML lang attribute follow. A language only code targets speakers of that language regardless of country. Adding a region subtag narrows it to that country. Only narrow when you genuinely have different content for different markets. Adding region subtags to identical content creates more annotations to keep reciprocal, which means more ways for the set to break later.

  • What standard do language codes follow?

    BCP 47, the specification behind language tags in HTML and XML. It is a superset that includes the familiar two letter codes plus optional region subtags. W3C also recommends always declaring the language on the html element of every page, which is separate from hreflang but part of the same discipline. Getting the tag right is cheap. Getting it wrong is one of the mistakes Google specifically names as a reason annotations fail.

  • Will Google treat four language versions of a page as duplicate content?

    No, provided the body content is genuinely in each language. Google's rule is specific: different language versions of a single page are considered duplicates only if the primary content is in the same language. Google also states that some duplicate content on a site is normal and is not a violation of its spam policies. So a properly translated page stands on its own rather than competing with its source page.

  • I translated my navigation and footer but left the body text in English. Is that a problem?

    Yes. Google's duplicate content rule turns on the primary content, not the template. If the body is still in the source language, the page is a duplicate of the original regardless of how much of the navigation and footer you translated. That is the exact mechanism that makes the translate the template shortcut fail. Those pages do not earn credit as distinct localised pages, so the effort produces very little.

  • Can I run my whole site through machine translation and publish it?

    Google's spam policies name automated translation directly. Under scaled content abuse, the policies list generating many pages through automated transformations, including synonymising and translating, as an example of content produced at scale without adding value. That is a named policy rather than a mild quality concern. Publishing unreviewed machine output across a large number of pages sits squarely inside it, which makes it a risk you are taking deliberately.

  • Is machine translation ever acceptable?

    Google's line is drawn at scale and review, not at the existence of the technology. Using machine translation as a first draft that a competent human then edits line by line is a different practice from publishing thousands of unreviewed pages. The practical test is whether a native reader of that language would notice. If the sentence rhythm and word order still belong to the source language, a human has not really been through it yet.

  • Google already translates search results. Does that replace building real language pages?

    No. Google can translate a result's title and snippet and let a user open a translated version of a page, but its own description is that opening a page through a translated result is no different from using Google Translate or in browser translation, and that it does not host translated pages. It is a convenience layer applied to your unchanged original. It does not give you a page that ranks in that language.

  • Can I opt out of Google's translated search results?

    Yes. Google provides a notranslate meta tag and an equivalent HTTP header for opting out on a per page basis. Whether you should is a separate question. If you have no localised version of a page, the machine translated view may still help a reader who would otherwise bounce. If you do have a proper localised version, the better fix is making sure that version is declared and discoverable rather than opting out.

  • Should my site auto-detect a visitor's browser language or IP and redirect them?

    No. Google's guidance is explicit: avoid automatically redirecting users from one language version of a site to a different language version. Google separately states that IP location analysis is difficult and generally not reliable, and that it may not be able to crawl variations of your site properly when content is served that way. It feels helpful to build and it causes both user and indexing problems that are hard to spot afterwards.

  • Why does auto-redirecting by location hurt search specifically?

    Because Googlebot's own crawl requests are not reliably localised. It does not consistently signal a matching language preference, and much of its crawling originates from one region. A site that redirects on perceived location can end up showing Google only one version of itself. The other language versions are then not just ranking poorly, they may never be discovered or indexed at all, which is a much harder problem to diagnose.

  • What should I use instead of an automatic redirect?

    Google's recommended alternative is direct: add hyperlinks to other language versions of a page so users can click to choose a different version. In practice that means a persistent, visible switcher on every page, not a pop-up that guesses and redirects. It also means the switcher should link to the equivalent page in the other language rather than dumping everyone on the homepage, which is a common and irritating shortcut.

  • Do robots rules need to match across every language version?

    Yes. Google's guidance on locale-adaptive pages states that robots directives must be applied consistently across every locale variant of a page. Blocking one language version while leaving another open creates crawl and indexing problems specific to multilingual sites. This is an easy one to get wrong during a phased rollout, when a new language sits behind a temporary block that somebody forgets to remove after launch.

  • What is the real ongoing cost of running a multilingual site?

    The translation of your existing pages is the one off part. The recurring part is that every future page, price change, campaign and post now has to be produced in every published language, or that content sits outside your multilingual set. That follows directly from the hreflang reciprocity requirement rather than being a separate rule. No official body publishes a content operations budget for it, so plan it as a process cost with a named owner.

  • Who should own keeping translated pages in sync?

    Somebody specific, by name, with time allocated. This is an operational decision rather than a search engine rule, so no official source prescribes a structure. The technical constraint that does apply is that ownership has to be continuous. A stale translated page is not only outdated content, it can also fall out of the hreflang relationship once the source page moves ahead of it, which removes it from the set entirely.

  • What typically goes wrong after a business adds a second or third language?

    Asymmetric maintenance. The main language keeps moving because that is where the business runs, while the added versions quietly stop being updated because nobody owns them. The visible damage is a customer reading last year's prices. The invisible damage is that new pages ship in one language only, so your newest and most commercial content sits outside the multilingual set that you paid to build.

  • What does it cost to add a second language to an existing UAE website?

    Our own figure is from around AED 2,500 for a focused site where the pages already exist and only the content and technical wiring are new. That is our commercial figure, not a market survey, because no government body or standards organisation publishes translation or localisation rates. The two things that move it most are page count and whether your current setup can hold multiple locales at all. Final pricing depends on scope.

  • Why would adding Russian or Hindi cost less than adding Arabic?

    Because Arabic's extra cost is driven mainly by right-to-left layout engineering rather than translation alone. Mirrored layouts, direction aware components and typography testing are build work, not writing work. Russian, Chinese and Hindi are left-to-right and do not need that rework, so the marginal cost sits closer to content production. Urdu is the exception worth flagging, since it is written right-to-left and carries a similar layout cost profile to Arabic.

  • Does adding languages force a website migration?

    Sometimes. If your current URLs cannot cleanly hold language paths, or the language versions were built on parameters or a separate system, adding languages properly means restructuring URLs. That is a migration, with redirects and search preservation work attached. Our own figure for a migration starts from around AED 5,000 and rises with content volume. Final pricing depends on scope. Check this before you commit to a language, not after the translation is delivered.

  • Should I add a language, or spend the same money on search in the languages I already have?

    Ask which one your evidence supports. A second language is worth it when a defined group of buyers is stalling because of language. Deeper search work in an existing language is usually the better bet when you already rank badly for terms your buyers use. Also remember that a second language multiplies your ongoing search work too, since keyword research, content and technical checks now happen twice.

  • How many languages is too many?

    More than you can keep current. There is no technical ceiling, only an operational one. A useful test is to take your last three months of website changes, multiply the work by the number of languages you are proposing, and ask who does that every month for the next three years. If the honest answer is nobody, publish fewer languages properly instead of many badly. The stale version costs you more than the missing one.

SKIMBOX Team

Tech Consultancy

Get fresh writing in your inbox

One email a fortnight. No filler.

By subscribing, you agree to our privacy policy.

Want us to build something?

We work with teams across MENA, UK, USA, and India to build products, run programs, and grow.

Get in touch

Continue reading