Hreflang en PrestaShop: correspondencias de idiomas y validación
Comprueba hreflang, correspondencias recíprocas, URL regionales y x-default opcional en PrestaShop. Verifica la salida de módulos y sitemap.
Comprueba las URL de idioma que publica tu tienda antes de cambiar hreflang. Usa correspondencias de páginas precisas, un responsable claro de la salida y una validación repetible para cada grupo de idiomas participante.
Qué haríamos
Identificaríamos la causa de una alternativa incorrecta o ausente antes de elegir un módulo. La solución depende de tu tema actual, los módulos SEO, las integraciones que importan traducciones o cambian URL, las correspondencias del catálogo, los mercados y el equipo que los mantiene. Registra qué páginas deben ser equivalentes y qué componente publica actualmente esa relación.
Realiza el cambio en una copia de pruebas de esa configuración. Mantén el entorno de pruebas privado y fuera de los buscadores, ensaya las comprobaciones de correspondencias y salida y guarda los ajustes y las plantillas anteriores. Acuerda una ventana de cambio y los pasos de reversión y después comprueba las páginas públicas tras el despliegue. Las comprobaciones en pruebas validan la estructura; los hosts definitivos de producción y la indexabilidad aún deben comprobarse en las páginas reales. Nunca publiques URL del entorno de pruebas en las alternativas o los sitemaps de producción.
Si entran en conflicto el enrutamiento multilingüe, las canónicas y las correspondencias de alternativas, PrestaShop SEO Audit & Action Plan ofrece una revisión y correcciones priorizadas para tu desarrollador; la implementación va aparte.
Comprende qué hace hreflang
Hreflang identifica versiones equivalentes de una página por idioma o región. Ayuda a los buscadores a elegir una versión adecuada; no traduce contenido, fuerza el posicionamiento ni combina páginas traducidas en una única página canónica.
El contenido principal totalmente traducido no es contenido duplicado solo por estar traducido. El texto copiado en el idioma de origen y la duplicación regional en el mismo idioma necesitan su propia revisión de contenido y canónicas. Usa URL de idioma separadas y permite que las personas cambien explícitamente. Consulta las directrices de Google sobre sitios multilingües.
Hreflang se recomienda cuando necesitas expresar esa relación, pero no es obligatorio para todas las tiendas multilingües. Google puede descubrir versiones de idioma sin él. El contenido deficiente, las traducciones ausentes, las URL bloqueadas y el enrutamiento confuso son problemas independientes.
Inspecciona primero la salida nativa de PrestaShop
PrestaShop moderno crea un mapa de URL alternativas para los idiomas activos de la tienda actual. En PrestaShop 9, la clave del mapa es language_code y utiliza Link::getLanguageLink(). El tema debe representarlo realmente en la cabecera. Una plantilla parcial de cabecera sustituida puede eliminarlo o duplicarlo.
Classic y Hummingbird ofrecen integraciones de temas modernos, pero verifica las versiones instaladas. Classic siguió siendo el predeterminado en 9.0; Hummingbird pasó a serlo en 9.1. La cabecera de default-bootstrap de PrestaShop 1.6 no proporciona el mismo bloque moderno de alternativas. No supongas una salida idéntica entre estas generaciones.
El código ISO del idioma interviene en el enrutamiento de URL, mientras que language_code proporciona la clave del mapa nativo de alternativas. La configuración regional (locale) es un campo separado. Corrige los valores erróneos en su configuración real y comprueba después la salida generada; cambiar uno no garantiza que el otro sea correcto.
Las URL de tienda pertenecen a tiendas, no a idiomas individuales. Las subcarpetas pueden usar el enrutamiento multilingüe nativo. Los dominios o subdominios separados por idioma necesitan multitienda o enrutamiento personalizado adecuados. Los enlaces nativos de idioma de una sola tienda no descubren automáticamente productos equivalentes en dominios de tiendas sin relación.
En las versiones que usan estas etiquetas de menú, revisa Internacional → Localización → Idiomas para los campos de idioma y Parámetros de la tienda → Tráfico & SEO → SEO y URLs para los ajustes de URL. Establecer URL de la tienda se refiere a la dirección de la tienda. Registra el contexto de tienda y los valores actuales antes de editar; cambiar una ruta de idioma establecida también necesita un plan de redirecciones y enlaces internos.
Crea grupos de páginas recíprocos
Usa códigos de idioma válidos, opcionalmente con una región admitida: en-GB, no en-UK; cs para checo, no cz. Apunta a la página equivalente real mediante su URL completa. Cada versión participante debe identificarse a sí misma y devolver enlaces a las demás. Google puede procesar subconjuntos recíprocos; una anotación ausente en otro lugar no invalida todos los pares funcionales. Consulta las reglas de Google para versiones alternativas.
Para un grupo de producto en inglés, alemán y francés, el mismo conjunto participante debe aparecer en la cabecera de cada página:
<link rel="alternate" hreflang="en" href="https://store.example/en/product">
<link rel="alternate" hreflang="de" href="https://store.example/de/produkt">
<link rel="alternate" hreflang="fr" href="https://store.example/fr/produit">x-default es una alternativa opcional, por ejemplo un selector de idioma o una versión general elegida. Su ausencia no invalida el conjunto de idiomas. Si lo usas, mantén el destino adecuado y accesible. Consulta la explicación de x-default de Google.
<link rel="alternate" hreflang="x-default" href="https://store.example/en/product">Mantén la canónica habitual de cada versión realmente traducida en ese idioma. Resuelve las redirecciones inesperadas, noindex, errores o canónicas contradictorias antes de confiar en el grupo. Hreflang no convierte en indexable un destino no elegible.
Para tiendas regionales, asocia explícitamente las entidades equivalentes. Los ID numéricos coincidentes entre tiendas solo son seguros cuando representan el mismo artículo o contenido. Decide qué destino se responsabiliza de cada código de idioma o región si lo ofrecen varias tiendas. Nunca asocies un producto sin traducir a una página de inicio solo para rellenar un hueco.
Las etiquetas de cabecera HTML y las anotaciones en sitemaps XML pueden expresar estas relaciones. Si usas ambas, mantén coherentes sus correspondencias. Una entrada de sitemap debe incluir la URL actual y las referencias alternativas pertinentes con los espacios de nombres XML requeridos; inspecciona todas las entradas participantes en lugar de añadir solo un enlace extranjero unidireccional.
Ejemplo de un error de correspondencia regional
Tus tiendas de Reino Unido y Estados Unidos venden la misma lámpara en inglés, pero las importaciones del catálogo crearon registros de producto distintos. Una correspondencia basada en ID numéricos coincidentes enlaza la lámpara británica con una pantalla de lámpara estadounidense. Los códigos en-GB y en-US pueden ser válidos aunque la relación sea incorrecta.
Confirma el equivalente mediante una referencia estable del catálogo y el contenido real del producto, corrige la correspondencia e inspecciona después ambos destinos y sus enlaces de retorno. Si la lámpara estadounidense no está publicada, retira su entrada alternativa de las páginas participantes y de las anotaciones de sitemap activadas hasta que esté lista. Añade este caso a las comprobaciones posteriores a las importaciones del catálogo: un rastreador puede señalar relaciones rotas sin reconocer que dos páginas válidas venden artículos distintos.
Elige una implementación y deja la configuración en la ayuda del módulo
| Qué encuentras | Opción inicial | Pruebas antes del cambio |
|---|---|---|
| La salida nativa cubre las URL de idioma de tu tienda. | Consérvala y mantén la configuración de idiomas. | Las páginas equivalentes representativas tienen conjuntos utilizables y recíprocos. |
| Un tema personalizado ha eliminado el bloque de alternativas. | Restaura su representación del mapa nativo si ese mapa cubre tus necesidades. | La cabecera reparada contiene el conjunto previsto sin salida duplicada. |
| Necesitas correspondencias entre tiendas, exclusiones o excepciones por página. | Evalúa una implementación adicional según esos requisitos. | La versión instalada admite tus entidades y destinos, incluidos los enlaces de retorno. |
| Distintos generadores publican conjuntos contradictorios. | Elige el responsable de la salida y desactiva la salida competidora mediante sus controles compatibles. | Las respuestas públicas en caché y las anotaciones de sitemap activadas coinciden. |
Elige un único responsable del conjunto de alternativas de cada página y comprueba su integración con la salida real del tema.
Para las conexiones automáticas multitienda, los grupos manuales Local/Shared, las filas de origen y destino, las exclusiones, las vistas previas de borradores, la responsabilidad de la salida y los requisitos de licencia, sigue la página de ayuda de Hreflang Tags Manager.
Para los ajustes de hreflang, los patrones de URL, las vistas previas, las redirecciones del historial de URL y los sitemaps de idiomas generados, sigue la página de ayuda de SEO Revolution.
Hreflang Tags Manager cubre páginas de entidades admitidas y omite sus conjuntos generados en búsquedas, resultados filtrados y páginas de listado posteriores a la primera. En respuestas correctas, las páginas de cuenta, compra y módulos conservan las alternativas que proporcionen sus propios controladores y el tema. Las asignaciones manuales tienen prioridad sobre las conexiones automáticas. Los destinos de URL personalizados y las correspondencias dinámicas siguen necesitando comprobaciones de enlaces de retorno. La gestión de canónicas sigue siendo una cuestión independiente.
Cuando SEO Revolution se encarga de la salida hreflang, el gestor independiente no emite nada. La suite necesita al menos dos alternativas elegibles, incluida la página actual; su salida x-default depende de que la URL predeterminada seleccionada siga siendo elegible. Su código da prioridad a language_code y puede recurrir a la configuración regional. Las funciones de cabecera y sitemap tienen sus propios controles y comprobaciones de elegibilidad. Repite las comprobaciones de salida tras cambiar el tema, porque las etiquetas generadas por el módulo siguen dependiendo de la integración del tema.
Valida las páginas reales después de los cambios
- Elige un producto real con traducciones completas. Obtén la respuesta HTML o usa Ver código fuente e inspecciona después los enlaces alternativos de la cabecera. Comprueba qué componente los proporciona.
- Abre cada destino. Confirma la URL final, el idioma visible, el estado de respuesta, la directiva robots y la canónica. Comprueba el código real de idioma o región frente al público previsto.
- Compara los conjuntos. Verifica las autorreferencias y enlaces de retorno de las páginas participantes. Trata x-default como opcional y valida su destino cuando exista.
- Repite en inicio, categorías, CMS, marcas y proveedores donde participen. Los tipos de página que un módulo no admita deliberadamente no requieren correspondencias inventadas.
- Inspecciona el XML generado si están activadas las anotaciones del sitemap. Compara sus URL con las etiquetas de cabecera y los destinos del selector de idioma.
- Usa un rastreador sobre el inventario de URL previsto para encontrar códigos no válidos, redirecciones, pares unidireccionales, salida duplicada y destinos no elegibles. Registra las excepciones en lugar de suponer que todas las páginas deben participar.
- Repite tras cambiar dominios, ajustes de idioma, slugs, plantillas de cabecera del tema, responsabilidad del SEO o generación de sitemaps.
Las anotaciones ausentes o inutilizables pueden ignorarse o no llegar a establecer una relación. Comprueba qué correspondencias están afectadas y corrige las anotaciones inutilizables.
Si un destino antiguo persiste tras una corrección, compara una respuesta actualizada con el HTML en caché e identifica la capa de caché antes de editar más correspondencias. Vaciar la caché del navegador no elimina el HTML del servidor o la CDN. Si faltan etiquetas, compara el mismo tipo de página en el tema instalado y su sobrescritura de cabecera antes de suponer que faltan los datos de idioma.
Para preparar el contenido y las monedas que hay detrás de estas URL, usa la guía de traducciones y venta internacional.
Planifica el cambio y la entrega
- Guarda el HTML y los ajustes de correspondencias de antes y después para las páginas de prueba acordadas, incluida una exclusión intencionada. Ten preparada la configuración de salida anterior para restaurarla.
- Despliega juntos los ajustes aprobados y los cambios de plantillas, actualiza las cachés afectadas y regenera los sitemaps activados. Repite la validación anterior en las URL públicas antes de dar el visto bueno.
- Entrega a quien mantiene la tienda el responsable de la salida, las reglas de correspondencia, las exclusiones, las URL de prueba y las instrucciones de reversión. Repite las comprobaciones pertinentes cuando esa persona cambie un idioma o importe datos del catálogo.
Qué preguntar a tu desarrollador o agencia
- ¿Cómo se asocian los registros equivalentes entre tiendas y qué ocurre cuando se retira una traducción o una importación sustituye un registro?
- ¿Qué sobrescritura del tema o módulo controla la cabecera y qué ajustes controlan las anotaciones de sitemap?
- ¿Quién comprueba los nuevos cambios de idioma y dominio y qué pruebas harán que se revierta el cambio?
Preguntas de los propietarios
¿Necesito pasar a dominios separados para corregir hreflang?
No. Una configuración funcional con subcarpetas puede expresar alternativas de idioma. Elige los dominios según tu mercado y la arquitectura de la tienda; trasladar URL establecidas añade un trabajo de migración que puede no ser necesario para corregir una etiqueta.
¿Puede hreflang sustituir al selector de idioma o redirigir a los visitantes?
No. Conserva un selector usable que enlace a la página equivalente. Las redirecciones automáticas por idioma o ubicación necesitan una revisión independiente: pueden impedir que los visitantes y rastreadores lleguen a la URL solicitada.
¿Cuánto tardará Google en mostrar la versión corregida?
No hay un plazo fijo. Conserva el HTML corregido y los resultados del rastreo como pruebas técnicas; los resultados de búsqueda dependen de un nuevo rastreo y de la selección de Google. Que el posicionamiento no cambie no indica por sí solo si una anotación es válida.