RTL Website Checklist: 12 Things to Test
A right-to-left checklist for Arabic sites: markup, CSS, typography, forms and navigation, with the exact things to test before launch.
An RTL checklist covers four areas: HTML markup, CSS layout, typography and fonts, and interactive elements like forms and navigation. Get dir and lang right on the html element, replace left and right CSS properties with logical ones, and test every icon and form field by hand before launch.
This is the hands-on companion to Arabic SEO: the technical work that keeps a well-researched Arabic page from looking broken the moment someone opens it.
On this page
What actually breaks when you flip a site to RTL?
Almost everything that was hardcoded to a direction. Templates built English-first tend to bake in assumptions — sidebars on the left, icons pointing right, form labels aligned to one edge — and every one of those assumptions becomes visibly wrong the moment the page reads right to left.
The failures fall into four buckets: markup that never declares direction correctly, CSS that uses physical rather than logical properties, typography that wasn't built for Arabic glyphs, and interactive elements — forms, navigation, carousels — that keep their English-direction behavior. The rest of this checklist works through each one.
None of these are exotic problems. They show up on well-built, well-tested English sites the moment an Arabic version ships, precisely because "well-tested" usually meant tested in one direction. A checklist run once, before launch, catches nearly all of it far more cheaply than fixing it after a native reader reports the site "feels broken" without being able to say exactly why.
Structural markup: dir, lang and the html element
Set dir="rtl" and lang="ar" on the html element of every Arabic page, not just on a wrapping div [1]. The W3C's guidance is explicit that direction belongs on the document's root markup, because browsers, screen readers and search engines all read it from there first.
Mixed-language pages need care too. A paragraph that embeds an English brand name or a phone number inside Arabic text can render with the embedded text in the wrong position unless the markup handles bidirectional text correctly [2].
Layout and CSS: logical properties instead of left and right
The single highest-leverage fix on this list is switching from physical CSS properties to logical ones. Logical properties describe position relative to the reading direction — start and end — instead of a fixed left or right, so the same stylesheet adapts automatically when the page flips [3].
| Physical property | Logical replacement | What changes |
|---|---|---|
| margin-left / margin-right | margin-inline-start / margin-inline-end | Follows reading direction automatically |
| padding-left / padding-right | padding-inline-start / padding-inline-end | Same stylesheet works for LTR and RTL |
| text-align: left | text-align: start | Aligns to the reading start, not a fixed side |
| left: 0 / right: 0 (positioning) | inset-inline-start: 0 / inset-inline-end: 0 | Positioned elements flip with direction |
Once the properties are logical, most layout bugs disappear without a separate RTL stylesheet. What's left is a smaller list of things that need explicit handling regardless of CSS: images, icons and anything with an inherent direction.
This is worth doing even on a site with no immediate Arabic plans. Logical properties cost nothing in a left-to-right layout — they render identically to their physical equivalents — so writing them by default means the day an RTL language enters the roadmap, the layout work is already mostly done.
Typography and fonts that don't fight the script
Arabic glyphs are connected and contextual — a letter's shape changes depending on its position in a word — so a font with weak Arabic support renders disconnected, broken-looking letterforms even when the text itself is correct. Test your font stack with real Arabic text, not a placeholder.
Numbers are a separate trap. Arabic text commonly uses Western Arabic numerals (0–9) even while the surrounding text reads right to left, and a number embedded in an Arabic sentence needs to stay left-to-right internally without breaking the sentence's overall direction. Test phone numbers, prices and dates specifically, because they're where this most often goes wrong.
Line height and letter spacing deserve a separate check too. Arabic script relies on connected strokes and diacritical marks above and below the baseline, so a line height tuned for Latin text can clip marks or crowd lines together. Give Arabic text noticeably more line height than the equivalent English paragraph, and confirm it in the actual browser rather than a design mockup.
Forms, navigation and icons that point the wrong way
Form labels, input alignment and validation messages all need to sit on the correct edge for RTL, which is the "end" edge rather than a fixed side once you're using logical properties. Test every form on the Arabic site by hand — autofill, placeholder text and error states included.
Navigation menus, breadcrumbs and carousels often keep their English-direction behavior even after the visual layout flips: a "next" arrow that still points right, a breadcrumb trail that still reads left to right, a carousel that scrolls the wrong way relative to the reading direction. These are small individually, and they add up to a page that reads as unfinished.
Dropdown menus and modals are worth a specific check too. A menu that opens to the left in English should open to the right in Arabic to stay attached to its trigger, and a modal's close button should sit on the reading-start edge rather than a fixed corner. Component libraries built without RTL in mind rarely handle this without configuration.
How do you actually catch these before launch?
Run a fixed test pass on every new Arabic template, not just the homepage.
Load every page in Arabic and scan for mirrored layout
Sidebars, navigation and content should visually flip. If they don't, direction isn't set on the right element.
Click through every directional icon
Back and forward arrows, carousel controls and expandable chevrons should point toward the reading direction, not the English default.
Fill out every form
Labels, alignment, placeholder text and error messages should sit and read correctly on the RTL edge.
Check numbers, dates and mixed text
Phone numbers, prices and embedded English words should render without breaking the surrounding Arabic sentence's flow.
Have a native Arabic reader review the finished page
A checklist catches structural bugs; a native reader catches reading-flow problems that still feel wrong even when every rule above passes.
How this connects to keyword research and hreflang
A page that passes this checklist still needs the right words on it. If your Arabic keyword list was built from a translated English one, revisit it using the process in Arabic keyword research tools, and check that your target terms account for the dialect differences covered in Arabic dialects and search.
Once the Arabic page itself is solid, make sure search engines know it's connected to its English twin. That's a hreflang job, and hreflang for Arabic shows the exact tags and how to test them once this checklist is done.
Questions people also ask
Is setting dir="rtl" on the body enough to make a site right-to-left?
No. It flips text direction but not the rest of the layout unless your CSS uses logical properties. A site built with left and right properties still shows a mirrored English layout with Arabic text pasted into it.
Do I need a completely separate stylesheet for RTL?
Not if you use CSS logical properties such as margin-inline-start instead of margin-left. Written that way, one stylesheet adapts to both directions automatically based on the page's dir attribute.
Why do my icons and arrows look wrong on the Arabic version of my site?
Directional icons — back arrows, forward arrows, chevrons in carousels — usually need to be mirrored for RTL, and most icon libraries don't do this automatically. It has to be handled explicitly in your components.
Can I test RTL issues without a native Arabic speaker?
You can catch the structural bugs — broken alignment, wrong-direction arrows, form fields on the wrong edge — without one, but a native reader should still review the finished page. They catch reading-flow problems a checklist alone misses.
Sources
- Structural markup and right-to-left text in HTML — W3C Internationalization (checked 23 September 2026)
- dir — HTML global attribute — MDN Web Docs (checked 23 September 2026)
- CSS logical properties and values — MDN Web Docs (checked 23 September 2026)
- lang — HTML global attribute — MDN Web Docs (checked 23 September 2026)
Get your Arabic pages checked against this list
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.
- 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.
- Arabic Dialects and Search: What ChangesModern Standard Arabic and spoken dialects behave differently in search. Here's how Gulf, Egyptian and Levantine queries differ, and what to do about it.
- Arabic Keyword Research: Tools and MethodMost keyword tools were built for English first. Here's how to research Arabic keywords properly, and which tools actually hold up once you do.