Una actualización de PrestaShop se convierte en una carrera contra los errores 500 y los tiempos de espera.
Actualizar cientos o miles de productos en PrestaShop debería ser una tarea administrativa, no una ceremonia de invocación frente a un error 500. Sin embargo, basta un CSV mal preparado, una importación demasiado ambiciosa o un servidor con la paciencia de una vela encendida para que el catálogo se convierta en una tormenta.
La buena noticia: se puede hacer bien. La noticia menos poética: hay que respetar los límites de PHP, MySQL, PrestaShop y, por supuesto, del sentido común. 🛒⚙️
Contenido de la guía
Por qué fallan las actualizaciones masivas
Métodos recomendados
Preparar CSV sin dramas
Actualizar precios correctamente
Combinaciones y stock
Ajustes del servidor
Flujo seguro paso a paso
Errores frecuentes
Preguntas frecuentes
En una tienda pequeña, cambiar precios puede parecer un paseo: se abre el producto, se edita, se guarda. Casi doméstico. En una tienda con 20.000 referencias, múltiples proveedores, combinaciones, reglas de impuestos, descuentos por grupo y multitienda, ese paseo se vuelve una expedición polar. El panel de administración, tan amable para editar un artículo, puede ser torpe como un piano en una escalera cuando se le pide procesar un catálogo entero de golpe.
Y aun así, las actualizaciones masivas son inevitables. Suben las tarifas del proveedor, cambian los costes logísticos, se corrige un margen, llegan productos nuevos, desaparecen otros. El comercio electrónico vive en movimiento. Un catálogo quieto es como una pecera sin agua: conserva la forma, pero ya no tiene vida.
Por qué fallan las actualizaciones masivas en PrestaShop 🧨
Antes de hablar de soluciones, conviene mirar al monstruo a los ojos. Los errores de servidor durante importaciones masivas en PrestaShop no suelen aparecer por una sola causa. Son el resultado de una cadena: demasiados datos, poco tiempo de ejecución, memoria insuficiente, consultas pesadas, índices que se regeneran, cachés que se limpian y un navegador esperando una respuesta que quizá nunca llegue.
El clásico error 500 no es un diagnóstico, es una cortina. Detrás puede haber un fallo de PHP, una excepción de PrestaShop, un módulo interfiriendo, una consulta SQL rota o un servidor agotado. El error 504 Gateway Timeout, por su parte, es más explícito: el proceso tardó demasiado. Como un camarero que se va a buscar pan y vuelve en marzo.
| Error o síntoma | Causa probable | Dónde revisar |
|---|---|---|
| Error 500 | Fatal error de PHP, excepción de PrestaShop, módulo incompatible, memoria agotada | Logs de PHP, logs de PrestaShop, modo debug |
| Error 504 | Timeout en Nginx, Apache, proxy, PHP-FPM o Cloudflare | Configuración del servidor, reverse proxy, panel de hosting |
| Pantalla en blanco | Error fatal sin visualización habilitada | var/logs/, logs del servidor |
| Importación incompleta | Límite de ejecución, archivo demasiado grande, filas con errores | CSV, configuración PHP, historial de importación |
| Precios duplicados o incoherentes | Uso incorrecto de precios específicos, impuestos, multitienda o combinaciones | Tablas de productos, reglas de precios, configuración de impuestos |
| Tienda lenta después de importar | Caché desactualizada, índices pendientes, muchas combinaciones, consultas pesadas | Caché, índice de búsqueda, base de datos, módulos |
PrestaShop, en especial en tiendas con catálogos grandes, no debe tratarse como una hoja de cálculo con botones bonitos. Es una aplicación compleja, apoyada en una base de datos relacional, con dependencias entre productos, categorías, atributos, imágenes, stock, reglas fiscales y precios específicos. La antítesis es clara: el usuario quiere inmediatez; el sistema necesita orden.
⚠️ Idea clave: el objetivo no es “subir un archivo enorme y rezar”, sino dividir, validar, ejecutar por lotes y medir. La actualización masiva profesional se parece más a una operación quirúrgica que a volcar una caja de piezas sobre la mesa.
Métodos para actualizar catálogo y precios en PrestaShop
No existe un único camino correcto. Existe el camino adecuado para el tamaño de tu catálogo, la frecuencia de actualización, el tipo de datos y el nivel técnico del equipo. Un catálogo de 400 productos puede vivir feliz con importaciones CSV manuales. Uno de 80.000 referencias con cambios diarios necesita automatización seria, quizá vía API, ERP, conector o procesos CLI.
1. Importador CSV nativo 📄
Es la opción integrada en PrestaShop para importar productos, combinaciones, categorías, clientes, direcciones y otros datos. Resulta útil para operaciones puntuales o catálogos medianos.
Ideal para: actualizaciones controladas, tiendas pequeñas o medianas, usuarios no técnicos.
2. Módulos de importación profesional 🧩
Herramientas especializadas permiten mapear campos, programar tareas, importar desde URL, FTP o feeds XML/CSV y procesar lotes con más estabilidad.
Ideal para: proveedores externos, sincronización frecuente, catálogos grandes.
3. Webservice API de PrestaShop 🔌
Permite crear, consultar y actualizar recursos mediante peticiones HTTP. Es más limpio que tocar la base de datos directamente, aunque requiere desarrollo y control de errores.
Ideal para: integraciones con ERP, PIM, sistemas internos o middleware.
4. Scripts CLI o tareas programadas 🖥️
Procesos ejecutados desde consola o cron, sin depender del navegador. Son más resistentes a timeouts web y permiten lotes, reintentos y logs detallados.
Ideal para: catálogos grandes, actualizaciones nocturnas, precios diarios.
5. SQL directo, con mucho cuidado 🧬
Puede ser rápido, sí. También puede ser devastador. Modificar tablas de PrestaShop sin comprender su estructura es como arreglar un reloj con un martillo: a veces algo se mueve, pero rara vez mejora.
Ideal para: técnicos expertos, operaciones muy concretas, entornos controlados.
Cómo preparar un CSV de productos sin provocar una catástrofe elegante 📊
El CSV es humilde. Un archivo de texto con separadores. Nada glamuroso. Y, sin embargo, en él se decide buena parte del éxito de una importación masiva. Un separador mal elegido, una codificación incorrecta o una coma decimal rebelde pueden arruinar una tarde con una eficacia admirable.
Campos mínimos recomendados
Para actualizar productos existentes, no siempre necesitas importar todo el catálogo completo. De hecho, cuanto menos toques, mejor. Si solo vas a actualizar precios, no importes descripciones, imágenes ni categorías. Si solo vas a cambiar stock, no alteres el nombre del producto. La moderación, en informática, es una virtud infravalorada.
| Campo | Uso | Recomendación |
|---|---|---|
| ID de producto | Identifica el producto dentro de PrestaShop | Muy fiable si los productos ya existen y no cambias de entorno |
| Referencia | Identificador comercial o SKU | Imprescindible si conectas con proveedores o ERP |
| EAN-13 / UPC / MPN | Identificadores externos | Útiles para catálogos grandes, marketplaces y sincronización |
| Precio sin IVA | Precio base del producto | Recomendado para evitar confusiones con impuestos |
| Categoría | Clasificación del producto | No tocar si solo actualizas precios |
| Cantidad | Stock disponible | Actualizar con precaución si hay combinaciones |
| Activo | Producto visible o no visible | Útil para descatalogados, pero peligroso si el proveedor envía valores incompletos |
Codificación, separadores y formato
- Usa codificación UTF-8, especialmente si hay tildes, eñes, símbolos de moneda o caracteres especiales.
- Elige un separador claro: punto y coma
;suele ser más seguro en entornos europeos donde la coma se usa para decimales. - Evita fórmulas de Excel dentro del CSV. Exporta valores planos.
- Usa punto decimal o coma decimal según espere tu configuración, pero no mezcles ambos formatos.
- No incluyas columnas innecesarias. Cada columna adicional es una puerta abierta al malentendido.
- Valida que no existan referencias duplicadas si vas a actualizar por SKU.
💡 Pequeña digresión de taller: una vez vi una importación fallar porque el proveedor enviaba precios con espacios invisibles al final. Nadie los veía. Todos culpaban al servidor. El servidor, esa víctima habitual de nuestros descuidos, era inocente. Un carácter invisible había puesto de rodillas a una tienda entera. Hay tragedias griegas con menos sutileza.
Actualizar precios en PrestaShop: lo que parece simple y no siempre lo es 💶
“Solo queremos cambiar precios”. Frase breve, peligrosa. En PrestaShop, el precio no es siempre un número solitario. Puede convivir con impuestos, ecotasa, descuentos específicos, reglas de catálogo, grupos de clientes, monedas, países, tiendas, combinaciones y redondeos. Un precio, visto de cerca, es una pequeña república con ministerios propios.
Precio base frente a precio final
PrestaShop almacena habitualmente el precio base sin impuestos en el producto. El precio final que ve el cliente depende de la regla de impuestos, el país, el grupo, posibles descuentos y configuración de redondeo. Por eso conviene actualizar precios sin IVA siempre que sea posible, salvo que tu flujo esté diseñado expresamente para precios finales.
| Elemento | Qué afecta | Riesgo típico |
|---|---|---|
| Precio base | Valor principal del producto | Importar con IVA cuando PrestaShop espera sin IVA |
| Reglas de impuestos | Precio final según país o zona | Asignar una regla incorrecta y mostrar precios erróneos |
| Precio específico | Descuentos por cliente, grupo, cantidad, país o periodo | Duplicar descuentos o dejar promociones antiguas activas |
| Reglas de precio del catálogo | Descuentos masivos por categoría, marca, atributos | No recalcular o aplicar descuentos sobre precios ya rebajados |
| Combinaciones | Impacto de precio por talla, color, formato | Actualizar solo el producto padre e ignorar variaciones |
Ojo con los precios específicos
Los precios específicos son potentes. Permiten descuentos por grupo, cliente, moneda, país, tienda, cantidad mínima o rango de fechas. También son un lugar magnífico para sembrar confusión si se importan sin estrategia.
Si tu objetivo es sustituir una tarifa completa, define primero si vas a:
- Actualizar el precio base del producto.
- Eliminar precios específicos antiguos y crear nuevos.
- Mantener descuentos existentes y solo cambiar el precio de partida.
- Aplicar reglas de precio del catálogo en lugar de importar descuentos producto por producto.
🚫 Error muy común: importar una nueva tarifa sin limpiar descuentos anteriores. Resultado: el precio base cambia, pero una regla vieja sigue aplicando un descuento inesperado. El cliente ve un precio, el administrador otro y contabilidad empieza a mirar a desarrollo con una ternura francamente inquietante.
Combinaciones, atributos y stock: el laberinto bajo el escaparate 🧵
Si los productos simples son una avenida, las combinaciones son una ciudad subterránea. Talla S en rojo, talla M en azul, pack de 3, formato XL, acabado mate, capacidad de 128 GB. Cada variación puede tener referencia, EAN, impacto de precio, peso, stock e imagen propia.
Al actualizar catálogos con combinaciones en PrestaShop, hay que distinguir entre:
- Producto padre: contiene datos generales como nombre, categoría, descripción, marca.
- Combinaciones: representan variaciones y pueden modificar precio, peso, referencia y stock.
- Stock disponible: se gestiona normalmente en la estructura de stock asociada al producto y, si aplica, a cada combinación.
En versiones modernas de PrestaShop, el manejo de stock se apoya en registros de disponibilidad vinculados al producto y al atributo de producto. Por eso, cambiar únicamente la cantidad del producto padre cuando existen combinaciones puede no tener el efecto esperado. La tienda, obediente y exasperante, mostrará lo que le diga la combinación.
Buenas prácticas al importar combinaciones
- Usa referencias únicas para cada combinación si el proveedor las ofrece.
- No mezcles en el mismo archivo productos simples y combinaciones complejas si no tienes experiencia.
- Importa primero productos base y después combinaciones.
- Valida que los atributos y valores existan antes de importar.
- Revisa el impacto de precio: una combinación puede sumar o restar al precio base.
- Comprueba el stock por combinación, no solo por producto.
Ajustes del servidor para evitar errores 500, 502 y 504 ⚙️
Una actualización masiva no solo exige un buen archivo. También necesita un servidor preparado. Aquí aparece una contradicción curiosa: queremos procesos grandes en entornos web diseñados para responder rápido. El navegador espera una página; nosotros le pedimos que haga mudanza completa. Y luego nos sorprende que proteste.
Los valores exactos dependen del hosting, del tamaño del catálogo, de la versión de PHP, de la memoria disponible y de si usas Apache, Nginx, LiteSpeed, PHP-FPM o un proxy intermedio. Aun así, hay parámetros que conviene revisar antes de lanzar una importación seria.
| Parámetro | Función | Valor orientativo para importaciones |
|---|---|---|
memory_limit |
Memoria máxima para procesos PHP | 512M o más en catálogos grandes, si el servidor lo soporta |
max_execution_time |
Tiempo máximo de ejecución PHP | 300 a 900 segundos para procesos puntuales |
max_input_time |
Tiempo máximo para procesar entrada | 300 segundos o más según tamaño de archivo |
upload_max_filesize |
Tamaño máximo de archivo subido | Superior al CSV que vas a importar |
post_max_size |
Tamaño máximo de datos POST | Mayor que upload_max_filesize |
max_input_vars |
Número máximo de variables de entrada | 3000, 5000 o más si el panel lo requiere |
max_allowed_packet |
Tamaño máximo de paquete MySQL/MariaDB | 64M o más para operaciones con datos extensos |
request_terminate_timeout |
Límite de tiempo en PHP-FPM | Alinear con max_execution_time |
proxy_read_timeout |
Espera de respuesta en Nginx como proxy | 300 a 900 segundos si aplica |
⚠️ Importante: aumentar límites no convierte un proceso mal diseñado en uno bueno. Solo le da más cuerda. Si importas 100.000 productos en una sola petición HTTP, quizá no necesitas más memoria; necesitas otra estrategia.
Modo debug y logs: mirar donde duele
Cuando algo falla, no basta con decir “PrestaShop se ha roto”. Hay que revisar registros. En PrestaShop 1.7 y 8, los logs de la aplicación suelen encontrarse en var/logs/. Además, el servidor puede registrar errores en archivos de Apache, Nginx, PHP-FPM o en el panel del proveedor de hosting.
Para investigar en un entorno seguro, puedes activar el modo debug desde la configuración de PrestaShop o modificando el archivo de parámetros correspondiente según la versión. No lo dejes activo en producción más tiempo del necesario: mostrar errores internos al público es como dejar las facturas pegadas en el escaparate.
Flujo seguro para actualizar precios y catálogo paso a paso ✅
El método profesional no empieza en el botón “Importar”. Empieza antes, con una copia, una prueba y un plan de regreso. La diferencia entre un administrador prudente y uno temerario no está en que el primero no cometa errores; está en que sabe volver atrás.
1. Haz una copia de seguridad completa
Antes de cualquier actualización masiva, crea una copia de:
- Base de datos completa.
- Archivos de la tienda, especialmente
img/,modules/,themes/y archivos de configuración. - CSV original y versión modificada.
Si tienes acceso por consola, una copia SQL puede hacerse con herramientas como mysqldump. En hosting gestionado, normalmente podrás generarla desde el panel. Lo importante no es el método; lo importante es comprobar que la copia existe y se puede restaurar.
mysqldump -u usuario -p nombre_base_datos > backup-prestashop.sql
2. Trabaja primero en staging
Un entorno de staging es una copia de la tienda donde puedes probar sin afectar ventas reales. Si tu tienda factura a diario, importar directamente en producción es un acto de fe; respetable en una catedral, discutible en comercio electrónico.
- Clona archivos y base de datos.
- Desactiva indexación por buscadores en staging.
- Cambia credenciales de pago, email y servicios externos para evitar operaciones reales.
- Ejecuta la importación completa en staging.
- Compara precios, stock, categorías y productos activos antes de tocar producción.
3. Divide el archivo en lotes
Esta es una de las recomendaciones más simples y menos obedecidas. No subas 50.000 filas si puedes subir 2.000 por tanda. Sí, parece más lento. En realidad, es más rápido que restaurar una tienda rota a las dos de la mañana.
| Tamaño de catálogo | Lote recomendado | Comentario |
|---|---|---|
| Hasta 1.000 productos | 200 – 500 filas | Importación manual normalmente viable |
| 1.000 – 10.000 productos | 500 – 2.000 filas | Conviene probar límites del servidor |
| 10.000 – 50.000 productos | 1.000 – 5.000 filas | Mejor usar módulos robustos o procesos programados |
| Más de 50.000 productos | Lotes dinámicos | Recomendable CLI, API controlada, PIM o integración ERP |
4. Importa solo lo necesario
Si el objetivo es actualizar precios, usa un archivo con identificador y precio. Nada más. No incluyas descripciones HTML, imágenes, categorías o campos SEO si no van a cambiar. Cada dato innecesario es una piedra más en la mochila del proceso.
Ejemplo sencillo de CSV para actualización de precios:
id_product;reference;price
152;CAM-NEG-M;19.95
153;CAM-NEG-L;19.95
154;ZAP-URB-42;64.90
Si actualizas por referencia:
reference;price;active
CAM-NEG-M;19.95;1
CAM-NEG-L;19.95;1
ZAP-URB-42;64.90;1
5. Desactiva tareas pesadas durante la importación
Durante actualizaciones grandes, conviene reducir ruido. No es buena idea importar 20.000 productos mientras se ejecuta una sincronización de marketplace, un módulo de estadísticas recalcula datos y una copia de seguridad comprime imágenes. El servidor no es un héroe trágico; es una máquina con límites.
- Pausa cron jobs no esenciales.
- Evita regeneraciones masivas de imágenes simultáneas.
- Desactiva temporalmente módulos que reaccionan a cada actualización de producto, si sabes exactamente qué hacen.
- Programa la importación en horas de menor tráfico.
- Informa al equipo comercial para que no edite productos durante el proceso.
6. Limpia caché e índices al finalizar
Después de importar, puede ser necesario limpiar caché, regenerar índices de búsqueda o reconstruir facetas si usas filtros por atributos, precios o categorías. No siempre hay que hacerlo en cada lote, pero sí al cerrar la operación.
- Vaciar caché de PrestaShop.
- Reindexar búsqueda interna si se modificaron nombres, referencias o descripciones.
- Actualizar índice de navegación por facetas si cambian precios, atributos o stock.
- Limpiar caché externa si usas Varnish, LiteSpeed Cache, Cloudflare u otro CDN.
- Probar fichas de producto, categorías, carrito y checkout.
Importar desde el Back Office: consejos prácticos para no sufrir
El importador nativo de PrestaShop se encuentra habitualmente en el panel de administración, dentro de las opciones de importación. Permite elegir entidad, subir archivo, seleccionar separador, mapear columnas y decidir ciertas opciones como forzar IDs o eliminar elementos antes de importar, según el tipo de entidad.
Para una actualización de productos existentes, presta especial atención a estas decisiones:
- Forzar IDs: útil si estás importando datos de la misma tienda y quieres actualizar productos por ID. Peligroso si los IDs no corresponden.
- Omitir miniaturas o imágenes: recomendable si no estás actualizando imágenes.
- Separador de campos: debe coincidir exactamente con el archivo.
- Separador de valores múltiples: importante para categorías, características o etiquetas.
- Idioma: fundamental si importas nombres o descripciones multilingües.
- Tienda en multitienda: revisa el contexto antes de importar; aquí se han perdido más horas de las que nadie confiesa.
✅ Recomendación profesional: guarda plantillas de mapeo para importaciones recurrentes. Si cada mes recibes una tarifa del mismo proveedor, no improvises cada vez. La repetición controlada es aburrida, sí, pero el aburrimiento bien gestionado paga facturas.
Actualización masiva mediante API: más control, menos azar 🔌
El Webservice de PrestaShop permite actualizar productos mediante peticiones autenticadas. No es el método más rápido para operaciones gigantes si se usa sin optimización, pero ofrece trazabilidad, validación y una integración más limpia que manipular tablas a ciegas.
Para usarlo bien:
- Activa el Webservice solo con permisos necesarios.
- Usa claves distintas por integración.
- Registra cada petición y respuesta.
- Procesa por lotes y añade reintentos ante errores temporales.
- No actualices todos los campos si solo cambia el precio.
- Respeta límites del servidor para no crear un pequeño ataque DDoS contra tu propia tienda.
Una estrategia habitual consiste en tener un proceso intermedio que lea el feed del proveedor, compare con los datos actuales y actualice únicamente productos modificados. Esta diferencia es enorme: no es lo mismo tocar 30.000 productos cada noche que tocar 1.200 porque son los únicos que han cambiado. El primer método es una avalancha; el segundo, riego por goteo.
SQL directo: cuándo sí, cuándo no y por qué da respeto 🧯
Modificar la base de datos directamente puede ser tentador. Es rápido, preciso y no depende del navegador. También puede romper relaciones internas, dejar datos inconsistentes o saltarse lógica de PrestaShop que normalmente se ejecuta al guardar productos.
PrestaShop distribuye información de producto entre varias tablas, y el prefijo puede variar, aunque comúnmente se usa ps_. Algunas tablas relevantes son:
| Tabla habitual | Contenido | Precaución |
|---|---|---|
ps_product |
Datos base del producto | No suficiente en multitienda |
ps_product_shop |
Datos del producto por tienda | Clave para precios y estado en multitienda |
ps_product_lang |
Nombre, descripción y campos por idioma | Requiere gestionar idioma y tienda |
ps_product_attribute |
Combinaciones | Impactos de precio y atributos |
ps_product_attribute_shop |
Combinaciones por tienda | Importante en multitienda |
ps_stock_available |
Stock disponible | Distinguir producto y combinación |
ps_specific_price |
Precios específicos y descuentos | Evitar duplicados y reglas obsoletas |
Si vas a hacer una actualización SQL, usa transacciones cuando sea posible, crea tablas temporales para cargar datos, compara antes de escribir y registra cuántas filas se modifican. Y, por favor, ejecuta primero un SELECT. La civilización empezó el día en que alguien decidió mirar antes de borrar.
SELECT p.id_product, p.reference, ps.price
FROM ps_product p
INNER JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE p.reference IN ('CAM-NEG-M', 'CAM-NEG-L');
Una actualización de precios por SQL podría requerir modificar tanto ps_product como ps_product_shop, según configuración y versión. No copies consultas de internet sin adaptarlas a tu tienda, prefijo, multitienda e impuestos. Lo que salva una instalación puede hundir otra con impecable indiferencia.
🚨 Regla de hierro: no ejecutes SQL directo en producción sin copia restaurable y prueba previa. Si no sabes explicar qué tablas modifica una consulta, no deberías ejecutarla.
Automatización con cron y procesos por lotes ⏱️
Para tiendas con actualización diaria de precios o stock, la importación manual envejece rápido. Al principio parece aceptable. Luego llega el viernes, el proveedor cambia 12.000 precios, alguien está de vacaciones y el archivo pesa como una novela rusa.
Automatizar no significa perder control. Significa diseñar un flujo que haga siempre lo mismo, con registros, validaciones y alertas. Un buen proceso automático debería:
- Descargar el archivo desde FTP, SFTP, URL privada o API del proveedor.
- Validar estructura: columnas, codificación, separador, número de filas.
- Detectar cambios frente al estado actual.
- Aplicar actualizaciones en lotes pequeños.
- Registrar productos actualizados, omitidos y fallidos.
- Enviar aviso por email o sistema interno al terminar.
- Detenerse si detecta anomalías graves, por ejemplo una tarifa con precios a cero.
Este último punto es esencial. Un proceso automático sin frenos es eficiente del mismo modo que un incendio es luminoso.
Errores frecuentes al actualizar masivamente en PrestaShop
1. Importar precios con IVA cuando la tienda espera precios sin IVA
El resultado será una desviación sistemática en todo el catálogo. A veces se detecta rápido. A veces no, y entonces la tienda vende durante días con márgenes deformados. Revisa siempre si el campo representa precio neto o precio final.
2. No tener en cuenta multitienda
En multitienda, un producto puede tener valores distintos según la tienda. Actualizar solo datos globales puede no alterar lo visible en una tienda concreta. Antes de importar, confirma el contexto de tienda y las tablas o campos afectados.
3. Subir imágenes junto con una actualización de precios
Las imágenes son pesadas. Si no cambian, no las toques. Importar imágenes desde URLs externas puede multiplicar tiempos, generar errores de descarga y consumir recursos de forma brutal.
4. No limpiar reglas de precio antiguas
Un precio nuevo puede quedar maquillado por un descuento viejo. Revisa precios específicos, reglas de catálogo y promociones activas.
5. Ignorar redondeos
PrestaShop permite configurar modos de redondeo. Si tu ERP redondea de una forma y la tienda de otra, aparecerán diferencias de céntimos. Pequeñas, sí. Pero los céntimos son como arena en un engranaje: parecen nada hasta que todo chirría.
6. No revisar módulos externos
Marketplaces, ERPs, feeds de Google Merchant Center, módulos de cache, facturación o sincronización pueden reaccionar ante cambios de catálogo. Algunos lo hacen bien. Otros, con una creatividad que nadie pidió.
7. No medir tiempos por lote
Si un lote de 500 filas tarda 20 segundos, uno de 10.000 no tardará necesariamente 400. Puede tardar mucho más, fallar o bloquear recursos. Mide, ajusta y escala gradualmente.
Checklist profesional antes de lanzar la actualización masiva 🧾
Antes
- Copia de seguridad verificada.
- Prueba en staging.
- CSV validado en UTF-8.
- Separadores correctos.
- Columnas mínimas necesarias.
- Reglas de impuestos revisadas.
- Precios específicos auditados.
Durante
- Importar por lotes.
- Monitorizar CPU, RAM y base de datos.
- Revisar logs si aparece un error.
- No editar productos manualmente al mismo tiempo.
- No ejecutar procesos pesados simultáneos.
Después
- Limpiar caché.
- Reindexar búsqueda si corresponde.
- Revisar navegación por facetas.
- Comprobar productos de muestra.
- Probar carrito y checkout.
- Comparar totales frente al archivo original.
Cómo validar que la actualización salió bien 🔍
No basta con que el importador diga “proceso finalizado”. Esa frase puede ser tan tranquilizadora como ambigua. Hay que validar datos reales.
- Elige una muestra de productos baratos, caros, con descuento, con combinaciones y sin stock.
- Comprueba precio en Back Office y Front Office.
- Verifica precio con impuestos incluidos y excluidos.
- Añade productos al carrito para confirmar el cálculo final.
- Comprueba una categoría con filtros por precio.
- Revisa productos con promociones activas.
- Exporta datos después de importar y compáralos con el archivo fuente.
Si tienes conocimientos técnicos, una comparación mediante consulta SQL o script puede detectar diferencias masivas con mayor precisión que una revisión visual. La vista humana es buena para detectar rarezas; mala para auditar 30.000 filas. Para eso inventamos las máquinas, aunque a veces parezcan vengarse.
Rendimiento después de una importación: no descuides la tienda visible 🚀
Después de una actualización grande, el rendimiento puede resentirse temporalmente. Cachés vacías, índices recién modificados, consultas de módulos, regeneraciones pendientes. El escaparate puede quedarse algo pesado, como una ciudad después de una nevada.
Para estabilizar la tienda:
- Vacía y precalienta caché si usas sistemas de cache avanzados.
- Comprueba logs de errores después de la importación.
- Revisa consultas lentas si tienes acceso a slow query log.
- Optimiza tablas si hubo operaciones muy grandes, con prudencia y en horario de bajo tráfico.
- Controla métricas de Core Web Vitals si cambiaste imágenes, categorías o filtros.
- Verifica feeds externos como Google Merchant Center, Facebook Catalog o marketplaces.
¿Cuándo conviene usar un PIM o ERP en lugar de CSV?
El CSV es práctico hasta que deja de serlo. Si gestionas múltiples canales, varios proveedores, traducciones, reglas de enriquecimiento, imágenes, atributos técnicos y tarifas por mercado, quizá necesitas un PIM o una integración ERP. No por moda, sino por higiene operativa.
Señales claras:
- Recibes catálogos de varios proveedores con estructuras distintas.
- Actualizas stock y precios varias veces al día.
- Vendes en marketplaces además de tu PrestaShop.
- Necesitas aprobación editorial antes de publicar productos.
- Hay muchos errores humanos en hojas de cálculo.
- El equipo dedica demasiadas horas a limpiar archivos.
Un PIM centraliza información de producto. Un ERP gobierna operaciones, compras, inventario y facturación. PrestaShop debería vender; no necesariamente actuar como centro universal de todos los datos. Cada herramienta tiene su reino. Confundirlos es el principio de muchas noches largas.
Preguntas frecuentes sobre actualización masiva en PrestaShop ❓
¿Cuál es la forma más segura de actualizar precios masivamente?
Para tiendas pequeñas o medianas, un CSV bien preparado e importado por lotes suele ser suficiente. Para tiendas grandes o actualizaciones frecuentes, es más seguro usar un módulo profesional, API o proceso CLI con logs, validaciones y reintentos.
¿Puedo actualizar solo precios sin tocar el resto del producto?
Sí. De hecho, es lo recomendable. Usa un archivo con identificador del producto y precio. Evita incluir columnas que no necesites modificar.
¿Por qué aparece error 500 al importar productos?
Puede deberse a memoria insuficiente, tiempo de ejecución agotado, errores en el CSV, módulos incompatibles, excepciones de PrestaShop o problemas de base de datos. Revisa logs de PHP, servidor y PrestaShop para obtener el motivo real.
¿Qué hago si aparece error 504 Gateway Timeout?
Divide el archivo en lotes más pequeños y revisa límites de Nginx, Apache, PHP-FPM o proxy. Si el proceso es grande, evita depender del navegador y considera usar tareas por consola o cron.
¿Es recomendable actualizar precios directamente en la base de datos?
Solo si sabes exactamente qué tablas intervienen y has probado antes en staging. En multitienda o con combinaciones, tocar una sola tabla puede dejar datos incoherentes.
¿Debo desactivar la tienda durante la importación?
No siempre. Para cambios pequeños, no hace falta. Para operaciones grandes, puede ser prudente activar mantenimiento durante una ventana breve o ejecutar el proceso en horas de baja actividad.
¿Qué pasa con los productos con combinaciones?
Debes actualizar la combinación correcta si el precio, referencia o stock depende de ella. Cambiar solo el producto padre puede no modificar lo que ve el cliente en una variación concreta.
¿Cómo evito que los descuentos antiguos alteren los nuevos precios?
Audita precios específicos y reglas de precio del catálogo antes de importar. Decide si se mantienen, se reemplazan o se eliminan. No mezcles estrategias sin documentarlo.
Una estrategia sensata vale más que un servidor enorme
Actualizar un catálogo masivo en PrestaShop sin errores de servidor no depende de un truco secreto. Depende de respetar el sistema: preparar datos limpios, importar por lotes, ajustar límites razonables, revisar logs, probar en staging y validar resultados. Es menos épico de lo que algunos quisieran, pero mucho más rentable.
Hay una belleza discreta en una importación que termina sin ruido. Sin pantallas blancas. Sin llamadas urgentes. Sin ese silencio espeso que aparece cuando nadie quiere preguntar quién hizo clic en “Importar”. La tecnología, cuando funciona bien, se parece a la fontanería: nadie la celebra, pero todos la echan de menos cuando falla.
Resumen operativo para hacerlo bien 🛠️
Haz copia de seguridad, prueba en staging, usa CSV limpio en UTF-8, divide en lotes, importa solo campos necesarios, revisa límites de PHP y servidor, controla precios específicos, respeta combinaciones y valida en Front Office. La actualización masiva perfecta no es la más rápida: es la que no deja ruinas detrás.