¿Qué es un URL Slug?

Un buen slug cumple pocas reglas, pero las cumple todas a la vez. Debe ser corto: cuántas menos palabras necesite para describir la página, mejor se lee tanto en el navegador como en un resultado de búsqueda. Debe ser descriptivo: alguien que ve solo la URL, sin haber entrado todavía, tiene que hacerse una idea razonable de qué va a encontrar. Y debe incluir la palabra clave principal de la página, la que resume de qué trata en dos o tres términos, sin forzar variantes ni sinónimos alrededor.

Esta misma página lo demuestra con su propia estructura de URL. En español: https://zds.es/que-es-url-slug. En alemán: https://zds.es/de/was-ist-url-slug. En inglés: https://zds.es/en/what-is-url-slug. En los tres casos, el tramo final es corto, va en minúsculas, no lleva tildes ni caracteres especiales, y las palabras se separan con guiones, no con guiones bajos. Google trata el guion (-) como separador y lee "url" y "slug" como dos términos distintos; el guion bajo (_) lo trata como un carácter que une, así que "url_slug" se leería como una sola palabra, diluyendo la relevancia de cada término por separado.

El prefijo /de/ o /en/ que precede al slug en las versiones alemana e inglesa no forma parte del slug en sí: es la ruta que marca el idioma de la página. El slug es solo el tramo final, el que cambia de un artículo a otro dentro del mismo idioma.

El tercer caso merece un aparte, porque no siempre es un descuido evidente. Las mayúsculas, la tilde y el guion bajo no rompen la página, pero sí generan un problema real: la mayoría de servidores tratan /Taladro-Atornillador y /taladro-atornillador como dos URL distintas, no como la misma con formato diferente. Y una tilde en la URL casi siempre acaba codificada como %C3%A1 en la barra de direcciones, algo que nadie escribe a mano ni recuerda de memoria.

Un slug corto y claro también rinde donde nadie lo analiza técnicamente: en la lista de resultados de un buscador, la URL aparece visible bajo el título, y quien la lee por encima decide en una fracción de segundo si merece la pena el clic. Un slug como /taladro-atornillador-bateria transmite confianza porque anuncia justo lo que va a encontrar. Una cadena larga de IDs o parámetros, en cambio, parece un acierto técnico al azar, aunque la página de detrás tenga un contenido excelente.

Sobre eliminar palabras de relleno hay un matiz que conviene aclarar con el propio ejemplo de este glosario: todos sus slugs en español empiezan por "que-es-", como en "que-es-url-slug". No es un descuido ni una excepción a la regla de evitar relleno; es una convención deliberada y constante en todo el sitio, pensada para que cada URL anticipe el formato de pregunta y respuesta del artículo. Evitar palabras de relleno significa no meter términos que no aportan nada a una URL concreta, no romper un patrón que el propio sitio mantiene a propósito en todas sus páginas.

Cambiar el slug de una página ya publicada no es una simple edición de texto: cambia la URL completa, y una URL nueva es, tanto para el servidor como para Google, un recurso distinto al anterior. Si un artículo pasa de /guía-taladros-2024 a /mejor-taladro-bateria, la primera dirección deja de existir tal cual. Quien intente visitarla, sea una persona que guardó el enlace o el rastreador de Google, se encuentra con un error si nadie ha hecho nada más.

Ahí entra el Redirect 301: la herramienta que avisa de que esa URL se movió de forma permanente a la nueva dirección, y que traslada con ella tanto a quien la visita como el valor de posicionamiento acumulado en enlaces y en historial de rastreo. Sin ese redirect, el cambio de slug no es neutro: la página pierde el rastro de lo que había construido en la URL anterior y suele empezar casi de cero en la nueva.

Esto pesa todavía más con los enlaces externos. Los enlaces internos se pueden actualizar a mano, uno por uno, en cuestión de minutos. Los backlinks que otras webs han puesto hacia la URL antigua no están bajo tu control: nadie va a entrar en un blog de hace tres años a corregir un enlace porque tú cambiaste el slug. Ese backlink sigue apuntando a la dirección original para siempre, y solo un Redirect 301 en esa dirección consigue que el valor de ese enlace llegue de verdad hasta la página nueva.

La mecánica del redirect en sí, cómo se configura, la diferencia con un 302 temporal, cómo comprobar que el servidor devuelve realmente el código 301, está explicada con detalle en el artículo dedicado a Redirect 301. Aquí basta con la conclusión que afecta directamente al slug: cambiarlo sin crear el redirect correspondiente no es un ajuste de detalle, es renunciar al posicionamiento que esa URL ya tenía acumulado.

Es habitual confundir el Canonical Tag con la solución para un cambio de slug, y no lo es. El Canonical existe para una situación distinta: cuando el mismo contenido, o uno muy parecido, está disponible en varias URL que deben seguir funcionando las dos a la vez, por ejemplo una ficha de producto accesible con y sin un parámetro de color. Ahí, el Canonical le indica a Google cuál de las dos versiones prefiere, pero deja ambas accesibles.

Un cambio de slug es justo lo contrario: la URL antigua no tiene que seguir accesible, tiene que desaparecer de verdad y dejar paso a la nueva. Poner un Canonical en la URL antigua que apunte a la nueva, en vez de un redirect, deja esa URL antigua viva y a merced de que Google decida respetar la señal, que trata como una recomendación fuerte, no como una orden. Un Redirect 301 no deja ese margen: la URL antigua deja de responder por su cuenta y el tráfico llega directo a la nueva.

La regla práctica separa los dos casos sin ambigüedad. Si las dos URL tienen que seguir existiendo, Canonical. Si la URL antigua debe dejar de existir porque el slug cambió de verdad, Redirect 301.

Hay un matiz adicional que ayuda a no confundir ambas herramientas: toda página debería llevar un Canonical autorreferente, apuntando a su propia URL, incluida esta misma. Eso confirma cuál es su dirección de referencia mientras no cambie nada. El día que el slug cambia de verdad, ese Canonical autorreferente pasa a apuntar a la URL nueva porque la página ahora vive ahí, y es el Redirect 301, no el Canonical, el que se encarga de que la URL antigua deje de estar accesible por su cuenta.

Usar las dos herramientas a la vez suele complicar más que ayudar: un Canonical de la URL antigua hacia la nueva, combinado con un Redirect 301 en esa misma dirección, es redundante, porque en cuanto la redirección actúa, Google ya ni siquiera llega a evaluar la URL antigua como una entidad aparte. Para un cambio de slug real, el Redirect 301 por sí solo es suficiente.

• Define el slug definitivo antes de publicar, no después: cambiarlo ya publicado siempre cuesta más que acertarlo la primera vez.
• Incluye la palabra clave principal de la página, pero solo esa; no repitas variantes ni sinónimos dentro del mismo slug.
• Usa solo minúsculas, guiones para separar palabras, y ningún carácter especial, tilde o ñ.
• Elimina artículos, preposiciones y palabras de relleno que no aporten significado, salvo que formen parte de una convención ya establecida en el resto del sitio.
• Mantenlo corto: si el slug no cabe entero en una línea de resultados de búsqueda sin cortarse, probablemente sobran palabras.
• Si tienes que cambiarlo de todas formas, crea el Redirect 301 de la URL antigua a la nueva en el mismo momento en que publicas el cambio, no días después.
• Revisa los enlaces internos que apuntan a la URL antigua y actualízalos a la nueva dirección, en vez de dejar que pasen por la redirección.

• Cambiar el slug para "mejorarlo" sin crear el Redirect 301 correspondiente, dejando la URL antigua sin dueño.
• Usar guiones bajos en vez de guiones para separar palabras, lo que hace que Google lea el slug como una sola palabra.
• Meter la fecha, un ID interno o parámetros de sesión en el slug, generando una URL que envejece mal o que cambia en cada visita.
• Encadenar demasiadas palabras clave en el mismo slug pensando que así se posiciona por todas a la vez, cuando en realidad solo lo hace más difícil de leer.
• Confundir el cambio de slug con una situación de contenido duplicado y usar un Canonical donde hacía falta un Redirect 301.
• Dejar mayúsculas o tildes en la URL, generando variantes accesibles por dos direcciones distintas sin ninguna necesidad real.