Arabic URLs vs Transliteration: Which to Use
Arabic-script slugs, transliterated slugs or English slugs on your Arabic pages — how each behaves in search, sharing and analytics, and how to pick one.
Arabic pages can use Arabic-script slugs, transliterated Latin-letter slugs, or English slugs — Google indexes all three correctly when properly encoded, so none is a ranking mistake on its own. The real trade-off is practical: Arabic slugs match the page's language but turn into long encoded strings when shared; transliterated slugs stay short and portable but read as less native.
This decision is a small piece of Arabic SEO on its own, but it's one of the few technical choices that's expensive to reverse once a site has published at volume.
On this page
What's actually at stake in the URL — Arabic script or Latin letters?
Less than it might seem for rankings, and more than it might seem for everyday usability. Google explicitly supports readable URLs in any properly encoded script, so an Arabic-script URL is not a ranking advantage over a transliterated one on its own [1].
What differs is how the URL behaves outside the search results page: how it looks when a reader glances at the address bar, how it survives being copied into WhatsApp or an email, and how easy it is for your own team to read in analytics and spreadsheets. Those are real costs and benefits, just not SEO ones in the direct sense.
There's a second, quieter stake: your own team's daily working life. Someone debugging a 404, reading a crawl report or scanning a list of top pages in analytics has to read that URL dozens of times a week. A transliterated or English slug is faster for an English-speaking team to scan; an Arabic-script slug is faster for an Arabic-speaking team, and both groups' time is worth weighing alongside the reader-facing trade-off.
Arabic slugs, transliterated slugs and English slugs compared
Three real options exist, and each site tends to land on one for consistency rather than mixing them page by page.
| Style | Example | Strengths | Watch out for |
|---|---|---|---|
| Arabic script | example.com/ar/دليل-تحسين-محركات-البحث | Matches the page's language; readable to native speakers who see it decoded | Displays as a long percent-encoded string in many apps and chat clients |
| Transliterated | example.com/ar/dalil-tahsin-muharrikat-al-bahth | Short, portable, easy to type and read in a URL bar | Means little to a reader who doesn't already know the Arabic term |
| English (shared) | example.com/ar/seo-guide | Mirrors the English URL structure exactly; simple to maintain | Doesn't reflect the page's language at all |
None of the three is a mistake on its own. The mistake is picking one without deciding on purpose, or mixing styles across the site so some Arabic URLs are in script and others are transliterated.
The English-slug option deserves a specific word, because it's the one most likely to be a default rather than a decision. Plenty of CMS platforms generate the Arabic page's slug automatically from the English one when a translation is created, and teams simply never revisit it. That's not necessarily wrong — it's genuinely the simplest option to maintain — but it should be a choice made once you know the alternatives, not an accident of how the software happened to behave.
What happens to an Arabic URL when it's shared?
It gets percent-encoded by whatever app is displaying it, which converts each Arabic character into a sequence like %D8%AF%D9%84%D9%8A%D9%84 [2][3]. The URL still resolves correctly — this is exactly what percent-encoding is for — but it becomes unreadable and looks broken to someone glancing at it.
This matters more for a business that expects its URLs to be shared directly — quoted in a WhatsApp message, read aloud, or typed from memory — than for one where nearly all traffic arrives by clicking a search result or a stored link. If direct sharing is common in your market, that alone can tip the decision toward a transliterated or English slug.
Encoding itself is not the risk here; it's a well-established, standard behavior defined by the same specification that governs every URL on the web, Arabic or otherwise [2]. The risk is entirely about human perception — an encoded string looks broken to someone who doesn't know what percent-encoding is, even though the link works exactly as intended when clicked.
Does Google treat Arabic and transliterated URLs differently?
Not by design. Google's URL structure guidance asks for readable, descriptive URLs and explicitly supports non-ASCII characters when properly encoded — it doesn't state a preference for script over transliteration [1]. What it does reward, in either style, is a URL that describes the page rather than a string of IDs or parameters.
Where a difference does show up is indirectly, through readability and click behavior in the search results snippet, where Google sometimes displays the URL or breadcrumb path. A transliterated slug that reads as recognizable words can be marginally easier to scan there than a long encoded string, though this is a minor factor next to the title and description doing the real work.
Slugs also feed into how a page gets referenced internally — a descriptive slug, in any of the three styles, is what a developer or analyst scans when reading a URL list or a crawl report [4]. A slug of random characters or numeric IDs is a worse choice than any of the three real options here, regardless of which one you end up choosing.
How do you pick one and apply it consistently?
Decide based on how your specific audience actually uses URLs, not on a general preference for "more Arabic is more native."
Check how your audience actually shares links
If WhatsApp and messaging apps drive meaningful traffic, test how each URL style displays there before deciding.
Look at what your CMS generates by default
Many platforms auto-generate slugs from the page title. Know what you're getting by default before treating it as a deliberate choice.
Pick one style and document it
Write the rule down somewhere your team will actually see it, so future pages follow the same pattern without a fresh debate each time.
Set up redirects before changing anything on a live site
If you're switching an existing site's URL style, plan the redirect map first — every old URL needs to point at its new equivalent.
What if you already have a mix of both?
Audit before you standardize. List every Arabic URL pattern currently live, note which style each one uses, and check whether any of them are actually earning meaningful traffic or backlinks before you touch them — a URL with real external links pointing at it is a worse candidate for a style change than one nobody links to yet.
Standardize new pages going forward immediately, even before you've decided what to do about the old ones. That stops the inconsistency from growing while you plan the larger cleanup, which can happen on its own timeline without holding up everything else.
When you do migrate older URLs, redirect one to one and verify each redirect resolves before considering the migration done. A bulk pattern-based redirect that mostly works but silently breaks a handful of URLs is worse than doing nothing, because the failures are invisible until someone reports a 404 weeks later.
Does the choice affect analytics and tracking?
Yes, in ways worth planning for before you launch rather than after. Filters, dashboards and UTM-based reports that were built assuming Latin-character URLs sometimes need adjustment to correctly parse or group Arabic-script paths, and a team unprepared for that can end up with an Arabic section that quietly under-reports in its own analytics.
Test your actual analytics setup against a real Arabic-script URL before committing to that style at scale. It's a small check that catches a class of reporting bugs that are otherwise easy to miss until someone asks why Arabic traffic looks lower than it should.
Does the same logic apply to file names and query parameters?
Mostly, yes, though the stakes are lower. Image file names, category IDs and query parameters are read by far fewer humans than a page's own slug, so the readability argument matters less there. Encoding still applies the same way technically, but it's reasonable to be more relaxed about Arabic script in a parameter than in the main path a person actually sees and shares.
Where it's worth staying consistent regardless is anything that appears in a canonical URL or gets referenced in structured data, since those get read by crawlers and tools that assume a stable, well-formed pattern across the whole site.
Is this decision different for a Salla or Shopify store than for a marketing site?
The trade-offs are the same, but the volume changes the stakes. An ecommerce catalog can generate thousands of product URLs automatically, so whatever default your platform applies becomes your site-wide pattern almost immediately, with far less opportunity to catch and fix inconsistency page by page.
Check your platform's default slug behavior for Arabic product titles before you import or publish at volume, and decide deliberately rather than accepting whatever the theme does out of the box. Fixing a URL pattern across a few dozen manually published pages is a manageable afternoon; fixing it across an ecommerce catalog with thousands of live product URLs is a project with real redirect risk attached.
How this decision connects to the rest of your Arabic content
If you're using Arabic script in your slugs, the spelling variant question becomes part of your URL decision too — a URL spelled with one hamza variant and a title spelled with another looks inconsistent even when both are technically correct. Our guide to hamza and taa marbuta variants covers how to pick one spelling and apply it everywhere a keyword appears.
The URL style question also tends to come up at the same time as the translation decision, since both get settled when a new Arabic section is being planned. If you haven't yet decided which pages get a native rewrite versus a straight translation, translation vs transcreation is worth deciding alongside this one rather than after.
The same planning session is also where page length gets decided — how long should Arabic content be covers sizing a page once the URL and translation questions are settled.
Questions people also ask
Does Google support Arabic characters directly in URLs?
Yes, as long as they're properly percent-encoded, which browsers and servers handle automatically in modern implementations. Google indexes and displays Arabic-script URLs without penalty.
Why does an Arabic URL turn into a long string of percent signs when I paste it somewhere?
Because some apps and chat clients percent-encode non-ASCII characters when displaying or copying a URL, converting each Arabic character into a %XX sequence. The URL still works; it's just unreadable in that raw form.
Is a transliterated slug bad for SEO?
No. Google doesn't require Arabic-script URLs to rank Arabic content well. A transliterated or English slug works fine as long as the page's actual content, headings and metadata are properly written in Arabic.
Can I switch URL styles later if I pick the wrong one?
You can, but it means redirecting every affected URL, which costs time and can cause a temporary dip while search engines reprocess the change. Pick deliberately the first time rather than defaulting to whatever a CMS generates automatically.
Sources
- URL structure best practices for Google — Google Search Central (checked 23 September 2026)
- RFC 3986: Uniform Resource Identifier (URI): Generic Syntax — IETF (checked 23 September 2026)
- Percent-encoding — MDN Web Docs (checked 23 September 2026)
- Slug (URL) — MDN Glossary — MDN Web Docs (checked 23 September 2026)
Get your Arabic URL structure decided before you publish at scale
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- Arabic SEO: the complete guide for 2026Arabic SEO is ranking pages written for Arabic searchers: research in Arabic, write natively, build a clean /ar/ section and earn Arabic links.
- Translation vs Transcreation for Arabic SEOTranslation and transcreation are different products with different prices. Here's when a straight translation is fine, and when Arabic pages need a rewrite.
- Hamza and Taa Marbuta: Arabic Spelling in SEOArabic allows more than one correct spelling for many words. Here's how hamza, taa marbuta and alif maqsura variants affect keywords and how to handle them.
- Hreflang for Arabic: The Exact Tags to UseHow to set hreflang for Arabic pages: which language and region codes to use, where the tags go, and the mistakes that break them most often.