Bilingual SEO for Saudi Arabia: Arabic and English Search Strategy
- Arabic and English search demand are different journeys, not two copies of one keyword list.
- Each language needs its own titles, URLs, content and internal links, written natively.
- hreflang and self-canonicals tell Google which page is which; they do not replace useful content.
- Measure rankings, traffic and enquiries by language, or you will optimise the wrong version.
Saudi customers search in Arabic, in English, and often in a mix of both. A company that publishes one English site and then pastes a translation under /ar/ has not built bilingual SEO. It has built a duplicate with a language label. This guide is the operating version: how to research, structure, write and measure Arabic and English search as two connected journeys that still point to one business.
What bilingual SEO is (and is not)
Bilingual SEO means each language has pages that a speaker of that language would actually use: native wording, native examples, and a conversion path that matches how that audience buys. It is not a plugin that “adds Arabic.” It is not hreflang on thin translated templates. And it is not ranking one English page for Arabic queries because the logo happens to be in Arabic.
Google’s own guidance on multi-regional and multilingual sites is the baseline: give each language a clear URL, keep content in that language, and use hreflang so the right version can be served. The rest of this article is how that plays out for a Saudi business whose customers switch languages mid-journey.
Map demand in each language separately
Start with the jobs customers hire you to do — “find a clinic in Riyadh,” “compare two software vendors,” “book a fit-out contractor” — then collect the queries people type for each job in Arabic and in English. Do not translate the English list. Arabic searchers use different nouns, different levels of formality, transliterations of English brand and product names, and spelling variants (ة/ه, ى/ي, hamza forms). English searchers in Saudi Arabia often use city and country modifiers (“Riyadh,” “KSA,” “Saudi Arabia”) that Arabic queries may omit because the location is assumed.
A practical research pass:
- Seed Arabic terms from sales calls, WhatsApp enquiries and the words on your invoices, not from an English glossary.
- Seed English terms from how expatriate and bilingual buyers describe the same job.
- Group by intent (learn / compare / buy), not by department (SEO / ads / content).
- Note mixed queries: Arabic sentence with an English product name, or English query with an Arabic place name.
If one language has almost no queries for a topic, do not invent a page to “complete the pair.” Empty locale pages drag quality down. Google’s international SEO notes that thin translated locales are a site-wide risk, not a local one.
Choose a URL pattern and stick to it
For a single Saudi site, subfolders are the usual pattern: English at the root or /en/, Arabic at /ar/. Subdomains and separate country domains add operational cost without helping a company that serves one market in two languages. Pick one host (www or non-www), HTTPS, trailing-slash rule, and lowercase paths, then apply the same rule to both languages so canonicals, hreflang and the sitemap agree.
Avoid:
- Language as a query parameter (?lang=ar).
- Serving different languages at the same URL based on IP or Accept-Language — Googlebot mostly crawls from the US without that header.
- Arabic pages whose canonical points at the English page. That tells Google to drop the Arabic URL.
Write native pages, then connect them
Each URL should answer the query in that language in the first paragraph, then go deep enough that a careful buyer does not need a second tab. Arabic pages need Arabic headings, Arabic examples, and CTAs that match how Saudi buyers actually contact a vendor (form, email, WhatsApp — whichever you really offer). English pages should not assume the reader is outside the Kingdom; they are often Riyadh-based buyers who work in English.
Transcreation, not translation: rebuild the argument. An English heading that plays on a pun will not survive a literal Arabic pass. A Saudi regulation, a local payment method, or a city-level proof point may belong on the Arabic page even if the English page talks about process.
Then link the pair with hreflang annotations that include a self-reference, the other language, and x-default (usually the English page for a bilingual Saudi site). Reciprocal tags are required: if English points at Arabic, Arabic must point back. Put the same cluster in the HTML head; if you also annotate the sitemap, the two lists must match.
Technical checks that actually affect indexing
| Check | What “good” looks like |
|---|---|
| html lang | en-SA on English pages, ar-SA on Arabic pages |
| Canonical | Self-canonical on each language URL; never cross-locale |
| hreflang | en, ar, x-default; all return 200; all are indexable |
| Sitemap | Only canonical, indexable URLs; lastmod is real |
| Internal links | Arabic nav stays in Arabic; English nav stays in English; language switcher is a crawlable link, not JavaScript-only |
| Titles and H1s | Unique per URL; primary phrase near the start; no leftover quotes or truncated sentences |
Core Web Vitals, mobile layout and RTL rendering are part of SEO here. An Arabic page that clips type, mirrors icons incorrectly, or loads a 600 KB hero will lose both users and crawl budget. Treat RTL as a design requirement, not a CSS flip.
On-page pattern that search and answer engines can use
Lead with a 40–60 word answer. Use H2s that match how people ask (“How do hreflang tags work on a Saudi site?”). Put comparison points in a table. Add an FAQ only for questions the page already answers in prose. Mark the FAQ up with FAQPage JSON-LD that matches the visible text. Do not stuff the same paragraph onto fifty URLs — that is the scaled-content pattern Google already discounts.
Measure each language as its own channel
In Search Console, filter by page prefix (/ar/ vs the rest) and by query language. A blended average hides a healthy English blog and a failing Arabic service page, or the reverse. Track:
- Impressions and average position for the money queries in each language.
- Which URL Google actually ranks (service page vs article vs homepage).
- Enquiries that started on an Arabic URL versus an English URL, using first-touch landing data.
If a blog post ranks for a commercial query that a service page should own, the fix is not to noindex the post. Strengthen the service page’s title, H1 and first paragraph, and add a clear link from the article to that page.
A 90-day sequence that does not require a redesign
- Inventory every indexable URL. Mark language, canonical, hreflang, and whether the body is native or translated.
- Hold out thin translated templates (noindex, follow) until they are rewritten. Leaving them in the sitemap trains Google that the domain publishes duplicates.
- Fix host, slash, and hreflang errors on the URLs you keep.
- Rewrite or create the money pages first: the service pages that match how buyers search in each language.
- Only then add supporting guides, one topic at a time, with unique evidence and sources.
How Eclipse uses this on client work
Eclipse runs SEO as part of digital marketing in Saudi Arabia, with Arabic and English pages planned together. If you already have a bilingual site, the first conversation is usually an inventory of what Google is actually ranking, not a new brand film. Send the current URLs, Search Console access if you have it, and the enquiries you want more of.
Frequently asked questions
Should every English page have an Arabic twin?
Only when there is real search demand and you can write a native Arabic page. Empty or machine-translated twins hurt the whole site.
Is hreflang enough for bilingual SEO?
No. hreflang tells Google which URL is which language. Rankings still depend on native content, internal links, and whether the page answers the query.
Can one URL serve both languages with a toggle?
No. Each language needs its own indexable URL. A toggle that rewrites the same address hides one version from Googlebot.
Sources: developers.google.com · developers.google.com · developers.google.com