Organización de imágenes de producto: el sistema de nomenclatura que me salvó más de una vez
Un sistema práctico de nombrado y organización de archivos de imagen para equipos que gestionan catálogos visuales de alta rotación.
Hay nombres de archivo que parecen inofensivos y hasta graciosos… hasta que tenemos que trabajar con cientos o miles de imágenes.
IMG_4582.jpg
producto-final.jpg
foto-buena-2.jpg
FINAL-ahora-si.jpg
Mientras tenemos cinco archivos abiertos y recordamos qué hay dentro de cada uno, probablemente podamos sobrevivir así. El problema aparece seis meses después, cuando otra persona tiene que encontrar la imagen principal de un SKU, distinguirla de una versión anterior o saber si corresponde al producto padre, a una variante de color o a una fotografía de ambiente.
Ahí el nombre deja de ser una simple etiqueta y empieza a funcionar como información de producto.
Para organizar imágenes de catálogo no necesitamos nombres larguísimos ni una convención imposible de mantener. Necesitamos una regla estable que permita responder, con solo mirar el archivo: a qué producto pertenece, qué función cumple, si corresponde a una variante y en qué orden debería utilizarse.
Mi reglaes bastante simple: si para entender una imagen tenemos que abrirla, buscar una planilla o preguntarle a la persona que la creó, el nombre del archivo todavía no está haciendo suficiente trabajo.
¿Por qué el nombre de una imagen importa tanto en un catálogo?
Cuando pensamos en información de producto, solemos empezar por SKU, títulos, atributos, categorías o descripciones. Las imágenes parecen estar en otro plano, como si fueran archivos que simplemente acompañan a la ficha.
Pero no están realmente separadas.
Una imagen puede corresponder a un producto, una variante, una vista, una campaña o un canal concreto. Puede ser la imagen principal, una vista posterior, un detalle de textura, una fotografía de contexto o un gráfico explicativo.
Es decir, la imagen también tiene identidad, relaciones, función y contexto.
Cuando el catálogo crece, tratar las fotografías solamente como archivos adjuntos empieza a producir problemas muy parecidos a los de cualquier dato sin normalizar: duplicados, nombres ambiguos, asociaciones incorrectas y versiones difíciles de distinguir.
Una imagen de producto no es solamente un recurso visual. También es información que necesitamos identificar, relacionar, ordenar y distribuir.
El problema no es tener muchas imágenes: es no poder identificarlas
Un catálogo visual puede crecer muy rápido.
Supongamos que tenemos 500 productos y que cada uno utiliza una imagen principal, dos vistas alternativas, un detalle y una fotografía de contexto. Ya tenemos 2.500 archivos. Si además existen variantes por color, campañas estacionales o versiones específicas para algunos canales, el volumen aumenta rápidamente.
Con pocos archivos podemos confiar en nuestra memoria. Con miles, necesitamos una estructura.
Y esa estructura debería ayudarnos a responder preguntas concretas:
¿A qué SKU pertenece esta imagen?
¿Es la principal o una secundaria?
¿Corresponde al producto padre o a una variante?
¿Es frontal, lateral o un detalle?
¿En qué posición debería aparecer?
¿Es una imagen aprobada o una versión de trabajo?
Una buena nomenclatura convierte varias de esas respuestas en partes del propio nombre del archivo.
¿Cuál es una estructura simple para nombrar imágenes de producto?
No existe una nomenclatura universal que funcione para todas las empresas. La estructura depende del catálogo, del modelo de variantes y de los sistemas que reciben las imágenes.
Pero como punto de partida, una fórmula muy útil es: identificador + función + variante + orden
[IDENTIFICADOR][VARIANTE][FUNCIÓN]_[ORDEN].[EXTENSIÓN]
Si no necesitamos distinguir una variante:
[IDENTIFICADOR][FUNCIÓN][ORDEN].[EXTENSIÓN]
Por ejemplo:
ABC123_main_01.jpg
ABC123_front_02.jpg
ABC123_back_03.jpg
ABC123_detail_04.jpg
Si el producto tiene imágenes diferentes por color:
ABC123_RED_main_01.jpg
ABC123_RED_back_02.jpg
ABC123_BLUE_main_01.jpg
La ventaja no está en utilizar exactamente estas palabras. Está en que todos los archivos respeten una misma gramática.
Una persona puede interpretarla, una planilla puede ordenarla y un sistema puede utilizarla para automatizar parte del trabajo.
La mejor nomenclatura no es la más sofisticada. Es la que una persona nueva puede aprender rápido y el equipo puede aplicar sin inventar una excepción cada semana.
¿Qué identificador conviene usar en el nombre?
La primera parte debería relacionar el archivo con un producto de forma inequívoca.
Por eso prefiero un identificador estable antes que el nombre comercial completo.
Por ejemplo:
84372_main_01.jpg
suele ser más sostenible que:
Silla-de-comedor-nordica-madera-natural-main.jpg
El nombre comercial puede cambiar por una decisión de marketing, por idioma o incluso por canal. Un SKU, una referencia interna o un código de estilo suele ser más estable.
Además, evitamos construir nombres enormes que después son difíciles de leer y procesar.
Eso no significa que el SKU sea siempre la respuesta correcta. En moda, por ejemplo, podemos trabajar con una referencia de estilo y agregar el código de color cuando la fotografía corresponde a una variante visual.
La pregunta que tenemos que responder es otra: ¿qué identificador permite relacionar esta imagen con el producto correcto sin depender del nombre visible?
Ese debería ser el punto de partida.
¿Cómo conviene nombrar el tipo de imagen?
Después del identificador aparece una zona que parece simple y puede volverse caótica muy rápido.
Una persona escribe:
front
Otra:
frontal
Otra:
frente
Y otra:
vista1
Los cuatro términos podrían referirse exactamente a la misma cosa.
Por eso conviene definir un vocabulario controlado para los tipos de imagen.
Podría ser algo tan simple como:
| Código | Uso |
|---|---|
main | Imagen principal |
front | Vista frontal |
back | Vista posterior |
side | Vista lateral |
detail | Detalle |
lifestyle | Producto en contexto |
packaging | Embalaje |
diagram | Esquema o gráfico |
No necesitamos quince términos si nuestro catálogo utiliza cinco.
Lo importante es que, una vez elegido un valor, no aparezcan sinónimos para la misma función. Si usamos back, no alternamos después entre back, rear, posterior y dorso.
La lógica es la misma que aplicamos a los atributos del catálogo: un concepto debería tener una forma preferida de nombrarse.
¿Por qué conviene separar función y orden?
Otro sistema frecuente consiste en utilizar solamente números:
ABC123_1.jpg
ABC123_2.jpg
ABC123_3.jpg
Es bastante mejor que IMG_4582.jpg, pero sigue dejando una pregunta abierta: ¿qué representa cada número?
El orden indica dónde debería aparecer la imagen. La función indica qué muestra.
Podemos necesitar ambas cosas.
ABC123_front_01.jpg
nos informa que se trata de una vista frontal y que ocupa la primera posición.
ABC123_detail_04.jpg
nos dice que se trata de un detalle y que debería aparecer en cuarta posición.
También conviene usar una cantidad fija de dígitos. Por ejemplo usar siempre dos dígitos —01, 02, 03— mantiene un orden consistente incluso cuando tenemos más de nueve archivos, en lugar de mezclar: 1, 2, 10.
Es un detalle pequeño, pero ayuda a mantener el orden cuando los archivos se clasifican automáticamente por nombre.
¿Cuándo conviene incluir la variante?
Cuando la imagen cambia según la variante que selecciona el comprador.
El ejemplo más evidente es el color.
Si una camiseta roja y una azul utilizan fotografías distintas, necesitamos poder diferenciarlas:
TS100_RED_front_01.jpg
TS100_BLUE_front_01.jpg
En cambio, si una misma fotografía aplica a todas las tallas, probablemente no tenga sentido agregar S, M, L y XL al nombre.
La regla que uso es simple:
incluimos la variante cuando necesitamos distinguir visualmente los archivos.
Esto es particularmente útil en moda, calzado, decoración, cosmética y otros catálogos donde el color, el acabado o la presentación modifican realmente lo que el comprador ve.
No toda variante necesita una imagen diferente. La nomenclatura debería reflejar diferencias visuales reales, no repetir datos porque sí.
¿Tenemos que incluir toda la información dentro del nombre?
No.
De hecho, intentar hacerlo puede llevarnos al problema contrario.
Podríamos terminar con algo así:
SKU123_marca_producto_color_rojo_categoria_verano_web_amazon_aprobada_2026_final.jpg
Eso ya no es una nomenclatura. Es una base de datos improvisada.
Hay información que funciona muy bien dentro del nombre porque ayuda a identificar rápidamente el archivo:
- producto;
- variante visual;
- función;
- orden.
Y hay información que funciona mejor como metadato dentro de un PIM o DAM:
- derechos de uso;
- fecha de vencimiento;
- fotógrafo;
- campaña;
- estado de aprobación;
- canal autorizado;
- versión;
- resolución;
- fecha de creación.
El nombre sirve para identificar. Los metadatos sirven para describir y gobernar.
El nombre del archivo no tiene que convertirse en una ficha técnica. Tiene que contener la información mínima necesaria para identificarlo sin ambigüedad.
¿Cómo evitar el clásico “final-final-ahora-sí.jpg”?
Vengo del mundo editorial, así que tengo una relación bastante cercana con este problema:
final.jpg
final2.jpg
final-corregido.jpg
final-corregido-definitivo.jpg
final-definitivo-este-si.jpg
No es un problema exclusivo de las imágenes de producto. Aparece cada vez que trabajamos con archivos sin un sistema claro de versiones.
Para un catálogo, conviene separar archivos de trabajo de archivos aprobados para publicación.
Si contamos con un DAM que gestiona versiones, no necesitamos incorporar todo el historial al nombre final.
Si todavía trabajamos principalmente con carpetas compartidas, podemos utilizar una estructura sencilla:
01_ORIGINALES
02_TRABAJO
03_APROBADAS
04_SALIDAS
La imagen que llega al PIM, al eCommerce o al marketplace debería provenir de la zona aprobada, no de una carpeta donde conviven originales, pruebas, recortes y descartes.
Esto mantiene limpia la nomenclatura final y evita que los nombres de publicación terminen acumulando la historia completa del proceso de retoque.
¿Qué reglas conviene seguir con espacios y caracteres especiales?
Las imágenes no siempre permanecen dentro de una carpeta.
Pueden pasar por un PIM, un DAM, una API, un feed, un CDN, una plataforma de eCommerce o un marketplace. Por eso, conviene utilizar nombres previsibles y simples.
Como regla práctica:
- evitar espacios;
- elegir un único separador;
- evitar símbolos innecesarios;
- no mezclar guiones y guiones bajos sin una razón;
- mantener una misma lógica de mayúsculas y minúsculas;
- evitar caracteres que puedan generar problemas al viajar entre sistemas;
- conservar correctamente la extensión del archivo.
Lo importante no es si elegimos - o _.
Lo importante es elegir una regla y sostenerla.
Por ejemplo:
SKU_VARIANTE_FUNCION_ORDEN.ext
Si nuestros SKU ya contienen guiones bajos, probablemente sea mejor utilizar otro separador.
La convención tiene que diseñarse sobre los datos reales, no sobre un ejemplo perfecto de laboratorio.
¿Las carpetas pueden reemplazar una buena nomenclatura?
No deberían.
Una estructura de carpetas puede ser muy útil durante la producción. Podemos separar colecciones, campañas, productos o estados.
Pero el archivo debería seguir siendo identificable cuando salga de esa carpeta.
Si ABC123_front_01.jpg estaba guardado en:
Colección 2026 > Aprobadas > ABC123
y luego se copia al PIM, al DAM o a otro repositorio, el contexto de la carpeta desaparece.
El nombre viaja con el archivo.
Cuando contamos con un DAM, podemos complementar esa identidad con metadatos, etiquetas, colecciones y estados de aprobación. Pero la nomenclatura sigue siendo una primera capa de reconocimiento muy útil.
Una buena nomenclatura también permite automatizar
Este es el punto donde una tarea que parece puramente administrativa empieza a tener impacto técnico.
Si todos los archivos siguen una estructura como:
ABC123_RED_front_01.jpg
podemos interpretar:
Producto: ABC123
Variante: RED
Función: front
Orden: 01
Esa estructura puede utilizarse como base para procesos de asociación, importación o validación.
Por eso, antes de definir una nomenclatura, vale la pena consultar con quien administra el PIM, el DAM o las integraciones. Quizás el sistema pueda utilizar partes del nombre para asociar automáticamente una imagen con un producto o una variante.
Relacionar diez imágenes manualmente es posible.
Relacionar veinte mil de la misma forma deja de ser un proceso razonable.
Una nomenclatura consistente no solo ayuda a encontrar imágenes. También puede transformar el nombre del archivo en una estructura aprovechable por las automatizaciones.
Un caso real: cuando miles de imágenes tienen que convivir con variantes y varios canales
En un proyecto real de CRITERIA para un grupo de indumentaria con múltiples marcas, el catálogo incluía más de 5.000 productos padre, más de 20.000 variantes de talla y más de 5.000 imágenes de producto.
El PIM debía abastecer varios destinos: eCommerce, punto de venta, marketplace mediante una plataforma de sindicación, un sistema de identificación GTIN y otros canales de catálogo.
En un escenario así, las imágenes no pueden gestionarse como archivos independientes del modelo de producto.
Hay que saber a qué referencia pertenecen, con qué variante se relacionan y cómo viajarán hacia los distintos canales.
El proyecto implicó saneamiento y normalización de datos, organización de variantes e ingesta de imágenes dentro del PIM. Ese tipo de volumen muestra por qué una convención estable deja de ser una preferencia personal: se convierte en parte del modelo operativo del catálogo.
No hace falta esperar a tener miles de fotografías para definirla. De hecho, es bastante más fácil diseñarla antes.
¿Cuál sería una plantilla mínima para empezar?
Para un equipo que hoy tiene sus imágenes repartidas entre carpetas y quiere ordenar el proceso sin complicarlo demasiado, empezaría con:
[ID_PRODUCTO][VARIANTE][FUNCIÓN]_[ORDEN].[EXT]
Cuando no existe una variante visual:
[ID_PRODUCTO][FUNCIÓN][ORDEN].[EXT]
Ejemplos:
100245_main_01.jpg
100245_front_02.jpg
100245_detail_03.jpg
100245_RED_main_01.jpg
100245_RED_back_02.jpg
Y acompañaría esa convención con una guía muy breve:
| Elemento | Regla |
|---|---|
| Identificador | SKU, referencia o código estable |
| Variante | Solo cuando cambia visualmente |
| Función | Valor de una lista controlada |
| Orden | Dos dígitos: 01, 02, 03… |
| Separador | Siempre el mismo |
| Espacios | Evitarlos |
| Versiones | Gestionarlas fuera del nombre final |
No necesitamos diseñar una estructura enorme antes de empezar.
Necesitamos una lógica suficientemente clara para funcionar hoy y suficientemente estable para seguir funcionando cuando el catálogo crezca.
¿Qué revisar antes de una carga masiva de imágenes?
Antes de renombrar o cargar miles de archivos, haría una prueba con una muestra pequeña y revisaría:
- ¿Cada imagen contiene un identificador válido?
- ¿Todos los nombres siguen la misma estructura?
- ¿Los tipos de imagen pertenecen a un vocabulario definido?
- ¿Las variantes aparecen solamente cuando corresponde?
- ¿El orden se expresa siempre de la misma manera?
- ¿Los archivos aprobados están separados de las versiones de trabajo?
- ¿Podemos distinguir imagen principal, vistas y detalles sin abrir los archivos?
- ¿La nomenclatura está documentada para todo el equipo?
- ¿Probamos cómo interpreta los nombres el PIM o DAM antes de cargar todo?
- ¿Sabemos qué información debe estar en el nombre y cuál corresponde a metadatos?
Hay una prueba adicional que me gusta mucho porque es sencilla: entregarle diez archivos a alguien que no participó en la producción y pedirle que explique qué representa cada uno.
Si puede hacerlo sin preguntarnos demasiado, probablemente la nomenclatura esté funcionando.
Una buena nomenclatura de imágenes no debería depender de que alguien recuerde cómo funciona. Tiene que poder explicarse, repetirse y mantenerse cuando cambie el equipo, aumente el catálogo o aparezca un nuevo canal. Para mí, ese es el verdadero valor del sistema: que ABC123_RED_front_01.jpg deje de ser simplemente el nombre de un archivo y se convierta en una pequeña pieza de información que cualquier persona —y eventualmente cualquier sistema— pueda interpretar y utilizar.
