Bilingual Arabic-English SEO for Kuwait Sites

Q: Does hreflang need to point both ways?

Yes. The most common hreflang mistake is one-directional: the English page references the Arabic version, but the Arabic page never references back. Every language version needs to point to every other version, including itself.

Q: Should hreflang use "ar" or "ar-kw"?

For a Kuwait-specific business, ar-KW targets Arabic speakers in Kuwait specifically, while plain ar targets Arabic speakers anywhere. If the content and offer are Kuwait-specific, the region-tagged version is the sharper signal.

Q: Do Arabic fonts actually slow a site down?

They can. Many Arabic web fonts load at 300-500KB, which is heavy compared to typical Latin fonts. Subsetting the font to only the characters actually used and serving it as WOFF2 keeps this from becoming a real performance problem.

Almost every Kuwaiti business website claims to be "bilingual." Very few actually implement it in a way that ranks properly in both Arabic and English search results. Having built bilingual sites like Zumord and worked extensively on nowebda.com's Arabic SEO, here's what actually matters technically.

1. Translated content isn't the same as localized SEO

Pasting a translated version of your English copy into an Arabic page misses how Kuwaiti users actually search. Arabic search queries often use different phrasing, keywords, and structure than a direct translation would produce — proper bilingual SEO requires separate keyword research for each language, not translation of the same keyword list.

2. Use hreflang tags correctly, on every page

Without proper hreflang annotations — Google's own documentation on the tag — Google can't reliably tell which language version to show to which searcher — leading to the wrong version ranking, or both versions competing against each other instead of reinforcing the same domain's authority.

The mistake I see most often is one-directional: the English page correctly references the Arabic version, but the Arabic page never references back to English. Hreflang has to be reciprocal — every version links to every other version, including itself:

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

Use ar-kw rather than plain ar if the business and content are genuinely Kuwait-specific — it's a sharper signal than targeting Arabic speakers everywhere. Add x-default so there's a clear fallback for searchers who don't match either tagged version.

3. RTL layout needs to be built in, not bolted on

Arabic requires right-to-left layout — not just mirrored text, but mirrored navigation, icons, forms, and spacing. Sites that "support Arabic" by simply flipping text direction without adjusting layout logic often end up with broken alignment, awkward spacing, and a visibly unpolished Arabic experience that undermines trust.

4. Separate, real URLs for each language — not a toggle that hides content

Search engines need distinct, crawlable URLs for Arabic and English content (e.g. /ar/page vs /page) to index and rank both properly. A JavaScript toggle that swaps text without changing the URL is invisible to search engines — meaning only one language ever gets indexed.

5. Meta titles and descriptions need independent optimization per language

Each language version needs its own meta title and description, written for how people actually search in that language — not a literal translation of the other language's meta tags.

6. Watch for brand-name collisions in Arabic

One real issue I diagnosed on a Kuwaiti startup platform: the brand name was also a common Arabic verb, so unrelated generic usage of the word diluted the search results. If your brand name has a literal meaning in Arabic, this is worth checking early — before it becomes a ranking problem to untangle later.

7. Arabic fonts are a real, measurable performance cost

Poor Arabic font choices or inconsistent line-height hurt readability and increase bounce rate, which search engines factor into ranking through engagement signals. But there's a more direct cost too: many Arabic web fonts load at 300-500KB, heavy compared to a typical Latin font. Subset the font to only the characters actually in use and serve it as WOFF2, or that weight shows up directly in your Core Web Vitals — see what a perfect PageSpeed score actually means for SEO for how much page weight matters to the numbers Google measures.

The takeaway

A genuinely bilingual website is a technical SEO project, not just a translation task — proper hreflang implementation, real RTL design, separate URLs, and language-specific keyword strategy all matter more than the translation quality itself.

I build and optimize bilingual Arabic/English websites for Kuwaiti businesses, combining development with dedicated technical SEO. If you're planning a bilingual site or fixing an existing one, feel free to get in touch.

Frequently asked questions

Does hreflang need to point both ways?

Yes. The most common mistake is one-directional — English references Arabic, but Arabic never references back. Every version needs to point to every other version, including itself.

Should hreflang use "ar" or "ar-kw"?

For a Kuwait-specific business, ar-kw targets Arabic speakers in Kuwait specifically, while plain ar targets Arabic speakers anywhere. If the content and offer are Kuwait-specific, the region-tagged version is the sharper signal.

Do Arabic fonts actually slow a site down?

They can — many load at 300-500KB, heavy compared to typical Latin fonts. Subsetting to only the characters used, served as WOFF2, keeps this from becoming a real performance problem.

Can I use one URL with a language toggle instead of separate URLs?

No, not if you want both languages indexed. A toggle that swaps text via JavaScript without changing the URL is invisible to search engines — only one language version ever gets crawled.