A buyer reads your English service page, finds a relevant project and decides to enquire. Then the form opens in Arabic, the error message is unclear, and the language switch sends them back to the home page. Your website has two languages. The customer’s journey does not.
An Arabic English bilingual website needs more than translated headings and a language button. It should explain your offer, establish confidence and let visitors complete the next step in the language they chose. That includes the small details: product options, form errors, confirmation messages and the person who receives the enquiry.
Before comparing development quotes, define the pages each audience needs, who writes and approves the copy, and what counts as a working bilingual delivery. Those decisions make the scope clearer and reduce surprises near launch.
Does your business need both languages now?
A second language is useful when it serves a real audience: Arabic-speaking customers and international partners, procurement teams with different working languages, or shoppers who need to compare products and order in either language.
It is less useful when the English version is added for appearance, nobody can review it, and your team cannot follow up on the enquiries it invites. In that situation, a strong Arabic launch with a planned expansion may be more useful than an incomplete English experience.
Answer four questions before commissioning the site:
- Who needs English: the customer, a purchasing manager, an investor or a partner?
- Do they need the same services and proof, or a different explanation of the business?
- Can the team respond and deliver in the language used to enquire?
- Who updates both versions when a service, policy or product changes?
You do not need identical customer groups. You need a clear reason for the second version and an owner for keeping it accurate.
Map the customer journey before counting translated pages
Start with the decisions a visitor must make: understand the offer, see relevant evidence, choose a service or product, and take action. Then map the pages that support those decisions.
A service business may need a home page, company information, priority service pages, selected projects and contact. A store adds categories, products, options, cart, checkout, account screens and policies. A page count alone does not describe that difference.
Use a paired-page inventory to make the scope reviewable:
| Part of the website | What to check in both languages |
|---|---|
| Service pages | Audience, deliverables, exclusions and the next step |
| Projects and case studies | The problem, your role, implementation and relevant evidence |
| Contact flow | Fields, validation, confirmation and request delivery |
| Navigation | Labels, destinations and equivalent-page switching |
| Store journey, if applicable | Product data, options, ordering, customer messages and policies |
This is a planning model, not a mandatory page list. You can phase the project, but record what is deferred. Do not label an untranslated page as a completed English version or send visitors to an empty destination.
Good bilingual copy communicates the same value—not the same sentence
“Innovative, integrated solutions” tells a buyer very little in either language. A useful service page explains what you do, who it is for, what the client receives and what happens next.
First make the original message specific. Then adapt it for the other audience. Keep product specifications, commitments and technical terminology accurate, while allowing sentence structure, length and calls to action to change naturally.
Agree the content responsibilities explicitly:
- Writing: will the business supply approved copy, or does the scope include developing the message from source materials?
- Translation: is reviewed translation included, or will the developer enter text supplied by the client?
- Approval: who signs off professional terminology, specifications and commercial promises?
- Maintenance: how will an editor know that one version has changed and the other needs review?
Machine translation can help with a draft. It is not approval of your policies, service claims or product information. A shorter, carefully reviewed page is more useful than a long version that reads like unedited output.
An Arc Vision decision: explain the relationship between the services
For Arc Vision’s bilingual engineering website, the content needed to connect six disciplines, including reality capture, BIM, design and fit-out. Listing the terms did not explain where a client should start or how the disciplines support one project.
I organised the experience around a journey from reality to delivery, supported by a six-stage methodology and project evidence. The Arabic and English versions preserve that sequence, with suitable writing and direction for each language and a clear route to start a project.
The lesson for a business website is simple: fix the explanation before translating it. If the original service structure is confusing, another language will reproduce the confusion. This is an implementation example, not a claim of measured growth in enquiries.
RTL and LTR need their own mobile checks
Arabic reads right to left; English reads left to right. Changing the page direction is a starting point, not a complete layout solution.
An English label may need more space than its Arabic equivalent. A phone number inside Arabic text may become difficult to read. A menu can look correct on a desktop while its translated buttons overlap on a phone.
Test the tasks in both versions:
- Open and close the mobile menu, then reach a priority service.
- Read long headings and use the main buttons without clipped text.
- Check phone numbers, email addresses, amounts and mixed-language terms.
- Trigger form errors and complete a valid submission.
- Switch language from a service or product and reach its counterpart, rather than restarting at the home page.
A second language does not require heavy animation libraries or unnecessary font downloads. Ask for appropriate image sizes, controlled font loading and page-level performance checks. A promised speed score is not a substitute for measured results under stated conditions.
A Raphia decision: the whole shopping journey belongs in the language scope
In Raphia’s bilingual WooCommerce coffee store, customers can discover coffee by category or brewing method, then choose grind and weight before ordering.
That means translation is not limited to brand storytelling. Product options, basket, account, shipping information, policies and customer-facing messages are part of the delivery too. A shopper should not have to guess what an option means because only the marketing pages were reviewed.
For your store, list the texts that help someone finish a task—not just the pages in the navigation. A one-line validation message can matter more at checkout than a long translated company history.
Multilingual SEO: what should the developer deliver?
A visitor being able to change the language does not necessarily mean search engines can discover both versions independently.
Google’s multilingual-site guidance recommends separate URLs for language versions, clearly identifiable page language and links that let people choose a version, rather than automatic redirects based on an assumed language.
Ask for the following in the implementation scope:
- Stable URLs for each published version, with a structure you can maintain.
- Search titles, descriptions and headings that fit each page’s actual content.
- Internal links to the correct published language pages and valid sitemap entries.
- Reviewed canonical signals so a fully translated page is not inadvertently consolidated into the other language.
hreflangannotations for genuine equivalent pages.
hreflang identifies the relationship; it does not translate the page or guarantee better rankings. Google’s localized-version documentation requires versions to list themselves and their counterparts with complete, reciprocal URLs. Do not advertise an English alternate before that page exists.
What changes the cost of a bilingual website?
There is no reliable universal percentage for “adding English.” Some work is shared, such as the component design and content system. Other work needs separate attention: copy, terminology, forms, metadata and testing each journey.
Cost depends on the paired-page inventory, content readiness, writing and translation responsibilities, service or product complexity, language-management requirements, any recurring licenses, and the agreed acceptance checks.
Compare quotes on those deliverables. Does “two languages” include reviewed content, product options, form messages, language SEO and editor training? Or only installing a translation plugin and entering supplied text?
For a Saudi WordPress scope, the WordPress website cost guide explains current service starting points and their limits. Those amounts are not the fees charged for Arc Vision or Raphia. Your project still needs an individual scope.
A launch checklist you can use with the delivery team
Before accepting the bilingual delivery:
- Approve the pages, copy and terminology, and record deferred content.
- Review priority pages, menus and buttons on a real phone in both directions.
- Change language from services, products and contact, checking the equivalent destinations.
- Submit a test request in each language and confirm receipt by the intended team.
- Review metadata, internal links, canonicals, language alternates and the sitemap.
- Confirm account ownership, editor access and who maintains both versions after handover.
Keep the observations and resolved issues. “Tested” should mean a visitor can complete the task, not only that both home pages look finished.
Frequently asked questions
Must every page be translated at launch?
Not necessarily. You can launch a defined set of pages that supports a complete journey in each language, then expand. Be explicit about deferred pages, and do not link users or search engines to nonexistent translations.
Do I need separate domains for Arabic and English?
No. A single domain with separate language URLs can support both. Choose a structure that fits the content system and long-term management; two domains are not a requirement.
Is translation enough for SEO?
No. Each version needs useful audience-appropriate content, clear headings and links, indexable pages and correctly connected language versions. Translation does not guarantee traffic or a particular ranking.
Can English be added to an existing Arabic website?
Yes, after reviewing the system, page structure and content. Protect existing URLs where possible, plan any migrations before changing them, and test the new pages, forms and language switching.
Bring the page list—not a vague request for “two languages”
You do not need every paragraph ready before the first conversation. Send the business type, audiences, required languages, priority pages and the content you already have. For an existing website, include its URL and what you want to improve.
Use the website project brief template to organise those details. Through my website design and development service, we can turn them into a clear scope with content responsibilities, editable sections and launch checks agreed before implementation.
