Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con…
Datos de producto estructurados: cómo se notan en tu storefront
Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con una unidad, un identificador estable y un lugar claro en la jerarquía de variantes, y no dentro de un texto descriptivo. Tus clientes nunca ven el modelo de datos, pero sí sus efectos en cinco lugares: filtros, tablas comparativas, selección de variantes, marcado Schema.org y feeds. Si el modelo es débil, cada uno de esos componentes tiene que adivinar, y tus clientes lo notan.
Qué significa "estructurado" en un catálogo de productos
"Tenemos un PIM" y "nuestros datos de producto están estructurados" son dos afirmaciones distintas. La estructura surge de las decisiones de modelado que tomas dentro del PIM:
- Modelo de atributos: cada atributo tiene un tipo (texto de una lista de valores, número, sí/no, rango) en lugar de texto libre. "Blanco", "blanco " y "bco" son tres valores de filtro; un valor de una lista es uno solo.
- Unidades: el número y la unidad se guardan por separado. "aprox. 60 cm" en un campo de texto nunca será un control deslizante; 60 con la unidad cm, sí.
- Clasificación: en surtidos B2B técnicos, estándares como ETIM y ECLASS definen estas reglas por ti. ETIM describe los productos mediante clases y características de cuatro tipos (alfanumérica, lógica, numérica, rango), y las características numéricas y de rango necesitan una unidad, salvo los recuentos como el número de polos. ECLASS asigna a cada propiedad un identificador único a nivel mundial (IRDI) y admite listas de valores y unidades convertibles.
- Variantes: un producto padre lleva la información común, cada variante comprable su propio SKU, GTIN, precio y stock, y los ejes de variante (talla, color, tensión) son explícitos.
- Multilingüe: los identificadores no dependen del idioma; solo se traducen etiquetas y valores.
- Asignación de medios: las imágenes están vinculadas a la variante u opción que muestran, no simplemente subidas a una galería.
Filtros y facetas: donde las carencias aparecen primero
Una faceta vale lo que vale el atributo que hay detrás. En Laioutr, Orchestr define un contrato de filtros para las páginas de listado: filtros de lista, interruptores sí/no, rangos continuos e intervalos predefinidos. Los límites de un rango pueden ser números, importes o medidas con unidad. La relación con tu modelo de datos es directa: un ancho guardado como número más unidad se convierte en un control deslizante; un ancho guardado como texto, en el mejor de los casos, en una larga lista de casillas sin ordenar.
Los valores y recuentos de las facetas vienen de tu backend o de tu proveedor de búsqueda; componentes como la barra de filtros y el panel lateral de filtros muestran lo que devuelve Orchestr. Si además quieres búsqueda semántica y filtros que se adapten a los resultados, AI Search & Discovery está disponible como add-on. La base de tus facetas sigue siendo tu modelo de atributos.
Los filtros también importan para el rastreo: la guía de Google sobre navegación por facetas recomienda excluir las URL de filtros del rastreo si no necesitas indexarlas. Si quieres indexarlas, mantén un orden de parámetros coherente y devuelve un 404 para las combinaciones vacías. Con qué frecuencia los clientes empiezan por un filtro en lugar de por la búsqueda es el tema de nuestro análisis sobre búsqueda con IA, navegación por categorías y filtros por facetas.
Fichas técnicas y tablas comparativas: por qué importan los identificadores compartidos
En el modelo de producto canónico de Laioutr, las especificaciones son filas ordenadas: un nombre visible, un valor tipado (texto, número, booleano, medida o importe) y, opcionalmente, una sección como "dimensiones" o "técnica". La tabla de especificaciones formatea cada valor según la locale y agrupa las filas en secciones. Quien compra en España ve "1,5 kg" y quien compra en Estados Unidos "1.5 kg", a partir de los mismos datos.
Una tabla comparativa coloca estas filas de varios productos una junto a otra, y eso solo funciona si las filas comparten identificadores. Si un producto dice "Peso" y el siguiente "Peso neto (kg)", la tabla tiene huecos, y una vista de "solo diferencias" acaba comparando etiquetas en lugar de valores. Los nombres de propiedad estandarizados existen precisamente para eso: alinear filas que vienen de conectores distintos.
Con filas coherentes, colocar la tabla de especificaciones en la página de producto es trabajo de maquetación y no un proyecto de datos, y tu equipo editorial lo hace en Studio, el editor visual de Laioutr. Una vista comparativa de productos, si tu proyecto construye una, lee las mismas filas.
Selección de variantes: ejes, disponibilidad e imágenes
En el modelo canónico, un producto contiene sus grupos de opciones (por ejemplo talla con S, M, L y color con rojo y azul), y cada variante lleva sus opciones seleccionadas, SKU, un GTIN opcional, disponibilidad y precios, incluido el precio por unidad.
Aquí aparecen tres errores típicos:
- Colores modelados como productos separados. El selector no puede ofrecerlos, así que los clientes saltan de una ficha de producto a otra.
- Disponibilidad solo por valor. Desactivar "XL" funciona por valor de eje, pero "rojo en XL" es una combinación y necesita stock a nivel de variante.
- Imágenes vinculadas solo al producto padre. Al elegir azul cambia el precio, pero no la foto.
Los tres se corrigen en el modelo de datos, no en el componente.
Schema.org y feeds: la misma estructura, leída por máquinas
Los buscadores y los motores de respuesta con IA leen los mismos datos que tus filtros. Schema.org permite que un Product tenga propiedades adicionales como pares PropertyValue: propertyID contiene un código estándar para la característica, que es donde encaja un identificador ETIM o ECLASS, y unitCode un código de unidad UN/CEFACT. Para las variantes, Google documenta un ProductGroup con productGroupID, los atributos por los que varía y variantes anidadas.
En un frontend de Laioutr puedes generar el JSON-LD con el módulo Nuxt Schema.org a partir de la entidad que muestra una sección, en lugar de campos SEO mantenidos por separado. Así marcado y página visible comparten una fuente, consulta SEO y GEO.
Los feeds siguen las mismas reglas. Google Merchant Center espera el mismo ID de grupo de artículos en todas las variantes de un grupo y valores distintos para color, talla, material o estampado. Por qué cuarenta canales acaban siendo cuarenta verdades lo explica nuestro artículo sobre la coherencia de los datos de producto entre canales. Para exportar formatos de canal directamente desde la capa frontend, Distributr está disponible como add-on: cero importaciones, los datos ya están ahí, una sola dirección, hacia fuera. No es un PIM.
Un único modelo de datos para todos los backends con Orchestr
Los datos de producto rara vez viven en un solo sistema: el PIM gestiona atributos y medios, el ERP precios y stock, un proveedor de búsqueda las facetas. Orchestr mapea estas fuentes a un modelo canónico de productos, variantes, especificaciones y filtros, de modo que los componentes reciben la misma forma sin importar de dónde venga un campo. Agrupa varias llamadas API secuenciales en una sola petición y usa una caché de tres niveles. Laioutr se conecta a 50+ backends mediante 300+ integraciones; otras fuentes pueden conectarse con una integración de Orchestr. Más sobre la arquitectura: Componibilidad y orquestación.
Por dónde empezar:
- Revisa los 20 atributos que usan tus filtros de categoría más importantes: tipo, unidad, lista de valores.
- Define los ejes de variante en el PIM antes del próximo release del frontend.
- Asigna los identificadores de atributos a nombres compartidos para que las filas de comparación se alineen.
- Genera los datos estructurados a partir de la entidad mostrada y revisa tus feeds contra ellos.
FAQ
¿Necesitamos ETIM o ECLASS?
Solo si tu mercado los espera, normalmente en la distribución técnica, las instalaciones eléctricas y de climatización o las compras industriales. Para moda o bienes de consumo suele bastar un modelo de atributos propio y limpio, con valores tipados y unidades.
¿Laioutr sustituye a nuestro PIM?
No. El PIM sigue siendo el sistema de referencia para los datos de producto. Laioutr es la capa frontend: lee los datos a través de Orchestr, los muestra en componentes y mantiene el storefront coherente entre backends.
¿Quién gestiona filtros y fichas técnicas, desarrollo o marketing?
Ambos, con un reparto claro. Desarrollo define una vez los componentes y su conexión a los datos. Los equipos de producto y marketing los colocan y configuran en Studio, sin un ticket para cada página de categoría.
Próximos pasos
¿Quieres ver cómo se comporta tu modelo de atributos en filtros, fichas técnicas y selección de variantes? Reserva una demo y trae una categoría de ejemplo. La revisaremos juntos sobre un Composable Headless Frontend.