Tenés una página en español y otra en inglés. Ambas funcionan y el selector de idiomas parece correcto, pero Google muestra a veces una versión que no corresponde al público que querés atender. Antes de sumar etiquetas, necesitás comprobar qué páginas son equivalentes y si sus señales permiten que cada versión participe en la búsqueda.
Hreflang declara relaciones entre variantes de una página por idioma o región. No traduce el contenido, no garantiza que Google elija siempre una URL determinada y no reemplaza la indexabilidad. Vamos a implementarlo en un caso pequeño y a convertirlo en un procedimiento que puedas repetir por plantilla.
Empezá por una familia de páginas
Imaginemos una empresa que vende una misma sesión de asesoramiento en español y en inglés. Cada versión explica alcance, duración y contratación en su idioma. Si ambas satisfacen la misma necesidad, pueden formar una familia de variantes. La página de asesoramiento en español no debería declarar como alternativa la home inglesa solo porque todavía falta traducir el servicio.
Prepará un mapa de equivalencias antes de tocar el código. Cada fila representa una necesidad o contenido, no una carpeta del sitio. Cuando una traducción no existe, dejá ese dato visible para el equipo y excluí la alternativa inexistente de las etiquetas publicadas.
| Contenido | Español | Inglés | Decisión |
|---|---|---|---|
| Asesoramiento | /es/asesoramiento/ | /en/advisory/ | Dos variantes equivalentes. |
| Taller presencial | /es/taller/ | No existe | No inventar una versión inglesa. |
| Contacto | /es/contacto/ | /en/contact/ | Familia independiente de la del servicio. |
Si las URLs cambian según el idioma, registrá las direcciones finales completas. No deduzcas una traducción sustituyendo “es” por “en” en toda la web: los slugs, las páginas publicadas y las relaciones editoriales pueden ser diferentes. Ese atajo genera alternativas que responden con error o llevan a otro contenido.
Elegí idioma y región según la oferta real
Usá un código de idioma y, cuando tenga sentido, una región compatible. Por ejemplo, es identifica español; es-AR, una variante de español orientada a Argentina; en-GB, inglés para Reino Unido. Una región sola no identifica el idioma, y escribir “UK” o “LATAM” como si fueran las regiones admitidas del código produce una señal incorrecta.
No necesitás una variante regional por cada país al que podrías vender. Si el contenido, las condiciones y la atención son los mismos para distintos hablantes de español, una versión general puede ser suficiente. Crear carpetas vacías de diferencias comerciales agrega mantenimiento sin resolver una necesidad del comprador.
Cuando existan diferencias de moneda, disponibilidad, contratación o entrega, documentalas junto al mapa. Hreflang debe representar versiones que el negocio puede sostener. Una URL que dice atender otro mercado pero no permite comprar con sus condiciones deja un problema de experiencia aunque el código esté bien escrito.
El valor x-default permite señalar una alternativa para los casos no cubiertos por las otras variantes. Puede ser un selector de idioma o una versión general adecuada. Elegilo por familia de contenido: enviar cualquier servicio al selector de la home puede interrumpir una búsqueda específica.
Implementación mínima en el encabezado HTML
En el ejemplo vamos a usar etiquetas HTML en el head. También existen métodos mediante encabezados HTTP y sitemap; no hay una ventaja por repetir la misma declaración en los tres. Elegí una fuente de mantenimiento y evitá que dos sistemas generen conjuntos contradictorios.
Estas dos etiquetas deben aparecer en cada una de las dos páginas del servicio, incluida la referencia a la propia URL. Son direcciones ficticias para mostrar la estructura:
<link rel="alternate" hreflang="es"
href="https://example.com/es/asesoramiento/">
<link rel="alternate" hreflang="en"
href="https://example.com/en/advisory/">
En la versión española, el canonical de este caso apunta a la española. En la inglesa, a la inglesa. Las etiquetas hreflang relacionan las variantes; el canonical expresa una preferencia de consolidación. Si todas las traducciones apuntan canónicamente a una única versión española, estarías dando una señal que puede competir con tu intención de mantenerlas como páginas diferenciadas.
<!-- Canonical de la página inglesa del ejemplo -->
<link rel="canonical"
href="https://example.com/en/advisory/">
Este patrón supone traducciones con contenido principal propio. Las variantes regionales casi idénticas en el mismo idioma requieren evaluar también la consolidación; no conviertas la autorreferencia en una regla ciega para cualquier duplicado. La guía de canibalización SEO ayuda a separar páginas que cumplen funciones distintas de páginas que compiten por la misma intención.
En WordPress, corregí la relación antes de editar la salida
Si usás una solución multilingüe, verificá que las dos entradas estén vinculadas como traducciones del mismo contenido. Revisá idioma asignado, estado de publicación, URL final y versión elegida en el selector. Un artículo duplicado manualmente no siempre queda registrado como traducción aunque su título esté en otro idioma.
Comprobá qué componente genera hreflang: plugin multilingüe, tema, integración SEO o código propio. Conservá un responsable de la salida. Si aparece un conjunto correcto y otro que apunta a la home, agregar un tercero no soluciona el conflicto.
Probá el resultado público después de limpiar la caché correspondiente. El editor puede mostrar datos actualizados mientras el HTML servido al visitante todavía contiene relaciones anteriores. Revisá además que las páginas privadas, borradores o traducciones retiradas no sigan dentro de la familia publicada.
Seis comprobaciones para una familia
- Abrí ambas URLs directamente. Deben mostrar el contenido esperado sin depender de haber pasado por un selector o de una sesión previa. Registrá si hay redirecciones y usá los destinos finales en las declaraciones.
- Revisá el código fuente recibido. Buscá cada
hreflangy comprobá que las etiquetas estén en el encabezado, con direcciones absolutas y códigos válidos. - Comprobá reciprocidad. La española declara la inglesa y la inglesa devuelve la relación. Las dos incluyen su propia versión dentro del conjunto.
- Revisá la posibilidad de indexación. Confirmá respuesta correcta, ausencia de instrucciones de exclusión incompatibles y canonical coherente con el modelo elegido.
- Verificá equivalencia humana. Compará contenido, alcance y disponibilidad. La misma etiqueta de idioma en la plantilla no convierte una página distinta en alternativa.
- Repetí desde otro recorrido. Abrí enlaces internos, selector y acceso directo. La versión no debe depender exclusivamente de una redirección forzada por ubicación o idioma del navegador.
Guardá la evidencia por URL: fecha, códigos declarados, destinos, reciprocidad y hallazgos. Si trabajás con cientos de páginas, usá un rastreador que extraiga las anotaciones y agrupá errores por patrón. La comprobación manual de una sola página no valida toda la instalación.
Qué cambiar cuando una prueba falla
La versión inglesa declara otra URL diferente
Volvé al mapa y a la relación de traducción en el CMS. Puede haber una entrada antigua todavía vinculada. Corregí el dato de origen y comprobá todas las páginas de esa familia. Editar solamente una etiqueta de la plantilla puede dejar la relación inversa equivocada.
La alternativa redirige
Actualizá la declaración hacia la dirección final pertinente. Investigá si la redirección aparece por una barra, un slug cambiado o una regla de idioma. Después revisá enlaces internos y sitemap para que no sigan enviando a versiones intermedias.
El conjunto apunta siempre a las homes
La generación está relacionando idiomas del sitio en lugar de contenidos equivalentes. Necesitás una búsqueda de traducciones de la página actual. Cuando no haya equivalente, omití esa alternativa. No uses la home como reemplazo automático de cualquier traducción pendiente.
La etiqueta existe, pero el contenido solo aparece después de ejecutar scripts
Revisá qué recibe Google y si puede acceder al contenido principal. Una familia técnicamente declarada puede contener páginas difíciles de procesar. La guía para auditar el renderizado de JavaScript permite comprobar esa capa sin atribuirle todo a hreflang.
Pasá de la muestra al sitio completo
Elegí una muestra que cubra home, servicios, productos y artículos, más una página sin traducción. Sumá un caso retirado o con slug modificado. Esos bordes suelen revelar reglas que la página principal no muestra.
Después ampliá la comprobación al inventario de URLs. Buscá alternativas inexistentes, códigos duplicados con destinos diferentes, falta de retorno y destinos fuera de la familia. Separá el error editorial, que requiere elegir una equivalencia, del error de generación, que afecta a una plantilla completa.
Definí además qué ocurre cuando se publica una traducción, se retira un producto o cambia una URL. La relación debe actualizarse en todas las variantes afectadas. Asignar esa responsabilidad evita que una implementación correcta se deteriore con el siguiente cambio de contenido.
Qué observar después de publicar
Revisá una muestra con Inspección de URLs en Search Console y contrastá la versión seleccionada para indexación con la intención del sitio. La prueba en vivo y la información de una versión indexada responden a momentos diferentes; guardá fechas para no interpretar como simultáneas dos observaciones separadas.
Luego mirá consultas y páginas por los mercados relevantes, con volumen y tiempo suficientes para observar tendencias. Un resultado puntual no prueba un error ni un éxito de implementación. Hreflang ayuda a interpretar relaciones, pero no obliga a Google a mostrar una versión ante cualquier búsqueda.
El trabajo queda verificable cuando cada familia tiene equivalentes reales, una declaración consistente y pruebas repetibles. Si aparecen problemas de acceso o indexación anteriores a esta capa, retomá el orden de revisión de SEO técnico antes de seguir modificando etiquetas.
