Los datos estructurados son lo que convierte un resultado de búsqueda normal en uno con estrellas, precio y disponibilidad. Funcionan bien y están razonablemente resueltos en una web monolingüe.
En una web multiidioma se rompen de una forma silenciosa: el JSON-LD de la versión inglesa sigue diciendo lo mismo que el de la española, incluida la URL. Y cuando el schema contradice al hreflang, Google se queda con una sola versión.
Al grano: el error más caro y más invisible es dejar la propiedad @id apuntando a la URL original en todos los idiomas. Google interpreta que todas las versiones son la misma entidad, elige una y descarta las demás. No da ningún aviso en Search Console: simplemente no indexa el resto.
Qué se traduce dentro del JSON-LD
La regla general: se traduce lo que el usuario lee en el resultado de búsqueda; se cambia lo que identifica a esa versión concreta; no se toca lo que es un dato.
Se traduce
nameyheadline: el texto que sale como título del resultado enriquecido.description: debe coincidir con la meta descripción de ese idioma, no con la del original.articleBody, si lo incluyes.- Las preguntas y respuestas de un bloque
FAQPage. - Los pasos de un
HowToy los ingredientes de unaRecipe. jobTitle,addressCountryy similares cuando forman parte del texto visible.
Se cambia, pero no se traduce
inLanguage: el código del idioma de esa versión. Es la propiedad que más se olvida y la que declara explícitamente en qué idioma está.urly@id: a la URL traducida. Siempre.mainEntityOfPage: a la URL traducida.potentialAction, si incluye una URL de búsqueda interna: debe apuntar al buscador de ese idioma — lo cual tiene sus propias implicaciones, en el buscador interno multiidioma.
No se toca nunca
sku,gtin,mpn,isbn: son identificadores. Traducirlos los invalida.price: solo cambia si vendes en otra moneda, y entonces tambiénpriceCurrency.datePublishedydateModified: formato ISO, idéntico en todos los idiomas.@type: son los tipos de schema.org y están en inglés por definición. UnProductesProducten todos los idiomas.ratingValue,reviewCount: son números.
Ojo: el fallo de principiante más común es traducir los @type. Ver "@type": "Producto" en el código de una web es señal de que alguien pasó el JSON-LD entero por un traductor. Schema.org es un vocabulario en inglés: sus nombres son etiquetas técnicas, no texto. Un @type traducido deja el bloque entero sin validez.
La tabla de decisión
| Propiedad | Acción | Ejemplo en la versión inglesa |
|---|---|---|
name, headline |
Traducir | «Guía completa» → «Complete guide» |
description |
Traducir | La meta de ese idioma |
inLanguage |
Cambiar | es → en |
url, @id |
Cambiar | /guia/ → /en/guide/ |
@type |
Nunca | Siempre Article, Product… |
sku, gtin |
Nunca | El mismo identificador |
price |
Solo si cambia | Mismo número salvo otra moneda |
datePublished |
Nunca | Formato ISO idéntico |
Schema y hreflang tienen que contar lo mismo
Son dos declaraciones sobre la misma página, y si se contradicen, gana la confusión. Un caso típico: el hreflang dice que /en/guide/ es la versión inglesa de /guia/, pero el JSON-LD de /en/guide/ declara "url": "https://tudominio.com/guia/".
Le estás diciendo a Google dos cosas incompatibles: que son versiones distintas y que son la misma página. El resultado habitual es que indexa una y marca la otra como duplicado — el mismo síntoma que describimos en por qué Google no indexa tus traducciones.
La comprobación de que el hreflang está bien está en hreflang con Yoast SEO. Aquí solo hay que asegurarse de que el schema lo acompaña.
Cómo comprobarlo en tu web
- Abre una página traducida y copia su URL.
- Pásala por la prueba de resultados enriquecidos de Google y por el validador de schema.org.
- Busca
"url"y"@id"en el resultado: ¿apuntan a la URL traducida o a la original? - Busca
inLanguage: ¿está y lleva el código correcto? - Comprueba que
nameydescriptionestán en el idioma de la página. - Repite en un tipo de página de cada clase: entrada, producto, página de servicio, archivo.
Consejo: comprueba primero la ficha de producto, si tienes tienda. Es donde el schema tiene más impacto —precio y disponibilidad en el resultado— y donde más propiedades hay que no deben traducirse. Si tus fichas están bien, el resto de tipos casi seguro también, porque el mismo mecanismo las genera.
El caso de los plugins de SEO
Yoast, Rank Math y similares generan el JSON-LD a partir de los datos de la entrada. Si la entrada traducida es una entrada de WordPress con su propio título, su propia meta y su propia URL —que es como funcionan los plugins multiidioma basados en entradas gemelas—, el schema sale correcto solo.
Donde suele fallar es en:
- Los datos de la organización, que son globales y se declaran una vez: nombre, logo, dirección. Normalmente no hay que traducirlos, pero la
descriptionde la organización sí conviene revisarla por idioma. - Los breadcrumbs, que arrastran los nombres de las categorías. Si las taxonomías no están traducidas, el breadcrumb del schema sale en castellano. Se resuelve traduciéndolas: traducir categorías y etiquetas.
- El schema que inyecta el tema o el maquetador por su cuenta, que muchas veces está escrito a mano en la plantilla y es idéntico en todos los idiomas.
Ese tercer caso es el más difícil de detectar, porque conviven dos bloques de JSON-LD en la misma página: uno correcto del plugin de SEO y otro heredado de la plantilla. Si la prueba de resultados enriquecidos te devuelve dos entidades del mismo tipo, es eso.
Cuando la traducción genera entradas reales con su URL y sus metadatos propios, el schema se resuelve prácticamente solo. Es lo que hace WP-Translate: cada traducción es contenido propio en tu base de datos, con su título SEO, su meta descripción y su URL, así que el plugin de SEO tiene de dónde construir el JSON-LD correcto. Puedes comprobarlo con la versión gratuita pasando una página traducida por el validador.
Preguntas frecuentes
¿Hay que poner inLanguage obligatoriamente?
No es obligatorio, pero ayuda y cuesta nada. Es una señal explícita más, junto al hreflang y al atributo lang del HTML.
¿Puedo tener un solo bloque de schema para todos los idiomas?
No deberías. Cada versión es una página distinta con su URL, y su schema debe describirla a ella.
¿Los resultados enriquecidos aparecen igual en todos los idiomas?
Dependen del país y del tipo de búsqueda. Que un tipo de resultado enriquecido funcione en España no garantiza que salga igual en Alemania.
¿El schema arregla el contenido duplicado?
No: esa es función del hreflang y del canonical. El schema describe, no desambigua. El marco completo está en contenido duplicado en webs multiidioma.
Seguir leyendo
Esta pieza forma parte de la guía de WordPress multiidioma, donde está el recorrido completo: estructura de URL, elección de plugin, traducción automática, SEO y presupuesto. Si lo que te falta es decidir herramienta, la comparativa está en los mejores plugins de traducción.
- hreflang con Yoast SEO — qué cubre de verdad y qué te toca completar
- contenido duplicado en webs multiidioma — cuándo Google no te penaliza y cuándo sí
- traducir WordPress sin plugin — las 4 formas y cuándo compensa de verdad