Hreflang es el protocolo que decide si tu trabajo de traducción produce visibilidad o no. Un hreflang correctamente implementado en un sitio multilingüe rutea a cada usuario a la página correcta en el idioma correcto para su región. Un setup roto de hreflang mina el mismo trabajo de traducción — las páginas existen pero salen las equivocadas, las alternantes compiten entre sí en el índice, y la inversión en SEO internacional nunca paga de regreso. Este capítulo cubre la implementación, la auditoría, y los modos de falla que silenciosamente topen a la mayoría de los sitios multilingües.

“Hreflang es la pieza más barata del stack de SEO internacional y la más consecuente cuando se rompe. Una auditoría de dos horas atrapa lo que un año de traducción no puede arreglar por sí solo — el protocolo que le dice 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 set completo de alternantes idioma-y-región y cuál es esta página. La señal vive en tres lugares válidos:

• Head HTML, link rel="alternate". La implementación más común. Cada página lista cada alternante en tags <link rel="alternate" hreflang="..." href="..." />.
• Headers HTTP. Para recursos no-HTML (PDFs, imágenes), hreflang vive en el header de respuesta Link:.
• XML sitemap. Una entrada xhtml:link separada por alternante dentro de cada bloque de URL. Útil para sitios muy grandes donde la inyección al head se vuelve pesada de mantener.

Los tres son leídos por Google. Escoge uno y mantente con él; mezclarlos invita inconsistencias. Para la mayoría de los sitios el head HTML es la decisión correcta — el mismo motor que renderea la página renderea el hreflang.

El formato

Los valores de hreflang usan ISO 639-1 (idioma) más ISO 3166-1 alpha-2 opcional (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 a servir cuando ninguna otra alternante matchea el locale del usuario. Crítico para sitios globales; cubierto abajo.

El código de región es mayúsculas por convención pero case-insensitive para Google. El código de idioma debe ser minúsculas por la spec; algunas implementaciones lo capitalizan y Google aún acepta.

El requerimiento de simetría

Cada página en el set de alternantes debe referenciar a cada otra alternante — incluyéndose a sí 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 set mínimo completo de hreflang en un sitio de 3 locales (EN, es-MX, en-AU):

• Auto-referencia: <link rel="alternate" hreflang="en" href="https://example.com/page" />
• Sibling 1: <link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/page" />
• Sibling 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 locale deben incluir las cuatro entradas. La auto-referencia es obligatoria; perderla no siempre rompe el rendering de Google pero consistentemente crea ambigüedad de parseo.

Hreflang y canonical — la interacción

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

• Cada versión de idioma se auto-canonicaliza. El canonical de la página es-MX apunta a la URL es-MX, no a la URL EN. El hreflang declara que las alternantes EN/AU/etc existen; el canonical confirma que la página es la canónica para su locale.
• Error común: establecer el canonical a la versión EN en cada locale. Esto colapsa todas las alternantes en un solo canonical y deshace el hreflang. No lo hagas.
• Consistencia de trailing slash. Canonical, hreflang, y la URL real deben coincidir en trailing-slash. El mismatch es una supresión silenciosa.
• Consistencia de protocolo. Las URLs de canonical y hreflang deben usar https://, el mismo dominio, y la misma capitalización que la URL real.

Patrones de implementación

• Patrón de 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 compara esto contra subdominios y ccTLDs.
• Patrón de subdominio. us.example.com, mx.example.com, au.example.com. Hreflang funciona igual; trata cada subdominio como un origen distinto en el set de alternantes.
• Patrón de ccTLD. example.com, example.mx, example.com.au. Cada dominio es tratado separadamente por Google; hreflang ata las alternantes a través de los tres dominios.

El playbook de auditoría

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

• Revisión de cobertura. Para cada página, ¿existe el bloque de hreflang? Muchas migraciones de CMS sueltan el hreflang en subset de páginas.
• Revisión de simetría. Para cada alternante referenciada, ¿esa página alternante también referencía de regreso? Usa un crawler (Sitebulb, Screaming Frog) para validar el enlace bidireccional.
• Revisión de auto-referencia. ¿Cada página se incluye a sí misma en su set de hreflang?
• Compatibilidad de canonical. ¿El canonical apunta al mismo locale que la página en la que está, no a la versión EN?
• Validez de x-default. ¿La URL de x-default existe, regresa 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í.)
• Revisión de status HTTP. ¿Todas las URLs alternantes regresan 200, no 301/302/404?
• Consistencia de HTTPS. Todas las URLs de hreflang en el mismo protocolo que la página misma.

Lo que hreflang no hace

• No es señal de ranking. Hreflang no hace que una página rankee más alto — solo rutea la página correcta al usuario correcto. La página aún tiene que estar optimizada para rankear contra los competidores locales.
• No traduce contenido. La traducción es una disciplina separada; 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 sobrepasa el geotargeting. Hreflang más targeting internacional de Search Console más localización on-page más perfil de enlaces todos se apilan — hreflang solo es necesario pero no suficiente.
• No ayuda con pricing regional. Moneda, métodos de pago, productos específicos por región se manejan en la capa de aplicación, no vía hreflang.

Los modos de falla

• Contenido traducido sin hreflang. Google trata las alternantes como contenido duplicado y puede escoger una para canonicalizar, dejando caer las otras.
• Hreflang asimétrico. A dice que B es su alternante en español; B no reciprocidad. Google deja caer la relación de B.
• x-default faltante o roto. Los usuarios de locales no matcheados ven la página equivocada o una rota.
• Canonical apuntando a EN en cada locale. Colapsa todas las alternantes en un canonical; hreflang se ignora.
• Mismatch de trailing slash. La URL de hreflang no matchea exactamente la URL servida; Google no puede matchear la alternante.
• Hreflang desactualizado después de cambios de URL. Una página se mueve; el hreflang en sus alternantes aún apunta a la URL vieja. Común después de rebrands o migraciones de CMS.

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