2026-03-17 · Redacción Baduno · 30 blog.readMin · Blog & Conocimiento
Datos estructurados internacionales: Schema.org a través de las barreras lingüísticas
Los sitios web multilingües necesitan datos estructurados precisos para que los motores de búsqueda comprendan el contenido según el idioma. En esta guía aprenderá a utilizar correctamente los marcados de Schema.org a través de las barreras lingüísticas, desde organización hasta producto y preguntas frecuentes. Con consejos prácticos y métodos de validación, evitará errores típicos y mejorará la visibilidad internacional de sus contenidos.
Introducción a los datos estructurados para sitios web multilingües
Los datos estructurados según Schema.org ayudan a los motores de búsqueda a comprender el contenido de su sitio web, y esto trasciende las barreras del idioma. Cuando opera varias versiones lingüísticas, el marcado correcto se vuelve aún más importante. Motores de búsqueda como Google utilizan datos estructurados para mostrar resultados enriquecidos como fragmentos, precios de productos o elementos de preguntas frecuentes. En sitios multilingües, estos marcados deben ser específicos del idioma; de lo contrario, se podría mostrar información incorrecta, como un número de teléfono de la página alemana en la versión francesa.
Un error típico: transferir el esquema de un idioma a otras versiones sin ajustar las indicaciones de idioma. No basta con traducir el contenido; la estructura también debe reflejar el idioma de destino. Por ejemplo, el campo inLanguage del objeto Schema debe indicar el idioma de la página correspondiente. Una página de producto en alemán recibe `inLanguage: 'de'`, la inglesa `inLanguage: 'en'`. Además, puede usar `translationOfWork` para hacer referencia a la versión original.
En la práctica, comience con los tipos de página más importantes: Organización, Producto, Preguntas frecuentes. Estos son los más utilizados para resultados enriquecidos. Evalúe de antemano qué páginas en qué idioma son especialmente relevantes. Para un sitio corporativo internacional, es adecuado el esquema de Organización; para una tienda en línea, el esquema de Producto. Asegúrese de que cada versión de idioma tenga su propio script JSON-LD o entradas separadas en el script. Utilice herramientas como la Prueba de resultados enriquecidos de Google para validar cada versión de idioma por separado. Tenga en cuenta que la prueba solo proporciona una instantánea; se recomienda una verificación periódica.
Desde el punto de vista legal, los datos estructurados no deben contener datos personales que infrinjan el RGPD. Al proporcionar datos de contacto en diferentes países, asegúrese de que los datos sean correctos y estén actualizados. En caso de duda, solicite asesoramiento legal. Con una implementación limpia de datos estructurados multilingües, mejora sus posibilidades de ser encontrado con resultados enriquecidos relevantes en las diferentes regiones lingüísticas.
Fundamentos de Schema.org y marcado de idioma
Schema.org ofrece una estructura de vocabulario común compatible con los motores de búsqueda. Para sitios web multilingües, la marcación correcta del idioma es fundamental. Cada objeto Schema puede tener una propiedad `inLanguage` que indica el idioma del contenido (p. ej., `'de'`, `'en'`, `'fr'`). Esta indicación debe coincidir con el idioma real de la página. En JSON-LD, establezca `@language` en todo el documento o en objetos individuales si hay varios idiomas.
Un ejemplo: Para un producto en alemán, utilice: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Si marca el mismo producto en una página en inglés, en su lugar use `"inLanguage": "en"` y el nombre en inglés. Evite mezclar varias versiones de idioma en un solo objeto Schema, ya que genera incoherencias. En su lugar, use bloques de marcado separados por idioma o trabaje con matrices `@language` dentro de un objeto si la entidad es multilingüe.
Para datos específicos del sitio web como `WebSite` o `WebPage`, también debe indicar el idioma. Si la página tiene un selector de idioma, puede hacer referencia a otras versiones con `potentialAction` o `translationOfWork`. En la práctica, se recomienda colocar un bloque JSON-LD independiente para cada idioma en el `<head>` correspondiente. Así la asignación es clara y las herramientas de validación la interpretan correctamente.
Asegúrese de que los códigos de idioma utilicen el estándar ISO 639-1 (p. ej., "de" para alemán, "en" para inglés). Para variantes regionales, puede agregar el código de país, como "de-CH" para alemán suizo. En ese caso, verifique si el motor de búsqueda admite esta distinción fina; por lo general, el código básico es suficiente. Valide cada versión de idioma por separado con la Herramienta de análisis de datos estructurados de Google o la Prueba de resultados enriquecidos. Anote las posibles advertencias sobre la falta de indicaciones de idioma y corríjalas específicamente.
Esquema de Organización: Datos de la empresa en varios idiomas
El esquema Organization es ideal para empresas con sitios web multilingües, ya que proporciona información central como nombre, dirección y datos de contacto. Para cada versión de idioma, debe crear un objeto Organization independiente marcado en el idioma correspondiente. El `name` debe indicarse en el idioma de destino, por ejemplo, 'Muster GmbH' en alemán y 'Sample Inc.' en inglés. Si la empresa tiene un nombre uniforme, basta con la traducción de la descripción (`description`).
Para direcciones, use el esquema `PostalAddress` con `addressCountry` y `addressLocality`. Para ubicaciones internacionales, puede prever varias entradas `location`. Asegúrese de que los números de teléfono (`telephone`) incluyan el prefijo internacional correcto. Por ejemplo, para la página alemana `+49 30 1234567`, para la página suiza `+41 44 1234567`. Lo mismo aplica para correos electrónicos y horarios de apertura. Use `areaServed` para cubrir los países donde opera la empresa.
Un detalle que a menudo se pasa por alto es la propiedad `sameAs` para perfiles de redes sociales. Si existen, añada perfiles específicos por idioma, como la página de Facebook en alemán y la cuenta de Twitter en inglés. La `url` también debe apuntar a la página de inicio específica del idioma. En sitios web multilingües, puede usar `translationOfWork` para relacionar las versiones de idioma, siempre que las páginas representen el mismo contenido en otro idioma.
Recomendación práctica: Implemente el esquema Organization en la página de inicio de cada versión de idioma. Para ello, añada un script JSON-LD en el `<head>`. Evite duplicados creando un bloque independiente para cada idioma con el `inLanguage` adecuado. Valide el marcado con la Prueba de resultados enriquecidos de Google y compruebe que los datos de contacto se muestren correctamente. Legalmente, debe asegurarse de que la información proporcionada sea completa y cumpla con la protección de datos. Especialmente en varias ubicaciones: la obligación del aviso legal puede diferir según el país. En caso de duda, busque asesoramiento legal. Con estos detalles, se asegura de que su empresa esté representada de manera uniforme y correcta en todas las regiones lingüísticas.
Esquema de Producto: Descripciones de productos en idiomas específicos
Para sitios web multilingües, es esencial marcar los productos con Schema.org Product en el idioma correspondiente. Cada versión lingüística de un producto debe tener su propio marcado Schema, que incluya el nombre local, la descripción y atributos como precio, moneda o disponibilidad. Para ello, use el atributo `inLanguage` por idioma – p. ej., `"inLanguage": "de-DE"` para alemán (Alemania). Asegúrese de que el nombre del producto y la descripción en el objeto JSON-LD estén realmente en alemán, no solo la etiqueta de idioma.
Un error común es marcar todas las variantes de idioma con el mismo `@id` (p. ej., un ID de producto global). En su lugar, asigne un `@id` diferente para cada idioma, como `https://example.com/de/produkt/123` y `https://example.com/fr/produit/123`. Así Google puede mostrar la versión correcta. Para los precios, use `priceCurrency` con el código ISO-4217 (p. ej., EUR, USD) e indique el precio específico del idioma – aunque el precio sea el mismo, pertenece a la página local.
Recomendación práctica: cree una plantilla JSON-LD para cada producto que establezca dinámicamente los parámetros de idioma. Verifique cada versión de idioma individualmente con el Rich Results Test de Google. Asegúrese de que el atributo `url` apunte a la URL del idioma correspondiente. Evite mezclar todos los idiomas en un solo bloque JSON-LD – esto a menudo genera errores de validación. Para las imágenes, puede mantener el atributo `image` independiente del idioma, pero asegúrese de que las URL de las imágenes sean correctas.
Adicionalmente, puede adaptar `offers` con `availability` según el mercado (p. ej., `InStock` para Alemania, `PreOrder` para Francia). Use `gtin` o `mpn` de forma global, pero mantenga variantes locales para `sku`. Por último, compruebe que los datos estructurados en Search Console se indexen correctamente para cada versión de idioma.
Esquema FAQ: Optimizar páginas de preguntas y respuestas multilingües
Las páginas de FAQ en varios idiomas se benefician de un marcado claro y específico del idioma con el esquema FAQPage. Cada versión lingüística de la página de FAQ recibe su propio objeto JSON-LD. Establezca `inLanguage` con el código de idioma correspondiente (p. ej., `fr-FR` para francés). Las preguntas y respuestas deben estar redactadas en el idioma de destino dentro del objeto – a menudo no basta con una traducción automática; que un hablante nativo las revise, ya que los matices son cruciales.
Un error típico: usar el mismo `@id` para todas las variantes de idioma. En su lugar, use la URL específica del idioma como `@id`, p. ej., `https://example.com/de/faq/` y `https://example.com/en/faq/`. Dentro del esquema FAQPage, enumere las preguntas como `mainEntity` con `@type: Question` y la respuesta correspondiente como `acceptedAnswer`. Cada pregunta puede recibir adicionalmente `inLanguage`, aunque es redundante si toda la página está marcada. Mantenga el número de preguntas por página en un máximo de 10–15, ya que los motores de búsqueda solo consideran un número limitado de entradas.
Recomendación práctica: utilice un sistema de gestión de contenidos que ofrezca un campo multilingüe por cada entrada de FAQ. En la salida JSON-LD, consulte dinámicamente el idioma actual. Valide cada versión de idioma individualmente con el Rich Results Test y preste atención a las advertencias sobre propiedades `name` faltantes en las preguntas. Añada una `url` a cada pregunta que enlace al ancla correspondiente – así los usuarios pueden saltar directamente a la respuesta adecuada.
Tenga en cuenta: FAQPage solo es adecuado para páginas con preguntas y respuestas explícitas. No lo use para páginas de soporte general. Tras el despliegue, pruebe la visibilidad en la búsqueda de Google – los fragmentos enriquecidos de FAQ suelen aparecer en consultas con partículas interrogativas. Para el SEO multilingüe, vale la pena adaptar las respuestas a formulaciones propias de cada país (p. ej., „¿Cómo puedo?“ vs. „Comment puis-je?”).
Los detalles de inLanguage: código de idioma y configuración regional
El atributo `inLanguage` en Schema.org indica el idioma de un contenido, donde el valor idealmente consiste en un código de idioma (ISO 639-1) y un código de región opcional (ISO 3166-1 Alpha-2) – por ejemplo, `en-US` para inglés estadounidense. La región es importante cuando los contenidos difieren: «colour» frente a «color» o diferentes unidades de medida. Sin región, el código se interpreta como idioma general. Por lo tanto, use `de-DE`, `de-AT`, `de-CH` para páginas específicas de un país, incluso si el texto es casi idéntico.
Un ejemplo práctico: un producto se ofrece en una página alemana y otra austriaca. El idioma es alemán, pero los precios y condiciones de envío difieren. Configure `inLanguage: "de-DE"` para la página alemana y `"de-AT"` para la austriaca. Así Google puede entender mejor la relevancia regional. Lo mismo aplica para `en-GB` y `en-US`. Si no necesita distinción regional, basta con `"de"` o `"en"`. Sin embargo, asegúrese de que el código de idioma siempre esté en minúsculas y la región en mayúsculas (por ejemplo, `fr-CA`).
Un error común es usar `inLanguage` en un objeto superior mientras los subobjetos tienen otro idioma. Ejemplo: un sitio web en alemán pero un artículo individual en inglés. Entonces configure `inLanguage: "de"` en el sitio web e `inLanguage: "en"` en el artículo. Valídelo con un validador de esquemas, ya que algunas herramientas reportan conflictos. Para páginas multilingües con etiquetas hreflang, `inLanguage` debe corresponder al valor hreflang respectivo – esto ayuda a Google a entregar la versión correcta.
Implementación práctica: defina un `@id` único por versión de idioma y configure `inLanguage` de forma consistente. Use un archivo de configuración central que contenga los códigos correctos para cada idioma. Pruebe con la herramienta de schema.org si se acepta la etiqueta `inLanguage`. Un consejo: incluso en páginas AMP o datos estructurados mediante microdatos, no olvide `inLanguage`. En JSON-LD, colóquelo en el nivel superior (por ejemplo, `WebSite` o `WebPage`). Para contenido dinámico como artículos de blog, `inLanguage` puede variar según la entrada – entonces configúrelo por elemento.
Marcar correctamente el multilingüismo en una única URL
Cuando una URL contiene contenido en varios idiomas – por ejemplo, mediante un selector de idioma, pestañas o acordeones –, debe indicar claramente en los datos estructurados qué texto pertenece a qué idioma. De lo contrario, un rastreador de motores de búsqueda podría asumir erróneamente que todo el contenido está en un solo idioma, lo que provoca errores en la indexación y visualización.
El método básico es usar el atributo `inLanguage` en los elementos correspondientes. En un esquema FAQ con preguntas y respuestas en alemán e inglés en la misma página, marque cada pregunta y respuesta por separado: ```json { "@type": "Question", "name": "¿Cómo me registro?", "inLanguage": "es", "acceptedAnswer": { "@type": "Answer", "text": "Haga clic en ...", "inLanguage": "es" } } ``` Lo mismo aplica para esquemas de Producto: describa `name` y `description` por idioma en un objeto `Product` independiente con su propio `inLanguage`, o use `@language` y `@value` en una propiedad `multilingualDescription` (si su vocabulario lo admite).
Para organizaciones con nombres multilingües, use un array de objetos `name`: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Evite declarar toda la página como multilingüe. En su lugar, realice la asignación de idioma de la forma más granular posible. Un error común es establecer `inLanguage` solo en el nivel superior de un esquema sin marcar los elementos secundarios. Por lo tanto, verifique en su flujo de validación que todos los textos estén correctamente etiquetados por idioma.
Como recomendación práctica: cree un objeto de esquema separado para cada variante de idioma en una URL, que contenga solo los textos de ese idioma, y establezca `inLanguage` en el código de idioma correspondiente. Si la página muestra por defecto un idioma principal pero carga otros mediante JavaScript, incluya los datos estructurados para todos los idiomas de forma estática en el HTML. Herramientas como Google Rich Results Test le mostrarán si el marcado se interpreta correctamente. Pruebe cada versión de idioma por separado forzando al rastreador al idioma deseado mediante un parámetro de URL o control de cookies.
Diferenciación entre hreflang e inLanguage: ¿cuándo usar cada método?
`hreflang` e `inLanguage` cumplen propósitos diferentes en el SEO internacional y no deben confundirse. `hreflang` es un elemento HTML o encabezado HTTP que indica a los motores de búsqueda que existen versiones alternativas en otros idiomas o regiones de la misma página. Sirve para mostrar la página correcta a usuarios de diferentes países o con configuraciones de idioma específicas. `inLanguage`, por otro lado, es un atributo en datos estructurados (Schema.org) que especifica el idioma en el que está redactado un elemento de texto concreto.
¿Cuándo usar cada uno? Use `hreflang` cuando tenga URLs separadas para diferentes versiones de idioma (p. ej., `example.com/de/` y `example.com/en/`). Así evita problemas de contenido duplicado y se asegura de que la página correcta aparezca en el snippet. `inLanguage` es necesario cuando marca contenido multilingüe en una sola URL o cuando un elemento de datos estructurados, como una descripción de producto, está disponible en varios idiomas. `inLanguage` complementa a `hreflang` a nivel de bloques de texto individuales.
Un malentendido común: `inLanguage` no reemplaza a `hreflang`. Incluso si marca cada línea de un artículo con `inLanguage`, los motores de búsqueda no sabrán si existen versiones alternativas de toda la página sin `hreflang`. A la inversa, `hreflang` no es suficiente para describir de forma granular el contenido multilingüe dentro de una misma URL. En la práctica, si tiene páginas separadas para cada idioma, `hreflang` es primordial, mientras que `inLanguage` solo indica el idioma concreto del contenido en los datos estructurados de esas páginas. Si hay varios idiomas en una URL, necesita `inLanguage` para cada elemento específico de un idioma.
Recomendación concreta: Planifique su estrategia de URL antes de la implementación. Decida si usará una URL por idioma (ccTLD, subdominio, subdirectorio) o una URL compartida con cambio dinámico de idioma. Para esta última, es esencial un marcado correcto con `inLanguage`. En cualquier caso, verifique que sus etiquetas `hreflang` apunten a todas las versiones de idioma relevantes y que no haya contradicciones con las indicaciones de `inLanguage` en los datos estructurados. La conciliación de estas dos señales puede ayudar a los motores de búsqueda a asignar correctamente su contenido.
Flujo de trabajo de validación: herramientas y verificaciones automatizadas
La verificación manual de los datos estructurados en cada versión de idioma es propensa a errores y requiere mucho tiempo. Un flujo de trabajo de validación automatizado garantiza que sus marcados Schema.org sean correctos y se mantengan así, incluso tras actualizaciones de contenido o al añadir nuevos idiomas. Las herramientas más importantes son Google Rich Results Test (para tipos compatibles con Google, como FAQ, Product) y Schema.org Validator (para la verificación de sintaxis pura). Además, rastreadores como Screaming Frog SEO Spider ayudan a extraer y verificar los datos estructurados de todo su sitio web.
Integre la verificación en su proceso CI/CD: tras cada despliegue o actualización de idioma, ejecute una prueba automatizada. Utilice la API de Google Rich Results Test o un script que analice sus páginas y valide los bloques JSON-LD contra un esquema definido por usted. Preste especial atención a las siguientes fuentes de error: - Falta de `inLanguage` en lugares donde aparecen varios idiomas. - Códigos de idioma contradictorios (p. ej., "de" en lugar de "de-DE" para variantes regionales). - Campos obligatorios incompletos (p. ej., `name` en Product para cada idioma). - Etiquetas `hreflang` obsoletas que ya no coinciden con sus URLs actuales.
Recomendación práctica: cree una lista de verificación para cada tipo de esquema (Organization, Product, FAQ) con los atributos requeridos por idioma. Utilice una herramienta de prueba como `json-schema` para la validación automática de sus datos. Además, realice periódicamente (por ejemplo, mensualmente) un rastreo completo con el validador de Schema.org y genere informes de las páginas con errores. Documente las categorías de error y asigne responsables para las correcciones. Tenga en cuenta que los datos estructurados deben verificarse en las páginas en vivo; una prueba en staging no es suficiente, ya que allí puede haber contenido diferente. Solo así se asegurará de que los errores relevantes para los motores de búsqueda se corrijan a tiempo.
Los sitios web multilingües necesitan datos estructurados precisos para que los motores de búsqueda comprendan el contenido según el idioma. En esta guía aprenderá a utilizar correctamente los marcados de Schema.org a través de las barreras lingüísticas, desde organización hasta producto y preguntas frecuentes. Con consejos prácticos y métodos de validación, evitará errores típicos y mejorará la visibilidad internacional de sus contenidos.
Errores comunes en los datos estructurados internacionales
El marcado de sitios web multilingües con Schema.org presenta escollos típicos. Un error frecuente es la ausencia o la indicación incorrecta del atributo de idioma `inLanguage`. Por ejemplo, si ofrece un producto en alemán pero no establece `inLanguage: "de-DE"` en el marcado, los motores de búsqueda pueden interpretar los datos como neutros en cuanto al idioma. Otro error fundamental es la mezcla de idiomas dentro de un solo bloque de Schema. Debe evitar establecer la propiedad `name` en inglés y la `description` en alemán en un objeto `Product`. En su lugar, debe crear un bloque separado para cada versión de idioma con el `inLanguage` correcto.
Otro error común es el uso de tipos de Schema inapropiados. Para una empresa multilingüe, muchos recurren erróneamente a `LocalBusiness`, aunque `Organization` es la opción correcta si no hay una dirección física en cada idioma. También en productos se olvida a menudo marcar la propiedad `offers` específica del idioma. Además, se descuida la actualización de los datos estructurados tras las traducciones: un texto de producto recién traducido debe ajustarse también en el marcado; de lo contrario, los resultados de búsqueda mostrarán información obsoleta o incorrecta.
La negligencia en la validación es otro error cardinal. Después de cada cambio, debe comprobar los marcados con herramientas adecuadas. Las referencias `@id` incorrectas o faltantes en entidades que son iguales en todos los idiomas (por ejemplo, una organización) provocan duplicados o datos incompletos. Además, a menudo se ignora la interacción con `hreflang`: cuando no existen URL alternativas, debe trabajar con `inLanguage` en la misma página.
Recomendaciones de acción: Verifique cada marcado para asegurar una asignación correcta del idioma. Utilice bloques de Schema separados para cada versión de idioma con `@id` únicos. Evite mezclas: también en `aggregateRating` o `review` el idioma debe ser coherente. Realice una nueva validación tras cada traducción y coteje los datos con los contenidos visibles. Solo así se asegurará de que los motores de búsqueda entiendan correctamente sus ofertas multilingües.
Prueba con Google Rich Results, Bing Webmaster Tools y Yandex
La verificación de los marcados Schema.org multilingües no debe limitarse a una sola herramienta. Cada motor de búsqueda tiene sus propias interpretaciones y criterios de validación. El Google Rich Results Test es el primer punto de partida: introduzca una URL con su marcado o pegue el código directamente. Preste atención a todos los errores y advertencias, especialmente si las indicaciones `inLanguage` se reconocen correctamente. Un problema común es que Google acepta `de-DE`, pero emite una advertencia si falta la parte regional (`de`). Pruebe cada versión de idioma por separado.
Bing Webmaster Tools ofrece una comprobación de URL con una vista de datos estructurados. Aquí podrá ver si Bing interpreta los marcados como se espera. Bing suele ser más estricto en la validación de `inLanguage` y puede exigir el código de idioma de dos letras sin región (p. ej., `de` en lugar de `de-DE`). Realice una prueba en vivo y corrija las desviaciones. Bing también muestra posibles duplicados si los valores `@id` se usan varias veces.
Yandex Webmaster tiene su propio validador, relevante sobre todo para sitios en ruso. También aquí puede probar datos estructurados. Yandex admite la mayoría de los tipos de Schema.org, pero el manejo de errores difiere. En particular, en los marcados `Product` a menudo se critica la propiedad `availability`. Por lo tanto, pruebe también aquí cada versión de idioma. Tenga en cuenta que Yandex puede ponderar de manera diferente los códigos de idioma regionales como `de-DE`.
Recomendaciones de acción: Pruebe cada versión de idioma en las tres herramientas después de la implementación y tras cada cambio. Anote las desviaciones y ajuste los marcados para que sean aceptados por los tres motores de búsqueda. Idealmente, utilice el código de idioma de dos letras (`de`, `en`) en `inLanguage`, ya que es comprendido de manera uniforme por la mayoría de los sistemas. Automatice las pruebas con herramientas de CI para mantener una visión general en sitios web multilingües con muchas páginas.
Lista de verificación para la implementación de marcas Schema.org multilingües
Un enfoque estructurado previene errores típicos en la internacionalización. Antes de la implementación, debe definir la estrategia de idioma: ¿utilizar URLs separadas por idioma (p. ej., `/de/produkt` y `/en/product`) o una sola URL con conmutación de idioma? Para URLs separadas, use `hreflang` y un marcado propio por URL. Para una sola URL, inserte varios bloques `inLanguage` con diferentes códigos de idioma. Planifique también qué tipos de esquema se necesitan: Empresa (Organization), Productos (Product), FAQ (FAQPage), etc.
Durante la implementación, tenga en cuenta los siguientes puntos: Cada objeto de esquema recibe un `@id` único que identifica la entidad independientemente del idioma. Para cada versión de idioma, cree un objeto separado que indique el idioma mediante `inLanguage`. Use códigos de idioma coherentes, preferiblemente el código ISO de dos letras (p. ej., `de`, `en`) complementado con la región si es necesario. Enlace correctamente dentro de los marcados: en `Organization`, use `url` y `logo` con rutas específicas del idioma. Verifique que textos como `name` y `description` coincidan con los contenidos visibles.
Tras la implementación, sigue la validación: pruebe cada versión de idioma con Google Rich Results Test, Bing Webmaster Tools y Yandex. Corrija errores y advertencias. Preste especial atención a la falta de `inLanguage` o códigos de idioma incorrectos. Utilice también la herramienta de validación de Schema.org de Google para comprobar la sintaxis. Documente todos los cambios y realice nuevas pruebas después de cada traducción.
Por último, el monitoreo forma parte del proceso: supervise el rendimiento en Search Console, especialmente los informes de datos estructurados. Reaccione ante nuevos errores o advertencias. Actualice los marcados rápidamente cuando modifique o traduzca contenidos. Realice auditorías periódicas para garantizar la coherencia en todas las versiones de idioma. Una implementación bien mantenida de Schema.org mejora la visibilidad en los resultados de búsqueda, sin garantías pero con un beneficio práctico.
Avisos legales: Responsabilidad propia en la traducción automática
La traducción automática de datos estructurados conlleva riesgos legales que usted, como operador de un sitio web multilingüe, debe examinar bajo su propia responsabilidad. En particular, en los marcados Schema.org que contienen contenido jurídicamente relevante, como advertencias de seguridad de productos, términos y condiciones o denominaciones de marca, una traducción inexacta puede dar lugar a responsabilidades. Por ejemplo, un nombre de producto mal traducido o una descripción de producto engañosa podría infringir la legislación sobre competencia desleal. Por ello, recomendamos que todas las traducciones generadas automáticamente sean revisadas por un profesional nativo. Esto se aplica especialmente a campos como «description» en el esquema de Producto o «answer» en el esquema de FAQ, donde los matices son cruciales.
Además de la corrección del contenido, también entran en juego aspectos de protección de datos: si su esquema contiene datos personales (p. ej., reseñas de clientes en el esquema de Review), debe asegurarse de que la traducción cumpla con el RGPD. Los servicios de traducción automática solo deben utilizarse si ofrecen garantías suficientes de protección de datos. No existe una prohibición general, pero la responsabilidad del tratamiento de datos recae en usted como operador del sitio web. Consulte a un asesor jurídico sobre los requisitos específicos de sus países de destino.
Otro escollo legal: el uso de «inLanguage» con códigos de idioma no permitidos. Utilice siempre los códigos BCP-47 oficiales (p. ej., «de-DE» en lugar de «deutsch»). Los códigos incorrectos pueden hacer que los motores de búsqueda ignoren sus marcados, lo que, aunque no supone un problema legal, perjudica la visibilidad. Por lo tanto, antes de la publicación, realice una validación con herramientas como Google Rich Results Test y compruebe adicionalmente si las traducciones cubren correctamente todos los campos jurídicamente relevantes.
Recomendación de actuación: defina un flujo de trabajo en el que cada marcado Schema traducido automáticamente sea revisado por un redactor nativo o un jurista. Documente este proceso para poder demostrar en caso de controversia que ha cumplido con su deber de diligencia. Evite la traducción automática de bloques de texto con carácter jurídico (p. ej., condiciones de garantía, exclusiones de responsabilidad); tradúzcalos manualmente o mediante un servicio especializado.
Perspectiva: Localización asistida por IA y futuros desarrollos de esquemas
La localización de los marcados Schema.org se facilita cada vez más mediante herramientas basadas en IA. Los sistemas actuales pueden generar traducciones basadas en redes neuronales que son contextualmente más precisas que los métodos estadísticos anteriores. Para sitios web multilingües, esto significa que pueden transferir grandes volúmenes de datos de productos o contenidos de preguntas frecuentes a varios idiomas más rápidamente. Sin embargo, el control de calidad sigue siendo crucial, ya que los modelos de IA no siempre captan correctamente los términos específicos del sector o los matices regionales. Un enfoque práctico es utilizar la IA para la traducción preliminar, seguida de una revisión humana. Herramientas como Baduno combinan la traducción con IA con la revisión de hablantes nativos, ofreciendo así una solución escalable.
Paralelamente al desarrollo de la IA, Schema.org amplía continuamente su vocabulario. Los futuros tipos podrían abordar más los contenidos generados por IA, como un esquema "AIContent" para etiquetar textos creados por máquinas. También cobra mayor importancia la vinculación con grafos de conocimiento: los marcados multilingües podrían generarse automáticamente a partir de bases de conocimiento centralizadas. Ya existe la propiedad "translationOfWork", que explicita la relación entre contenidos traducidos. Recomendamos incorporar estas nuevas propiedades a su estrategia con antelación para estar preparados ante las actualizaciones de los motores de búsqueda.
Otra tendencia son los marcados dinámicos específicos por idioma, que se muestran según el contexto del usuario. Por ejemplo, un esquema de Producto podría incluir la moneda local y la unidad de medida según la ubicación del usuario. El desafío radica en el uso correcto de "inLanguage" y en evitar conflictos con hreflang. Futuras versiones de Schema podrían definir más claramente cómo representar las variantes regionales dentro de un esquema. Para prepararse, debe construir sus marcados de forma modular: utilice bloques separados para cada idioma dentro del mismo JSON-LD o use etiquetas script separadas por versión de idioma, según su infraestructura técnica.
Recomendación de acción: pruebe soluciones de traducción basadas en IA con un conjunto representativo de sus datos de esquema y mida la tasa de error. Manténgase al día con las notas de lanzamiento de Schema.org para identificar nuevas propiedades. Pilote la visualización dinámica de marcados para diferentes audiencias y valide los resultados con las Search Consoles de los principales motores de búsqueda. Así se asegurará de que su sitio multilingüe se beneficie de los desarrollos futuros sin asumir riesgos legales o técnicos.
Ejemplo práctico: Implementación paso a paso de una página de producto multilingüe
Para poner en práctica los fundamentos teóricos, consideremos un sitio web ficticio de comercio electrónico que ofrece un smartphone en los idiomas alemán, inglés y francés. Supongamos que la página del producto está disponible bajo una sola URL con un selector de idioma (por ejemplo, example.com/smartphone). El objetivo es marcar el marcado de Producto de Schema.org con información específica de cada idioma.
1. **Establecer códigos de idioma**: Para cada variante de idioma se utiliza un valor inLanguage único. Ejemplo: Alemán: "de-DE", Inglés: "en-US", Francés: "fr-FR".
2. **Marcar nombre y descripción específicos por idioma**: En el marcado JSON-LD se utiliza un array @graph. A cada variante de idioma se le asigna un objeto Producto propio con su inLanguage correspondiente. Ejemplo: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Product", "inLanguage": "de-DE", "name": "Smartphone Pro Max", "description": "Smartphone potente con 128 GB de almacenamiento", "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. **Validar el marcado**: Con el Google Rich Results Test se comprueba para cada versión de idioma si el marcado es aceptado. Hay que asegurarse de que las indicaciones inLanguage coincidan con el idioma real de la página.
4. **Inclusión mediante servidor o JavaScript**: En la práctica, lo mejor es generar el marcado del lado del servidor, de modo que el código fuente de la página contenga el JSON-LD completo. En caso de cambios dinámicos de idioma mediante JavaScript, el marcado se puede cargar posteriormente, aunque es posible que los motores de búsqueda no lo detecten.
5. **Prueba de visibilidad**: Tras la implementación, se verifica que los datos estructurados se notifiquen como válidos en Google Search Console y que los resultados enriquecidos aparezcan en la búsqueda.
Este ejemplo paso a paso muestra cómo proceder concretamente. Adapte la estructura a su tecnología y pruebe cada variante de idioma por separado.
Colaboración con proveedores de servicios de traducción y localización
Al implementar datos estructurados multilingües, a menudo se trabaja con traductores o agencias de localización. Es importante que los marcados de Schema.org también formen parte del proceso de localización. Acuerde con su proveedor que no solo el contenido visible, sino también los valores en JSON-LD (p. ej., «name», «description») deben traducirse. Un error frecuente: la agencia recibe solo el texto de la página, pero no los datos estructurados. Por ello, proporcione un documento separado con todos los campos de Schema, idealmente en formato JSON, y establezca qué campos se traducen por idioma (p. ej., «offers» o «review» pueden permanecer globales, mientras que «name» varía según el idioma).
Consejo práctico: utilice glosarios y memorias de traducción también para sus datos estructurados. Así se asegura de que los nombres de productos y términos técnicos aparezcan de forma coherente en todos los marcados. Solicite además al proveedor que establezca los códigos de idioma (inLanguage) según sus indicaciones, por ejemplo, «de-DE» en lugar de solo «de». Tras la entrega, realice comprobaciones aleatorias para verificar que todos los valores traducidos estén correctamente insertados en los marcados. Una prueba automatizada con la herramienta de Prueba de resultados enriquecidos de Google puede proporcionar indicios iniciales.
Otro aspecto: la colaboración en el aseguramiento de la calidad. Acuerde que los datos de Schema traducidos sean revisados por un editor nativo antes de su publicación. Los atributos de producto o instrucciones mal traducidos en preguntas frecuentes pueden perjudicar el posicionamiento internacional. Documente todo el proceso, desde la extracción de los textos fuente hasta la implementación, y actualice su lista de verificación para cada versión lingüística. Así evitará que los datos estructurados queden desactualizados en futuras actualizaciones de contenido.
Aviso legal: la responsabilidad de las traducciones correctas recae en usted. Solicite una confirmación por escrito del cumplimiento de sus directrices y aclare contractualmente las cuestiones de responsabilidad en caso de traducciones erróneas. Se recomienda asesoramiento jurídico independiente.
Planificación presupuestaria y estimación de esfuerzos para la implementación de esquemas multilingües
La introducción de datos estructurados en varios idiomas genera costes únicos y recurrentes. Además de la mera traducción de los contenidos del marcado, se incurre en gastos de integración técnica, pruebas y mantenimiento. Para una planificación presupuestaria realista, debe tener en cuenta las siguientes partidas:
1. Traducción de los campos de Schema: por cada versión lingüística se generan costes de traducción de todos los elementos JSON-LD relevantes (títulos, descripciones, preguntas, respuestas, etc.). Dado que se trata de textos cortos y a menudo técnicos, las agencias de traducción pueden ofrecer precios especiales. Calcule un recargo del 10–20 % por la familiarización con las definiciones de Schema.
2. Adaptación técnica: el marcado debe realizarse por idioma, ya sea en bloques JSON-LD separados o mediante campos multilingües. Dependiendo del sistema, su equipo de desarrollo necesitará tiempo adicional para implementar la lógica de cambio de idioma y alternativas. La experiencia indica que el esfuerzo inicial para un sitio web con cinco versiones lingüísticas oscila entre 15 y 25 días-persona de desarrollo.
3. Pruebas y aseguramiento de la calidad: cada versión lingüística debe validarse por separado, con la herramienta de Prueba de resultados enriquecidos de Google, validadores de Schema.org y muestreos manuales. Calcule aproximadamente 1–2 días por idioma para la configuración inicial y media hora por cada modificación.
4. Mantenimiento continuo: al actualizar el catálogo de productos o el contenido de las preguntas frecuentes, los marcados deben ajustarse oportunamente. Establezca si el equipo de traducción debe proporcionar siempre los datos de Schema junto con los nuevos contenidos. Un sistema de gestión de contenidos que genere datos estructurados automáticamente reduce el esfuerzo a largo plazo, pero requiere una configuración adecuada.
5. Herramientas y licencias: si utiliza herramientas especiales para supervisar los datos estructurados (p. ej., API de Search Console o cuadros de mando propios), es posible que se apliquen cuotas de suscripción.
Como regla general, para todo el proceso (introducción en tres idiomas principales) debe presupuestar entre 5.000 y 15.000 euros, dependiendo del alcance del sitio y del número de productos. En proyectos pequeños con pocas páginas de preguntas frecuentes, la cantidad puede ser inferior.
Aviso legal: las cifras mencionadas son meramente orientativas. Solicite presupuestos individuales a desarrolladores y traductores, y tenga en cuenta que los costes reales pueden variar según la complejidad. Para declaraciones vinculantes, consulte a su asesoría jurídica y fiscal.
blog.faqT
¿Cómo se estructura un esquema de FAQ cuando las preguntas varían según el idioma?
Cree entradas mainEntity independientes con question y acceptedAnswer para cada versión de idioma. Use inLanguage en el nivel superior del esquema de FAQ para el idioma objetivo. Para contenido idéntico en diferentes URL, use hreflang; para traducciones en una misma página, basta con inLanguage. Asegúrese de que las respuestas estén completa y correctamente traducidas al idioma correspondiente; las traducciones automáticas deben ser revisadas legalmente.
¿Puedo marcar una página de producto con una sola URL para varios idiomas?
Sí, siempre que el contenido en la misma URL sea multilingüe (p. ej., mediante pestañas o AJAX). Establezca inLanguage en el fragmento DOM correspondiente o utilice un esquema separado por idioma con su propio inLanguage. Además, debe proporcionar un name y description en el idioma de destino para cada versión lingüística. Cuando las URL sean claras por país o idioma, generalmente es preferible combinarlo con hreflang.
¿Qué herramientas son adecuadas para validar marcas Schema.org multilingües?
Google Rich Results Test verifica URLs individuales y muestra errores en códigos de idioma. Bing Webmaster Tools ofrece funciones similares. Para pruebas automatizadas en varias páginas, son adecuados rastreadores como Screaming Frog, que extraen datos estructurados. Siempre valide manualmente que las traducciones en name, description y otras propiedades sean correctas; aquí es donde ocurren la mayoría de los errores en la práctica.
