البيانات المهيكلة في المواقع العربية: ما الذي ترمّزه 28 صفحة رئيسية لعلامات تجارية عربية

Nearly half of Arab brand homepages ship no JSON-LD structured data. On 3 October 2026 we read the live markup of 28 Arabic homepages: 13 had none, including all 4 banks. Where structured data on Arabic websites does exist, it is mostly English markup copied across: 12 of 15 never declare a language, and 9 carry dead SearchAction code.

أبرز النقاط

• 13 of 28 Arabic homepages (46%) ship no JSON-LD, including 4 of 4 banks, 5 of 6 telecoms and 2 of 2 hospitals.
• 12 of the 15 homepages with JSON-LD never set inLanguage, and 5 name the brand only in Latin script.
• 9 of 28 still publish SearchAction for the sitelinks search box, a feature Google stopped showing in November 2024.
• A Saudi electronics retailer dumps 629 CMS menu objects into JSON-LD as invented @type values.

What do Arab brand homepages mark up in JSON-LD?

Commerce brands mark up; banks, telecoms and hospitals mostly do not. All 9 retail, fashion, pharmacy and delivery homepages in our sample ship JSON-LD, against 1 of the 12 bank, telecom and hospital homepages. Across all 28, 15 have JSON-LD, 14 declare an Organization-type node, and only 3 set inLanguage.

By country, 5 of 9 Saudi homepages carry JSON-LD, 4 of 6 in the UAE, 4 of 9 in Egypt, 2 of 2 in Qatar and 0 of 2 in Kuwait. Samples that small cannot rank countries; sector predicts the result better.

One caveat on our own headline. A Saudi telecom without JSON-LD has one microdata item, so 12 of 28 homepages carry no structured data in either format we checked.

كيف أجرينا الفحص

VOCTOS, 3 October 2026, desktop Chrome, logged out, from Cairo. We opened the Arabic homepage of each brand in our 2 October audit of Arab brand websites, waited 3 seconds (5 on one retry) and parsed every JSON-LD script in the live DOM: @type values including @graph, inLanguage, name script, sameAs, alternateName and potentialAction. We also counted microdata items and read og:locale tags and the title.

Limits: homepages only, one visit each. JSON-LD injected after about 3 seconds was not counted, and we ran no Rich Results Test. 28 sites were read; a UAE developer froze the tab and was excluded, and the 8 sites unreachable on 2 October were not retried.

What goes wrong in the markup that does exist?

The markup describes an English company sitting on an Arabic page. Of the 15 homepages with JSON-LD, 12 never declare inLanguage, 5 give the brand name only in Latin script, and only 4 use alternateName at all. The outbound links are healthier: 14 of 15 list sameAs profiles, between 2 and 12 each.

The Latin-only five, in Saudi Arabia, the UAE, Egypt and Qatar, are Arabic homepages whose markup names the company only in English.

The worst case is a Saudi electronics retailer. Its JSON-LD carries 629 @type values such as “MobileTabletNavNode” and “cmsitem_00833088”, which are CMS navigation objects, not schema.org types. The same blocks hold 543 Arabic-script names, the most in our sample, so Arabic is not what this site lacks.

A Saudi delivery app gets it right: inLanguage ar-SA, the brand name in both scripts, two alternateName values and og:locale ar_SA. No other homepage in our sample combines inLanguage, both scripts and alternateName.

Does SearchAction markup still do anything in Google?

Not in Google Search. Google announced on 21 October 2024 that it would stop showing the sitelinks search box from 21 November 2024, and removed its documentation on 29 November 2024. The leftover markup causes no errors, Google says. It is dead weight, and 9 of 28 homepages still ship it.

‏ farewell post for the sitelinks search box and its documentation changelog have the details: the change applied in every country and did not touch rankings or ordinary sitelinks.

SearchAction keeps coming back because SEO plugins add it. Rank Math’s knowledge base notes the removal, yet Rank Math still adds the search action to the homepage by default, and Yoast’s WebSite specification keeps it as an optional property. Both publish a filter to switch it off, shown below.

Keep the WebSite node, because it carries your site name. Drop its potentialAction.

Why do Arabic and English brand names belong in the same graph?

People search for many Arab brands by both names, and Google’s markup gives you one place to connect them. Google’s Organization documentation recommends name and alternateName and asks you to reuse your site name values. Site names work per domain, not per folder, so an /ar/ section cannot carry its own Arabic site name.

‏ Organization structured data guide says the markup helps Google disambiguate your organization, and that logo can influence the logo shown in results and in your knowledge panel. No property is required.

‏ site names documentation adds two rules for bilingual sites: WebSite markup must sit on the domain or subdomain home page, and alternateName takes several values in order of preference, optionally ending with your lowercase domain. With /ar/ and /en/ folders, alternateName is the documented place for the other-script name.

‏ guide to generative AI features says structured data “isn’t required for generative AI search,” and that no special schema.org markup exists for it. For ChatGPT, Claude and Perplexity we have no vendor documentation on JSON-LD use, so we make no claim there. The same Google guide says Search ignores llms.txt files. Our llms.txt check of Arab websites covers who publishes one anyway. And markup counts only if a crawler can fetch the page, which our robots.txt check of AI crawlers on Arab websites tested.

What does a correct bilingual Organization graph look like?

One Organization node with a stable @id, the main brand name in name, the other-script name and the domain in alternateName, plus logo, url and sameAs. A WebSite node references it, and each language version gets a WebPage node with inLanguage. Every page points to the same @id, so both languages describe one company.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Example Brand",
      "alternateName": ["ARABIC_BRAND_NAME", "example.com"],
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/assets/logo-512.png",
      "sameAs": [
        "https://www.linkedin.com/company/example",
        "https://x.com/example",
        "https://www.instagram.com/example"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "name": "Example Brand",
      "alternateName": ["ARABIC_BRAND_NAME", "example.com"],
      "url": "https://www.example.com/",
      "inLanguage": ["ar-SA", "en-SA"],
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://www.example.com/ar/#webpage",
      "url": "https://www.example.com/ar/",
      "name": "ARABIC_PAGE_TITLE",
      "inLanguage": "ar-SA",
      "isPartOf": { "@id": "https://www.example.com/#website" },
      "about": { "@id": "https://www.example.com/#organization" }
    }
  ]
}
</script>

Four rules make this hold up:

• Write ARABIC_BRAND_NAME exactly as the Arabic pages show it. Raw UTF-8 and \uXXXX escapes parse to the same string; let your serializer write escapes, since the Rich Results Test rejects malformed ones.
• Put the name your homepage uses most in name. Google’s site name system also reads the title, headings and og:site_name, and asks you to use one name consistently.
• Only mark up names readers can see. ‏ general structured data guidelines forbid marking up content that is not visible on the page.
• Reuse the same @id on every language version. The English WebPage changes url, name and inLanguage; the Organization stays identical.

How should html lang, hreflang, inLanguage and og:locale agree?

They should name the same language and region, written in two syntaxes. HTML lang, hreflang and inLanguage use hyphenated codes such as ar-SA; schema.org asks for IETF BCP 47 codes in inLanguage. Open Graph’s og:locale uses language_TERRITORY with an underscore, such as ar_SA. Four Arabic homepages in our sample contradict themselves.

‏ Open Graph protocol defines og:locale as language_TERRITORY with en_US as the default, and og:locale:alternate as the other locales the page exists in. Meta’s localization page lists ar_AR as its umbrella Arabic locale, an exception to that pattern, so we count ar_AR as valid.

Only 9 of 28 homepages set og:locale. Two match the page’s language and country (ar_SA, ar_EG), two use ar_AR, two use a hyphen (ar-sa, ar-eg), one uses bare ar, and two point elsewhere: en_AE on a UAE super-app’s Arabic URL and ar_SA on a Kuwaiti telecom.

The four contradictions: an Egyptian developer with html lang=”en-us” and og:locale ar-eg, the UAE super-app’s English title and en_AE on /ar-AE/, an Egyptian telecom declaring lang ar-SA, and the Kuwaiti telecom’s Saudi og:locale. Our audit of lang, dir and hreflang on Arab brand websites covers the html side.

What changes on Arabic branch and product pages?

Branch and product pages carry the markup that still produces rich results. LocalBusiness needs name and address on each branch page. Product snippets need name plus offers, review or aggregateRating. On Arabic pages the traps are prices written in Arabic-Indic digits and ratings the brand did not collect.

Give every branch its own page per language, with a LocalBusiness subtype and the branch name as that page shows it. Google’s LocalBusiness documentation lists name and address as required and recommends aggregateRating only for sites that capture reviews about other businesses. Our guide to السيو المحلي متعدد الفروع في السعودية والإمارات has the full branch template. On homepages, 4 of 15 carry a Store, LocalBusiness or RealEstateAgent node, which covers one location at most.

For products, the visible price can use Arabic-Indic digits, but the markup cannot. The schema.org price guidelines ask for digits 0 to 9 (U+0030 to U+0039), a full stop as the decimal mark, and an ISO 4217 currency code. Google’s product snippet guide types price as a number.

"offers": {
  "@type": "Offer",
  "price": "1299.00",
  "priceCurrency": "SAR",
  "availability": "https://schema.org/InStock"
}

Use SAR, AED, EGP, QAR or KWD, never a currency word or symbol. Only 1 of 15 homepages with JSON-LD, a UAE electronics retailer, carries Product markup; product pages were outside our check.

What do Rank Math and Yoast output on an Arabic WordPress site?

Both build a connected @graph with WebSite and Organization nodes, and both can attach SearchAction to the WebSite node. Yoast’s specification adds inLanguage to WebPage and WebSite. Rank Math keeps the website name, one alternate name and the organization name in its Local SEO settings, which is where the Arabic name goes.

• Yoast SEO. ‏ WebSite piece allows an array of inLanguage values for multilingual sites, and the WebPage piece adds inLanguage per page. Its Open Graph specification outputs og:locale as language and territory, falling back to language only, and lists no og:locale:alternate tag.
• Rank Math. Under Titles and Meta, then Local SEO, the Organization settings hold Website Name, Website Alternate Name (output as alternateName), Organization Name and a logo of at least 112 by 112 pixels. The knowledge base pages we read do not mention inLanguage, so check your own output.

// Yoast SEO: remove SearchAction from the WebSite node
add_filter( 'disable_wpseo_json_ld_search', '__return_true' );

// Yoast SEO: set the Arabic name and the domain as alternateName
add_filter( 'wpseo_schema_website', function ( $data ) {
    $data['alternateName'] = [ 'ARABIC_BRAND_NAME', 'example.com' ];
    return $data;
} );

// Rank Math: remove SearchAction (add to rank-math.php in the theme)
add_filter( 'rank_math/json_ld/disable_search', '__return_true' );

In our sample, an Egyptian payments brand with a plugin-style @graph is one of only 3 homepages that set inLanguage. If your templates mix a plugin graph with hand-written blocks, review the JSON-LD on my Arabic and English templates.

How do you test structured data on an Arabic page?

Test the rendered page, not the template. Run the URL through Google’s Rich Results Test for features Google supports, the Schema Markup Validator for everything else, and URL Inspection in Search Console for what Googlebot saw. Then read the live DOM yourself, because none of these tools compares your language signals for you.

// Paste in the DevTools console on the live Arabic page
document.querySelectorAll('script[type="application/ld+json"]').forEach((s, i) => {
  try {
    const data = JSON.parse(s.textContent);
    [].concat(data['@graph'] || data).forEach(n =>
      console.log(i, n['@type'], n.inLanguage || 'no inLanguage', n.name || ''));
  } catch (e) {
    console.warn(i, 'invalid JSON:', e.message);
  }
});
console.log('html lang:', document.documentElement.lang,
  '| og:locale:', document.querySelector('meta[property="og:locale"]')?.content);

1. Rich Results Test. ‏ صفحة المساعدة says it takes a URL or pasted code, fetches as Google-InspectionTool with a smartphone agent by default, and shows the rendered source. It ignores comments inside JSON-LD, which the standard does not allow, so strip them before release.
2. Schema Markup Validator. الاستخدام validator.schema.org for site name markup, which Google says the Rich Results Test does not support, and for types outside Google’s list.
3. URL Inspection and reports. After release, inspect the live URL and watch the rich result and Unparsable structured data reports; Google’s structured data introduction warns that templates can break markup after deployment.
4. Repeat after every plugin or theme update. Google reads JSON-LD injected by JavaScript, but a quick audit like ours misses anything that arrives late.

رأينا

For banks, telecoms and hospitals the gap is basic: 1 of 12 in our sample ships any JSON-LD. One Organization node and one WebSite node on the homepage, with the Arabic name in alternateName, a logo and sameAs, is a small change to one template.

For commerce brands the job is cleanup. Remove SearchAction, stop serializing CMS objects into JSON-LD, set inLanguage on each language version, and make og:locale and html lang agree with hreflang.

Do not sell schema as an AI visibility switch. Google says its AI features do not require structured data. What we can defend is eligibility for rich results and one consistent record of who you are, in both scripts.

What should you fix first?

The useful question is not whether your homepage has schema. It is whether your Arabic and English pages describe the same company, in the language each page is written in. Run the console snippet above and compare the four language signals.

If your homepage already has one Organization node with the Arabic name, inLanguage on each version and matching og:locale values, move on to branch and product pages. If not, fix the homepage graph and the language signals first, because every other page points back to them. For the search side, check how search engines read my brand in Arabic and English.

الأسئلة الشائعة

Does structured data help my site appear in Google AI Overviews?

Google says structured data is not required for its generative AI features and that no special schema.org markup exists for them. It still recommends structured data for rich result eligibility. A page must be indexed and eligible for a snippet to appear in AI Overviews, so crawlability and useful content come first.

Should the schema on our Arabic page use the Arabic or English brand name?

Use the name the page shows. Keep one Organization node, shared across both languages through the same @id, with the main brand name in name and the other-script name in alternateName. On the Arabic WebPage node, write the page title in Arabic and set inLanguage to match the html lang attribute.

Is og:locale ar_AR wrong for an Arabic page?

Not for Meta. Meta’s developer documentation lists ar_AR as its umbrella locale for Arabic, an exception to its usual language and country pattern. Values such as ar_SA or ar_EG also follow the Open Graph format. A hyphen breaks that format, as in ar-sa, which 2 of the 9 homepages with og:locale used.

Do we need to remove old sitelinks search box markup?

Not to avoid errors. Google said the unsupported markup causes no problems in Search and no Search Console errors after it retired the feature in November 2024. We still remove it, because 9 of 28 Arab homepages carry it and it signals that nobody has reviewed the template since then.

Our site runs Yoast or Rank Math. Is our schema already correct?

Partly. Both plugins build a connected graph with WebSite and Organization nodes and can add SearchAction. Check three things in the rendered source: an Arabic alternateName, inLanguage on the Arabic pages, and an og:locale in language_TERRITORY form. Yoast and Rank Math each publish a filter that switches SearchAction off.