Arabic and English Website Structure: How to Build a Bilingual Site Google Understands

For most Kuwait businesses, the best bilingual website structure is one domain with a subfolder for each language, such as example.com/ar/ and example.com/en/. Google's guidance on multilingual sites, last updated on 10 December 2025, treats subfolders, subdomains and country domains as workable options and advises against URL parameters like ?lang=ar. A subfolder is a directory inside the same domain, so both languages share one site, one hosting setup and one Search Console property.

Google lists the trade-offs plainly. Subfolders are easy to set up and cheap to maintain. Subdomains such as ar.example.com are also easy to set up, but Google notes that users may not read the targeting from the URL alone. Country domains give the clearest geographic signal but cost more to run. Shopify's help centre recommends subfolders for most stores too, noting that they share authority with the main domain and need no extra registration.

In Kuwait, the country-domain question is about country, not language. A .com.kw address tells Google and customers that the site is for Kuwait; it says nothing about Arabic or English. The trouble starts when languages are split across domains, with English on a .com and Arabic on a .com.kw. That doubles renewals, analytics setups and Search Console work, and it divides the links people give you between two sites when both languages could be building one.

Parameters and cookies fail for a specific reason. Google's page on locale-adaptive pages says Googlebot sends requests without an Accept-Language header, by default from IP addresses that appear to be in the USA. A site that serves Arabic or English at the same URL depending on a cookie or the browser's language will usually show Google only one version, and the other may never be indexed. Give each language its own URL, and decide deliberately which language sits at the root.

Hreflang is markup that tells Google which URLs are language or regional versions of the same page. Google's guide to localized versions, last updated on 22 December 2025, accepts it in three places: link tags in the page head, HTTP headers or the XML sitemap. Pick one method and use it everywhere. On a two-language page, the head then carries three lines: one for the Arabic URL, one for the English URL and one for x-default, each with the full https address.

Every version must list itself and every other version, and Google says that if two pages don't point to each other, the tags are ignored. So the Arabic page names both itself and the English page, and the English page does the same. Codes use a two-letter ISO 639-1 language, optionally followed by an ISO 3166-1 region: ar, en, ar-KW and en-KW are all valid, while KW on its own is not, because a region can't be given without a language.

Plain language codes or regional ones? If the site serves Kuwait only, ar-KW and en-KW describe it exactly. If Arabic readers in Saudi Arabia or the UAE should land on the same Arabic page, a plain ar code covers every Arabic reader without naming a country. x-default is the reserved value Google describes as the fallback for users whose language settings match none of your versions; point it at the language most of your visitors read, or at a language selector page.

Hreflang breaks quietly in a few familiar ways. The alternate URL redirects, carries noindex or has its canonical pointing elsewhere. The Arabic page's canonical names the English page, when Google's canonical guidance says to specify one in the same language. Or tags in the head and the sitemap disagree. Google also notes that translated pages count as duplicates only when the main content stays untranslated. After any change, recheck the pages with the steps in the SEO audit checklist.

Google's multilingual guidance says to avoid automatically redirecting people from one language version to another based on the language you assume they prefer, because it can stop both users and search engines reaching every version. In Kuwait the assumption is weak anyway: a phone's interface language says little about the language someone wants to read a product page or a clinic's price list in, in a market where many people move between Arabic and English all day.

Platforms can redirect for you, so check the setting. Shopify's help centre says its automatic redirection uses the customer's IP address and browser language, and that search engine crawlers are excluded, with the caveat that only known search engine crawlers are. If you keep a redirect switched on, test how your site responds to other bots as well. A softer pattern is a small banner offering the other language, which leaves the visitor on the page they actually asked for.

The language switcher itself should be a visible link in the header of every page, labelled with each language's name in its own script, العربية and English, rather than with a flag, since flags stand for countries and Kuwait has two languages under one flag. It should lead to the equivalent page in the other language, not the home page. Google's guidance suggests exactly this: linking each page to its other language versions so people can choose.

Build the switcher from real links, because Google's ecommerce guidance asks for standard anchor links with an href rather than JavaScript events on other elements. A switcher that swaps the text with JavaScript at the same URL hides the second language from crawlers entirely. Remember the visitor's choice with a cookie if you like, but never let that cookie override a URL someone opened on purpose, such as an Arabic link sent on WhatsApp to someone whose browser is in English.

RTL, short for right to left, is the direction Arabic is written in, and it belongs in the markup rather than the styling. The W3C's internationalisation guidance says to put dir="rtl" on the html element of an Arabic page and not to use CSS for base direction, so the direction holds even if the stylesheet fails to load. The lang attribute is separate: lang="ar" names the language but does not set direction, so an Arabic page needs both.

Mirroring means the whole layout flips, not just the text. Navigation starts from the right, back arrows point right, progress steps and carousels run right to left, and the cart drawer opens from the matching side. The W3C recommends logical CSS properties such as margin-inline-start and text-align: start, which follow the direction automatically, so one stylesheet can serve both languages. Logos, product photos, video play buttons and phone numbers stay as they are.

Numbers and Latin words inside Arabic sentences are where RTL pages most often look broken. The W3C notes that problems appear when an opposite-direction phrase starts or ends with a number or punctuation, which is exactly what a product line with an English brand, a model number and a KD price to three decimals contains, or a +965 phone number. Its advice is to wrap each opposite-direction phrase tightly in an element with a dir attribute, or in a bdi element for text pulled from a database.

Text that customers type needs the same care. Reviews, names and delivery addresses in Kuwait arrive in both scripts, so set dir="auto" on inputs and on the elements that display them, which the W3C describes as taking direction from the first strongly directional character. Then check mixed product titles on a phone, where line wrapping exposes most direction mistakes. The theme side of this, from fonts to the checkout, is in the Arabic RTL Shopify setup guide.

A bilingual site has three choices for Arabic URL slugs: translated Arabic words, Arabic transliterated into Latin letters, or the same English slug under the Arabic folder. Google's URL structure guidance, last updated on 10 December 2025, recommends words in your audience's language, gives an Arabic example, and says links in href attributes should be percent-encoded where needed. So /ar/عبايات is a valid address, but in the code it becomes a long run of percent signs and letter codes.

Each choice has a cost. Arabic slugs read naturally in the address bar but can paste as that encoded string into WhatsApp messages, Instagram bios and analytics reports, where nobody can read them. Transliterated slugs such as abayat help neither reader and invite spelling drift. English slugs under /ar/ are the easiest to maintain and to pair with their English twin. Google says it works out a page's language from the visible content, not the URL, so the slug doesn't decide the language either way.

Pick one rule and apply it everywhere, because changing slugs later means redirects, updated hreflang and updated sitemaps. On Shopify, the help centre says automatic translation skips URL handles, translated handles are added by hand in Translate & Adapt, redirects are created from the default-language URL, and the word products stays in English. A Kuwait store that shares most of its links through WhatsApp and Instagram may get more from short, readable English slugs than from Arabic ones.

One language per page is the other rule. Google determines language from visible content and warns that side-by-side translations make a poor experience when the same content keeps appearing in results. So an Arabic page should be Arabic throughout: menu, buttons, footer, form labels, error messages and image alt text, with only brand names and model numbers left in Latin letters. A page that mixes both languages evenly gives Google no clear answer. Writing the Arabic itself well is covered in Arabic SEO in Kuwait.

Answer engines need each language version to be a complete, indexable page in its own right. An answer engine is a search tool that replies with a written answer and cites its sources, such as Google's AI Overviews or ChatGPT search. Google's page on AI features, last updated on 10 December 2025, lists no extra requirements: a page must be indexed and eligible to show with a snippet. An Arabic page that is noindexed, canonicalised to English or loaded only after a click is out before any AI reads it.

Other assistants run their own crawlers. OpenAI's documentation says sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers, and that robots.txt changes take about 24 hours to register. Check that your robots.txt doesn't block it by accident, and that both the /ar/ and /en/ folders are open to it. A language folder shut by an old rule is invisible to that assistant, however good the writing inside it is.

Near-duplicates are the subtler problem. Bing's webmaster blog said in December 2025 that AI systems tend to group near-identical URLs and pick one page to represent the group, which may not be the version you want, and that localised pages count as duplicates when they differ in nothing meaningful. Hreflang helps, and so does substance: an Arabic page that uses the words Kuwaiti customers use, with local examples and prices in KD, is plainly a page of its own.

The last requirement is parity of facts. When an assistant answers an Arabic question, it should find the same prices, delivery areas, opening hours and policies on the Arabic page as on the English one. It is easy to update the English page and forget its Arabic twin, so a customer reads last year's price in Arabic. Keep one checklist per update that covers both versions. How assistants choose what to cite is covered in getting cited by AI answer engines.