Generador de hreflang

Qué hace realmente hreflang

Una anotación hreflang le dice al buscador que varias URL son la misma página escrita para idiomas o países distintos, para que cada persona reciba la versión que le corresponde. Conviene ser preciso con los límites, porque casi toda la decepción alrededor de hreflang viene de esperar más de lo que da:

• Es una indicación sobre qué versión mostrar, no una instrucción sobre qué indexar. Cada página sigue teniendo que ganarse su sitio por sí misma.
• No mejora el posicionamiento. Lo que arregla es que posicione la versión equivocada, o que dos versiones tuyas compitan por la misma consulta.
• No sustituye a la canónica, y no puede contradecirla. Si la página en inglés canonicaliza hacia la española y a la vez la declara alternativa, has dado dos instrucciones opuestas y la anotación se ignora.

Dónde poner las etiquetas

Hay tres sitios válidos, y deberías usar exactamente uno:

• Head del HTML. Lo habitual. Cada página lleva el conjunto completo, incluida la etiqueta que apunta a sí misma.
• Cabecera HTTP Link. Para archivos sin head donde poner etiquetas: PDF, imágenes, feeds. El mismo contenido, servido como cabecera de respuesta.
• Sitemap XML. Una entrada por URL, cada una con el conjunto entero. Es verboso, pero mantiene las anotaciones en un solo archivo en vez de repartidas por miles de plantillas, y eso es lo que lo convierte en la opción cómoda a partir de una veintena larga de versiones.

Hacer dos a la vez es un lío frecuente y evitable. Las etiquetas del head se actualizan en un rediseño, el sitemap no, y de pronto la misma URL está declarada de dos maneras distintas por dos equipos que nunca han hablado entre ellos.

Códigos que validan y aun así pierden el mercado

Todos estos pasan cualquier comprobador de sintaxis. Están mal igualmente, y son la razón de que esta herramienta lleve dentro la lista ISO completa en lugar de una expresión regular:

El patrón es que hreflang no tiene ningún concepto de continente, de región ni de bloque comercial. Hay un idioma y, opcionalmente, un país. Todo lo de esa lista es alguien intentando expresar algo que el formato sencillamente no tiene, y quedándose con un código válido que significa otro sitio.

Para quien vende a Latinoamérica esto importa especialmente. No existe una etiqueta para la región. O usas es a secas y dejas que el idioma haga el trabajo, o segmentas país por país con es-MX, es-AR, es-CO — y entonces te toca justificar por qué esas páginas son distintas entre sí, porque si no lo son acabarán compitiendo.

El orden en el que yo trabajaría

1. Primero la lista de URL, después los códigos. Al revés es como acabas con versiones para las que nadie tiene páginas.
2. Usa códigos de solo idioma salvo que el país cambie algo de verdad. es sirviendo a toda Latinoamérica gana a es-MX, es-AR y es-CO apuntando a tres páginas casi idénticas que luego compiten entre ellas.
3. Revisa la canónica de cada página. Cada versión se canonicaliza a sí misma. Esta es la forma más habitual de que un conjunto de etiquetas correcto se ignore.
4. Despliega en todas las URL del conjunto a la vez. Un despliegue parcial es un conjunto de etiquetas de retorno rotas, y los pares siguen descartados hasta que sale la última página.
5. Verifica cuando esté en producción, descargando las páginas y comparando las dos direcciones. No mirando la plantilla.

Lo que esta herramienta no hace

Genera y valida códigos. No rastrea tu sitio, así que no puede ver si las etiquetas que pegues acabaron de verdad en todas las páginas ni si las de retorno se corresponden en producción. Ese es otro trabajo, y es el que merece la pena hacer después de desplegar: en la guía práctica de hreflang explico el fallo de las etiquetas de retorno con detalle, y en la checklist de auditoría SEO internacional (en inglés) está el orden completo de revisión.

Preguntas