URL Slugs que posicionan: cómo crear URLs amigables para SEO siempre

Llevo mucho tiempo construyendo sitios web, y una de las fuentes más consistentes de daño SEO silencioso e invisible que veo son los malos URL slugs. No canonicals incorrectos. No meta descripciones faltantes. Solo malos slugs — URLs que fueron generadas automáticamente por un CMS sin pensar, o escritas a mano por alguien con prisa que nunca había oído hablar de la codificación porcentual.

La buena noticia es que los slugs son fáciles de hacer bien. Una vez que entiende las reglas, nunca pensará dos veces al respecto. Y si quiere saltarse el pensamiento por completo, nuestro convertidor de texto a slug hará el trabajo pesado por usted.

Pero entender por qué existen las reglas vale unos minutos de su tiempo. Permítame explicarlo.

¿Qué es exactamente un URL slug?

Un slug es la parte legible por humanos de una URL que identifica una página específica. En esta URL:

https://example.com/blog/how-to-bake-sourdough-bread

El slug es how-to-bake-sourdough-bread.

El término proviene de la industria periodística, donde un "slug" era un nombre corto dado a un artículo en progreso — un identificador interno antes de que el titular fuera finalizado. Los desarrolladores web tomaron prestado el término en los primeros días de los CMS y se quedó.

Los slugs sirven dos propósitos simultáneamente: le dicen a los humanos de qué trata una página antes de hacer clic, y le dicen a los motores de búsqueda qué palabras son relevantes para el contenido de la página. Haga un slug correctamente y está haciendo ambas cosas a la vez. Hágalo mal y está trabajando contra usted mismo en ambos frentes.

Por qué los slugs realmente importan para el SEO

Aquí hay algo que mucha gente hace mal: tratan la estructura de URLs como un factor SEO menor y la relegan al final de la lista de prioridades. Y aunque es cierto que la calidad del contenido y los backlinks importan más, los URL slugs son una de las pocas señales de clasificación que no cuestan nada corregir en una nueva página.

Google lee su URL slug como una señal sobre lo que cubre la página. Si su página trata sobre "las mejores botas de senderismo para pies anchos" y su slug es best-hiking-boots-for-wide-feet, está reforzando esa palabra clave en un lugar más. Si su slug es product-2847-v3, está tirando esa oportunidad.

Más prácticamente: las URLs aparecen en los resultados de búsqueda. Se muestran debajo del título de su página en el fragmento SERP. Un slug limpio y legible hace que su resultado parezca más confiable y relevante. Un slug lleno de guiones, números aleatorios e IDs de sesión produce el efecto contrario.

Los enlaces compartidos en redes sociales, correos electrónicos y mensajes de Slack a menudo se muestran como texto plano. Compare:

• example.com/p?id=4821&ref=sidebar — sospechoso, parece spam de seguimiento
• example.com/blog/best-hiking-boots-wide-feet — le dice inmediatamente lo que obtendrá

El segundo obtiene más clics. Más clics con las mismas impresiones significa una mejor tasa de clics, que Google usa como señal de clasificación.

El debate guiones vs. guiones bajos (finalmente resuelto)

Este argumento ha estado en curso desde principios de los 2000 y todavía lo veo aparecer en canales de Slack y publicaciones en foros. Permítame cerrarlo aquí.

Use guiones. Siempre. En URLs.

Aquí está la posición oficial de Google: los guiones en URLs se tratan como separadores de palabras. Si su slug es best-hiking-boots, Google lo lee como tres palabras separadas: "best", "hiking", "boots". Su página será elegible para clasificarse en búsquedas que involucren cualquiera de esas palabras.

Los guiones bajos no se tratan de la misma manera. best_hiking_boots es tratado por Google como un solo token: best_hiking_boots. Su página no se clasificará para "hiking boots" como frase — solo para la cadena conectada con guiones bajos que casi nadie busca.

Esto no era un rumor de un foro SEO. Matt Cutts de Google lo abordó explícitamente en un video de Webmaster hace años, y John Mueller lo ha confirmado desde entonces. La recomendación oficial de Google es: use guiones como separadores de palabras en las URLs.

Cuándo los guiones bajos están bien (solo no en URLs)

Los guiones bajos tienen su lugar — solo no en rutas de URL:

• Nombres de archivos en código: user_profile_image.png, config_loader.py
• Nombres de variables Python: PEP 8 dice snake_case para variables y funciones
• Nombres de columnas de base de datos: created_at, user_id, order_total
• Variables de entorno: DATABASE_URL, API_SECRET_KEY

En estos contextos, los guiones bajos son idiomáticos y correctos. Pero en el momento en que está construyendo una URL, cambie a guiones.

Errores comunes de slugs (he cometido todos estos)

1. Dejar caracteres especiales

Alguien escribe una publicación titulada What's the Best Framework for 2026? y el CMS falla o genera un slug como what%27s-the-best-framework-for-2026%3F. El apóstrofe se convierte en %27, el signo de interrogación en %3F.

Estas URLs codificadas en porcentaje funcionan técnicamente, pero se ven terribles cuando se pegan como texto plano. También son manejadas de manera inconsistente por diferentes servidores, CDNs y proxies inversos. Simplemente elimínelos.

Buena regla: mantenga solo letras minúsculas, números y guiones en sus slugs. Todo lo demás se elimina o transliterate.

2. Dejar los caracteres acentuados tal cual

Un sitio en idioma francés podría tener una publicación titulada "Café au lait: histoire et préparation". Un generador de slugs ingenuo podría producir café-au-lait-histoire-et-préparation.

El é en ese slug se codificará en porcentaje en la URL real: caf%C3%A9-au-lait-histoire-et-pr%C3%A9paration. Eso es un desastre. Un mejor enfoque es transliterar los caracteres acentuados a sus equivalentes ASCII primero: cafe-au-lait-histoire-et-preparation.

Sí, los puristas dirán que los caracteres acentuados ahora son técnicamente válidos en IRIs (Internationalized Resource Identifiers). Tienen razón. Pero la realidad práctica es que las URLs con caracteres multibyte codificados en porcentaje se rompen en clientes de correo, se ven mal en compartidos sociales y a veces se corrompen al copiar y pegar. Para URLs públicas, los slugs ASCII puros son más seguros y más limpios.

3. Letras mayúsculas en slugs

/Blog/How-To-Bake-Sourdough-Bread y /blog/how-to-bake-sourdough-bread son técnicamente dos URLs diferentes. La mayoría de los servidores son sensibles a mayúsculas/minúsculas en el componente de ruta. Puede terminar con problemas de contenido duplicado y división de link equity si ambas versiones son accesibles.

Siempre minúsculas. Sin excepciones.

4. Guiones consecutivos o guiones al inicio/final

how--to-bake--sourdough (guiones dobles por eliminación de caracteres) o -how-to-bake-sourdough- (guiones al inicio/final por eliminación de caracteres especiales al inicio/final). Estos no rompen nada técnicamente, pero se ven descuidados y algunos validadores los señalan.

Un buen generador de slugs colapsa múltiples guiones consecutivos en uno y elimina guiones del inicio y final del resultado.

5. Las palabras vacías consumen el presupuesto de caracteres

the-best-way-to-bake-sourdough-bread-at-home vs bake-sourdough-bread-home.

La segunda versión es más corta, acierta en los términos clave y se lee bien. "the", "best", "way", "to", "at" son palabras vacías — añaden longitud sin añadir valor SEO. No necesita eliminar cada palabra vacía, pero sea deliberado sobre la longitud del slug.

Dicho esto, personalmente no me estreso por cada palabra vacía. A veces hacen el slug más legible. how-to-bake-sourdough se lee más naturalmente que bake-sourdough. Use su criterio.

Buenos slugs vs. malos slugs: ejemplos reales

Así es como se ve en la práctica:

Tema de la página	Slug malo	Slug bueno
Publicación de blog sobre pan de masa madre	post-1293-v2	sourdough-bread-beginners-guide
Página de producto para zapatillas de running	product?id=8821&cat=shoes	mens-running-shoes-lightweight
Página de documentación	Docs_API_Reference_v3	api-reference
Página de evento	event_for_2026-03-25_conference	2026-developer-conference
Artículo de café francés	caf%C3%A9-au-lait-recipe	cafe-au-lait-recipe
Artículo de pregunta	what%27s-new-in-react-2026%3F	whats-new-react-2026

Note que los buenos slugs son consistentes: minúsculas, solo guiones, sin caracteres especiales, cortos pero descriptivos. No necesitan ser perfectamente concisos — sourdough-bread-beginners-guide está bien — pero deben describir claramente el contenido de la página.

Longitud del slug: ¿qué tan largo es demasiado largo?

No hay un límite estricto, pero hay algunas pautas prácticas.

Google generalmente muestra las URLs en los resultados de búsqueda truncadas alrededor de 70-80 caracteres. Si su slug tiene 120 caracteres, la URL mostrada en los resultados de búsqueda se cortará. Eso no es catastrófico, pero es ligeramente menos legible.

Más importante: los slugs largos a menudo indican que está incluyendo palabras vacías o términos redundantes que no necesita. Si su título es "La guía definitiva completa y total para entender y usar URL slugs en el desarrollo web moderno en 2026", su slug no debería ser toda esa frase. Algo como url-slug-guide-web-development cubre las palabras clave relevantes en una fracción de la longitud.

Objetivo aproximado: intente mantener los slugs por debajo de 70 caracteres. Por debajo de 50 es aún mejor. Por debajo de 30 es ideal para páginas de alto tráfico que quiere que sean fáciles de recordar y escribir.

¿Qué pasa cuando cambia un slug después de publicar?

Aquí es donde mucha gente comete errores costosos. Publica una publicación de blog con slug how-to-build-react-app, acumula backlinks, se comparte, sube en los rankings. Luego seis meses después decide renombrarla a react-app-tutorial-beginners. Cambia el slug y... la URL antigua comienza a devolver 404.

Cada enlace entrante que apunta a la URL antigua ahora llega a una página muerta. Cada ranking de búsqueda construido en esa URL desaparece. El link equity que pasó meses ganando se evapora.

Debe configurar una redirección 301 de la URL antigua a la nueva. Una 301 es una redirección permanente — le dice tanto a los navegadores como a los motores de búsqueda que la página se ha movido permanentemente, y transfiere la mayor parte del link equity y las señales de clasificación a la nueva URL.

En la práctica: la mayoría de los CMSes tienen gestión de redirecciones incorporada (o a través de plugins). En Next.js lo maneja en next.config.js. En nginx es una directiva rewrite. En Apache es un Redirect o RewriteRule en .htaccess.

Si está en WordPress, el plugin Redirection es el camino más fácil. Asegúrese de establecer redirecciones 301, no redirecciones 302 (temporales).

La conclusión: si una página tiene backlinks o tráfico orgánico, trate un cambio de slug como una operación significativa que requiere trabajo de redirección. No simplemente actualice el slug y lo llame hecho.

Cómo generar slugs programáticamente

Si está construyendo un CMS o una plataforma de contenido, querrá auto-generar slugs a partir de títulos de publicaciones. Aquí está la lógica central en JavaScript:

function toSlug(text) {
  return text
    .toLowerCase()
    .normalize('NFD')                    // Descomponer caracteres acentuados
    .replace(/[\u0300-\u036f]/g, '')     // Eliminar marcas de acento
    .replace(/[^a-z0-9\s-]/g, '')        // Eliminar caracteres especiales restantes
    .trim()
    .replace(/\s+/g, '-')               // Reemplazar espacios con guiones
    .replace(/-+/g, '-');               // Colapsar múltiples guiones
}

Algunos puntos a tener en cuenta sobre esta implementación:

• normalize('NFD') seguido de eliminar caracteres de combinación maneja limpiamente la mayoría de las letras acentuadas europeas. café se convierte en cafe, naïve en naive, résumé en resume.
• No maneja todos los scripts. Cirílico, chino, japonés, árabe — estos requieren bibliotecas de transliteración en lugar de simple eliminación de acentos. Si su contenido es multilingüe, mire los paquetes npm transliteration o slug que manejan esto mejor.
• No elimina las palabras vacías. Recomendaría manejar eso por separado con una lista explícita si quiere ese comportamiento, en lugar de incorporarlo a la función slug central.

O puede saltarse escribir esto por completo y usar nuestro convertidor de texto a slug, que maneja caracteres acentuados, símbolos especiales, múltiples espacios y todos los casos límite.

SEO más allá del slug

Los slugs son una pieza del rompecabezas de estructura de URLs, pero algunos puntos relacionados vale la pena mencionar:

La profundidad de la URL importa. Una URL como example.com/blog/seo/2026/03/how-to-write-slugs está profundamente anidada y señala que la página es una sub-sub-subcategoría. Las estructuras más planas como example.com/blog/how-to-write-slugs generalmente tienen mejor rendimiento.

La consistencia dentro de un sitio importa. Si algunas de sus publicaciones usan URLs basadas en fechas (/2026/03/25/post-title) y otras no, esa inconsistencia no es una penalización de clasificación — pero sí hace la gestión de URLs más compleja. Elija un patrón y cúmplalo.

No rellene con palabras clave. Un slug como best-seo-slug-url-slug-generator-seo-2026 parece spam. Las políticas de spam de Google mencionan explícitamente el keyword stuffing en URLs. Una o dos palabras clave principales, describa el contenido con precisión, deténgase ahí.

El flujo de trabajo práctico

Cuando estoy escribiendo una publicación o creando una nueva página, mi flujo de trabajo de slugs es:

1. Escribir el título
2. Pensar qué escribiría alguien en Google para encontrar esta página
3. Construir el slug a partir de las palabras clave principales del paso 2, no mecánicamente del título
4. Verificar: ¿minúsculas? ¿Solo guiones? ¿Sin caracteres especiales? ¿Menos de 60 caracteres? ¿Descriptivo sin relleno?
5. Configurar, publicar y dejarlo solo

La parte de "dejarlo solo" es importante. Resista el impulso de ajustar slugs después de publicar a menos que tenga una muy buena razón. El costo SEO de los cambios de URL es real.

Para convertir rápidamente cualquier título a un slug limpio, marque como favorito el convertidor de texto a slug — maneja todos los casos límite y produce un resultado listo para copiar instantáneamente.

---

Preguntas frecuentes

¿Qué es un URL slug?

Un URL slug es la parte de una dirección web que viene después del nombre de dominio, identificando una página específica. Por ejemplo, en example.com/blog/how-to-bake-bread, el slug es how-to-bake-bread. Los buenos slugs están en minúsculas, usan guiones como separadores de palabras y describen el contenido de la página de forma concisa.

¿Debo usar guiones o guiones bajos en las URLs?

Use guiones. Google trata los guiones como separadores de palabras, lo que significa que un slug como best-hiking-boots se lee como tres palabras separadas. Los guiones bajos no reciben este tratamiento — best_hiking_boots se analiza como un solo token. Esto afecta directamente cómo se posiciona su página para consultas de búsqueda de múltiples palabras, por lo que la elección importa.

¿Qué tan largo debe ser un URL slug?

Mantenga los slugs por debajo de 70 caracteres cuando sea posible. Los slugs más cortos son más fáciles de compartir, recordar y frecuentemente tienen mejor rendimiento en los resultados de búsqueda. El objetivo práctico es incluir sus palabras clave principales y eliminar palabras de relleno como "el", "un", "y". La mayoría de los buenos slugs terminan entre 20 y 50 caracteres.

¿Puedo cambiar un URL slug después de publicar?

Puede hacerlo, pero requiere configurar redirecciones 301 de la URL antigua a la nueva. Sin redirecciones, perderá todos los backlinks y rankings de búsqueda acumulados para la URL antigua. Trate los cambios de slugs en páginas establecidas como una operación SEO deliberada, no una edición rápida.

¿Funcionan los caracteres acentuados como é o ñ en las URLs?

Técnicamente sí — los navegadores modernos los codifican automáticamente — pero en la práctica es mejor eliminarlos o convertirlos. El carácter é se convierte en %C3%A9 en una URL sin procesar, lo que se ve terrible en correos electrónicos y compartidos en redes sociales y puede corromperse en sistemas más antiguos. Convertirlos a equivalentes ASCII simples (e, n) es más limpio y seguro.