2026-03-17 · Baduno Editorial Team · 26 blog.readMin · Blog & Knowledge
Structured Data International: Schema.org Across Language Boundaries
Multilingual websites require precise structured data so that search engines understand content in a language-specific manner. In this guide, you will learn how to correctly use Schema.org markups across language boundaries—from Organization to Product to FAQ. With practical tips and validation methods, you avoid common mistakes and improve the international visibility of your content.
Introduction to structured data for multilingual websites
Structured data according to Schema.org helps search engines understand the content of your website – across language barriers. When you operate multiple language versions, correct markup becomes even more important. Search engines like Google use structured data to display rich results such as snippets, product prices, or FAQ elements. For multilingual pages, these markups must be language-specific, otherwise incorrect information could be delivered – for example, a phone number from the German page in the French version.
A typical mistake: taking the schema of one language and copying it into other versions without adjusting the language specifications. It is not enough to just translate the content; the structure must also reflect the target language. For example, the inLanguage field of the schema object should indicate the language of the respective page. A German product page receives `inLanguage: 'de'`, the English one `inLanguage: 'en'`. Additionally, you can use `translationOfWork` to reference the original version.
Practically, start with the most important page types: Organization, Product, FAQ. These are most commonly used for rich results. Check in advance which pages in which language are especially relevant. For an international company website, the Organization schema is suitable; for an online shop, the Product schema. Ensure that each language version receives its own JSON-LD script or separate entries in the script. Use tools like the Google Rich Results Test to validate each language version individually. Note that the test only provides a snapshot – regular review is recommended.
From a legal perspective, structured data must not contain personal data that violates the GDPR. When specifying contact information in different countries, ensure the data is correct and up-to-date. If in doubt, consult a legal advisor. Through clean implementation of multilingual structured data, you improve your chances of being found with relevant rich results in different language regions.
Basics of Schema.org and language markup
Schema.org provides a shared vocabulary structure supported by search engines. For multilingual websites, correct language annotation is essential. Each schema object can have an `inLanguage` property indicating the content's language (e.g., `'de'`, `'en'`, `'fr'`). This should match the actual language of the page. In JSON-LD, set `@language` either on the entire document or on individual objects if multiple languages occur.
Example: For a product in German, use: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` If marking up the same product on an English page, use `"inLanguage": "en"` and the English name. Avoid mixing multiple language versions in a single schema object—this leads to inconsistencies. Instead, use separate markup blocks per language or work with `@language` arrays within an object if the entity is multilingual.
For site-specific items like `WebSite` or `WebPage`, also specify the language. When a page has a language switcher, you can reference other language versions via `potentialAction` or `translationOfWork`. In practice, it is advisable to place a separate JSON-LD block for each language in the corresponding page's `<head>`. This keeps the mapping clear and correctly interpreted by validation tools.
Ensure that language codes follow the ISO 639-1 standard (e.g., "de" for German, "en" for English). For regional variants, append country codes, e.g., "de-CH" for Swiss German. However, verify whether the search engine supports such fine-grained distinctions—usually the base language code suffices. Validate each language version individually using Google's Structured Data Testing Tool or Rich Results Test. Note any warnings about missing language annotations and fix them promptly.
Organization Schema: Company Information in Multiple Languages
The Organization schema is ideal for companies with multilingual websites, as it provides central information such as name, address, and contact details. For each language version, you should create a separate Organization object annotated in that language. The `name` should be given in the target language—for example, "Muster GmbH" in German and "Sample Inc." in English. If the company has a uniform name, translating the description (`description`) is sufficient.
For addresses, use the `PostalAddress` schema with `addressCountry` and `addressLocality`. For international locations, you can include multiple `location` entries. Ensure that phone numbers (`telephone`) include the correct country code. Example: for the German page `+49 30 1234567`, for the Swiss page `+41 44 1234567`. The same applies to email addresses and opening hours. Use `areaServed` to indicate which countries the company operates in.
A frequently overlooked detail is the `sameAs` property for social media profiles. Provide language-specific profiles if available—for example, the German Facebook page and the English Twitter presence. The `url` should also point to the language-specific homepage. For multilingual websites, you can use `translationOfWork` to establish a relationship between language versions, provided the pages represent the same content in different languages.
Practical recommendation: Implement the Organization schema on the homepage of each language version. Embed a JSON-LD script in the `<head>`. Avoid duplicates by creating a separate block for each language with the appropriate `inLanguage`. Validate the markup with Google's Rich Results Test and check that contact details are correctly displayed. Legally, ensure that the provided information is complete and compliant with data protection regulations, especially for multiple locations: imprint requirements may differ by country. Seek legal advice if in doubt. These details ensure that your company is consistently and correctly represented across all language regions.
Product Schema: Annotating Product Descriptions by Language
For multilingual websites, marking up products with Schema.org Product in the respective language is essential. Each language version of a product should have its own schema markup, including the local name, description, and attributes such as price, currency, or availability. Use the `inLanguage` attribute per language – e.g., `"inLanguage": "de-DE"` for German (Germany). Ensure that the product name and description in the JSON-LD object are actually in German, not just the language tag.
A common mistake is marking up all language variants with the same `@id` (e.g., a global product ID). Instead, assign a separate `@id` for each language, such as `https://example.com/de/produkt/123` and `https://example.com/fr/produit/123`. This allows Google to serve the correct version. For prices, use `priceCurrency` with the ISO 4217 code (e.g., EUR, USD) and specify the price in a language-specific manner – even if the price remains the same, it belongs to the local page.
Practical recommendation: Create a JSON-LD template for each product that dynamically sets the language parameters. Test each language version individually using Google's Rich Results Test. Ensure that the `url` attribute points to the respective language URL. Avoid mixing all languages in a single JSON-LD block – this often leads to validation errors. For images, you can keep the `image` attribute language-independent, but make sure the image URLs are correct.
Additionally, you can customize `offers` with `availability` per market (e.g., `InStock` for Germany, `PreOrder` for France). Use `gtin` or `mpn` globally, but keep local variants for `sku`. Finally, test whether the structured data in Search Console is correctly indexed for each language version.
FAQ Schema: Optimizing Question-and-Answer Pages for Multilingual Use
FAQ pages in multiple languages benefit from clear, language-specific markup using the FAQPage schema. Each language version of the FAQ page gets its own JSON-LD object. Set `inLanguage` to the appropriate language code (e.g., `fr-FR` for French). The questions and answers must be written in the target language within the object – machine translation is often insufficient; have them reviewed by a native speaker, as nuances are critical.
A typical mistake: using the same `@id` for all language variants. Instead, use the language-specific URL as the `@id`, for example `https://example.com/de/faq/` and `https://example.com/en/faq/`. Within the FAQPage schema, list the questions as `mainEntity` with `@type: Question` and the corresponding answer as `acceptedAnswer`. Each question can additionally receive `inLanguage`, but this is redundant if the entire page is marked up. Keep the number of questions per page to a maximum of 10–15, as search engines only consider a limited number of entries.
Action recommendation: Use a content management system that provides a multilingual field per FAQ entry. In the JSON-LD output, dynamically query the current language. Validate each language version individually with the Rich Results Test and watch for warnings about missing `name` properties on questions. Add a `url` to each question pointing to the specific anchor – this allows users to jump directly to the correct answer.
Note: FAQPage is only suitable for pages with explicit questions and answers. Do not use it for general support pages. After deployment, test visibility in Google Search – FAQ rich snippets often appear for queries with question particles. For multilingual SEO, it is worthwhile to adapt answers to country-specific phrasing (e.g., 'Wie kann ich?' vs. 'Comment puis-je?').
The Nuances of inLanguage: Language Code and Locale
The `inLanguage` attribute in Schema.org indicates the language of content, with the value ideally consisting of a language code (ISO 639-1) and an optional region code (ISO 3166-1 Alpha-2) – e.g., `en-US` for American English. The region is important when content differs: "colour" vs. "color" or different units of measurement. Without a region, the code is interpreted as a general language. Therefore, use `de-DE`, `de-AT`, `de-CH` for country-specific pages, even if the text is nearly identical.
A practical example: A product is offered on a German and an Austrian page. The language is German, but prices and shipping conditions differ. Set `inLanguage: "de-DE"` for the German page and `"de-AT"` for the Austrian page. This helps Google better understand regional relevance. The same applies to `en-GB` and `en-US`. If regional differentiation is not required, `"de"` or `"en"` suffices. However, ensure the language code is always lowercase and the region is uppercase (e.g., `fr-CA`).
A common mistake is using `inLanguage` on a parent object while child objects have a different language. For example, a WebSite in German but a single article in English. Then set `inLanguage: "de"` on the WebSite and `inLanguage: "en"` on the Article. Validate this with a schema validator, as some tools report conflicts. For multilingual pages with hreflang tags, `inLanguage` should correspond to the respective hreflang value – this helps Google deliver the correct version.
Practical implementation: Define a unique `@id` per language version and apply `inLanguage` consistently. Use a central configuration file containing the correct codes for each language. Test with the schema.org tool to see if the `inLanguage` tag is accepted. Tip: Even for AMP pages or structured data via Microdata, do not forget `inLanguage`. For JSON-LD, place it at the top level (e.g., `WebSite` or `WebPage`). For dynamic content such as blog articles, `inLanguage` can vary per post – then set it per item.
Correctly marking multilingual content on a single URL
When a URL contains content in multiple languages – e.g., via a language switcher, tabs, or accordions – the structured data must clearly indicate which text belongs to which language. Otherwise, a search engine crawler might mistakenly assume all content is in one language, leading to indexing and display errors.
The basic method is to use the `inLanguage` attribute on the relevant elements. For an FAQ schema with questions and answers in German and English on the same page, mark each question and answer individually: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` The same applies to Product schemas: describe `name` and `description` per language in a separate `Product` object with its own `inLanguage`, or use `@language` and `@value` in a `multilingualDescription` property (if your vocabulary supports it).
For organizations with multilingual names, use an array of `name` objects: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Avoid declaring the entire page as multilingual. Instead, assign language as granularly as possible. A common mistake is setting `inLanguage` only at the top level of a schema without marking child elements. Therefore, ensure in your validation workflow that all texts are correctly language-annotated.
As a concrete recommendation: create a separate schema object for each language variant on a URL, containing only the texts in that language, and set `inLanguage` to the appropriate language code. If the page displays a default language and loads others via JavaScript, embed the structured data for all languages statically in the HTML. Tools like the Google Rich Results Test will show whether the markup is interpreted correctly. Test each language version individually by forcing the crawler to the desired language via a URL parameter or cookie control.
Distinguishing hreflang and inLanguage: When to use which method?
`hreflang` and `inLanguage` serve different purposes in international SEO and should not be confused. `hreflang` is an HTML element or HTTP header that signals to search engines that there are alternative language or regional versions of the same page. It ensures the correct page is delivered to users in different countries or with specific language settings. `inLanguage`, on the other hand, is an attribute in structured data (Schema.org) that specifies the language in which a particular text element is written.
When do you use which? Use `hreflang` when you have separate URLs for different language versions (e.g., `example.com/de/` and `example.com/en/`). This prevents duplicate content issues and ensures the correct page appears in snippets. `inLanguage` is necessary when you mark up multilingual content on a single URL or when a structured data element like a product description exists in multiple languages. Thus, `inLanguage` complements `hreflang` at the level of individual text blocks.
A common misconception: `inLanguage` does not replace `hreflang`. Even if you mark every line of an article with `inLanguage`, search engines without `hreflang` won't know if there are alternative versions of the entire page. Conversely, `hreflang` is insufficient to granularly describe multilingual content within a single URL. In practice, this means: If you have separate pages per language, `hreflang` is primarily required, while `inLanguage` only indicates the specific language of the content in structured data on those pages. If multiple languages reside on one URL, you must use `inLanguage` for each language-specific element.
Practical recommendation: Plan your URL strategy before implementation. Decide whether to use a separate URL per language (ccTLD, subdomain, subdirectory) or a shared URL with dynamic language switching. For the latter, correct `inLanguage` markup is essential. In any case, check that your `hreflang` tags reference all relevant language versions and do not conflict with `inLanguage` statements in structured data. Aligning these two signals helps search engines correctly interpret your content.
Validation Workflow: Tools and Automated Checks
Manually checking structured data on each language version is error-prone and time-consuming. An automated validation workflow ensures that your Schema.org markup remains correct – even after content updates or when adding new languages. The most important tools are the Google Rich Results Test (for Google-supported types like FAQ, Product) and the Schema.org Validator (for pure syntax checking). Additionally, crawlers like Screaming Frog SEO Spider can extract structured data across your entire website and check for errors.
Integrate this check into your CI/CD process: after every deployment or language update, run an automated test. Use the Google Rich Results Test API or a script that parses your pages and validates the JSON-LD blocks against a self-defined schema. Pay special attention to the following error sources: - Missing `inLanguage` in places where multiple languages occur. - Conflicting language codes (e.g., "de" instead of "de-DE" for region-specific variants). - Incomplete required fields (e.g., `name` for Product in every language). - Outdated `hreflang` tags that no longer match your current URLs.
Concrete recommendation: Create a checklist for each schema type (Organization, Product, FAQ) with the required attributes per language. Use a validation tool like `json-schema` for automated validation of your data. Additionally, run a full crawl with the Schema.org Validator regularly (e.g., monthly) and generate reports on pages with errors. Document error categories and assign responsible persons for corrections. Note that structured data must be checked on live pages – testing in staging is insufficient because it may contain different content. Only then can you ensure that search engine-relevant errors are fixed in a timely manner.
Multilingual websites require precise structured data so that search engines understand content in a language-specific manner. In this guide, you will learn how to correctly use Schema.org markups across language boundaries—from Organization to Product to FAQ. With practical tips and validation methods, you avoid common mistakes and improve the international visibility of your content.
Common Mistakes in International Structured Data
Marking up multilingual websites with Schema.org involves typical pitfalls. A common mistake is missing or incorrect specification of the language attribute `inLanguage`. For example, if you offer a product in German but do not set `inLanguage: "de-DE"` in the markup, search engines may interpret the data as language-neutral. Another fundamental error is mixing languages within a single schema block. You should avoid setting the `name` property in English and the `description` in German within a `Product` object. Instead, create a separate block for each language version with the correct `inLanguage`. Another widespread mistake is using inappropriate schema types. For a multilingual company, many mistakenly use `LocalBusiness` when `Organization` is the right choice if no physical address exists in each language. Also, products often miss language-specific annotation of the `offers` property. Additionally, structured data is not updated after translations: a newly translated product text must also be updated in the markup – otherwise search results show outdated or incorrect information. Neglecting validation is another cardinal mistake. After each change, you should check the markups with suitable tools. Incorrect or missing `@id` references for entities that are identical across languages (e.g., an organization) lead to duplicates or incomplete data. Moreover, the interplay with `hreflang` is often ignored: where no alternative URLs exist, you must work with `inLanguage` on the same page. Recommendations: Check each markup for correct language assignment. Use separate schema blocks for each language version with unique `@id`s. Avoid mixing – even in `aggregateRating` or `review` the language must be correct. Perform a new validation after each translation and align the data with the visible content. Only then can you ensure that search engines correctly understand your multilingual offerings.
Testing with Google Rich Results, Bing Webmaster Tools, and Yandex
Checking multilingual Schema.org markups should not be limited to a single tool. Each search engine has its own interpretations and validation criteria. The Google Rich Results Test is the first port of call: enter a URL with your markup or paste the code directly. Pay attention to all errors and warnings – especially whether the `inLanguage` specifications are correctly recognized. A common issue is that Google accepts `de-DE` but warns if the region part (`de`) is missing. Test each language version individually. Bing Webmaster Tools offers a URL inspection with a structured data view. Here you can see whether Bing interprets the markups as expected. Bing is often stricter in validating `inLanguage` and may require the two-letter language code without region (e.g., `de` instead of `de-DE`). Perform a live test and correct deviations. Bing also shows possible duplicates if `@id` values are used multiple times. Yandex Webmaster has its own validator, which is particularly relevant for Russian-language sites. You can also test structured data there. Yandex supports most Schema.org types, but error handling differs. Especially with `Product` markups, the `availability` property is often criticized. Therefore, test each language version here as well. Note that Yandex may weight regional language codes like `de-DE` differently. Recommendations: Test each language version in all three tools after implementation and after every change. Note deviations and adjust the markups so that they are accepted by all three search engines. Ideally, use the two-letter language code (`de`, `en`) in `inLanguage`, as it is understood uniformly by most systems. Automate tests with CI tools to keep track on multilingual websites with many pages.
Checklist for implementing multilingual Schema.org markups
A structured approach prevents typical mistakes in internationalization. Before implementation, define your language strategy: Use separate URLs per language (e.g., `/de/produkt` and `/en/product`) or a single URL with language switching? For separate URLs, use `hreflang` and a separate markup per URL. For a single URL, use multiple `inLanguage` blocks with different language codes. Also plan which schema types are needed: Organization, Product, FAQPage, etc.<br><br>During implementation, pay attention to the following: Each schema object gets a unique `@id` that identifies the entity language-independently. For each language version, create a separate object that specifies the language via `inLanguage`. Use consistent language codes – preferably the two-letter ISO code (e.g., `de`, `en`) supplemented by the region if necessary. Link correctly within the markups: For `Organization`, use `url` and `logo` with language-specific paths. Verify that texts like `name` and `description` match the visible content.<br><br>After implementation, validation follows: Test each language version with Google Rich Results Test, Bing Webmaster Tools, and Yandex. Correct errors and warnings. Pay special attention to missing `inLanguage` or incorrect language codes. Additionally, use Google's Schema.org validation tool to check syntax. Document all changes and retest after each translation.<br><br>Finally, monitoring is part of the process: Track performance in Search Console, especially the structured data reports. React to new errors or warnings. Update the markups promptly when you change or translate content. Conduct regular audits to ensure consistency across all language versions. A well-maintained Schema.org implementation improves visibility in search results – without guarantees, but with practical benefits.
Legal Notice: Responsibility for Automatic Translation
The automatic translation of structured data carries legal risks that you, as the operator of a multilingual website, must independently review. Particularly for Schema.org markups containing legally relevant content such as product safety instructions, terms and conditions, or brand names, an inaccurate translation can lead to liability. For example, a mistranslated product name or misleading product description may violate competition law. We therefore recommend having all automatically generated translations proofread by a native-speaking expert. This applies especially to fields like 'description' in Product schema or 'answer' in FAQ schema, where nuances are critical.<br><br>In addition to content accuracy, data protection aspects also play a role: If your schema contains personal data (e.g., customer reviews in Review schema), you must ensure the translation complies with GDPR. Automatic translation services should only be used if the service provides sufficient data protection guarantees. There is no general prohibition, but the responsibility for data processing lies with you as the website operator. Consult a legal advisor for the specific requirements in your target countries.<br><br>Another legal pitfall: the use of 'inLanguage' with invalid language codes. Always use official BCP-47 codes (e.g., 'de-DE' instead of 'deutsch'). Incorrect codes may cause your markups to be ignored by search engines – which is not a legal issue but impairs findability. Therefore, before going live, perform validation with tools like Google Rich Results Test, and additionally check that the translations correctly cover all legally relevant fields.<br><br>Recommendation: Define a workflow where each automatically translated schema markup is reviewed by a native-speaking editor or lawyer. Document this process to prove in disputes that you have fulfilled your duty of care. Avoid automatic translation of legally significant text blocks (e.g., warranty conditions, disclaimers); translate these manually or through a specialized service.
Outlook: AI-Powered Localization and Future Schema Developments
The localization of Schema.org markup is increasingly facilitated by AI-powered tools. Current systems can leverage neural networks to produce translations that are contextually more precise than older statistical methods. For multilingual websites, this means you can transfer large amounts of product data or FAQ content into multiple languages faster. However, quality assurance remains crucial, as AI models do not always correctly capture industry-specific terms or regional nuances. A practical approach is to use AI for raw translation, followed by human review. Tools like Baduno combine AI translation with native-speaker review, offering a scalable solution.
Parallel to AI development, Schema.org is continuously expanding its vocabulary. Future types may better cater to AI-generated content, such as an "AIContent" schema for marking machine-created texts. Interlinking with knowledge graphs is also becoming more important: multilingual markups could be automatically generated from central knowledge bases in the future. The "translationOfWork" property already exists, explicitly defining the relationship between translated content. We recommend incorporating such new properties into your strategy early on to be prepared for search engine updates.
Another trend is dynamic, language-specific markups served based on user context. For example, a Product schema could include the local currency and unit of measurement depending on the user's location. The challenge lies in correctly using "inLanguage" and avoiding conflicts with hreflang. Future schema versions may more clearly define how regional variants can be represented within a schema. To prepare, build your markups in a modular way: use separate blocks per language within the same JSON-LD or separate script tags per language version, depending on your technical infrastructure.
Action recommendation: Test AI-based translation solutions with a representative set of your schema data and measure the error rate. Stay informed about Schema.org release notes to identify new properties. Pilot dynamic serving of markups for different target audiences and validate results using the search consoles of major search engines. This way, you ensure your multilingual site benefits from future developments without taking on legal or technical risks.
Practical Example: Step-by-Step Implementation of a Multilingual Product Page
To put the theoretical foundations into practice, let's consider a fictional e-commerce website offering a smartphone in German, English, and French. Assume the product page is available under a single URL with a language switcher (e.g., example.com/smartphone). The goal is to mark up the product page with Schema.org Product markup containing language-specific information.
1. **Set language codes**: For each language variant, assign a unique inLanguage value. Example: German: "de-DE", English: "en-US", French: "fr-FR".
2. **Mark up name and description per language**: Use an @graph array in the JSON-LD markup. Assign a separate Product object with its own inLanguage to each language variant. Example: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Product", "inLanguage": "de-DE", "name": "Smartphone Pro Max", "description": "Leistungsstarkes Smartphone mit 128 GB Speicher", "offers": { ... } }, { "@type": "Product", "inLanguage": "en-US", "name": "Smartphone Pro Max", "description": "Powerful smartphone with 128 GB storage", "offers": { ... } }, { "@type": "Product", "inLanguage": "fr-FR", "name": "Smartphone Pro Max", "description": "Smartphone puissant avec 128 Go de stockage", "offers": { ... } } ] } ```
3. **Validate markup**: Use Google's Rich Results Test to check if each language version's markup is accepted. Ensure the inLanguage values match the actual page language.
4. **Server-side or JavaScript integration**: Ideally, generate the markup server-side so the page source contains the complete JSON-LD. For dynamic language switching via JavaScript, the markup can be loaded asynchronously, but search engines may not pick it up.
5. **Test visibility**: After implementation, check that the structured data is reported as valid in Google Search Console and that Rich Results appear in search.
This step-by-step example shows how you can proceed concretely. Adapt the structure to your technology stack and test each language variant individually.
Collaboration with Translation and Localization Service Providers
When implementing multilingual structured data, you often work with translators or localization agencies. It is important that Schema.org markups become part of the localization process. Discuss with your service provider that not only the visible content but also the values in JSON-LD (e.g., "name", "description") need to be translated. A common mistake: the agency receives only the page text, not the structured data. Therefore, provide a separate document with all schema fields—ideally in JSON format—and specify which fields need language-specific translation (e.g., "offers" or "review" can remain global, while "name" varies by language).
Practical tip: Use glossaries and translation memories for your structured data as well. This ensures that product names and technical terms appear consistently across all markups. Also ask the service provider to set the language codes (inLanguage) according to your specifications—e.g., "de-DE" instead of just "de". After delivery, you should randomly check whether all translated field values are correctly placed in the markups. An automated test with Google's Rich Results Test can provide initial indications.
Another aspect: collaboration in quality assurance. Agree that the translated schema data will be proofread by a native-speaking editor before publication. Because incorrectly translated product attributes or instructions in FAQ questions can harm international rankings. Document the entire process—from source text extraction to deployment—and update your checklist for each language version. This way, you avoid structured data becoming outdated during later content updates.
Legal notice: Responsibility for correct translations lies with you. Have compliance with your specifications confirmed in writing and clarify liability issues for mistranslations contractually. Independent legal advice is recommended.
Budget Planning and Effort Estimation for Multilingual Schema Implementation
Introducing structured data in multiple languages incurs one-time and ongoing costs. In addition to the pure translation of markup content, there are expenses for technical integration, testing, and maintenance. For realistic budget planning, you must consider the following items:
1. Translation of schema fields: For each language version, costs arise for translating all relevant JSON-LD elements (titles, descriptions, questions, answers, etc.). Since these are short, often technical texts, translation agencies can offer special rates. Budget a surcharge of 10–20% for familiarizing with the schema definitions.
2. Technical adaptation: The markup must be implemented either in separate JSON-LD blocks per language or via multilingual fields. Depending on the system, your developer team will need additional time to implement the logic for language switching and fallbacks. Experience shows that the initial effort for a website with five language versions is between 15 and 25 person-days in development.
3. Testing and quality assurance: Each language version must be validated individually—using Google Rich Results Test, Schema.org validators, and manual spot checks. Plan about 1–2 days per language for initial setup and half an hour per change.
4. Ongoing maintenance: When updating product ranges or FAQ content, the markups must also be adjusted promptly. Determine whether the translation team always delivers the schema data along with new content. A content management system that automatically generates structured data reduces long-term effort but requires appropriate setup.
5. Tools and licenses: If you use special tools for monitoring structured data (e.g., Webmaster Tools APIs or custom dashboards), subscription fees may apply.
As a rule of thumb, for the entire process (introduction in three main languages), you should budget between 5,000 and 15,000 euros, depending on the scope of the site and the number of products. For small projects with only a few FAQ pages, the amount can be lower.
Legal notice: The figures mentioned are for orientation only. Obtain individual quotes from developers and translators, and note that actual costs may vary depending on complexity. For binding statements, consult your legal and tax advisors.
blog.faqT
How do I mark up a FAQ schema when questions differ by language?
Create separate mainEntity entries for each language version, with question and acceptedAnswer. Use inLanguage at the top level of the FAQ schema for the target language. For identical content on different URLs, use hreflang; for translations on a single page, inLanguage suffices. Ensure that answers are fully and accurately translated into the corresponding language – automatic translations should be legally reviewed.
Can I mark up a product page with a single URL for multiple languages?
Yes, as long as the content on the same URL is multilingual (e.g., via tabs or AJAX). Set inLanguage to the respective DOM fragment or use a separate schema per language with its own inLanguage. Additionally, provide a name and description in the target language for each language version. For clear country or language URLs, combining with hreflang is usually preferable.
Which tools are suitable for validating multilingual Schema.org markup?
Google Rich Results Test checks individual URLs and displays errors for language codes. Bing Webmaster Tools offers similar features. For automated tests across multiple pages, crawlers like Screaming Frog that extract structured data are suitable. Always manually verify that translations in name, description, and other properties are correct – this is where errors occur most frequently in practice.
