Cómo cargan el catálogo los mejores
Segunda investigación, esta vez del lado del panel: cómo se crean categorías, productos y variantes. Con fuente citada. 2026-08-29.
1. Categoría ≠ colección, y confundirlas es el error clásico
Shopify separa dos cosas que todo el mundo llama «categoría», y dice explícitamente que es su fuente de confusión más común:
| Qué es | Para qué sirve | |
|---|---|---|
| Categoría (taxonomía) | qué ES el producto. Un campo único, de un vocabulario estándar | Que los canales, buscadores e integraciones entiendan el producto |
| Colección | agrupación de merchandising. Manual o automática por condiciones | Cómo se navega y se vende |
La taxonomía clasifica por lo que el producto es, no por cómo se comercializa: una silla gamer sigue siendo Muebles > Sillas, no Electrónica. (Shopify Help · BSS Commerce · Ouiteo)
Cómo aterriza: mueb_categories hace de navegación del showroom (Comedores, Salas,
Alcobas) — eso está bien y se queda. Lo que le falta es el puente a la taxonomía
estándar, para que el producto sea legible fuera de nuestro sitio.
2. Lo que Google EXIGE de un mueble
Este es el hallazgo que obliga a migración:
Ancho, alto y profundidad en centímetros son obligatorios para todo mueble y artículo grande de hogar, y además hay que incluir peso (kg), requiere armado (sí/no) y empaque plano (sí/no). — LynkPIM, taxonomía de hogar y muebles
De los cinco, ya teníamos tres. Faltaban «requiere armado» y «empaque plano» — y no son un capricho del feed: son exactamente lo que un comprador colombiano pregunta antes de decidir, porque determinan si necesita a alguien que se lo arme y si le cabe en el carro.
Y un detalle de implementación que evita una migración futura: usar el identificador numérico de la categoría de Google, no la ruta de texto. Los identificadores son estables entre revisiones de la taxonomía y entre idiomas; las rutas cambian cada vez que Google la revisa. (WISEPIM · LynkPIM)
3. Cómo se crean 72 variantes sin perder la cabeza
El vocabulario que usa la industria, y que conviene usar igual:
- Opción: la dimensión por la que el cliente elige — Tela, Tamaño.
- Valor de opción: una elección dentro de ella — Lino beige.
- Variante: una combinación concreta. Es la variante la que lleva el SKU, el precio y el inventario.
Coincide exactamente con el modelo que ya construimos.
Sobre la creación: la matriz se genera, no se escribe a mano. El panel ofrece generar todas las combinaciones de las opciones y una acción aparte para generar los SKU. Y por encima de cierto tamaño, editar variante por variante es impracticable — de ahí que la edición masiva y el CSV no sean un lujo. (Matrixify · Apimio)
Consecuencia de diseño: generar el producto cartesiano completo y dejar que el dueño borre las combinaciones que no existe es más rápido que hacerle crear 72 a mano. Pero el generador tiene que respetar los topes (3 opciones, 250 variantes) y avisar antes de generar, no fallar a mitad.
4. Lo que se cambia
| # | Cambio | Porque |
|---|---|---|
| 1 | gpc_category_id en mueb_categories — entero, no texto |
Los identificadores numéricos de Google son estables; las rutas cambian |
| 2 | assembly_required en mueb_products |
Obligatorio para muebles en el feed, y es lo primero que pregunta el comprador |
| 3 | flat_pack en mueb_products |
Ídem. Además decide si le cabe en el carro |
| 4 | Generador de matriz de variantes | La matriz se genera, no se escribe a mano |
| 5 | El generador avisa ANTES de pasar el tope | Fallar a mitad deja el producto en un estado raro |
6. Imágenes: lo que exige un catálogo que se abre en celular y en escritorio
Investigación del 2026-08-29, segunda tanda.
Resolución
El punto dulce del sector es 2000–2500 px del lado largo. Los umbrales concretos: por debajo de 1000 px el zoom ni siquiera tiene sentido; 1600 px es el mínimo para que se aprecie la trama de la tela, y a 2000 px el comprador puede examinar la costura y leer una etiqueta. Las imágenes ampliables suben la conversión entre un 9% y un 30%. (Baymard · Squareshot · furn)
El contraste con Gastro es el dato que ordena la decisión: su procesador topa en 1080 px porque un plato se mira en un celular y se decide en dos segundos. Un mueble se decide en semanas y con zoom sobre la tela. 2048 px.
Y sRGB, nunca Adobe RGB ni CMYK: se renderizan con el color desplazado en la tienda, y en muebles el color de la tela es el producto.
Un catálogo mezcla proporciones muy distintas
Un puf es casi cuadrado; un comedor de ocho puestos, muy apaisado; un armario o una lámpara de pie, verticales. De ahí dos reglas:
- Se escala por el LADO LARGO, no por el ancho. Topando solo el ancho, un armario de 1800 × 3800 termina en 2048 × 4096 — un archivo enorme en una página que se abre en 4G. (Este bug existió: lo encontró la primera prueba con proporciones reales.)
- No se recorta nunca. Un recorte cuadrado automático le corta las patas a una mesa y la cabecera a una cama. La proporción nativa viaja en la respuesta para que la tarjeta encaje la foto sobre el fondo de la marca.
Responsivo de verdad: la escalera de srcset
El consenso son 4–6 anchos, aproximadamente al doble cada uno: 400 / 800 / 1200 /
1600, y para héroes 2000+. El navegador elige con srcset + sizes. La carga
diferida recorta el peso inicial entre un 30% y un 50%.
(Krunkit ·
Picovert)
Puntos de corte de referencia: móvil 320–480, móvil grande 481–768, tableta 769–1024, escritorio 1025–1440, escritorio grande 1441+.
Por qué no basta con una sola resolución: mandarle 2048 px a un celular es descargar medio megabyte para pintarlo en 380 px de ancho. Eso solo ya rompe el presupuesto de LCP de 2 segundos en 4G que fijamos en la especificación del catálogo.
Se generan solo los peldaños por debajo del tamaño real —ampliar no añade detalle,
solo peso— y los anchos que existen se guardan en la fila, no se derivan de una
constante: si la escalera cambia, anunciar en el srcset un ancho que nadie subió sería
un 404 por cada tarjeta.
Formato
AVIF pesa ~30% menos que WEBP y ya supera el 95% de soporte; WEBP está por encima del 97% y es el respaldo seguro. Se sirven los dos. (Orquitool)
Para el placeholder, LQIP y no BlurHash: pesa unos 150 bytes más pero no necesita JavaScript para dibujarse y se ve mejor. Veinte píxeles de ancho, en base64 dentro del JSON, sin petición extra. (Mux)