Technical SEO for a bilingual Arabic–English website means making sure Google can crawl, index and serve the right language version to the right searcher. In 2026 that comes down to five things: a clean URL structure (usually subfolders such as /en/ and /ar/), reciprocal hreflang tags with an x-default, a self-referencing canonical on every language version, one XML sitemap per language, and a fast, properly mirrored right-to-left (RTL) layout. Get these right and your Arabic pages compete on their own instead of competing with your English pages.
What is technical SEO for a bilingual website?#
Bilingual technical SEO is the infrastructure layer of multilingual search: how URLs, tags, sitemaps and templates tell search engines which page is the Arabic version, which is the English version, and how they relate. A site can have excellent copy in both languages and still lose traffic because Arabic pages are canonicalised to English ones, hreflang points one way only, or the RTL template is slow on mobile.
One detail surprises many site owners: Google’s multilingual documentation states that Google determines a page’s language from its visible content and does not use code-level signals such as the lang attribute or the URL. You still need lang="ar" and dir="rtl" for browsers and screen readers, but Google judges the language your main content is actually written in.
URL structure: subfolders vs subdomains vs ccTLDs#
Google’s guide to managing multi-regional and multilingual sites compares the URL options. Applied to an Arabic–English site in 2026:
| Structure | Example | Strengths | Weaknesses | Best for |
|---|---|---|---|---|
| Subfolders | example.com/en/ and /ar/ | Easy setup, low maintenance, one host, shared domain authority | One server location; URL alone shows no country target | Most Jordan and GCC businesses with one brand in two languages |
| Subdomains | en.example.com, ar.example.com | Easy to separate; can run on different servers | Users may not know if “ar” means language or country | Groups running each language on a separate stack |
| Country domains (ccTLD) | example.jo, example.sa | Clear country signal | Higher cost, registry rules, one country per domain | Separate entities or prices per country |
| URL parameters | example.com/?lang=ar | None | Not recommended by Google | Avoid |
For a company selling the same services across Jordan, Saudi Arabia, the UAE and the wider Gulf, subfolders are usually the simplest and strongest choice, because the main split is language, not country. If you later need Saudi pricing in SAR, add a region folder such as /ar-sa/ and annotate it with hreflang.
Avoid automatic redirects based on IP or browser language. Google warns that Googlebot usually crawls from the USA without an Accept-Language header, so forced redirects can hide your Arabic pages. Use a language switcher that links each page to its exact counterpart.
hreflang: reciprocal tags and x-default#
hreflang is an annotation that tells Google which URLs are language or regional alternates of the same page. Google’s localized-versions documentation allows three equivalent methods: HTML <link> tags, HTTP headers or the XML sitemap. Pick the one easiest to maintain.
- Self-including: each language version must list itself as well as all other versions.
- Reciprocal: if two pages do not both point to each other, Google ignores the tags.
- Fully qualified: include
https://and the domain; relative paths are invalid. - Valid codes: language from ISO 639-1 (
ar,en), optional region from ISO 3166-1 Alpha-2 (ar-JO,ar-SA,en-AE). - x-default: the reserved fallback when no language matches the user’s settings, often the English page or a language selector.
<link rel="alternate" hreflang="en" href="https://example.com/en/seo/" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/%D8%B3%D9%8A%D9%88/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/seo/" />The same three lines appear on both the English and Arabic page. That symmetry is what makes the cluster valid.
Common hreflang errors#
- Missing return links, usually because the translation plugin never linked the two pages.
- Invalid codes such as
ar-AR(AR is Argentina) oren-UK(UK is a reserved code Google ignores; useGB). - Alternates that redirect, are noindexed or return 404. Every URL in the cluster should return 200.
- Mixing encoded and decoded Arabic URLs, so one page appears as two URLs.
Canonical tags per language#
Each language version needs a self-referencing canonical: the Arabic page points to itself, the English page to itself. Never point an Arabic page’s canonical at its English twin; that asks Google to drop the Arabic page from the index.
Google’s canonicalization documentation says language versions are considered duplicates only if the primary content is in the same language. If only the header, footer and menus are translated while the body stays English, the “Arabic” page may be treated as a duplicate. Translate the main content fully before publishing.
Arabic slugs vs Latin slugs#
A slug is the readable part of a URL that identifies a page. Google’s URL structure guidance recommends using words in your audience’s language and percent-encoding non-ASCII characters in links. Each Arabic letter is two bytes in UTF-8, so it becomes six characters when encoded: تصميم-الويب (11 characters) becomes a 61-character string.
| Factor | Arabic slug | Latin slug under /ar/ |
|---|---|---|
| Match with Arabic queries | Native and relevant | Different script from the page |
| Sharing on WhatsApp and email | Often pasted as long encoded strings | Short and clean |
| Redirects and analytics | Encoded and decoded forms must be handled consistently | Simple |
| CMS truncation | Long auto-generated slugs can be cut short | Rarely an issue |
Both can rank. Our default is manually written Arabic slugs of three to six words, hyphen-separated (Google prefers hyphens to underscores), without diacritics, and in one consistent encoded form across canonicals, hreflang and sitemaps. Choose once: changing slugs later is a migration.
RTL layout, Core Web Vitals and UX#
A correct Arabic template sets dir="rtl" and lang="ar" on <html>, mirrors navigation, sliders and directional icons, and keeps numbers, prices and Latin brand names readable inside Arabic text. CSS logical properties such as margin-inline-start let one stylesheet serve both directions.
The Arabic version is often slower, and fonts are the usual cause because Arabic web fonts carry many more glyphs. Google’s web.dev font guidance recommends WOFF2 (up to 30% better compression than WOFF), subsetting, preloading only the critical font with crossorigin, and choosing font-display carefully because swap can cause a visible layout shift. Measure each language against the Core Web Vitals thresholds that web.dev sets at the 75th percentile of page loads:
- LCP: 2.5 seconds or less.
- INP: 200 milliseconds or less.
- CLS: 0.1 or less.
For Jordan and Gulf audiences, also test the elements people tap most: WhatsApp buttons, click-to-call links and mixed Arabic–English forms. A sticky WhatsApp button that covers the mirrored mobile menu is a real UX bug.
Human vs machine translation#
Google does not ban machine translation, but it judges the result. Its scaled content abuse policy, introduced in March 2024, covers unoriginal content produced at scale through automated transformations, including translating, that provides little value to users. In June 2025 Google removed old advice to block auto-translated pages with robots.txt, and told Glenn Gabe its policies do not strictly define AI-translated content as spam.
The 2026 rule: machine translation is a first draft, not a finished page. A native Arabic editor should localise terminology, prices in JOD, SAR or AED, and examples for Jordanian and Gulf readers. If a page must go live before it is translated properly, add noindex to that page rather than blocking the whole language folder.
XML sitemaps per language#
Use a sitemap index pointing to sitemap-en.xml and sitemap-ar.xml, so Search Console shows Arabic submitted versus indexed URLs at a glance. Google’s limits are 50,000 URLs or 50MB uncompressed per file; files must be UTF-8 with escaped values, and Google uses <lastmod> only when it is consistently accurate. If hreflang lives in the sitemap, every <url> entry needs xhtml:link elements for all versions, including itself.
Search Console in 2026: no country targeting#
Google deprecated the legacy International Targeting report; Search Engine Land reported it went away on September 22, 2022. Google’s help page says country targeting is no longer supported, while Google continues to support and use hreflang. Your signals are now URL structure, hreflang, content and local relevance. Monitor instead:
- The Performance report filtered by pages containing /ar/ and by country.
- The Page indexing report for “Google chose different canonical than user”, a common sign of half-translated pages.
- URL Inspection on key Arabic URLs to confirm Google’s chosen canonical matches yours.
Our website audit and performance service checks all of this in both languages, our SEO team runs the Arabic and English keyword work, and our web design team builds RTL templates that stay fast on mobile.
If your Arabic pages are not showing up, or you are planning a bilingual site from scratch, Consult One in Amman can audit your hreflang, canonicals and RTL performance and hand you a prioritised fix list. Get a free quote.
FAQ#
Is it better to use subfolders or subdomains for an Arabic and English website?
For most businesses, subfolders such as example.com/en/ and example.com/ar/ are the better choice. Google describes them as easy to set up and low maintenance, and both languages share one domain’s authority. Subdomains suit teams running each language on a separate platform, while country-code domains suit separate legal entities or country-specific pricing.
Do I need x-default in my hreflang tags?
x-default is optional but recommended. It tells Google which page to show when a searcher’s language matches none of your versions, for example a French speaker in Dubai. On an Arabic–English site it usually points to the English page or a language selector. Include it on every page in the cluster so the annotations stay reciprocal.
Should the Arabic page have a canonical tag pointing to the English page?
No. Each language version should carry a self-referencing canonical. A canonical from Arabic to English asks Google to index only the English page. Google treats language versions as duplicates only when the main content is in the same language, so fully translated Arabic pages should stay independently indexable.
Are Arabic characters in URLs bad for SEO?
No. Google recommends using words in your audience’s language and percent-encoding non-ASCII characters in links, so Arabic slugs are valid and can match Arabic queries. The trade-offs are practical: encoded URLs look long when shared on WhatsApp or email, and redirects must handle encoded forms consistently. Keep Arabic slugs to three to six words.
Will Google penalise machine-translated Arabic content?
Translation itself is not spam, but Google’s scaled content abuse policy covers automated translation that adds little value for users. In 2025 Google said its policies do not strictly define AI-translated content as spam. The safe approach is to use machine translation as a draft and have a native Arabic editor localise terms, prices and examples before indexing.
Can I still set a target country in Google Search Console?
No. Google deprecated the International Targeting report and its country setting, which went away in September 2022, and says it continues to support hreflang. To reach a specific market today, rely on URL structure, hreflang, a country domain where justified and genuinely local content, then track results with the Performance report’s country filter.
