Multilingual structured data.
On multilingual sites structured data is generated separately in every language version, and the content’s language is declared explicitly.
Structured data declares the page’s meaning to machines; on a multilingual site, which language that meaning is expressed in must be declared too. Otherwise the machine can take a description on a German page for Turkish.
The declaration is simple: every node carries its content’s language. But there are two traps in practice, and both are seen often.
Trap one: schema generated in one language
The most common error is generating the schema once and using it as-is in all languages. The result: the German page serves a schema block carrying a Turkish description. German on screen, Turkish in the machine layer — the two readers hear different things.
The correct behaviour is translating the schema together with the content. Name, description, service definition, question-and-answer blocks — all must be in that page’s language. That raises the translation load, but otherwise the schema carries wrong information.
On this site the schema comes out of the generator and the strings are read from the language dictionary; the German page’s schema thus carries the German strings. Drift is structurally impossible.
Trap two: should identities split by language
The organization and person nodes are defined again in every language. The question: are these the same entity, or separate entities per language?
The answer: the same entity. An organization described in three languages does not become three organizations. Identities therefore must not split by language — the same fixed identity must be used in every language, so the machine understands the three pages speak of the same entity.
Page nodes, by contrast, are separate per language: every language version carries its own page node and declares its own address. So: one entity, many pages.
- Organization and person — one identity, the same in all languages. The strings are translated, the identity unchanged.
- Page nodes — separate per language; each declares its own address and language.
- Content nodes — article, service; separate per language and with the language declared.
- The breadcrumb — separate per language; the labels carry that language’s terms.
That distinction lets the graph be read correctly: the three pages in three languages appear as three separate pages bound to the same organization — not as three separate organizations.
Social card tags
Beside the schema there is also a social-sharing layer, and it carries a language declaration too. The tag wants a format combining language and country code — the language code alone is counted invalid.
Alternate language versions can be declared as well: a page can say which other languages it exists in. On this site every page declares its own language and the other two — measured, and the verification suite additionally audits the format.
Consistency between schema and screen
The golden rule that holds on single-language sites becomes doubly important on multilingual ones: everything written in the schema must also be on screen. Because here two drift risks exist at once — information drift and LANGUAGE drift.
The second is more insidious: the description in the schema can carry the right information but in the wrong language. That raises no error in a validation tool — the tool does not check language — but the wrong signal reaches the model, and that page can match queries in the wrong language.
- Are the schema’s strings in the page’s language — description, name, question-and-answer.
- Is the language declared on every node — the content’s language must be written explicitly.
- Are identities unsplit by language — the organization is the same entity in all three languages.
- Are the page nodes separate per language — every version must declare its own address.
- Are the social tags in language-country format — the language code alone is invalid.
- Is every fact in the schema also on screen — without exception.
The third and fourth items should be read together, because they build the distinction: one entity, many pages. The organization node carries the same identity in all three languages — its strings translated, its identity fixed. The page nodes are separate, because they really are separate pages.
On this site the schema comes out of the generator and the strings are read from the language dictionary; drift is structurally impossible. The verification suite additionally measures on every route the presence of the expected nodes and the format of the social tags.
Translation load and automation
When it becomes clear the schema needs translating too, the first reaction is usually “that is a lot of work”, and it is a fair reaction. But the load is real when the schema is written by hand — nearly zero when it comes out of a generator.
The reason: the strings in the schema are the strings already on the page. Title, description, service name, question-and-answer — all already stand on screen and are already translated. The schema does not rewrite them; it reads from the same source.
That is also the rationale for why the schema must be generated from the same source as the content: the same text held in two separate places drifts apart sooner or later, and once drifted, which one is correct becomes unclear.
On this site the schema comes out of the generator and the strings are read from the language dictionary. When a text is updated, screen and schema update at the same moment — because both look at the same source. The translation load, beyond the content translation itself, is zero.
A final frame: multilingual schema is not a harder version of single-language schema — the same rules hold, only one more dimension is added. If the rules are already known, the language dimension is a small extra load; if not, the language dimension makes the problem visible but does not produce it.
A final scope note: the part of the schema that needs translating is only the free-text fields. Type names, property names and identifiers are not translated — they are part of the machine vocabulary and stay the same in every language.
That distinction is sometimes confused and schema property names get translated; the result is an invalid block. What is translated is the value, not the key.
A principle to close: multilingual schema should be a by-product of the translation work, not an extension of it. Built right, it produces no extra translation load — it carries the already-translated strings into the machine language. If it produces extra load, the schema is being fed from the wrong place.