Cuando las etiquetas canónicas apuntan a través de idiomas, Hreflang se rompe

Una página puede llevar 2 etiquetas en el mismo <head> que se dirigen al mismo rastreador sobre la misma URL y dicen cosas opuestas. En https://example.com/fr/pricing, esto indica que la página es el miembro francés de un clúster:

<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />

Y esto, la línea 1 debajo de ella, indica que la página es una variante que debe integrarse en el original en inglés:

<link rel="canonical" href="https://example.com/pricing" />

Los sitios reales envían ambos, desde la misma plantilla, en cada ruta localizada que poseen. Esta es la falla que permanece después de la que documentamos en julio — la referencia propia hreflang faltante, aún falla el 58 % de 88 evaluaciones hreflang en nuestros datos actuales. Un sitio puede cerrar ese bucle, obtener cada referencia propia correcta, y aún así hacer que cada página localizada solicite ser reemplazada por su gemelo en inglés.

Un canonical multilingüe pide a Google que integre la localizada URL en el original

Una etiqueta canonical es una solicitud de consolidación: trata esta URL como una variante de esa, e indexa esa. Una anotación hreflang es una reclamación de enrutamiento: esta URL es la versión para este idioma. Apúyalas a URLs diferentes y el sitio ha emitido una solicitud que anula su propia reclamación — el espacio francés en el clúster es ocupado por una página que se desmarca a sí misma.

Google ha sido explícito de que hreflang es una pista más que una directiva, y la canonización funciona de la misma manera: el sitio suministra señales, Google las resuelve. Esa resolución es todo el problema. Con una página localizada con canonical propio, el editor decide qué URL sirve a los buscadores franceses. Con un canonical multilingüe, el editor ha delegado la decisión mientras cree que el clúster está configurado — y el resultado que se reporta más tarde es una página localizada que no se posiciona en su propio mercado mientras la página en inglés aparece en su lugar.

Los generadores que producen esto son ordinarios. Un asistente canonical construido a partir de una definición de ruta en lugar de la ruta de la solicitud emite el URL sin prefijo para cada locale. Un CMS cuya configuración hreflang es por locale pero cuya configuración canonical es global hace lo mismo. Entonces, una migración que añadió prefijos de localización a las URLs y dejó el canónico apuntando a donde el contenido originalmente vivía. En cada caso la página se muestra perfectamente, las anotaciones parecen completas en view-source, y la contradicción es 2 atributos aparte.

El conjunto de datos

Metodología: instantánea de auditoría completada más reciente por dominio de nuestro conjunto de comprobaciones actual, aproximadamente mayo 23 – August 31, 2026, anonimizado. Los denominadores difieren por comprobación — 34 a 49 sitios — porque una comprobación solo se ejecuta cuando sus entradas existen: la comprobación de referencia propia no produce veredicto en una página de inicio sin anotaciones hreflang en absoluto, lo que explica por qué su recuento de sitios es el menor. Las tasas a nivel de evaluación y a nivel de sitio difieren porque algunos dominios fueron auditados más de una vez en la ventana. La muestra es auto-seleccionada — propietarios que realizaron una auditoría — y sesga a tamaño pequeño-mediano, por lo que trate las tasas como direccionales para ese segmento.

La segunda fila es el riesgo más silencioso. Una página sin canónico no ha contradicho su anotación hreflang, pero tampoco la ha defendido: nada en la página indica cuál URL considera autoritativo, por lo que una variante de localización accesible en más de 1 dirección se resuelve completamente por inferencia. Llegar a un clúster correcto pasa primero por la higiene canónica, por eso nuestro guía canónica es el prerequisito para la guía de implementación de hreflang, no un complemento de ella.

La contradicción solo es visible desde ambos extremos del clúster

Una sola página no puede reportar este fallo sobre sí misma. /fr/pricing parece internamente consistente — un conjunto hreflang, un canónico, ambos bien formados. El defecto aparece cuando se sostiene la anotación y la página anotada lado a lado, por eso verificarlo exige obtener el clúster completo en lugar de leer 1 documento.

Siga cada anotación hreflang hasta su destino y anote lo que devuelve: el código de estado, si la solicitud redirigió, si hay una directiva noindex y si el canónico del propio destino nombra la URL a la que apuntaba la anotación. Un destino cuyo canónico nombra otra URL es el canónico entre idiomas del que trata este artículo.

El atributo lang es un segundo testigo. Una página cuyo html lang indica un idioma distinto del locale que reclama su propia entrada hreflang se contradice de la misma manera, y suele ser la primera señal visible de que una ruta localizada sirve el contenido del original.

Una alternativa que no se puede obtener es una laguna en la evidencia, no la prueba de un defecto. Regístrela como no verificada y vuelva a intentarlo antes de dar el clúster por roto.

graph TD
    FR["/fr/pricing — html lang=fr"]
    EN["/pricing — original en inglés"]
    FR -->|"hreflang=fr, self-referencing"| CLAIM["Reclamo: servir este URL a buscadores franceses"]
    FR -->|"rel=canonical"| EN
    EN -->|"hreflang=fr"| FR
    CLAIM --> Q{"¿Qué URL responde a una consulta francesa?"}
    EN --> Q
    Q -->|"el sitio dejó de decidir"| OUT["Google selecciona — usualmente el URL en inglés"]

Nuestros propios prefijos de locale sirvieron inglés hasta August 17, 2026

Nosotros mismos fallamos en esta clase de defecto en seoreport.dev. Ahrefs Site Audit reportó un hreflang y una discrepancia de HTML lang en 184 URLs en nuestro propio sitio. El atributo lang era el síntoma; el contenido también estaba en inglés, en cada uno de los 9 prefijos de locale, lo que hizo que cada URL localizado fuera un duplicado de su gemelo inglés — el mismo resultado que produce un canónico cruzado de idioma, alcanzado desde la otra dirección.

La causa fue la frontera de función 1. El shell del documento tomó su idioma de un ayudante que devuelve el idioma predeterminado siempre que window esté indefinido. En el servidor, /fr/pricing por lo tanto renderizó lang="en" y sembró el paquete de traducción al inglés, mientras que el componente que emite los enlaces de head — que lee la ruta, no el tiempo de ejecución — emitió un fr self-hreflang correcto directamente al lado. Un efecto del cliente cambió el idioma después de la hidratación, por lo que cada comprobación basada en navegador pasó y ningún humano lo vio. Los rastreadores no ejecutan ese efecto.

Corregido en August 17, 2026: el shell deriva su idioma de la ruta, el diseño localizado resuelve el paquete de locale en un cargador para que el renderizado del servidor y la hidratación lo compartan, y un locale soportado sin paquete lanza una excepción en lugar de servir silenciosamente inglés bajo su prefijo. La dirección del texto también estaba incorrecta — el árabe había estado sirviendo ltr.

La prueba de regresión es una ejecución sobre el HTML sin procesar y sin JavaScript, porque una comprobación en el navegador no puede ver esta clase de fallo. Ejecutar red-primer contra producción reportó 440 fallos en 128 URLs localizadas, cada página en 100% inglés con traslado. Contra la compilación fija: 0 fallos en 144 URLs. Una comparación de lang frente a hreflang habría hecho fallar primero a nuestro propio sitio.

x-default hereda lo que declare la página de reserva

Nuestra muestra de sitios que declaran x-default es demasiado pequeña para publicar una tasa de fallo. Además, el HTML demuestra menos de lo que parece: muestra que se declara una anotación x-default, no a qué público pretendía dirigirla el editor. Los hechos comprobables son los vecinos: la forma de la URL, el estado del destino, las anotaciones recíprocas y la alineación del canónico.

Lo que implica el mecanismo vale la pena declararlo de todos modos. x-default es la reserva para buscadores cuyo idioma el sitio no sirve, por lo que normalmente apunta a la página del mercado principal. Si esa página lleva un canónico cruzado de idioma, la reserva para cada buscador no coincidente en el planeta hereda la contradicción, y la contradicción aparece en el estado del destino, no en la propia línea x-default.

Verifícalo en HTML crudo, por localidad, en ambas direcciones

Obtén la página como lo hace un rastreador y lee 3 cosas:

curl -s -A "Googlebot" https://example.com/fr/pricing | grep -iE '<html|rel="canonical"|hreflang'

El atributo lang, la entrada hreflang auto-referencial, y el canónico deben concordar en 1 localidad y 1 URL:

<!-- On https://example.com/fr/pricing -->
<html lang="fr">
<link rel="canonical" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="en" href="https://example.com/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

Luego repite en 1 página por localidad, y obtén cada URL que el nombre de la anotación confirma que cada uno canoniciza a sí mismo. La regla es lo suficientemente corta como para entregarla a un desarrollador: cada miembro de un clúster hreflang canoniciza a sí mismo. Un canónico cruzado de idioma es correcto en exactamente 1 situación — cuando el URL localizado no está localizado en absoluto y sirve el mismo idioma que el original — y en esa situación el URL no pertenece al clúster tampoco.

La Inspección URL de Search Console da la segunda opinión autorizada sobre qué canónico Google realmente se seleccionó, por URL. Un diagnóstico de pago de SEOReport recorre el clúster completo y enumera cada par contradictorio junto con la página donde se encontró. Los prefijos de localidad 9 en seoreport.dev pasan ahora, y pasan porque enviamos el defecto primero, en un sitio cuyo producto entero lo está encontrando.