Web Development

Ecommerce website development for Arabic and English stores

A good online store loads fast on a phone, lets shoppers find products in Arabic and English, takes payment without exposing card data and gives search engines clean product pages. The first big decision is a hosted platform or a headless build. This page walks through that choice and the parts that decide whether a store sells.

Start a project

Storefront performance

Category and product pages are where speed pays, because shoppers arrive from search and ads and leave quickly when a page stalls. Product images are usually the heaviest part of a page, so they get the most attention first.

  • Serve responsive images in modern formats at the size they are shown, and load the main product image eagerly and the rest lazily.
  • Keep third-party scripts, such as chat widgets, tag managers and review tools, to the few that earn their cost, and load them after the page is usable.
  • Reserve space for images and banners so the layout does not jump while the page loads.
  • Measure Core Web Vitals on real mid-range phones, not only on a fast laptop.

For a custom storefront, category and product pages are usually built ahead of time or regenerated on a schedule, while the cart and account pages are rendered per visitor. Next.js development explains these rendering choices.

Headless commerce or a hosted platform?

A hosted platform is one product that includes the storefront, the admin and the checkout. A headless build keeps the commerce back end, which holds the catalogue, the cart and the orders, and puts a custom front end on top through an API. It is the same idea as a headless CMS, applied to the shop.

QuestionHosted platformHeadless build
Time to the first saleUsually shorterLonger, because more is built
Design freedomWithin the platform's themes and limitsFull control, including bilingual layout
Arabic and right-to-leftDepends on the theme and apps, so test before choosingDesigned into the front end
Running cost and upkeepPlatform fees plus paid appsHosting plus a team that maintains the front end
CheckoutControlled by the platformYou integrate a payment provider's hosted page
Best forStandard catalogues and small teamsCustom experiences, many integrations, a bilingual brand

A hosted platform is often the right first store. Go headless when the platform's limits start to cost sales, or when bilingual design needs more control than its themes allow. Our article on web platform cost drivers explains what moves the cost either way, and a CMS can hold the editorial content around the shop.

Whichever route you take, test an Arabic product page, an Arabic search and a full checkout on the platform's demo before you commit. Right-to-left support varies widely.

Catalogue and search in Arabic and English

Each product needs both languages for its title, description, attributes and URL slug. Decide which fields are required in both languages before data entry starts, store attributes such as size and colour as structured values rather than free text, and have translations reviewed by a person rather than published straight from a machine.

Search that understands Arabic

  • Normalise spelling variants in both the index and the query: the different forms of alef, the endings taa marbuta and haa, yaa and alef maqsura, and optional diacritics.
  • Handle the definite article and common prefixes through stemming or a search engine with Arabic language analysis.
  • Accept mixed queries. Shoppers often type a brand in Latin letters and the product type in Arabic.
  • Add synonyms and transliterations for products that people name in more than one way.
  • Accept both Western and Arabic-Indic digits in queries.

Checkout and payments

The safest way to take cards is never to touch them. Use the payment provider's hosted payment page, or its secure embedded fields, so card numbers travel from the shopper's browser to the provider and never pass through your servers or logs. That reduces what you have to secure and prove under PCI DSS, the card industry's data security standard.

This is general awareness, not a compliance claim and not legal advice. Your payment provider or acquiring bank, and a qualified assessor if needed, can tell you which requirements apply to your store.

Checkout design is a security topic as much as a conversion topic:

  • Offer guest checkout, and ask for an account after the order.
  • Ask for as few fields as possible, and make phone and address forms fit the region. Do not make a postcode mandatory where customers may not have one.
  • Calculate prices on the server. Never trust a price sent from the browser.
  • Confirm payment from the provider's webhook, verify its signature and handle duplicate events.
  • Show clear failure messages, allow a retry, and prevent double charges.

Local payment methods in the Gulf

Shoppers in the Gulf often expect more than international cards: local debit card schemes, digital wallets, instalment services and, in some markets, cash on delivery. What is available depends on the country, the payment provider and your business registration. Ask your provider which methods it supports in each market and how settlement and refunds work for each, and build checkout so a new method can be added without a rebuild.

Product-page SEO

Product pages earn a store's search traffic, and they fail in predictable ways.

  • One indexable URL per product and language, with a real title, description and heading written in that language.
  • Alternate-language links between the Arabic and English versions of each page, and a canonical link on each.
  • Canonical links for variants and filtered lists, and a decision on which filtered pages deserve to be indexed.
  • Product structured data with name, image, price and availability. Add review markup only for genuine reviews.
  • Out-of-stock products keep their page, show availability and suggest alternatives. Redirect only when a product is gone for good.

The Arabic website development checklist covers the language-specific parts in more detail.

Fraud and account security

  • Card testing. Bots try many stolen card numbers on small orders. Defend with rate limits, bot checks and the payment provider's fraud tools.
  • Account takeover. Reused passwords are the usual cause. Offer multi-factor sign-in, rate-limit attempts and alert customers when an email or address changes.
  • Admin access. Use strong sign-in, narrow roles and a log of price changes and refunds.
  • Order lookups. Never let a guessable order number show someone's address. Use unguessable links.
  • Checkout pages. Keep third-party scripts to a minimum and restrict them with a content security policy.

Our secure-by-default web checklist lists the basics, and a store that handles customer accounts and payments is a good candidate for a deeper review under cybersecurity.

Mobile first, then everything else

Many shoppers browse and buy on a phone, so design the phone layout first and enlarge it for desktop afterwards.

  • A sticky add-to-cart button and large tap targets.
  • The right keyboard for each field, such as a numeric keypad for phone numbers, and autofill attributes on address fields.
  • Image galleries and carousels that mirror correctly in right-to-left.

Questions we get asked

  • Start with a hosted platform if your catalogue is standard and speed to market matters most. Choose a custom headless build when you need a distinctive bilingual experience, deep integrations or control that platform themes cannot give. Test Arabic product pages and checkout on any platform before you commit.

  • Your obligations depend on how card data flows through your business. A hosted payment page keeps card numbers off your servers, which reduces what you must secure and prove. Your payment provider or acquiring bank can tell you which requirements apply. We design for awareness of the standard and make no certification claim.

  • We normalise spelling variants and diacritics in both the index and the query, handle prefixes with Arabic language analysis, add synonyms and transliterations, and accept mixed Arabic and Latin queries. We then review searches that return no results, because they show exactly where the catalogue and the language disagree.

  • Yes. Keep one catalogue with a translation for each field, one URL per language, and shared stock and orders. The work is in the details: required fields in both languages, reviewed translations, alternate-language links for search engines and a checkout that mirrors correctly right-to-left.

  • The commerce platform manages products and orders, but landing pages, guides, campaigns and brand content are usually easier to run in a CMS, especially with two languages. A headless CMS can feed the same storefront, so editors work in one place without touching the shop's code.

Keep exploring

Ready to build something secure?

Tell us about your product. We will reply with a clear plan.

Start a project

We would like to use Microsoft Clarity to see how visitors use the site, so we can improve it. It sets cookies and is off unless you accept. Cookie policy