URL amigable: cómo escribir slugs para SEO

Cuando alguien busca "url amigable seo" suele partir de una de dos situaciones: un gestor de contenidos que pide un slug y no se sabe qué escribir, o una URL ya publicada del tipo /producto?id=48291&cat=12. Una URL amigable es una secuencia de palabras que describe el contenido de la página sin depender de parámetros ni identificadores numéricos que solo entiende la base de datos. Tanto una persona como un rastreador deberían poder leer la URL y adivinar, sin entrar, de qué trata la página.

Este artículo se centra en el nivel de la palabra: longitud del slug, qué palabras quitar, cómo tratar los acentos y la ñ, cuándo usar guiones y cuándo fechas, y cuántas carpetas anidar por delante. Las decisiones de migración entre plataformas o de arquitectura completa del sitio se tratan en otros artículos del blog; aquí el foco es el slug en sí y las decisiones diarias de quien lo escribe.

Qué hace que un slug sea realmente amigable

Un slug amigable cumple tres condiciones a la vez. Primero, es legible: una persona que ve la URL en una pestaña del navegador, en un resultado de búsqueda o al copiarla en un chat entiende de qué trata la página sin necesidad de hacer clic. Segundo, es descriptivo: contiene las palabras que realmente identifican el contenido, no una etiqueta genérica como /post-482 o /articulo-nuevo. Tercero, es estable: una vez publicado, no depende de datos que cambian con el tiempo, como un precio, un nivel de stock o la fecha de un evento que ya pasó, porque cada cambio de esos datos tienta a cambiar también la URL.

La confusión más común es tratar el slug como un campo de metadatos más, al mismo nivel que la meta description. No lo es: el slug forma parte de la dirección permanente del recurso. Cambiarlo rompe enlaces entrantes, marcadores guardados por usuarios y, si no se gestiona con una redirección, el historial de rastreo que un buscador ya tiene acumulado sobre esa URL concreta. Por eso conviene decidirlo bien la primera vez, en vez de corregirlo sobre la marcha cada pocos meses.

Cuánto debe medir un slug

No existe un número mágico de caracteres. Lo que sí es un mecanismo verificable es que Google trunca los resultados de búsqueda a un ancho de píxeles, no a un conteo fijo de caracteres: una URL con palabras largas se corta antes que una de longitud similar hecha con palabras cortas. Y, a nivel de lectura humana, una URL que necesita dos líneas para leerse deja de transmitir información de un vistazo, que es precisamente la ventaja que se busca al hacerla amigable.

En la práctica, la regla operativa es otra: incluir las palabras necesarias para identificar el contenido sin ambigüedad y detenerse ahí. Si el título de una página es "Cómo cuidar un bonsái de ficus en interior", un slug razonable es /bonsai-ficus-interior, no /como-cuidar-un-bonsai-de-ficus-en-interior-guia-completa. El segundo no es más amigable por ser más largo; simplemente repite palabras que ya aparecen en el título y en el encabezado principal de la página, donde también cuentan para el usuario y para el rastreador.

• Recorta lo que ya se explica en otro lugar de la página, como el encabezado principal o las migas de pan: el slug no tiene que repetirlo todo.
• Si dos páginas comparten casi el mismo slug, añade solo la palabra que las distingue, no una frase entera.
• Antes de publicar, comprueba cómo se ve la URL en un resultado de búsqueda; si se corta a mitad de palabra, es señal de que sobra texto.

Palabras vacías: cuáles quitar y cuáles dejar

Las palabras vacías, artículos, preposiciones y conjunciones, son las primeras candidatas a eliminar de un slug, pero quitarlas todas sin criterio puede dejar una secuencia de sustantivos que no se lee como una frase real y que, en español, a veces cambia el sentido.

El criterio útil no es "quita todas las de, la, el, y" sino "quita las que no cambian el significado si desaparecen". En "guía de contratación de personal" se puede quitar el "de" sin perder nada: /guia-contratacion-personal. Pero en un slug como "antes y después" quitar la "y" rompe la frase: /antes-despues no comunica lo mismo que /antes-y-despues, aunque ambas versiones se entiendan de lejos. Esta decisión no cambia el posicionamiento de forma medible en ninguno de los dos casos: es una decisión de legibilidad, no de optimización.

• Los artículos (el, la, los, las) y las preposiciones simples (de, en, por) casi siempre se pueden quitar sin ninguna pérdida de sentido.
• Las conjunciones que unen dos conceptos distintos (y, o, pero) conviene conservarlas si el slug pierde sentido sin ellas.
• Nunca elimines una palabra que forme parte de un nombre propio o de un término técnico exacto que la gente escribe tal cual, como "Search Console".

Acentos y la ñ en las URLs

Técnicamente, una URL puede contener caracteres no ASCII: los navegadores y servidores modernos los codifican en UTF-8 y después en percent-encoding, de modo que una "á" se convierte en %C3%A1 y una "ñ" en %C3%B1. El problema no es que no funcione, sino que ese código deja de ser legible y es incómodo de escribir a mano, copiar en un mensaje o dictar por teléfono. Algunos sistemas más antiguos, como ciertas hojas de cálculo o clientes de correo, todavía muestran esa codificación rota en vez de decodificarla.

Por eso la práctica establecida en español es transliterar: quitar las tildes y sustituir la ñ por n dentro del slug, mientras el título y el contenido visible sí conservan la ortografía correcta. "Diseño de interiores pequeños" se convierte en /diseno-interiores-pequenos como slug, mientras el encabezado de la página sigue mostrando "Diseño de interiores pequeños" tal cual se escribe. No es una concesión al inglés: es evitar una capa de codificación innecesaria en la parte de la URL que la gente más manipula a mano.

• Transformación estándar para el slug: á pasa a a, é a e, í a i, ó a o, ú a u, ü a u y ñ a n.
• Aplica la transliteración solo al slug, nunca al título visible ni al cuerpo del texto: ahí la ortografía correcta con tildes es obligatoria.
• Si el gestor de contenidos genera el slug automáticamente a partir del título, revisa el resultado: algunos generadores dejan la cadena percent-encoded en vez de transliterarla, y eso conviene corregirlo a mano.

Guiones, mayúsculas y otros detalles de formato

El guion medio es el separador estándar entre palabras en un slug, y hay una razón técnica para preferirlo sobre el guion bajo: los motores de búsqueda lo tratan como un espacio, separando "seo" y "tecnico" en dos palabras, mientras que el guion bajo se ha interpretado tradicionalmente como parte de una sola palabra, uniendo "seo_tecnico" en un único token. Usar guion bajo no rompe el sitio, pero puede diluir la señal de qué palabras individuales contiene realmente esa URL.

Las mayúsculas son otro punto de fricción menos visible: en muchos servidores, /Contacto y /contacto son rutas técnicamente distintas, aunque para una persona parezcan la misma página. Si el gestor de contenidos no fuerza minúsculas de forma consistente, se puede terminar con dos URLs sirviendo el mismo contenido, compitiendo entre sí en vez de consolidar toda la señal en una sola dirección. La solución no es vigilar cada slug a mano, sino fijar la regla una sola vez para que el propio sistema la aplique siempre.

• Usa siempre guion medio; evita el guion bajo y evita mezclar mayúsculas y minúsculas dentro del mismo slug.
• Si detectas que tu sitio sirve la misma página en mayúsculas y en minúsculas, añade una redirección o una regla de normalización a una sola versión; no dejes que convivan ambas indefinidamente.
• Evita también espacios sin codificar y símbolos como &, % o # dentro del slug; cada uno introduce una capa de codificación o entra en conflicto con la sintaxis propia de la URL.

Fechas en la URL: cuándo ayudan y cuándo estorban

Incluir una fecha en el slug, como /2024/03/titulo-del-articulo, tiene sentido cuando el contenido es intrínsecamente temporal: una noticia, un resultado deportivo, una convocatoria con plazo de inscripción. En esos casos la fecha forma parte del significado del contenido, no es decoración, y quitarla no simplificaría nada porque el lector necesita saber a qué momento corresponde.

El problema aparece cuando se aplica esa misma plantilla a contenido evergreen. Una guía sobre cómo optimizar imágenes, por ejemplo, no caduca por naturaleza, pero si su slug lleva /2022/, cada vez que se actualice en 2026 la URL seguirá sugiriendo que el contenido tiene varios años, incluso después de haberla reescrito por completo. Corregir eso más adelante exige cambiar el slug y gestionar una redirección permanente, con el riesgo de trasladar mal el historial de esa dirección. Sale más barato decidir bien desde el principio: fecha en el slug solo cuando el propio contenido es efímero, y sin fecha cuando se trata de una página de referencia que se espera actualizar con el tiempo.

Profundidad de carpetas: cuántos niveles usar

La profundidad de carpetas es el número de segmentos separados por barra antes del slug final: /blog/articulo tiene un nivel, mientras que /blog/categoria/subcategoria/articulo tiene tres. Ningún nivel adicional penaliza por sí solo; no existe una regla que castigue una URL de cuatro niveles frente a una de dos. Pero sí añade fricción indirecta: más eslabones en la ruta de clics desde la página de inicio, más probabilidad de que un rastreador con presupuesto limitado tarde más en llegar hasta esa página, y una dirección más difícil de recordar o compartir.

El criterio práctico es reflejar la jerarquía real del sitio sin inventar niveles que no aportan nada. Si una categoría solo agrupa tres artículos y no tiene una página propia de listado útil, ese nivel es ruido: mejor /blog/articulo que /blog/categoria-vacia/articulo. Si un sitio tiene cientos de productos organizados en categorías reales que la gente navega y filtra activamente, esa carpeta intermedia sí describe algo genuino y ayuda tanto a la navegación como al rastreo por secciones.

• Antes de añadir un nivel de carpeta, pregúntate si esa categoría tiene su propia página de listado con valor real; si no lo tiene, probablemente no merece ser un segmento de la URL.
• Mantén la profundidad razonablemente constante entre páginas del mismo tipo: que todos los artículos del blog vivan al mismo nivel facilita mantener la plantilla de URLs a largo plazo.
• Si más adelante cambias la estructura de categorías, los slugs de las páginas individuales no tienen por qué moverse: se puede mantener /blog/articulo estable aunque la categoría a la que pertenece cambie de nombre.

Cuándo vale la pena cambiar una URL que ya existe

Cambiar el slug de una página que ya está indexada y recibe tráfico no es gratis: exige una redirección permanente, un periodo en el que el buscador vuelve a procesar la señal, y el riesgo de que algún enlace externo antiguo no se actualice y quede apuntando a una dirección que ya no existe salvo por esa redirección. Por eso el cambio solo compensa cuando el slug actual tiene un problema real, no simplemente algo mejorable.

Compensa cuando: hay un identificador numérico sin significado, como /producto/48291, sustituible por uno descriptivo; una errata evidente que se repetirá en cada enlace futuro; una fecha en el slug de un contenido evergreen, como se explicó antes; o una acumulación de palabras clave de una época anterior, como /zapatillas-running-baratas-zapatillas-running-oferta, que hoy penaliza más por mala experiencia que por otra cosa. Normalmente no compensa cuando el slug es correcto pero solo mejorable en un margen pequeño, la página tiene pocos enlaces y poco tráfico, o el cambio es puramente estético sin ningún problema funcional detrás.

Si finalmente se decide cambiar un slug, conviene hacerlo de una vez y de forma definitiva: cambiarlo dos veces en poco tiempo añade un eslabón a la cadena de redirecciones, y cada eslabón adicional diluye la señal. Conviene también comprobar que la redirección apunta directamente al destino final, y no a otra redirección intermedia.