If your Arabic pages are indexed but rarely appear in rich results or AI answers, check the layer machines read first: the structured data. On many bilingual Saudi sites it was copied from the English version and never translated — English FAQ text on Arabic URLs, an English organisation name, the wrong language code. The fix is methodical: audit what each Arabic URL declares, rebuild it in the page's own language in priority order, and validate every template per language. Nothing here promises a rich result or an AI citation; it makes your Arabic pages eligible and unambiguous — the part you control.
The short answer: the schema Saudi pages need, in the language the page is written in
An Arabic page needs the same core types an English page needs — Organization or LocalBusiness for the entity, Article, FAQPage and BreadcrumbList on content pages, Product and Offer on product pages — but with every text value in Arabic, `inLanguage` set to the page's language, and one entity identity across both versions. Google's general guidelines set the governing rule: markup must describe content visible on the page, as the visitor sees it. For the general service-business baseline, start with our guide to structured data for service businesses; this article covers the Arabic-language layer on top.
The bilingual leak: English structured data sitting on Arabic URLs
The leak happens at build time. A template is written for the English site, the Arabic version inherits its JSON-LD, and nobody translates the block because it is invisible on the page. The Arabic URL then declares an English FAQ that does not exist on it, English breadcrumbs, and an organisation name matching only the English homepage. Each value may be valid schema in isolation; together they describe a page that is not the one being crawled.
Audit before you fix. List your main Arabic templates — home, service, article, product, location — extract the JSON-LD from one URL of each, and compare every text value against the visible Arabic page. Where they differ, the markup is the leak. The wider bilingual picture is covered by our guide to SEO for bilingual Arabic-English websites; hreflang and localisation live there, not here.
Rule one — markup must match the visible page, in Arabic where the page is Arabic
Google's guidelines are explicit: do not mark up content that is not visible to readers of the page, and do not mark up irrelevant or misleading content. Applied to a bilingual site, the JSON-LD on an Arabic URL describes that Arabic page — its Arabic headline, Arabic FAQ questions and answers, Arabic breadcrumb labels, prices as displayed. A translated value is not a courtesy to crawlers; it is the accuracy rule in a second language.
Build the fix into the template, not page by page: generate structured data from the same fields that render the visible page, per language, so a headline edit updates both.
Set the language properly: inLanguage, ar vs ar-SA, and one entity across both versions
Schema.org defines `inLanguage` as the language of the content, expressed with a code from the IETF BCP 47 standard. Use `ar` for Arabic generally, or `ar-SA` where the content is specifically the Saudi version — the same distinction your URLs and hreflang already draw; the rule is consistency, so code, page language and hreflang target tell one story. Apply it on page-level types that accept it, such as Article and FAQPage.
Then hold the entity steady. Both versions describe the same Saudi company, so give the organisation one stable identity: the same `@id` on both, both legal names where they differ by language (Arabic name as the Arabic `name`, English name as `alternateName`, reversed on the English version), and the same `sameAs` links. Two names, one identity is correct bilingual practice; two identities is fragmentation.
Priority 1 — Organization and LocalBusiness for the Saudi entity
Start where every page points: the entity. On the Arabic site, the Organization (or LocalBusiness, for a business with a location customers visit) should carry the Arabic legal or trading name as displayed on the Arabic pages, the Saudi address as it appears on the page, and contact details matching the Arabic contact page. Keep `@id` and `sameAs` identical to the English version so both resolve to one entity.
Do not let templates multiply this block: a theme, an SEO plugin and a local plugin can each emit an organisation, often disagreeing on the name's language. Choose one emitter and disable the rest.
Priority 2 — Article, FAQPage and BreadcrumbList on Arabic content pages
On Arabic articles, the Article markup's `headline` and description should be the Arabic ones the reader sees, with `inLanguage` set as above and author and publisher resolving to the same entity. FAQPage is the highest-leak type: its questions and answers must be the Arabic ones printed on that page — an English FAQ block under Arabic content describes a different page and fails the matching rule, however valid its syntax. BreadcrumbList is simpler and often forgotten: item names should be the Arabic labels shown in the trail, pointing at the Arabic URLs. Why this precision matters beyond classic results is covered in our explainer on how Google AI Overviews choose business citations: a system selecting a source to cite needs one page whose visible content and machine-readable description agree, in the query's language.
Priority 3 — Product and Offer schema on Arabic product pages
On Arabic product pages, Product and Offer values must mirror the Arabic page: the Arabic product name and description, the price and currency exactly as displayed, and availability matching what the page states. Generate markup from the same product record that renders the page, per language, so a price change cannot strand the schema. Mismatched prices or stale availability are accuracy failures, not formatting errors. Stores running schema inside a wider automation setup should also read our piece on e-commerce SEO automation for product pages: feeds move data, but the matching rule judges page and markup as one pair.
What not to mark up: review stars you cannot prove and schema with no visible twin
Google's guidelines prohibit marking up misleading content, and name fake reviews as the example. So: no AggregateRating unless the page genuinely displays reviews your customers gave and the numbers match them; no rating imported from another platform and presented as your own; no FAQ entries that exist only in JSON-LD; no offers for products the page does not sell; and no copying a competitor's richer markup. If the content is not visibly yours, in Arabic, on that URL, it does not go in the block.
Validate and monitor: Rich Results Test and Search Console, per language
Validate per URL and per language, because the English version passing proves nothing about the Arabic one. Run representative Arabic URLs through Google's Rich Results Test: it shows which types are detected, which are eligible, and which required properties are missing or invalid — Google's guidelines make completeness a condition of eligibility. Fix errors at the template.
Then monitor Search Console's enhancement reports, filtered to Arabic URLs, after every release touching templates, translations or plugins: a plugin update that re-enables an English organisation block is exactly the regression this catches. A check of this kind is part of a wider technical SEO audit.
Common mistakes on bilingual Saudi sites
The recurring mistakes are consistent: English JSON-LD inherited by Arabic templates; `inLanguage` missing, or set to English on Arabic pages; two organisation identities, one per language; FAQ markup that summarises rather than matches the visible Arabic FAQ; prices updated on the page but not in the Offer; ratings marked up without visible reviews; and validation run once, on the English homepage, then assumed to cover the site. One habit finds them all — compare markup with the visible page, per language, template by template.
FAQ
Should Arabic pages carry Arabic structured data, or is the English version enough?
Arabic pages should carry Arabic structured data. Google's guidelines require markup to describe the content visible on the page, so an Arabic URL declaring English FAQ text, headlines or breadcrumbs describes a page that is not the one being crawled. Keep the same types as the English version, with Arabic values, correct inLanguage, and one shared entity identity.
Should I use ar or ar-SA in inLanguage?
Use the code matching how the version is defined elsewhere: ar for Arabic generally, ar-SA where the content is specifically the Saudi version and your URLs and hreflang draw that distinction. Schema.org asks for an IETF BCP 47 code. Either can be right; inconsistency between code, page language and hreflang is what to avoid.
Does adding Arabic schema guarantee rich results or AI citations?
No. Valid, complete markup makes a page eligible for rich results; Google does not guarantee an eligible page will be shown with one, and no markup can promise an AI citation. Correct Arabic schema removes ambiguity: the machine-readable description of your Arabic page agrees with its visible content, in the query's language — the condition you control.
Can I mark up review ratings that are not shown on the page?
No. Google's guidelines prohibit marking up content not visible to readers, and name fake reviews as misleading content. Mark up ratings only where the page genuinely displays reviews, the values match what visitors see, and the reviews are your own customers' — on Arabic pages, in Arabic, exactly as displayed.
How do I check whether our Arabic schema is valid?
Test representative Arabic URLs — one per template — in Google's Rich Results Test, which reports detected types, eligibility and missing or invalid properties. Then watch Search Console's enhancement reports filtered to Arabic URLs after every template, translation or plugin change. Passing English pages prove nothing about Arabic ones.
Get your Arabic pages' structured data audited and fixed (CTA)
If your bilingual site grew by copying templates, the leak described here is probably already live on your Arabic URLs. WebStackRank's SEO services for Saudi Arabia include the per-language structured-data audit and template-level fix. Start from our Saudi Arabia hub, bring one Arabic URL per template, and we will show you what those pages currently declare.
