A language button can change the words in a navigation bar while leaving the service explanation, form, and confirmation in English. The site then looks bilingual from the homepage but becomes monolingual at the decision point. For a UAE business, the useful planning unit is a complete task path: discover the right service, understand its conditions, make an inquiry, and know what happens next in the chosen language.
Give each translated page a stable address
Google recommends separate URLs for each language version instead of showing a different version at one address according to cookies or browser settings. It also recommends hreflang annotations to connect equivalent pages, and warns that automatic location-based redirection may prevent crawlers from finding variations. These are discovery practices, not a promise of ranking. Google's multilingual-site guidance explains the tradeoff.
Start with a page map, not a translation spreadsheet. For each service or product page, record its English URL, Arabic URL, owner, status, and the next action it leads to. An English service page should link to its Arabic counterpart, not simply to the Arabic homepage. If a page has no genuine counterpart yet, leave the language link off that page or label the destination honestly. Translating only the template while leaving the main content English does not make a full Arabic version; Google's localized-version guidance distinguishes those cases.
hreflang relationships should be reciprocal and include each page itself. Google accepts HTML tags, HTTP headers, or a sitemap, and says using all three adds no Search benefit. Choose the method the team can maintain when pages change. Verify the actual URLs resolve and that their canonical tags do not accidentally point both languages to the English page. Google's localized-version documentation sets out these requirements.
Make the Arabic path usable, not merely translated
Set the page language in HTML and use right-to-left direction where appropriate. W3C internationalization guidance recommends a language attribute on the html element and a dir attribute for bidirectional text. These are implementation details that matter when a screen reader speaks the page or a form mixes Arabic with email addresses, phone numbers, or product codes.
Check prices, units, dates, availability, and service-area wording with a person who knows the offer. A polished translation of an obsolete promise is still an obsolete promise. Preserve the same substantive answer across languages, but do not force identical sentence structure. If the Arabic page says “request a quote,” the Arabic form and success message should carry that same action and tell the visitor when to expect a response.
Before launch, give two reviewers the same task in their preferred language: find the relevant service, identify a condition that could disqualify the purchase, and submit a test inquiry. Record where they leave the chosen language. Repeat on a phone. Then inspect a sample of page pairs and hreflang links after deployment; a correct launch checklist can drift as new pages are added.
For an ARCHV website brief, include the translated page inventory, copy ownership, language switching behavior, RTL review, metadata, form routing, and post-launch maintenance. ARCHV's website service page treats content, functions, QA, and technical scope as proposal items. A second language is a second content and QA responsibility, so ask for that scope explicitly in a website estimate.