La estructura del catálogo es la arquitectura de datos que decide cómo se organizan los productos para la navegación, el merchandising, los menús, las páginas de destino y el descubrimiento por parte del cliente. Un producto puede existir correctamente en el sistema administrativo y seguir siendo difícil de encontrar si su relación con categorías, pertenencia a colecciones, ruta de menú, posición de ordenación o contexto de página de destino no se representa correctamente.
En una tienda de comercio electrónico, la organización del catálogo no siempre es un simple árbol de categorías. Una plataforma puede utilizar categorías anidadas con relaciones padre-hijo. Otra puede depender de colecciones manuales o automáticas, etiquetas de producto, campos de taxonomía, enlaces de menú, product types, páginas de destino creadas con constructores de páginas o reglas de merchandising basadas en búsqueda. Dos tiendas pueden parecer muy similares para el cliente y utilizar modelos de datos muy diferentes en segundo plano.
Por ello, una revisión técnica de la estructura del catálogo debe separar varias capas: el objeto de agrupación subyacente, la relación entre productos y grupos, la ruta de navegación utilizada por los clientes, el contenido asociado a páginas de categoría o colección, las reglas que controlan la inclusión de productos y la lógica de visualización que decide qué aparece primero.
Qué representa la estructura del catálogo en una tienda de comercio electrónico
La estructura del catálogo define cómo se organizan los productos en recorridos de navegación con significado. Ayuda al cliente a pasar de una intención general a productos concretos, por ejemplo Women > Shoes > Running Shoes, Electronics > Laptops > Gaming Laptops o Replacement Parts > Refrigerator Parts > Water Filters.
La estructura suele servir para mucho más que la navegación. Puede afectar a páginas de destino de categorías, migas de pan, enlaces internos, páginas de entrada SEO, productos destacados, reglas de merchandising, descubrimiento, clasificación para marketplaces, informes y mantenimiento administrativo del catálogo.
Una estructura de catálogo puede incluir varios objetos de datos y capas de presentación:
| Componente del catálogo | Qué representa | Funcionamiento afectado |
|---|---|---|
| Categoría o colección | Agrupación de productos utilizada para navegar o hacer merchandising | Páginas de categoría, listados de productos, filtros y descubrimiento |
| Jerarquía padre-hijo | Relación entre grupos amplios y más específicos | Profundidad de menú, migas de pan, recorridos de navegación y estructura de URL |
| Asignación de producto | Enlace entre productos y una categoría o colección | Visibilidad de productos dentro de páginas de navegación |
| Elemento de menú | Enlace de navegación hacia categoría, colección, página o URL externa | Cómo llegan los clientes a las páginas del catálogo |
| Ruta de migas de pan | Recorrido o jerarquía mostrada al cliente | Orientación, enlazado interno y confianza en la navegación |
| Contenido de categoría | Texto, imágenes, banners, metadatos, bloques o contenido de página de destino | SEO, merchandising y explicación de la categoría |
| Reglas de ordenación y visualización | Orden manual, orden predeterminado, posiciones destacadas o ranking algorítmico | Qué productos ve primero el cliente |
| Regla de inclusión dinámica | Condiciones que incorporan productos automáticamente a un grupo | Collections automáticas, categorías inteligentes, grupos estacionales y mantenimiento operativo |
Estas capas pueden estar fuertemente conectadas en una plataforma y separadas en otra. Esa diferencia es una de las principales razones por las que una migración de catálogo no puede evaluarse únicamente contando categorías.
Estructura de datos y relaciones habituales
Una categoría, colección o grupo de catálogo suele tener un registro propio. Ese registro puede almacenar ID interno, nombre, slug, referencia al padre, ruta, estado, orden, descripción, imagen, campos SEO, configuraciones de visualización, reglas de asignación de productos y indicadores de visibilidad.
Una estructura habitual puede incluir:
| Campo de datos | Función típica | Por qué importa |
|---|---|---|
| ID interno | Identificador estable del sistema | Mantiene conectadas las asignaciones y referencias |
| Nombre | Etiqueta visible en administración o para clientes | Controla visualización, menús y reconocimiento interno |
| Slug o handle | Identificador apto para URL | Afecta URL de páginas y referencias desde menús o enlaces |
| ID del padre | Define la categoría superior | Crea jerarquía y profundidad de navegación |
| Ruta o nivel | Guarda la posición completa dentro de la jerarquía | Ayuda a migas de pan, ordenación y menús anidados |
| Estado o visibilidad | Activa, desactiva, oculta o publica el grupo | Determina si el cliente puede acceder a la página |
| Posición | Controla el orden del grupo o de productos | Afecta navegación y prioridades de merchandising |
| Descripción y contenido | Aporta explicación o contenido de página de destino | Apoya SEO, intención de compra y contexto para el cliente |
| Imagen o banner | Representación visual del grupo | Afecta cuadrículas y páginas de destino |
| Título y descripción SEO | Metadatos visibles para buscadores | Apoyan la presentación orgánica |
| Relación de asignación | Conecta productos con el grupo | Determina qué aparece en los listados |
| Regla de inclusión | Selecciona productos automáticamente mediante condiciones | Alimenta smart colecciones o categorías dinámicas |
| Referencia de menú | Conecta el grupo con la navegación | Determina si el cliente puede llegar de forma natural |
La asignación de productos suele almacenarse separada del registro de grupo. Una relación muchos-a-muchos puede permitir que un producto pertenezca a varias categorías o colecciones. Un modelo estricto puede exigir una categoría principal. En un modelo basado en reglas, cada asignación puede no almacenarse directamente: los productos se incluyen según condiciones como product type, etiqueta, proveedor, brand, atributo, precio, inventario o fecha de publicación.
La diferencia entre una asignación almacenada y una calculada es importante. Una categoría estática contiene enlaces explícitos a productos. Una colección dinámica se reconstruye a partir de reglas. Una categoría controlada por búsqueda puede depender de un índice. Una página de destino gestionada por una extensión puede mostrar productos mediante un block, widget, módulo o llamada API en lugar de usar pertenencia nativa a una categoría.
Árboles de categorías, colecciones y modelos taxonómicos
Las plataformas difieren mucho en cómo modelan la organización del catálogo.
Algunas utilizan árboles de categorías como estructura principal. Las categorías padre contienen categorías hijas, estas contienen subcategorías más profundas y los productos se asignan a uno o varios nodos. Este modelo es habitual en catálogos grandes, repuestos, B2B, productos técnicos o navegación departamental profunda. Facilita una jerarquía sólida, pero exige controlar la profundidad, los nombres, las relaciones padre-hijo y las asignaciones.
Otras plataformas priorizan colecciones. Una colección puede parecer una categoría en la tienda, pero su lógica subyacente puede ser manual, automática, basada en etiquetas, product types o reglas. Puede aportar flexibilidad de merchandising sin imponer un árbol estricto. La contrapartida es que menús, migas de pan y significado padre-hijo pueden requerir configuración independiente.
Los modelos taxonómicos añaden otra capa. Una taxonomía es un sistema controlado de clasificación que define familias de productos y atributos esperados. Puede ser nativa de la plataforma, provenir de un marketplace, administrarse en un PIM o mantenerse para fuentes de datos y publicidad. La taxonomía no siempre coincide con la navegación visible. Un producto puede clasificarse de una forma para los compradores y de otra para Google Shopping, fuentes de datos de marketplaces, procurement o informes.
Por eso, un mismo concepto comercial puede existir en formas diferentes:
| Concepto comercial | Posible representación en la plataforma |
|---|---|
| Running shoes | Categoría hija, colección, smart colección, product type, grupo de etiquetas, nodo taxonómico o página de destino |
| Clearance items | Collection manual, colección automática, grupo por regla de precio, página por etiquetas o campaña de merchandising |
| Replacement filters | Ruta de categoría profunda, taxonomía de compatibilidad, resultado de búsqueda facetada o familia de producto gestionada por PIM |
| New arrivals | Collection automática basada en fecha de publicación, etiqueta, release date o regla de merchandising |
| Brand page | Categoría, colección, página de proveedor, página de destino, resultado de búsqueda o página generada por aplicación |
Una migración puede conservar la etiqueta y cambiar el modelo. Puede ser aceptable si la representación de destino mantiene el mismo funcionamiento. Se vuelve arriesgado cuando un árbol de categorías se aplana en colecciones, una smart colección se convierte en grupo estático o una página de destino de categoría se reduce a un simple listado de productos.
Navegación, menús y migas de pan son capas de datos separadas
Un grupo del catálogo puede existir sin aparecer en el menú. Un menú puede enlazar a una página que no sea una categoría nativa. Un miga de pan puede generarse a partir de la jerarquía, la ruta de menú, la ruta URL, la asignación del producto, el tema o una aplicación.
Esta separación importa porque los clientes experimentan la estructura mediante la navegación, no mediante registros de base de datos. Una categoría puede migrarse correctamente como registro y, aun así, perder la ruta que guiaba al cliente hasta ella.
Los menús suelen tener su propia estructura. Un elemento puede incluir etiqueta, destino, elemento padre, posición, visibilidad, alcance por mercado o idioma, icono, imagen, distintivo, diseño de megamenú y referencias a bloques personalizados. Los megamenús pueden incluir enlaces de categorías, productos destacados, imágenes, bloques promocionales o submenús curados manualmente.
Los migas de pan también pueden comportarse de forma distinta entre plataformas. Algunas los derivan del árbol de categorías. Otras utilizan la ruta de menú, la colección principal del producto, la URL o reglas del tema. Un producto asignado a varias categorías puede necesitar una ruta principal para los migas de pan. Sin ella, el recorrido puede ser inconsistente o confuso.
Para planificar el catálogo, la distinción técnica clave es:
| Capa | Pregunta técnica |
|---|---|
| Grupo de catálogo | ¿Existe la categoría, colección o nodo taxonómico? |
| Relación del producto | ¿Los productos están conectados con el grupo correcto? |
| Navegación | ¿Puede el cliente llegar al grupo por la ruta de menú esperada? |
| Breadcrumbs | ¿La tienda muestra el recorrido y contexto previstos? |
| Landing page | ¿La página del grupo conserva contenido, merchandising y lógica de presentación? |
Un resultado fiable requiere que las cinco capas funcionen juntas.
Asignación de productos y comportamiento de ubicación múltiple
La asignación controla dónde aparecen los productos. En catálogos sencillos, un producto puede pertenecer a una categoría. En tiendas maduras, suele aparecer en múltiples contextos: brand, department, sale group, seasonal colección, grupo de compatibilidad, ruta de repuestos, gift guide, contexto de paquete de productos o campaña.
El comportamiento depende de la plataforma. Algunas permiten asignaciones ilimitadas de categorías. Otras usan colecciones, etiquetas, product types, proveedor campos, canales de venta o campos personalizados. Algunas admiten una categoría principal para canonical paths y migas de pan. Otras consideran todas las pertenencias equivalentes.
Esto afecta a distintos comportamientos:
| Comportamiento de asignación | Posible efecto |
|---|---|
| Producto en varias categorías | Puede aparecer en varios recorridos, pero canonical path y migas de pan pueden necesitar reglas |
| Producto con una categoría principal | Jerarquía más fuerte, pero menos contextos de navegación si no existen asignaciones secundarias |
| Asignación por etiqueta o regla | Mantenimiento más fácil, pero depende de la calidad de los etiquetas y de la precisión de la regla |
| Producto mostrado por búsqueda o lógica de aplicación | Presentación flexible, pero puede no preservarse mediante datos nativos de categoría |
| Producto oculto en un canal y visible en otro | Tienda online, marketplace, B2B y catálogos regionales pueden divergir |
Un producto de alto valor puede migrarse correctamente como registro y fallar comercialmente si desaparece de una categoría importante. La validación por número de productos no detecta este problema salvo que las muestras incluyan categorías críticas para ingresos y productos presentes en varios grupos.
Grupos estáticos, grupos dinámicos y smart colecciones
Los grupos de catálogo pueden ser estáticos o dinámicos. Un grupo estático guarda asignaciones explícitas. Un grupo dinámico incluye productos cuando cumplen condiciones.
La agrupación dinámica puede depender de:
- etiquetas de producto;
- product type;
- proveedor o brand;
- precio o estado de oferta;
- disponibilidad de inventario;
- publish date o release date;
- valores de atributos;
- valores de variantes;
- grupo de clientes o mercado;
- product metacampos o campos personalizados;
- reglas administradas por aplicaciones;
- condiciones de índices de búsqueda.
Smart colecciones y categorías automáticas reducen mantenimiento manual, pero introducen dependencia técnica. El grupo no es solo un nombre: es un conjunto de reglas más un modelo de datos que debe seguir satisfaciéndolas.
Una colección como Summer Dresses Under $100 puede depender de product type, season etiqueta, género, categoría, precio, inventario y estado de publicación. Si un campo cambia de modelo en la plataforma de destino, la colección puede quedar incompleta o demasiado amplia. Una categoría que antes se actualizaba automáticamente puede convertirse en estática si el destino no puede representar la misma lógica.
Los grupos dinámicos necesitan una revisión más fuerte que los estáticos porque el riesgo puede aparecer después. Una colección puede parecer correcta en el lanzamiento y dejar de incluir productos futuros si la regla no se ha recreado o mantenido.
Landing pages de categoría y estructuras de contenido
Las páginas de categoría suelen contener mucho más que una lista de productos. Una página de destino puede incluir texto introductorio, contenido SEO, banners, vídeos integrados, guías de compra, bloques FAQ, enlaces internos, subcategorías destacadas, product carousels, promotion tiles o secciones de constructor de páginas.
Este contenido puede almacenarse en diferentes lugares:
| Tipo de contenido | Posible ubicación |
|---|---|
| Descripción de categoría | Campo nativo, descripción de colección, CMS block, metacampo o campo personalizado |
| Imagen de banner | Imagen de categoría, sección del tema, block de constructor de páginas, contenido multimedia library o datos de aplicación |
| Metadatos SEO | Campos SEO nativos, plugin/módulo, CMS o configuraciones del tema |
| Productos destacados | Orden manual, módulo de merchandising, product block o regla de aplicación |
| Guía de compra | CMS page, block de categoría, blog article o plantilla de constructor de páginas |
| Enlaces internos | HTML de descripción, blocks de menú, secciones del tema o datos de custom módulo |
Una página de destino puede parecer una categoría y depender técnicamente de CMS data, configuraciones del tema, campos personalizados o extensiones. Si esos componentes no se identifican, puede migrarse como listado simple y perder el contenido que la hacía útil.
Aquí es importante mantener la separación entre este análisis técnico de Section 6 y los temas SEO de Section 2. Este artículo no trata la estrategia de redirecciones. Trata el almacenamiento estructural y las dependencias que hay detrás de las páginas de categoría. La planificación de URL y redirecciones pertenece a otro lugar; la arquitectura de datos de las páginas de categoría pertenece aquí.
Ordenación, merchandising y reglas de visualización
Las páginas de categoría y colección suelen depender de reglas de presentación. El orden puede ser alfabético, más reciente primero, por precio, best-selling, curado manualmente, condicionado por disponibilidad, basado en búsqueda score, margen o controlado por aplicaciones.
Los datos de merchandising pueden incluir:
- posición manual del producto dentro de una categoría;
- indicadores de producto destacado;
- productos fijados;
- productos promocionados;
- productos excluidos;
- reglas de ordenación específicas por categoría;
- visibilidad por grupo de clientes;
- visibilidad por mercado o canal;
- ordenación sensible al inventario;
- ranking controlado por aplicaciones;
- boosts y bury rules de proveedores de búsqueda.
Estos detalles son fáciles de perder porque no parecen parte de la estructura a primera vista. Una categoría puede contener los productos correctos y mostrarlos en un orden equivocado. En categorías de alto tráfico, la ordenación puede afectar ingresos, liquidación, estacionalidad y descubrimiento.
Cuando origen y destino utilizan modelos de merchandising diferentes, preservar el resultado puede exigir trasladar una lista de posiciones manuales, recrear reglas de colecciones, reconstruir boosts de búsqueda o aceptar otro modelo de ordenación. La decisión correcta depende de cuánto valore la tienda una presentación curada.
Comportamientos de catálogo específicos de plataforma
Distintas familias de plataformas crean retos distintos.
Las plataformas SaaS suelen separar colecciones, menús de navegación, etiquetas de producto y secciones del tema. Esto puede simplificar la administración, pero también crear distancia entre el objeto de datos y la ruta visible. Una colección puede existir sin estar en el menú. Un etiqueta puede alimentar una colección automática. Un tema o una aplicación puede controlar filtros, banners y bloques de producto en páginas de colección.
Las plataformas Open-Source suelen exponer árboles de categorías más profundos, conjuntos de atributos, módulos y relaciones a nivel de base de datos. Pueden soportar jerarquías y comportamientos complejos, pero las tiendas pueden depender de extensiones, tablas personalizadas, sistemas de URL rewrites o overrides del tema que no forman parte del registro estándar de categoría.
Las plataformas enterprise y B2B pueden incluir catálogos por grupo de clientes, lista de precios, cuenta de empresa, canal de venta, geografía, contrato o aprobación flujo de trabajo. Un producto puede existir globalmente pero mostrarse solo en determinadas vistas. Por ello, la estructura puede estar conectada con permisos, jerarquía de cuentas, buyer roles o contract precios.
Las tiendas conectadas a marketplaces o controladas por PIM pueden mantener una estructura de navegación para la tienda y otra de clasificación para canales externos. El PIM puede ser propietario de taxonomía, atributos, familias de productos y asignaciones, mientras que la tienda solo consume las salidas publicadas. En ese modelo, la planificación debe identificar cuál es la verdadera autoridad del catálogo.
Qué puede cambiar al recrear modelos de catálogo
La estructura puede cambiar de formas que no se detectan mediante recuentos.
| Cambio estructural | Posible efecto |
|---|---|
| Árbol profundo se convierte en colecciones planas | Se pierde jerarquía, migas de pan y recorridos de refinamiento |
| Categorías estáticas se convierten en colecciones dinámicas | Mejora el mantenimiento futuro, pero la precisión de reglas se vuelve crítica |
| Collections dinámicas se convierten en grupos estáticos | El lanzamiento puede parecer correcto, pero la inclusión futura pasa a ser manual |
| Contenido de categoría se reduce a una descripción simple | Pueden debilitarse diseño, enlaces internos y bloques promocionales |
| La estructura de menú se reconstruye por separado | Las categorías existen, pero faltan rutas de navegación esperadas |
| Las asignaciones se recalculan por etiquetas | La pertenencia depende de consistencia de etiquetas y diseño de reglas |
| Se pierde el orden manual | La categoría contiene los productos correctos, pero con merchandising más débil |
| No se conserva la categoría principal | Breadcrumbs, canonical paths y informes pueden volverse inconsistentes |
No todo cambio es incorrecto. Una migración puede ser una oportunidad para simplificar un árbol desordenado, sustituir categorías duplicadas por colecciones más limpias o pasar de agrupaciones manuales a reglas automáticas. Lo importante es que estas sean decisiones de arquitectura, no efectos secundarios accidentales.
Qué deben revisar los comercios
La revisión debe empezar por recorridos representativos de navegación, no por la lista completa de categorías.
Conviene incluir:
- rutas de categorías con mayores ingresos;
- páginas de categoría o colección de alto tráfico orgánico;
- rutas profundas con varios niveles padre-hijo;
- productos asignados a múltiples categorías o colecciones;
- smart colecciones o categorías automáticas;
- páginas de categoría con contenido de página de destino;
- páginas con orden manual, posiciones destacadas o reglas de merchandising;
- estructuras de menú, megamenús y migas de pan;
- catálogos específicos por grupo de clientes, B2B, mercado o canal;
- estructuras controladas por PIM, ERP, proveedores de búsqueda, aplicaciones, módulos o código personalizado.
Para cada muestra, debe compararse la estructura de datos y el funcionamiento visible. ¿Existe el grupo? ¿Están asignados los productos correctos? ¿Puede alcanzarse desde la navegación? ¿Los migas de pan tienen sentido? ¿La página conserva contenido y significado de merchandising? ¿El grupo se actualiza automáticamente si antes era dinámico? ¿La plataforma de destino representa la misma jerarquía o un modelo diferente?
También debe identificarse la propiedad de los datos. Si la jerarquía se mantiene en PIM, ERP, fuente de datos de marketplace o custom administración módulo, la plataforma visible puede no ser la verdadera fuente del modelo. Preservar solo la tienda puede no preservar el flujo operativo.
Cuándo los datos necesitan una revisión más profunda
La estructura del catálogo necesita una revisión más profunda cuando la navegación depende de más que registros estándar de categorías.
Normalmente ocurre cuando:
- origen y destino utilizan modelos diferentes de categorías, colecciones o taxonomías;
- hay jerarquías profundas, productos en múltiples categorías o comportamiento importante de categoría principal;
- las páginas contienen contenido enriquecido, bloques de CMS, banners, diseños de constructor de páginas o estructuras de enlaces internos;
- smart colecciones, grupos automáticos, reglas de búsqueda, etiquetas, atributos o aplicaciones controlan la inclusión;
- el orden manual, productos destacados, posiciones fijadas o reglas de merchandising influyen en ingresos;
- menús, megamenús, migas de pan o lógica de tema están separados de los registros de categoría;
- grupo de clientes, B2B, mercado, canal o contrato afectan la visibilidad;
- PIM, ERP, marketplace o sistemas de búsqueda son propietarios de parte del modelo de clasificación.
Cuando el modelo no puede representarse mediante transferencia directa de Category o colección, el proyecto necesita una representación de destino definida para jerarquía, navegación, campos personalizados, menús, contenido de página de destino y propiedad en sistemas externos. Cualquier diseño de migración personalizado debe mantenerse ligado a ese resultado específico de catálogo.
Conclusión
La estructura del catálogo es la arquitectura de datos que sostiene la navegación por productos. Conecta categorías, colecciones, taxonomías, asignaciones, menús, migas de pan, páginas de destino, reglas de ordenación y merchandising en el recorrido visible desde la intención hasta el descubrimiento del producto.
Una transición fiable no conserva únicamente nombres de categorías. Conserva las relaciones y comportamientos que hacen utilizable el catálogo: jerarquía, accesibilidad, lógica de asignación, agrupación dinámica, contexto de contenido y orden de merchandising. La preparación más sólida consiste en revisar el catálogo como un conjunto de recorridos y dependencias estructurales antes de asumir que los registros de categoría representan toda la experiencia.
Preguntas frecuentes
¿Las categorías y las colecciones son lo mismo?
No. Pueden parecer similares en la tienda, pero utilizar modelos distintos. Las categorías suelen implicar jerarquía. Las colecciones pueden ser manuales, basadas en reglas, etiquetas o dependientes del tema. La estructura correcta de destino depende del comportamiento que se necesite conservar.
¿Por qué puede existir una categoría y no aparecer en la navegación?
Porque los registros de categoría y los menús suelen estar separados. Una categoría o colección puede existir en administración sin estar enlazada en el menú, megamenú, miga de pan o estructura de página de destino que utilizan los clientes.
¿Cuál es la diferencia entre grupos estáticos y dinámicos?
Un grupo estático guarda asignaciones explícitas de productos. Un grupo dinámico incluye productos cuando cumplen reglas como etiqueta, product type, proveedor, precio, disponibilidad, valor de atributo o fecha de publicación. En los grupos dinámicos debe conservarse la regla, no solo el nombre.
¿Por qué importa la asignación si todos los productos se migraron?
Porque los clientes no navegan directamente por registros de producto. Navegan por categorías, colecciones, resultados de búsqueda y menús. Un producto migrado puede perder visibilidad comercial si desaparece de un recorrido importante.
¿Cuándo necesita tratamiento personalizado la jerarquía del catálogo?
Puede ser necesario cuando depende de datos de extensiones, menús personalizados, reglas dinámicas, contenido de constructores de páginas, propiedad externa en PIM o ERP, catálogos específicos por cliente o un modelo de origen que no se corresponde directamente con el modelo de destino.