Data Terstruktur Multibahasa: Lokalkan JSON-LD pada URL Tiap Versi Bahasa dan Wilayah

Multilingual structured data is easy to get wrong when teams treat JSON-LD as a site-wide English snippet pasted onto every locale URL. Search engines and answer systems consume structured data as a description of the page at a specific URL. If your French product page still declares inLanguage: en, English name values, and a canonical entity graph copied from the US site, you send mixed signals that undermine both traditional indexing and answer-engine clarity.

This guide explains how to localize schema.org markup per crawlable locale URL, align JSON-LD with hreflang and canonicals, keep organization and product entities consistent, and QA a multilingual schema launch—grounded in Google’s multilingual documentation and truthful schema practice. No invented ranking boosts: structured data helps systems understand content; it does not compensate for thin translations.

Pertanyaan yang dijawab dalam panduan ini

• Why does structured data need to be localized per language URL?
• How should inLanguage and alternate language pages be represented?
• What schema types matter most for multilingual sites?
• How do hreflang and canonicals interact with structured data?
• What mistakes create mixed-language or duplicate entity markup?
• How should organization and product entities stay consistent across locales?
• How does structured data support answer engines without inventing ranking factors?
• What QA checks belong in a multilingual schema launch?

Quick answer: localize schema on each crawlable locale URL

Short answer: Emit JSON-LD on every crawlable locale URL that truthfully describes the visible page in that language—correct inLanguage, localized text properties, accurate url, and entity identifiers that stay consistent across markets.

Google recommends different crawlable URLs for each language or region version rather than cookies or browser language alone. Structured data should describe the page users and crawlers see at that URL, not a single shared English shell injected globally.

Each block should reflect the same language as the primary visible content. Google determines page language primarily from visible content; schema that contradicts the body creates unnecessary reconciliation work for crawlers.

Why structured data follows language-version architecture

Structured data is not a separate international SEO layer floating above URL architecture—it mirrors it. When you publish /de/produkt/widget, the JSON-LD on that URL should describe the German page: German titles, descriptions, offers where applicable, and inLanguage set to a valid BCP 47 tag such as de or de-DE.

Language versions need distinct crawlable URLs; structured data should describe the page users and crawlers see at that URL, not a single shared English shell. If your CMS renders one global schema partial, you inherit English entity names on every locale—a common source of mixed-language rich result eligibility issues and weak answer-engine summaries.

Hreflang tells search engines about alternates; structured data tells them what the current page is about. Both must agree that each URL is a complete language version, not a duplicate pretending to be another language.

For strategy context on language versus country targeting, read international SEO versus multilingual SEO.

Core properties: inLanguage, url, and entity identity

Three properties deserve first-pass scrutiny on every locale template:

inLanguage — Use a valid language or locale code matching the page. Do not leave English on localized URLs. When you target regional variants (en-GB vs en-US), align with your hreflang codes.

url — Should resolve to the canonical URL of the page being described—typically the same URL in the browser bar for that locale, not the English homepage.

Entity @id or stable identifiers — Organization and product entities often need consistent IDs across locales (https://example.com/#organization) while localizing human-readable properties. Consistent IDs help systems recognize the same brand or SKU across languages; localized name and description fields carry market-specific language.

Avoid duplicating conflicting entity definitions on one URL. One coherent Organization graph per page is cleaner than three competing blocks injected by different plugins.

Schema types that commonly need localization

Not every schema type needs translation, but these frequently do on multilingual sites:

• WebPage / Article / BlogPosting — headline, description, inLanguage, and url.
• Product — name, description, offers with appropriate currency and availability text.
• FAQPage — Questions and answers must match visible FAQ content in the page language.
• Organization — Localized name where markets use different legal or trade names; consistent @id.
• BreadcrumbList — Localized breadcrumb labels matching navigation.
• LocalBusiness — Address and areaServed appropriate to the locale when relevant.

Helpful, people-first content remains the foundation; structured data should truthfully reflect localized content rather than compensate for thin translations. Marking up an empty stub page does not make it useful.

Hreflang, canonicals and JSON-LD alignment

Hreflang annotations tell Google about alternate language or regional URLs and must be reciprocal across the set of pages they describe. Canonicals tell Google which URL to prefer among duplicates in the same language. JSON-LD should not fight either signal.

Practical alignment rules:

1. Same-language canonicals — Each language or locale URL should have a clear canonical that prefers the same-language preferred URL when duplicates exist. Do not canonical every locale to English while publishing fully localized pages.
2. Hreflang in HTML or sitemap — XML sitemaps help discovery of language versions and can carry xhtml:link hreflang annotations when used as an implementation method.
3. JSON-LD url matches canonical — When you canonicalise /fr/produit to itself, schema url should reference that URL, not /en/product.
4. No hreflang inside JSON-LD as a substitute — Google’s hreflang guidance focuses on link elements, HTTP headers, or sitemaps—not schema as the primary alternate declaration.

When plugins auto-generate all three layers independently, run a cross-check after each locale launch.

Keeping organization and product entities consistent

Multilingual SEO breaks when every locale invents a new organization name or product ID. A practical entity strategy:

• One stable @id per organization across locales; localize display properties.
• Product SKUs or global IDs stay constant; localize marketing titles.
• Same logo URL unless markets require different assets—document why.
• Consistent sameAs social profiles unless a market operates separate verified accounts.

Google helpful-content guidance prioritizes people-first pages; thin or boilerplate-only language versions are weak SEO and weak answer sources. Entity consistency helps systems connect localized pages to a known brand, but it cannot rescue low-quality copy.

Teams managing many locales benefit from a multilingual SEO platform that keeps glossary terms aligned between visible copy and structured data fields.

Answer-engine implications without invented ranking factors

Answer engines and AI Overviews may use structured data as one signal among many when summarizing or citing pages—but no public documentation promises that JSON-LD alone earns citations, rankings, or Overview placement.

What structured data can do truthfully:

• Clarify page type (Article, FAQPage, Product).
• Expose inLanguage for the described URL.
• Support consistent entity recognition when IDs align across locales.

What it cannot do:

• Compensate for untranslated or thin content.
• Replace crawlable locale URLs or hreflang.
• Guarantee rich results in every market.

Treat schema as accurate metadata about people-first pages, not a ranking hack.

Common multilingual schema mistakes

1. English JSON-LD on non-English URLs — inLanguage and text properties stay in the source language.
2. Global schema partial — One CMS block copied to all locales without localization hooks.
3. Conflicting canonical and url — Schema points to English while the page canonicalises to French.
4. FAQ schema in the wrong language — Markup language does not match visible FAQs.
5. Duplicate entity graphs — Multiple plugins inject competing Organization blocks.
6. Invented product properties — Marking up offers or reviews that are not on the page.
7. Hreflang neglected while schema is “fixed” — Annotations and JSON-LD must work together.
8. Thin stub pages with full schema — Boilerplate translations with elaborate markup.

Bing Webmaster Guidelines emphasize crawlable, useful content and clear site structure for indexing across markets—the same crawlability bar applies before structured data adds value.

Daftar periksa implementasi

Use this launch list for each new locale schema batch:

• Localize inLanguage, name, description, and other text properties per URL
• Set url to the locale canonical
• Keep stable @id values for organization and product entities
• Match FAQ and HowTo schema to visible content in the same language
• Verify canonical tags align with JSON-LD url
• Confirm hreflang reciprocity on the same URL set
• Validate with Rich Results Test or equivalent per locale template
• Re-audit after CMS or plugin updates

Dasar-dasar mesin pencari tradisional dan mesin jawaban

Landasan yang sama tetap penting di Google, Bing, dan mesin penjawab: versi bahasa yang dapat dirayapi, entitas yang jelas, klaim berbasis bukti, data terstruktur yang sesuai fakta, serta pelokalan yang sesungguhnya—bukan sekadar kerangka halaman berbahasa Inggris. Gunakan panduan di bawah ini sebagai sudut pandang khusus tiap platform terhadap standar penyajian multibahasa yang sama.

Panduan platform: Google Search

For Google Search, discovery depends on crawlable locale URLs with language-appropriate HTML, accurate titles and headings, and reciprocal hreflang when alternates exist. Technical foundations include indexable content rather than cookie-only switches, localized metadata, sitemaps, and canonical discipline per language version. Content quality means people-first main content in each language; authority comes from clear organization identity and corroborating sources—not translation-tool marketing claims. Multilingual implication: each market or language URL must stand alone as a complete page Google can rank for local queries. Measure with Search Console coverage and URL Inspection per locale. Known vs uncertain: Google documents multilingual and hreflang behavior; it does not guarantee rankings from any CMS or translation workflow.

Panduan platform: Bing

Bing menemukan dan mengindeks halaman multibahasa yang dapat dirayapi dan memiliki struktur yang jelas, serupa dengan ekspektasi Google terkait kejelasan URL dan konten. Landasan teknisnya mencakup URL versi bahasa/wilayah yang dapat diakses, konten yang bermanfaat, serta pemantauan melalui Bing Webmaster Tools untuk setiap properti atau domain terverifikasi. Utamakan heading, klaim, dan FAQ yang dilokalkan, bukan terjemahan yang hanya mencakup antarmuka, dengan navigasi yang berganti bahasa tetapi isi utama tetap sama. Sinyal otoritas tetap bergantung pada sumber tepercaya dan entitas yang konsisten di seluruh versi bahasa/wilayah. Implikasinya untuk situs multibahasa: jangan menyembunyikan versi bahasa di balik tombol yang hanya bekerja di sisi klien atau pergantian berbasis cookie pada satu URL yang tidak memungkinkan perayap menemukan semua versinya. Ukur pengindeksan dan statistik perayapan di Bing Webmaster Tools. Yang sudah diketahui dan yang belum pasti: panduan Bing menekankan konten bermanfaat yang dapat dirayapi; jangan mengada-adakan faktor peringkat khusus Bing terkait alat penerjemahan.

Panduan platform: ChatGPT

ChatGPT dapat mengutip atau merangkum halaman yang dapat diakses publik jika versi bahasanya jelas dan kontennya siap digunakan untuk menjawab pertanyaan. Penemuan konten tidak mengikuti sistem peringkat perayapan konvensional; visibilitas berarti dipilih sebagai sumber atau dirujuk dalam jawaban, bukan muncul dalam urutan peringkat di halaman hasil pencarian. Landasan teknisnya tetap dimulai dari URL HTML yang dapat diakses—bukan lapisan widget yang menyembunyikan teks dari sistem pengambil konten. Karakteristik konten yang membantu mencakup jawaban langsung, FAQ, dan terminologi konsisten dari glosarium yang dipelihara untuk setiap bahasa/wilayah. Otoritas berasal dari bukti dan entitas yang konsisten di seluruh bahasa. Implikasinya untuk situs multibahasa: setiap halaman versi bahasa/wilayah harus dapat dipahami secara mandiri tanpa mengasumsikan pengguna akan berganti bahasa. Pengukurannya belum sempurna—perlakukan pemeriksaan kutipan sebagai hipotesis kualitatif, bukan KPI. Yang sudah diketahui dan yang belum pasti: tidak ada jaminan terdokumentasi bahwa data terstruktur, hreflang, atau alur kerja penerjemahan apa pun akan menghasilkan kutipan di ChatGPT.

Panduan platform: Gemini

Gemini dan pengalaman AI Google terkait terbantu oleh entitas yang konsisten, data terstruktur yang akurat, serta halaman yang dilokalkan dan dapat diindeks. Visibilitas berkaitan dengan dirujuk atau dikenalinya konten—bukan dengan mengada-adakan faktor peringkat khusus Gemini. Landasan teknisnya sejalan dengan kemampuan perayapan Google Search dan kualitas metadata pada setiap URL versi bahasa/wilayah. Konten harus menyajikan klaim dan definisi yang jelas dalam setiap bahasa, dengan pembahasan mendalam yang mengutamakan pengguna. Otoritas bergantung pada konsistensi organisasi dan informasi yang saling menguatkan di berbagai pasar. Implikasinya untuk situs multibahasa: nama produk yang diatur melalui glosarium mengurangi kebingungan entitas antarversi bahasa/wilayah, baik di Penelusuran maupun fitur AI. Lakukan pengukuran konvensional melalui Search Console dan ambil sampel jawaban AI dalam bahasa sasaran untuk penilaian kualitatif. Yang sudah diketahui dan yang belum pasti: perilaku Gemini tidak menggantikan panduan resmi Google Search tentang hreflang dan versi bahasa.

Panduan platform: Google AI Overviews

Google AI Overviews may link supporting pages; eligibility framing still rests on people-first, indexable content in each language. They are not a language switch and do not replace hreflang annotations between alternates. Technical foundations remain crawlable locale HTML and truthful structured data that matches visible page content. Content qualities include concise answers and clear headings in each language version. Authority signals mirror helpful-content expectations rather than schema markup alone. Multilingual implication: Overview inclusion is not guaranteed for any translated page, regardless of English performance. Measure Search Console generative reports where available and keep traditional index metrics separate. Known vs uncertain: no translation workflow can promise Overview placement.

Peran GlotEO

Schema localization at scale is a content-ops problem as much as a developer task. When glossaries, translated fields, and SEO annotations drift apart, JSON-LD becomes the last place mixed-language bugs hide. GlotEO helps teams keep multilingual SEO workflows aligned—so structured data, hreflang, and on-page copy share terminology and locale URLs.

Explore the multilingual SEO platform when you need governance across many locales, and review GlotEO pricing and plans to compare workflow tiers for schema QA and translation review.