Cómo configurar y gestionar la multitienda de PrestaShop

Qué haríamos

Primero enumeraríamos qué debe compartirse y qué debe ser distinto, y después contrastaríamos ese mapa con tu tienda actual: versión de PrestaShop, módulos esenciales, conexiones con el ERP y el almacén, tema, catálogo y datos de clientes, mercados y responsabilidades del personal. Una integración imprescindible que no pueda distinguir entre tiendas puede determinar la arquitectura antes de crear otro escaparate.

Crea la estructura propuesta en una copia aislada en un entorno de pruebas, sin que los correos a clientes, los pagos reales ni las exportaciones de existencias o pedidos lleguen a los sistemas de producción. Acuerda las comprobaciones de aceptación, ensaya el cambio y planifica una transición controlada con un procedimiento de restauración probado. Mantén el escaparate actual en funcionamiento hasta el momento acordado.

Si quieres evaluar las dependencias de módulos esenciales en una copia de tu tienda, PrestaShop Module Selection & Fit Assessment prueba las opciones disponibles según el resultado necesario.

Elige multitienda o instalaciones separadas

Multitienda ejecuta varios escaparates desde un mismo código, base de datos y back office. La jerarquía es grupo de tiendas, tienda y después URL de tienda. Un grupo define el uso compartido admitido de clientes, stock y carritos; cada tienda tiene sus propias asociaciones y valores de configuración compatibles.

Las reglas comerciales, como la visualización de impuestos, las cantidades mínimas y la disponibilidad de métodos de pago, también requieren configuración y pruebas. Para el recorrido del comprador profesional, consulta la guía de configuración B2B.

Todas las tiendas de una instalación comparten las consecuencias de un despliegue fallido de código o un cambio en la base de datos. Haz copias de seguridad de toda la base de datos y los archivos. Documenta tu mapa de tiendas: grupos, dominios, idiomas, monedas, asociaciones de catálogo, propiedad del stock y ámbito previsto de los módulos.

Decide los tres ajustes de uso compartido del grupo de tiendas

Las tiendas usan una tabla estándar de clientes con pertenencia a tienda y grupo. No tienen una tabla de clientes separada cada una. Por tanto, las cuentas separadas y las compartidas requieren configurar deliberadamente los grupos, no copiar manualmente entre tablas.

El uso compartido sigue limitado al grupo de tiendas. La disponibilidad de cuentas compartidas no garantiza una sesión de navegador o carrito compartidos entre dominios sin relación: las cookies del navegador están limitadas a su dominio. Prueba los hosts y rutas elegidos. Un pedido conserva el id_shop de la tienda donde se realizó. Usa el contexto del back office y los permisos de empleados para gestionar los pedidos de las tiendas previstas.

Decide estos ajustes en un entorno de pruebas antes de que los clientes, pedidos y stock reales dificulten un cambio. No trates un interruptor de uso compartido como una forma segura de fusionar un conjunto establecido de tiendas independientes.

Revisa un caso de venta minorista y mayorista

Tu tienda minorista y la tienda profesional que planeas crear venden el mismo accesorio desde un almacén. Deben compartir stock, las solicitudes de alta profesional necesitan aprobación y solo las cuentas profesionales aprobadas deben ver el pago por factura. Estos requisitos no exigen por sí solos compartir cuentas de clientes ni carritos. Decide por separado si compartir clientes y cantidades, y activa Compartir pedidos solo cuando un carrito deba pasar de una tienda a otra.

1. Asocia el producto de prueba a ambas tiendas y asígnale precios minoristas y profesionales que se distingan. Registra la cantidad disponible inicial y el precio esperado en cada contexto.
2. Realiza un pedido de prueba minorista y comprueba la cantidad restante en ambas tiendas y la tienda de origen que figura en el pedido. Repítelo desde la tienda profesional y sigue el movimiento de stock a través del conector del almacén para detectar un posible procesamiento duplicado.
3. Prueba una cuenta exclusivamente minorista, una solicitud profesional sin aprobar y un comprador profesional aprobado. Comprueba sus precios y opciones de pago reales. Compartir una cuenta no debe conceder acceso a condiciones profesionales simplemente por visitar la URL de esa tienda.

Si el conector no puede identificar qué tienda originó un pedido, trátalo como una dependencia sin resolver antes del lanzamiento. Compartir almacén no elimina la necesidad de dirigir correctamente las facturas, comunicaciones con clientes y devoluciones de cada tienda.

Activa multitienda y crea la estructura de tiendas

1. Haz una copia de seguridad de toda la instalación y ensaya en un entorno de pruebas.
2. Activa Multitienda en Parámetros de la tienda → Configuración.
3. Abre Parámetros avanzados → Multitienda y crea o selecciona el grupo de tiendas previsto.
4. Configura las tres opciones de uso compartido según tu plan.
5. Crea la tienda con su nombre, grupo y categoría raíz. Si importas datos de otra tienda, revisa cada categoría de importación ofrecida y verifica las asociaciones resultantes.
6. Añade la URL de la tienda y confirma el dominio, dominio SSL, ruta física, ruta virtual, estado activado e indicador de URL principal.
7. Completa el enrutamiento del servidor y prueba después la tienda antes de importar o editar grandes cantidades de datos.

Un catálogo o configuración copiados son un estado inicial. No supongas que cada valor copiado permanece vinculado a las ediciones posteriores de la tienda original.

Configura DNS, TLS y el enrutamiento del servidor

Los dominios y subdominios independientes deben resolver al servidor. Configura el servidor web para servir el mismo directorio de PrestaShop para cada host e instala certificados que cubran todos los nombres de host HTTPS. Un certificado comodín solo cubre nombres dentro de su ámbito permitido; comprueba los nombres reales del certificado.

La URI física es la ruta web real de la instalación. La URI virtual identifica una ruta de tienda que no necesita un directorio de instalación separado. Para una instalación en la raíz del dominio, estos son ejemplos de configuración:

Apache

Configura primero los hosts virtuales y TLS. Activa el soporte de reescritura necesario y permite las reglas de reescritura de la instalación. Guarda los ajustes de URL en Parámetros de la tienda → Tráfico y SEO → SEO y URLs para generar las reglas aplicables de .htaccess. Inspecciona el resultado y pruébalo. El archivo .htaccess no configura DNS, certificados ni hosts virtuales.

nginx

nginx no lee .htaccess. Empieza por la configuración de nginx para PrestaShop, incluidas las reescrituras de recursos, los directorios protegidos y la gestión de PHP. Configura cada host para usar la misma raíz de instalación.

Para una instalación en la raíz cuya ruta virtual de tienda sea wholesale/, añade una reescritura de prefijo en el bloque de servidor antes de las reescrituras normales de PrestaShop:

rewrite ^/wholesale/(.*)$ /$1 last;

Mantén la alternativa normal al controlador frontal de la tienda:

location / {
    try_files $uri $uri/ /index.php$is_args$args;
}

Los parámetros de PHP deben conservar la REQUEST_URI original, incluido /wholesale/, para que PrestaShop identifique la tienda. La reescritura interna permite que las mismas reglas de recursos y controlador frontal sirvan la ruta virtual. Adapta el prefijo a cada tienda virtual, conserva todas las ubicaciones de seguridad y comprueba la configuración de nginx antes de recargar. Prueba la página de inicio de la tienda, las URL amigables, las imágenes, las rutas de módulos, el carrito y el proceso de compra.

Para ambos servidores, confirma que HTTPS y las cabeceras fiables del proxy inverso coincidan con las URL configuradas. Prueba las redirecciones canónicas desde hosts y rutas alternativos. Vacía las cachés pertinentes después de cambiar la configuración de URL.

Comprende el contexto de tienda y los distintos ámbitos de datos

Lee el selector de tienda antes de cada guardado. Elige Todas las tiendas, un grupo de tiendas o una tienda según el cambio previsto. El ámbito admitido por un formulario determina a qué puede afectar el guardado; no supongas que todas las páginas aceptan todos los contextos.

Las casillas pueden significar usar el valor de configuración heredado, seleccionar campos que actualizar o elegir las tiendas afectadas por una acción. Lee la etiqueta y la ayuda de ese formulario y versión. Una casilla de actualización de producto no promete herencia continua.

Asocia productos y categorías solo a las tiendas previstas. Verifica el ámbito mostrado por las acciones de desactivar, quitar asociación y eliminar antes de confirmarlas. Quitar una asociación y eliminar la entidad compartida tienen consecuencias distintas.

Configura temas, logotipos, idiomas activados, monedas, transportistas, métodos de pago e impuestos en su contexto admitido. Recarga la página y visita cada tienda después de guardar. Da nombres claros a los recursos específicos de tienda, por ejemplo banner-de.jpg, y documenta cualquier recurso compartido.

Prueba los cambios de idioma y moneda en una página de producto: el visitante debe llegar al producto correspondiente y la moneda seleccionada debe mantenerse en el carrito y el proceso de compra. Registra a qué tienda pertenecen cada página legal y cada identidad de remitente antes de copiar contenido o configuración entre marcas. Consulta la guía de traducciones y venta internacional para configurar los mercados.

Prueba los módulos en dos contextos de tienda

1. Identifica qué ajustes del módulo son globales por diseño y cuáles deben variar por tienda.
2. En un entorno de pruebas, guarda valores distintos en dos tiendas. Recarga ambas páginas de configuración e inspecciona ambos escaparates.
3. Ejercita la salida de hooks, importaciones, tareas cron, tareas de línea de comandos y aciertos de caché. Pueden ejecutarse con un contexto distinto al de la sesión del navegador de un empleado.
4. Comprueba la pertenencia de los datos personalizados mediante columnas de tienda, tablas de asociación o entidades padre con ámbito definido. Una tabla no necesita una columna id_shop cuando otro modelo sólido de pertenencia proporciona el ámbito.
5. Comprueba las claves de caché para cada dimensión del contexto que afecte al resultado, incluidas la tienda y el idioma o moneda pertinentes.

Para los conectores de ERP, almacén, marketplaces, contabilidad y correo, registra cómo identifica cada importación, exportación y notificación su tienda de destino. Ejecuta las tareas programadas en su contexto real y revisa los registros y los datos salientes resultantes. Un conector que asume la tienda predeterminada necesita una modificación compatible o una sustitución si su flujo debe atender otras tiendas; añadir una columna de tienda no corrige por sí solo el resto del flujo.

Cuando una integración necesaria requiera adaptar el ámbito por tienda, PrestaShop Custom Module Development Service ofrece un desarrollo conforme a una especificación acordada.

Configuration::get() y Configuration::updateValue() infieren la tienda o grupo actuales cuando se omiten los argumentos de ámbito. Los ID explícitos resultan útiles cuando el contexto de ejecución difiere del destino. Las escrituras globales, el contexto erróneo, las consultas sin ámbito y las colisiones de caché necesitan diagnósticos separados.

Una fila de configuración específica de tienda puede funcionar con id_shop_group establecido en NULL. Una única fila global puede ser un valor predeterminado heredado. Prueba las lecturas y escrituras previstas antes de declarar cualquiera de los estados un error y corrige la ruta de la aplicación en lugar de insertar filas de configuración manualmente.

La compatibilidad depende de la función. Por ejemplo, los ajustes habituales de SEO Revolution y la capa de configuración de Financial Revolution usan rutas globales de configuración. Confirma el ámbito de cada función antes de esperar ajustes independientes por tienda.

Comprueba el SEO y el rendimiento de cada tienda

Para las páginas que quieras indexar por separado, usa URL canónicas deliberadas dentro de la tienda correspondiente. Usa una canónica entre dominios solo cuando pretendas consolidar. Limita el sitemap de cada tienda a sus URL previstas y verifica las propiedades pertinentes de Search Console.

Las alternativas de idioma del núcleo se refieren a idiomas de la tienda actual. Las páginas equivalentes de tiendas separadas necesitan su propia correspondencia entre tiendas. Se recomienda hreflang para alternativas lingüísticas y regionales, con autorreferencias, URL completas y enlaces recíprocos entre páginas equivalentes. Un x-default opcional puede apuntar a una alternativa adecuada.

Si necesitas generar conjuntos de idiomas, Hreflang Tags Manager ofrece una vista previa de auditoría y conjuntos para los idiomas activos, con conjuntos separados por tiendas y dominios. No emite etiquetas para tiendas con un único idioma activo. Antes de elegirlo, prueba en el entorno de pruebas los enlaces recíprocos que necesitas entre páginas equivalentes de distintas tiendas, los tipos de página admitidos y la salida del sitemap. Disponer de conjuntos de idiomas por tienda no demuestra que exista la correspondencia necesaria entre tiendas.

La ausencia de enlaces de retorno puede hacer que se ignoren esas anotaciones mientras siguen funcionando las relaciones recíprocas válidas. Hreflang no es un requisito de indexación ni una garantía de posicionamiento. Sigue las directrices de Google sobre páginas localizadas e inspecciona el conjunto generado.

Mide las consultas de catálogo, las uniones de asociaciones, la carga de configuración y el uso de caché con tu carga de trabajo. El núcleo mantiene en caché la configuración cargada dentro del proceso; cada Configuration::get() no es una nueva consulta a la base de datos. Los valores globales predeterminados también hacen que no tenga que existir una fila de configuración por tienda.

Usa EXPLAIN para consultas lentas y revisa los índices compuestos existentes antes de añadir un índice id_shop. El almacenamiento en caché depende de claves, contextos e invalidación, así que planificar la capacidad requiere mediciones en lugar de multiplicar por el número de tiendas. Consulta la guía de rendimiento.

Resuelve problemas de ámbito y mantén todas las tiendas

Un producto aparece en la tienda equivocada

Comprueba sus asociaciones en el editor de productos y verifica el conjunto de filas. Ambos ejemplos SQL utilizan el prefijo de tablas ps_; sustitúyelo por el de tu instalación. Este ejemplo de solo lectura utiliza el producto 123; introduce un ID de producto real:

SELECT id_product, id_shop, active
FROM ps_product_shop
WHERE id_product = 123;

Corrige las asociaciones mediante el editor admitido y comprueba después la pertenencia a categorías, la visibilidad y los listados en caché.

Un guardado afecta a ambas tiendas

Vuelve a comprobar el contexto activo, el ámbito del campo, los valores heredados y el almacenamiento del módulo. Compara los valores anteriores y posteriores en dos contextos. Una función exclusivamente global puede estar funcionando como se diseñó.

Un carrito aparece en varias tiendas

Comprueba primero el ajuste Compartir pedidos del grupo. Inspecciona el nombre, dominio y ruta reales de la cookie en el navegador y después las URL de las tiendas. El uso compartido intencional de carritos del grupo y un defecto de aislamiento necesitan soluciones distintas. El núcleo deriva el ámbito de la cookie; no existe un campo general de dominio de cookies en Parámetros de la tienda → Configuración.

Una importación o URL llega a la tienda equivocada

Selecciona la tienda de destino antes de abrir la herramienta de importación. Prueba una importación pequeña y verifica las asociaciones. Para redirecciones, comprueba DNS, hosts virtuales, certificados, cabeceras de proxy, ajustes canónicos y estas filas de URL:

SELECT s.id_shop, s.name, su.domain, su.domain_ssl,
       su.physical_uri, su.virtual_uri, su.main, su.active
FROM ps_shop s
JOIN ps_shop_url su ON su.id_shop = s.id_shop
ORDER BY s.id_shop, su.main DESC;

Comprobaciones habituales

• Carga cada tienda y verifica el tema, los productos, el idioma, los precios y las redirecciones.
• Prueba la compra, los métodos de pago, los efectos sobre stock y la tienda registrada en los pedidos.
• Revisa los ajustes de módulos con ámbito de tienda, los registros, los dominios de remitente y los correos de prueba.
• Comprueba las respuestas de sitemap y las asociaciones de productos después de importaciones.
• Tras actualizar un módulo o el núcleo, repite las comprobaciones en todas las tiendas, revisa las URL e invalida las cachés afectadas.

Planifica el cambio y entrega la operativa

1. Registra los cambios de catálogo, clientes y pedidos realizados desde que se creó la copia de pruebas. Acuerda cómo llevar la configuración probada a producción sin sobrescribir esos cambios con una base de datos antigua.
2. Elige la ventana del cambio y designa a la persona que controla las importaciones y escrituras. Decide si hay escrituras que deban detenerse y cómo se conciliarán los pagos, pedidos y actualizaciones de almacén en curso.
3. Ensaya la restauración de la copia de seguridad completa y define las condiciones de fallo que activarán la reversión. Si llegan pedidos nuevos tras el cambio, consérvalos y concílialos antes de restaurar; una copia anterior al lanzamiento no los contiene.
4. Utiliza las comprobaciones habituales anteriores como criterios de aceptación del lanzamiento de cada tienda. Asigna un responsable a cada comprobación y registra el resultado antes de entregar el nuevo escaparate al personal.

Qué preguntar a tu desarrollador o agencia

• ¿Qué funciones necesarias de los módulos se probaron en contextos de tienda separados y cuáles siguen siendo globales por diseño?
• ¿Cómo conserva cada conector la pertenencia a una tienda en tareas programadas, notificaciones y referencias externas?
• ¿Puedes demostrar la reversión y conciliar los pedidos recibidos tras el cambio?
• ¿Qué empleados pueden realizar cambios de grupo o globales y dónde están el mapa de tiendas y las instrucciones operativas?

Pide al personal que ensaye un cambio de precio específico de una tienda y confirme el resultado en el otro escaparate antes de empezar las ediciones habituales. Registra quién autoriza los cambios de campos compartidos para que los nuevos miembros del equipo sepan cuándo una edición aparentemente local necesita una revisión más amplia.

Preguntas de los propietarios de tiendas

¿Conservarán los clientes sus contraseñas al reunir tiendas separadas?

Exige que el ensayo de migración demuestre el acceso de las cuentas existentes y acuerda cómo se tratarán las direcciones de correo duplicadas. No prometas la continuidad de las cuentas por el mero hecho de activar multitienda ni fusiones identidades solo porque coincidan las direcciones de correo.

¿Un único back office significa que todos los empleados ven todas las tiendas?

Revisa los permisos y las asociaciones de tienda de los empleados, inicia sesión como un empleado con restricciones y prueba el acceso a pedidos, clientes y pantallas de módulos. Comprueba también las exportaciones: una pantalla restringida no basta si su exportación incluye registros de otra tienda.

¿Podemos ceder o vender una marca más adelante?

Planifica la extracción antes de comprometerte a compartir entidades. Pide una exportación con alcance definido y un ensayo que cubran los pedidos, clientes, asociaciones de catálogo, archivos multimedia y referencias externas de esa tienda, con un tratamiento acordado de los registros utilizados por otras tiendas.

¿Necesitamos una cuenta de pagos por tienda?

Comprueba las entidades comerciales y el contrato con el proveedor; después prueba las credenciales por tienda del conector y el enrutamiento de las notificaciones. La administración centralizada no determina qué negocio recibe los fondos; concilia cada pago de prueba con la cuenta y el pedido previstos.