Arabic Site Search Normalization: 20 Arab Online Stores Tested

Arabic site search still breaks on simple spelling differences. On 8 October 2026 we ran four spelling pairs through the on-site search of 20 online stores in Saudi Arabia, the UAE and Egypt. Only 4 of 20 returned the same products for every pair, and the taa marbuta versus haa pair split results on 10 of the 20.

Key takeaways

• We searched 20 storefronts (12 Saudi, 3 UAE, 5 Egyptian) on 8 October 2026 with four spelling pairs. 4 of 20 returned the same products for every pair we tested: the three Amazon storefronts and a Saudi pharmacy chain.
• Taa marbuta versus haa was the weakest pair: the same results on 10 of 20 stores, a different ranking on 3 and different products on 7.
• Arabic-Indic digits returned zero products on 3 stores, and 5 of the 19 stores we could test on digits lost or changed results.
• All 4 Salla stores matched digits and all 4 split at least one letter pair. Both Zid stores we could test on digits returned nothing for Arabic-Indic numbers.
• Elasticsearch’s built-in arabic analyzer already chains decimal_digit and arabic_normalization, which together cover all four pairs.

Results across 20 Arab storefronts

Most pairs worked on most stores, yet 16 of 20 stores failed at least one pair. Across 74 paired searches, 51 (69%) returned the same products for both spellings. Three returned the same matches in a different order, and 20 returned different products or none. Taa marbuta was the weakest pair and alef madda the strongest.

Each pair is one product word typed two ways. We picked words that exist in each catalog, so a coffee store got coffee words and a pharmacy got skincare words. The table counts results as “first spelling vs variant”.

“Not tested” means the catalog had no product word with that feature, so a pair would have compared zero with zero. Five food and perfume stores had no word with alef madda, and one store had no numbers in its product names.

Why do four spellings of one word split Arabic search results?

Each variant is a different Unicode character, and a search engine treats two characters as equal only when its analyzer maps them to one form. We found both forms inside the stores themselves. Four stores in our sample spelled their own products with the variant form, so a shopper who types the textbook spelling can miss real stock.

The coffee store’s own menu spells coffee, qahwa, with a final haa. The honey store writes habba (piece) with haa, the Salla dates store writes abyad (white) with no hamza, and the perfume store writes a’wad (incense sticks) with no hamza. Here is what each pair changes at the code point level:

• Hamza on alef: alef with hamza above (U+0623) or below (U+0625) against bare alef (U+0627).
• Alef madda: U+0622 against bare alef U+0627, as in one Arabic spelling of iPhone.
• Taa marbuta vs haa: U+0629 against U+0647 at the end of a word, as in sa’a (watch).
• Digits: Arabic-Indic digits U+0660 to U+0669 against 0 to 9. The W3C Arabic Layout Requirements list Arabic-Indic digits as the ones used in Egypt and Saudi Arabia, and Extended Arabic-Indic digits (U+06F0 to U+06F9) for Iran and Afghanistan.

Lucene’s ArabicNormalizer covers the first three: it turns the hamza and madda alef forms into bare alef, taa marbuta into haa and alef maksura into yaa, and removes the short-vowel marks and tatweel. Digits need a separate filter.

Which stores and platforms lost results?

The failures clustered by platform. The three Amazon storefronts and one Saudi pharmacy chain matched every pair. Salla stores matched every digit query but split at least one letter pair in all 4 stores. Zid stores matched most letter pairs and returned nothing for Arabic-Indic digits in both stores we could test.

The widest single gap came from an Egyptian electronics retailer on Magento. Typing the word for devices, ajhiza, with hamza returned 7 product cards; without hamza it returned 42, and none of the 7 appeared in the 42. The same store returned 45 cards for an iPhone 15 query in Western digits and none for the identical query in Arabic-Indic digits.

Three stores returned zero products when the shopper typed the same number in Arabic-Indic digits. Two more changed the results. An Egyptian appliance retailer dropped from 1,171 results to 172. A UAE electronics retailer ignored the number and showed iPhone 18 cases for an iPhone 15 query.

The subtlest case was a Saudi retailer on a hosted search API. Both watch spellings returned exactly 1,396 results. Matching was normalized, yet none of the first 40 products overlapped. The API response showed pinned products attached to the taa marbuta spelling only, so the merchandising rule fired for one spelling and not the other.

How do you normalize Arabic in Elasticsearch or OpenSearch?

Run one analyzer at index time and query time, and make sure it contains arabic_normalization and decimal_digit. The built-in arabic analyzer in Elasticsearch already chains lowercase, decimal_digit, stop words, arabic_normalization and a stemmer, so a field mapped with it collapses all four of the pairs we tested.

Elastic’s language analyzer reference shows that chain as a rebuilt custom analyzer. The decimal_digit filter converts every digit in the Unicode Decimal_Number category to 0 to 9. For product names we prefer a lighter chain without the stemmer. Add a stemmed subfield later if recall testing asks for it:

PUT /products
{
  "settings": {
    "analysis": {
      "analyzer": {
        "ar_product": {
          "tokenizer": "standard",
          "filter": ["lowercase", "decimal_digit", "arabic_normalization"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": { "type": "text", "analyzer": "ar_product" }
    }
  }
}

GET /products/_analyze
{
  "analyzer": "ar_product",
  "text": "\u0623\u062C\u0647\u0632\u0629 \u0661\u0665"
}
// expected tokens: "\u0627\u062C\u0647\u0632\u0647" and "15"

JSON accepts \u escapes, so you can paste test strings into _analyze without an Arabic keyboard. The icu_folding filter applies Unicode-wide folding rules based on UTR#30. Run your own catalog terms through _analyze before you swap it in. OpenSearch documents a built-in arabic analyzer as well; check its filter chain the same way.

If you would rather have a developer run these four pairs against your own catalog and fix the analyzer, get my store’s Arabic search checked.

Algolia settings and MySQL collations

Algolia ignores four common Arabic diacritics by default and treats the Arabic and Persian forms of kaf and yaa as equal. Its normalization guide lists no rule for hamza, taa marbuta or Arabic-Indic digits. Add those yourself with customNormalization. In MySQL, test your collation with WEIGHT_STRING() before trusting it, and keep a normalized column for search.

Algolia’s normalization guide says normalization runs at indexing and query time and cannot be turned off. The customNormalization setting maps one input character to at most two output characters, and it does not apply to decomposed sequences built with combining marks:

{
  "customNormalization": {
    "default": {
      "\u0623": "\u0627", "\u0625": "\u0627", "\u0622": "\u0627",
      "\u0629": "\u0647",
      "\u0660": "0", "\u0661": "1", "\u0662": "2", "\u0663": "3", "\u0664": "4",
      "\u0665": "5", "\u0666": "6", "\u0667": "7", "\u0668": "8", "\u0669": "9"
    }
  }
}

MySQL’s Unicode collation documentation describes utf8mb4_0900_ai_ci as accent-insensitive and case-insensitive, built on UCA 9.0.0. Its list of language-specific collations includes Persian and no Arabic tailoring. Check what your collation does with the hamza forms:

SELECT
  HEX(WEIGHT_STRING(_utf8mb4 0xD8A3 COLLATE utf8mb4_0900_ai_ci)) AS alef_hamza_above,
  HEX(WEIGHT_STRING(_utf8mb4 0xD8A7 COLLATE utf8mb4_0900_ai_ci)) AS bare_alef;
-- different weights = LIKE and = treat the two spellings as different words

For a LIKE-based search we would not rely on the collation at all. Store a normalized copy of the name in its own indexed column, built by the function in the next section, and query that column.

A normalization function in JavaScript and PHP

When search runs on a database query or a small in-house index, normalize in application code. Write a normalized copy of each product name when the product is saved, and pass every incoming query through the same function before it reaches the index. The mapping below mirrors Lucene’s ArabicNormalizer and adds both Arabic-Indic digit ranges.

// JavaScript: run on product text at save time AND on every search query
const AR_MAP = {
  '\u0622': '\u0627', // alef with madda above -> alef
  '\u0623': '\u0627', // alef with hamza above -> alef
  '\u0625': '\u0627', // alef with hamza below -> alef
  '\u0629': '\u0647', // taa marbuta -> haa
  '\u0649': '\u064A', // alef maksura -> yaa
};

export function normalizeArabic(input) {
  return input
    .normalize('NFC')
    .replace(/[\u064B-\u0652\u0640]/g, '') // short vowels, shadda, sukun, tatweel
    .replace(/[\u0622\u0623\u0625\u0629\u0649]/g, (ch) => AR_MAP[ch])
    .replace(/[\u0660-\u0669]/g, (d) => String(d.charCodeAt(0) - 0x0660))
    .replace(/[\u06F0-\u06F9]/g, (d) => String(d.charCodeAt(0) - 0x06F0))
    .toLowerCase()
    .trim();
}

// PHP 7.4+ (arrow functions): same mapping, using \u{...} string escapes and /u regexes
function normalize_arabic(string $s): string {
    $s = preg_replace('/[\x{064B}-\x{0652}\x{0640}]/u', '', $s);
    $s = strtr($s, [
        "\u{0622}" => "\u{0627}", "\u{0623}" => "\u{0627}", "\u{0625}" => "\u{0627}",
        "\u{0629}" => "\u{0647}", "\u{0649}" => "\u{064A}",
    ]);
    $s = preg_replace_callback('/[\x{0660}-\x{0669}]/u',
        fn ($m) => (string) (mb_ord($m[0], 'UTF-8') - 0x0660), $s);
    $s = preg_replace_callback('/[\x{06F0}-\x{06F9}]/u',
        fn ($m) => (string) (mb_ord($m[0], 'UTF-8') - 0x06F0), $s);
    return mb_strtolower(trim($s), 'UTF-8');
}

We ran the JavaScript version against the electronics pairs from our test, and each pair produced identical output. String.prototype.normalize runs first so composed and decomposed sequences compare equal, and the PHP \u{…} escape needs double-quoted strings.

What can Salla and Zid store owners change?

Not the matching engine. Neither platform exposes analyzer settings to merchants in the documentation we read, so the levers are product text, theme code, search apps and testing. In our sample Salla matched digits in all 4 stores and split letter pairs, while Zid matched most letter pairs and failed Arabic-Indic digits in both stores we could test.

What owners and theme developers can change:

• Product names: put the spelling your customers type in the product name and the variant in the description. Four stores in our sample used variant spellings in their own catalogs, so start by searching your catalog for both forms.
• Tags: Salla’s Merchant API has Product Tags endpoints. The docs do not say whether storefront search reads tags, so tag one product with a variant and search for it first.
• Theme code on Salla: the Twilight SDK exposes salla.product.search, which the Search web component uses. A theme can clean the query before it is sent, but that only helps when the catalog text is written the same way.
• Theme code on Zid: the live search box on the Zid stores we tested called a same-origin products API with the raw query. Converting Arabic-Indic digits to Western digits in the query before that call would have turned both zero-result cases into matches, because those catalogs wrote numbers in Western digits.
• Search apps: third-party search apps for Salla and Zid advertise Arabic-aware matching. Test the four pairs on a trial first.

What they cannot change: the platform’s tokenizer, normalization rules or default ranking. Our Salla and Zid store SEO audit covers the crawlable side of the same stores.

Our read

Treat Arabic normalization as a correctness bug. A zero-result page for a product you stock ends the search, and no ranking change rescues a product the engine never matched. Fix digits first because they cause the zero-result failures, then hamza and taa marbuta, then key every merchandising rule to the normalized query.

Digits are the cheapest fix. The Amazon storefronts show the whole job is solvable across three Arab markets at once: 12 of 12 pair tests matched. The hosted-search case shows the trap on the other side. Matching was normalized, but the pinned products were keyed to one spelling, so shoppers who typed the haa spelling saw a different first page.

Normalize once, in one function, and run it on both sides of the search. Over-normalizing has a cost: mapping taa marbuta to haa merges words that differ only in that last letter. For product search we accept that trade, because missing stock costs more than a wider result set. Dictionaries need stricter rules. Keep normalization out of URLs and display text; it belongs in the index only. Our guide to Arabic URL slugs covers the URL side.

How we checked

We searched 20 storefronts on Thursday 8 October 2026, between about 12:00 and 12:50 Cairo time. We used desktop Chrome on a Cairo connection, signed out, and added nothing to a cart. Each store got one run of at least eight queries plus a same-query control, so run-to-run noise was measured but not repeated on another day.

• Sample: 12 Saudi, 3 UAE and 5 Egyptian storefronts, including 4 Salla and 3 Zid stores identified from their page source. A Kuwaiti retailer blocked us with an access-denied page and is not counted. Amazon and the regional marketplace count once per country storefront.
• Reading results: the store’s own search URL or search endpoint, called from the store’s own origin, or the results page loaded after typing in the search box.
• Scoring: “Same” means counts within 1% and at least 8 of the first spelling’s top 10 products found on the variant’s first page. Sponsored listings were excluded on Amazon.
• Limits: one point in time; page-1 counts where a store shows no total; Salla counts capped at 150; one Saudi electronics retailer measured on its six-product dropdown because its search box opens no results page; no field data on how often shoppers type each spelling.

FAQ

Why does my store search show nothing for a product we stock?

Check spelling variants first: two valid spellings of one word can reach different products. In our test of 20 Arab stores on 8 October 2026, 3 returned zero products for a number in Arabic-Indic digits. One Egyptian store returned 7 products instead of 42 when the word carried a hamza. Test four pairs on your search box.

Does Arabic normalization make search results less precise?

It widens them. Mapping hamza and madda forms to bare alef and taa marbuta to haa merges words that differ only in those letters, so result sets grow. For product search we accept that trade, because a product that never appears in results cannot be bought. Dictionaries and religious-text search need stricter rules.

Can I fix Arabic search on Salla or Zid without a developer?

Partly. You cannot change the platform’s matching rules, but you can write product names in the spelling customers type, add the variant to descriptions, and test a search app on trial. In our test Salla handled digits in all 4 stores, while both Zid stores we tested on digits failed Arabic-Indic numbers.

Do Arabic-Indic digits matter if our catalog uses Western numbers?

Yes. The mismatch starts in the query, so a clean catalog does not prevent it. The W3C Arabic Layout Requirements list Arabic-Indic digits as used in Egypt and Saudi Arabia. In our test 5 of 19 stores lost or changed results when a shopper typed the same number in Arabic-Indic digits, including 3 that showed nothing.

How do I test my own store’s Arabic search?

Pick four product words from your catalog: one with hamza on alef, one ending in taa marbuta, one with alef madda and one containing a number. Search each word both ways, count the results and compare the first ten products. Any gap means your index and query are normalized differently.

A better test than “does our engine support Arabic” is simple: do two spellings of the same product word reach the same products? If your stack is Elasticsearch, OpenSearch, Algolia or your own code, add the normalization above to the index and the query, then rerun the four pairs. If you are on Salla or Zid, fix the catalog spelling first and test digits before anything else. Slow results pages are a separate fix, covered in our Core Web Vitals study of Arab websites. If you want your product pages found in Google as well as in your own search box, help me get my Arabic product pages ranking.