Hreflang y targeting de idioma

Hreflang es el protocolo que decide si tu trabajo de traducción rinde en visibilidad o no. Un hreflang bien implementado en un sitio multilingüe lleva a cada usuario a la página correcta, en el idioma correcto, para su región. Una configuración rota de hreflang erosiona ese mismo trabajo de traducción: las páginas existen, pero aparecen las equivocadas, las alternas compiten entre sí en el índice y la inversión en SEO internacional nunca rinde. Este capítulo cubre la implementación, la auditoría y los modos de falla que en silencio le ponen techo a la mayoría de los sitios multilingües.

“Hreflang es la pieza más barata del stack de SEO internacional y la que más pesa cuando se rompe. Una auditoría de dos horas resuelve lo que un año de traducción no puede arreglar por sí solo: el protocolo que le indica a los buscadores qué versión es para quién.”

Cómo funcionan las señales de hreflang

Hreflang declara, en cada página, el conjunto completo de alternas idioma-región e indica cuál de ellas es esta página. La señal está en tres lugares válidos:

• HTML head, link rel="alternate". La implementación más común. Cada página lista a cada alterna mediante etiquetas <link rel="alternate" hreflang="..." href="..." />.
• Encabezados HTTP. Para recursos que no son HTML (PDFs, imágenes), hreflang viaja en el encabezado de respuesta Link:.
• XML sitemap. Una entrada xhtml:link por alterna dentro de cada bloque de URL. Útil en sitios muy grandes donde inyectar al head se vuelve pesado de mantener.

Google lee los tres. Elige uno y mantente con él; mezclarlos abre la puerta a inconsistencias. Para la mayoría de los sitios el head HTML es la opción correcta: el mismo motor que renderiza la página renderiza el hreflang.

El formato

Los valores de hreflang usan ISO 639-1 (idioma) más, de forma opcional, ISO 3166-1 alpha-2 (región):

• hreflang="en" — inglés (cualquier región).
• hreflang="en-US" — inglés, Estados Unidos.
• hreflang="en-GB" — inglés, Reino Unido.
• hreflang="es-MX" — español, México.
• hreflang="es-ES" — español, España.
• hreflang="x-default" — la página que se muestra cuando ninguna otra alterna coincide con el locale del usuario. Crítico en sitios globales; lo vemos más abajo.

El código de región va en mayúsculas por convención, aunque Google no distingue mayúsculas y minúsculas. El código de idioma debe ir en minúsculas según la especificación; algunas implementaciones lo capitalizan y Google las sigue aceptando.

El requisito de simetría

Cada página del conjunto de alternas debe referenciar a todas las demás — incluida ella misma. Si la página A dice “la versión en español está en B” pero la página B no dice “la versión en inglés está en A”, la relación está rota desde el lado de B. La verificación de Google falla y el hreflang se cae de las páginas afectadas.

El conjunto mínimo completo de hreflang en un sitio de 3 locales (EN, es-MX, en-AU):

• Autorreferencia: <link rel="alternate" hreflang="en" href="https://example.com/page" />
• Hermana 1: <link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/page" />
• Hermana 2: <link rel="alternate" hreflang="en-AU" href="https://example.com/en-au/page" />
• Default: <link rel="alternate" hreflang="x-default" href="https://example.com/page" />

Las tres páginas de cada locale deben incluir las cuatro entradas. La autorreferencia es obligatoria; omitirla no siempre rompe el renderizado de Google, pero consistentemente genera ambigüedad al momento de analizar.

Hreflang y canonical — la interacción

Hreflang declara alternas; canonical declara la versión preferida cuando hay duplicados. Los dos interactúan:

• Cada versión de idioma se autocanonicaliza. El canonical de la página es-MX apunta a la URL es-MX, no a la URL EN. El hreflang declara que existen las alternas EN/AU/etc.; el canonical confirma que la página es la canónica para su locale.
• Error común: poner el canonical hacia la versión EN en todos los locales. Eso colapsa todas las alternas en un solo canonical y anula el hreflang. No lo hagas.
• Consistencia del trailing slash. Canonical, hreflang y la URL real deben coincidir en el trailing slash. El desajuste es una supresión silenciosa.
• Consistencia de protocolo. Las URL del canonical y del hreflang deben usar https://, el mismo dominio y la misma capitalización que la URL real.

Patrones de implementación

• Subdirectorio. example.com (en), example.com/es-mx (español México), example.com/en-au (Australia). Hreflang es directo: mismo dominio, distintos subdirectorios. El capítulo sobre arquitectura de URL internacional lo compara contra subdominios y ccTLDs.
• Subdominio. us.example.com, mx.example.com, au.example.com. Hreflang funciona igual; trata a cada subdominio como un origen distinto dentro del conjunto de alternas.
• ccTLD. example.com, example.mx, example.com.au. Google trata a cada dominio por separado; hreflang amarra las alternas entre los tres dominios.

El manual de auditoría

La mayoría de los sitios multilingües tienen hreflang roto en al menos algunas páginas. La auditoría detecta los patrones que no saltan a la vista en Search Console:

• Cobertura. En cada página, ¿existe el bloque de hreflang? Muchas migraciones de CMS dejan caer el hreflang en una parte de las páginas.
• Simetría. Por cada alterna referenciada, ¿esa página alterna también referencia de vuelta? Usa un rastreador (Sitebulb, Screaming Frog) para validar el enlace bidireccional.
• Autorreferencia. ¿Cada página se incluye a sí misma en su conjunto de hreflang?
• Compatibilidad de canonical. ¿El canonical apunta al mismo locale de la página en la que vive, y no a la versión EN?
• Validez del x-default. ¿La URL de x-default existe, devuelve 200 y no redirige?
• Validez de código. ¿Los códigos de idioma-región son códigos ISO válidos? (en-uk está mal; en-GB está bien. es-LA no es válido; es-MX o es-ES sí lo son).
• Estado HTTP. ¿Todas las URL alternas devuelven 200, y no 301/302/404?
• Consistencia de HTTPS. Todas las URL de hreflang deben estar en el mismo protocolo que la página.

Lo que hreflang no hace

• No es una señal de ranking. Hreflang no hace que una página posicione más alto: solo lleva la página correcta al usuario correcto. La página todavía tiene que estar optimizada para competir contra los rivales locales.
• No traduce contenido. La traducción es una disciplina aparte; hreflang solo declara qué versión existe para qué audiencia. El capítulo sobre traducción vs. localización cubre la estrategia de contenido.
• No sustituye a la segmentación geográfica. Hreflang, la segmentación internacional de Search Console, la localización on-page y el perfil de enlaces se suman: hreflang por sí solo es necesario, pero no suficiente.
• No resuelve los precios por región. Moneda, métodos de pago y productos específicos por región se resuelven en la capa de aplicación, no a través de hreflang.

Los modos de falla

• Contenido traducido sin hreflang. Google trata a las alternas como contenido duplicado y puede elegir una para canonicalizar, dejando fuera al resto.
• Hreflang asimétrico. A dice que B es su alterna en español; B no responde de vuelta. Google da por rota la relación desde B.
• x-default faltante o roto. Los usuarios de locales no contemplados ven la página equivocada o una rota.
• Canonical apuntando a EN en todos los locales. Colapsa todas las alternas en un solo canonical; el hreflang queda ignorado.
• Desajuste del trailing slash. La URL del hreflang no coincide con exactitud con la URL servida; Google no puede hacer match con la alterna.
• Hreflang desactualizado tras cambios de URL. Una página se mueve; el hreflang de sus alternas sigue apuntando a la URL vieja. Común después de rebrands o migraciones de CMS.

Hreflang es el cimiento. El siguiente capítulo, arquitectura de URL internacional, cubre la decisión estructural — subdirectorios, subdominios o ccTLDs — que hreflang amarra.