Optimizar las rutas de una aplicación Angular es uno de los pasos más importantes para mejorar el posicionamiento en motores de búsqueda. Aquí aprenderás a transformar URLs basadas en IDs en slugs legibles, una práctica clave para SEO que prepara tu aplicación para aprovechar al máximo Server-Side Rendering.

Por qué Angular necesita URLs amigables para SEO

Durante mucho tiempo Angular se asoció con dashboards y aplicaciones administrativas llenas de formularios y gráficas. Hoy, gracias a mejoras como Server-Side Rendering, también es una opción sólida para sitios públicos como un e-commerce, un buscador o un formulario abierto al público.

Y ahí es donde entra el detalle de las rutas. Si navegas por Platzi sin login, vas a notar que las URLs no usan identificadores numéricos, sino palabras descriptivas: platzi.com/escuela/datos, cursos/nombre-del-curso. Eso es un slug: una cadena única que describe el contenido y le dice algo a Google sobre lo que vive en esa página [00:34].

¿Qué es un slug en una URL? Es un identificador único en formato de texto legible que reemplaza al ID numérico. Por ejemplo, clothes en lugar de ?categoryId=2. Funciona igual que un ID (debe ser único), pero comunica significado tanto al usuario como al motor de búsqueda.

Cómo transformar la ruta de categorías a slug en Angular

La ruta de categorías original no existía como tal: el componente raíz renderizaba un ListComponent y filtraba productos a través de un query param opcional llamado category_id [03:45]. Esa URL funciona, pero no es amigable.

La solución es crear una nueva ruta reutilizando el mismo componente:

• Copia el path existente y define la nueva ruta como category/:slug.
• Mantén el input del componente como opcional, porque el mismo ListComponent se reutiliza en distintos contextos.
• Cambia el nombre del parámetro de categoryId a slug dentro del componente.

Así, cuando alguien entra a /category/clothes, Angular lee el slug desde la ruta en lugar de un query param numérico.

Cómo ajustar el servicio getProducts para filtrar por slug

El siguiente paso ocurre en la capa de servicios. El método getProducts debe aceptar tanto categoryId como categorySlug, ambos opcionales [06:18].

• Si llega categoryId, se envía como query param a la API.
• Si llega categorySlug, se envía también como query param con su nombre correspondiente.
• Si ninguno llega, simplemente no se incluye en la petición.

Esto depende de cómo esté diseñada tu API. En el caso de la API de Platzi, el endpoint de productos acepta ambos parámetros, así que puedes filtrar por cualquiera de los dos sin romper la lógica existente.

typescript getProducts(params?: { category_id?: string; category_slug?: string }) { // construye dinámicamente los query params // según cuál venga definido }

Cómo actualizar los enlaces del listado de categorías

Falta un detalle: los enlaces del menú todavía apuntaban al formato viejo con query param. Si haces clic, no pasa nada, porque el componente ya no escucha ese parámetro [08:52].

La corrección está en la plantilla del listado:

• Cambia el routerLink de ?categoryId= a /category/{{category.slug}}.
• Asegúrate de que cada objeto categoría tenga el atributo slug, que la API ya entrega junto al id, name e image.

Al probarlo, la petición sale como products?category_slug=clothes y la URL del navegador queda como /category/clothes. Limpia, descriptiva y lista para indexar.

Qué retos aplicar al detalle de producto

Las categorías ya tienen URLs amigables, pero el detalle del producto sigue navegando con el ID: /product/1. El reto es replicar la misma lógica.

¿Cómo aplicar slug a la ruta de un producto? Cambia :id por :slug en la configuración del router, ajusta el servicio para consultar el producto por slug en lugar de ID y usa product.slug en los routerLink del listado.

Los pasos concretos son:

1. Modificar la ruta del producto para recibir :slug.
2. Revisar la documentación de la API y encontrar el método de consulta por slug.
3. Reemplazar product.id por product.slug en los enlaces del listado.

Recuerda que el atributo slug ya viene en cada producto que devuelve la API, igual que ocurre con las categorías.

Por qué los slugs funcionan como identificadores únicos

Un slug no es solo decoración. Cumple la misma función que un ID: identifica de forma única un recurso. No pueden existir dos cursos ni dos productos con el mismo slug, porque colisionarían en el routing [02:30].

La diferencia con un ID numérico es que el slug aporta contexto semántico. Para un buscador, cursos/angular-avanzado comunica muchísimo más que cursos/4821. Y cuando combines esto con Server-Side Rendering, los beneficios para SEO se multiplican, porque el HTML que reciben los crawlers ya viene con URLs descriptivas y contenido renderizado.

¿Cómo vas a estructurar los slugs en tu propia aplicación? Cuéntame en los comentarios qué patrón usas para mantenerlos únicos.