Schema Markup in Arabic: A Working Guide
Structured data is language-neutral: property names stay in English, values go in Arabic. Here is how to write JSON-LD correctly for Arabic pages.
Schema markup works the same way in Arabic as in English: the property names stay in a fixed vocabulary, and you fill them with Arabic values. The one addition is the inLanguage property, set to ar, so search engines and AI assistants know which language the marked-up content is actually written in.
Structured data is one piece of a larger technical setup. If you have not yet settled where your Arabic pages live and how their URLs are written, start with the full Arabic SEO guide before you invest time in markup.
On this page
Why does schema markup matter for an Arabic page at all?
Structured data gives search engines and AI assistants an explicit, unambiguous description of a page's facts, instead of leaving them to infer everything from the prose [1]. That matters more in Arabic than in English, because assistants and search engines generally have less training data and fewer examples to draw on for Arabic content, so an explicit JSON-LD block reduces the guesswork they would otherwise have to do.
It also protects you from a common failure mode on bilingual sites: markup that was copied from the English page and never updated, so an Arabic page's JSON-LD still describes English text, English prices or an English author name that does not match what is on screen. That mismatch is confusing to a crawler and, if a human ever inspects the page source, looks careless.
How do you set the language correctly in JSON-LD?
Add "inLanguage": "ar" to the top-level object describing your Arabic content, alongside the Arabic values for every other property. This is a separate signal from hreflang: hreflang tells search engines which URL to show to which searcher, while inLanguage tells them, and any assistant reading the markup directly, what language the described content is actually in [2].
{
"@context": "https://schema.org",
"@type": "Article",
"inLanguage": "ar",
"headline": "دليل تحسين محركات البحث للمحتوى العربي",
"author": {
"@type": "Person",
"name": "إبراهيم هلال"
},
"datePublished": "2026-09-23"
}
Notice that @type, headline, author and datePublished stay in English — they are keys in a fixed vocabulary schema.org defines once for every language [2]. Only the strings you assign to them, the actual headline text and the author's name, are written in Arabic.
Which schema types matter most for an Arabic site?
Start with the types that touch every page before moving to specialised ones. Organization schema, present once sitewide, should carry your Arabic legal name if you use one, alongside the English name, plus sameAs links to any Arabic-language profiles you maintain [5]. Article schema belongs on every Arabic blog post, with an Arabic headline, an Arabic author name matching the byline shown on the page, and the same inLanguage treatment.
| Schema type | Where it belongs | What must be in Arabic |
|---|---|---|
| Organization | Every page, usually via a shared template | Arabic legal name, Arabic description |
| Article | Every Arabic blog post | Headline, author name, article body summary if used |
| FAQPage | Posts and pages with a real FAQ section | Every question and every answer |
| LocalBusiness | Location or contact pages | Address fields, business name, hours description |
| BreadcrumbList | Any page with a visible breadcrumb trail | The name of each breadcrumb item |
Article schema is worth getting right first, because it appears on the most pages and is the easiest to get wrong by accident [3]. Every Arabic post should carry its own headline, its own author, matching whichever founder's byline actually appears on that page, and its own datePublished — copied fields from a shared English template are the single most common defect we find on a first audit.
FAQPage schema deserves particular care on Arabic posts, because both the question and the answer text must be marked up in full, matching what a reader actually sees on the page, not a shortened or translated-back version of it [4]. If your Arabic FAQ answers are genuinely rewritten rather than translated word for word from English, as we recommend in translation vs transcreation, make sure the markup reflects the rewritten Arabic, not the original English draft someone forgot to update.
How do you implement this without duplicating work?
Template the parts that repeat and vary only the parts that change per page. Organization and site-wide markup should render from one source of truth with an Arabic branch, not be hand-copied onto every page. Article and FAQPage markup should pull directly from the same content fields that render the visible Arabic text, so the markup can never drift from what a reader sees.
Generate markup from your content source, not by hand
Pull headline, author and date values from the same fields the page itself renders, so they cannot silently diverge.
Set inLanguage per page, driven by the page's own locale
Do not hardcode ar everywhere; derive it from the same locale flag that controls the page's dir and lang attributes.
Validate with a real testing tool before publishing
Paste the rendered JSON-LD into a structured data testing tool and confirm it parses with no errors on the Arabic values specifically.
Re-check after any content edit
An editor who updates the visible Arabic FAQ answer but not the underlying field will silently break this; build the check into your publishing step.
How does this interact with where your Arabic pages live?
Not much technically, but it is worth confirming once. Whether your Arabic section sits on a subfolder or a subdomain — see subfolder vs subdomain for Arabic if that is still an open question — structured data should describe the URL the page actually lives at, including the correct canonical, so a crawler never receives markup that points at a different structure than the one it just fetched.
This is where a copy-paste mistake between structures shows up most often. A team that migrates from a subdomain to a subfolder, or the reverse, frequently updates the visible canonical tag and the sitemap but forgets that the JSON-LD url field on every template still points at the old address. Search that field specifically after any structural migration, because it is easy to miss and it directly contradicts the canonical tag sitting right above it in the page head.
Does structured data help with Arabic voice search too?
Indirectly, yes. FAQPage and Article markup both make it easier for an assistant to extract a clean, complete answer to a specific question, which is exactly the shape a spoken query expects back. We cover the voice side of that separately in Arabic voice search, but the two pieces of work reinforce each other: markup that accurately describes a well-structured Arabic answer is more likely to get read aloud correctly than markup layered on top of a vague one.
What common mistakes should you check for first?
The most frequent one is markup left over from an English template: an Arabic page whose JSON-LD still has an English headline or an English author.name, usually because a developer built the Arabic template by copying the English one and only translated the visible text. The second is missing inLanguage entirely, which is easy to skip because the page still validates without it — it just leaves an assistant guessing.
The third is a schema author name that does not match the visible byline, which matters for E-E-A-T signals as much as for consistency, since a mismatched name looks, at best, unmaintained. Fix these in the order they cause the most damage: language mismatches first, then missing types, then cosmetic inconsistencies.
A fourth mistake is subtler and shows up only after a redesign: markup that still validates but describes a page that no longer exists in that shape, because a developer changed the visible layout — merged two sections, removed a byline, restructured the FAQ — without touching the JSON-LD sitting underneath it. Structured data does not break loudly when this happens; it just quietly stops matching reality, and nothing in a normal QA pass catches that unless someone specifically checks it.
Build that check into your release process rather than your memory. A short rule that says "any change to headline, author, date or FAQ text requires a schema diff review" costs almost nothing to follow and catches the exact class of error that otherwise survives for months. Treat structured data as part of the content, not as a one-time technical setup task you finish and forget.
How do you know the markup is actually working?
Test it the way a crawler would, not just the way a human reads the page. Paste the rendered JSON-LD for a live Arabic page into a structured data testing tool and confirm it parses with zero errors on the Arabic-specific fields — a block that validates in general but silently drops non-Latin characters because of an encoding issue is a common and easy-to-miss failure.
Then check your indexing reports periodically for any drop in rich result eligibility on Arabic pages specifically, separate from the English ones. A sitewide dashboard that blends both languages can hide an Arabic-only regression for weeks before anyone notices the pattern.
Questions people also ask
Do schema property names need to be translated into Arabic?
No. Property names such as name, author and datePublished always stay in English or their defined schema.org form; only the values you assign to them go in Arabic.
What does the inLanguage property actually do?
It tells search engines and assistants which language the content described by the markup is written in, separately from the page's hreflang tag, and it should be set to ar on every Arabic page.
Can one page carry both English and Arabic structured data?
Avoid it. Each language version should carry its own markup describing only that version's content; mixing them makes it unclear which language a title or description actually belongs to.
Does structured data help AI assistants understand Arabic pages?
It helps them parse the page's facts reliably even when the surrounding prose is dense, which matters more in Arabic because assistants have less training data to fall back on for the language.
Sources
- Introduction to structured data markup — Google Search Central (checked 23 September 2026)
- Getting started with schema.org — Schema.org (checked 23 September 2026)
- Article structured data — Google Search Central (checked 23 September 2026)
- FAQPage structured data — Google Search Central (checked 23 September 2026)
- Organization structured data — Google Search Central (checked 23 September 2026)
Get your structured data checked against your actual Arabic pages
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Arabic SEO: the complete guide for 2026Arabic SEO is ranking pages written for Arabic searchers: research in Arabic, write natively, build a clean /ar/ section and earn Arabic links.
- 12 Arabic Link Building Sources That WorkArabic backlinks come from news sites, directories, universities, associations and original data, not bought link packages. Here is where to start.
- Subfolder vs Subdomain for Arabic: Which to UseA subfolder like /ar/ shares your domain's authority; a subdomain runs independently. Here is how to choose for an Arabic section of your site.
- Arabic Voice Search: What Changes for SEOArabic voice queries are longer, more dialectal and phrased as full questions. Here is what that means for how you write and structure a page.