Right to Left Is Engineering, Not Design

Right-to-left support fails quietly. That is what makes it dangerous. A broken Arabic build does not throw a 500, does not show up in an uptime alert, and usually looks acceptable in a screenshot review. It renders. Someone approves it. Then it underperforms for a year while the team blames content quality.

The reason is that right-to-left is treated as a design decision when it is an engineering one. Flipping a layout is the easy half. The hard half is direction declaration, bidirectional text handling, logical property discipline, canonical integrity across two language trees, and whether your Arabic documents are machine-readable at all. Each of those has a specific failure mode, and none of them announces itself.

What follows is the list, in the order the failures actually happen, with the reason each one matters rather than just the fix.

Direction belongs on the html element, not in your stylesheet

Start with the mistake that sits underneath most of the others. A team wants the Arabic pages to read right to left, so someone adds direction rules in CSS, applies them to a wrapper div, and the layout mirrors. Visually it works.

What has not happened is a declaration. The document has not told anything reading it that this is a right-to-left document in Arabic. It has told a rendering engine how to arrange boxes.

The correct form is on the root element itself, with both attributes present: a language attribute and a direction attribute. Language and direction are separate pieces of information and both are needed. Direction without language leaves the content unidentified. Language without direction leaves the reading order undeclared.

Why does the distinction matter beyond tidiness? Because crawlers, extraction pipelines and answer engines read markup, not rendered pixels. A page that mirrors through CSS but never declares direction produces parsing noise for anything working from the source. And since a growing share of discovery now runs through systems that extract passages rather than render pages, undeclared direction is a compounding cost rather than a cosmetic one.

One more thing about scope. Direction is not a site-wide setting when a site is bilingual. It is a per-document setting. The English tree stays left to right, the Arabic tree is right to left, and the switch happens at the document level. Teams that set it globally end up with English pages reading in the wrong direction, which is at least a visible failure and therefore gets caught.

Left and right are the wrong words

Every stylesheet written for a single left-to-right language is full of assumptions expressed as directions. Margin on the left. Padding on the right. Text aligned left. Border on the left edge of a quote block.

In a bidirectional codebase, every one of those is a bug waiting for a language switch. The concept you actually meant was not left. It was start.

CSS logical properties express that. Instead of naming a physical side, they name a position relative to the reading direction, so the same declaration produces the correct result in both directions without a second stylesheet and without an override block. Margin at the start of the line. Padding at the end. Text aligned to start. Border on the inline start edge.

The payoff is not elegance. It is that you stop maintaining two truths. The alternative, which most teams reach for first, is to write left-to-right styles and then add a right-to-left override sheet that flips them. That works until someone adds a component and forgets the override. Then one card in one section stays anchored to the wrong edge, nobody notices for months, and the fix requires archaeology.

There is a discipline question buried here. Logical properties only help if the team uses them consistently, including in components written before Arabic was on the roadmap. Retrofitting is the expensive path, which is why this decision belongs at the start of a bilingual project rather than at the point where translation begins.

Bidirectional text is where it actually gets hard

Here is the part that separates a build that works from a build that merely mirrors.

Arabic runs right to left. Numerals, Latin script, URLs, email addresses, acronyms and model numbers run left to right. Put them in the same sentence and you have bidirectional text, which is resolved by an algorithm rather than by your stylesheet.

That algorithm does its best with ambiguous cases, and its best is not always what you meant. A sentence containing a product code, a phone number and a Latin brand name can render with those elements in an order the author never intended, and the failure is often positional: the same string renders correctly in the middle of a paragraph and incorrectly at the start of a list item, because the surrounding context changed what the algorithm inferred.

The consequence for a commercial site is concrete. A model number that reorders is a wrong model number. A phone number whose country code migrates to the wrong end is a phone number that does not work. And a native Arabic reader does not experience these as technical glitches. They experience them as a company that did not care enough to check.

The fix is explicit isolation around mixed-direction runs, so that each embedded left-to-right element is treated as a self-contained unit rather than being merged into the surrounding flow. It has to be applied deliberately, at authoring time or in the template layer, because there is no automatic detection that gets it right in every case.

Two practical rules follow. First, treat every place where Latin script or digits enter Arabic prose as a location that needs handling, and build it into the component rather than trusting the writer to remember. Second, test with real content. A test page containing only Arabic will pass while the live product page containing an Arabic description and an English SKU will not.

What should mirror, and what should not

Mirroring is not a global transform. Some things flip, some things must not, and getting the second category wrong looks worse than not mirroring at all.

Flip the things that carry direction as meaning. Next and previous arrows. Progress indicators. Breadcrumb separators. Sliders and carousels, including the swipe direction. Indentation of nested lists. The order of items in a horizontal navigation.

Do not flip the things where direction is not the meaning. Clock faces and time-based icons. Media playback controls, because play still points forward in the universal sense rather than in the reading sense. Checkmarks. Logos, ever. Numerals themselves, which keep their own internal order. Charts where the axis carries a real-world sequence.

The grey area is worth naming rather than pretending it away: some icons genuinely have no settled convention, and the honest approach is to pick one, apply it consistently across the interface, and have a native speaker review it in context. Consistency matters more than being theoretically right about a single glyph.

Typography is not a matter of taste here

Arabic script has different metrics from Latin script, and a stylesheet tuned for English will render Arabic that is technically legible and practically tiring.

Arabic letterforms carry more detail in a smaller vertical space, connect to their neighbours, and change shape depending on position within a word. The practical result is that Arabic needs a larger base size and more generous line height than the same design would use for English. A body size that reads comfortably in English will read cramped in Arabic at the same numeric value.

Font choice is a real constraint rather than a preference. Typefaces with genuine Arabic coverage designed for screen use, rather than a Latin font with a bolted-on Arabic fallback, are what produce a page that looks native. Several are widely used for exactly this purpose in Gulf digital work, including Cairo, Tajawal, IBM Plex Sans Arabic and Noto Sans Arabic. The test is simple: if the Arabic on your page looks like it came from a different design system than the English, it did.

Then there are diacritics. Arabic can be written with vowel marks, and in most commercial text they are omitted. Keep them omitted. Adding them to body copy changes the character strings, which affects matching, and it also reads as unusual to a commercial audience since the convention outside religious and educational text is to leave them out. Where a term is genuinely ambiguous without them, handle it with clearer phrasing rather than by adding marks.

The bilingual architecture checklist

This is the part that decides whether both languages exist as far as a search engine is concerned. It is also where the most damaging single mistake lives.

Element	Correct implementation	What goes wrong
URL structure	Separate, stable URLs per language, one clear pattern applied everywhere.	Language switched by cookie or session on the same URL, leaving one address that returns two different documents.
hreflang	Reciprocal annotations covering every language version, with region where it is genuinely needed, such as an Arabic and English pair scoped to Qatar.	One-way annotations that point outward but are never returned, invalid region codes, or pages missing from the set entirely.
Canonical	Self-referencing on every page, in both languages.	Arabic pages canonicalised to their English equivalents. This removes the Arabic version from the index while the site still looks bilingual to a visitor.
Sitemaps	Declared per language tree so each version is discoverable independently.	A single sitemap containing only the primary language, leaving Arabic pages to be found by internal linking alone.
Internal linking	Arabic pages link to Arabic pages. The language switcher is an addition, not the only route in.	An Arabic tree reachable only through a header toggle, receiving almost no internal signal of its own.
Encoding	UTF-8 without a byte order mark, declared consistently across templates and exports.	Mixed encodings between the CMS, a feed and a PDF export, producing text that renders on one surface and breaks on another.

The canonical row deserves its own sentence, because in our auditing experience it is the most common cause of an Arabic site that seems to have been built properly and still has no Arabic visibility. Somebody set canonicals during an English-first build, the Arabic tree was added later, and the template inherited a canonical pointing at the English original. Every Arabic page is now telling search engines to ignore it in favour of a page in a different language. The site looks complete. Half of it is not there.

Your Arabic documents are probably not readable

Here is a failure mode that sits outside the website entirely and quietly caps what the site can achieve.

A great deal of substantive Arabic commercial content lives in documents. Specifications, catalogues, price schedules, technical datasheets, tender responses. Frequently those documents are PDFs, and frequently the Arabic inside them is either a scan or text that does not extract cleanly.

How bad is it? A 2025 benchmark called KITAB-Bench measured Arabic document understanding across 8,809 samples, nine domains and twenty-one distinct chart types. On the task of converting Arabic documents into clean machine-readable markdown, the best reported result was around sixty-five per cent accuracy. Complex layouts degraded it further.

Sit with that number for a second. Under favourable conditions, roughly a third of the content in an Arabic document does not survive the trip into a form that a machine can use reliably. And that is a benchmark result with researchers trying hard. It is not a measurement of what happens when a marketing team exports a brochure.

Three consequences follow for anyone building an Arabic web presence.

First, anything that matters commercially belongs on an HTML page as real text, not only inside a document. Product specifications, service descriptions, comparison data, pricing structures. If it exists only as a PDF, treat it as approximately invisible and plan accordingly.

Second, tables must be real HTML tables containing real text. A table rendered as an image is not a table, it is a picture of one, and Arabic tables inside images are among the least recoverable content on the web.

Third, where documents genuinely have to be documents, generate them from text rather than from a scan, keep the encoding clean, and avoid multi-column layouts that interleave Arabic and Latin script in ways that confuse extraction ordering.

Schema, and what it does and does not do

Structured data is language-neutral, which surprises people the first time they build an Arabic site. JSON-LD itself stays left to right, because it is code rather than prose. What changes is the content of the string values, which should be genuinely native Arabic rather than transliterations of English names.

Two things belong in every bilingual implementation. A language declaration on the content, using proper language tags rather than an ad hoc label. And stable identifiers so that the Arabic and English representations of the same entity are understood as one thing described twice rather than two separate organisations.

Now the honest part. Both Google and Microsoft have said publicly that structured data helps their systems understand content, with Google's structured data engineers and Microsoft's search leadership making that point at industry events. What neither has said is that it guarantees any particular outcome, and Google states plainly that structured data does not guarantee a rich result. Various vendor blogs circulate multipliers claiming specific citation or visibility lifts from schema alone. Those figures do not come with disclosed methodology and we do not repeat them.

So implement schema as hygiene. It makes your entity legible and it costs little. Treat any agency that sells it as a lever with a promised multiplier as someone who has stopped reading primary sources.

A quality assurance sequence that catches these

None of the failures above are hard to detect once you know to look. The problem is that a standard review process does not look. Here is a sequence that does.

Fetch the raw source of ten Arabic URLs and read the root element. Confirm both language and direction are declared there rather than applied in a stylesheet.

Read the canonical on each of those ten. Any canonical naming a different language is a stop-work finding.

Check hreflang reciprocity in both directions. An annotation that is not returned is an annotation that does nothing.

Grep the stylesheet for physical direction properties. Every hit is a candidate bug, and components added most recently are the most likely offenders.

Build a test page containing real mixed content: an Arabic sentence with an English brand name, a model number, a URL and a phone number, placed in a paragraph, a heading, a list item and a table cell. Review it with a native reader. This single page catches more bidirectional problems than any automated check.

Inventory your Arabic documents. Anything commercially important that exists only as a PDF gets scheduled for an HTML equivalent.

Have a native Arabic speaker walk the interface, not just read the copy. Icon direction, form flow, error message placement and the language switcher itself are things a translator reviewing a text file will never see.

That sequence takes a day or two on an existing site. It routinely finds problems that a content team has been trying to solve with more content for a year, which is the wrong tool for a markup problem. If you want the wider strategic and regulatory picture that surrounds this work, including how register choice interacts with the technical layer, our search practice for the Qatari market covers the full scope, and our team has documented how these decisions compound over a bilingual build.

The short version

Right to left is engineering. Direction and language get declared on the root element, not applied through a stylesheet. Logical properties replace physical ones so you maintain one truth instead of two. Bidirectional isolation gets applied wherever Latin script or digits enter Arabic prose, and gets tested with real mixed content rather than Arabic-only samples. Icons mirror where direction is the meaning and stay put where it is not. Typography gets its own scale and a real Arabic typeface.

Then the architecture: separate URLs, reciprocal hreflang, self-referencing canonicals on both sides, per-language sitemaps, and clean encoding end to end. Check the canonicals first, because that is where a whole language quietly disappears. And take an inventory of your Arabic documents, because a benchmark result of roughly sixty-five per cent on document conversion means a meaningful share of what you have already written is not reaching anything that reads the web.

---

Frequently asked questions

Is it enough to set direction in our CSS for the Arabic pages?

No. Applying direction through CSS mirrors the layout for a human viewer, which is why it passes a visual review, but it never declares to a machine what language the document is in or which direction it reads. Both a language attribute and a direction attribute belong on the root element of each Arabic document. This matters more than it used to, because a growing share of discovery runs through systems that extract text from source markup rather than rendering the page, and an undeclared document produces parsing noise for all of them.

What exactly is bidirectional text and why does it cause problems?

It is any passage where right-to-left and left-to-right content sit in the same string, which in practice means almost every Arabic commercial sentence, since numerals, URLs, email addresses, acronyms, model numbers and Latin brand names all run left to right. The rendering order of those embedded runs is resolved by an algorithm, and in ambiguous cases the result is not always what the author intended. The same string can render correctly in a paragraph and incorrectly in a list item because the surrounding context changed. A reordered model number is a wrong model number, and a native reader reads it as carelessness rather than as a technical fault, so it needs explicit isolation applied in the template layer.

Which icons and elements should be mirrored on an Arabic page?

Mirror the ones where direction carries the meaning: next and previous arrows, progress indicators, breadcrumb separators, carousels including swipe direction, nested list indentation, and horizontal navigation order. Do not mirror clock faces, media playback controls, checkmarks, numerals, logos, or charts where an axis represents a real-world sequence. Some icons genuinely have no settled convention, and in those cases the right answer is to choose one, apply it consistently, and have a native speaker review it in context. Consistency beats theoretical correctness on any single glyph.

Why would our Arabic pages disappear from search if the site looks fine?

The usual cause is a canonical tag inherited from an English-first build. The Arabic template points its canonical at the English equivalent, which instructs search engines to treat the English page as the authoritative version and drop the Arabic one. Nothing looks broken to a visitor, both pages load, and the traffic report shows the English page performing while the Arabic page stays flat, which teams often misread as low Arabic demand. Fetch ten Arabic URLs and read the canonical each one declares. If it names a different language, fix that before commissioning any more content.

Do we need special fonts and sizes for Arabic?

Yes, and this is not a stylistic preference. Arabic letterforms connect to their neighbours, change shape by position within a word, and carry more detail in less vertical space than Latin script, so the same numeric body size that reads comfortably in English reads cramped in Arabic. Arabic needs a larger base size and more generous line height. Font choice matters too: a typeface with genuine screen-oriented Arabic coverage produces a native-looking page, whereas a Latin font with a bolted-on Arabic fallback does not. Diacritics should stay omitted in commercial text, because that is the convention outside religious and educational contexts and because adding them changes the character strings.

How much of our Arabic content in PDFs is actually reachable?

Less than most teams assume. The KITAB-Bench benchmark evaluated Arabic document understanding across 8,809 samples, nine domains and twenty-one chart types, and the best reported accuracy for converting documents into clean machine-readable markdown was around sixty-five per cent, degrading further on complex layouts. That is a research result under favourable conditions rather than a measurement of a typical marketing export. The practical rule is that anything commercially important belongs on an HTML page as real text, tables are real HTML tables rather than images, and where documents must stay documents they are generated from text rather than scanned.

---