¿Cómo gestiona un Headless CMS las asociaciones entre contenidos multilingües en sitios web globales?

Cuando un sitio web global se publica en varios idiomas, los problemas más habituales no son «si hay traducciones», sino que, tras actualizar la página de producto en inglés, no se sabe qué debe sincronizarse en la página en alemán; que, al cambiar de idioma, el usuario vuelve a la página de inicio; o que las traducciones retiradas siguen apareciendo en la navegación de idiomas. Para gestionar estas relaciones, se debe conectar cada versión lingüística mediante un identificador estable de grupo de contenido y registrar por separado el idioma, la región, el estado de publicación y la versión de origen, en lugar de intentar deducir la correspondencia a partir del título o la URL.

Al evaluar una solución de Headless CMS for global websites, es necesario validar conjuntamente el modelo de contenido, el flujo de traducción y la salida del frontend. Que el CMS conserve las relaciones no significa que el sitio vaya a cambiar correctamente de idioma o a generar hreflang. La API de entrega debe proporcionar información suficiente para que el frontend identifique «qué versiones lingüísticas de un mismo contenido están disponibles públicamente».

Defina primero qué significa «el mismo contenido» y después decida cómo almacenar las traducciones

Las descripciones en inglés y alemán de un mismo producto suelen pertenecer a un grupo de contenido, pero las páginas promocionales dirigidas a mercados distintos y con condiciones de oferta diferentes no son necesariamente simples traducciones. Antes de modelar el contenido, determine qué páginas comparten una misma identidad de negocio y cuáles son contenidos de mercado independientes. De lo contrario, emparejarlas a la fuerza puede llevar al usuario a una página que no es equivalente.

Se recomienda separar la identidad de negocio de la identidad de cada versión lingüística para evitar que las relaciones se rompan al cambiar los títulos o las rutas de idioma:

• contentGroupId: identifica el mismo contenido entre distintos idiomas y no cambia con la traducción o el cambio de nombre.
• variantId y locale: identifican una versión concreta y su configuración regional, por ejemplo, de-DE; dentro de un mismo grupo, cada locale debe tener una restricción de unicidad.
• sourceVariantId y sourceRevision: registran la versión y la revisión en las que se basa la traducción, para determinar si está desactualizada.
• slug, estado y fecha de publicación: se mantienen de forma independiente para cada versión lingüística; no se debe asumir que heredan el resultado de publicación del idioma de origen.

Se recomienda utilizar el formato BCP 47 para los códigos de idioma. La decisión de distinguir entre en-US y en-GB debe basarse en las diferencias de contenido, no en añadir una versión nueva simplemente porque exista un país de destino. Los códigos de mercado del sistema empresarial pueden almacenarse por separado; no deben mezclarse con el campo de idioma.

¿Cómo elegir entre la localización de campos y las entradas independientes por idioma?

Ambos modelos permiten establecer relaciones; la diferencia está en el nivel de granularidad de la edición y la publicación.

El modelo y los parámetros técnicos pueden compartirse, mientras que los títulos, las descripciones y los textos SEO se mantienen por idioma. Los precios, la información sobre certificaciones y las condiciones de entrega, en cambio, pueden requerir ajustes por mercado. No traduzca todos los campos indiscriminadamente ni permita que los «campos compartidos» oculten diferencias regionales reales.

Las relaciones también deben abarcar el contenido referenciado. Si una página de producto en alemán hace referencia a material descargable en inglés, el sistema debe indicar claramente si se trata de un recurso compartido cuyo uso está permitido o si falta la versión en alemán. No basta con comprobar el texto principal de la página.

Integre las relaciones de traducción en el proceso de publicación, no solo en la interfaz de edición

La existencia de una traducción no significa que siga siendo válida. Cuando se modifica el texto de origen, compare la revisión de origen registrada para la traducción con la revisión actual y marque las versiones afectadas como «pendientes de revisión», en lugar de sobrescribir directamente el texto aprobado. La decisión de retirar una traducción antigua debe depender del riesgo de la modificación: no conviene aplicar la misma estrategia a un ajuste de redacción y a un cambio de parámetros de seguridad.

1. Cuando el texto de origen esté listo para traducirse, genere una tarea que incluya el grupo de contenido, el idioma, la ruta del campo y la revisión de origen.
2. Al recibir la traducción, compruebe la revisión de origen. Si el texto de origen ha cambiado, conserve el borrador y avise del conflicto; no lo sobrescriba de forma silenciosa.
3. Durante la revisión, compruebe la terminología, los recursos referenciados, las restricciones regionales y los campos SEO localizados. A continuación, publique con los permisos correspondientes.
4. Tras publicar o retirar contenido, active mediante Webhook la reconstrucción de páginas, la invalidación de caché y la actualización de la navegación de idiomas, y vuelva a intentar los eventos que hayan fallado.

Las devoluciones de llamada de las tareas deben procesarse de forma idempotente para evitar que los reintentos generen entradas duplicadas. Las interfaces de vista previa y de entrega pública también deben mantenerse separadas para evitar que las relaciones de idioma expongan borradores en el sitio publicado.

El resultado de fallback de la API debe poder identificarse

Si se solicita una página en francés y se devuelve contenido en inglés, pero el frontend sigue identificándolo como francés, el idioma declarado no coincidirá con el texto de la página. La API debe devolver el idioma solicitado, el idioma del contenido realmente devuelto y si se ha activado el fallback; no debe devolver únicamente el cuerpo del texto.

Se recomienda configurar reglas de fallback por separado para el contenido de las páginas, los menús y los recursos compartidos. Si falta la traducción de un menú, puede aplicarse el fallback previsto por la estrategia del producto. Si la traducción de una página completa aún no se ha publicado, debe elegirse explícitamente entre ocultar la entrada de ese idioma, indicar que no está disponible o redirigir a la dirección en el idioma de origen. No se debe copiar el texto de origen bajo una URL del idioma de destino sin avisar al usuario.

Las claves de caché deben distinguir, como mínimo, el contenido, el idioma y el entorno de entrega. De lo contrario, aunque las relaciones de la base de datos sean correctas, el uso compartido de la caché puede hacer que se devuelva la misma página a solicitudes en distintos idiomas.

Las relaciones SEO solo deben hacer referencia a versiones realmente accesibles

El selector de idioma y hreflang deben utilizar los mismos datos de relaciones publicados. Al cambiar de idioma, conserve el grupo de contenido; no se limite a sustituir el prefijo de idioma de la ruta. Si la versión de destino no existe, no genere un enlace que parezca válido.

• hreflang debe incluir la página actual y sus versiones correspondientes que realmente existan, y las referencias deben ser recíprocas. Los códigos de idioma y región también deben ajustarse al formato admitido por los motores de búsqueda.
• Las páginas independientes por idioma que puedan indexarse suelen utilizar un canonical autorreferente. No deben apuntar todas a la página en el idioma de origen, ya que esto enviaría señales de canonicalización contradictorias.
• Las versiones no publicadas, redirigidas, que devuelvan errores o estén configuradas como noindex no deben seguir presentándose como alternativas lingüísticas destinadas a la indexación.

Durante la validación, utilice un mismo grupo de contenido para probar cuatro situaciones: «modificación del texto de origen», «traducción no publicada», «retirada de una versión lingüística» y «cambio del slug». Compruebe si la API, la navegación de idiomas, la caché y hreflang se actualizan de forma sincronizada. Si el panel de administración muestra que las relaciones son correctas, pero en el sitio publicado siguen apareciendo direcciones no válidas, compruebe primero los eventos de publicación y la cadena de construcción del frontend, en lugar de volver a crear las relaciones de traducción.