Generador de slug URL

¿Qué es un slug de URL?

A slug is the human-readable, URL-safe path segment that identifies a page within a site. It sits at the tail of the URL and replaces what would otherwise be an opaque database identifier with a descriptive token. In https://example.com/blog/2026/my-awesome-post, the slug is my-awesome-post. Mechanically, a slug is the output of a deterministic transformation: take an arbitrary input string, strip everything that isn't allowed in a URL path segment, fold case, replace whitespace with a separator, and emit ASCII. The transformation is one-way in practice, you can't reliably reconstruct "My Awesome Post: Take Two!" from my-awesome-post-take-two: which is why slugs are stored alongside the original title, not in place of it.

Los buenos slugs solo usan letras minúsculas, cifras y guiones. Retiran los acentos, caracteres especiales y espacios superfluos. Eso mejora tanto el SEO como la experiencia de usuario · los motores de búsqueda y las personas pueden leer la URL y entender el contenido de la página.

De dónde viene la palabra, salas de redacción del siglo XIX

La palabra precede a la web en un siglo. En las salas de composición de la era Linotype, cada línea de texto se fundía como una sola tira de metal (un «slug») de unas treinta picas de ancho y un peso aproximado de doce onzas de plomo. El término luego derivó a significar el corto identificador que un editor escribía en la parte superior de una historia para etiquetarla a través de la producción: un handle de una o dos palabras como mayor-budget o school-fire que periodistas, sub-editores e impresores podían usar para referirse a la historia sin escribir el titular completo. Las guías de estilo de AP y de los principales diarios todavía documentan el uso.

Cuando Movable Type, WordPress y los primeros docs de Django adoptaron «slug» como nombre de campo a principios de los 2000, estaban tomando prestado el término de la sala de redacción tal cual. La documentación de Django ha llamado al campo slug al menos desde la versión 0.91 en 2005, con la definición ahora canónica: una etiqueta corta que contiene solo letras, números, underscores o guiones, generalmente usada en URLs. La metáfora encaja precisamente porque tanto el slug fundido en plomo como el slug de URL son tokens cortos, distintos y machine-friendly que apuntan a algo más largo.

RFC 3986 y el conjunto de caracteres no reservados

URL syntax is defined by RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"), published January 2005 by Tim Berners-Lee, Roy Fielding and Larry Masinter, replacing RFCs 2396 and 2732. It is an STD 66 Internet Standard, the IETF's highest maturity tier, reserved for protocols of demonstrated stability and broad implementation. Section 2.3 of RFC 3986 defines the unreserved characters, the only characters that are guaranteed to be safe in any URI component without percent-encoding: A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. That's sixty-six characters total. Everything else is either a reserved character (with structural meaning in some URI component) or "other", anything in the latter group must be percent-encoded if it appears in a URI.

Como el conjunto no reservado es el único garantizado para ir y venir limpiamente a través de cualquier parser de URI jamás escrito, los generadores de slug convergen a un pipeline casi idéntico: pasar a minúsculas los caracteres alfabéticos, mantener los dígitos, mantener los guiones, reemplazar espacios por un único guion, y o eliminar o transliterar todo lo demás. Underscore, punto y tilde están técnicamente permitidos pero convencionalmente evitados en slugs, el punto choca con extensiones de archivo, el tilde se lee como directorio home en convenciones antiguas de URL, y el underscore pierde frente al guion por las razones SEO cubiertas más abajo.

«Cool URIs Don’t Change», Berners-Lee, 1998

La nota de estilo de 1998 de Tim Berners-Lee «Cool URIs Don’t Change», alojada en el sitio del W3C, es la pieza más citada de filosofía de slug jamás escrita. La línea de apertura es famosa: un cool URI es uno que no cambia. La nota luego se lee como una polémica contra los diseños de URL que incorporan detalles de implementación transitorios en el path. Los no-hacer recomendados han moldeado la práctica de slug durante casi treinta años: no pongas extensiones de herramienta de autor en la URL (filtran la implementación y se rompen cuando migras; no pongas estado en la URL) las páginas salen de «actual» pero la URL no debería; no pongas nombres de autores, los autores siguen adelante; no pongas fechas a menos que la fecha sea fundamental al recurso; no pongas IDs de sesión, parámetros de query o estado de login en una URL canónica.

El slug (las palabras descriptivas, semánticas, minúsculas-guiones-palabras) es exactamente lo que está permitido en una URI «cool». Todo lo demás es decoración estructural que no debería sangrar en la dirección. El diseño de permaliks de WordPress, el SlugField de Django y el to_param de Rails internalizan todos esta orientación: emitir una URL que es el significado de la página, no la mecánica de cómo se sirve.

Los guiones ganan a los underscores, y está documentado

En una entrevista de WebmasterWorld de 2005, el ingeniero de Google Matt Cutts dijo que los guiones son tratados como separadores de palabras por el tokenizer de Google, mientras que los underscores son uniones de palabras. Así green-apples se lee como los dos tokens green y apples, mientras que green_apples se lee como el único token green_apples. Para la consulta «green apples», la URL con guiones coincidiría con la verificación de palabra clave del título; la URL con underscores no. Cutts revisó esto en 2007 en su blog y en un vídeo de Google Webmaster Help de 2011 en YouTube («Underscores vs. dashes in URLs»), reafirmando el mismo consejo y notando que Google había evaluado en un momento cambiar el comportamiento del underscore para que también actúe como separador, pero no lo había hecho porque habría roto demasiadas URLs existentes que intencionalmente usaban underscores como uniones (__init__.py, nombres de funciones de programación).

La página actual de Google «URL structure best practices for Google Search» recomienda directamente los guiones: una URL como /green-dress.html es más útil que /greendress.html, y deberías usar guiones en lugar de underscores. La recomendación ha estado documentada continuamente durante más de veinte años. El efecto es pequeño por URL pero se compone a través de un sitio de miles de páginas, y convertir guiones a underscores no tiene ventaja, no hay escenario SEO donde los underscores ganen. Toda guía de slug creíble termina con el mismo consejo: usa guiones.

Normalización Unicode, cómo NFD elimina acentos

El estándar Unicode define dos formas de codificar muchos caracteres acentuados: precompuesto (un único code point, donde é es U+00E9) y descompuesto (una letra base seguida de marcas combinantes, donde é es U+0065 más U+0301, el acento agudo combinante). Visualmente idénticos, byte por byte diferentes. Unicode Technical Standard #15 define cuatro formas de normalización (NFC, NFD, NFKC, NFKD) y para la generación de slug, NFD es la palanca. Si tomas una cadena de entrada, la normalizas a NFD, y luego eliminas todo code point en el rango Unicode U+0300 a U+036F (el bloque Combining Diacritical Marks), recuperas la letra ASCII base. Café se convierte en cafe, naïve en naive, François en Francois, niño en nino, crème brûlée en creme brulee.

NFD no pliega caracteres que no son descomponibles en base+marca. La ß alemana (s aguda) no se descompone en ss bajo NFD, requiere transliteración explícita. La ł polaca (l con barra) no se descompone en l. La ø noruega no se descompone en o. La þ islandesa (thorn) y ð (eth) necesitan tablas de búsqueda. Los navegadores soportan nativamente String.prototype.normalize() desde aproximadamente 2015 (Chrome 34, Firefox 31, Safari 10), por eso incluso pequeñas utilidades JavaScript de slugify pueden hacer el trabajo de eliminar diacríticos sin biblioteca.

La familia de bibliotecas slugify, qué entrega cada ecosistema

django.utils.text.slugify() de Django ha estado en el framework Python desde principios de los 2000. Pasa a minúsculas, elimina caracteres no en [A-Za-z0-9_-], y reemplaza espacios por guiones. Desde Django 1.9 (2015) una palabra clave allow_unicode=True cambia a un modo Unicode-aware que preserva letras no-ASCII. Es la implementación de referencia que todos los demás copian. En Node.js, @sindresorhus/slugify de Sindre Sorhus es el paquete slugify más descargado en npm, con millones de descargas semanales, las características incluyen separadores legibles, reemplazos personalizables (de modo que puedes mapear & a and, @ a at), manejo Unicode y minúsculas locale-aware (I con/sin punto turca, ß → ss alemana). Para usuarios de Python que no usan Django, python-slugify de Val Neekman en PyPI envuelve la biblioteca de transliteración unidecode y añade comportamiento específico de slug: división de palabras por regex, caracteres de reemplazo, longitud máxima, eliminación de stop-words.

Otros ecosistemas siguen el mismo patrón. PHP tiene cocur/slugify de Cocur en Packagist, usado por plugins de Laravel y Symfony, y Symfony mismo entrega un AsciiSlugger en symfony/string desde la versión 5.0. Ruby on Rails usa String#parameterize, incorporado en ActiveSupport al menos desde Rails 1.0; el gem friendly_id superpone seguimiento de historial y manejo de colisiones. Go tiene gosimple/slug con tablas de locale para más de ochenta idiomas. Rust tiene el crate slug. Java tiene Apache Commons Text y slugify-jvm. Lo notable es lo convergente que es la API: cadena de entrada, cadena de slug de salida, con el mismo puñado de opciones, separador, longitud máxima, minúsculas, locale. La herramienta de Absolutool se sienta en la misma familia pero corre enteramente en tu navegador, sin biblioteca que instalar.

WordPress: el 43 % de la web corre este pipeline

WordPress es el mayor sistema individual de emisión de slugs en la web, alimenta aproximadamente el 43 % de todos los sitios web según la encuesta de W3Techs de 2026, así que sus convenciones de slug son efectivamente las convenciones de slug de la web para la mayoría de los lectores. Cuando un post se guarda, WordPress auto-genera el slug desde el título vía sanitize_title() (que llama a sanitize_title_with_dashes() para el caso de reescritura por defecto): minúsculas, elimina HTML, decodifica entidades, reemplaza espacios y la mayoría de la puntuación por guiones, percent-encodea caracteres inseguros, colapsa guiones adyacentes, recorta guiones iniciales/finales. Si el resultado choca con el slug de un post existente, WordPress añade -2, -3, y así sucesivamente. El slug es editable en el editor de post, una vez publicado un post, cambiar el slug rompe todo enlace existente a menos que el editor establezca una redirección. WordPress históricamente no transliteraba los caracteres no-ASCII por defecto; los percent-encodeaba, lo que producía las URLs cirílicas famosamente feas como %D0%BF%D1%80%D0%B8... que plugins como Cyr-To-Lat fueron escritos para arreglar.

Más allá del latín: transliteración para cirílico, CJK, árabe

NFD solo maneja caracteres que se descomponen en base ASCII + marcas combinantes. Para scripts no latinos, el pipeline de slug necesita transliteración: un mapeo de cada carácter no latino a su equivalente en script latino. La biblioteca canónica de Python es unidecode, originalmente un port del Text::Unidecode Perl de Sean M. Burke de 2001, que mapea prácticamente todo carácter del Basic Multilingual Plane a una cadena ASCII de «mejor suposición»: Москва → Moskva, Αθήνα → Athena. El fallback CJK es la parte controvertida: unidecode usa pinyin mandarín para todos los caracteres CJK porque el chino tiene la mayor cobertura de caracteres CJK, lo que produce romanizaciones sin sentido para japonés (東京 → Dong Jing en pinyin, no Tokyo). Herramientas específicas para japonés como pykakasi hacen el trabajo de convertir kanji + kana en rōmaji apropiado. La biblioteca International Components for Unicode (ICU), mantenida por el Unicode Consortium e IBM, proporciona una API Transliterator con conjuntos de reglas nombrados como Russian-Latin/BGN, Greek-Latin/UNGEGN y Han-Latin que implementan estándares oficiales de romanización. La herramienta de Absolutool se sienta en el extremo más ligero: pliega diacríticos latinos vía NFD y descarta todo lo demás. Un usuario que quiera un título ruso o chino en slug puede correr un paso separado de transliteración antes de pegar el texto.

Límites de longitud de URL, de dónde viene la regla de los 2.000 caracteres

No hay límite de longitud especificado por el RFC 3986 mismo, la sintaxis URI es no acotada. Cada límite es práctico. Internet Explorer históricamente capó las URLs en 2.083 caracteres (un límite duro horneado en el motor Trident), que es el origen de la ampliamente citada regla empírica de los «2.000 caracteres». Chrome, Firefox, Safari y Edge moderno soportan URLs de hasta aproximadamente 64.000 a 100.000+ caracteres en la barra de direcciones. LimitRequestLine de Apache vale por defecto 8.190 bytes para toda la línea de petición; large_client_header_buffers de nginx vale por defecto 8 KB; IIS vale por defecto 4.096 bytes para la URL y 2.048 para la query string. RFC 9110 (HTTP/1.1, 2022) recomienda en §4.1 que un servidor «ought to be capable of handling URIs of length 8.000 octets or longer» pero no llega a imponer un límite superior. Para los slugs, lo que importa es que son convencionalmente cortos (tres a siete palabras, treinta a sesenta caracteres) para SEO y compartibilidad. John Mueller de Google ha dicho en múltiples Webmaster Hangouts que la longitud de URL en sí no es una señal de ranking, pero las URLs largas pueden ser truncadas en snippets de resultados de búsqueda, perjudicar el CTR, y verse poco profesionales en compartidos sociales. La mayoría de generadores de slug exponen una opción de longitud máxima por esta razón; este por defecto vale ilimitado y te deja establecer un tope.

Eliminación de stop-words: denso vs gramatical

Muchas bibliotecas slugify ofrecen eliminación opcional de stop-words, abandonar palabras cortas comunes (a, an, the, of, is, and, or, to, in, for, on) antes de ensamblar el slug. La razón es que no añaden señal SEO y rellenan la URL. Así «The Best Way to Make a Cup of Tea» se convierte en best-way-make-cup-tea (5 tokens, 24 caracteres) en lugar de the-best-way-to-make-a-cup-of-tea (10 tokens, 35 caracteres). El compromiso: más corto y denso, pero con colapso gramatical ocasional (how-to-be-good reducido a how-good pierde significado) y riesgo de eliminar palabras que en realidad llevan intención (art-of-war reducido a art-war). WordPress no elimina stop-words por defecto (es un comportamiento de plugin opt-in) y la mayoría de generadores de slug modernos lo dejan desactivado por defecto y lo exponen como una casilla. Yoast SEO para WordPress marca un slug con stop-words como recomendación menor más que como error. Este generador no elimina stop-words automáticamente, sobre la base de que el editor conoce mejor la intención del título que una lista estática de palabras. Si los quieres fuera, edita la salida directamente.

Colisiones de slug: qué hacen los CMS cuando dos posts comparten título

Cuando dos posts auto-generan el mismo slug, «My Post» y «My-Post!» ambos producen my-post: el sistema tiene que resolver el conflicto. Las estrategias más comunes: un sufijo numérico (my-post-2, my-post-3) (predecible, nunca colisiona, pero el sufijo no carga diferencia semántica; un prefijo de fecha (2026-04-27/my-post)) funciona bien para contenido de blog y es el por defecto en Jekyll, Hugo y la mayoría de sitios de noticias; un sufijo de autor (my-post-jane) (usado por Medium y blogs multi-autor; un sufijo de hash aleatorio (my-post-a3f9)) usado por Stack Overflow, Notion y sistemas de shortlinking, intercambiando legibilidad humana por unicidad garantizada; o edición manual al publicar, editorialmente limpio pero rara vez el por defecto porque interrumpe el flujo. La elección pragmática para la mayoría de CMSes es el sufijo numérico con edición manual como escapatoria. Los permaliks con prefijo de fecha son populares para contenido anclado en el tiempo donde la fecha es información significativa.

Impacto SEO: el slug como señal menor pero visible

La documentación de ranking de Google lista la estructura de URL como una señal de ranking menor, el contenido de página, backlinks, señales de engagement de usuario y frescura todos cargan más peso. Pero las palabras de URL contribuyen, y contribuyen visiblemente. Los términos de slug aparecen en la línea de URL del snippet SERP debajo del título, lo que influye en el CTR incluso cuando el slug en sí no está rankeado. Los términos de slug pueden aparecer en negrita en la SERP si coinciden con la consulta del usuario, peso visual extra. El texto de ancla de enlaces internos y externos a menudo vale por defecto la URL cuando no se proporciona texto de enlace, así que un slug semántico se convierte en el texto de enlace y lleva sus palabras clave a través de la equidad de enlace entrante. Las pruebas A/B en editores muestran consistentemente que los slugs descriptivos aumentan el CTR en porcentajes de un dígito sobre IDs opacos. El estudio de factores de ranking 2020 de Backlinko (1,18 millones de SERPs analizadas) encontró que las URLs cortas superaban ligeramente a las largas en lo alto de las SERPs.

Hay una excepción a la intuición «más palabras clave = mejor»: el atiborramiento de palabras clave. La actualización Exact-Match Domain (EMD) de septiembre de 2012 redujo específicamente el crédito para dominios y slugs exact-match de baja calidad (cheap-life-insurance.com/buy-cheap-life-insurance), y Google ha continuado descontando el atiborramiento de palabras clave en URLs desde entonces. La conclusión 2026: la presencia de palabras clave en el slug ayuda modestamente; el atiborramiento de palabras clave perjudica. La mayor ganancia SEO de un slug es no cambiarlo después de publicar. Los enlaces entrantes se acumulan a una URL. La autoridad de página se compone al nivel de URL. Una redirección 301 preserva la mayoría pero no toda la equidad de enlace, y solo si el editor realmente establece la redirección, muchos no. El consejo «Cool URIs Don’t Change» de Berners-Lee tiene consecuencias SEO directas: cada cambio de slug, incluso con una redirección, cuesta una pequeña cantidad de autoridad que toma tiempo recuperar.

Buenas prácticas SEO para los slugs

• Mantén los slugs cortos (3-5 palabras es lo ideal)
• Integra las palabras clave objetivo
• Usa guiones, no guiones bajos (Google trata los guiones como separadores de palabras)
• Retira las palabras vacías (el, la, es, y, etc.) cuando no aportan nada
• Usa únicamente letras minúsculas
• Evita cambiar los slugs tras la publicación (o pon redirecciones)
• Elimina o translitera caracteres no-ASCII a menos que tu plataforma maneje IRIs limpiamente a través de analytics, compartidos sociales y clientes de email.
• Evita fechas a menos que la fecha sea fundamental al recurso; evita extensiones de archivo, IDs de sesión, nombres de autores y palabras de estado.

Preguntas frecuentes

¿Admite los caracteres acentuados?

Sí. El generador usa la normalización Unicode (NFD) para retirar los acentos. Por ejemplo, «cafe» sigue siendo «cafe» mientras que «café» también se vuelve «cafe». Eso garantiza slugs limpios, en ASCII puro.

¿Hay que usar guiones o guiones bajos?

Los guiones son los recomendados para el SEO. La documentación oficial de Google confirma que los guiones en las URL se tratan como separadores de palabras, mientras que los guiones bajos no. Así, «mi-articulo» se lee como dos palabras, mientras que «mi_articulo» solo forma una.

¿Qué pasa con los emoji y símbolos?

Los emoji no están en el conjunto de caracteres no reservados de URL, y NFD no los descompone, no tienen equivalente latino. Este generador los descarta. Otras herramientas percent-encodean los emoji (convirtiendo un solo carácter en una cadena larga como %F0%9F%94%A5), lo que técnicamente funciona en navegadores modernos pero produce URLs ilegibles en analytics, compartidos sociales y previews de email. La mayoría de guías de slug recomiendan eliminar emoji enteramente; si quieres preservarlos, percent-encodéalos antes del paso de slug.

¿Esto generará slugs de títulos rusos, chinos o árabes?

No por sí solo. NFD solo pliega caracteres acentuados de script latino; no puede transliterar scripts cirílico, griego, árabe, hebreo o CJK a latino. Pegar un título ruso o chino en esta herramienta descartará esos caracteres y producirá un slug vacío o casi vacío. El flujo correcto es correr un paso de transliteración primero (unidecode de Python, el paquete npm transliteration de JavaScript, o las convenciones de romanización de Wikipedia) y pegar el resultado romanizado aquí. Para japonés específicamente, usa una herramienta kana-aware como pykakasi: los transliteradores CJK genéricos aplican pinyin mandarín y producen Dong Jing para 東京 en lugar de Tokyo.

¿Y si necesito cambiar un slug después de publicar?

Establece una redirección 301 desde la URL antigua a la nueva antes de cambiar el slug. Un 301 («Moved Permanently») preserva la mayor parte de la equidad de enlace que se ha acumulado a la URL antigua y le dice a crawlers y navegadores que actualicen sus marcadores. Sin redirección, todo enlace entrante existente se rompe y pierdes la autoridad de página que esos enlaces representaban. Incluso con una redirección, pierdes una pequeña cantidad de equidad que toma semanas o meses recuperar. La máxima de Berners-Lee (cool URIs don’t change) es en parte estética, en parte una verdad SEO: cada cambio de slug cuesta algo, así que vale la pena hacer el slug bien la primera vez.

¿Hay una longitud de slug recomendada?

La convención es de tres a siete palabras, aproximadamente treinta a sesenta caracteres. Lo suficiente para ser descriptivo, lo suficientemente corto para que el snippet SERP de Google no lo trunque y los humanos puedan captar el tema de un vistazo. No hay máximo técnico duro (RFC 3986 no especifica uno y los navegadores modernos manejan URLs de decenas de miles de caracteres) pero Apache, nginx e IIS imponen topes prácticos en el rango de kilobytes, y la regla heredada de los «2.000 caracteres» de Internet Explorer todavía se cita como techo cross-platform seguro. La opción Longitud Máxima aquí te permite topar la salida; ponerla a 0 significa ilimitada.

¿Mis textos se almacenan o envían a algún sitio?

No. La transformación corre enteramente en tu navegador usando el método incorporado String.prototype.normalize() de JavaScript (soportado desde Chrome 34, Firefox 31, Safari 10, aproximadamente 2015). Nada se sube, ninguna API se llama, no se escriben logs. Puedes verificar esto abriendo la pestaña Network de DevTools de tu navegador mientras generas slugs, no hay peticiones salientes. La página es segura para slugs derivados de títulos no publicados, documentación interna, posts borrador o cualquier otro contenido que no quieras que salga de tu dispositivo.

Herramientas relacionadas