Jerarquía


Una URL no es solo una dirección técnica. Es la representación pública y permanente de la arquitectura de la información de un sitio web. Cuando alguien lee https://www.arquitecturadelainformacion.es/formacion/cursos/taxonomias/, entiende sin abrir la página que está ante un curso sobre taxonomías dentro de una sección de formación. Eso es la jerarquía de URLs funcionando correctamente.


Qué es la jerarquía de URLs

La jerarquía de URLs es la estructura de segmentos de ruta que refleja la organización del contenido del sitio. Cada segmento separado por / representa un nivel en esa jerarquía:

https://www.arquitecturadelainformacion.es/urls/jerarquia/
│                                           │    │
│                                           │    └── Nivel 2: artículo específico
│                                           └──── Nivel 1: sección temática
└──────────────────────────────────────────────── Raíz: dominio

La jerarquía de URLs debe ser coherente con la jerarquía de navegación del sitio. Si el menú principal tiene una sección “URLs” y dentro hay un artículo sobre jerarquía, la URL debe ser /urls/jerarquia/. No /jerarquia/, no /articulos/jerarquia-de-urls/, no /urls/2024/jerarquia/.


Principios de diseño de la jerarquía de URLs

1. La URL debe reflejar la estructura, no el sistema de gestión

Un error frecuente en WordPress es dejar la estructura de URLs por defecto, que en muchas instalaciones es /?p=123. Eso no es una URL, es un identificador de base de datos. La estructura de URLs debe diseñarse antes de publicar el primer contenido y debe reflejar la organización del sitio, no los internos del CMS.

2. Cada segmento debe tener significado

En /formacion/cursos/taxonomias-en-wordpress/:

  • formacion — sección principal
  • cursos — tipo de contenido dentro de la sección
  • taxonomias-en-wordpress — el contenido específico

Cada segmento aporta contexto. Si un segmento no aporta nada (/contenidos/paginas/articulos/texto/), sobra.

3. La profundidad debe ser limitada

La profundidad óptima para la mayoría de sitios es de dos a tres niveles. Cuatro niveles es el máximo razonable. A partir del quinto segmento, la URL se vuelve difícil de leer, difícil de recordar y difícil de enlazar.

ProfundidadEjemploValoración
1 nivel/taxonomias/Correcto para secciones principales
2 niveles/glosario/taxonomia/Óptimo para la mayoría de contenidos
3 niveles/formacion/cursos/taxonomias/Aceptable con jerarquía bien justificada
4 niveles/formacion/cursos/nivel-avanzado/taxonomias/Límite razonable
5+ niveles/formacion/cursos/nivel-avanzado/modulo-3/taxonomias/Evitar si es posible

4. La URL debe ser estable

Una URL publicada no debería cambiar nunca. Si cambia, debe existir una redirección 301 permanente desde la URL antigua hasta la nueva. Esta estabilidad no es solo una buena práctica: es un compromiso con los usuarios que han enlazado, compartido o guardado esa dirección.

5. La URL no debe depender de datos mutables

La fecha de publicación cambia de relevancia con el tiempo. El nombre de una categoría puede modificarse. El autor puede cambiar. Ninguno de estos datos debe formar parte de la estructura de URLs permanente.

Lo que sí puede usarse: el tipo de contenido (/productos//cursos//eventos/) porque raramente cambia y aporta contexto duradero.


Patrones de URL por tipo de contenido

Páginas estáticas

/sobre-nosotros/
/contacto/
/legal/privacidad/
/legal/cookies/

Las páginas estáticas viven en la raíz o en un máximo de un nivel de profundidad. Rara vez necesitan más.

Artículos de blog

/blog/nombre-del-articulo/

El prefijo /blog/ es opcional si el blog es el contenido principal del sitio. Si el blog coexiste con otros tipos de contenido, el prefijo evita colisiones y deja claro el tipo.

/nombre-del-articulo/          ← sin prefijo, si el blog es el sitio
/blog/nombre-del-articulo/     ← con prefijo, si hay otros tipos de contenido

Lo que no debe aparecer en la URL del artículo:

  • La fecha: /blog/2024/03/nombre/ envejece el contenido visualmente y complica las redirecciones cuando se actualiza un artículo antiguo.
  • La categoría: /blog/categoria/nombre/ obliga a gestionar redirecciones si el artículo cambia de categoría.
  • El ID numérico: /blog/1234/nombre/ no aporta información al usuario.

Productos

/productos/nombre-del-producto/
/tienda/categoria/nombre-del-producto/

La segunda opción incluye la categoría en la URL. Es válida si la categoría del producto es estable y forma parte de la identidad del producto. Si los productos cambian de categoría con frecuencia, mejor la primera opción.

Cursos y formación

/formacion/nombre-del-curso/
/formacion/nombre-del-curso/modulo-1/
/formacion/nombre-del-curso/modulo-1/leccion-2/

La ficha del curso es pública. El contenido interno (módulos y lecciones) puede ser privado pero debe tener URLs estables y coherentes.

Glosario

/glosario/nombre-del-termino/

El glosario es una colección plana. No necesita jerarquía interna: /glosario/taxonomia/, no /glosario/terminos/avanzados/taxonomia/.

Documentación técnica

/documentacion/nombre-del-componente/
/docs/nombre-del-componente/

Si hay versionado explícito:

/documentacion/v2/nombre-del-componente/

Solo añadir el número de versión si la documentación de versiones anteriores debe mantenerse accesible. Si solo existe la versión actual, el versionado en la URL añade complejidad sin beneficio.


La URL como contrato

Publicar una URL es hacer un contrato implícito con quien la visita, la enlaza o la guarda. Ese contrato dice: “esta dirección siempre apuntará a este contenido”. Romper ese contrato con redirecciones frecuentes, cambios de estructura o eliminaciones sin redirección es uno de los errores más costosos en la gestión de un sitio web a largo plazo.

Tim Berners-Lee, inventor de la web, lo formuló en 1998 en su artículo Cool URIs don’t change: una URI bien diseñada no debería cambiar nunca. Ese principio sigue siendo tan válido hoy como entonces.


Para profundizar