How to build one website in English, Turkish and Arabic that Google ranks in all three

In short: give every language its own URL (/, /tr/, /ar/), connect them with reciprocal hreflang links, serve prerendered HTML, build Arabic as a real right-to-left layout, load only the fonts each language needs — and measure speed in every language.

Most businesses I work with in Istanbul sell to three audiences at once: Turkish customers, visitors and buyers from the Arab world, and everyone else in English. So the question is rarely "do we need a website?" It is "how do we get one website that works, and ranks, in three languages?"

The usual answer — a translation plugin with a language dropdown — tends to fail quietly. The site looks multilingual, but Google only ever sees one language, the Arabic version reads backwards in places, and the pages get slower with every font added.

This is the checklist I use instead. It is also exactly how this site is built: English, Türkçe and العربية.

1. Give every language its own URL

Search engines index URLs, not buttons. If the language changes through a cookie, a dropdown or the visitor's IP address while the address bar stays the same, Google will crawl one version and never see the others.

Use one clear pattern and keep it everywhere:

example.com/ — English (or your main language)
example.com/tr/ — Turkish
example.com/ar/ — Arabic

Subfolders are the simplest choice for a small business: one domain, one SSL certificate, and every language shares the authority the domain has built up. Every page should exist in every language at the same path — /work/maro/, /tr/work/maro/, /ar/work/maro/ — so switching language keeps the visitor on the same page.

Never redirect visitors automatically by IP or browser language. Suggest a language if you like, but let people (and Googlebot, which mostly crawls from the US) reach every version directly.

2. Tell Google the pages are translations of each other

Without hints, three versions of the same page can look like duplicate content. hreflang links solve this. Each page lists all of its language versions, including itself:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="tr" href="https://example.com/tr/" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Three rules that catch most mistakes:

The links must be reciprocal. If the Turkish page points to the Arabic one, the Arabic page must point back. One-way hreflang is ignored.
Each page has its own canonical. The canonical of /tr/ is /tr/, not the English page. Pointing every language at the English canonical tells Google to drop the translations.
x-default is the fallback for visitors whose language you don't serve.

Put the same alternates in your XML sitemap as well. Then submit the sitemap in Google Search Console and Bing Webmaster Tools — Bing's index also powers AI answers such as Microsoft Copilot.

3. Make the HTML exist before JavaScript runs

Many modern sites render everything in the browser. The server sends an almost empty page, and JavaScript fills in the text — in the right language — a moment later. Google can run JavaScript, but it does so later and less reliably, and most AI crawlers don't run it at all.

The fix is to prerender (or server-render) every page in every language, so the HTML the server sends already contains the real title, headings and text. On this site, each build writes a static HTML file for every page in every language — 24 pages before this blog existed — and the JavaScript only adds the interactive layer on top.

A quick test: open your page, choose View page source (not Inspect), and search for a sentence from the Arabic version. If it isn't there, search engines are not seeing it either.

4. Arabic is a layout, not just a translation

Right-to-left support is where most trilingual sites break. Setting dir="rtl" on the <html> element is the start, not the end:

Use logical CSS properties. margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, text-align: start instead of left. Then one stylesheet works in both directions.
Mirror direction, not content. Arrows, "next/back" chevrons and progress bars should flip. Logos, photos, phone numbers, code and Latin brand names should not.
Reset letter-spacing. Spaced-out uppercase looks sharp in Latin text, but letter-spacing breaks the joins between Arabic letters. Set it to 0 for Arabic.
Give Arabic more line height. Arabic glyphs are taller, and a tight Latin headline style makes Arabic lines crash into each other.
Decide on digits once. Arabic-Indic digits (١٢٣) or Western digits (123)? Both are correct, but mixing them on one page looks careless. Intl formatting lets you choose: the locale ar-EG-u-nu-latn writes Arabic dates with Western digits.

Then test with real content. Lorem ipsum in Arabic hides exactly the problems you need to find.

5. Load the fonts each language needs — and only those

Three languages usually means at least two font families: one for Latin script (with the Turkish letters ş, ğ, ı and İ) and one designed for Arabic. Loaded naively, that is several hundred kilobytes before the first line of text appears.

What works:

Self-host the fonts instead of loading them from a third-party CSS file. That removes an extra connection and a render-blocking request.
Split fonts by unicode-range. The browser then only downloads the Arabic file when a page actually contains Arabic letters, and the Latin Extended file only when it meets a Turkish character.
Preload just the one or two fonts above the fold — usually the headline font.

When I made these changes on this site, mobile Lighthouse performance went from 70 to around 90, and the Arabic font no longer downloads on English pages.

6. Translate what people search for, not word for word

Every language needs its own page title and meta description, written for how people in that language actually search. Turkish customers search for "e-ticaret sitesi", not a literal translation of "online store". An Arabic speaker in Istanbul may search in Arabic, in Turkish, or in a mix of both.

Have a native speaker review each version — ideally someone who knows the industry. Machine translation is a good first draft and a poor final one, and visitors notice the difference within a sentence.

7. Measure speed in every language

The Arabic version is often the slowest, because it carries its own fonts and is tested least. Measure each version separately with PageSpeed Insights or Lighthouse, and look at Largest Contentful Paint (LCP): how long the main content takes to appear. Under 2.5 seconds is Google's "good" threshold.

For reference, these are measured LCP medians (desktop, three cold loads) for sites I've built:

Project	Type	LCP
Maro Patissier	Patisserie store	0.32 s
VagoShop	Hospitality e-commerce	0.40 s
Midoré Paris	Beauty brand	0.51 s
Vago Design	Brand site	0.77 s

The checklist

One URL per language, same path structure (/, /tr/, /ar/)
No automatic redirects by IP or browser language
Reciprocal hreflang links plus x-default, in the page head and in the sitemap
A self-referencing canonical on every language version
Prerendered or server-rendered HTML with the real text in it
dir="rtl", logical CSS properties and mirrored arrows for Arabic
Letter-spacing 0 and more line height for Arabic text
One digit style per page
Self-hosted fonts split by unicode-range, only the headline font preloaded
Separate titles and descriptions per language, reviewed by native speakers
LCP measured for each language, under 2.5 s
Sitemap submitted to Google Search Console and Bing Webmaster Tools

Getting all of this right takes care at the start of a project, but almost nothing afterwards. Retrofitting it into a site that was built for one language is much harder — so if you are planning a new site for Türkiye and the Arab market, build it trilingual from day one.