SEO on-page
Capítulo 05 / 08
Estructura de URL
Las URLs son una señal de ranking pequeña y una señal de UX grande. El slug que defines hoy decide si en dos años puedes refactorizar el sitio limpio o si cada cambio se convierte en un campo minado de redirecciones.

Las URLs son las direcciones de la web. Aparecen en la barra del navegador, en los enlaces que se comparten, en las SERPs, en las citas de los motores de IA y en cada enlace interno de tu sitio. Una estructura de URL limpia es una señal de ranking pequeña pero real, una señal de UX significativa y una decisión de arquitectura fundacional que se vuelve más difícil de cambiar cuanto más esperes. Aciértale en el lanzamiento y el costo de crecer es bajo. Equivócate y te pasas años desenredándola.
“La URL es la única pieza de metadata de tu página que está en la barra de direcciones, en la SERP, en el preview al compartir y en la cita. Tratarla como cosmética es uno de los errores más caros que un sitio comete al principio.”
Qué hace bueno a un slug
Un buen slug es corto, descriptivo, en minúsculas, en kebab-case y coincide con la keyword principal de la página. Cinco atributos:
- Corto. Lo ideal son 3–5 palabras. A partir de 6, el slug empieza a truncarse en algunas superficies y suma ruido sin sumar señal.
- Descriptivo. El slug debe permitirle a una persona que solo lee la URL adivinar qué hay en la página.
- En minúsculas. Los servidores case-sensitive tratan /Title-Tags y /title-tags como URLs distintas. Las minúsculas en todo el sitio previenen duplicados accidentales.
- Kebab-case. Palabras separadas por guiones (
title-tags), no por guion bajo (title_tags) ni concatenadas (titletags). El guion es el único separador que los motores de búsqueda tratan de forma confiable como límite de palabra. - Alineado a la keyword. El slug debe contener la keyword principal palabra por palabra, según la regla H1 = URL = Title.
Kebab-case vs underscore vs camelCase
| Formato | Ejemplo | Veredicto |
|---|---|---|
| kebab-case (guion) | /title-tags | Correcto. Los motores tratan los guiones como límites de palabra. |
| snake_case (guion bajo) | /title_tags | Evítalo. El guion bajo une las palabras para los motores y perjudica el reconocimiento de la keyword. |
| camelCase | /titleTags | Evítalo. Mezcla mayúsculas y minúsculas, es frágil en servidores case-sensitive y se lee peor. |
| concatenado | /titletags | Evítalo. Los motores no parten palabras unidas de forma confiable. |
| espacios (encoded) | /title%20tags | Nunca. Los espacios encoded se ven rotos al compartir y en las citas. |
Rutas jerárquicas vs URLs planas
Dos patrones compiten: jerárquico (/seo/on-page/title-tags) y plano (/title-tags). Los dos pueden funcionar; la elección correcta depende del tamaño y de la estructura del contenido.
Usa jerarquía cuando:
- Tienes varios clusters temáticos (SEO, CRO, paid) y quieres que la URL refleje a qué cluster pertenece la página.
- Tienes tantos artículos que las URLs planas se vuelven difíciles de manejar.
- La jerarquía refuerza la estructura de enlaces internos (pillar en la ruta padre, clusters por debajo).
- A los usuarios les sirve poder recortar el slug y aterrizar en un índice padre (
/seo/on-page/como página real).
Usa URLs planas cuando:
- El sitio es chico y el cluster es implícito, no visible.
- Esperas refactorizar temas con frecuencia y no quieres comprometer la URL con una jerarquía.
- El slug plano es bastante más corto y el nombre del cluster no aporta valor de UX.
El error son las URLs planas que imitan jerarquía con prefijos (/seo-title-tags) o las jerarquías tan profundas que nadie las construiría a mano (/blog/categoria/sub-categoria/2026/04/title-tags). Lo primero desperdicia el slug; lo segundo es inmanejable.
Longitud: más corto casi siempre es mejor
Las URLs más cortas posicionan algo mejor, reciben más clics en SERPs y se comparten con más facilidad. Los estudios de los top-10 de SERP muestran una correlación pequeña pero consistente: las URLs más cortas ocupan posiciones más altas en promedio. La causalidad está en discusión; el consejo práctico es inequívoco: apunta a menos de 60 caracteres totales de URL cuando puedas, y menos de 100 sin duda.
La regla H1 = URL = Title aplicada a slugs
En cualquier página que apunta a una sola keyword principal, tres elementos estructurales deben coincidir: el H1, el slug de la URL y el title tag. El slug lleva la keyword en kebab-case; el H1 y el title tag la llevan en prosa natural. Mismas palabras en el mismo orden, distinto formato:
- Slug de URL:
/title-tags - H1:
Etiquetas de título - Title tag:
Etiquetas de título
El slug no debe incluir palabras de relleno (a, the, of, for, los, las, de, para) a menos que formen parte de la formulación canónica de la keyword. “/los-mejores-title-tags-de-2026” está inflado. “/title-tags” es correcto.
Estructura de URL multi-locale
Los sitios multi-locale necesitan un patrón de URL que le señale el locale tanto a los rastreadores como a los usuarios. Tres patrones válidos:
| Patrón | Ejemplo | Cuándo usarlo |
|---|---|---|
| Subdirectorio | /es-mx/seo/title-tags | Por default: el más fácil de manejar, autoridad concentrada en un dominio, hreflang directo |
| Subdominio | es-mx.example.com/seo/title-tags | Úsalo solo cuando los locales los manejan equipos distintos con stacks distintos |
| ccTLD | example.com.mx/seo/title-tags | Señal local más fuerte, pero fragmenta la autoridad de dominio entre TLDs |
Para la mayoría de los sitios multi-locale, los subdirectorios son la respuesta correcta. La ruta de locale (/es-mx/) antecede al slug, el slug en sí va en el idioma del locale para lenguas romances/germánicas, y el hreflang une los locales (según etiquetas canonical).
Slug localizado vs slug en inglés
Para español, francés, alemán y similares, el slug debe ir en el idioma del locale: /es-mx/seo/estructura-de-url, no /es-mx/seo/url-structure. La excepción son los términos estándar de la industria en inglés que la audiencia localizada de hecho busca en inglés (title tag, meta description, anchor text, snippet, SEO). En esos casos, dejar el slug en inglés dentro de es-MX es correcto porque coincide con la keyword que la audiencia teclea.
EN y en-AU (o cualquier par de variantes en inglés) comparten el mismo slug porque las keywords son idénticas.
Slash final vs sin slash final
Elige uno y mantenlo en todo el sitio. Tanto /title-tags/ como /title-tags funcionan; mezclarlos crea duplicados que necesitan canonical o 301 para consolidarse. La mayoría de los frameworks modernos resuelven la redirección de forma automática, pero la elección debe ser explícita al lanzar y consistente en cada enlace interno.
La regla de redirección al cambiar URLs
No cambies URLs a la ligera. Cuando tengas que hacerlo:
- Redirección 301 de la URL vieja a la nueva. Conserva casi toda la autoridad. Permanente (301), no temporal (302).
- Actualiza cada enlace interno a la URL nueva. No te apoyes en la redirección: cada redirección pierde una fracción de autoridad y ralentiza la página.
- Actualiza el sitemap. Quita la URL vieja, agrega la nueva.
- Actualiza la canonical de la URL nueva para que apunte a sí misma.
- Monitorea Search Console por reportes de “Página con redirección” y errores de rastreo durante los siguientes 30 días.
- Sin cadenas de redirección. Si antes la URL A redirigía a B y ahora B se va a C, actualiza la redirección de A para que apunte directo a C. Las cadenas pierden más autoridad y ralentizan el rastreo.
Parámetros de query y desperdicio de rastreo
Los parámetros de query (?utm_source=..., ?sort=price, ?ref=...) crean variantes de URL que los rastreadores pueden tratar como páginas separadas. Tres reglas:
- Auto-canonical hacia la versión sin parámetros. Cada URL con parámetros apunta canonical a la URL limpia.
- Evita armar la navegación del sitio sobre parámetros. Los filtros, los ordenamientos y la paginación deberían usar rutas limpias cuando sea posible.
- Bloquea del índice los parámetros ruidosos conocidos por robots.txt o meta robots cuando generan combinaciones infinitas.
Cómo leen los motores de IA los slugs de URL
Los motores de respuesta con IA leen el slug como una de las señales temáticas más fuertes en tiempo de retrieval. Tres observaciones:
- El slug se lee antes que el cuerpo. Cuando el motor decide qué páginas recuperar para una consulta, lo primero que escanea es slug + title + meta. Un slug limpio acelera el retrieval; un slug sin sentido (
/p/12345) lo retrasa. - El slug es parte de la cita. Cuando ChatGPT o Perplexity citan tu página, la URL queda a la vista del usuario.
/seo/title-tagsse ve creíble./blog/post?id=4519se ve transaccional. - El slug refuerza la agrupación temática. El motor agrupa las páginas bajo
/seo/on-page/con más confianza que un conjunto de URLs planas dispersas sobre el mismo tema.
Errores comunes en estructura de URL
- Incluir la fecha en la URL.
/2024/04/title-tagsenvejece tu contenido a la vista y obliga a redirigir cada vez que lo actualizas. - Incluir la categoría en la URL cuando las categorías cambian. En cuanto un contenido se mueve entre categorías, la URL queda mal y te enfrentas a una redirección o a una mentira.
- Slugs autogenerados a partir del título. Muchos CMS toman el H1 palabra por palabra por default, lo que produce slugs como
/la-guia-2026-para-escribir-mejores-title-tags. Edita el slug al publicar. - IDs numéricos.
/p/12345es invisible para humanos y motores de IA. Usa slugs descriptivos incluso en páginas de producto. - Mayúsculas aleatorias.
/Title-Tagsfunciona solo en servidores case-insensitive y se rompe en los case-sensitive. Minúsculas en todo el sitio. - Espacios, acentos, caracteres especiales. Encoded como
%20,%C3%A9, etc., se rompen al compartir y se ven rotos en las citas. - Stop words sin valor. Quita “el”, “la”, “de”, “para” a menos que sean esenciales para la keyword.
El veredicto
La estructura de URL es una decisión de lanzamiento que se convierte en pasivo de mantenimiento si te equivocas. Usa kebab-case, minúsculas y slugs cortos alineados a la keyword. Elige jerárquico o plano de forma consistente. Define el comportamiento del slash final al lanzar. Localiza los slugs al idioma de búsqueda real de la audiencia. 301-redirige con disciplina cuando las URLs sí cambien. Bloquea los parámetros ruidosos para que no creen duplicados en el índice. Aciértale a esto y el slug se convierte en una señal silenciosa de ranking que compone con los años; equivócate y te pasas esos mismos años explicando por qué la migración está tardando tanto.
Preguntas frecuentes
Preguntas frecuentes
Respuestas rápidas a lo que nos preguntan antes de cada prueba.
Solo cuando tengas una razón real: reestructurar el sitio, corregir una errata que rompe la comprensión, consolidar contenido duplicado. No cambies URLs para perseguir variaciones de keyword ni porque el slug nuevo ‘suena mejor’. Cada cambio de URL exige una 301 desde la URL vieja, pierde una fracción pequeña de autoridad durante la transferencia y arriesga romper backlinks externos si esos sitios no actualizan. El costo casi siempre supera al beneficio cosmético.
En este clúster