A German visitor lands on your page, but the rich snippet still displays an English headline and a price formatted with a dollar sign. The page ranks, yet that specific inconsistency creates a quiet trust gap at the exact moment of click. This is the core issue with multilingual schema implementation: the visible text is localized, but the structured data remains in English, undermining the user’s confidence in the content behind the URL. It is not a fatal error, but it is a persistent leak in click-through rate that many international SEO teams overlook because the search engine still serves the correct page.
When you localize the user-facing copy, the underlying JSON-LD must mirror that effort. If the schema data does not match the language of the page, the rich result presents a disjointed experience. For a French reader, an English description in the snippet signals a lack of attention to detail, even if the landing page is perfectly translated. This discrepancy erodes the perceived authority of the brand. The goal of international SEO is not just indexing the right version, but presenting it in a way that feels native and trustworthy. We need to align the technical markup with the linguistic reality of the page to protect the value of that click.
Which JSON-LD properties actually carry translation
When you localize JSON-LD, the goal is to align the structured data with the visible text so the rich snippet mirrors the user’s experience. Not every field in your schema block requires translation, though. We need to distinguish between free-text properties that describe the content and fixed-structural properties that define how that content is indexed.
The free-text properties are the ones that carry the actual message. These include name, headline, description, and the specific text within FAQPage questions and answers. For local businesses, address components like streetAddress or addressLocality often need localization if the user expects local language conventions. Breadcrumb labels also fall into this category. If a German user clicks a link to “Services” but the breadcrumb in the schema says “Dienste,” the mismatch breaks trust. These fields must be written in the target language.
In contrast, fixed-enum properties are structural identifiers. The @type (e.g., “Article” or “Product”) and @context must always remain in English as per the schema.org standard. The availability status, such as “InStock,” is also a fixed value that should not be translated. Changing these to “EnStock” or “Artikel” will break validation and confuse search engines.
One critical property sits in a unique category: inLanguage. This is the property that signals the page’s language to the search engine. It stays as a standard ISO code—like en, fr, or de—rather than a translated word. Getting this to match the visible content is the highest-leverage fix in international SEO. If your German page has "inLanguage": "en", the engine may serve it to English speakers, ignoring your German content entirely.
Consider this simple WebPage block for a French version of an article:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Comment optimiser votre site pour 2025",
"description": "Un guide pratique pour le SEO international.",
"inLanguage": "fr",
"url": "https://example.com/fr/seo-2025"
}
Notice that headline and description are in French, while @type and @context remain in English. The inLanguage code fr confirms the content’s language to the crawler.
A common misconception persists: because the schema.org documentation is in English, many developers assume the data values must be too. This is incorrect. The documentation is a reference manual; the data itself is your content. A French or German site can and should fill name, headline, and description fields in their own language. Treating the English documentation as a constraint on data language is a barrier to effective localization markup that we should remove. When we localize JSON-LD, we are simply extending our existing content strategy to the metadata layer, ensuring the machine-readable version speaks the same language as the human-readable one.
Localizing Offer data: the priceCurrency and date format detail
The Offer schema drives the price display in rich snippets, but only if the data aligns with user expectations. The priceCurrency field must match the currency shown to that specific audience. For a European version of a page, this value should be "EUR", not "USD", even if the backend database stores everything in dollars. This alignment is the first step in localizing structured data effectively.
Consider the visual difference in how prices are rendered. In the United States, the convention is $99.99. In Europe, it is often 99,99 €. If your page displays the latter but your JSON-LD contains "price": "99.99" and "priceCurrency": "USD", the search engine snippet may render a number that looks foreign or incorrect to the local reader. This mismatch creates a subtle trust issue at the moment of decision. A user clicking a snippet that promises a deal in their own currency format, only to land on a page that displays it differently, experiences a jarring disconnect.
The role of date and number formats
Date formatting is another area where international SEO often stumbles. The United States typically uses MM-DD-YYYY, while Europe favors DD-MM-YYYY. When a publicationDate or validUntil field is formatted in the US style on a page targeting a French or German audience, the resulting snippet can look unintuitive. While search engines are generally forgiving with date parsing, the user-facing snippet must feel natural. If the reader expects 25-12-2024 but sees 12-25-2024, the content appears less polished and less relevant to their locale. Ensuring these fields match the reader’s expectations is a key part of creating a cohesive language schema.
Protecting click-through rate through consistency
The goal of proper localization markup is internal consistency. When the rich snippet matches the on-page content, the user’s journey feels smooth. If the snippet says 99,99 EUR and the page confirms it, trust is reinforced. If they conflict, click-through rates suffer because users perceive the information as unreliable. By carefully auditing priceCurrency and date fields for each locale, you remove this friction. This attention to detail ensures that the structured data supports the user’s intent rather than undermining it, protecting the value of your ranking efforts in each market.
How hreflang and inLanguage keep each language version aligned
A common source of confusion in international SEO is conflating two distinct signals: the hreflang attribute and the inLanguage schema property. They solve different problems, and treating them as interchangeable often leads to broken localization. Hreflang establishes a relationship between pages. It tells the search engine which URL serves which specific language and region. It is a map of your site’s architecture, linking the English, French, and German versions of a page so the engine knows they are variants, not duplicates.
inLanguage, on the other hand, is a property of the data itself. It declares that the content on this specific page is written in a certain language. If you use hreflang but leave your JSON-LD schema in English, the engine knows where the German version is, but the data it reads is in English. This mismatch can leave the snippet under-optimized for the target language, as the rich result may display text that does not match the user’s query language. Conversely, having a localized schema without hreflang leaves the engine unsure which version to serve to a user in Berlin versus a user in London, risking the display of the wrong page entirely.
Consistency across implementation methods
Hreflang can be implemented in three ways: within the <head> tag, in HTTP headers, or via an XML sitemap. For large multilingual sites, the XML sitemap approach is often more practical because it centralizes the relationships in one place rather than cluttering every page header. However, the critical rule is consistency. The language codes used in your sitemap hreflang tags must match the inLanguage codes in your schema exactly. If your sitemap says de and your schema says deu, or if one uses a regional variant like de-DE while the other uses just de, you introduce noise that can dilute the signal. Keep these identifiers synchronized to ensure the engine receives a clear, unified instruction on how to serve your multilingual content.
Why localized markup moves CTR, and the mistakes that undo it
Localizing structured data is not just a technical nicety; it is the primary driver of whether a user trusts your snippet enough to click. When a German reader sees a German headline and a correctly formatted EUR price in the rich result, the visual consistency signals that the landing page is intended for them. Conversely, an English headline paired with a misformatted number breaks that trust immediately, causing the user to skip your result in favor of a competitor whose data matches their locale. This alignment between the snippet and the target language is the core benefit of a well-executed multilingual schema.
The most common reasons this value is lost are surprisingly basic. Many teams leave the JSON-LD in English because the documentation is in that language, overlooking that the data values themselves should be localized. Others implement hreflang tags to signal language versions to the engine but fail to update the schema content to match, creating a disconnect between the URL and the data. A third frequent error is treating validation as a one-time task; in reality, small structural changes or minor typos can silently break the markup, causing search engines to ignore the rich snippet entirely.
To protect your click-through rate, treat validation as an ongoing habit rather than a setup phase. After every structural change, run your localized versions through a rich results test tool and a schema validator. This simple check ensures that the language schema remains valid and that your localization markup continues to reflect the intended content for each audience.
Localizing structured data requires the same rigor as localizing visible text. Keep your hreflang declarations and inLanguage properties in agreement, and treat re-validation as a routine after every site update. Consistency in your multilingual schema is what ensures search engines serve the correct version to the right audience. Does the rich snippet a non-English speaker currently sees read as trustworthy to them?
