Las URLs traducidas rompen hreflang. Nosotros mantenemos un solo slug en inglés.

La mayoría de los errores de hreflang en webs multilingües no son errores de hreflang. Son errores de slug. Traduce la URL además de la página y cada renombrado, cada redirección y cada traducción que falta se convierte en una forma de que el grafo de idiomas se deshaga, en silencio, en un subconjunto de páginas que nadie está mirando.

Este sitio funciona en cuatro idiomas y deliberadamente no traducimos los slugs. La página alemana de visibilidad en IA vive en /de/services/ai-visibility/, no en una ruta en alemán. Es un trade-off real con un coste real, y creemos que es el correcto para la mayoría de los equipos. Este es el razonamiento, y el precio.

Qué exige realmente hreflang

El contrato es más simple de lo que sugieren las herramientas. Cada página de un conjunto de idiomas debe apuntar a todas las demás versiones, incluida ella misma, y cada uno de esos punteros debe ser devuelto por la página a la que apunta. Un hreflang autorreferencial es correcto y obligatorio, no una redundancia que optimizar.

Ese requisito de reciprocidad es donde los slugs traducidos se vuelven caros. Con un solo slug necesitas conocer los prefijos de idioma. Con slugs traducidos necesitas una tabla de correspondencias correcta y actualizada entre cuatro cadenas distintas por documento, y necesitas que sobreviva a cada edición que haga cualquiera.

Los cuatro fallos que crean los slugs traducidos

Ninguno es imposible de arreglar. Todos son por documento, y ahí está el problema: aparecen en un puñado de páginas y no en todo el sitio, así que una revisión por muestreo parece limpia.

Qué te da un solo slug

Si el slug es independiente del idioma, el grafo de idiomas pasa a ser una función del prefijo de ruta. La plantilla puede generar cada puntero hreflang a partir de la lista de idiomas y del propio nombre de archivo de la página, sin tabla que mantener y sin nada que se desincronice. La reciprocidad se vuelve estructural en lugar de algo que verificar.

También abarata las comprobaciones vecinas. Cuando la versión de cada idioma de un documento comparte slug, "¿está este documento traducido en todas partes?" es una comparación de conjuntos sobre nombres de archivo. Eso lo blindamos en el build: un script comprueba que los cuatro idiomas contienen los mismos conjuntos de entradas para cada archivo de datos, y otro compara el contenido por idioma buscando divergencias. Ambas cosas solo son posibles porque el identificador es compartido.

La misma propiedad ayuda a máquinas que no son buscadores. Un agente que tiene tu URL en inglés puede construir la alemana por regla. Combinado con un espejo en Markdown por ruta, eso significa una dirección predecible por documento y por idioma, sin paso de búsqueda.

El coste honesto

Pierdes la palabra clave en la URL para todos los idiomas excepto el inglés. Para un comprador alemán que busca una frase en alemán, un slug en alemán es una señal pequeña y real de relevancia y de clic, y estamos eligiendo no tenerla.

Lo aceptamos por tres razones. La palabra clave en la URL es una señal débil comparada con el título, los encabezados y el cuerpo, que están totalmente traducidos. El fallo que evita es silencioso y acumulativo, mientras que el beneficio que cuesta es pequeño y medible. Y en un sitio donde los motores de respuestas pesan tanto como los buscadores, una dirección predecible vale más que una palabra clave en la ruta.

Si tu negocio es sobre todo búsqueda en el idioma local de un mercado y tienes dos docenas de páginas, traduce los slugs. La correspondencia se mantiene lo bastante pequeña para llevarla a mano. El argumento de aquí trata de cuatro idiomas y varios cientos de rutas, donde nadie mantiene a mano una tabla correcta.

Migrar sin perder las páginas que ya tienes

Si ya tienes slugs traducidos, esto no es urgente y no es gratis. Cuando lo hagas:

1. Elige el slug en inglés como el canónico y mantenlo estable a partir de entonces. El renombrado que hagas ahora debería ser el último.
2. Redirige con 301 cada slug traducido hacia él, de forma permanente. Deja esas redirecciones puestas; no hay buena razón para quitarlas nunca.
3. Regenera hreflang desde la lista de idiomas en lugar de desde una tabla, y confirma que cada página devuelve una autorreferencia.
4. Reenvía el sitemap y avisa a los endpoints de IndexNow, para que el cambio se recoja en días y no en meses.
5. Comprueba que los enlaces internos apuntan directamente al nuevo slug y no pasan por la redirección, porque un sitio lleno de 301 internos es su propio problema lento.

El paso cinco es el que se salta la gente. Una redirección que solo es alcanzable desde tu propia navegación es una redirección de la que nunca notarás que está mal.