Why isn't an automatic translation plugin enough for a bilingual website?

A translation plugin swaps text after the page loads, but it doesn't fix CSS written with hardcoded left/right values, doesn't know which icons should mirror and which shouldn't, and doesn't solve mixed text with embedded numbers and English brand names. On top of that, content injected via JavaScript after load usually isn't crawled as an independent page by Google or AI engines - so the second language version effectively doesn't exist for them.

What's the difference between adding dir="rtl" to a page and actually building it RTL-ready?

dir="rtl" only changes the base reading direction. It doesn't automatically flip CSS written with fixed margin-left or padding-right values, doesn't decide which icons (arrows, navigation) should mirror versus ones that must not (play buttons, clocks, phones), and doesn't handle mixed Hebrew-English text. Proper RTL support requires CSS logical properties and a per-element mirroring review.

Is it better to have two separate sites for Hebrew and English, or one page with a language switch?

A separate HTML page per language with its own canonical URL and hreflang tags between the versions - not a client-side language toggle. That way both Google and AI engines can crawl and cite each language as a complete, independent page, instead of relying on dynamically swapped content that's sometimes invisible to crawling entirely.

← All Articles

Websites · Sep 11, 2026 · May I

Building a Bilingual Hebrew-English Website - The RTL/LTR Technical Pitfalls That Cost You Conversions

Short answer: a bilingual Hebrew-English website isn't one site where you translate the words and flip the reading direction. It's a separate technical foundation - CSS built with logical properties instead of hardcoded left/right, a per-icon decision on whether to mirror it, and dedicated handling for mixed text like an English brand name or a phone number sitting inside a Hebrew sentence. Businesses that skip this and settle for a translation plugin or a blanket dir="rtl" lose a real share of their audience: a CSA Research survey of 8,709 consumers across 29 countries found that 76% prefer buying a product with information in their native language, and 40% simply won't buy from a site in a language they don't understand (source: csa-research.com). That's the difference between a site that looks bilingual and one that actually works in both languages.

Why "translate it and flip the direction" doesn't work

Both language versions are supposed to run on the same code with a direction switch, but in practice dir="rtl" only changes the base reading direction. It doesn't automatically flip CSS written with hardcoded left and right values, doesn't know which icons should mirror and which shouldn't, and doesn't solve mixed text where an English brand name, a phone number, or a price sits inside a Hebrew sentence. A site built in English and then "flipped" with a translation plugin or a blanket dir="rtl" usually looks broken in the small details - a button whose arrow points the wrong way, uneven spacing, a number that splits across a line break.

Pitfall one - CSS with hardcoded directions

When styling is written with margin-left, padding-right, or text-align: left, it only "knows" one direction. In an RTL page everything needs to flip, and manually fixing every place left or right appears in the code is slow and error-prone - it's easy to miss one spot and end up with a single element stuck in the wrong direction. The clean fix is writing CSS from the start with logical properties - margin-inline-start/end instead of margin-left/right, inset-inline instead of left/right, text-align: start instead of text-align: left. The same exact code then flips correctly in both languages with nothing extra - the browser handles it based on the page's dir.

Pitfall two - icons that should mirror, and ones that shouldn't

Not every icon should flip just because the direction flipped. Arrows, "next/previous" buttons, navigation icons, and progress bars should mirror, because they represent a direction of motion tied to reading direction. A video play button, a clock, a phone, or a camera icon, on the other hand, shouldn't mirror - they represent an international convention that has nothing to do with language direction, and a "play" button pointing left on a Hebrew page just confuses people. The call has to be made per icon, not a blanket transform on every SVG on the page.

Pitfall three - mixed text: numbers and English names

The moment a Hebrew sentence contains a phone number, a price, or an English brand name, the browser's basic bidirectional text (bidi) algorithm can order the characters unpredictably, especially next to punctuation. The typical symptom: a detail that looks fine on desktop but breaks on mobile, where rendering differences between browsers are more pronounced. The practical fix: wrap embedded foreign text (an English product name, a code, an email address) in a span with unicode-bidi: isolate or dir="auto", so it behaves as an independent unit inside the Hebrew sentence instead of bleeding into the surrounding direction.

Why this is also an SEO and GEO/AEO issue, not just design

Every language needs its own independent canonical URL with hreflang tags between the versions - exactly how this page itself is built - not a client-side language toggle that swaps text with JavaScript. The reason: an AI engine crawling a page whose content loads or swaps dynamically usually sees only one version, sometimes none at all. And even in the version it does see, the direct answer has to sit in the opening, not buried deep in the page - a study on ChatGPT citations found that 44.2% of citations come from the first 30% of a document (source: searchengineland.com). Meaning even a properly built bilingual page loses citations if the direct answer sits mid-page in one of the languages instead of at the top.

What actually works

A separate HTML page per language, with its own lang and dir, and mutual hreflang links between the versions.
CSS built with logical properties (margin-inline, inset-inline, text-align: start/end) instead of hardcoded left/right.
An explicit per-icon decision on whether it should mirror in Hebrew or stay as-is.
Wrapping embedded foreign text (names, numbers, codes) in its own bidi markup so it doesn't bleed into the sentence's direction.
Testing on mobile, not just desktop - that's where bidi and mirroring bugs show up far more often.

That's exactly why building a bilingual site properly doesn't end with translation. It requires thinking about both languages from the design and code stage - not bolting it on at the end.

Building a bilingual site and want it to actually work in both languages?

We build bilingual websites in custom code - including proper RTL/LTR infrastructure, not just translation with a flipped direction.

Get started