- Give each language its own crawlable URL with real, human quality content. Do not rely on a script that swaps text in the browser.
- Google documents hreflang as a way to tell it about language versions. It says nothing about AI answers, so treat it as good hygiene, not a GEO lever.
- We cannot say how any specific engine performs in Arabic without a fresh test of your own prompts, so test in both languages and record the results.
Why bilingual sites need their own GEO plan
A buyer in Dubai or Riyadh might ask an AI tool for a supplier in English on Monday and in Arabic on Tuesday. They might also mix both in one question. If your brand is clear in only one language, you are invisible to half of those moments, or worse, described by an engine using a thin or machine translated page.
Bilingual GEO is the work of making each language version of your site readable, accurate and consistent, and making sure both versions describe the same company with the same facts. The base principles of generative engine optimization still apply. Crawlers must reach the pages, the answers must be clear and the facts must agree. Language adds a few extra ways to get these wrong.
One caution before we go on. This is a fast moving area, and public evidence on how individual AI engines treat Arabic content is thin. We will not claim that one engine is better or worse in Arabic. What follows is technical hygiene and content practice that is documented or follows from how crawlers read the web. For market context, see our post on how buyers use AI search in the UAE.
Give every language its own URL
The first rule is structural. Each language should live at its own address that a crawler can request directly. Common patterns are a subfolder such as /ar/ for Arabic, a subdomain, or a separate country domain. Google's documentation on multilingual and multi regional sites says all three can work, and each has trade offs in cost, setup and maintenance. For most single brand sites, subfolders are the simplest to run.
Avoid setups where one URL changes language based on a cookie, a browser setting or a button that runs JavaScript. A crawler that does not carry your cookie will usually see only the default language. Also avoid automatic redirects that send visitors, and crawlers, to a language they did not request. Offer a visible language switcher that links to the other version instead.
- Serve the full text of each language in the HTML response, not only after a script runs. Our post on GEO for JavaScript and headless sites explains why.
- Keep titles, headings, body text, image text alternatives and schema in the page language.
- Make sure robots.txt and any firewall rules treat both language folders the same way.
- List both language sets in your XML sitemap.
Give every language its own address
- ✓Each language has its own crawlable URL
- ✓Full text of each language is in the HTML response
- ✓Both language folders get the same robots and firewall treatment
- ✓Both language sets are listed in the XML sitemap
- Language set by a cookie or script
- Automatic redirects by browser language
Which URL structure should an Arabic and English site use?
Quick answer: for most single brand businesses, subfolders on one domain are the simplest to run and keep consistent. The table sets out the trade offs. Pick the structure your team can maintain for years, not the one that sounds most impressive.
| Structure | Example pattern | Choose it if | Watch out for |
|---|---|---|---|
| Subfolder | example.com/ar/ | You have one brand and one team, and want simple setup | Both folders need the same technical treatment |
| Subdomain | ar.example.com | A separate team or platform runs the Arabic site | Treated as a separate property for robots rules and verification |
| Country domain | example.ae and example.co.uk | You have real local operations and teams in each market | Highest cost; each domain needs its own setup and upkeep |
| Cookie or parameter based | One URL that switches language | Avoid it | Crawlers may see only one language |
Language and country are different things. A Gulf company may write Arabic for readers in several countries, and English for readers in the same country. If you target several regions, decide whether you truly need separate pages per country or one Arabic page that serves all. Do not create near identical pages only to hold a different address.
Subfolder
example.com/ar/
- Simple for one brand and one team
- Both folders need the same technical treatment
Subdomain
ar.example.com
- Fits a separate team or platform
- Separate property for robots rules
Country domain
example.ae and example.co.uk
- Real local operations in each market
- Highest cost and upkeep
Switching URL
One URL that changes language
- Avoid it
- Crawlers may see one language only
How to implement hreflang correctly, step by step
- List every page that exists in both languages as a pair. Pages that exist in only one language get no alternate.
- For each pair choose one method: tags in the HTML head, HTTP headers, or the XML sitemap. Google says they are equivalent, so use the one your platform handles best.
- Write each annotation with the language code, for example en for English and ar for Arabic, and add a region code only when you need it.
- Make the annotations reciprocal. The English page lists itself and the Arabic page. The Arabic page lists itself and the English page.
- Use fully qualified URLs, including https, that match the canonical address of each page.
- Decide whether to add an x default entry for a language selector or fallback page.
- Crawl the site and check for missing return links, wrong codes and annotations pointing to redirected or noindexed pages.
Most hreflang errors come from pages that point to a version that redirects, is blocked, or has a different canonical. Check that the canonical tag on each page points to itself, not to the other language. If you canonicalise the Arabic page to the English one, you tell Google to ignore the Arabic version.
What hreflang does, per Google's documentation
Hreflang is an annotation that tells a search engine which URLs are alternate versions of the same page for different languages or regions. We checked Google's current Search Central page on localized versions of your pages in October 2026. Here is what it documents.
| Topic | |
|---|---|
| Methods | You can declare alternates in the HTML head, in an HTTP Link header, or in an XML sitemap. Google says the three are equivalent, and using more than one adds no benefit. |
| Return links | Each version should list itself and every other version. If page A points to page B and B does not point back, the annotations may be ignored. |
| Full URLs | Alternate URLs should be fully qualified, including https. They can sit on different domains. |
| Fallback value | The x default value marks a fallback page, for example a language selector or an auto redirecting home page, for users whose language does not match any version. |
| Codes | A language code uses the ISO 639 standard, with an optional region code from the ISO 3166 standard. A region code on its own is not valid. Some codes you may expect to work are not recognised. |
| Language detection | Google says it does not use hreflang or the HTML lang attribute to detect the language of a page. It uses its own systems for that. |
Notice what is missing. The page covers Google Search. It does not say that hreflang affects AI Overviews or AI Mode, and it does not mention ChatGPT, Perplexity or other engines. Anyone who says hreflang gets you cited in Arabic AI answers is going beyond the documentation. Still, hreflang helps keep language versions from being treated as duplicates and helps Google show the right one in classic results, and AI features in Google build on that index. That is a reason to do it. It is not a promise of anything.
Documented for Google Search
- HTML head, HTTP header or sitemap
- Each version lists itself and the others
- Keeps versions from being treated as duplicates
Not documented
- Any effect on AI Overviews or AI Mode
- Any AI engine reading hreflang
- Citations in Arabic AI answers
Arabic specific points that affect GEO
The following are practical observations about writing and building Arabic pages. They are not statements about how any engine treats Arabic, which we cannot source.
- Choose the register on purpose. Modern Standard Arabic is the usual choice for formal business pages, while people may phrase spoken questions in a regional dialect. Test which words your buyers use and let the headings reflect real phrasing, while the body stays clear and consistent.
- Decide how you handle numbers. Arabic text can use different numeral styles. Pick one for prices, dates and phone numbers and use it consistently, so the same figure is not written three ways.
- Mark the language and direction. Set the lang attribute and the right to left direction on Arabic pages. This helps browsers and assistive tools, and keeps layouts correct.
- Watch mixed text. Brand names, product codes and numbers in English inside Arabic sentences can display in the wrong order if direction is not handled. Test real pages.
- Keep structured data in the page language. Schema.org has an inLanguage property, and names and descriptions should be in the language of the page.
- Do not rely on images of text. Arabic text inside a banner image cannot be read as text. Put prices, offers and key claims in the HTML.
- Consider transliteration. Some people type Arabic words in Latin letters when searching. If that is true of your buyers, make sure your English pages mention the common transliterated name of your brand or service where it is natural.
Search and AI tools handle language in ways that vary and change. What stays constant is the value of a clear page that states who you are and what you do in the words the reader uses.
Worked example: a Dubai property consultancy
Example, hypothetical: a property consultancy in Dubai sells to international investors in English and to regional buyers in Arabic. Its Arabic pages were produced by running the English text through machine translation and publishing it. A baseline in both languages produces three findings.
| Finding | Likely reason | Fix |
|---|---|---|
| English prompts name the firm; Arabic prompts do not | Arabic pages read as literal translation and lack the terms buyers use | Have a native speaking property writer rewrite the key pages; research real Arabic prompts |
| The Arabic brand name appears in two spellings | Different staff transliterated it differently | Choose one, write it in the entity sheet, update every page and profile |
| Licence number is on the English page only | Compliance text was not copied across | Add the same licence details to the Arabic pages |
| Arabic page canonical points to English | Template error | Set each canonical to the page itself and fix hreflang |
None of the fixes require guessing how an engine treats Arabic. They remove inconsistency and errors that any engine could trip over. Real estate has specific needs too, covered on our GEO for real estate page.
Write both languages as originals
AI engines answer from text. If the Arabic page is a literal translation of the English page, it may read awkwardly, miss the terms buyers really use, and fail to answer the questions people ask in Arabic. The same is true in reverse. Have a native speaker who knows your industry write or edit each version.
That does not mean two different businesses. It means each page should answer the buyer's question in natural wording for that language, while the facts stay identical. Pricing model, service areas, licences, contact details and company description should match across versions. A mismatch gives an engine two conflicting statements to choose from.
- Research prompts in each language. The words buyers type in Arabic often differ from a translation of your English keywords, and dialect can matter in how people phrase a question.
- Use headings written as the actual question in that language, with a direct answer underneath. See how to write content AI engines cite.
- Put the company name in both scripts where people use both. Decide on one Arabic spelling of your brand and use it everywhere.
- Add FAQs that answer real questions asked by customers in each language.
An entity sheet you can copy
A short table that every team and agency uses removes most spelling and wording drift. Fill in the right hand columns and store the sheet where editors can find it.
| Field | English | Arabic |
|---|---|---|
| Registered business name | [as on the licence] | [as on the licence] |
| Brand name as customers write it | [spelling] | [spelling] |
| One sentence description | [text] | [text] |
| Services list | [list in approved wording] | [list in approved wording] |
| Address and areas served | [address] | [address in Arabic format] |
| Phone, email, opening hours | [details] | [same details] |
| Licence or registration numbers | [numbers] | [same numbers] |
| Official profiles | [URLs] | [URLs] |
Do not translate legal names unless the registration allows it. If a name exists in both scripts on the licence, use that.
- Registered nameAs on the licence
- Brand nameThe spelling customers write
- DescriptionOne sentence in each language
- Services listIn approved wording
- Address and areasAddress in Arabic format too
Keep your entity consistent across languages
An engine builds a picture of your company from many pages. When the name, address, description and services appear in two languages, the picture should still be one company. The risk is variation: three different Arabic spellings of the brand, a transliteration that differs from your registered English name, or a description that exaggerates in one language and is modest in the other.
Write a short entity sheet that lists the English name, the approved Arabic name, the one line description in each language, address, phone, licence details where relevant and links to official profiles. Use it for the site, directories and profiles. Our guide to entity consistency for GEO goes deeper. Structured data should use the correct language for each page, and the organisation markup should point to the same official profiles in both versions.
Text direction also matters for usability. Arabic reads right to left, and layouts, tables and mixed text with English product names or numbers can break. Test both versions in a browser. Broken layout will not by itself stop an engine reading text, but it can hurt the people who arrive.
Common mistakes on bilingual sites
| Mistake | Why it hurts | Fix |
|---|---|---|
| Machine translated Arabic published as is | It can be awkward and miss buyer wording | Use a native writer or editor |
| Language set by cookie or script | Crawlers may see one language only | Give each language its own URL |
| Redirecting visitors by location or browser language | Crawlers and users may never reach the other version | Offer a visible switcher instead |
| Hreflang without return links | Annotations may be ignored | Make every pair reciprocal |
| Only the English side tested | Arabic gaps stay hidden | Run matching prompt sets in both languages |
| Different facts in each language | Engines get conflicting statements | Use one entity sheet |
| Blocking one folder in robots.txt | One language disappears from crawlers | Treat both folders alike unless there is a reason |
A 30 day plan for a bilingual site
- Week 1. Inventory language versions. Check robots.txt, firewall rules, canonicals and hreflang. Build two prompt sets and record the baseline in each language.
- Week 2. Fix structure: separate URLs, reciprocal hreflang, sitemap entries for both languages, correct canonicals.
- Week 3. Write the entity sheet. Rework the top five pages in each language with direct answers and question headings, written or reviewed by native speakers.
- Week 4. Rerun both prompt sets. Compare with the baseline and decide where to invest next.
A bilingual site is two jobs. The GEO Pilot covers one language, so we usually start with the one that carries most of your buyers and quote the second as ongoing work. For a market view, see our GEO agency in Dubai page, and use the GEO checklist to run the technical checks in either language.
Test in both languages and record the limits
Measurement is where bilingual work usually falls short. Teams test in English, see a result and assume the Arabic side works. It may not.
Build two prompt sets with the same intent, one per language. Run each on the engines that matter to your buyers and record whether your brand is mentioned, whether it is cited with a link, and whether the facts are correct. Repeat on later dates, because answers vary. Be careful when comparing: a gap between the English and Arabic sets might reflect the engine, your content, the way the prompt was phrased or plain variation. A single run cannot tell these apart.
| Check | English set | Arabic set |
|---|---|---|
| Prompts tested | [number] | [number] |
| Brand named in answer | [count] | [count] |
| Brand cited with link | [count] | [count] |
| Facts correct | [count] | [count] |
| Date and engine of run | [date, engine] | [date, engine] |
Fill the table with your own results. We have not published figures here because we have no sourced data on how specific engines perform in Arabic, and we would rather leave the cells empty than invent them. The prompt method is covered in how to research buyer prompts, and you can run a first check with the AI Visibility Checker.
What to do next
Start small. Confirm that each language has its own crawlable URL, that robots.txt allows the AI crawlers you want, and that hreflang is correct and reciprocal. Write an entity sheet. Then pick your ten most important buyer questions and make sure each has a strong, original answer page in the language your buyers use.
If you would like us to do that work, the GEO Pilot is a fixed price $999 USD, delivered inside 30 days, for one domain and one language. For a bilingual site that means choosing one language for the Pilot, and we can quote the second as ongoing work. It does not include a new site build, link building or paid media, and we do not promise rankings, citations or traffic.




