--- title: "Slugs localizados y hreflang: nuestro trade-off compartido" canonical: https://wavect.io/es/blog/english-slugs-vs-localized-urls-hreflang/ language: es description: "Los slugs localizados son válidos, pero requieren correspondencias por documento. El argumento a favor de un slug compartido y su trade-off real." image: "https://wavect.io/img/blog/headers/header_english-slugs-vs-localized-urls-hreflang.png" author: ["Kevin Riedl"] published: "2026-08-18" updated: "2026-09-02" reviewed: "2026-09-02" --- # Slugs localizados y hreflang: por qué mantenemos uno en inglés [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 7 min de lectura · 18 ago 2026 Última revisión 2 de septiembre de 2026 [**Siguiente**](/es/blog/can-an-ai-agent-use-your-product/) Resumen Google permite palabras localizadas en las URLs, y los slugs localizados no rompen hreflang por sí mismos. El coste operativo está en la capa de correspondencias: cada página de un conjunto de idiomas debe incluirse a sí misma y a todas las alternativas disponibles, y cada alternativa debe devolver esa relación. Un mapa de slugs correcto puede cumplir el contrato, pero exige validar más estados ante renombrados, redirecciones, traducciones ausentes y colisiones de ruta. Mantenemos un slug independiente del idioma porque nuestras plantillas pueden derivar las alternativas desde el prefijo del idioma y el build puede comparar traducciones con una clave compartida. Es una decisión de ingeniería, no una regla SEO universal. El trade-off es una ruta menos localizada y menos legible fuera del inglés. Google afirma que determina el idioma por el contenido visible y no por la URL, así que no atribuimos un efecto directo de ranking a ninguna estrategia. **Los slugs localizados son válidos. Su coste es la capa adicional de correspondencias alrededor de hreflang.** La [guía de Google para sitios multilingües](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) dice expresamente que las palabras localizadas en las URLs son válidas. Renombrados, redirecciones y traducciones ausentes no invalidan la estrategia, pero crean más estados por documento que deben mantenerse alineados. 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 una decisión técnica adecuada para nuestras plantillas y validaciones, no una receta universal. ## Qué exige realmente hreflang El contrato es más simple de lo que sugieren las herramientas. La [documentación de Google sobre hreflang](https://developers.google.com/search/docs/specialty/international/localized-versions) exige que cada página se incluya a sí misma y a todas las versiones disponibles, y que cada destino devuelva la relación. La autorreferencia forma parte del conjunto completo. 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. ## Cuatro fallos que un mapa de slugs localizados debe evitar | Fallo | Qué lo causa | Síntoma | | --- | --- | --- | | Reciprocidad rota | Se renombró el slug de un idioma y los demás siguen apuntando a la cadena antigua | El clúster de idiomas se parte en dos que parecen ambos autoritativos | | hreflang hacia una redirección | Las anotaciones apuntan a la URL previa al renombrado, que ahora hace 301 | La anotación se descarta, y las páginas compiten en lugar de agruparse | | Traducción parcial | Un idioma todavía no tiene versión de este documento | O un puntero muerto o un hueco silencioso, según cómo se escribiera el bucle | | Colisiones de ruta | Dos documentos en inglés se traducen al mismo slug en el idioma destino | Una página sobrescribe la otra, y normalmente lo detecta un cliente | 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](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/), eso significa una dirección predecible por documento y por idioma, sin paso de búsqueda. ## El coste honesto Fuera del inglés pierdes una ruta localizada y más legible para las personas. La dirección puede resultar menos clara o familiar antes de abrirla. Aceptamos ese coste de experiencia porque una dirección predecible simplifica nuestras plantillas, validaciones y espejos legibles por máquinas. Google determina el idioma por el contenido visible, no por la URL. Por eso no tratamos el slug inglés como una penalización demostrada ni el localizado como una mejora demostrada de ranking. 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. Usa redirecciones permanentes del servidor, como 301 o 308, desde cada slug antiguo. Mantenlas al menos un año; conservarlas más tiempo puede seguir ayudando a usuarios y enlaces externos. 3. Regenera hreflang desde la lista de idiomas en lugar de desde una tabla, y confirma que cada página devuelve una autorreferencia. 4. Envía el sitemap actualizado en Search Console e inspecciona URLs representativas o importantes. La [guía de Google para cambios de URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) no promete un plazo fijo. 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. ## Preguntas frecuentes ### ¿Hay que traducir los slugs de URL a cada idioma? Es una opción válida. Una ruta localizada puede ser más clara para las personas, mientras que un slug independiente del idioma simplifica las correspondencias y su validación. Elige el modelo que tu sistema pueda mantener correctamente. ### ¿Es obligatoria la etiqueta hreflang autorreferencial? Sí. Cada página de un conjunto de idiomas debe listar todas las versiones, incluida ella misma. No es redundante, y quitarla es una causa habitual de que un clúster de idiomas se ignore. ### ¿Un slug en inglés perjudica el posicionamiento local? Google documenta que detecta el idioma por el contenido visible, no por la URL, y permite palabras localizadas en ella. No hemos encontrado una fuente fiable que demuestre una penalización automática por compartir un slug inglés. Mide la respuesta de los usuarios en tu mercado. ### ¿Y si una página todavía no está traducida a todos los idiomas? Emite hreflang solo para las versiones que existen y nunca apuntes a una URL que falta o que redirige. Una anotación muerta es peor que una ausente. ### ¿Cómo evitamos que las traducciones se separen? Haz del slug compartido la clave de unión y compruébalo en el build. Verificamos que los cuatro idiomas contienen los mismos conjuntos de entradas para cada archivo de datos y comparamos el contenido por idioma buscando divergencias. Ambas comprobaciones dependen de que el identificador se comparta entre idiomas. ### ¿Hay que mantener funcionando las URLs traducidas antiguas? Google recomienda conservar las redirecciones al menos un año. Mantenerlas más tiempo puede seguir atendiendo a usuarios y enlaces externos que usan la dirección antigua. ## Reflexiones finales Los slugs localizados son compatibles y pueden aclarar las rutas para quien las lee. También necesitan un mapa fiable por documento cuando las URLs alternativas cambian entre idiomas. En nuestro sitio de cuatro idiomas, un slug independiente del idioma simplifica la generación de hreflang y las comprobaciones de paridad. Es nuestro trade-off técnico, no una regla para todas las webs multilingües. ## También te puede gustar.. [**Webs legibles por agentes: llms.txt y espejos en Markdown** Las cuatro superficies que deciden si un motor de respuestas puede leerte, y los fallos de conversión que conviene blindar.](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) [**Wavect vs una agencia de desarrollo generalista** Dónde se solapa el trabajo y dónde no lo hacen el modelo de precios ni la propiedad del alcance.](/es/compare/wavect-vs-dev-agencies/) Ingeniería de agentes ## Qué leer después Agentes de código, MCP, contexto, evaluación y controles para automatización fiable. [Empieza aquí**Ingeniería de grafos para agentes de IA: ¿Cuándo compensa un knowledge graph?**](/es/blog/graph-engineering-ai-agents/) - [RTK AI 1.0: ahorro real, instalación y licencias](/es/blog/rtk-ai-token-savings-review/) - [Anatomy para Claude Code: SVG interactivos en documentación](/es/blog/anatomy-claude-code-interactive-svg/) - [Google AX: suspensión, reinicios y autoalojamiento](/es/blog/google-ax-agent-executor-security-self-hosting/) - [WikiSkill: cómo los agentes evolucionan SKILL.md con experiencia](/es/blog/wikiskill-self-evolving-agent-skills/) - [Tencent Octop: qué reciben realmente gratis los desarrolladores](/es/blog/tencent-octop-ai-assistant-review/) [Artículo anterior**Webs legibles por agentes: llms.txt, espejos en Markdown y qué se rompe**](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) [Artículo siguiente**¿Puede un agente de IA usar tu producto, o solo leer sobre él?**](/es/blog/can-an-ai-agent-use-your-product/) [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 7 min de lectura · 18 ago 2026 Última revisión 2 de septiembre de 2026 [**Siguiente**](/es/blog/can-an-ai-agent-use-your-product/)